如何给LLM代码评审打分：从缺陷检出率到幻觉控制

你有没有遇到过这样一类“AI 代码评审”：模型对着一段埋了雷的代码，输出一整页正面评价，最后结论是“LGTM，可以直接合并”，而代码里刚好有一个在产品并发环境下必然触发的缺陷。标题 The Review That Praised the Bug: grading three LLM code reviews against the code 说的就是这种现象——评审不仅没有发现 Bug，反而把带 Bug 的实现当成良好设计表扬了一遍。

本文不是想讨论“哪个大模型更强”，而是想把“如何给 LLM 代码评审结果打分”这件事讲透。我们会准备一份带有种子缺陷的 Java 代码，用三份风格完全不同的 LLM 评审结果做横向对比，然后按同一套评分规则给它们打分。读完你会得到：一套可复用的评审质量评估维度、一个最小可运行的打分脚本，以及把 LLM 代码评审真正接入工程链路时需要注意的坑。

1. 背景与问题定义

1.1 什么是 LLM 代码评审

代码评审（Code Review）是软件开发流程中用来保证代码质量的关键环节。传统做法是由一名或多名有经验的工程师，在代码合并（Merge / PR）之前对变更进行检查，主要关注功能正确性、代码风格、并发安全、资源释放、边界条件、潜在安全漏洞等。

LLM 代码评审则是把“读代码、找问题、写意见”这件事交给大语言模型来完成。常见做法是：

1. 把本次代码变更（git diff 或完整文件）作为文本输入；
2. 在提示词中描述项目背景和本次变更意图；
3. 让模型输出评审意见，包括问题位置、原因、建议修改方式；
4. 工程师根据模型意见进行二次确认后处理。

相比传统人工评审，LLM 评审的优势是响应快、覆盖面广、能同时从多个角度提意见；缺点是会一本正经地生成错误结论，也就是通常说的“幻觉（Hallucination）”。在实际项目中，如果工程师对模型输出缺乏判断力，这类错误结论会造成两种后果：一是把真正的问题漏掉，二是把不存在的“问题”当成真问题去改。

1.2 “表扬 Bug”的评审到底差在哪里

标题中的 “praised the Bug”，准确说是“评审对带有 Bug 的代码给出了正面评价”。这种评审最大的危害不是“没说话”，而是“说了错误的安全结论”。

举个例子，如果一段代码使用了线程不安全的SimpleDateFormat，正确的评审意见应该指出“并发调用时可能产生错乱，必须替换成DateTimeFormatter或ThreadLocal”。而一份“表扬 Bug”的评审会怎么说？它可能会说：“这里复用了SimpleDateFormat，避免了重复创建格式化对象的性能开销，是一种不错的优化。”

这段话单看前半句并没有错，复用对象确实能减少创建开销。问题在于SimpleDateFormat内部保存了可变状态，不是线程安全的，在多线程共用一个实例时，可能出现日期错乱甚至抛出异常。评审只看到了“复用”的收益，却没有评估“共享可变对象”的风险，最终得出一个让代码带着隐患上线的结论。

LLM 评审的另一个典型问题是“结论过于正面”。很多模型在缺少明确约束时，倾向于输出礼貌、肯定、建议性的内容，而不是直接说“这段代码不能合并”。当模型输出大量表扬性文字时，工程师很容易放松警惕，以为代码没有问题。

1.3 为什么需要给“评审结果”打分

我们平时会给代码质量打分，给测试覆盖率打分，却很少给代码评审本身打分。在引入 LLM 代码评审之后，“评审质量”这件事变得非常重要，因为模型输出不稳定，不同提示词、不同模型、不同运行次数下结果差异都很大。

给 LLM 评审打分，本质上是在回答几个问题：

1. 它发现了多少真实缺陷？—— 缺陷检出率（Recall）；
2. 它发现的“缺陷”里有多少是真的？—— 精确率（Precision）；
3. 它给出的修改建议能不能直接执行？—— 可执行性；
4. 它给合入结论时是否负责任？—— 风险决策质量。

