用 AI 改造百万行老代码库时如何通过多模型交叉评审确保质量
很多团队在尝试用 AI Agent 开发 MVP 原型时，习惯于建立一个简单的闭环：PRD → 架构文档 → 编码 → 提交。但实际操作中你会发现，如果让同一个模型（比如 Claude 3.5）既负责编写又负责自审，极易陷入“认知闭环”。AI 会倾向于认为自己的逻辑是自洽的，导致大量潜在的 Bug 在 Review 阶段才被人类工程师揪出来，这不仅浪费了专家的时间，更让 AI 失去了效率优势。
要将 AI 生成的代码推向“生产级别（Production-grade）”，核心在于打破单一模型的逻辑垄断，构建一套冗余校验机制。
首先，必须引入“对立模型”的交叉验证。在实操中，最有效的策略是让不同训练集、不同逻辑偏好的模型“打架”。例如，由 Claude 3.5 Sonnet 负责根据架构文档编写业务逻辑，但评审环节绝对不能交给它，而应交给 GPT-4o 或 DeepSeek。在实际测试中，这种交叉评审能过滤掉绝大多数低级逻辑错误，因为不同模型对 C# 异步处理或 React 状态管理的理解偏差，恰恰是发现 Bug 的最佳切入点。
其次，要实现测试用例的独立解耦。很多开发者习惯让 Agent 在写完功能后顺手写个 Unit Test，这其实是最大的陷阱。因为 Agent 会倾向于编写“能够通过”的测试，而非“能够发现问题”的测试。正确的做法是：由一个独立的 Agent 仅根据原始需求文档生成测试用例，在业务代码实现之前，测试套件就已经定义好。只有当业务代码通过了由第三方 Agent 预设的、与实现逻辑无关的测试集时，代码才具备进入 Review 阶段的资格。
针对老旧系统最容易崩塌的环节，建议为评审 Agent 配置一套强制性的《边缘案例清单》。在 100 万行级别的遗留系统中，最致命的往往不是主流程错误，而是空指针、超时处理以及并发冲突。通过在 Prompt 中强制要求 Agent 扫描这些特定维度，可以将原本随机的 Review 变成一次结构化的专项审计。
最后，为了降低人类工程师的认知负担，必须要求 AI 构建“证据链文档”。不要直接扔给工程师一个巨大的 Diff 文件，而应要求 AI 为每个关键改动生成一份 Decision Log。这份文档需要明确记录：该改动解决了什么问题 → 尝试过哪几种替代方案 → 最终选择当前方案的权衡理由。当工程师在 Review 时，他们不需要从零开始推演 AI 的逻辑，而是直接审核决策过程是否合理，这能将 Review 效率提升数倍。
如果时间紧迫，建议将优化优先级排布为：交叉模型评审 > 独立生成测试 > 补齐决策文档。通过这种多模型冗余校验的 Agentic Workflow，我们实际上是在用计算资源的冗余，来对冲 AI 随机性带来的风险，从而在面对大规模遗留系统时，真正实现从“能跑通”到“敢上线”的跨越。
