القائمة
TDD 驱动的 Bug 修复流程。当用户描述 Bug、报错、异常、要求修复问题时必须使用此 Skill。 触发关键词包括但不限于：fix、bug、报错、异常、失败、不生效、NullPointerException、NPE、 ClassCastException、空指针、抛异常、500 错误、返回值不对、数据不一致、逻辑错误、 修复、排查、定位问题。即使用户只是说"这个接口有问题"或"这里不对"，也应触发此 Skill。 此 Skill 强制 AI 遵循 Red-Green-Verify 三阶段流程，禁止跳过任何阶段。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | tdd-fix |
| description | TDD 驱动的 Bug 修复流程。当用户描述 Bug、报错、异常、要求修复问题时必须使用此 Skill。 触发关键词包括但不限于：fix、bug、报错、异常、失败、不生效、NullPointerException、NPE、 ClassCastException、空指针、抛异常、500 错误、返回值不对、数据不一致、逻辑错误、 修复、排查、定位问题。即使用户只是说"这个接口有问题"或"这里不对"，也应触发此 Skill。 此 Skill 强制 AI 遵循 Red-Green-Verify 三阶段流程，禁止跳过任何阶段。 |
用户报告了 Bug、异常、错误行为，需要 AI 协助定位并修复。此 Skill 确保修复过程遵循 TDD 纪律：先用失败测试证明 Bug 存在，再做最小修复，最后回归验证。
核心原则：没有亲眼看到测试失败，就无法证明测试真正覆盖了 Bug。
违反规则的字面含义就是违反规则的精神。
在开始三阶段流程之前，AI 必须先了解项目上下文。
按以下优先级依次查找项目根目录的上下文文件，找到第一个即停止：
| 优先级 | 文件路径 | 说明 |
|---|---|---|
| 1 | PROJECT-CONTEXT.md | 公司推荐标准，通用格式 |
| 2 | CLAUDE.md | Claude Code 生态 |
| 3 | .cursorrules | Cursor 生态 |
| 4 | .github/copilot-instructions.md | GitHub Copilot 生态 |
从上下文文件中获取：
如果以上文件均不存在，扫描项目根目录的 pom.xml 或 build.gradle，推断：
确认项目使用 mvn test、gradle test 还是其他命令运行测试，以便后续阶段执行。
用一个在当前代码下必定失败的测试用例，精确复现 Bug。
分析根因：
[类名]#[方法名] 在 [条件] 下会 [错误行为]编写复现测试：
should_[期望行为]_when_[触发条件]templates/unit-test-template.java 中的骨架执行测试，确认红灯：
如果 Bug 涉及外部系统调用、文件系统、网络请求等不可控因素，无法直接编写复现测试：
当项目构建环境不可用（如私有仓库不可达、parent POM 缺失、依赖下载失败等），导致无法通过 mvn test 或 gradle test 实际运行测试时，允许降级为代码走查验证，但必须满足以下三个硬性要求：
测试执行状态 —— "测试未实际运行，需在 CI/CD 环境或 IDE 中补充验证后方可合并代码"用最小的代码改动修复 Bug，使阶段一的测试通过。
实施修复：
运行复现测试，确认绿灯：
输出改动清单：
确保修复没有引入新问题，并输出完整的修复报告。
执行回归检查清单：
templates/regression-checklist.md 逐项列出每一条检查项的检查结果运行相关模块测试：
完成前自检：
| # | 自检项 | 对应阶段 |
|---|---|---|
| 1 | 每个修复点是否都有对应的测试 | Red |
| 2 | 是否亲眼看到了测试失败（红灯） | Red |
| 3 | 是否只写了最小化代码让测试通过 | Green |
| 4 | 所有测试是否全部通过 | Green |
| 5 | 测试是否使用了真实代码而非过度 Mock | Red |
| 6 | 边界情况和异常路径是否覆盖 | Red |
无法全部打勾？说明跳过了 TDD 步骤，必须回退重做。
输出修复报告：
templates/fix-report-template.md 的章节结构输出，不得省略任何章节，不得自行更改格式| 规则 | 说明 |
|---|---|
| 禁止跳过 Red 阶段 | 没有失败测试就不能开始修复 |
| 禁止跳过 Green 确认 | 修复后必须运行测试确认通过 |
| 禁止跳过回归验证 | 必须检查是否引入新问题 |
| 禁止顺手重构 | 只修 Bug，不做任何无关改动 |
| 测试命名规范 | should_xxx_when_xxx 格式 |
| 改动需说明理由 | 多文件改动时逐个说明 |
以下是 AI 试图跳过 TDD 流程时最常见的借口。出现这些想法时必须立即停止并纠正。
| 借口 | 现实 |
|---|---|
| "这个改动太简单了不需要测试" | 简单的改动测试也只需要 30 秒，没有理由跳过。简单代码也会出 Bug。 |
| "先改完再补测试" | 测试后补无法证明测试能捕获 Bug——测试直接通过说明不了任何问题。必须先看到红灯。 |
| "手动测试过了没问题" | 手动测试无法复现、无法回归、无记录。"我试了没问题" ≠ 全面覆盖。 |
| "写测试太复杂了" | 如果测试难写，说明代码设计有问题。用 Mock 方案隔离依赖，或重新审视接口设计。 |
| "时间紧来不及写测试" | TDD 比修复线上 Bug 快得多。跳过测试是用未来的时间偿还现在的懒惰。 |
| "已有代码没有测试，加不上去" | 你正在改进它。为你修改的部分补上测试。 |
| "先写完留着做参考，再按 TDD 来" | 你会不自觉地"适配"已有代码，那就不是 TDD 了。删掉，从测试开始。 |
| "TDD 太教条了，我更务实" | TDD 本身就是务实的——提前发现 Bug、防止回归、记录行为、支持重构。跳过测试才是在制造技术债。 |
红线信号——出现以下任何一种情况，必须停下来从 Red 阶段重新开始：
参考 examples/example-bug-fix.md 查看一个从 Red 到 Green 到 Verify 的完整修复流程示例。
对应的测试代码见 examples/example-test-output.java。