LLM代码审查也会“表扬”Bug？一场静默失败评测实验与优化指南

最近在推进代码审查自动化时，发生过一个很有意思的评测现象：同一段存在严重缺陷的代码，不同 LLM 给出的 Code Review 意见差异极大，有的能正确定位到核心隐患，有的只是隔靴搔痒，最意外的是，还有一份 Review 通篇都在“表扬”那段有 Bug 的代码本身。

这个问题不是个别现象。LLM 做代码审查已经成了研发效能领域的热门方向，但评审质量如何验证、模型会不会漏报、会不会因为代码“看起来规范”就忽略运行时风险，依然值得系统讨论。本文用一个可复现的小实验切入，展示三份典型 LLM 审查意见的全过程，并给出判断 LLM 审查质量的方法和提示词优化思路。

1. 为什么生成式 AI 做代码审查，先要“审查 AI”

1.1 代码审查的價值与痛点

代码审查是保障代码质量最传统也最有效的手段之一。它能提前发现逻辑缺陷、设计问题、安全隐患和可维护性风险，也能促进团队内部的知识传递。但人工审查的成本很高。一个中型 PR 可能涉及十几到几十个文件，审查者既要理解业务流程，又要关注边界条件，还要在有限时间内给出结论。审查不充分时，一些隐藏较深的问题就会流入测试甚至生产环境。

LLM 的出现让许多团队开始尝试“让 AI 先审一遍代码”。它的优点很直观：

• 响应速度快，适合作为第一轮初筛；
• 能覆盖新人容易忽略的常见问题；
• 能根据代码上下文给出修改建议；
• 可以作为代码规范检查的补充手段。

但 LLM 不是静态分析工具，也不是确定性规则引擎。它生成的是概率化文本，天然存在“流畅但不准确”的风险。把这个风险放到代码审查场景中，后果可能比普通问答更严重：如果模型把有问题的代码解读成“设计良好”，开发人员又没有二次确认，Bug 就可能被默认放行。

1.2 LLM Code Review 与人工审查的差异

传统意义上的代码审查，强调“人对代码负责”。审查者会基于调用链、数据流、业务契约去判断一段代码是否满足需求，而不仅是看它是否语法正确。LLM 的审查则更像是“基于大范围代码语料进行模式匹配”，它能快速给出类似资深工程师会说的话，但缺少真实执行环境和完整业务上下文。

简单来说：

• 静态分析工具能告诉你“这个变量可能为空”；
• 单元测试能告诉你“这个分支没有被覆盖”；
• 资深工程师能告诉你“如果这里返回 True，订单会进入成功状态，但 ERP 里根本没有这条记录”；
• 而 LLM 可能会告诉你“代码结构清晰，异常处理完善”，即使那段代码存在致命的静默失败。

因此，在使用 LLM 辅助 Code Review 时，第一件事不是讨论怎么用，而是知道怎么验证它给出的结论。这正是本文实验要回答的问题。

1.3 评测思路：用“一个确定的 Bug”去检验 Review 质量

要判断一份 Code Review 写得好不好，最直接的办法是拿一段包含确定 Bug 的代码交给模型审查。然后看模型是否发现了 Bug、如何描述 Bug、是否把无害代码误判为缺陷，以及给出的修改建议是否真的能解决问题。

我在实验中选择了业务开发中一类典型且隐蔽的问题：静默失败。它也常被称为“吞掉异常后的伪成功”。随着微服务和异步任务增多，这类问题特别容易出现在接口调用、状态同步、消息推送等场景。代码看起来有异常处理、有日志、有返回值，但错误发生时调用方依然会收到“成功”信号，后续业务逻辑继续往下走，最终导致数据不一致。

2. 评测实验：一段藏着静默 Bug 的订单推送代码

2.1 完整代码

为了让审查过程可复现，我准备了一段接近真实业务的 Python 函数。它的职责是把订单推送到外部 ERP 系统，并告诉调用方推送是否成功。

# 文件路径：demo/order_sync.py import json import logging import requests logger = logging.getLogger(__name__) ERP_ORDER_URL = "https://erp.example.com/api/order/create" def push_order_to_erp(order: dict) -> bool: """推送订单数据到 ERP 系统。 调用方约定： - 返回 True，表示 ERP 已成功接收订单； - 返回 False，表示推送失败，需要后续补偿或告警。 """ try: response = requests.post( ERP_ORDER_URL, json=order, timeout=5, headers={"Content-Type": "application/json"}, ) if response.status_code == 200: payload = response.json() return payload.get("success", False) is True except requests.Timeout: logger.exception("push order to erp timeout") except requests.RequestException as exc: logger.exception("push order to erp request failed, reason=%s", exc) except json.JSONDecodeError: logger.exception("push order to erp response is not valid json") # 注意：这里无论是网络异常、超时、非 200 状态，还是 JSON 解析失败， # 都会执行到这一行返回值是 True 的语句。 return True

