用大模型做代码评审：从提示词设计到落地检查清单

大模型进入代码评审流程已经不是新鲜事。很多团队的做法是把一段 diff 贴给模型，让它“帮忙看看有没有问题”，然后把输出原样贴回评审意见里。这样做效率看似提高了，实际效果却很不稳定：有时模型能指出真实的边界条件遗漏，有时又会纠结于风格细节，甚至对一段完全正确的代码给出错误的“修复建议”。问题不在模型本身，而在使用方式上：评审是一项有目标、有上下文、有责任边界的工作，提示词、输入范围和复核流程都需要事先设计好。

一、大模型适合做什么，不适合做什么

先把定位说清楚，大模型评审才能用对地方。

它比较擅长的事情有三类。第一是“找茬式”的局部检查：空指针、越界、下标错误、资源未关闭、异常分支缺失、并发下的共享状态、SQL 拼接、日志里打印敏感字段，这类问题有比较固定的模式，模型识别起来相对可靠。第二是可读性建议：命名是否表意、函数是否过长、重复逻辑是否可以抽取、注释与实现是否一致。第三是给出多角度的提问：这段代码如果输入为空会怎样？如果并发调用会怎样？如果依赖服务超时会怎样？这些问题本身就有价值，哪怕模型给出的答案不完全正确，也能提醒评审人去验证。

它不擅长的事情同样要心中有数。模型看不到完整的业务背景，不知道这个接口的历史兼容性约束，也判断不了“这个折中方案是当时权衡后的选择”。它对大型重构的理解常常是局部的，容易把一次有意的架构取舍当成错误；对性能的判断也多是定性推测，缺少真实的压测数据支撑。更关键的是，模型不会为评审结论负责——最终合并代码、承担线上风险的仍然是人。

所以一个可行的定位是：大模型是评审的“第一遍筛查员”和“提问者”，不是“终审法官”。人工评审仍然负责业务正确性、架构合理性和最终决策。

二、提示词怎么写：给模型一个明确的评审任务

直接说“帮我评审这段代码”，得到的多半是泛泛而谈。好的评审提示词通常包含五个要素：角色、范围、背景、输出格式和约束。

角色要具体，不要只写“你是一名资深工程师”。可以写成“你是一名负责后端服务评审的工程师，重点关注正确性、健壮性和安全性，风格问题只在影响可读性时才提”。范围要限定：是只审本次 diff，还是连同相关调用方一起审；只审新增代码，还是也审被修改的旧逻辑。背景要给足最小必要信息：这是什么服务、这个函数的输入来源、调用方是谁、有哪些已知约束，例如“该接口需要兼容旧版本客户端，字段不能删除，只能新增”。

输出格式是最容易被忽视的一环。如果不做约束，模型会输出一大段散文式点评，评审人很难逐条处理。建议要求模型按固定结构输出，例如：问题列表（每条包含位置、问题描述、严重程度、建议修改方式）、存疑点（需要人工确认的问题）、通过项（明确表示检查过但没有发现问题的维度）。同时要求它“只对本次 diff 中的代码发表意见，不要评价未修改的文件；不确定的问题标注为存疑，不要编造结论”。

下面是一个可以直接套用的提示词模板：

你是一名后端代码评审员，评审语言为 Java，重点关注正确性、健壮性与安全性。
本次评审范围：以下 diff 中的新增与修改代码，不评价未改动的文件。
背景：该方法是订单查询接口的内部实现，输入来自上游服务调用，调用方可能传入空列表；接口需兼容旧版本客户端。
请按以下格式输出：
1. 问题列表：文件与行号、问题描述、严重程度（高/中/低）、建议修改方式；
2. 存疑点：你无法确认、需要人工核实的问题；
3. 已检查无问题的维度：简要列出。
约束：不要评价代码风格细节；不要推测没有依据的业务逻辑；不确定的内容必须标注为存疑。
[在此处粘贴 diff 或代码片段]

模板的价值不在于文字本身，而在于每次评审都用同一套结构。这样团队可以横向比较不同评审的输出质量，也能逐步发现哪些提示词写法容易产生误报，再把它写进团队的评审规范里。

三、评审维度的检查清单

只靠提示词还不够，评审维度的清单决定了检查是否全面。下面是一份按维度整理的清单，评审时可以逐项对照，也可以把它写进提示词里，要求模型按维度逐项给出结论。

使用这份清单时有一个技巧：不要让模型一次性检查所有维度。diff 较小时可以全量检查，diff 较大时按维度分轮检查，例如第一轮只查正确性与健壮性，第二轮只查安全与性能。分轮检查有两个好处：一是模型注意力更集中，误报更少；二是输出更容易逐条处理，评审人可以按维度分配复核精力。

四、落地流程：从 diff 到可执行的评审意见

一套可落地的流程，大致可以分为四步。

