我是觉得与其天天研究各种 Vibe Coding 的奇技淫巧不如先把规格驱动开发Spec Driven Development掌握好。工具一直在变但规格驱动开发不会。它足以解决你日常绝大多数编程问题。为什么我一直推崇规格驱动开发因为它天然就符合程序员的工作方式。在真正开始写代码之前先分析需求、设计方案、思考边界条件这本来就是一个成熟程序员应该做的事情。以前这些思考可能停留在脑子里或者写在设计文档里。现在只不过把这个过程变成了和 AI 一起完善一份 Spec。不断讨论不断补充不断修改。直到这份 Spec 足够完善。这个过程本质上是在做设计。我跟AI一起写的 Spec 一般都比较长。给大家看一下我最近处理一个线上 Bug 时写的一份 Spec。总共七百多行两千多字。下面只是截取其中一部分。很多人可能会觉得为什么要写这么长因为 AI 并不了解你的业务。它不知道哪些数据绝对不能丢不知道哪些历史逻辑必须兼容也不知道哪些地方可以改哪些地方最好不要动。这些都需要你告诉它。所以这份 Spec 并不是一次写出来的。而是我和 AI 来来回回讨论了几十轮慢慢沉淀出来的。期间我不断补充它不知道的信息例如数据不能丢这是一个 B 端系统数据已经落库然后才开始执行后续流程某些历史逻辑必须兼容……同时我也会明确告诉它一些约束例如不能破坏原来的代码尽量减少改动范围不能引入新的问题必须验证 Bug 已经真正解决……当然整体的设计方案大部分还是由我来决定。我会告诉 AI我准备采用什么方案然后让它分析有没有遗漏的场景有没有更好的实现方式有没有潜在风险有没有边界条件没有考虑到。很多时候它提出的问题确实能帮我发现一些之前没有想到的细节。且还有一个很有意思的事情经过几十轮讨论以后沉淀出来的 Spec本身就是一份格式良好的 AI 指令。部分人使用 AI是一直聊天。需求想到一点就补充一点。发现一个问题又继续追问。几十轮下来聊天记录越来越长也越来越混乱。而我的做法是不断把聊天过程中达成的共识沉淀回 Spec。正确的内容保留下来。遗漏的场景补进去。错误的地方修改掉。最后得到的不是一长串聊天记录而是一份越来越完善的 Spec。对于 AI 来说它并不关心这份内容是谁写的。它更关心的是这份输入是否完整、结构是否清晰、约束是否明确。而一份经过反复打磨的 Spec恰恰就是这样一种输入。它记录的不只是需求还包含了业务背景、设计思路、约束条件、边界场景以及验收标准。所以在我的工作流里聊天只是形成 Spec 的过程Spec 才是真正驱动 AI 工作的指令。那花这么长时间写 Spec是不是有点浪费时间 并不是的。Spec 写得越完善AI 一次把代码写对的概率就越高。前段时间我写过一篇《一次线程池线上故障复盘四层防线如何避免数据丢失》。那个线上 Bug从分析问题、设计方案到最后生成代码我都是围绕这份 Spec 来完成的。最终当 Spec 完善以后我让 AI 一次性生成了完整代码。而我做的事情就是审核代码以及部署到测试环境验证主流程。确认没有问题之后就直接上线了。整个过程中我没有再反复修改 AI 生成的代码。在AI时代真正值得花时间的不是在写代码而是把Spec打磨正确。这一点也是我使用 AI 比较深的一个体会。很多人把时间花在反复修改 AI 生成的代码上。而我更愿意把时间花在完善 Spec 上。因为当 Spec 足够完整的时候后面的编码阶段反而会变得非常顺畅。最后我想说最终决定 AI 输出质量的取决于你提供给它的信息质量。通过不断地跟AI沟通慢慢打磨出一份高质量的specAI基于这份spec就可以产生符合你预期的代码。有效率有质量。我认为这才是 Vibe Coding 最大的奇技淫巧。