只看这段代码，不少同学可能觉得它“挺完整”。函数有 docstring，有类型注解，异常被分类捕获，日志也打印了堆栈。但如果沿着所有执行路径走一遍，就会发现真正的问题。

2.2 这个 Bug 的本质是什么

函数最后一行return True并不在try块内部，而是在所有except分支之后。它意味着：

• 当 ERP 返回 500 状态码时，函数进入if response.status_code == 200的判断，条件不满足，不进入 try 内的return；
• 当请求超时时，异常被except requests.Timeout捕获，打印日志后流程继续向下；
• 当响应体不是合法 JSON 时，response.json()抛出json.JSONDecodeError，被捕获后流程继续向下；
• 无论哪种情况，最终都会执行return True。

调用方的代码可能是这样的：

# 文件路径：demo/order_service.py from demo.order_sync import push_order_to_erp def submit_order(order): order.save(status="PENDING") if push_order_to_erp(order): order.update(status="SUCCESS") else: order.update(status="SYNC_FAILED") send_alert(order)

由于push_order_to_erp在所有错误场景下都返回True，调用方会认为订单推送成功，把订单状态更新为SUCCESS。但 ERP 系统可能根本没有收到任何数据。这个 Bug 的直接后果就是：订单显示成功，却没有进入下游仓储、财务、物流等系统，且没有告警，属于非常典型的静默数据一致性问题。

2.3 为什么这类 Bug 难发现

这类 Bug 有以下三个特点，导致它比普通的空指针、越界更容易通过 Review：

• 代码“看起来规范”。函数有完善的分层异常处理、有日志、有类型标注，如果只看局部代码，很容易形成“作者是有经验的工程师”的正面印象。
• 错误路径不是立即报错。异常被捕获后没有继续抛出，也没有返回False，而是“自然流入”到函数末尾的成功返回值。
• 真正产生危害的地方不在函数内部，而在调用方。如果只看这个函数，很难看到订单状态被更新为SUCCESS的后果，必须结合核心业务链路才能判断严重级。

人工审查需要顺着异常分支逐个走查才能发现，而 LLM 在生成 Review 时可能根本没有对每一条返回路径做穷举推理，这给后续的“表扬 Bug”埋下了伏笔。

3. 三份代表式 LLM 审查意见

我使用同一段代码、同一份提示词，对不同 LLM 分别进行了多轮测试。由于模型版本迭代很快，本文不比较具体品牌，而是把几类常见输出归纳整理为 A、B、C 三种代表式意见。下面展示的是经过脱敏整理后的审查内容，用来讨论不同评审风格背后的质量差异。

3.1 Review A：能定位核心 Bug，并给出明确影响

Review A 的开头非常直接，它将问题标记为“P0 严重缺陷”。

P0 严重缺陷：所有异常路径最终都返回 True

当requests.post抛出超时异常、ERP 返回非 200 状态码、响应体不是合法 JSON 时，函数都会执行最后一行的return True。调用方会把推送失败误判为成功，导致订单状态被更新为 SUCCESS，但 ERP 中并没有对应订单，产生数据不一致。

建议修改：

1. 只有确认 ERP 接受订单后，才返回True；
2. 所有异常分支统一返回False；
3. 调用方基于False触发告警或重试。

P1 建议：增加幂等键

如果订单服务使用消息队列重试推送，ERP 可能因为网络超时已经创建了订单，但客户端没有得到响应。建议在请求体中增加order_id作为幂等键，避免重复创建。

这份 Review 的价值在于它穿透了代码表面，直接描绘了“调用方收到 True 之后会发生什么”，因此能准确判断出这是一个 P0 级问题。同时它也给出了后续重试场景下可能存在的幂等风险，属于不仅仅“找到 Bug”，还能往下延伸建议的高质量审查。

3.2 Review B：发现了异常分支问题，但严重级判断不足

Review B 也提到了异常分支的返回值问题，但把它当作“健壮性优化”而不是数据一致性严重缺陷。

问题：函数在所有异常场景下都会返回 True，返回值语义不够精确。