只有用同一套标准去评估多次评审结果，团队才能判断当前引入的模型和提示词方案是否可靠。

2. 实验设计：三个评审 vs 一份代码

“给 LLM 代码评审打分”这个命题，需要一个可控的评估环境。否则你无法判断一条评审意见是否准确，也无法量化模型的表现。

2.1 三层评估结构

整个评估可以拆成三层：

第一层：被测代码 包含已知种子缺陷（Ground Truth） ↓ 第二层：LLM 评审输出 三份或多份评审结果 ↓ 第三层：评审打分 用固定评分维度给每份评审结果打分

很多团队只做到了前两层：把代码丢给模型，模型给出了意见，然后凭感觉判断“这个模型行不行”。如果希望结论可复现、可对比，第三层才是关键。没有地面真值（Ground Truth）和固定评分标准，“模型表现不错”就只是一句无法验证的主观感受。

三层结构中有一个容易被忽略的点：被测代码的种子缺陷清单必须在评审之前冻结。评审前先确定“哪些问题算 Bug”，评审后严格按照这份清单判断命中情况，避免根据模型输出临时调整标准。

2.2 打分维度与权重设计

本文使用的评分表包含 5 个维度，按重要程度加权，满分 100 分。

缺陷检出权重最高，因为代码评审的第一使命就是找出能导致线上事故的问题。评审准确率同样重要，它可以避免工程师被一堆不存在的“问题”带偏。

2.3 保证评审过程可复现

对 LLM 评审做评估时，需要固定几个参数：

1. 固定模型版本和接口参数，建议将温度设为 0；
2. 固定系统提示词和用户提示词，避免每次提问方式不一致；
3. 同一问题至少运行 3 次，观察结果稳定性；
4. 评审时只给模型代码本身和必要的业务契约，不要事先告诉它“这里埋了 Bug”。

如果模型运行多次结果差异很大，说明评估得分只能代表某一次输出，不能代表模型稳定水平。这也是为什么很多规范做法会把同一份代码跑三遍，然后观察检出率的浮动区间。

3. 被测代码与种子缺陷

为了让读者能亲手复现，下面准备一份完整的 Java 示例代码。业务背景是用户积分服务，代码里包含两个高风险并发缺陷。

3.1 示例业务背景

假设有一个会员积分系统，RewardService被多个 HTTP 请求线程并发调用，需要满足两个业务规则：

1. 多个线程可以同时对同一个用户累加积分，累加不能丢失；
2. 积分明细需要把奖励时间格式化成字符串进行展示，多线程并发调用格式化方法时，结果必须正确。

代码文件如下。

// 文件路径：src/main/java/com/example/reward/RewardService.java package com.example.reward; import java.text.SimpleDateFormat; import java.util.Date; import java.util.HashMap; import java.util.Map; /** * 用户积分服务。 * 注意：该类会被多个 HTTP 请求线程同时使用。 */ public class RewardService { private static final SimpleDateFormat DATE_FORMAT = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); private final Map<String, Integer> pointsMap = new HashMap<>(); /** * 给指定用户增加积分。 */ public void addPoints(String userId, int points) throws InterruptedException { if (points < 0) { throw new IllegalArgumentException("points must be >= 0"); } Integer oldPoints = pointsMap.get(userId); int newPoints = (oldPoints == null ? 0 : oldPoints) + points; // 模拟累计过程中的耗时，方便观察并发问题 Thread.sleep(10); pointsMap.put(userId, newPoints); } /** * 查询用户当前积分。 */ public int getPoints(String userId) { return pointsMap.getOrDefault(userId, 0); } /** * 把奖励时间格式化为字符串并返回。 */ public String formatDate(Date date) { return DATE_FORMAT.format(date); } }

这段代码表面上结构清晰，方法命名也没有问题。但结合“多线程并发使用”这个前提，代码里有两个明确的种子缺陷。

3.2 种子缺陷清单

在评审开始之前，先冻结缺陷基线。

需要注意，Thread.sleep(10)本身不是必现 Bug，但它会放大 BUG-02 的竞争窗口。真实项目中，数据库更新、远程调用、复杂计算都会天然制造竞争窗口，所以并发累加问题并不只存在于这段模拟代码里。

