如果你是一个团队的代码评审者最近半年大概已经感受到某种微妙的变化提交上来的代码越来越多的部分看起来像是 AI 生成的。格式整齐、命名工整、注释完整但你在合并之前还是会卡一下——因为“好看”不等于“正确”更不等于“安全”。这个问题在 Hacker News 上被反复讨论当团队用 LLM 写代码、改代码、补测试之后代码评审流程到底会发生什么乐观的一方说AI 可以自动评审人彻底解放悲观的一方说AI 生成的海量代码会把评审拖垮。两种说法其实都没说到点子上。我的判断是LLM 不会让代码评审消失但会让代码评审的重心发生迁移。过去评审者主要靠“读代码找错”未来评审者的核心能力变成了“判断该相信哪一部分 AI 的判断”。这篇文章从流程变化、本质不变、工具接入、最小实现、验证方法、常见问题和工程建议七个角度把这个话题讲透。读完之后你可以回答三个问题LLM 到底改变了评审流程中的哪些环节如何在自己的仓库里接入一个可用的 LLM 自动评审人工评审的注意力究竟应该放在哪里1. 为什么代码评审流程需要把 LLM 当变量看代码评审一直是软件工程里的“质量闸门”。它的目标很朴素在代码进入主线之前尽早发现缺陷统一风格传递团队知识。这个目标过去已经够复杂因为人工评审有两大天然瓶颈一是注意力有限二是评审者的水平差异会直接影响质量。现在多了一个变量AI 已经把“生产代码”的速度往上提了一大截。使用 AI 编程助手之后一个开发者一天产出的 diff 量可能比以前多出数倍。产出变快了评审环节却往往还是原来的节奏。于是团队会卡在一个新的瓶颈上代码写出来了但没人审或者审不过来。很多团队因此开始尝试把 LLM 引入评审环节。大家期望的是AI 先把明显问题过滤掉人再看剩下的关键决策。理想很合理但落地时会出现三个误区我建议你先对照一下误区一LLM 评审可以直接替代人工评审。实际上AI 对业务上下文、历史决策、隐式团队规范一无所知它只能做“知识盲扫”。误区二LLM 评审就是给代码挑毛病。真正有价值的输出是“哪些变更存在风险哪些地方需要人工特别确认”而不是背一遍代码规范。误区三接一个 API、写一段 prompt 就能得到稳定可靠的评审结果。LLM 的输出稳定性、上下文长度、数据安全、误报率全是需要工程化解决的问题。所以这篇文章并不是告诉你“AI 评审很好用”而是帮你搞清楚在代码评审流程里LLM 能承担什么不能承担什么以及怎么把它放进去。2. 使用 LLM 之后评审流程哪些环节真的变了把 LLM 纳入评审流程后变化并不是“从人工到机器”这么简单。更准确的说法是评审流程从一条线性流水线变成了“人机协同的多级筛选”。比较典型的变化包括下面几个方面。2.1 覆盖面从“人读全部”到“AI 扫全部 人读关键”过去人工评审的理想状态是每行代码都看过但实际团队里代码量大、PR 频繁能做到重点函数精读已经很不容易。LLM 评审可以做到把每个文件都过一遍包括那些容易被人忽略的工具类、配置类文件。然后人工评审者再看 AI 标出的高危区域和核心业务逻辑。这个改变的实质是评审的下限被抬高了。以前可能会漏掉低活跃文件里的隐藏问题现在 AI 会把这些问题摆到明面上人工只需要判断真伪。2.2 反馈速度从“约时间看”到“提交即有初步报告”传统评审的等待时间取决于评审人什么时候有空。很多团队里一个 PR 挂两天是常态。LLM 评审工具可以在代码提交后的几分钟内生成初步意见作者可以先改一轮再请人工评审进入。这里要注意速度快是好事情但不能让“AI 已经审过”变成“不用再约人工评审”的理由。速度快只是把低级错误提前暴露不能抵消架构判断、业务对齐的需求。2.3 反馈风格从“指令式”到“建议式”人工评审容易出现一种情况评审者的说话方式比较直接比如“这个变量命名不对”“这样写有 bug”。而目前主流 LLM 评审输出更偏向“建议式”它会给出问题描述、影响程度和修改方向。建议式反馈对新人更友好但也容易让作者误以为所有意见都可选。所以实践中需要给 LLM 评审设定严重级别比如 critical、warning、suggestion让作者知道哪些必须改哪些可以商榷。2.4 新增环节变更摘要与风险雷达传统评审流程里评审者打开 diff 后要从零开始理解这次改动的目的。LLM 的另一个价值是把 diff 转成一份简短的变更摘要说明改动涉及哪些模块、主要影响范围、潜在风险点。这等于给评审者配了一个“导读员”。实际使用中很多团队是先让 LLM 生成摘要人工评审读摘要、再按风险点抽样读代码效率提升比单纯挑错更明显。2.5 旧的环节还在但变得更吃上下文既然 AI 可以辅助评审那评审者需要提供的上下文就变得很重要。比如 PR 描述是否清晰、有没有关联工单、数据库变更是否说明兼容性。对这些信息人工评审者以前是“顺便看一眼”现在则必须意识到LLM 评审质量高度依赖 prompt 与上下文描述写得越清楚AI 意见越准。下面用一个表格对比传统评审与 LLM 辅助评审的核心差异。维度传统人工评审人工 LLM 辅助评审代码覆盖依赖评审人精力AI 全量扫描人工聚焦高优先区域反馈时延取决于评审人时间提交后分钟级产出初步报告上下文理解能结合业务与团队历史基本只能依赖本次 diff 与描述知识传递评审过程本身是团队学习机会知识传递仍要依赖人工评审留言与讨论可靠性低误报但可能漏看漏看较少但会产生幻觉与误报责任归属明确由评审人合入最终仍由人工评审人负责表格背后是一个小结论LLM 改变的是“发现问题的效率”并没有改变“决定是否通过的权力”。这一点必须首先达成共识后面所有接入方式才有讨论基础。3. 但代码评审的本质并没有变很多人以为流程变复杂是因为工具变了其实复杂的是分工边界。代码评审的本质仍然是确保合入代码满足质量、安全、业务目标和团队共识。这四条里LLM 目前只能可靠地覆盖质量与部分安全问题。3.1 安全与合规判断不能交给模型LLM 可以识别常见的注入写法、硬编码密钥、弱密码算法但它无法判断你的系统信任边界在哪里也无法理解“这条数据在监管上是否允许出域”。安全评审里真正困难的部分是理解攻击面与业务风险的组合关系。这仍然需要安全负责人和技术负责人决策。3.2 架构与业务上下文只能由人提供AI 看到的是 diffs 和上下文文本看不到上次架构决策会议上的争论也看不到某个看似笨拙的实现是为了兼容老系统。代码评审里有一类经典问题是“为什么这么写”这类问题只有人在才能回答。3.3 AI 幻觉会带来新的评审成本LLM 评审会生成看起来非常专业的意见但偶尔会指向一个不存在的函数、一个错误行号或者把“可能存在问题”放大成“存在严重漏洞”。这就是 AI 幻觉的具象化。你不检查这些意见就会被带偏每条都检查又回到了人工全读的老路。所以更稳妥的做法是把 LLM 评审报告当作“线索”而不是“结论”。人工评审者拿到报告后围绕 critical 问题做交叉确认而不是直接复制到 PR 评论里。3.4 责任主体仍然是人合规审计、紧急事故复盘、客户索赔最终被追责的一定是合入代码的人和审批的人。AI 只是辅助判断它不会为错误合入承担责任。这个责任边界比任何 prompt 技巧都重要。团队里只要有人把 AI 意见当盖章就迟早会在生产环境里交学费。4. 把 LLM 接入代码评审流程的四种主流方式不同团队的规模、代码仓库情况、对数据安全的要求都不一样所以接入方式也不是只有一种。下面按使用场景拆开讲你可以根据实际情况选择。4.1 方式一IDE 插件与本地辅助检查这种方式最轻量。开发者在 IDE 里启用 AI 插件写完代码先让 AI 在本地做一轮检查再提交。好处是反馈即时坏处是缺少团队级统一标准每个成员的插件配置可能不同导致质量参差不齐。适合人群个人项目、小团队团队规范还没固化、暂时不想改 CI 流程的场景。4.2 方式二pre-commit 钩子做快速预检pre-commit 钩子一般在代码提交之前运行适合执行快速检查格式化、静态分析、敏感信息扫描。也可以挂一个轻量 prompt让 LLM 在本地对暂存区代码做基础的 bug 预检。需要注意的是代码评审本身不适合放在 pre-commit 阶段因为 LLM 调用耗时、不稳定会打断开发节奏。更合理的是把“快速预检”和“正式评审”分开。pre-commit 只做门槛真正的评审放在 PR 阶段。4.3 方式三PR 级自动化评审目前最有价值、也最值得落地的是在 CI 里加一个 PR 评审任务。当开发者提交或更新 PR 时自动化流程导出 diff调用 LLM API把生成的评审意见回帖到 PR 或 GitLab MR 上。这种方式的优势是统一、可审计、不依赖单个开发者的 IDE 配置。团队可以约定一个标准 prompt 和输出格式确保每次评审都围绕同一组检查清单。4.4 方式四评审辅助工具与变更摘要有些团队并不希望 AI 直接在 PR 下面评论因为噪音太多。他们更想要的是AI 在人工评审前先产出一份“变更影响说明”列出关键文件、风险点、测试建议。人工评审者沿着这份摘要读代码再补充自己的意见。如果团队刚引入 AI 评审这种方式的接受度通常最高因为人对 AI 的判断还不太信任时让他用 AI 提供的导航信息比自己硬读更容易建立信任。无论是哪种接入方式建议都从低风险仓库开始试点。先把流程跑顺观察意见质量再逐步推广到核心业务仓库。5 完整示例搭建一个 PR 自动评审流程下面用一个最小可用方案演示如何把 LLM 接入 PR 评审。这个示例包含三部分一个调用 LLM API 生成评审报告的 Python 脚本、一个 GitHub Actions 工作流、一组可选的本机 pre-commit 配置。示例用了通用的 API 调用方式服务商地址用api.example.com占位你可以替换为自己实际使用的模型服务地址。版本与模型名建议查服务商最新文档。5.1 Python 脚本生成 Markdown 评审报告文件路径scripts/llm_review.py。# scripts/llm_review.py PR 自动评审脚本 用法示例: python scripts/llm_review.py --pr 123 --model gpt-4o-mini import argparse import json import os from urllib import request def collect_changes(pr_number: int) - str: 读取本地导出的 PR diffs 文件 diff_file fpr_{pr_number}.diff if not os.path.exists(diff_file): raise FileNotFoundError(f请先导出 PR 的 diff 到 {diff_file}) with open(diff_file, r, encodingutf-8) as f: return f.read() def build_prompt(diff: str): system_prompt ( 你是一名资深软件工程师负责代码评审。\n 请对下面的代码变更输出评审意见。\n 只关注明确的缺陷、并发与边界条件、安全问题、风格一致性和缺失的测试。\n 不要给出泛泛的改进建议。每条意见必须包含\n 1. 严重程度critical / warning / suggestion\n 2. 问题所在文件或位置\n 3. 问题描述\n 4. 可执行的修改建议\n ) user_prompt f代码变更内容如下\n\n{diff[:20000]} return system_prompt, user_prompt def call_llm(system_prompt: str, user_prompt: str, model: str) - str: 调用 LLM 接口真实环境请替换为服务商地址 api_key os.environ[LLM_API_KEY] req request.Request( https://api.example.com/v1/chat/completions, datajson.dumps({ model: model, messages: [ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], temperature: 0.2, }).encode(utf-8), headers{ Content-Type: application/json, Authorization: fBearer {api_key}, }, methodPOST, ) with request.urlopen(req, timeout60) as resp: body json.loads(resp.read().decode(utf-8)) return body[choices][0][message][content] def main() - None: parser argparse.ArgumentParser() parser.add_argument(--pr, typeint, requiredTrue) parser.add_argument(--model, defaultgpt-4o-mini) args parser.parse_args() diff collect_changes(args.pr) system_prompt, user_prompt build_prompt(diff) print(正在调用 LLM 生成评审意见...) result call_llm(system_prompt, user_prompt, args.model) report_path fpr_{args.pr}_review.md with open(report_path, w, encodingutf-8) as f: f.write(result) print(f评审报告已生成: {report_path}) if __name__ __main__: main()脚本的逻辑并不复杂读取 diff构建评审 prompt调用 LLM把输出结果保存成 Markdown 文件。关键点是 prompt 里明确约束了评审范围和输出格式否则模型很容易输出一堆“代码可以更优雅”的空话。5.2 GitHub Actions 工作流提交 PR 后自动评审文件路径.github/workflows/llm-review.yml。name: LLM Code Review on: pull_request: types: [opened, synchronize] permissions: contents: read pull-requests: write jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-pythonv5 with: python-version: 3.11 - name: Export PR diff run: | gh pr diff ${{ github.event.pull_request.number }} pr_${{ github.event.pull_request.number }}.diff env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} - name: Run LLM review run: | python scripts/llm_review.py --pr ${{ github.event.pull_request.number }} env: LLM_API_KEY: ${{ secrets.LLM_API_KEY }} - name: Upload review report uses: actions/upload-artifactv4 with: name: review-report path: pr_${{ github.event.pull_request.number }}_review.md - name: Post comment to PR run: | gh pr comment ${{ github.event.pull_request.number }} --body-file pr_${{ github.event.pull_request.number }}_review.md env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}使用这个工作流时需要提前在 GitHub 仓库配置两个变量LLM_API_KEY用于调用模型服务GITHUB_TOKEN是 GitHub Actions 自动带的不需要额外创建。还有一个要注意的地方工作流默认只在pull_request的 opened 和 synchronize 时间触发。如果你想让它也在 PR 转成 ready 评审时执行可以再加上ready_for_review类型。5.3 pre-commit 配置提交前的轻量预检如果只做非常轻量的本地预检可以在仓库里加一个.pre-commit-config.yaml挂在本地脚本上# .pre-commit-config.yaml repos: - repo: local hooks: - id: llm-quick-review name: LLM quick review entry: python scripts/quick_review.py language: system types: [python]quick_review.py可以是一个比 PR 评审脚本更简单的版本只检查当前暂存的 Python 文件把可疑问题打印出来提醒开发者但不阻塞提交。这里需要想清楚pre-commit 中如果在网络请求失败时直接退出非零反而会打断开发流程所以更稳妥的做法是“有提示但不阻断”把硬性阻断留给 CI 里的正式评审。这个组合的意思是本地钩子负责尽早提醒CI 评审负责出正式报告人工评审负责人最后拍板。6. 如何验证 LLM 评审真的对流程有帮助接入了工具不意味着流程变好了。没有指标支撑的“体验不错”不算数。我建议团队至少关注下面几类数据。6.1 评审意见采纳率统计 PR 评论中有多少条最终被作者接受并修改。如果 AI 评审意见的采纳率低于三成要么 prompt 和场景不匹配要么模型能力不足要么输出噪音过多。这个指标可以每周手动抽样统计不必做得很复杂。6.2 第一次合入通过率原来一个 PR 要经过多轮人工评审现在先用 AI 预审低级问题提前改完人工评审的第一轮意见自然减少。对比引入 LLM 前后的人工 review 轮次能比较直观地看出流程变化。6.3 缺陷漏出率这个指标需要结合生产环境或测试阶段发现的 bug 来看。比如在严格要求“评审后必须合入”的前提下漏到测试阶段或生产环境的缺陷数量是否下降。这里不要只看绝对数量还要考虑业务变化最简单的方式是选两个没有业务波动的季度做横向对比。6.4 人工评审有效时长给人工评审人发问卷或者通过代码托管平台 API 拉评审耗时数据。通常 AI 预审能把“逐行通读”的时间压缩掉一部分但压缩下来的时间应转移到“对关键路径和安全性的人工确认”上而不是让评审者更快地点击通过。建议先以两周为周期做试点同时收集定性反馈评审者觉得 AI 报告哪类信息最有用哪类最浪费时间这个信息比任何指标都更能指导 prompt 迭代。7. 常见问题与排查思路在实际接入过程中团队遇到最多的问题集中在下面几类。这里按“现象、原因、排查、解决”的方式做一个参考表。问题现象可能原因排查方式解决方案API 调用超时diff 太大单次请求超过模型上下文限制查看 CI 日志中超时位置按文件拆分 diff先读路径列表再分批评审评审意见太泛泛prompt 缺少检查清单和格式约束抽样多份报告看重复度在 prompt 中指定输出字段和禁止事项幻觉意见指向不存在的行号模型无法准确对齐 diff 行号对照报告与源文件验证定位改用统一 diff 格式并要求模型引用文件路径大量噪音评论temperature 设置过高或模型版本不稳定检查参数配置将 temperature 调低到 0 到 0.2固定模型版本把敏感代码发到外部 API仓库存在私有代码或密钥文件检查扫描文件清单在 workflow 中用路径过滤敏感文件走私有化部署AI 报告被直接复制成评审结论团队未约定 AI 报告只是参考人工评审是否仍然给出自己的意见约定仅 critical 级意见可作为合并拦截条件这里特别提一个真实工程里的场景AI 对一段看似正常的subprocess调用没有报错因为它的目标只是检查风格和逻辑。但实际这段代码把用户输入传给了 shell 命令存在明显的注入风险。最终拦截下来的不是 AI而是人工评审者对“外部输入不可信”这一原则的把关。这个例子恰好说明LLM 评审的定位永远是辅助而不是兜底。8. 最佳实践与工程建议8.1 分层评审让 AI 做第一层人做第二层建议把评审分成两层。第一层由 LLM 自动完成覆盖风格、边界条件、常用安全缺陷、单测缺失。第二层由人工评审完成聚焦架构合理性、业务逻辑、数据一致性、扩展性和团队知识传递。这样做的核心价值是让人从重复劳动里腾出精力做模型不擅长的工作。不要把两层混在一起会让 AI 意见干扰人工判断。8.2 最小权限与数据安全接入外部 LLM API 时务必检查仓库中有没有密钥、内网地址、客户信息等敏感内容。可以在 workflow 里配置过滤规则只允许非敏感路径参与 AI 评审。如果仓库本身需要高保密建议使用私有化部署的模型服务而不是默认走公共 API。另外LLM_API_KEY这类密钥不要直接写在 yaml 里用 GitHub Secrets 或 GitLab CI 变量统一管理。8.3 prompt 与团队规范对齐每个团队对代码风格、测试方案、安全要求的侧重点不同。与其套用通用评审 prompt不如把团队规范里最看重的几条直接写进 prompt。比如“必须检查事务是否回滚”“禁止在控制器层处理业务逻辑”。这样的 AI 评审才真正像团队的一员而不是一个只会背教科书的外部专家。8.4 固定模型版本与输出格式模型版本升级通常会改变输出风格甚至影响准确率。可以在 workflow 中固定model参数让评审报告在可预期范围内稳定输出。同时要求模型输出结构化文本比如 Markdown 或 JSON方便后续自动解析和统计。8.5 不要把 AI 评审变成合入阻塞条件比较危险的做法是CI 里跑了 LLM 评审只要 AI 给出负面意见就阻止合并。原因是模型会误报误报阻塞会直接让团队对流程失去信任。更稳妥的做法是AI 意见默认以“评论”形式呈现只有团队提前商定的高危场景如检测到硬编码密钥、危险函数调用才尝试接入阻塞逻辑。8.6 定期抽查评审质量持续迭代接入不是一劳永逸。每隔一段时间从历史评审报告里抽查样本把“AI 打错了”“AI 漏了”和“AI 有效”的案例都整理出来反向优化 prompt、检查清单和过滤规则。这本质上是在维护一个团队的评审质量数据闭环。9. 总结代码评审的未来是人机分工如果只记住一句话那就是LLM 让评审流程从“人找问题”变成了“人找重要问题”。它能用极低的成本覆盖每个文件能在几秒钟内产出一份相当专业的初步意见也能在新的代码格局里帮你提前发现大量低级缺陷。但同时它也把更多责任压在了人工评审者的判断力上。业务上下文、安全边界、架构取舍、团队知识的沉淀所有这些没有被模型替代的部分反而因为 AI 的介入而变得更加重要。一个只会签名通过的人被一套“看起来很可靠的 AI 报告”推着走风险只会更高。我建议你的下一步非常具体选一个低风险的工具仓库先只跑变更摘要和风险预检让团队习惯 AI 报告的语言风格和误报率。连续跑两到三周再决定是否把明细评审意见自动挂到 PR 上。关键是让团队明确一个约定——AI 负责扫雷人负责决定要不要继续前进。当你把这一点想清楚了代码评审流程无论接入什么模型都不会跑偏。
