mattpocock/skills 怎么用 TDD 写代码？ 关键不是让 AI 先写一堆测试，而是让 Agent 按红绿循环推进：先确认要测试的公共边界，再写一个会失败的测试，只写够通过这个测试的实现，然后再进入下一轮。tdd 技能的价值，就在于把这个节奏固定下来。

适合用它的任务通常有两类：新增一个小功能，或者修一个能复现的 bug。任务太大时，先拆成一个垂直切片；需求还不清楚时，先让 Agent 追问，不要直接进入 TDD。

开始前要准备什么

项目里最好已经有测试框架，比如 Vitest、Jest、Playwright、Pytest 或项目原本使用的测试工具。没有测试框架也能讨论方案，但真正跑 TDD 时，必须让 Agent 能执行测试命令，看见红灯和绿灯。

还要让 Agent 先读项目上下文。tdd 技能要求探索代码库时读取 CONTEXT.md，如果项目里有 ADR，也要尊重相关决策。这样测试名称、接口词汇和业务语言才不会跑偏。

怎么让 Agent 进入 TDD 流程

你可以直接把任务写清楚，让 Agent 使用 TDD 技能处理。提示词不需要复杂，重点是边界和验收。

请用 mattpocock/skills 的 tdd 流程处理这个任务：
目标：给订单折扣计算增加满减规则。
要求：先确认 seam，再写一个失败测试，只做最小实现，通过后停下来让我确认下一步。

这里的 seam 是测试边界，也就是你从哪里观察行为。它可能是一个公开函数、一个 API 路由、一个页面交互，或者一个服务接口。不要让测试直接盯私有方法、内部变量或临时实现细节。

第一轮应该怎么跑

确认测试边界

让 Agent 先回答两个问题：要测哪个公共接口？为什么这个接口能代表用户可见行为？如果它不能说清楚，就先别写测试。TDD 不是测试越多越好，而是把测试放在关键路径上。

写一个失败测试

第一条测试要像规格说明，而不是像实现复述。好的测试名类似“有效购物车满足满减时返回折扣后金额”，差的测试名是“discount 函数返回正确结果”。预期值要来自业务规则或手算例子，不能在断言里用同样算法再算一遍。

只写够通过测试的代码

红灯出现后，再让 Agent 写最小实现。不要顺手扩展未来规则，也不要一次把所有边界条件补齐。tdd 技能强调一个切片一轮：一个 seam、一个测试、一个最小实现。

怎样判断测试写得好不好

• 测试验证的是公共行为，不是私有方法。
• 测试失败时能说明哪个业务能力没实现。
• 重构内部结构时，测试不应该无故变红。
• 断言里的预期值来自独立规则，不是复制实现逻辑。
• 每轮只覆盖一个垂直切片，不一次铺满所有想象中的场景。

最容易踩的坑是“看起来很勤奋”的批量测试。一次写十几条测试，再让 Agent 一口气实现，常常会把想象中的结构锁死。更稳的做法是让上一轮结果影响下一轮判断。

什么时候该停下来 review

tdd 技能把重构放到 review 阶段，而不是混在红绿循环里。也就是说，当前测试通过后，不要马上让 Agent 大改架构。先看 diff：测试是否贴近行为，生产代码是否只做了必要实现，是否有重复和命名问题。

如果确实需要整理结构，再把任务交给 code review 或架构相关流程。这样做会慢一点，但能减少 AI 在“顺手优化”里扩大改动范围。

常见问题怎么处理

Agent 一上来就写实现怎么办

让它停下，要求先列出 seam，并写出第一条失败测试。没有红灯，就不进入实现。

测试一直绿，说明什么

可能测试没有打到真实行为，也可能断言太弱。让 Agent 故意注释掉关键实现，再跑测试。如果测试仍然通过，说明这条测试没有保护价值。

没有现成测试框架还能用吗

可以先让 Agent 调研项目技术栈，提出最小测试工具方案。但这已经是“搭测试环境”任务，不要和业务功能实现混在同一轮。

TDD 成功检查清单

• Agent 已确认测试边界，并得到你认可。
• 第一条测试先失败，再进入实现。
• 实现只覆盖当前测试，不提前做大范围扩展。
• 测试能通过项目真实测试命令执行。
• 绿灯后先 review diff，再决定是否进入下一轮。

用 mattpocock/skills 做 TDD，真正要盯住的是节奏。只要 Agent 还在“一个测试、一个实现、一次验收”里走，AI 写代码就更像工程流程，而不是一次性生成答案。