我是觉得，与其天天研究各种 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沟通，慢慢打磨出一份高质量的spec，AI基于这份spec，就可以产生符合你预期的代码。有效率有质量。
我认为，这才是 Vibe Coding 最大的奇技淫巧。