spec 派和测试派这几个月一直在吵。
spec 派说，先把规格写清楚，再让 AI 开工；测试派则不断晒出"全绿"的尴尬：覆盖率跑到 90%，改一个参数名却没有一条测试变红。这场争论连 B站都刷到了，已经有人专门做视频讨论"TDD测试驱动适合VibeCoding吗"。哔哩哔哩但把知乎 8 月集中放出的几篇实操复盘读完，我发现一个有点反直觉的事实：越往深处走，越没人站队，最完整的那个项目两套都装了。
两套指标，看清一个项目的真实状态
最有代表性的是 8 月初一篇企业级 RAG Agent 项目的复盘。作者不说"项目完成 100%“，而是同时写下"112 个任务全交付 + 227 个用例全 GREEN”。知乎112 是 SDD 规划出的功能任务数，227 是 TDD 测试用例数，其中后端 179 条、前端 48 条。
作者有句话值得钉在墙上：SDD 解决"做什么"和"做到哪"，TDD 解决"做得对不对"，112 代表广度，227 代表深度。知乎只看 112，说明饼画得大，不证明能吃；只看 227，质量有了，却没人知道饼画到了哪。
更有意思的是一个细节。项目最初的 spec 里写了条性能验收线：财务查询要在 30 秒内返回。结果跑起来才发现，DashScope API 高峰期要 35~40 秒，如果没有一条 TDD 用例对着这个阈值亮红，没人会发现 spec 已经过时了。知乎最后的处理不是硬改代码去凑 30 秒，而是确认后把 spec 阈值调到 45 秒。这就是两道锁配合的样子：测试暴露问题，spec 吸收修正。
为什么光写 spec 不够
有人可能会问：spec 都写到字段级了，AI 照单执行，还能出什么事？8 月中旬一篇知乎文章把答案说得很直白：真实的 AI 编程流程是"人写 spec → AI 生成代码 → 人 review → 修改 spec → AI 重新生成"。知乎
但写清楚了，不等于写对了。spec 的作用是压缩 AI 的猜谜空间：写得模糊，AI 猜错的概率就高；写得清楚，犯错概率降低，但不会归零——AI 本质上是在概率空间里搜索最可能的答案，而不是在逻辑空间里推导必然的结果。知乎
那"做得对不对"这道最终验收交给谁？交给 AI"事后补测试"恰恰是最危险的一种。一位大厂质量方向的工程师说得很难听：上线第二天，一个明显的空指针，测试一个都没拦住，AI 写的测试，绿得没有含金量。知乎先有实现再补的测试，是照着实现反写的：实现错了，测试跟着一起错，绿得皆大欢喜，只有用户受伤。
这正是为什么一位做了十几年测试的老兵，最近花 18 个小时带着 AI 把 Kent Beck 的测试驱动开发教材重新走了一遍核心章节。他的结论是：AI 生成代码很快，但它不知道产出的东西是不是你真正想要的，需求越模糊，输出越快，跑偏后的返工成本越高。测试不再只是用来验证对错，而是用来定义"什么才是正确"。知乎
为什么光写测试也不够
那跳过 spec、只死磕 TDD 行不行？也不行。
8 月有一篇被广泛转发的文章，把 Agent 写测试的默认习惯拆得很透：你让它实现功能顺便带上测试，它会选一条最省力的路——横向切开，给所有 service 批量产出单元测试，每一层都 mock 掉下一层。每条测试只证明了一件事：我正确地调用了下一层的 mock。改一个参数名，没有一条测试变红，因为这些测试从没让两层真正握过手。
作者给了两条可以立刻带走的判据。第一条：删掉所有 mock，测试还能跑吗？mock 只该出现在系统边界：第三方 API、系统时间、随机数、外部消息队列，删掉就跑不动，说明 mock 已经长进了你自己的模型。知乎
第二条：你的那次"红"，真的发生过吗？Agent 最爱的捷径是测试和实现一口气写完、一次提交，测试从未真正失败过。一个从没红过的测试，无法证明它能捕获错误。知乎少了那次真实的红，TDD 就退化成给已有实现补一张合格证。
而这一切的前提是输入——vertical-tdd 不凭空开始，它的输入是 grill-before-coding 落盘的 spec.md。知乎你看，连最硬核的 TDD 实践，也是拿 spec 当起点的。
双锁装起来什么样
把这几个 8 月实践的最大公约数抽出来，一共三步。
第一步，spec 层：写下"做什么、做到哪"。个人项目把验收标准写进 README 就够，团队项目可以用 Spec Kit、OpenSpec 这类工具做 specify → plan → tasks 拆解。关键动作只有一个：写代码之前，人和 AI 先达成共识、落盘成文件，别留在聊天记录里。
第二步，测试层：每个任务先写一条会失败的测试。纪律是先红后绿——先跑一遍，看着它因为"功能未实现"而红，再写最小实现让它绿。测试名描述用户能做什么，不描述函数返回什么；mock 只留在系统边界。
第三步，两层回写：任务清单一条条勾掉，每绿一批测试就回写进 spec。每天收工看两个数：勾掉多少任务、绿了多少用例，两个数一起涨，才睡得着。
开头那个项目的前端阶段也值得单独一提：不是所有测试都得是单元测试。他们的 UI 用例采用"手动验证 + 浏览器测试"，每条用例开发完成后在浏览器里逐条验证，通过才标绿。知乎再配上 TypeScript 严格编译和生产构建当自动门禁。测试形态可以灵活，"先红一次"不能省。
还有一句话，建议刻在显示器上：不要只让 Agent 写测试，要让测试约束 Agent。AI 写测试和测试约束 AI，是两件完全不同的事，前者只是让 AI 多产出几个测试文件，后者是让测试成为 Agent 必须通过的关卡。知乎
谁值得装，谁别装
两道锁不是免费的，给一张决策表。
一次性脚本、验证想法的原型：别装。前面那位十几年测试老兵也承认，TDD 绝非银弹，原型探索、一次性脚本这类场景，完全没必要硬上。知乎这种场景硬上纯属自虐，跑通看效果就行。
个人副业项目：装半套。验收标准写进 README，核心路径先红几条测试再写实现。再加一个一分钟土办法：故意把被测代码改错一行，把加号改成减号、把大于改成大于等于，重跑一遍，测试挂了说明它真在测，全绿说明它是摆设。知乎这比盯着覆盖率数字靠谱多了。
团队项目、要长期维护的代码：值得装全套。spec 是多人多 AI 协作的唯一共识底座，测试是唯一能拦住"修了这个、错了那个"的网。一条浏览量近 70 万的知乎回答把这笔账算透了：只算写代码的时间，Agent 确实省了很多，但从需求到交付的总成本看，编码时间下降了，审查和回归排查却成了新的瓶颈。知乎两道锁花掉的钱，本质是买回瓶颈环节的时间。
最后留两个值得盯的信号：OpenSpec、Spec Kit 这类工具的迭代速度，以及主流 Agent 框架什么时候把"spec → 测试 → 实现"三段流程做成内置。等这套流程被工具标准化，双锁就从进阶玩法变成默认配置——先学的人，等于白学。
这大概也是整个 8 月的讨论绕了一圈后的共识：TDD 以前被嫌弃太慢，但 AI 时代，"慢"反而成了优势——慢在前面把方向搞对，后面 AI 才能快得有价值。知乎AI 负责快，人负责定义对。
