它能做什么
中文摘要
一套强制纪律的测试驱动开发（TDD）工作流技能：先写一个最小失败测试（RED），必须亲眼看到它以预期原因失败，再写刚好通过测试的最简代码（GREEN），并运行整个项目测试套件确认全绿，最后在保持绿灯的前提下重构（REFACTOR），循环重复。核心铁律是“没有失败测试，就不写生产代码”，先写实现再补测试被视为需删除代码重来；同时列出常见合理化借口、红旗信号、验证清单，以及测试难以编写时的设计排错建议。适用于新功能、Bug 修复、重构与行为变更，一次性原型、生成代码、配置文件等例外需征得人类搭档同意。
为什么推荐
推荐理由
如果你想给编码 Agent 装上一套可执行的 TDD 纪律，而不是一句“请写测试”的口号，这个技能值得安装。它把 RED-GREEN-REFACTOR 拆成带强制验证步骤的流程，明确要求观察测试失败、只在绿灯后重构、并运行项目级测试命令而非单个测试文件，还专门列出“稍后再补测试”“我已经手工测过”“删掉几小时代码太浪费”等借口及反驳，能显著减少 Agent 事后补测试、测试 mock 而非真实行为、只跑自己那个测试文件就宣称完成等常见偏差。
什么时候用
适用场景
- Agent 实现新功能时，需要先写失败测试再写实现
- 修复 Bug 时，要求先写复现测试、再按 TDD 循环修复并防止回归
- 重构或改变行为前，需要已有测试与全绿基线保障
- 需要审查 Agent 是否真的遵循 TDD（是否观察过测试失败、是否跑了整个项目测试套件）
- 遇到测试难写、需要大量 mock、测试设置庞大时，用技能中的排错表反推设计问题
使用前先看
主要亮点
- 01
铁律：NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST，先写代码就必须删除重来，不能留作“参考”或边写测试边“改造”
- 02
红-绿-重构循环配有流程图，且 Verify RED 与 Verify GREEN 均标注为 MANDATORY、不可跳过
- 03
Verify RED 要求确认测试是以预期原因失败（功能缺失而非拼写错误），测试一写就通过说明测的是既有行为
- 04
Verify GREEN 强调必须运行项目自身的测试命令（如 pytest、npm test、cargo test），单个测试文件通过不等于测试套件通过，未报告的红灯属于遗漏性失实报告
- 05
GREEN 阶段只写刚好通过测试的最简代码，明确禁止添加功能、重构其他代码或过度设计（YAGNI 反例）
- 06
REFACTOR 仅在绿灯后进行：消除重复、改进命名、抽取辅助函数，且不得新增行为
- 07
列出常见合理化借口与反驳对照表，如“太简单不用测”“我会事后补测试”“删掉已花数小时的代码太浪费”等
- 08
提供 Red Flags 清单，出现“先代码后测试”“测试立即通过”“这次情况不同”等信号即应删代码、以 TDD 重新开始
- 09
给出好测试标准：一个行为、名称清晰、测试真实代码，除非万不得已不用 mock；并指向 writing-good-tests.md 规则
- 10
包含 Bug 修复的完整示例（空邮箱被接受的 RED→Verify RED→GREEN→Verify GREEN→REFACTOR）与完工验证清单
- 11
调试集成要求修复 Bug 必须先用失败测试复现，绝不在没有测试的情况下修 Bug
- 12
“卡住”排错表：不知道怎么测就先写期望的 API/断言、测试太复杂说明设计太复杂、必须 mock 一切说明耦合过高应依赖注入
原始文档
原文摘录
Test-Driven Development (TDD) Overview Write the test first. Watch it fail. Write minimal code to pass.