100万行老代码用AI改，怎么才敢交给工程师 review？

在100万行、写了15年的C#和React老代码库里搞开发，简直是噩梦。但最近看到一个很有意思的实操：有人尝试用Agentic Workflow（智能体工作流）在没有全职开发的情况下，直接在这么大的Legacy SaaS项目上撸出一个MVP原型。

这个流程挺硬核的，基本就是：PRD → 架构文档 → 拆分Epic → 编码Agent实现 → 评审Agent合入。最关键的是，他在用Claude-based Agent写代码后，特意用了另一个模型（Codex）来做二次评审，结果发现第二个模型揪出的Bug多得多。这再次证明了：同一个模型自审，很容易陷入“认知闭环”，觉得代码没问题，其实全是坑。

针对这种“AI写代码 → 人类 review”的场景，我想分享几个能把代码质量往生产级别（Production-grade）拉的实战思路：

• 引入“对立模型”交叉验证： 绝对不要让写代码的Agent兼任评审员。建议用 Claude 3.5 写，用 GPT-4o 或者 DeepSeek 审。不同模型的训练集和逻辑偏好不同，这种“模型打架”能过滤掉绝大多数低级逻辑错误。
• 测试用例的独立解耦： 测试代码必须由另一个独立的Agent根据需求文档生成，而不是由写业务代码的Agent顺手写。否则，Agent会倾向于写那些能通过的测试，而不是能发现问题的测试。
• 强制执行“边界条件”专项扫描： 给评审Agent喂一套专门的《边缘案例清单》，让它强制检查空指针、超时处理、并发冲突等老旧系统最容易崩的地方。
• 构建证据链文档： 不要只给工程师看代码。让AI为每个关键改动生成一份 Decision Log，记录：为什么要这么改 → 尝试了哪几种方案 → 最终为什么选这个。这样工程师 review 时不需要从零推演逻辑，速度快得多。

如果只有两周时间优化，我会把优先级排成：交叉模型评审 > 独立生成测试 > 补齐决策文档。

这种用AI Agent在大规模遗留系统上做原型的尝试确实很有启发，只要能通过多模型冗余校验，其实已经能覆盖大部分初级开发的工作量了。