Vibe Coding 实践：用 Claude Code 高效交付

"Vibe Coding"这个词被 Andrej Karpathy 带火后，争议不断。支持者说"我一下午写完一个 app"，反对者说"AI 写的代码一塌糊涂"。两种说法都对，差别只在一点：你把 AI 当人肉打字机，还是当一个需要被管理的初级工程师。

一、心智模型转变：描述意图，而不是写指令

传统编码是"我把每一步怎么做写出来"。Vibe Coding 是"我描述要什么、约束是什么，让 AI 出方案、写实现"。

这听起来像偷懒，但它对工程素养的要求反而更高：

• 你必须非常清楚要什么——需求模糊，AI 的产出就模糊。
• 你必须能看懂和验收 AI 的代码——不看就提交，等于把生产环境交给一个不看的人。
• 你必须会拆任务——把"做个商城"拆成可独立验收的小步，否则 AI 会在一个超大上下文里失控。

换句话说，Vibe Coding 把程序员的劳动从"敲键盘"转移到了"读、判、拆、验"。前者被自动化，后者价值反而放大。

二、Claude Code 的 spec → plan → iterate 工作流

Claude Code（以及类似的 agentic 工具）和 Copilot 式补全最大的不同：它是有状态、能多步操作的 Agent。用好它的关键是一个稳定的工作流：

1. 先写 spec（规格）。 开工前，把需求、约束、边界写成一个简短的 SPEC.md 或直接在对话里讲清。包括：要实现什么、不要实现什么、关键约束（性能、兼容性）、验收标准。spec 越清楚，AI 越少自由发挥。

2. 让它先 plan。 别上来就让它写代码。先问"你打算怎么实现，分几步"。一个像样的 plan 能让你在它动手前发现问题，比写完再推翻便宜得多。Claude Code 的 plan mode 就是干这个的。

3. 小步 iterate。 按 plan 逐步推进，每步看 diff、跑测试、确认后再下一步。永远不要"一次性让它写完整个项目"——上下文一长，质量必降。

4. 用工具让它自验证。 让它自己跑 tsc / lint / test，把错误回灌给自己修。Agent 能读错误信息自我纠错，比你转述错误快得多。

三、上下文是 Vibe Coding 的命门

Agent 的质量 ≈ 你喂给它的上下文质量。几个原则：

• 给对的，别给多的。 把相关的几个文件、约束、示例贴清楚，胜过"这是整个仓库你看吧"。无关代码是噪声，会稀释注意力。
• CLAUDE.md / AGENTS.md 是项目级的长期记忆。 把项目的约定（用什么框架、目录结构、命名规则、禁忌）写进去，每次会话自动加载。这一份文档的投入回报极高。
• 及时清理上下文。 一个长任务跑久了，早期对话已成噪声。该开新会话就开新会话，把关键结论带过去（或让 Agent 自己总结）。
• 用工具读取，而不是粘贴。 让 Agent 用 grep/read 自己找，比你手动贴几百行强——它找得准，也不污染上下文。

四、什么活适合 vibe，什么不适合

适合：

• 有明确输入输出的** CRUD / 脚手架 / 模板代码**——纯体力活，AI 最擅长。
• 有测试护栏的改动——AI 改、测试兜底，闭环清晰。
• 探索性原型——快速试错，反正要扔。
• 写测试、写文档、写迁移脚本——这些"该做但懒得做"的活，交给 AI 正好。

不适合（或要重度把关）：

• 核心业务逻辑 / 算法——错一行影响全局，必须人脑逐行审。
• 安全敏感（鉴权、加密、支付、SQL 拼接）——AI 偶尔会写出漏洞，不能盲信。
• 性能关键路径——AI 倾向写"能跑"的版本，不一定是"最快"的。
• 不熟悉的领域——你看不懂的代码，就验收不了，等于失控。

判断标准很简单：这段代码出了事，我能不能一眼看出问题？ 能，就 vibe；不能，就慢下来。

五、验收清单

每次 AI 产出的代码，过一遍这个最小清单：

1. diff 必须读完，不是"看上去跑通了"就 merge。
2. 跑测试 + 类型检查，最好让它自己跑、自己修。
3. 边界条件：空值、并发、错误分支——AI 最爱漏。
4. 安全：输入校验、权限、注入。
5. 别让它顺手"重构"没让它动的东西——AI 有过度修改的倾向，严守范围。

小结

Vibe Coding 的真正门槛，不是"会不会用 AI"，而是有没有工程纪律。AI 把"写代码"的门槛降到几乎为零，于是"读懂代码、拆解问题、严格验收"这些原本隐性的能力，成了区分效率高低的分水岭。

把 AI 当初级工程师：给清楚的 spec、要它先 plan、小步迭代、逐 diff 验收。你越像一个好的 tech lead，AI 就越像一支能打的主力。