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