大模型基于概率，有好有坏也能理解

背景

在代码评审（Code Review）场景中，大型语言模型（LLM）正越来越多地被用作辅助工具。开发者尝试将同一段代码提交（commit）交给不同的大模型进行审视，以评估其在发现逻辑错误、编码规范问题、文档不同步等方面的能力。本文涉及的对比实验来自 LINUX DO 社区的讨论，测试对象为 GPT-5.5（来自 Codex Plus 套餐，使用 Codex 工具）和 GLM-5.2（来自智谱 Pro 套餐，使用 ZCode 工具），被评审的代码由 Claude 3.5 Opus（4.8 版本）生成。

核心内容

社区用户对一次具体的代码提交（commit）执行了两次独立的 AI 代码评审，均使用相同的 skill（评审规则集）。被评审的代码由 Claude 3.5 Opus 编写，其中包含一个影响编译的错误。

• GPT-5.5 （xhigh）：仅发现了 2 个问题。

• GLM-5.2 （max）：发现了 5 个问题，其中 完全覆盖了 GPT-5.5 发现的 2 个问题，另外额外识别出 3 个问题：

  1. 新增的某个方法实际没有被任何地方调用（dead code / unused method）。
  2. Java record 类型的某个字段使用了 ConcurrentHashMap —— 可能违反 record 不可变性设计或序列化规范。
  3. Javadoc 描述与实际代码逻辑存在差异（文档与实际实现不一致）。

此外，被评审代码本身存在一个 “影响编译的错误”：某个单元测试类未能同步使用新的方法签名，即测试代码调用了旧版本的方法名或参数，导致编译失败或运行不通过。GPT-5.5 和 GLM-5.2 均提到了这个问题（包含在各自发现的 2 个和 5 个问题中）。

关键要点

• 问题数量差异显著：在相同 skill 和相同 commit 下，GLM-5.2 发现的问题数量是 GPT-5.5 的 2.5 倍，且完全涵盖了 GPT-5.5 的全部发现。
• GLM-5.2 的额外发现类型：
  • 未使用的方法（unused method）—— 属于代码冗余问题。
  • 不恰当的数据结构选择 —— ConcurrentHashMap 用于 Java record 字段，可能违背 record 的不可变语义或序列化设计。
  • 文档与实际代码不一致 —— Javadoc 描述与实际逻辑有偏差。
• 编译错误已被覆盖：影响编译的单元测试签名未同步问题，两个模型都成功识别。
• 评审能力不完全重叠：GPT-5.5 遗漏了三个有明显实际影响的问题（未使用的方法、数据结构选择不当、文档差异），且这些问题并非难以检测。
• 被评审代码的生成模型背景：代码由 Claude 3.5 Opus 生成，仍存在可被大模型检出的缺陷，说明即使是高质量 AI 生成代码也需人工或模型二次审查。

意义与影响

1. 大模型代码评审能力存在显著差异：不同模型在相同评审规则下的表现差异极大，用户在选择 AI 评审工具时需结合实际测试，不应默认任意模型能力等价。
2. 模型覆盖度比单纯查错更重要：GLM-5.2 不仅能发现编译错误，还能识别冗余方法、数据结构设计以及文档不一致等“软问题”，这类问题往往比单一编译错误更影响代码长期维护性。
3. 促进开发者重新评估模型选择：若团队依赖单一模型做代码评审，可能遗漏重要问题。在关键场景下，采用多模型交叉评审或人工复审更可靠。
4. 推动模型能力对比的社区讨论：这类真实代码评审对比实验为开发者提供了可复现的参照，有助于形成对“哪个大模型更适合代码审查”的实证认知。
5. 对代码生成模型本身的启示：Opus 生成的代码并非完美，提示开发者在接受 AI 生成代码后仍应进行充分审查，而非直接信任。