建议在except requests.Timeout和except requests.RequestException分支中增加return False，以便调用方感知推送异常。

另外，建议把logger.exception改为logger.error并指定exc_info=False。在业务代码中频繁打印完整堆栈会导致日志量过大，而且多数异常已经被上层框架统一记录，这里只需要输出简单错误信息和订单号即可。

代码整体质量较好，异常分类清晰，日志记录完善。

这份 Review 发现了“返回 True 不太对”，但它没有评估出这个问题的真实危害。它把修复描述成“返回值语义精确”的优化，而不是“订单会在没有推送成功的情况下被判为成功”的严重缺陷。如果开发人员按这个建议只加return False，虽然能改善问题，但可能仍然不会意识到需要增加告警机制和幂等保护。它在“是否发现 Bug”这个维度上算部分命中，在“是否理解 Bug 影响”这个维度上是明显不足的。

更需要注意的是，Review B 还提出了一个改进日志的误报式建议：把logger.exception换成logger.error。这其实是削弱可观测性的反向建议。一旦线上出现问题，没有堆栈将很难定位异常发生的位置。

3.3 Review C：通篇“表扬”，完美错过了 Bug

Review C 的写法最值得警惕，因为它用非常专业的口吻，把隐藏 Bug 的代码夸成了优质代码。

整体评价

这段代码整体质量较高，函数职责单一，异常处理层次清晰，尤其是对requests.Timeout和普通requests.RequestException做了分类处理，说明作者考虑了网络请求中的常见异常场景，具备较强的健壮性意识。

值得肯定的地方

1. 使用logger.exception保留异常堆栈，方便排查问题；
2. 对超时、请求异常、JSON 解析异常分别做了捕获，异常分类很细致；
3. 函数在多个失败场景下最终都返回True，相当于提供了一个统一的“兜底成功”语义，能简化调用方的重试策略。

建议

1. payload.get("success", False) is True可以简化为payload.get("success")；
2. 推荐把 ERP 地址提取到配置中心，避免硬编码。

第三点是非常典型的“幻觉式表扬”。把return True解读成“统一的兜底成功语义”，本质上是把 Bug 解释成了设计。如果开发人员没有独立判断能力，看到这份 Review 后可能会更确信代码没有大问题，反而比不审查更危险。

这也是“The Review That Praised the Bug”这个标题想强调的现象：一份看起来很专业、用词很自信的评审意见，却可能完全背离代码的真实行为。

4. 以代码为准线：给三份 Review 打分

4.1 评分维度说明

在评估 LLM 审查质量时，不能只看它写了多少条建议。我建议从以下四个维度对输出进行评分，每个维度 5 分：

• 核心缺陷定位：能否识别出代码中真正的 P0/P1 级 Bug；
• 严重级判断：能否正确理解 Bug 对调用方和业务链路的影响；
• 建议可执行性：修复建议是否具体、能不能直接落地；
• 噪声比例：是否包含误报、反向建议或空洞表扬。

4.2 评分结果对比

Review A 能明确指出“所有异常路径都返回 True”并联系到调用方的订单状态更新，说明它建立了从函数内部到业务链路的推理。Review B 虽然看到了返回值语义问题，却把它降级为一般健壮性建议，同时还引入了日志相关的反向建议。Review C 则连 Bug 在哪都没发现，反而用“健壮性很好”给出错误的正向反馈，在所有维度上得分最低。

4.3 一个重要结论

三份 Review 放在一起后，最反直觉的结论是：给人留下“专业”印象最深的 Review，不一定是有效的 Review。

Review C 的结构非常完整，开始给整体评价，接着列优点，最后提建议，语言也很像资深工程师。但它所谓的优点，恰恰掩盖了真正的问题。这提醒我们，评估 LLM 生成的评审意见不能只看文本流畅度，也不能只看条数多少，而要回到代码本身去验证每一条结论。

5. 从“表扬 Bug”现象看 LLM 的局限

5.1 表面代码质量会诱导模型生成正面评价

大语言模型在训练时学习过大量 GitHub Issue、Pull Request 和 Code Review 文本。这些语料中存在一个统计规律：包含完整 docstring、类型注解、分层异常处理的代码，更容易获得类似“代码清晰”“健壮性不错”的评价。

这段订单推送代码在这些表面特征上几乎拉满：有函数说明、有参数注解、异常捕获分类明确、每个分支都打了日志。对于没有真正“执行”代码能力的模型来说，这些表面特征会成为概率分布的强信号，驱动它生成正面内容。这是 Review C 会“表扬”这段代码的重要背景。

