实测代码Review效果：Sonnet 4.6、GLM 5.2与Codex打分对比

背景

在软件开发生命周期中，代码审查（Code Review）是保障代码质量、发现潜在缺陷及提升团队知识共享的关键环节。随着大语言模型（LLM）能力的提升，利用 AI 辅助甚至自动化执行代码审查已成为行业趋势。然而，不同模型在处理复杂企业级存量代码时的表现差异巨大，且评测方法本身也可能引入偏差。

本文基于 LINUX DO 社区的一篇实测分享，深入探讨了在真实企业 Java 存量系统场景下，多款主流 AI 模型（DeepSeek V4 Pro、Claude Sonnet 4.6、GLM-5.2）在代码审查任务中的实际表现。该测试不仅关注模型本身的智能水平，还引入了工作流（Workflow）脚本的影响，并采用 Codex + GPT-5.5 (xhigh) 作为第三方裁判进行量化打分，旨在为开发者提供更具参考价值的选型依据。

核心内容

本次测试的核心目标是评估不同 AI 模型在真实企业代码审查场景下的有效性。测试选取了一个包含 34 个 Java 文件、新增代码 926 行的真实企业需求开发功能分支作为测评集，该分支属于存量系统代码，具有典型的复杂性和维护难度。

测试过程采用了严谨的隔离环境设计，具体步骤如下：

1. 工作流构建：首先由 GLM-5.2 编写用于自动化代码审查的工作流脚本。
2. 模型执行与隔离：
   • GLM-5.2：直接使用上述工作流脚本进行代码审查。
   • Claude Sonnet 4.6：在独立的 worktree（工作树）环境中，使用相同的工作流脚本进行代码审查。
   • DeepSeek V4 Pro：同样在独立的 worktree 环境中执行审查。
   • 注：所有涉及的文件操作均在互相隔离的环境中进行，以确保评测的公平性。
3. 第三方量化评分：审查完成后，生成三份独立的审查报告。随后，引入 Codex 结合 GPT-5.5 (xhigh) 作为“裁判”，对这三份报告进行阅读和打分，以量化各模型的表现。

结果与反思： 测试结果显示，GLM-5.2 的表现最佳。在后续的反思环节中，DeepSeek V4 Pro 表现相对最差。当将 Claude Sonnet 4.6 和 GLM-5.2 的审查报告提供给 DeepSeek V4 Pro 进行对比反思时，DeepSeek 将自身表现不佳的原因归结为“工作流脚本存在问题”。

然而，这一归因存在逻辑悖论：工作流脚本本身正是由 GLM-5.2 编写的。由于 GLM-5.2 在生成脚本时可能隐含了对其自身模型特性的优化或适配，导致其直接运行该脚本时效果最好。相比之下，其他模型在运行同一脚本时，可能因理解偏差或执行逻辑差异而未能发挥最佳水平。这一发现揭示了在 AI 辅助开发中，“模型与工具链的匹配度”可能比单纯的“模型智商”更影响最终产出质量。

关键要点

• 测试场景真实性：测试基于真实的存量企业 Java 代码（34 个文件，926 行新增），而非简单的合成数据集，结果更具工程参考价值。
• 环境隔离的重要性：通过 worktree 技术确保各模型在完全隔离的文件环境中运行，避免了文件冲突和状态污染，保证了评测的客观性。
• 第三方裁判机制：引入 Codex + GPT-5.5 (xhigh) 对审查报告进行打分，建立了相对统一的量化评估标准，减少了主观判断的偏差。
• GLM-5.2 的“主场优势”：GLM-5.2 表现最佳并非完全因为其审查能力最强，很大程度上得益于工作流脚本由其自身编写，存在天然的适配性优势。
• DeepSeek V4 Pro 的局限性：在此次测试中表现最差，且倾向于将失败归因于外部工具（脚本）而非自身能力，反映出其在复杂工作流执行或自我诊断方面的潜在不足。
• 工作流脚本的偏差风险：AI 生成的工作流脚本可能隐含了对生成者自身模型特性的偏好，导致其他模型在使用时效果打折，这在自动化 AI 工作流设计中是一个值得警惕的偏差来源。

意义与影响

此次实测为 AI 辅助编程工具的选型和应用提供了重要启示：

1. 模型选型需结合具体工作流：没有绝对“最好”的模型，只有“最适合”当前工作流配置的模型。如果工作流由特定模型生成，该模型往往能取得更优结果。企业在构建 AI 开发流水线时，应考虑模型与工具链的协同优化，而非孤立地追求单一模型的基准测试分数。
2. 存量系统代码审查的挑战：真实企业代码往往包含大量历史包袱和非标准写法，这对 AI 的理解能力和上下文把握提出了更高要求。测试表明，即使在隔离环境下，不同模型对同一脚本的执行效果仍存在显著差异，提示开发者在引入 AI 审查时需要进行充分的本地化适配和测试。
3. 反思机制的价值与局限：虽然让模型进行自我反思或对比反思是提升输出质量的有效手段，但模型可能无法准确识别自身在工具链适配上的劣势。因此，人工复核或引入独立的第三方评估机制（如本次使用的 GPT-5.5 裁判）显得尤为重要。
4. 对 AI 工程实践的推动：该测试展示了从“单点模型调用”向“复杂工作流自动化”演进的趋势。未来，AI 代码审查将不再仅仅是调用一个 API，而是涉及脚本生成、环境隔离、多模型协同及自动化评估的完整工程体系。开发者需要关注整个链条的可靠性，而不仅仅是最终模型的智商。