Vibe Coding 这个词是 Karpathy 在 2025 年初提出的，最初带点自嘲——「完全跟着感觉走，对着 AI 说话，代码就出来了」。一年多过去，它已经从玩具变成很多团队的真实生产力，但产出质量天差地别。差距不在模型，在流程。这篇文章分享我沉淀了一年多的工作流，五个步骤，全是可以直接抄的。

第一步：先让 AI 写计划，人审计划

最贵的错误是让 AI 一口气生成三百行代码然后发现方向就错了。改一行 prompt 的成本，远低于改一千行代码。所以任何超过「改个文案」规模的任务，我都会先下这样的指令：

请为 OrderService.CancelOrderAsync 设计重构方案，要求：
1. 只列出改动计划，不要写任何代码；
2. 说明每一步如何验证；
3. 指出可能影响现有调用方的风险点。

计划里我会重点看三样东西：改动范围是否失控、有没有编造不存在的 API、风险点识别得全不全。计划通过后再放行写代码。

第二步：规则文件前置

AI 是个「什么都不懂的新同事」，你得给它新人手册。我的每个仓库根目录都有 AGENTS.md，写清楚构建命令、代码规范和禁区，细节可以看我之前那篇《从零维护一份 AGENTS.md》。没有这份文件，每次会话都在重新教一遍 AI，这是最常见的隐性浪费。

第三步：小步提交

AI 完成一个可验证的单元，就 commit 一次，commit message 说清「这一步做了什么、怎么验证的」。好处有三：

  • AI 改崩了可以精确回滚到上一个好状态，而不是整段推翻重来；
  • 每一步 diff 都很小，人工 review 不痛苦；
  • 出问题时 git bisect 能直接定位是哪一步引入的。

第四步：测试护航

我的铁律是：测试不过，不进入下一个任务。理想顺序是让 AI 先写测试（基于需求而不是基于实现），确认测试合理后再让它写实现，让绿灯真正代表行为正确。关于怎么判断 AI 写的测试靠不靠谱，可以看我那篇五条验收标准的文章。

第五步：把人工审查花在刀刃上

逐行检查 AI 的样板代码性价比很低，它写得比你好的地方就是这些。人工审查应该聚焦在 AI 最容易自信地写错的地方：

  • 并发与竞态（AI 对锁和取消的理解经常过于乐观）；
  • 事务边界与数据一致性；
  • 安全相关：鉴权、注入、敏感信息处理；
  • 数据迁移与不可逆操作。

什么时候我不 vibe

核心算法、安全关键路径、性能敏感的热点代码，我仍然自己写——AI 在这些场景的角色是 reviewer 而不是 author。Vibe Coding 的正确翻译不是「无脑交给 AI」，而是「把机械劳动交出去，把判断留下来」。

工具在一年里换了好几轮，但这五步流程一直没变：计划先行、规则前置、小步提交、测试护航、审查聚焦。模型越强，流程的杠杆越大。