一下说“等会儿这个项目现在其实还没准备好。”所以 Vibecoding 真正危险的地方不是入门难而是入门太顺。顺到你以为项目已经启动实际上只是生成了一堆暂时看起来像项目的东西。这就是我说的从 Vibecoding 入门到 Agent 差点入土。Vibecoding 不是坏事盲跑才是我不反感 Vibecoding。相反我觉得它是 AI 编程最有生命力的一种用法。人先用感觉、目标和反馈把方向跑起来再让 Agent 帮你补结构、写代码、改文件、做验证。这比一开始就写厚厚的 PRD 更接近真实创造。但 Vibecoding 有一个前提你得知道什么时候该让 Agent 跑什么时候该先把上下文补齐。很多失败不是发生在写代码时而是发生在更早的启动阶段。比如模型配置看起来填好了其实没有通过真实校验用户需求只有一句模糊想法Agent 已经开始拆任务项目需要工程、产品、安全、运营等不同视角结果只用了一个通用开发角色文件生成了但没人检查它是不是能被 Codex 继续接手页面显示成功实际只是流程走完了。失败不可怕失败会停。假成功最麻烦因为它会继续往下滚。坑一能生成不等于能接手很多 Vibecoding 新手会把“AI 生成了文件”当成“项目启动了”。这个判断太乐观。一个真实项目能不能接着做不只看有没有文件。还要看这些文件有没有回答几个问题我们在做什么第一阶段做什么谁负责判断方案后续工具从哪里接手哪些能力是必须安装的哪些事情当前明确不做如果这些没有说清楚Agent 写得越多后面越难收拾。你会得到一个看起来很忙的项目但没有主线。这也是为什么“协作包”比“脚手架”更重要。脚手架解决的是初始结构协作包解决的是接下来谁怎么干。坑二模型状态是假的Agent 还在跑AI 工具里最容易被忽略的细节是 provider 和 model 的状态。“发现配置”不是“渠道可用”。“渠道可用”也不是“模型可用”。这三件事必须分开。发现配置只能说明系统看到了一个线索。它可能来自本地文件、环境变量或者用户刚刚输入的一段文本。渠道可用至少要经过认证、地址、协议和轻量连通性校验。模型可用还要确认当前模型确实能被这个渠道调用最好来自受控选择而不是让用户随手填一个名字。如果这层没做Agent 就可能带着假的模型状态开工。它不是不努力它是从第一步就站在了不可靠的地基上。坑三团队角色靠模板凑Vibecoding 很容易让人产生一个错觉反正 Agent 都挺聪明给一个万能角色就够了。小项目也许能凑合。稍微复杂一点就不行。做网站、做 MCP、做 Skill、做后台系统、做内容工具、做内部自动化背后需要的角色是不一样的。工程师、产品经理、设计师、安全审查、文档、测试、运营不是每次都全要也不是每次都不要。关键在于为什么选为什么不选。这里最怕两种情况。一种是模板套人。每个项目都塞同一组角色看起来全面实际很虚。另一种是程序偷偷补人。主 Agent 没判断清楚程序发现少了某类角色就静默补上。这样生成物可能更完整但业务判断反而被代码替代了。更好的做法是让主 Agent 明确说明团队组成和取舍理由再让另一个审查角色挑刺你是不是漏了明显候选人你是不是选了不该选的人你的团队真的回应了用户目标吗一个靠谱的启动器应该先做笨活我觉得好的 Agent 启动器不应该一上来就炫“能生成多少文件”。它应该先做一些看起来很笨、但非常重要的事。先确认模型真的能调用。再确认用户到底想做什么。然后让 Agent 给出几个可比较的方案而不是直接冲进实现。接着让用户明确选一个方向。最后检查生成的协作包能不能被后续工具接手。这些步骤不酷也不适合拿来做夸张宣传。但它们能少挖坑。对 Vibecoding 来说这比一口气生成一大堆文件更值钱。星星的vibecoding启动器在解决这个问题星星的vibecoding启动器做的就是这类事。它的公开仓库在这里xinmengmeng-ai/CommonHE。按照公开 README它是一个 Windows 桌面启动器v1.0 的 release package 在release/CommonHE-v1.0.zip目标是为选定 workspace 生成 Codex handoff collaboration package。换成更直白的话它不是替你直接写完整业务项目而是帮你把项目交给 Codex 之前的那段启动上下文做扎实。它的主流程有几个点值得看先做 provider、model、API key、base URL 校验再让主流程继续让用户选择 workspace而不是在错误目录里盲跑通过内置 Agent 对话澄清项目方向输出三套方案并通过内置选择器确认最终方向生成面向 Codex 的协作包用本地 gates 和 package checks 判断初始化是否真的完成。本地真源里还进一步定义了两个内部角色梦星星和星梦梦。梦星星负责理解用户目标、推断团队、输出三套方案星梦梦负责语义验收专门挑错防止“文件存在就算成功”。还有一个很适合宣传、但也确实有实际意义的点它会使用agency-agents-zh作为团队推断知识源之一。这个角色库写明有 215 个即插即用的 AI 专家角色覆盖工程、设计、营销、产品、游戏、安全、金融等 18 个部门。这不是为了把 215 个角色全塞进一个项目。真正有用的是主 Agent 在做团队选择时不必总从几个通用角色里硬凑。它可以在一个更宽的专家池里判断这个 Vibecoding 项目到底该让哪些角色进来哪些暂时别来。它不适合什么人如果你只是想随手让 AI 写一个 demo不在乎后续维护也不需要 Codex 接着做那你可能不需要这种启动器。直接打开工具开写就行。如果你想用 Vibecoding 快速探索一个想法但又希望它后面能进入更严肃的项目协作启动器就有意义了。它更适合这类场景你想让 Codex 接手一个新项目或已有项目你不想每次都重新写 Agent 协作规则你需要先比较几套方案再决定怎么做你希望模型、workspace、团队角色、协作包都有明确记录你不想被“初始化成功”骗一次。这不是一个万能生成器。它更像 Vibecoding 前面的刹车和方向盘。你还是可以跑得很快但不至于一脚油门冲进沟里。少一点假成功才是真的提速Vibecoding 的核心吸引力是让人更快进入创造状态。这个方向没错。但如果 Agent 一开始拿到的是假的模型状态、含混的用户目标、随便拼出来的团队角色那它跑得越快偏得越远。所以我现在看 Agent 工具会先看它怎么处理启动阶段。它是不是敢在模型没通过时阻断是不是让主 Agent 真的理解需求是不是让用户选方案是不是有人负责语义验收是不是明确告诉你它不做什么