这次我们来看一个特别能说明问题的评测切入点同一段带有明确 bug 的代码分别交给不同的 LLM 做 code review最后把三份评审意见拉回源代码逐行打分。结果不一定是“模型越强评审越准”反而会出现一种很典型的现象——某份评审把问题代码夸了一遍却没有发现真正的缺陷。这种现象不能简单归结为“模型水平差”。更值得讨论的是我们到底应该怎么给 LLM code review 结果评级只看它有没有发现 bug 不够还要看它有没有误报、有没有给出可执行的修复方向、有没有在代码行为未被验证的情况下就给出“可以合入”的结论。这篇文章就用一个可控的最小复现案例拆开讲清楚评审质量的评分方法。如果你正在接 LLM code review 流程或者想把代码评审 Agent 做成一个可验收的内部工具这篇可以直接照着做。文章会包含四块内容一套可复现的评审样本设计、三段典型的 LLM 评审结果对比、一套“对照代码真相”的打分体系以及接入 CI/API 时需要注意的排查点。所有样例都是为了让读者能直接跑一个最小验证而不是只看结论。1. 核心课题LLM code review 的结果要先“再审”很多人测试 LLM code review 时习惯看模型输出文本是否流畅、有没有提到几个专业术语。这个验证方式在工程上是错的。评审结果是否合格不能靠阅读体验判断必须把它还原成三个问题代码里实际存在的缺陷评审有没有命中。评审提出的问题在代码里能不能找到对应证据。评审给出的修改建议是否能直接落地而不是绕圈子。否则就会出现标题里的情况一份评审写得态度很积极、结构很清晰但它赞美了一个会改变业务结果的 bug。如果评审流程只看“输出质量”这类结果就会被误判为高分。1.1 本次评测对象这次任务以“代码评审质量分级”为核心而不是跑一个超大模型做压测。评测对象可以用一句话描述同一个函数、同一份业务规则、同一个 diff交给 3 个不同模型分别做 code review由人来按代码真相打分。评测维度具体内容输入代码一个包含语义回归缺陷的 Python 函数业务规则明确要求返回金额最大的 N 条订单缺陷类型排序方向被改反导致结果从“取最大”变成“取最小”评审数量3 份独立评审最终评分方式对照已知缺陷、误报、建议可执行性进行人工判定这个场景很小但很适合做基准。因为代码缺陷和业务规则的冲突点非常具体函数明明要取金额前 N 大实现却用升序取前 N。LLM 如果只关注代码风格很容易给出“逻辑清晰、结构良好、可以合入”的错误结论。正是在这种边界清晰的场景里评审能力的差距才会暴露出来。1.2 为什么不能只关注“是否发现 bug”这里先给结论后面会用实际样例说明。“是否发现 bug”只是召回率的一部分。真正做评审打分还要看精确率模型提了 5 个问题其中几个是真问题几个是误报。证据链问题是否指向了具体函数、具体行、具体变量。业务理解模型是否把需求描述当作硬约束而不是只做代码风格分析。修复方向建议是“这里可能有风险”还是“应该改成 reverseTrue”。安全边界模型是否在自己不确定时给出了过于绝对的结论。所以本文的评分表不采用单一分数而是用一个分级表做最终判断。这样做的好处是当模型出现“没有发现明显问题”这种输出时不会被误认为合格。2. LLM code review 的失败模式表扬 bug在正式给样例前先说一下这类失败为什么会发生。LLM code review 常见翻车模式有三种。第一种是“表面合理性覆盖”模型看到代码变量命名清楚、函数结构不复杂、缩进整洁就会在摘要中给出正向评价。这种评价与代码实际行为无关却容易影响读者判断。代码评审不是作文批改代码整洁可以作为备注但不能替代逻辑正确性。第二种是“缺少执行语义验证”很多模型在阅读代码时并不会真正模拟多组输入输出。它更像是基于训练语料推断这段代码“可能是什么意思”。一旦代码的意图和实际业务规则出现细微偏差模型就可能顺着代码表面逻辑走而不是倒推业务规则。第三种是“权威语气误报”模型可能用很确定的语气说“这里会发生空指针”但实际上代码路径并不存在该问题。这种误报比漏报更隐蔽因为它会让开发者浪费时间排查一个根本不存在的缺陷甚至降低后续真实告警的可信度。这篇文章要搭建的评分方案就是针对这三种失败模式设计。我们最终会通过“把 review 结果与代码 ground truth 做差”来打分。3. 构造最小缺陷样本一段会误导评审的代码为了让 LLM code review 的对比可复现这里用一个很小的函数。重点不是函数复杂度而是业务规则分歧点必须足够清晰。3.1 业务规则系统需要计算“金额最高的 N 个订单总和”。这段逻辑被用于优惠券发放、对账报表等场景。输入是一个订单列表每个订单包含id和amount输出是最高的 N 个订单金额之和。3.2 缺陷代码下面这段代码是一份“重构后”的样本。旧版本用reverseTrue排序取前 N新版本为了“提升可读性”改成升序后直接取前 N。也就是把原逻辑取最大 N 个悄悄改成了取最小 N 个。def top_amount(orders, n): ascending sorted(orders, keylambda o: o[amount]) return sum(o[amount] for o in ascending[:n])如果输入数据为orders [ {id: a, amount: 1}, {id: b, amount: 3}, {id: c, amount: 2}, ]正确结果是金额最大的两个订单3 2 5。但上述代码返回的是金额最小的两个订单1 2 3。这就是“业务规则被悄悄反转”的 bug。3.3 配套的固定评审提示词为了让 3 个模型拿到一致的信息需要提供统一的任务描述。这里可以设计一份中性的评审提示词模板。注意不要在提示词里写“请找出所有 bug”因为这会诱导模型过度报告。更好的做法是让模型先理解业务规则再判断实现是否符合预期。你是一名资深代码评审工程师。下面有一段 Python 函数和它的业务规则请对这段代码进行 code review。 业务规则 传入一组订单列表 orders每个订单包含 id 和 amount。函数应返回金额最高的 n 个订单金额之和。 代码 def top_amount(orders, n): ascending sorted(orders, keylambda o: o[amount]) return sum(o[amount] for o in ascending[:n]) 请按以下格式输出 1. 总体结论通过 / 不通过 / 需要修改 2. 风险等级blocker / major / minor / nit 3. 问题明细给出函数名、问题描述、涉及变量、修复建议 4. 其他建议如果没有不要强行补充这个提示词把业务规则前置并要求模型按结构化字段输出。即便如此部分模型仍然可能因为函数代码不复杂而忽略排序方向问题。3.4 结构化输出协议如果要把评审结果接入下游流程可以要求模型输出 JSON。这里给出一个结构示例{ summary: 通过, findings: [ { severity: major, function: top_amount, issue: 排序方向与业务规则不一致, evidence: 使用升序排序后取前 n 个会返回金额最小的 n 个订单, suggestion: 排序时增加 reverseTrue或使用 sorted(..., reverseTrue) } ], false_positive_check: [] }结构化输出只是便于解析并不能保证内容正确。真正的质量把关仍然在“评审结果与已知缺陷的对照”这一步。4. 三份评审结果示例与分级下面给出三段具有代表性的评审结果样例。这三段样例代表了三种常见情况也可以直接拿去测试不同的 LLM API观察输出属于哪一类。4.1 评审一表扬了 bug 的评审第一份评审输出的文本风格是“总体积极、没有具体证据”。它可能会这样写该函数实现简洁变量命名清晰使用sorted对列表排序后取前 N 个元素逻辑正确。没有发现阻塞性问题建议合入。这份评审就是典型的高噪音输出。它做了三件错误的事情没有提到业务规则中“金额最高”这一限定条件。把排序方向完全忽略默认升序取前 N 就是正确逻辑。在没有任何测试案例或证据的情况下给出“可以合入”的结论。如果按 0 到 100 评分这份评审在“bug 召回”维度是 0 分。它甚至不是漏报而是用积极评价掩盖了问题。投入流水线后这种结果会让开发者跳过本应进行的边界检查。4.2 评审二命中缺陷但证据不够完整第二份评审有进步它会指出排序方向可疑但可能不会直接给出修复方式。例如当前实现使用升序排序取的是前 N 个元素。如果业务规则是返回金额最大的 N 笔订单这里的排序方向会导致结果错误。建议补充单元测试覆盖金额不等的订单列表确认排序方向是否符合预期。这份评审已经命中了核心 bug。它给出了原因分析并指出了业务规则冲突。不足之处在于修复建议不够“硬”没有直接给出reverseTrue或替代写法。如果团队里开发者对业务规则理解不深可能还需要二次沟通。这种评审可以评级为“及格偏上”。4.3 评审三命中缺陷并给出可执行修复第三份评审属于可以直接交给开发者的质量。它会这样写问题定位在top_amount。业务规则要求取金额最高的 N 笔订单但当前第 2 行ascending sorted(orders, keylambda o: o[amount])是升序排列第 3 行取出前 N 个后实际返回的是金额最低的 N 笔订单。 建议改为top_n sorted(orders, keylambda o: o[amount], reverseTrue)[:n]并补充用例当 orders [1, 3, 2]n 2 时期望结果为 5而不是 3。这份评审有三个特点命中真实缺陷。给出了具体代码补丁。补了可执行的测试样例。4.4 三份评审分级表评审是否发现缺陷是否给出证据是否给出修复方案是否误报评级评审一否否否无F表扬了 bug评审二是部分部分无B评审三是是是无A这个表格说明了一个问题同样一份代码LLM 评审质量可能从 F 到 A 都有。只看单个模型的一次输出很难判断模型能力必须结合任务规范和代码执行结果。5. 把 LLM 评审结果对照代码真相进行打分评分不能只靠“看起来对不对”。在一套可重复的评测流程里需要先定义 ground truth再写一个脚本把评审输出映射成可比较的指标。5.1 真实缺陷标签这里把缺陷标签定义为缺陷类型语义回归。所在函数top_amount。规则冲突排序方向错误导致取数范围错误。期望结果返回最大 N 个订单金额之和而非最小 N 个。5.2 用 Python 脚本做基础评分演示下面这段代码是一个最小演示脚本用于把“已知缺陷”与“评审文本”做简单匹配。实际生产中可以升级为对结构化 JSON 的字段判断而不是语义匹配。import json known_defects { sort_direction: 排序方向错误应该按 amount 降序取前 n } def evaluate_review(review_text): score 0 output { hit_known_defects: [], missed_defects: [], raw_score: 0.0, } if 升序 in review_text and (reverse in review_text or 降序 in review_text): output[hit_known_defects].append(sort_direction) score 60 else: output[missed_defects].append(sort_direction) if 测试 in review_text or 示例 in review_text: score 20 if 业务规则 in review_text or 金额最高 in review_text: score 20 output[raw_score] score return output review 当前排序方向可能有问题建议补充测试并确认业务规则 print(evaluate_review(review))这个脚本只是一个模板。真正生产使用的评分规则要把评论文本解析成结构化字段再与已知缺陷配置做映射。5.3 五个评分维度维度判断方式权重建议缺陷召回评审是否命中 ground truth 缺陷40%精确率评审提出的问题是否都是真问题20%可执行性是否给出具体修改方式和测试建议20%业务规则理解是否围绕“金额最大”等业务描述展开10%结果安全性是否在不确认时给出“可以合入”的结论10%缺陷召回权重最高是因为 code review 的第一目标就是拦住错误逻辑。如果模型在业务规则有硬约束的前提下仍然漏掉问题即使它写的意见再多也不能算合格。6. 接入 API 与批量评审的工程化思路如果只在网页对话框里测试 LLM code review无法形成稳定的质量反馈。真正要做的是把这段评审流程封装成 API 服务并支持批量的 diff 文件输入。6.1 通过 API 调用评审服务假设你已经有一个兼容 OpenAI 格式的本地或云端推理服务调用代码可以这样设计import requests def call_code_review_api(code_content, rules, api_urlhttp://127.0.0.1:8000/v1/chat/completions): payload { model: your-review-model, messages: [ { role: system, content: 你是一名严格的代码评审工程师。 }, { role: user, content: f业务规则{rules}\n代码\n{code_content} } ], temperature: 0.1, max_tokens: 1200, response_format: {type: json_object} } resp requests.post(api_url, jsonpayload, timeout180) resp.raise_for_status() return resp.json()注意几点温度建议调低。评审任务不适合发散输出。开启response_format可以拿到 JSON但不同服务支持程度不同需按实际接口调整。超时要设置得足够长代码长或上下文窗口紧凑时推理耗时可能明显增加。model字段要以你实际部署的模型名称为准不要照抄。6.2 批量评审任务的结构批量处理时不建议把多段代码塞进同一轮对话。更稳妥的方式是每个 patch 单独发送一次请求并把结果写入独立 JSON 文件。建议的目录结构review_task/ ├── patches/ │ ├── 001_fix_sort.json │ └── 002_fix_timeout.json ├── outputs/ │ ├── 001_fix_sort.review.json │ └── 002_fix_timeout.review.json └── logs/ └── review.logPython 批量任务框架可以这样写import json import pathlib patch_dir pathlib.Path(./patches) output_dir pathlib.Path(./outputs) output_dir.mkdir(exist_okTrue) for patch_file in patch_dir.glob(*.json): payload json.loads(patch_file.read_text(encodingutf-8)) review call_code_review_api( code_contentpayload[code], rulespayload[rules] ) out_path output_dir / f{patch_file.stem}.review.json out_path.write_text( json.dumps(review, ensure_asciiFalse, indent2), encodingutf-8 )批量任务必须保存原始请求、模型输出、打分结果三个部分。否则后面出现“某次评审质量差”的问题时很难回溯是提示词问题、模型问题还是代码本身问题。6.3 失败重试API 调用经常因为超时、限流、网络抖动失败。批量评审要加一个简单的重试函数import time def call_with_retry(*args, retries3, delay5, **kwargs): last_error None for attempt in range(retries): try: return call_code_review_api(*args, **kwargs) except Exception as exc: last_error exc time.sleep(delay * (attempt 1)) raise last_error重试是好习惯但不要无限重试。如果同一个 patch 连续失败 3 次应该先标记为失败而不是继续浪费时间和资源。7. LLM 资源占用与性能观察思路LLM code review 和图像生成、视频生成不同它没有特别夸张的显存需求但推理延迟和上下文长度仍然要关注。7.1 CPU 与 GPU 推理差异如果跑的是本地大模型CPU 推理可以做但速度会明显慢于 GPU。评审一段 200 行以内的代码CPU 推理可能需要等待几十秒到数分钟具体时间取决于模型大小和量化方式。GPU 推理通常更顺滑但显存占用仍要根据实际模型版本测试不能一概而论。如果团队只是小规模试用建议优先使用 API 服务减少本地部署维护成本。如果是私有化部署要求再考虑本地推理。7.2 上下文长度对性能的影响diff 文件越长模型需要处理的 token 越多推理耗时也越高。实践中有两个建议不要直接把巨大 MR 的全部 diff 一次性塞给模型。先做 diff 结构化拆分按文件或按函数分批评审。结构化拆分后单次评审的输入缩短输出质量通常会更稳定。把多次评审结果汇总后再由人做最终判定。7.3 可观察指标接入服务后至少记录这些指标指标说明单次请求耗时判断服务响应速度输入 token 数判断代码上下文长度输出 token 数判断评审篇幅超时次数判断服务稳定性缺陷命中数判断评审质量误报数判断输出可信度这些指标建议写入日志后续可以用来对比不同模型、不同提示词的效果。8. LLM code review 常见问题与排查方法问题现象可能原因排查方式解决方案评审输出“代码很好没有发现问题”但代码有明显 bug模型只做风格分析没有验证业务规则用多组输入输出案例反查模型在提示词中强制要求“必须给证据行”评审输出大量误报提示词诱导模型找 bug或温度过高检查提示词是否有负面引导降低 temperature增加业务规则描述评审没有围绕业务规则展开任务描述中业务规则不够醒目检查提示词结构把业务规则放在代码之前要求模型复述规则接口调用超时输入代码太长或模型推理慢查看日志中的输入 token 和时间拆分 diff分批评审增加超时时间批量任务中途卡住单条请求阻塞了队列检查是否缺少超时和重试增加timeout和失败标记模型给出修复建议但代码仍错误模型只给方向没有给完整补丁对比修复后输出引入单测作为验收门禁多模型结果差异大各模型指令遵循能力不同使用同一提示词跑同一代码用评分表给多模型建立基线这里要补充一个最容易踩的坑不要因为模型输出结构规范就认为评审内容可信。结构可以是正确的内容仍可能是在“自信地犯错”。尤其在 code review 场景里错误的结论比没有结论更危险。9. 最佳实践与使用建议从上面的样例可以看出LLM code review 真正能落地需要一套工程控制而不是单纯依赖模型能力。9.1 第一次先小参数验证不要一开始就接入全部代码仓库。可以先选一个包含历史缺陷的小项目跑通“代码 - 评审 - 对照真实缺陷 - 输出评分”的整条链路。9.2 强制模型给出证据链评审意见必须带有函数名和问题依据。如果模型只写“代码可读性较差”“建议优化性能”这类空泛内容应该在提示词阶段就尽量过滤。9.3 把单元测试作为二道防线LLM 评审可能漏掉逻辑问题但测试不会。建议把代码评审结论处理成待办项实际是否修复一定要靠单测或回归测试验证。示例def test_top_amount_returns_highest_total(): orders [ {id: a, amount: 1}, {id: b, amount: 3}, {id: c, amount: 2}, ] assert top_amount(orders, 2) 5这样即使评审说“可以合入”测试也会拦住实际问题。9.4 分层推进
LLM Code Review质量评测：如何识别表扬bug的评审结果
这次我们来看一个特别能说明问题的评测切入点同一段带有明确 bug 的代码分别交给不同的 LLM 做 code review最后把三份评审意见拉回源代码逐行打分。结果不一定是“模型越强评审越准”反而会出现一种很典型的现象——某份评审把问题代码夸了一遍却没有发现真正的缺陷。这种现象不能简单归结为“模型水平差”。更值得讨论的是我们到底应该怎么给 LLM code review 结果评级只看它有没有发现 bug 不够还要看它有没有误报、有没有给出可执行的修复方向、有没有在代码行为未被验证的情况下就给出“可以合入”的结论。这篇文章就用一个可控的最小复现案例拆开讲清楚评审质量的评分方法。如果你正在接 LLM code review 流程或者想把代码评审 Agent 做成一个可验收的内部工具这篇可以直接照着做。文章会包含四块内容一套可复现的评审样本设计、三段典型的 LLM 评审结果对比、一套“对照代码真相”的打分体系以及接入 CI/API 时需要注意的排查点。所有样例都是为了让读者能直接跑一个最小验证而不是只看结论。1. 核心课题LLM code review 的结果要先“再审”很多人测试 LLM code review 时习惯看模型输出文本是否流畅、有没有提到几个专业术语。这个验证方式在工程上是错的。评审结果是否合格不能靠阅读体验判断必须把它还原成三个问题代码里实际存在的缺陷评审有没有命中。评审提出的问题在代码里能不能找到对应证据。评审给出的修改建议是否能直接落地而不是绕圈子。否则就会出现标题里的情况一份评审写得态度很积极、结构很清晰但它赞美了一个会改变业务结果的 bug。如果评审流程只看“输出质量”这类结果就会被误判为高分。1.1 本次评测对象这次任务以“代码评审质量分级”为核心而不是跑一个超大模型做压测。评测对象可以用一句话描述同一个函数、同一份业务规则、同一个 diff交给 3 个不同模型分别做 code review由人来按代码真相打分。评测维度具体内容输入代码一个包含语义回归缺陷的 Python 函数业务规则明确要求返回金额最大的 N 条订单缺陷类型排序方向被改反导致结果从“取最大”变成“取最小”评审数量3 份独立评审最终评分方式对照已知缺陷、误报、建议可执行性进行人工判定这个场景很小但很适合做基准。因为代码缺陷和业务规则的冲突点非常具体函数明明要取金额前 N 大实现却用升序取前 N。LLM 如果只关注代码风格很容易给出“逻辑清晰、结构良好、可以合入”的错误结论。正是在这种边界清晰的场景里评审能力的差距才会暴露出来。1.2 为什么不能只关注“是否发现 bug”这里先给结论后面会用实际样例说明。“是否发现 bug”只是召回率的一部分。真正做评审打分还要看精确率模型提了 5 个问题其中几个是真问题几个是误报。证据链问题是否指向了具体函数、具体行、具体变量。业务理解模型是否把需求描述当作硬约束而不是只做代码风格分析。修复方向建议是“这里可能有风险”还是“应该改成 reverseTrue”。安全边界模型是否在自己不确定时给出了过于绝对的结论。所以本文的评分表不采用单一分数而是用一个分级表做最终判断。这样做的好处是当模型出现“没有发现明显问题”这种输出时不会被误认为合格。2. LLM code review 的失败模式表扬 bug在正式给样例前先说一下这类失败为什么会发生。LLM code review 常见翻车模式有三种。第一种是“表面合理性覆盖”模型看到代码变量命名清楚、函数结构不复杂、缩进整洁就会在摘要中给出正向评价。这种评价与代码实际行为无关却容易影响读者判断。代码评审不是作文批改代码整洁可以作为备注但不能替代逻辑正确性。第二种是“缺少执行语义验证”很多模型在阅读代码时并不会真正模拟多组输入输出。它更像是基于训练语料推断这段代码“可能是什么意思”。一旦代码的意图和实际业务规则出现细微偏差模型就可能顺着代码表面逻辑走而不是倒推业务规则。第三种是“权威语气误报”模型可能用很确定的语气说“这里会发生空指针”但实际上代码路径并不存在该问题。这种误报比漏报更隐蔽因为它会让开发者浪费时间排查一个根本不存在的缺陷甚至降低后续真实告警的可信度。这篇文章要搭建的评分方案就是针对这三种失败模式设计。我们最终会通过“把 review 结果与代码 ground truth 做差”来打分。3. 构造最小缺陷样本一段会误导评审的代码为了让 LLM code review 的对比可复现这里用一个很小的函数。重点不是函数复杂度而是业务规则分歧点必须足够清晰。3.1 业务规则系统需要计算“金额最高的 N 个订单总和”。这段逻辑被用于优惠券发放、对账报表等场景。输入是一个订单列表每个订单包含id和amount输出是最高的 N 个订单金额之和。3.2 缺陷代码下面这段代码是一份“重构后”的样本。旧版本用reverseTrue排序取前 N新版本为了“提升可读性”改成升序后直接取前 N。也就是把原逻辑取最大 N 个悄悄改成了取最小 N 个。def top_amount(orders, n): ascending sorted(orders, keylambda o: o[amount]) return sum(o[amount] for o in ascending[:n])如果输入数据为orders [ {id: a, amount: 1}, {id: b, amount: 3}, {id: c, amount: 2}, ]正确结果是金额最大的两个订单3 2 5。但上述代码返回的是金额最小的两个订单1 2 3。这就是“业务规则被悄悄反转”的 bug。3.3 配套的固定评审提示词为了让 3 个模型拿到一致的信息需要提供统一的任务描述。这里可以设计一份中性的评审提示词模板。注意不要在提示词里写“请找出所有 bug”因为这会诱导模型过度报告。更好的做法是让模型先理解业务规则再判断实现是否符合预期。你是一名资深代码评审工程师。下面有一段 Python 函数和它的业务规则请对这段代码进行 code review。 业务规则 传入一组订单列表 orders每个订单包含 id 和 amount。函数应返回金额最高的 n 个订单金额之和。 代码 def top_amount(orders, n): ascending sorted(orders, keylambda o: o[amount]) return sum(o[amount] for o in ascending[:n]) 请按以下格式输出 1. 总体结论通过 / 不通过 / 需要修改 2. 风险等级blocker / major / minor / nit 3. 问题明细给出函数名、问题描述、涉及变量、修复建议 4. 其他建议如果没有不要强行补充这个提示词把业务规则前置并要求模型按结构化字段输出。即便如此部分模型仍然可能因为函数代码不复杂而忽略排序方向问题。3.4 结构化输出协议如果要把评审结果接入下游流程可以要求模型输出 JSON。这里给出一个结构示例{ summary: 通过, findings: [ { severity: major, function: top_amount, issue: 排序方向与业务规则不一致, evidence: 使用升序排序后取前 n 个会返回金额最小的 n 个订单, suggestion: 排序时增加 reverseTrue或使用 sorted(..., reverseTrue) } ], false_positive_check: [] }结构化输出只是便于解析并不能保证内容正确。真正的质量把关仍然在“评审结果与已知缺陷的对照”这一步。4. 三份评审结果示例与分级下面给出三段具有代表性的评审结果样例。这三段样例代表了三种常见情况也可以直接拿去测试不同的 LLM API观察输出属于哪一类。4.1 评审一表扬了 bug 的评审第一份评审输出的文本风格是“总体积极、没有具体证据”。它可能会这样写该函数实现简洁变量命名清晰使用sorted对列表排序后取前 N 个元素逻辑正确。没有发现阻塞性问题建议合入。这份评审就是典型的高噪音输出。它做了三件错误的事情没有提到业务规则中“金额最高”这一限定条件。把排序方向完全忽略默认升序取前 N 就是正确逻辑。在没有任何测试案例或证据的情况下给出“可以合入”的结论。如果按 0 到 100 评分这份评审在“bug 召回”维度是 0 分。它甚至不是漏报而是用积极评价掩盖了问题。投入流水线后这种结果会让开发者跳过本应进行的边界检查。4.2 评审二命中缺陷但证据不够完整第二份评审有进步它会指出排序方向可疑但可能不会直接给出修复方式。例如当前实现使用升序排序取的是前 N 个元素。如果业务规则是返回金额最大的 N 笔订单这里的排序方向会导致结果错误。建议补充单元测试覆盖金额不等的订单列表确认排序方向是否符合预期。这份评审已经命中了核心 bug。它给出了原因分析并指出了业务规则冲突。不足之处在于修复建议不够“硬”没有直接给出reverseTrue或替代写法。如果团队里开发者对业务规则理解不深可能还需要二次沟通。这种评审可以评级为“及格偏上”。4.3 评审三命中缺陷并给出可执行修复第三份评审属于可以直接交给开发者的质量。它会这样写问题定位在top_amount。业务规则要求取金额最高的 N 笔订单但当前第 2 行ascending sorted(orders, keylambda o: o[amount])是升序排列第 3 行取出前 N 个后实际返回的是金额最低的 N 笔订单。 建议改为top_n sorted(orders, keylambda o: o[amount], reverseTrue)[:n]并补充用例当 orders [1, 3, 2]n 2 时期望结果为 5而不是 3。这份评审有三个特点命中真实缺陷。给出了具体代码补丁。补了可执行的测试样例。4.4 三份评审分级表评审是否发现缺陷是否给出证据是否给出修复方案是否误报评级评审一否否否无F表扬了 bug评审二是部分部分无B评审三是是是无A这个表格说明了一个问题同样一份代码LLM 评审质量可能从 F 到 A 都有。只看单个模型的一次输出很难判断模型能力必须结合任务规范和代码执行结果。5. 把 LLM 评审结果对照代码真相进行打分评分不能只靠“看起来对不对”。在一套可重复的评测流程里需要先定义 ground truth再写一个脚本把评审输出映射成可比较的指标。5.1 真实缺陷标签这里把缺陷标签定义为缺陷类型语义回归。所在函数top_amount。规则冲突排序方向错误导致取数范围错误。期望结果返回最大 N 个订单金额之和而非最小 N 个。5.2 用 Python 脚本做基础评分演示下面这段代码是一个最小演示脚本用于把“已知缺陷”与“评审文本”做简单匹配。实际生产中可以升级为对结构化 JSON 的字段判断而不是语义匹配。import json known_defects { sort_direction: 排序方向错误应该按 amount 降序取前 n } def evaluate_review(review_text): score 0 output { hit_known_defects: [], missed_defects: [], raw_score: 0.0, } if 升序 in review_text and (reverse in review_text or 降序 in review_text): output[hit_known_defects].append(sort_direction) score 60 else: output[missed_defects].append(sort_direction) if 测试 in review_text or 示例 in review_text: score 20 if 业务规则 in review_text or 金额最高 in review_text: score 20 output[raw_score] score return output review 当前排序方向可能有问题建议补充测试并确认业务规则 print(evaluate_review(review))这个脚本只是一个模板。真正生产使用的评分规则要把评论文本解析成结构化字段再与已知缺陷配置做映射。5.3 五个评分维度维度判断方式权重建议缺陷召回评审是否命中 ground truth 缺陷40%精确率评审提出的问题是否都是真问题20%可执行性是否给出具体修改方式和测试建议20%业务规则理解是否围绕“金额最大”等业务描述展开10%结果安全性是否在不确认时给出“可以合入”的结论10%缺陷召回权重最高是因为 code review 的第一目标就是拦住错误逻辑。如果模型在业务规则有硬约束的前提下仍然漏掉问题即使它写的意见再多也不能算合格。6. 接入 API 与批量评审的工程化思路如果只在网页对话框里测试 LLM code review无法形成稳定的质量反馈。真正要做的是把这段评审流程封装成 API 服务并支持批量的 diff 文件输入。6.1 通过 API 调用评审服务假设你已经有一个兼容 OpenAI 格式的本地或云端推理服务调用代码可以这样设计import requests def call_code_review_api(code_content, rules, api_urlhttp://127.0.0.1:8000/v1/chat/completions): payload { model: your-review-model, messages: [ { role: system, content: 你是一名严格的代码评审工程师。 }, { role: user, content: f业务规则{rules}\n代码\n{code_content} } ], temperature: 0.1, max_tokens: 1200, response_format: {type: json_object} } resp requests.post(api_url, jsonpayload, timeout180) resp.raise_for_status() return resp.json()注意几点温度建议调低。评审任务不适合发散输出。开启response_format可以拿到 JSON但不同服务支持程度不同需按实际接口调整。超时要设置得足够长代码长或上下文窗口紧凑时推理耗时可能明显增加。model字段要以你实际部署的模型名称为准不要照抄。6.2 批量评审任务的结构批量处理时不建议把多段代码塞进同一轮对话。更稳妥的方式是每个 patch 单独发送一次请求并把结果写入独立 JSON 文件。建议的目录结构review_task/ ├── patches/ │ ├── 001_fix_sort.json │ └── 002_fix_timeout.json ├── outputs/ │ ├── 001_fix_sort.review.json │ └── 002_fix_timeout.review.json └── logs/ └── review.logPython 批量任务框架可以这样写import json import pathlib patch_dir pathlib.Path(./patches) output_dir pathlib.Path(./outputs) output_dir.mkdir(exist_okTrue) for patch_file in patch_dir.glob(*.json): payload json.loads(patch_file.read_text(encodingutf-8)) review call_code_review_api( code_contentpayload[code], rulespayload[rules] ) out_path output_dir / f{patch_file.stem}.review.json out_path.write_text( json.dumps(review, ensure_asciiFalse, indent2), encodingutf-8 )批量任务必须保存原始请求、模型输出、打分结果三个部分。否则后面出现“某次评审质量差”的问题时很难回溯是提示词问题、模型问题还是代码本身问题。6.3 失败重试API 调用经常因为超时、限流、网络抖动失败。批量评审要加一个简单的重试函数import time def call_with_retry(*args, retries3, delay5, **kwargs): last_error None for attempt in range(retries): try: return call_code_review_api(*args, **kwargs) except Exception as exc: last_error exc time.sleep(delay * (attempt 1)) raise last_error重试是好习惯但不要无限重试。如果同一个 patch 连续失败 3 次应该先标记为失败而不是继续浪费时间和资源。7. LLM 资源占用与性能观察思路LLM code review 和图像生成、视频生成不同它没有特别夸张的显存需求但推理延迟和上下文长度仍然要关注。7.1 CPU 与 GPU 推理差异如果跑的是本地大模型CPU 推理可以做但速度会明显慢于 GPU。评审一段 200 行以内的代码CPU 推理可能需要等待几十秒到数分钟具体时间取决于模型大小和量化方式。GPU 推理通常更顺滑但显存占用仍要根据实际模型版本测试不能一概而论。如果团队只是小规模试用建议优先使用 API 服务减少本地部署维护成本。如果是私有化部署要求再考虑本地推理。7.2 上下文长度对性能的影响diff 文件越长模型需要处理的 token 越多推理耗时也越高。实践中有两个建议不要直接把巨大 MR 的全部 diff 一次性塞给模型。先做 diff 结构化拆分按文件或按函数分批评审。结构化拆分后单次评审的输入缩短输出质量通常会更稳定。把多次评审结果汇总后再由人做最终判定。7.3 可观察指标接入服务后至少记录这些指标指标说明单次请求耗时判断服务响应速度输入 token 数判断代码上下文长度输出 token 数判断评审篇幅超时次数判断服务稳定性缺陷命中数判断评审质量误报数判断输出可信度这些指标建议写入日志后续可以用来对比不同模型、不同提示词的效果。8. LLM code review 常见问题与排查方法问题现象可能原因排查方式解决方案评审输出“代码很好没有发现问题”但代码有明显 bug模型只做风格分析没有验证业务规则用多组输入输出案例反查模型在提示词中强制要求“必须给证据行”评审输出大量误报提示词诱导模型找 bug或温度过高检查提示词是否有负面引导降低 temperature增加业务规则描述评审没有围绕业务规则展开任务描述中业务规则不够醒目检查提示词结构把业务规则放在代码之前要求模型复述规则接口调用超时输入代码太长或模型推理慢查看日志中的输入 token 和时间拆分 diff分批评审增加超时时间批量任务中途卡住单条请求阻塞了队列检查是否缺少超时和重试增加timeout和失败标记模型给出修复建议但代码仍错误模型只给方向没有给完整补丁对比修复后输出引入单测作为验收门禁多模型结果差异大各模型指令遵循能力不同使用同一提示词跑同一代码用评分表给多模型建立基线这里要补充一个最容易踩的坑不要因为模型输出结构规范就认为评审内容可信。结构可以是正确的内容仍可能是在“自信地犯错”。尤其在 code review 场景里错误的结论比没有结论更危险。9. 最佳实践与使用建议从上面的样例可以看出LLM code review 真正能落地需要一套工程控制而不是单纯依赖模型能力。9.1 第一次先小参数验证不要一开始就接入全部代码仓库。可以先选一个包含历史缺陷的小项目跑通“代码 - 评审 - 对照真实缺陷 - 输出评分”的整条链路。9.2 强制模型给出证据链评审意见必须带有函数名和问题依据。如果模型只写“代码可读性较差”“建议优化性能”这类空泛内容应该在提示词阶段就尽量过滤。9.3 把单元测试作为二道防线LLM 评审可能漏掉逻辑问题但测试不会。建议把代码评审结论处理成待办项实际是否修复一定要靠单测或回归测试验证。示例def test_top_amount_returns_highest_total(): orders [ {id: a, amount: 1}, {id: b, amount: 3}, {id: c, amount: 2}, ] assert top_amount(orders, 2) 5这样即使评审说“可以合入”测试也会拦住实际问题。9.4 分层推进
