让 AI 自己 debug：缺陷调查的三次架构重写
2025-03-22
好的架构不是设计出来的，是被问题逼出来的。
起点：一个看似简单的需求
代码变更分析会标记三类发现：
- [BUG]：置信度 >= 90%，可以直接提交
- [SUSPECT]：置信度 50-90%，需要进一步调查
- [RISK]：设计层面的风险，生成测试建议即可
[SUSPECT] 是最棘手的——"可能有问题，但证据不够"。让 AI 自己完成调查过程。
V1.0：天真的大循环
一个简单的大循环，把所有发现一起调查。
崩溃症状：
- AI 开始重复分析之前已经看过的代码
- 上下文窗口在第 3 个发现时被填满
- 系统进入无限循环
V1.0 存活了 6 天就被废弃了。
V1.1：Per-Finding 隔离
核心改进：
- 上下文隔离：每个发现在独立上下文窗口中调查
- 增量交付：每个发现完成后立即写回主文档
- 三重收敛检测：确认/排除/饱和
- 状态持久化：每个发现的状态持久化到磁盘
| 指标 | V1.0 | V1.1 |
|---|---|---|
| 10 个发现完成率 | ~30%（崩溃） | 100% |
| 单发现平均耗时 | N/A | 3-5 分钟 |
| 误判率 | 高 | < 10% |
V1.2：自动化 + 调查策略矩阵
V1.1 需要手动触发每个发现的调查。V1.2 实现了全自动：
人类: /deep_investigation auto_mode=true AI: F1 → 完成 → F2 → 完成 → ... → 生成总结报告
调查策略矩阵：
| 假设类型 | 应该看什么 | 去哪里找 |
|---|---|---|
| 条件逻辑可疑 | 调用方代码 | GitHub 搜索所有 caller |
| 空值处理缺失 | 数据库 schema + 上下文 | 表定义 + Service 层 |
| 配置依赖 | 配置文件 + 环境差异 | 各环境 config |
| 前后端契约不一致 | API 定义 + 实际响应 | API 文档 + 代码 |
| 共享写入方法字段覆盖 | 所有调用方 + SQL 语句 | Mapper XML + Service |
三次重写的规律
V1.0 → V1.1：解决"能不能跑通"的问题 V1.1 → V1.2（auto）：解决"好不好用"的问题 V1.2 → V1.2（策略矩阵）：解决"能不能变聪明"的问题
你只能在实战中发现问题，然后演化架构来适应。
给同样在做 AI 调查系统的人
- 永远按子任务隔离上下文——共享上下文只会互相污染
- 给 AI 一个"我不确定"的合法出口——REMAINS_SUSPECT 状态
- 把领域经验编码为策略表——效率高且一致
- 增量交付而非批量交付——崩溃是常态
- 状态持久化到磁盘——LLM 上下文是易失的
这是"当 AI 接管测试流水线"系列的第三篇。下一篇将讲述整个系统从 1 个 Command 长到 15 个 Command 的迭代故事。