3.3 为什么选择这两个缺陷

选择SimpleDateFormat和HashMap累加作为种子缺陷，有两个原因：

1. 它们在 Java 并发场景中非常典型，有明确的权威结论，适合做自动评估；
2. 它们都是“静态代码检查工具不一定能查全、算法题训练数据里又大量出现”的问题，适合测试 LLM 在上下文明确时能否准确命中。

SimpleDateFormat线程不安全是 Java 官方文档明确说明的。SimpleDateFormat内部维护了Calendar等可变状态，多线程共用时会出现不可预期的结果。DateTimeFormatter被设计为不可变且线程安全，是替代方案。

4. 三份评审输出的横向对比

下面用三份不同类型的评审输出演示打分过程。这三份输出是构造的示例，内容只是为了展示典型表现，不代表任何具体模型的真实结论。实际评估时，请使用你希望测试的模型生成结果，再按同样方法打分。

4.1 评审 A：通篇表扬，没有发现缺陷

评审 A 的输出内容如下。

整体看下来，这段代码写得很干净，结构清晰，方法命名直观。 addPoints 中用 map.get 判断旧值再累加，逻辑简单可靠； formatDate 使用统一的 SimpleDateFormat，避免了每次创建格式化对象的开销； getPoints 提供了默认值处理，调用方不需要额外判空。 唯一的小建议是：方法注释可以再补全一些。 结论：LGTM，可以直接合并。

评审 A 就是典型的“表扬 Bug”。它的结论“可以直接合并”和真实风险完全相反。我们逐句看：

1. “addPoints逻辑简单可靠”——没有考虑并发覆盖问题；
2. “使用统一的SimpleDateFormat避免了创建开销”——把线程不安全的共享对象当成合理优化；
3. “getPoints提供了默认值处理”——这句没错，但掩盖了真正需要关注的高风险问题。

这项评审最大的问题不是没提建议，而是给出了一个误导性的放行信号。工程师如果信任这份评审，代码就会带着并发缺陷进入发布流程。

4.2 评审 B：发现一半缺陷，但存在幻觉意见

评审 B 的输出内容如下。

代码整体可用，但发现一个问题： 1. RewardService 使用了线程不安全的 SimpleDateFormat。 在并发环境中可能产生日期错乱，建议每次调用时 new SimpleDateFormat(...)， 或者使用 ThreadLocal 包装。 2. addPoints 方法中的读取和写入不是原子的，可能存在并发覆盖风险。 不过考虑到调用方似乎是单线程写入，该问题风险不大，建议确认一下调用方。 3. 另外，addPoints 没有对 points == 0 的情况做提前返回， 在积分不变化时仍然会执行 map.put，建议补充提前返回逻辑，减少无效写入。

评审 B 比评审 A 好很多，它发现了 BUG-01，也对 BUG-02 表达了疑虑。但问题是：

1. 对 BUG-01 的修复建议是“每次调用时new SimpleDateFormat”，虽然可行，但会带来不必要的对象创建开销，并不是最优方案；
2. 对 BUG-02 的表述是“风险不大，建议确认一下调用方”，而类注释已经明确说明“会被多个 HTTP 请求线程同时使用”，这个疑虑本可以被直接确认；
3. “对points == 0提前返回”是一条典型的幻觉意见。该方法本来就会对 0 积分做同样的写入，提前返回对并发正确性没有任何帮助，只会让代码多一个分支，反而增加理解成本。

评审 B 的问题在于把真问题和假问题混在一起输出，工程师需要逐条甄别，评审的辅助效率就打了折扣。

4.3 评审 C：缺陷定位与修复建议相对完整

评审 C 的输出内容如下。

