用途：在修复 bug 且存在清晰、低成本测试路径时，让缺陷行为先可执行验证，再改动生产代码。目标是得到一个聚焦的回归测试：修复前失败，修复后通过。资料强调，若强制写测试不切实际，不要硬写。
主要能力：先理解缺陷，明确预期行为、当前行为、受影响路径和最小可观察复现；选择最窄的可执行检查，优先复用该代码路径已有的单元、组件、集成或回归测试；先写最小的失败测试，测试应表达预期行为而非照搬当前实现；修复前运行新测试，确认它因预期原因失败，若通过或失败原因无关则先修正测试或复现；随后做最小生产改动，满足预期行为并保持周边契约；再运行回归测试确认通过。
适用场景：用户明确要求 TDD、失败测试或回归测试时；或 bug 具有明显低成本本地测试目标时。
限制与替代：当测试需要大量测试框架搭建、脆弱 mock、慢速端到端设施、仅生产环境状态、模糊复现步骤或大量无关 fixture 变动时，跳过新增测试，改用最接近的可执行回归检查，例如针对性脚本、手动复现命令、浏览器自动化、快照对比、日志断言或聚焦集成检查。资料主张宁可不加测试，也不要坏测试。护栏包括：不为了让测试匹配错误实现而改测试；不无理由削弱既有断言；回归测试保持聚焦，避免无关 fixture 变动和覆盖扩张；不稳定的 bug 尽量使测试确定化并记录所锁定的信号；若 bug 暴露更广故障类别，先落地聚焦回归路径，再考虑兄弟覆盖。最终报告应给出证据而非仅结果：说明修复前失败的测试或可执行检查及其失败表现、修复后通过的测试运行及邻近验证；若无法展示修复前失败证据，说明原因及所用最接近的回归检查。