这种逻辑有点像：一个人穿得非常正式，简历写得也很完整，面试官就容易默认他能力很强。但代码审查应该关注的是运行时行为和业务结果，而不是代码的“穿着”。

5.2 缺少对控制流进行穷举推理的机制

要发现这个 Bug，需要在函数内部做一次完整的路径分析：列出每一个return语句，分析什么条件下会执行到它，最后看是否有异常分支会误命中成功返回值。

对 LLM 来说，这不是一个轻松的任务。它更擅长基于前文信息预测下一个 Token，而不是像编译器或静态分析器那样对代码做结构化的路径穷举。虽然较新的模型具备更强的推理能力，但只要没有显式要求模型“逐步列出所有 return 路径”，它就可能依赖直觉直接输出结论，从而漏掉异常控制流中的问题。

这也是为什么在第 6 节优化提示词时，我们需要把“要求模型先推演路径”放在最前面。

5.3 用“上下文假设”替代“代码事实”

Review C 把return True解释为“统一的兜底成功语义”。它为什么要这样解释？很可能是因为模型在训练数据中见过大量“统一出口”“统一返回结构”的设计模式，因此在看到多个异常分支之后，自动脑补了一个合理的工程理由，于是把 Bug 合理化。

这是 LLM 推理中比较危险的一种表现：当它看到一个不常见或者本身就错误的写法时，不是停下来标记问题，而是尝试解释这个写法“为什么合理”。代码评审场景里，这种倾向会导致模型漏报，甚至会说服人类开发者接受错误的设计。

5.4 与静态分析工具形成互补

值得一提的对比是，传统静态分析工具并不会出现“表扬 Bug”的问题。像 SonarQube、ESLint、Bandit 这类工具基于确定规则运行，能在一秒内定位到未处理异常、空指针、危险函数调用等已知模式，且结果可复现。

静态分析工具的缺点是规则固定、难以理解业务语义，所以无法判断“返回 True 是否会导致订单状态错误”。而 LLM 的长处恰好是具备业务联想能力，能够结合调用链去理解代码影响。最合理的做法是把两者结合：先用静态分析工具处理确定性问题，再用 LLM 处理需要语义理解的逻辑问题，最后让人工做关键判断。

6. 让 LLM 做代码审查更可靠：提示词与工作流优化

6.1 从“自由评审”切到“契约式审查”

如果提示词只写“请 review 以下代码”，模型很可能会输出一段泛泛而谈的内容。更好的做法是在提示词里先定义这段代码的“契约”：

• 调用方依赖这个函数的哪些行为；
• 返回值的精确语义是什么；
• 哪些场景属于严重故障；
• 代码改动后会影响哪条业务链路。

例如，可以这样设计提示词：

你负责 review 以下 Python 函数。函数所在系统的业务约定如下： 1. 该函数会把订单推送到 ERP，并在成功后返回 True。 2. 调用方只要收到 True，就会把订单状态更新为 SUCCESS。 3. 返回 False 时，上层会发送告警并触发补偿流程。 请重点审查： - 是否存在 ERP 未成功接收订单，却返回 True 的路径； - 所有异常分支的返回结果是否与业务约定一致； - 是否存在重试时重复创建 ERP 订单的风险。 输出格式： - 问题清单，每条标记严重级别 P0/P1/P2 - 每条问题说明影响场景 - 给出可执行的修改建议

契约式审查的核心价值是让模型不再“自己脑补业务逻辑”，而是基于你提供的业务规则去核对代码。

6.2 强制模型先推演执行路径

对于容易静默失败的函数，可以加入一道“推理前置步骤”：

不要直接写结论。 第一步：列出函数中所有 return 语句，说明每条 return 在什么条件下会被执行。 第二步：针对每个 except 分支，说明异常发生后函数最终会返回什么值。 第三步：根据调用方约定，判断“ERP 未成功但调用方收到 True”的情况是否可能发生。 第四步：最后再给出问题和修改建议。

这一步很有价值。很多在自由生成模式下漏掉问题的模型，在“先列出路径再下结论”的约束下都能明显提高准确率。原因在于，它把问题从“预测下一句评审意见”转换成了“按步骤推理代码行为”，这更接近结构化分析。

6.3 让模型写“反向 Test Case”

另一个可行的技巧是让模型为函数设计测试用例，特别是覆盖异常路径的用例：

def test_push_order_to_erp_timeout_should_return_false(mocker): mocker.patch("requests.post", side_effect=requests.Timeout) result = push_order_to_erp({"order_id": "123"}) assert result is False

