用途：在修复缺陷时，先让错误行为变成可执行的测试，再修改生产代码，目标是得到一个修复前失败、修复后通过的聚焦回归测试。当测试不切实际时不强行加测试，改用最接近的有效验证方式。
主要流程：
- 理解 bug，明确预期行为、当前行为、受影响路径和最小可观察复现。
- 选择最窄的可执行检查，优先使用该代码路径已有的单元、组件、集成或回归测试；若没有明显可行测试路径，不要仅为走流程而从零创建。
- 先写失败测试，添加能捕获该 bug 的最小聚焦测试，测试应编码预期行为而非镜像当前实现。
- 修复前运行新测试，确认它因预期原因失败；若通过或因无关原因失败，先修正测试或复现。
- 修复 bug，做满足预期行为的最小生产改动，同时保持周边契约。
- 重新运行回归测试，确认通过。
失败测试不可行时：使用最接近的可执行回归检查，如定向脚本、手动复现命令、浏览器自动化、快照对比、日志断言或聚焦集成检查。宁可不加新测试，也不要坏测试。坏测试包括：主要测试 mock、编码当前实现细节、依赖时序或无关全局状态、为小修复需要昂贵基础设施，或证明修复后立刻被删除。
限制与护栏：不要为迎合错误实现而改测试；除非预期行为确实改变且原因清楚，否则不要削弱现有断言；回归测试要聚焦 bug，避免无关 fixture 变动或扩大覆盖；若 bug 不稳定，尽量让测试确定性并记录锁定的信号；若暴露更广的失败类别，先落地聚焦回归路径再考虑同类覆盖。
最终回复应报告证据而非仅结果：说明修复前失败的测试或可执行检查及其失败信息；说明修复后通过的测试运行及附近验证；若无法展示修复前失败证据，说明原因并描述所用的最接近回归检查。