Vibecoding 最迷人的地方，是它让“开始做一个东西”变得特别轻。你有一个想法，打开 AI 编程工具，说几句话，项目就有了第一批文件、第一段界面、第一套目录。那一刻很爽。
但很多人也是从这里开始翻车的。
不是 Agent 不会写。恰恰相反，它太会写了。它会在上下文不清、模型状态不稳、团队角色没选对的时候继续写。它不会停下来拍你一下说：“等会儿，这个项目现在其实还没准备好。”
所以 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 真的理解需求？是不是让用户选方案？是不是有人负责语义验收？是不是明确告诉你它不做什么？
这些听起来没有“十分钟生成一个系统”刺激。
但真正要把 Vibecoding 用进项目的人，最后会关心这件事：我能不能把这个结果交给下一个工具、下一个 Agent、下一个开发者继续做。
如果答案是能，那才叫启动成功。
项目入口在这里：