代码存在两个需要修复的高风险问题。 BUG-01（高风险，位于 RewardService.DATE_FORMAT 字段）： DATE_FORMAT 是 static final 的 SimpleDateFormat，而 SimpleDateFormat 内部持有可变状态， 不是线程安全的。类注释已说明该类会被多个 HTTP 请求线程使用，因此并发调用 formatDate 时， 可能出现日期错乱、Calendar 状态互相覆盖等异常。 修复建议：改用 java.time.format.DateTimeFormatter。 DateTimeFormatter 是不可变且线程安全的，可以作为 static 字段复用。 private static final DateTimeFormatter DATE_FORMAT = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"); public String formatDate(LocalDateTime dateTime) { return dateTime.format(DATE_FORMAT); } BUG-02（高风险，位于 addPoints 方法）： addPoints 执行的是“先取值、再累加、最后写回”的操作，并非原子操作。 当两个线程同时为同一 userId 调用 addPoints 时，两个线程可能读到相同的 oldPoints， 随后各自写入，最终只有一个线程的累加结果生效，造成积分丢失。 修复建议：将 pointsMap 改为 ConcurrentHashMap，并使用 compute 原子更新。 private final Map<String, Integer> pointsMap = new ConcurrentHashMap<>(); public void addPoints(String userId, int points) { pointsMap.compute(userId, (key, oldValue) -> { int old = (oldValue == null ? 0 : oldValue); return old + points; }); } 结论：建议修复 BUG-01 和 BUG-02 后再合并。

评审 C 的质量主要体现在三点：

1. 两个种子缺陷都被定位到具体方法和字段，说明不是泛泛而谈；
2. 每个问题都解释了“为什么危险”以及“什么场景会触发”；
3. 修复建议是可直接复制的代码，并且最终合入建议与风险等级匹配。

4.4 三份评审的直观对比

把三份评审放在一起对比，结果差异非常明显。

如果只问“哪个模型更厉害”，这个对比还不够严谨。真正严谨的做法是，把三份评审放入固定评分表中逐项打分。

5. 打分与结果分析

5.1 逐维度打分过程

缺陷检出维度（权重 40%）

评审 A 没有命中任何种子缺陷，得 0 分。评审 B 明确命中了 BUG-01，对 BUG-02 只是“疑虑但没有确认”，因此只能得到一半分数，即约 18 分（满分 40）。评审 C 两个缺陷全部命中且定位准确，得满分 40 分。

评审准确率维度（权重 20%）

评审 A 虽然没有任何正确发现，但也没有输出错误结论，不过在“评审准确率”这个维度上，没有检出同样意味着没有给工程师提供有效保护，按照从严原则记 10 分。评审 B 输出了一条明显的幻觉意见“对 points == 0 提前返回”，因此扣分较多，记 8 分。评审 C 没有发现虚假问题，记满分 20 分。

修复建议可执行性维度（权重 20%）

评审 A 没有给出任何代码级修复建议，记 0 分。评审 B 的修复建议偏笼统，“new 一个 SimpleDateFormat 或用 ThreadLocal”，虽然可以执行，但不是最优方案，记 6 分。评审 C 给出了DateTimeFormatter和ConcurrentHashMap.compute()两种完整修改思路，记满分 20 分。

风险结论正确性维度（权重 10%）

评审 A 的 “LGTM，可以直接合并” 属于严重误判，记 0 分。评审 B 虽然结论是整改后再合，但对 BUG-02 做了错误的风险降级，记 6 分。评审 C 对两个高风险问题都提出了“修复后合并”的正确结论，记满分 10 分。

边界覆盖度维度（权重 10%）

评审 A 完全没有考虑并发边界，记 2 分。评审 B 提到了并发，但没有结合类注释把风险确认下来，记 6 分。评审 C 覆盖了并发场景、线程安全 API 选择和在多线程下的影响，记满分 10 分。

5.2 最终评分汇总

5.3 从结果中得到的三个结论

1. “没有被发现问题”不等于“没有问题”。评审 A 的满分区间里没有任何检出，它的总分甚至低于只命中一半缺陷的评审 B。所以在选择代码评审模型时，不能只看评审是否“看起来专业”，而要看它能否命中已知缺陷。

2. 检出率与幻觉率必须同时评估。评审 B 命中了一个种子缺陷，看起来不错，但它同时输出了一条错误意见，增加了工程师的甄别成本。如果团队只看“模型找到了多少个问题”，很容易被幻觉意见带偏。

