Spec Coding（规格驱动开发）要求先把”做什么、怎么验收”写成明确规格，再让 AI 动手实现。它解决的核心问题是：AI 写代码很快，但你没写清楚的部分它会自己猜——规格就是把猜测空间换成验收标准。

动机：让 AI 有明确的验收标准

直接对 AI 说一句”帮我做个用户系统”，它会立刻产出一大堆看起来像样的代码。但用户怎么注册、邮箱能不能重复、接口失败返回什么格式、哪些功能这期不做——这些你没说，它就只能按训练数据里的常见模式自行补全。代码能跑，方向却可能偏了；等你发现不对劲，往往已经很难分清是需求没讲清，还是 AI 自由发挥过了头。

Spec Coding 的思路是把规则前置：需求边界、接口契约、验收标准先落在文档里，AI 照单执行，人按单验收。它本质上是把”AI 的行为由你定义，还是由它猜”这个问题，明确回答为前者。规格也是审计与协作的抓手：多人协作时它是单一真相源，需求变更走规格修订，而不是口头漂移。

规格的组成

一份能直接驱动 AI 的规格，至少包含三块内容。

需求描述

不只写方向，还要写边界和非目标。比较下面两种写法：

模糊版：做一个用户系统。

明确版：支持邮箱注册和登录；邮箱必须唯一；单因素密码至少 15 个字符；
本期不做第三方登录；管理员可以禁用用户，被禁用户不能登录但历史数据保留。

前者给 AI 留下一整片猜测空间，后者把能做、不能做、边界在哪一次说清。

接口与技术约定

技术栈版本、分层方式、错误码格式、状态码语义都要定死，否则 AI 会按自己的习惯各写一套：

统一错误返回：{"code": "USER_NOT_FOUND", "message": "...", "trace_id": "..."}
状态码约定：参数错误 400，未登录 401，无权限 403，资源不存在 404，冲突 409。

这类约定看似琐碎，却是返工的高发区：你没写错误码格式，AI 就可能这个接口返回 error、那个接口返回 message。

测试用例与验收标准

这是规格里最值钱的部分。”性能要好””代码要优雅”无法验收，”P95 低于 200ms、重复邮箱返回 409、关键分支有测试断言”才能验收。每条需求都应能对应至少一条可机械检查的验收项，任务拆分时每个 Task 自带验收清单，AI 完成后逐项打勾，打不了勾的必须说明原因。

与 TDD 的关系

Spec Coding 和 TDD 是同构的：都是先定义”完成的标准”，再写实现。区别在于粒度——TDD 用失败测试在代码级定义行为，Spec 用文档在任务级定义行为。两者不是替代关系，而是可以叠加：任务级规格里写明验收标准，实现时让 AI 先按验收标准写出会失败的测试，再写实现让测试转绿。这样 AI 没法”一边改代码、一边补一个永远通过的测试”，验收的客观性就有了双保险。规格回答”这个任务做完意味着什么”，TDD 回答”这段代码正确意味着什么”。

适用边界

不是所有代码都值得先写规格，判断标准可以看代码的寿命。跑完就扔的脚本、验证想法的 Demo，Vibe Coding 直接上，写规格反而是浪费；活三五天的中间地带，写一份只含目标、约束、验收三条的轻量规格，半小时足够；要长期维护、涉及数据持久化、多人协作的代码，才值得走完整规格流程。

规格本身也有分寸。它不是越细越好——定边界，而不是写逐行伪代码，否则 AI 连正常的实现灵活性都被锁死。规格必须进 Git 跟着代码走：代码变了规格不改，AI 下次拿到的就是过期说明，规范和实现会悄悄双轨漂移。最后，规格要接进 CI 或检查清单里被真正执行，写完没人验，跟没写差不多。

小结

  • Spec Coding 的动机：用明确的验收标准替代 AI 的自由猜测，减少返工与漂移。
  • 规格三要素：需求边界与非目标、接口与技术约定、可验证的测试与验收标准。
  • 与 TDD 同构互补，叠加使用能让任务级和代码级验收相互咬合。
  • 按代码寿命决定规格轻重，探索性代码不必硬套流程；规格要进版本库并被持续验证。