智能测试修复

什么时候会用到

重构、改 API 或动依赖之后，make test 或 CI 里往往一下子冒出大量失败。手工逐个改容易漏掉共性根因，修完一组又触发另一组回归。这个技能面向的是明确要求修测试、报告套件挂了、实现完要绿 CI 这几类场景，而不是泛泛「写点测试」。

它怎么组织修复

流程从全量跑测开始：用 make test 看清失败总数、错误类型和涉及的模块。接着做智能分组——按 ImportError、AttributeError、AssertionError 等错误类型、同一文件/模块的连锁失败，以及缺失依赖、签名变更、重构影响等根因归类；分组按「受影响用例数」和「依赖顺序」排序，先动影响面最大的。

对每个分组依次：定位根因（读代码、git diff 看近期变更）、最小改动修复（遵循项目约定如 CLAUDE.md）、用 pytest 标记或文件模式跑子集确认通过后再进下一组。顺序上先基础设施（导入、依赖、配置），再 API/重构类问题，最后断言与业务逻辑。

边界与习惯

一次只修一个分组；当前组未绿不跳组。改动保持聚焦，避免「顺手大改」。全部分组完成后仍要跑完整套件，确认无回归、覆盖率未被无意破坏。