3. 评审结论必须落到合并决策上。一个评审无论写了多少条建议，最终都要回答“这段代码能不能合入”。评审 A 最大的问题就是错误放行；评审 C 之所以得到满分，恰恰是因为它在发现风险后给出了明确且正确的合入决策。

6. 搭建一个最小可复现的“评审质量”评估脚本

上面的人工打分比较依赖人工判断。实际团队在做模型选型或提示词调优时，可以用脚本快速量化“缺陷检出率”和“幻觉率”。下面给出一个简化版 Python 评估脚本，作为思路示范。

# 文件路径：scripts/grade_review.py """ 简化版 LLM 代码评审质量评估脚本。 思路：把种子缺陷与评审文本中的关键词做匹配，统计检出率、精确率和幻觉次数。 注意：这里的关键词匹配只是演示，真实评估建议由人工或更强模型辅助判断。 """ GROUND_TRUTH = { "BUG-01": ["SimpleDateFormat", "线程安全", "formatDate"], "BUG-02": ["丢失更新", "并发", "addPoints"], } # 常见幻觉信号，不同评审可能不同 HALLUCINATION_SIGNALS = [ "没有对 points == 0 做提前返回", "SimpleDateFormat 在 JDK 8 后已是线程安全", ] def hit_bug(review_text: str, keywords: list[str]) -> bool: low_text = review_text.lower() return all(keyword.lower() in low_text for keyword in keywords) def evaluate_review(review_text: str) -> dict: detected = [] for bug_id, keywords in GROUND_TRUTH.items(): if hit_bug(review_text, keywords): detected.append(bug_id) false_positives = [] for signal in HALLUCINATION_SIGNALS: if signal.lower() in review_text.lower(): false_positives.append(signal) bug_count = len(GROUND_TRUTH) recall = len(detected) / bug_count if bug_count else 0.0 if detected or false_positives: precision = len(detected) / (len(detected) + len(false_positives)) else: precision = 1.0 return { "detected": detected, "recall": round(recall, 3), "precision": round(precision, 3), "false_positives": false_positives, } if __name__ == "__main__": review_b = """ 代码整体可用，但发现一个问题： 1. RewardService 使用了线程不安全的 SimpleDateFormat。 ... """ result = evaluate_review(review_b) print(result)

运行脚本后会输出类似下面的结果：

{'detected': ['BUG-01'], 'recall': 0.5, 'precision': 0.5, 'false_positives': ['没有对 points == 0 做提前返回']}

使用脚本时需要注意几点：

1. 关键词匹配无法判断同义表述，例如模型写的是“并发累加可能覆盖”，脚本不一定能匹配到丢失更新；
2. 幻觉信号的判断最好由人工维护，将多次评审中发现的错误意见添加到信号列表；
3. 脚本适合做“初筛”，真正选择模型或调整提示词时，还是要以人工抽样评审为准。

如果你的团队已经把代码评审流程收口到内部平台，也可以把这个脚本作为回归用例，在每次调整评审提示词后自动跑一遍，观察召回率和精确率的升降。

7. LLM 代码评审中的常见问题与排查思路

在真实业务中使用 LLM 做代码评审，通常不会像示例这样干净，常见的问题可以整理成一张排查表。

在使用 LLM 代码评审时，还要小心一个隐藏问题：模型会复用训练数据中的相似代码片段。如果训练数据里本来就有和你业务代码相似但错误的写法，模型可能会基于“这段代码看起来常见”而给出错误判断。这一点很难从提示词层面彻底解决，只能通过“评审必须给出可复现的触发条件”来限制模型空口下结论。

8. LLM 代码评审的工程化最佳实践

8.1 用“bug-first”提示词约束评审目标

要让 LLM 代码评审的结论更可靠，应该尽可能让提示词面向“找 Bug”，而不是面向“给评价”。下面是一个可以按团队情况调整的提示词模板。