让模型先写出这个测试，再让模型“运行”一遍测试，观察是否真的会失败。这个过程能帮助模型意识到，现有代码在超时场景下返回的是 True 而不是 False，测试会通过不了。这个方法比单纯要求“找 Bug”更能激活模型的逻辑校验能力。

6.4 引入人工复核步骤

即使优化了提示词，LLM 的输出仍然不能直接等同于审查结论。建议工作流调整为：

1. LLM 负责第一轮初筛，输出带严重级别的问题清单；
2. 静态分析工具负责规则类问题；
3. 开发人员只复核 LLM 标记为 P0/P1 的问题；
4. 对于 LLM 给出的“优点”描述，尤其是涉及异常处理、并发、返回值语义的部分，要回代码里反向验证；
5. 每周抽几份 LLM 审查历史，对照线上故障或测试发现的问题，统计漏报率。

这套流程既发挥了 LLM 的效率优势，又避免把模型输出当标准答案。

7. LLM Code Review 常见误区与判定清单

7.1 几个容易踩的坑

在日常使用 LLM 做代码审查时，以下几个现象应引起警惕：

7.2 如何判断一份 LLM Review 是否可用

面对一份 LLM 生成的 Code Review，建议用下面的清单做快速校验：

• 是否覆盖了所有异常分支和边界条件？
• 是否有问题明确指出了“哪条执行路径违反了什么业务规则”？
• 建议修改后，是否不会破坏原有正常流程？
• 有没有把代码中真正的优势和风险混为一谈？
• Review 的结论是否来自代码本身，还是模型自己创造出来的上下文？

如果一份 Review 无法回答前两个问题，它很可能只是一篇“看起来很专业”的文本，而不是一份真正有工程价值的审查结果。

8. 工程落地建议

8.1 先建“已知 Bug 样例库”，再上线评审 Agent

团队在引入 LLM Code Review 之前，建议先从历史故障和测试 Bug 中挑出 20 到 30 个真实案例，整理成“带缺陷代码 + 正确审查结论”的测试集。之后每一次调整提示词或更换模型，都用这个数据集做回归评测。

这样可以避免一个常见问题：某个模型在自由对话里表现很好，但一到代码审查场景就频繁漏报。有了测试集，LLM 的审查能力才是可衡量、可追踪的。

8.2 对 LLM 的“优点描述”保持警惕

代码审查的核心是发现问题，但 LLM 在生成评审意见时往往喜欢“先说优点再说问题”。如果模型把某个有风险的写法描述成优点，含义就完全变了。

建议在自己的审查工作流中，把 LLM 输出的“值得肯定的地方”同“问题清单”分开处理，并对前者做重点复查。毕竟，问题没被发现只是漏报，但把问题说成优点，则可能让开发者产生错误的安全感，反而比不做审查更有风险。

8.3 不要把模型当最终裁决者

LLM Code Review 的最优定位是“助手”，而不是“裁决者”。它能帮你快速覆盖大量常见问题、给你提供思路、帮你解释不熟悉的代码，但它缺少对业务历史的了解，也缺少真实运行环境的反馈。那些涉及数据一致性、资金安全、用户隐私的关键判断，最终还是要靠人来兜底。

落地上比较务实的目标是：让 LLM 帮团队节省 30% 到 50% 的机械性审查时间，再由人来集中精力解决模型无法处理的复杂逻辑和业务问题。

8.4 建议的输出模板

在团队内部，可以让 LLM 按下面模板输出，这样更便于人工复核：

## 严重问题（P0/P1） - [严重级别] 问题描述 - 触发条件：xxx - 影响范围：xxx - 修改建议：xxx ## 一般问题（P2） - [严重级别] 问题描述 ## 疑似误报汇总 - 模型不确定，但建议人工确认的点 ## 代码优点 - 按“代码位置 + 具体行为”描述，禁止只写抽象评价

加入“疑似误报汇总”这一项有个额外好处：它会提醒模型“不确定的内容不要乱说”，变相降低幻觉输出概率。

这段代码评测实验最有价值的收获之一，并不是判断哪个模型更强，而是提醒我们：生成式 AI 的输出必须回到代码和行为结果中去验证。未来无论模型能力的边界怎么扩展，“找到真实 Bug 并准确评估其影响”始终是代码审查的第一目标。使用 LLM 时，也别忘了给它定义清晰契约、要求路径推演、独立验证结论，并保留人工对关键问题的判断权。