Appearance
Matt Pocock 的 tdd 技能重点不是“测试先行”四个字，而是一次只推进一个 vertical slice。先写一条描述外部行为的失败测试，再写最小实现让它通过。不要让 AI 一口气写完所有测试，因为那往往是在测试想象中的代码形状。
AI 做 TDD 为什么要一条测试一条实现：Matt Pocock TDD 技能怎么用
很多人让 AI 做 TDD，会得到一堆测试文件。
看起来很专业。
问题是，这些测试可能测的是 AI 想象出来的结构，不是最后真的需要的行为。
Matt Pocock 的 tdd 技能强调的是 vertical slice：一条测试，一条实现，一次反馈。
不要横向写测试
错误做法是：
text
先写 test1、test2、test3、test4
再实现 feature1、feature2、feature3、feature4这会让 AI 在还没理解实现约束时，提前把测试结构定死。
后面你会发现测试耦合了内部函数、临时数据结构、mock 形状。代码一重构，测试就碎，但真实行为没有变。
一条行为一个循环
更稳的节奏是：
text
RED：写一条外部行为测试
GREEN：写最小实现让它通过
再进入下一条行为每一轮都回答一个具体问题：系统现在多了什么能力？
比如 API Key 管理功能，可以这样走：
- 测试“用户能看到当前 API Key 状态”。
- 写最小实现。
- 测试“用户能保存新的 API Key”。
- 写最小实现。
- 测试“保存失败时显示错误”。
- 写最小实现。
这比一次性生成完整测试套件慢一点，但更不容易跑偏。
测行为，不测实现细节
这个技能特别强调：测试应该通过公共接口验证行为。
不要让 AI 写这种测试：
- 调用私有函数。
- 检查内部变量。
- mock 掉所有真实路径。
- 断言某个实现步骤被调用。
更好的测试描述是用户能看懂的能力：保存成功、权限被拒绝、列表为空、错误可见。
如果测试读起来像实现说明，后面重构会很痛苦。
给 AI 的 TDD Prompt
md
请按 Matt Pocock TDD 风格实现这个功能。
一次只写一条失败测试，再写最小实现让它通过。
测试必须验证外部可观察行为，不要测试私有实现细节。
每完成一个 red-green 循环，先停下来说明下一条行为是什么。
不要一次性写完整测试套件。这里最关键的是“每完成一个循环先停下来”。
AI 很容易越写越快，你要把节奏拉回一条行为一次反馈。
和站内 TDD 文章的区别
站内已有 AI 修 bug 为什么要先写测试。那篇更偏通用测试验证：为什么要先有失败测试、如何防回归。
这篇更偏 Matt Pocock 的具体纪律：不要横向切片，不要一次性写完所有测试，用 vertical slice 一步一步推进。
你可能还需要
同类技能：
如果 AI 一次生成了很多测试，先让它停下来。问它第一条用户可见行为是什么，只保留那一条开始。