我是觉得,与其天天研究各种 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 最大的奇技淫巧。