从这个月起，打算定期总结一下团队使用 Vibe Coding 的实践，正如同当初敏捷实践中定期回顾一般。这其中的背景其实并不复杂：一来是 vibe coding 渐成主流，二来是思想的转变。
至少在半年前，我当时还只是认为 Vibe Coding 更适合于搭建 mvp 来快速验证想法，在 idea 验证之后，再切换到传统开发模式。但随着时间的推移，想法渐渐转变，同时在团队中大力推广。从当初只是个人尝试，变成强制要求团队使用。导致心路历程变化的几个原因：
- ai 发展迅猛，远超我的预期，尤其在 coding 方面，Gemini 2.5 pro 和 Claude 4 可以生成媲美人类的代码。
- 至少看到两个大厂的 CEO 公开要求团队使用 AI 工具。
- 业内裁员趋势越来越猛，微软和 Google 内部使用 AI 生成代码的比例并不低。
- 更重要的是看到若干著名开源软件者在用它去做实际的项目，如 flask creator 和 Ghosty 作者和 HashiCorp 的cofounder。
面对如此多的迹象，AI 换人乃是大势所趋，现在不学会与之相处，更待何时；若依旧抱残守缺，岂非不智？！
但是，Vibe Coding 虽然降低了编程的门槛，生成代码的速度飞快，但并不意味着就能轻易得到你想要的东西。我估计有几方面原因：
- 工具本身不给力，比如：人家都是花的 200 刀的 CC，公认的编码能力第一。
- 既有知识成为了障碍，这就好比小孩反而比老人更快掌握新手机类似。
- Vibe Coding 姿势不对。
鉴于此，我开始要求团队内部定期自我总结一下实践经验，促进相互交流和反思。
值得保留
不要将 AI 视为 SDK 或工具，将它视为“人”
一旦遵循此原则，那么以下实践就顺理成章了：
- 一次性将事情交代清楚，给出必要的背景介绍，方便它理解你的意图。
- 重大调整前，让它先给计划。在讨论计划时，可以来回在不同的 AI 之间切换，比如：Claude 生成设计，Gemini 去 review，定稿之后再让 Claude 完成代码。
- 在它陷入困境时，如转牛角尖，你可以：告诉它换一种思路；或者进一步澄清问题，重新讨论。
- 在它需要帮助时，及时提供帮助，如下例。不要事前当甩手掌柜，事后又怪小弟办事不力。
- 提供错误截图
- 提供错误日志输出
- 亲自帮他定位问题
- 对于前后有衔接的任务，在新任务开启之时，让它先总结进展，同交接班一样。
- 不同 ai 擅长不一样，根据任务类型不同，找不同的 ai 完成：
- Claude 适合生成设计和代码
- Gemini 虽然代码能力不错，但比起 Claude 还是差一些。但它的长上下文有助于总结和 review。
- ChatGPT 文采斐然，文案和设计交给它也 ok。
- v0 擅长前端，且设计能力出众，让它快速生成前端页面。
- 若非项目有强制的技术栈要求，让 ai 用自己趁手的工具，没有必要强求。你要的是结果，客户要的也是结果。
- 在接手新代码之前，让它先自我总结，你来补充必要的上下文。
- 在 review 它的工作时，用具体的场景来进行验证，尤其是那些 edge case。你也可以让它自行给你解释。
软件工程实践仍需遵循
- 软件开发实践和过程依旧必不可少，比如：你完全可以让它先基于 mindmap 写出需求分析，再让它设计，之后让它形成计划，最后让它去实现。
- 即便你为了偷懒，但关于需求的 mindmap 还是需要的，除非需求特别简单。至于 mindmap，可以直接截图让它去看。
- 为了限制它的输出，你完全可以设计出来接口和架构，让它去执行和实现。
- 在它完成初稿之后，要求它自我 review，进行代码整理和重构。
提供清晰的指令
- 各大 AI Coding 工具基本上支持相关的 instruction 或 rule 文件。
- 若所用工具有 llms.txt 文件，将其放在项目中，在 instruction 中要求它使用，这样团队内部会有一个一致的 ai coding 规范。
- 若无，同时它又是一个主要工具，建议将整个 repo 打包放进项目中，作为 llms.txt 的替代。
需要知道借力打力
- 若你的项目跟另一个项目高度相似，但只是技术栈不同，不妨让 ai 去参考它，然后重写。
比如，最近看到一个 mcp server 模板，其支持 oauth 认证。但我期望换成团队中使用的 better-auth。于是采用这样的方式，顺利完成。
- 持续收集相关对于 ai coding agent 友好的工具或指令集。
需要改进
- 避免一句话需求。
- 扩大知识面，因为你要为 ai 指明方向了。
- 放手让 ai 去做，除非你试了几种方式它都搞不定，遵循经典的：trust but verify 原则。
推荐实践
注：仅列出我们发布的文摘，视频见文内。