用途：在修复有清晰、低成本测试路径的缺陷时，先把出错行为变成可执行测试，形成聚焦的回归测试——修复前失败、修复后通过。若测试不切实际（需要大量测试脚手架、脆弱 mock、慢速端到端设施、仅生产状态、复现步骤模糊或大规模无关夹具变动），则跳过新增测试，改用最接近的有效验证方式。
主要能力与工作流：1) 理解缺陷，明确预期行为、当前行为、受影响路径与最小可观察复现；2) 选择最窄可执行检查，优先沿用该代码路径已有的单元、组件、集成或回归测试；3) 先写最小聚焦失败测试，测试应编码预期行为而非镜像当前实现；4) 修复前运行新测试，确认因预期原因失败；5) 做最小生产代码修改，满足预期行为并保持周边契约；6) 重跑回归测试确认通过；7) 运行相邻验证（相关测试、类型检查、lint 或场景检查）。
无法编写失败测试时：不要静默跳过回归步骤，应在修复前明确说明为何失败测试不可行或不值得，再选用最接近的可执行回归检查，例如定向脚本、手动复现命令、浏览器自动化、快照比较、日志断言或聚焦集成检查。
护栏：不得仅为匹配错误实现而修改测试；不得削弱现有断言，除非预期行为确实改变且原因清晰；回归测试应聚焦该缺陷，避免无关夹具变动或扩大覆盖；实用信号弱时不要新增测试，改用人工或脚本验证并说明理由；若缺陷不稳定，尽量使测试确定化并记录锁定的信号；若缺陷暴露更广的失败类别，先落地聚焦回归路径，再考虑同类覆盖。
最终响应应报告证据而非仅结果：说明修复前失败的测试或可执行检查及其失败信息、修复后通过的测试运行及周边验证；若无法展示修复前失败证据，说明原因并描述所用的最接近回归检查。