Appearance
TDD 技能解决的是 AI 修 bug 时“看起来修了，其实没有证据”的问题。它要求先写一个能复现问题的失败测试，再用最小实现让测试通过，随后再整理代码。对纯逻辑、边界条件和回归 bug 尤其有用。
AI 修 bug 为什么要先写测试：TDD 技能怎么用
下载 test-driven-development 中文版 Skill ZIP
你把一个 bug 丢给 AI，它很可能马上开始改代码。
几分钟后，它告诉你修好了。
你再试一次，发现只是这个输入好了，另一个输入又坏了。
这就是没有测试的典型问题：AI 说修好了，但你没有证据。
test-driven-development 这个技能的核心流程很简单：先让问题失败，再让它通过。
RED：先证明 bug 存在
TDD 的第一步不是写实现，而是写一个会失败的测试。
如果是 bug 修复，这个测试应该复现当前问题。
比如一个价格格式化函数把 0 错误显示成空字符串，先写测试：
ts
expect(formatPrice(0)).toBe('¥0')运行后它应该失败。
这一步很重要。因为如果测试没有失败，说明它没有复现 bug，后面的修复也没有意义。
对 AI 来说，这一步能把目标钉死：不是“优化格式化逻辑”，而是“让这个失败用例通过”。
GREEN：用最小改动通过测试
测试失败后，再让 AI 改代码。
这里要提醒它：只做最小实现。
不要让它顺手重写整个模块，不要为了一个边界值新增一套复杂抽象。目标是让刚才那条测试通过，同时不破坏已有测试。
你可以这样要求：
md
先不要重构。
只用最小改动修复这个失败测试。
修完后运行相关测试。AI Agent 很容易把 bug 修复写成“顺便整理”。这一步要把它按住。
REFACTOR：通过以后再整理
测试通过以后，才考虑是否需要整理代码。
如果改动已经很清楚，就不必为了 TDD 的完整流程硬重构。
如果为了通过测试加了一段临时代码、重复判断或命名不清楚，这时再整理，并确保测试仍然通过。
TDD 的价值不是流程表演，而是每一步都有证据。
AI 修 bug 时，TDD 为什么特别重要
人类工程师修 bug 时，会带着项目经验判断风险。
AI 没有你的线上事故记忆，也不知道哪个边界最容易出问题。它会倾向于改出一个“看起来合理”的版本。
测试能把抽象讨论变成可执行证据。
尤其是这些场景，很适合让 AI 先写测试：
- 纯函数逻辑错误。
- 日期、金额、边界值处理。
- 权限判断。
- 数据转换。
- 曾经修过又复发的 bug。
只要测试能稳定复现，AI 修复的可靠性就会高很多。
哪些场景不能只靠 TDD
TDD 不是万能药。
有些问题需要真实环境验证：
- 浏览器交互问题。
- 第三方 API 行为。
- 数据库迁移。
- 构建、部署、权限、网络问题。
- 移动端或不同浏览器差异。
这些场景仍然可以写测试，但不能把测试通过当成全部完成。你还需要本地运行、浏览器检查、日志确认，或者在测试环境走真实流程。
古法编程里说“拒绝黑盒”，不是说所有事都必须单元测试，而是每个结论都要能解释、能验证。
给 AI 的 TDD Prompt
你可以直接这样写：
md
我们用 TDD 修这个 bug。
问题：
[描述 bug]
要求：
1. 先写一个能复现 bug 的失败测试。
2. 运行测试，确认它确实失败。
3. 用最小改动修复实现。
4. 再运行测试，确认失败测试变绿，已有测试不被破坏。
5. 不要顺手重构无关代码。这段话的关键是“先失败”。如果 AI 没有证明测试失败，就直接实现，很容易把 TDD 变成补测试。
你可能还需要
同类技能：
如果你正在修一个可复现 bug，先让 AI 写失败测试。能失败，后面的修复才有抓手。