你是一名资深的 Java 代码评审专家。请对下面的代码做严格评审。 评审要求： 1. 按以下顺序检查：功能正确性、并发安全、资源释放、边界条件、空值处理、性能； 2. 每条意见必须输出四个部分：【文件或方法】【触发条件】【影响】【修复建议】； 3. 修复建议给出可直接使用的代码片段； 4. 如果没有发现可确认的缺陷，明确写“本轮未发现可确认的缺陷”； 5. 不要输出与代码风险无关的表扬性内容；不要凭猜测提出不存在的 Bug。 6. 最后必须给出合入结论：通过 / 修复后合并 / 不通过。 被测代码： {代码贴到这里}

这个模板的核心是两点：取消泛泛表扬，强制结论落到合并决策。这样模型输出的内容会更容易被人工复核，也更容易被评分脚本自动统计。

8.2 把 LLM 定位成“初筛”，而不是“终审”

从这次三份评审的对比可以看到，LLM 代码评审可以很优秀，也可以非常不靠谱。这里建议团队把它定位成“初筛助手”，而不是“终审人”。

推荐的流程是：

1. 静态检查工具先跑一遍，处理确定性的规范问题；
2. 单元测试和集成测试先跑，过滤功能性回归；
3. LLM 代码评审重点处理模式化的问题，如并发、空指针、资源泄漏、常见安全漏洞；
4. 最后由有经验的工程师做终审，重点关注业务语义和合入决策。

LLM 特别适合处理“常见 Bug 模式”的初筛，比如单例里持有可变的SimpleDateFormat、没有关闭的流、错误的锁顺序。但业务规则是否严谨、架构约束是否满足，这些只有结合项目上下文才能判断，模型很难替代人。

8.3 把评审经验沉淀成可复用的规则库

团队可以尝试把典型的代码评审案例整理成一个小的规则库，包括种子代码、缺陷说明、正确评审意见和错误评审意见。

这样做的价值在于：

1. 每次更换模型或修改提示词后，可以快速回归；
2. 新加入团队的工程师可以通过规则库理解“什么样的评审意见是合格的”；
3. 规则库可以用类似知识库的方式持续更新，积累越多，评审评估越准。

这里要注意的是，规则库里的代码片段在提交前要做脱敏处理，不要把公司内部真实业务代码直接放进外部模型或公共平台，涉及代码安全合规时，优先选择企业内部部署的模型或对代码进行脱敏后使用。

8.4 警惕“看起来很专业的幻觉”

LLM 代码评审里最危险的不是不说话，而是说一大堆看起来很专业的错误结论。这种幻觉可能出现在以下几个方面：

1. 编造不存在的 API 或方法；
2. 对代码行号和位置的错误引用；
3. 把训练数据里的旧版本 API 行为当作当前版本结论；
4. 对“可能存在问题”的表述过于自信，不给复现场景。

对应的处理手段是要求每条意见都给出“触发条件”。如果模型不能描述一个可以复现的触发条件，那么这条意见很可能是在猜测。反过来说，评审 C 之所以可信度高，正是因为它给每个问题都提供了具体的并发触发场景。

9. 总结与下一步实践

回到标题 The Review That Praised the Bug，这个实验说明了一个很容易被忽略的事实：模型给出的评审结论，并不因为语气自信而变得更可靠。真正决定评审价值的是它能否命中真实缺陷、是否误报、建议是否可执行、结论是否恰当。通过把一份已知带有种子缺陷的代码同时交给多个评审方案，再使用统一的评分表打分，团队就能把“哪个模型更靠谱”从主观感受变成可量化的结论。

如果你正在尝试把 LLM 引入代码评审，建议先从一个小仓库开始。准备两份到三份带种子缺陷的代码，让候选方案各跑三遍，按上面的维度打分，把结果整理成表格。这样你能很快知道当前的提示词方案在并发问题上是否敏感、在幻觉控制上是否合格。然后，再把评审脚本接到你的代码评审流程里，持续积累案例。

代码评审是一道需要长期维护的质量防线。让模型当助手、让人做终审，同时用一套标准给“评审的评审”打分，可能是当前最稳妥的落地方式。