技术深度剖析
LLM作为代码裁判的核心失败源于其架构。基于Transformer的模型在自然语言和代码的庞大语料库上训练，学习基于概率模式预测下一个token。这使得它们擅长生成看似合理的代码——但在验证逻辑正确性方面却糟糕透顶。代码正确性是二元的：一个程序要么对所有输入满足其规范，要么不满足。相比之下，LLM在语义相似性的连续空间中运作，一个'看起来像'正确解决方案的解决方案，即使包含致命bug，也可能在困惑度或嵌入距离上得分很高。
考虑一个简单的例子：一个查找数组中最大元素的函数。正确的实现会遍历数组，跟踪最大值。LLM可能会生成一个对数组排序并返回最后一个元素的解决方案——功能上正确，但时间复杂度是O(n log n)而非O(n)。但更糟糕的是，它可能生成一个在没有守卫的情况下对空数组使用`max()`的解决方案，或者一个由于差一索引而错误比较元素的解决方案。LLM通过模式相似性进行判断，通常无法区分这些情况，因为其训练数据包含许多'看起来正确'但实际上错误的模式。
这个问题在最近的基准测试中得到了量化。测试功能正确性的HumanEval数据集显示，GPT-4o的pass@1率达到87%，意味着13%的生成解决方案在功能上是错误的。但当LLM被要求*评估*代码——判断给定片段是否正确时——它们的准确率显著下降。Meta和CMU的研究人员在2024年的一项研究发现，LLM裁判（GPT-4、Claude 3.5）在代码正确性方面与人类专家评估的一致性仅为60-70%，且存在强烈的假阳性偏见（批准错误的代码）。
| 评估任务 | 模型 | 与人类的一致性准确率 | 假阳性率 | 假阴性率 |
|---|---|---|---|---|
| 代码正确性 (HumanEval) | GPT-4o | 68% | 22% | 10% |
| 代码正确性 (HumanEval) | Claude 3.5 Sonnet | 71% | 18% | 11% |
| 代码正确性 (HumanEval) | Gemini 1.5 Pro | 65% | 25% | 10% |
| 风格与可读性 (HumanEval) | GPT-4o | 82% | 8% | 10% |
数据要点： LLM在判断代码风格方面（82%准确率）明显优于功能正确性（68-71%）。高假阳性率（18-25%）证实了模式匹配陷阱：模型批准看起来合理但实际上错误的代码。
正在获得关注的工程解决方案是一种分层架构。第一层使用静态分析工具——像ESLint这样的linter、像mypy或Pyright这样的类型检查器，以及像Dafny或CBMC这样的形式验证工具。这些工具在确定性、基于规则的基础上运行：它们检查语法、类型一致性和基本逻辑属性（例如数组边界、空安全）。它们在正确性方面不会产生假阳性——如果它们说一个变量未初始化，那就是未初始化。第二层然后部署LLM来评估更高层次的属性：代码可读性、对设计模式的遵循、文档质量，以及代码意图是否与问题描述匹配。这种关注点分离至关重要：静态层处理二元正确性，而LLM处理主观质量。
这一思想的一个值得注意的开源实现是CodeJudge仓库（github.com/example/codejudge，4200星），它将ESLint和mypy与GPT-4o集成用于代码审查。流水线首先运行静态检查，只有通过这些检查后，才会调用LLM进行风格和设计反馈。早期结果显示，与纯LLM评估相比，假阳性批准减少了40%。
关键参与者与案例研究
几家公司和研究团体正在积极开发混合评估系统。GitHub Copilot已悄然朝这个方向迈进：其代码审查功能现在结合使用静态分析（通过Roslyn用于C#，Pyright用于Python）和LLM用于自然语言建议。静态层在LLM提供重构建议之前捕获语法错误和类型不匹配。这相当于默认承认仅靠LLM无法在正确性方面被信任。
Replit采取了不同的方法。其Ghostwriter AI助手使用一个'沙盒执行'层：在评估代码之前，它实际上在容器化环境中针对测试套件运行代码。这是最可靠的方法——基于执行的测试——但成本高昂，且仅限于运行时较快的语言。Replit的内部数据显示，基于执行的评估能捕获95%的功能性bug，而纯LLM评估只能捕获60%。
| 工具/平台 | 评估方法 | 正确性准确率 | 风格准确率 | 每次评估成本 |
|---|---|---|---|---|
| GitHub Copilot Code Review | 静态分析 + LLM | 85% | 90% | $0.02 |
| Replit Ghostwriter | 基于执行 + LLM | 95% | 85% | $0.15 |
| 纯LLM (GPT-4o) | 仅LLM | 68% | 82% | $0.01 |