Spec Coding 实践：别再让 AI 凭感觉写代码
最近 AI 编程工具越来越强，很多人开始习惯一种很直接的开发方式：
帮我做一个登录功能。帮我加一个订单模块。帮我写一个后台管理页面。这种方式确实很爽。你只要描述一个大概想法，AI 很快就能生成一堆代码。页面有了，接口有了，甚至测试也可能顺手补上。
这种“凭感觉驱动 AI 写代码”的方式，通常被叫作 Vibe Coding。它适合做原型、Demo、小工具，也适合快速验证一个想法。
但如果把它直接搬进真实项目，很快就会遇到问题：
- AI 写得很快，但你不一定知道它为什么这么写。
- AI 改得很多，但你不一定知道它有没有改坏别的地方。
- AI 看起来完成了需求，但细节可能和你的真实预期差得很远。
于是，就需要另一种更适合工程化开发的方式：Spec Coding。
什么是 Spec Coding？
Spec Coding 可以简单理解为：
先写清楚规格，再让 AI 写代码。
这里的 Spec 不只是需求描述，而是一份相对完整的开发规格。它应该说明目标、边界、业务规则、技术方案、任务拆分和验收标准。
也就是说，我们不再对 AI 说：
帮我实现用户管理。而是说：
这是用户管理模块的目标、权限规则、接口约定、异常场景、数据结构和验收标准。请先基于这些内容设计方案，再分步骤实现。两种方式的区别很大。
Vibe Coding 更像是：
我有个想法，你看着办。
Spec Coding 更像是：
我们先把问题定义清楚，再按计划交付。
前者适合探索，后者适合落地。
为什么不能只靠 Vibe Coding？
AI 很强，但它有一个天然问题：它特别擅长“补全空白”。
当你的描述不完整时，它会自动猜很多东西：
- 猜接口怎么设计；
- 猜数据库字段怎么建；
- 猜权限应该怎么控制；
- 猜异常情况怎么处理；
- 猜哪些逻辑“应该”存在。
在小项目里，这种猜测可能没什么问题。但在真实业务中，猜测往往就是风险。
举个例子，你让 AI 实现一个“删除用户”的功能。如果没有额外说明，它可能直接从数据库里物理删除用户记录。
但真实系统里，你可能需要的是：
- 软删除用户；
- 保留操作审计日志；
- 禁止删除超级管理员；
- 删除前检查是否有关联订单；
- 同步清理缓存；
- 通知其他系统更新状态。
这些规则如果没有写进规格里，AI 大概率不会完整考虑。
所以，Spec Coding 的核心价值不是让 AI 写得更多，而是让 AI 少猜一点。
一套实用的 Spec Coding 流程
我理解的 Spec Coding，大致可以分成四步。
1. 先写背景和目标
不要一开始就让 AI 写代码。
先告诉它为什么要做这个功能，解决什么问题，面向什么用户，最终希望达到什么效果。
比如：
我们要做一个账单导入功能，目标是让用户可以上传 Excel 文件批量导入消费记录，减少手动录入成本。第一版只支持标准模板，不支持用户自定义列映射。这段话里其实已经包含了目标和边界。
有目标，AI 才知道重点在哪里。
有边界，AI 才不会顺手把范围扩大。
2. 写清楚业务规则
业务规则是 Spec 里最重要的部分。
它决定了 AI 写出来的代码到底是不是你想要的代码。
还是以账单导入为例，规格可以这样写：
文件格式：- 必须是 xlsx 文件；- 第一行是表头；- 必须包含日期、金额、分类、备注四列。
校验规则：- 日期必须能解析为合法日期；- 金额必须是数字，且不能为 0；- 分类不存在时，默认标记为“未分类”；- 备注可以为空。
导入规则：- 单行失败不影响其他行；- 重复账单不重复导入；- 重复判断依据为日期、金额、备注完全一致。
返回结果：- 返回成功数量；- 返回失败数量；- 返回失败行号和失败原因。这就比“帮我做一个 Excel 导入”清楚太多了。
3. 让 AI 先出方案，而不是直接写代码
很多人用 AI 写代码时，喜欢一步到位：
直接帮我实现。更稳妥的方式是先让 AI 输出方案。
可以这样问：
请基于以上规格，先不要写代码。请先分析当前项目结构，并给出实现方案：1. 需要新增或修改哪些文件；2. 每个文件负责什么；3. 数据流如何流转；4. 需要覆盖哪些测试；5. 可能有哪些风险。这样做的好处是，你可以在代码生成前先发现问题。
如果方案都不对，代码大概率也不会对。先审方案，比事后审一大堆代码轻松得多。
4. 拆任务，逐步实现
复杂功能不要一次性交给 AI。
更好的方式是让 AI 把任务拆小：
请把实现过程拆成 5 个以内的任务。每个任务都要能独立验证。每完成一个任务后，先停止，等待我确认。这样可以控制节奏。
先改数据模型，再写服务逻辑。
先补单元测试，再接接口。
先跑测试，再继续下一步。
AI 很适合执行明确任务，但不适合在没有边界的情况下自由发挥太久。
一份好 Spec 应该包含什么？
不需要一开始就写得特别正式，但至少应该包含这些内容：
- 背景：为什么要做；
- 目标：这次要解决什么问题；
- 非目标：这次明确不做什么；
- 用户流程：用户怎么使用；
- 业务规则：正常情况和异常情况怎么处理；
- 数据结构：涉及哪些字段；
- 接口约定：请求和响应是什么；
- 权限规则：谁可以操作；
- 验收标准：什么情况算完成；
- 测试要求：至少覆盖哪些场景。
其中，“非目标”很容易被忽略，但它非常重要。
比如你写一句：
第一版不支持用户自定义 Excel 列映射。AI 就不会顺手给你设计一个复杂的模板配置系统。
这就是边界的力量。
Spec Coding 不是降低效率
有些人会觉得，写 Spec 太麻烦了。既然 AI 可以直接生成代码，为什么还要先写一堆规格？
我的看法是：Spec Coding 不是降低效率，而是在减少返工。
不写规格时，你省掉的是前面十分钟。
但你很可能会在后面花半小时解释、修正、回滚和重构。
写规格时，你是在提前消除歧义。
对 AI 来说，规格越清楚，输出越稳定。
对开发者来说，规格越清楚，审查越轻松。
对团队来说，规格越清楚，沟通成本越低。
尤其是在真实项目里，代码只是结果，真正重要的是共识。
使用 Spec Coding 的几个小建议
第一，让 AI 先复述需求。
在写代码前，可以先让 AI 总结它理解的需求。你会很快发现它有没有理解偏。
第二，让 AI 先写计划。
不要直接生成代码。先让它说明准备怎么改、为什么这么改、会影响哪里。
第三，控制单次修改范围。
一次只做一个小任务。任务越小，越容易检查，也越容易回滚。
第四，必须看 diff。
AI 生成代码后，不要只看它的总结。关键逻辑、权限判断、数据变更、异常处理都要自己过一遍。
第五，把验收标准变成测试。
Spec 里写的验收标准，最好能变成自动化测试。这样 AI 后续继续改代码时，你才有稳定的反馈机制。
一个完整的实战 Prompt
日常可以用下面这段作为模板：
你现在是这个项目的 AI 编程助手。
任务：实现用户收货地址的默认地址切换功能。
请按下面流程执行：1. 先阅读用户地址相关代码，只输出方案。2. 方案里说明需要修改哪些文件、有哪些风险。3. 等我确认后再写代码。4. 每次只完成一个小步骤。5. 修改后列出 diff 摘要和验证命令。
限制：- 不修改用户表结构；- 不改变已有地址列表接口返回格式；- 默认地址必须保证同一用户只有一个。
验收：- 新增或更新相关测试；- 无权限用户不能修改他人的地址；- 切换默认地址后，同一用户旧默认地址会被取消。这类 Prompt 不花哨，但很适合真实项目。它把目标、限制、流程和验收都写清楚了，AI 就不容易跑偏。
总结
AI 编程的关键，不是让 AI 写更多代码，而是让 AI 写对代码。
Vibe Coding 适合探索想法，Spec Coding 适合交付项目。
前者让你快速看到结果，后者让结果变得可靠、可维护、可测试。
当项目越来越复杂时，开发者的价值不再只是手写每一行代码，而是定义清楚问题、设计好边界、建立反馈机制，并让 AI 在这些约束下高效工作。
换句话说：
不要把 AI 当成一个“随便发挥的代码生成器”，而要把它当成一个需要清晰任务说明的工程协作者。
这才是 AI 编程真正进入工程化阶段的开始。
If this article helped you, please share it with others!
Some information may be outdated