第一步是准备输入。先把 diff 控制在可评审的规模内，一个合并请求尽量只做一件事，超过几百行就拆分。把与本次改动相关的上下文一并提供：接口定义、调用方、相关配置、对应的测试用例。只给模型一段孤立的代码片段，它只能做语法层面的检查，给不出有业务价值的意见。

第二步是分层筛查。先跑静态检查与单元测试，把格式、空指针提示、明显的安全规则问题交给工具处理；再把 diff 交给大模型做语义层面的筛查；最后由人工评审做业务与架构判断。三层各司其职，不要让模型去做工具已经能做好的事，也不要让人去重复模型已经筛查过的基础问题。

第三步是人工复核与分级。模型输出的每一条意见都要经过人工确认，按严重程度分级处理：高严重程度的问题必须修改并补充测试；中严重程度的问题由作者与评审人商定是否本次修改；低严重程度的问题可以记录下来，作为后续重构的待办。无法确认的“存疑点”不要直接忽略，要写清楚需要向谁确认、用什么方式验证，例如补充一个测试用例或查一次线上日志。

第四步是沉淀与复盘。把模型经常误报的问题、团队反复出现的同类问题记录下来，更新到提示词模板和检查清单里。例如模型多次把某个业务上刻意的兼容写法误判为问题，就在提示词的背景里补充这条约束；团队多次出现“重试没有上限”的问题，就把这一项写进合并请求的自查清单。评审流程本身也需要持续评审。

五、人工复核的边界：哪些结论必须由人来定

有三类结论，大模型不能代劳。

第一类是业务正确性。模型不知道“这个字段为 0 时代表未设置还是代表关闭”，也不知道“这个接口的调用方是否已经做了前置校验”。涉及业务语义、数据口径、兼容性承诺的判断，必须由熟悉业务的人确认。

第二类是架构取舍。是否引入新的依赖、是否拆分服务、是否接受一定的重复以换取解耦，这些都是权衡问题，没有唯一正确答案。模型可以列出不同方案的利弊，但选择哪一种、承担什么代价，需要人来决策并留下记录。

第三类是风险定级与上线决策。一段代码的风险不仅取决于代码本身，还取决于它影响的用户范围、回滚成本、监控是否到位。模型看不到这些信息，它的严重程度分级只能作为参考，最终的上线判断必须由人结合发布计划与应急预案来做。

一个实用的判断标准是：如果一条评审意见需要业务知识、需要跨系统信息、或者涉及“要不要改”而不是“怎么改”，那它就必须经过人工复核。反之，纯局部的、可验证的、可通过测试复现的问题，可以更多地交给模型与工具。

六、不要把敏感信息交给外部模型

这是使用大模型做评审时最容易被忽视的风险。代码里常常藏着真实的敏感信息：数据库连接串、AK/SK、内部服务地址、客户姓名与联系方式、真实订单数据、未公开的业务规则。把这些内容原样发给外部模型，相当于把内部资产交给了不可控的第三方。

可行的处理方式有几条。第一是先做脱敏再提交：替换真实的密钥、Token、内网地址、用户个人信息，用占位符代替，例如把真实手机号替换为 138****0000，把真实密钥替换为 <REDACTED>。第二是控制提交范围：只提交本次 diff 的最小必要片段，不提交整个仓库、不提交配置文件、不提交包含真实数据的测试文件。第三是优先使用团队内部合规的模型服务或私有化部署，明确数据不用于训练、不留存，外部通用模型只用于不含敏感信息的通用代码片段。第四是建立事前检查：提交前用密钥扫描工具扫一遍待提交内容，确认没有密钥与真实用户信息；评审完成后不把模型输出的完整记录随意转发到外部渠道。

如果一段代码脱敏后就失去了评审价值，例如问题本身就出在配置或数据处理逻辑上，那就不要用外部模型评审它，改用人工评审或内部工具。安全边界不是流程的点缀，而是前置条件。

七、结语：一份可以直接用的落地检查清单

把上面的内容收敛成一份清单，团队可以直接贴在评审规范里：

1. 合并请求是否足够小、只做一件事，diff 是否在可评审规模内；
2. 提示词是否写清了角色、范围、背景、输出格式与约束；
3. 是否按正确性、健壮性、并发、安全性、性能、可维护性、兼容性逐项检查；
4. 静态检查与单元测试是否先行，模型评审是否只做语义筛查；
5. 模型输出是否逐条经过人工确认，并按高/中/低分级处理；
6. 存疑点是否明确了确认人与验证方式，而不是直接忽略；
7. 提交给外部模型的内容是否已经脱敏，是否排除了密钥与真实用户信息；
8. 本次评审发现的共性问题，是否更新到了提示词模板与检查清单里。

大模型不会替代代码评审，但它可以让评审更全面、更稳定。前提是把提示词、检查清单、复核流程和安全边界都设计好，让模型做它擅长的事，让人做必须由人做的判断。这样，评审效率的提升才不会以质量与安全为代价。