1. 为什么我把 Code Review 交给了 AI 来打辅助做开发十来年Code Review 这件事我经历过好几个阶段。最早是团队里几个人互相看后来是强制 PR 必须至少一个人 Approve 才能合并再后来上了 CI跑 lint、跑单测、跑静态扫描。工具越来越多流程越来越长但有个问题一直没解决真正有价值的评审意见往往取决于评审人当天的心情、状态和手头忙不忙。我见过太多 PR 挂了两三天没人理也见过有人为了赶进度直接给自己点 Approve。更常见的情况是评审人只看了 diff 的前两百行后面几百行扫一眼就过了。这不是态度问题是人的注意力本来就有限。一个 PR 改动十几个文件、上千行代码指望人逐行看完还能给出高质量意见不现实。所以当我开始把 AI 引入 Code Review 流程时出发点很朴素让机器先过一遍把人从重复劳动里解放出来专注在真正需要判断力的地方。这篇内容就是我这段时间折腾下来的完整总结包括整体思路、工具选型、实操步骤、踩过的坑以及我目前稳定在用的方案。适合正在搭 CI 流程的团队、想提升 PR 质量的个人开发者以及任何对 AI 辅助研发流程感兴趣的人。需要先说明一点AI 做 Code Review 不是要替代人而是做第一层过滤。它能干掉大量低级问题让人只看值得看的部分。这个定位想清楚了后面的方案设计才不会跑偏。2. 整体设计与思路拆解2.1 先想清楚AI 评审到底该管什么很多人一上来就想让 AI 把整个 PR 从头到尾评一遍结果要么是意见太多没人看要么是废话一堆没重点。我的做法是先给 AI 划定职责边界把评审内容分成三类机器该管的代码风格、命名规范、明显的空指针风险、未使用的变量、重复代码、日志打印残留、硬编码密钥、SQL 拼接风险。这些有明确规则AI 判断准确率高误报率低。机器辅助人管的业务逻辑是否合理、边界条件是否覆盖、异常处理是否完整、接口设计是否一致。AI 可以给出提示但最终判断交给人。机器不该管的架构决策、技术选型、团队约定背后的历史原因。这些需要上下文AI 看不到全貌强行让它评只会添乱。这个分类直接决定了后面 prompt 怎么写、CI 怎么配。我见过有人把 AI 评审配成每个 PR 必须解决所有 AI 意见才能合并结果团队怨声载道因为 AI 连这个变量名不够好都要卡一次。评审意见要分级阻断性问题和建议性问题必须分开。2.2 方案选型为什么我最终选了CI 触发 分级评论市面上做 AI Code Review 的路子大概有这么几种我挨个试过方案优点缺点我的评价IDE 插件实时提示反馈快写代码时就能看到只覆盖本地改动看不到 PR 全貌团队无法统一适合个人不适合团队流程本地脚本手动跑灵活想跑就跑依赖个人习惯容易漏无法强制过渡方案CI 自动触发 PR 评论强制、统一、可追溯配置成本高需要调 prompt最终选择独立评审平台功能全报表好看数据出域成本高定制难大团队可以考虑我最终选 CI 触发核心原因是它把评审变成了流程的一部分而不是靠自觉。PR 一提交CI 自动跑 AI 评审结果以评论形式贴回 PR谁都能看到。这样既保证了覆盖率又留下了记录后面复盘也有据可查。至于为什么用分级评论而不是一次性贴一大段是因为我踩过坑。最早我把 AI 输出直接整段贴上去结果评论又长又密评审人根本不想看。后来改成按严重程度分三档阻断必须改、警告建议改、提示仅供参考每档用不同标记评审人一眼就能抓住重点。2.3 数据流设计从 PR 到评论的完整链路整个链路我画过好几版最后稳定下来的流程是这样的开发者提交 PR触发 CI。CI 拉取本次 PR 的 diff只取变更部分不取全量代码。对 diff 做预处理过滤掉二进制文件、锁文件、自动生成的代码。按文件或按 hunk 切分分批送给 AI 模型。AI 返回结构化结果JSON 格式包含文件、行号、严重级别、意见内容。CI 脚本解析结果去重、排序按级别生成评论。通过平台 API 把评论贴回 PR。如果存在阻断级问题CI 标记为失败阻止合并。这个链路里有两个关键设计点值得展开说。第一只送 diff 不送全量。原因很简单全量代码太大token 成本高而且 AI 容易被无关代码干扰。但只送 diff 有个问题——AI 看不到上下文可能误判。我的解决办法是在 prompt 里附上变更文件的完整内容作为参考但明确告诉 AI只评审 diff 部分。这样既控制了成本又给了足够上下文。第二结构化输出。早期我让 AI 直接输出自然语言结果解析起来很痛苦格式每次都不一样。后来强制要求 JSON 输出并在 prompt 里给出 schema 示例稳定性大幅提升。下面是我用的 schema{ file: src/main/java/com/example/UserService.java, line: 42, severity: blocker, category: null-safety, message: user.getAddress() 可能返回 null后续调用 getCity() 会抛 NPE, suggestion: 建议先判空或使用 Optional }这个结构后面解析、去重、排序都方便强烈建议一开始就定好。3. 核心细节解析与实操要点3.1 Prompt 设计决定评审质量的关键AI 评审效果好不好八成看 prompt。我前后改了十几版总结出几个必须包含的要素角色设定要具体。不要写你是一个代码评审员太泛。我现在的写法是你是一名有十年经验的 Java 后端工程师熟悉 Spring 生态注重代码健壮性和可维护性评审风格直接、务实只指出真正重要的问题。角色越具体输出越贴合预期。评审范围要明确。我会在 prompt 里列出本次评审关注的维度比如空指针风险、资源泄漏、并发问题、异常处理、日志规范、SQL 注入、硬编码。不关注的维度也列出来比如代码风格交给 lint、命名交给团队规范。这样 AI 不会越界。输出格式要强制。前面说的 JSON schema 必须写进 prompt并且给出正例和反例。我还会加一句如果某个文件没有问题不要输出该文件的任何内容。避免 AI 为了凑数硬编意见。严重级别定义要清晰。我在 prompt 里明确定义三档blocker会导致运行时错误、数据丢失、安全问题必须修复。warning可能导致问题、违反最佳实践建议修复。info可选优化不影响功能。定义清楚后AI 分级准确率明显提升。3.2 分批策略大 PR 怎么处理一个 PR 改动几百行甚至上千行是常事直接整段送进去模型要么超 token 限制要么注意力分散导致漏检。我的分批策略是这样的按文件分组单个文件超过 500 行 diff 的按 hunk 再切。每批控制在 2000 token 以内diff 部分加上上下文不超过 4000 token。批与批之间独立评审最后合并结果。合并时按文件和行号去重同一位置多条意见只保留最高级别的。这里有个细节跨文件的关联问题容易被漏掉。比如 A 文件改了接口签名B 文件还在用旧签名。分批评审时AI 看不到这种跨文件问题。我的补充办法是在最后加一轮全局检查只送变更文件的接口定义和调用点专门查这类问题。虽然多花一点成本但能抓到不少真实 bug。3.3 误报控制怎么让团队不反感AI 评审最大的敌人不是漏报是误报。误报多了团队就会无视所有 AI 意见整个流程就废了。我用了几个手段控制误报第一白名单机制。某些文件或目录不参与 AI 评审比如自动生成的代码、第三方库拷贝、测试 fixture。这些地方 AI 容易误判直接跳过。第二历史反馈学习。我在 CI 脚本里加了一个简单的反馈收集如果评审人把某条 AI 意见标记为无效就记录下来。积累到一定量后分析这些无效意见的模式反过来优化 prompt。比如发现 AI 老是把某种写法误判为空指针风险就在 prompt 里明确排除这种情况。第三阈值控制。info 级别的意见默认不贴到 PR只在 CI 日志里输出。warning 级别贴出来但不阻断。只有 blocker 级别才阻断合并。这样即使有误报也不会影响开发节奏。实测下来经过两三轮 prompt 调优误报率能压到 10% 以下团队接受度就上来了。3.4 成本控制别让 AI 评审变成烧钱机器token 成本是绕不开的话题。我算过一笔账一个中等规模的 PRdiff 大概 500 行加上上下文单次评审消耗约 8000 token。如果团队每天 20 个 PR一个月就是 480 万 token。用主流模型的价格算一个月几十到几百块不等看模型选择。控制成本的手段有这么几个只评审变更部分不送全量代码。跳过小 PR。改动少于 10 行的 PR 直接跳过 AI 评审人工看一眼就行。缓存重复内容。同一个文件多次提交如果 diff 没变复用上次结果。分级调用。blocker 级别的检查用强模型info 级别的用便宜模型。我目前的配置是默认用中等价位模型遇到大 PR 或关键模块才切到强模型。这样成本可控效果也够用。4. 实操过程与核心环节实现4.1 环境准备与依赖安装我以最常见的 Git 平台 CI 组合来演示具体平台名称就不提了思路是通用的。你需要准备一个能跑 CI 的环境自建 runner 或托管服务都行。一个能调用 AI 模型的 API key。一个能读写 PR 评论的 token。依赖方面我用 Python 写评审脚本主要用到这几个库pip install requests pygithubrequests用来调 AI APIpygithub用来操作 PR。如果你用别的语言找对应的 SDK 就行逻辑一样。环境变量配置export AI_API_KEYyour_api_key export AI_API_BASEhttps://your-api-endpoint export PR_TOKENyour_platform_token export PR_REPOowner/repo注意API key 和 token 一定要用 CI 的密钥管理功能注入不要硬编码在脚本里更不要提交到仓库。4.2 拉取 PR diff 并预处理第一步是把 PR 的 diff 拉下来。用pygithub大概是这样from github import Github import os g Github(os.environ[PR_TOKEN]) repo g.get_repo(os.environ[PR_REPO]) pr repo.get_pull(int(os.environ[PR_NUMBER])) diff_files [] for f in pr.get_files(): if f.filename.endswith((.lock, .min.js, .generated.java)): continue if f.filename.startswith(vendor/): continue diff_files.append({ filename: f.filename, patch: f.patch, additions: f.additions, deletions: f.deletions })这段代码做了两件事拉取 PR 的所有变更文件过滤掉锁文件、压缩文件、自动生成代码和第三方库。过滤规则要根据你项目实际情况调整原则是只评审人写的代码。预处理还有个重要步骤过滤掉纯删除的 hunk。如果某个 hunk 只有删除没有新增AI 评审意义不大直接跳过。4.3 调用 AI 模型并解析结果核心的评审函数大概长这样import requests import json def review_diff(diff_content, filename): prompt f你是一名资深后端工程师请评审以下代码变更。 评审维度空指针风险、资源泄漏、并发问题、异常处理、SQL注入、硬编码密钥。 不评审代码风格、命名规范。 输出要求JSON 数组每个元素包含 file、line、severity、category、message、suggestion。 severity 取值blocker、warning、info。 如果没有问题返回空数组 []。 文件{filename} 变更内容 {diff_content} resp requests.post( f{os.environ[AI_API_BASE]}/v1/chat/completions, headers{Authorization: fBearer {os.environ[AI_API_KEY]}}, json{ model: your-model, messages: [{role: user, content: prompt}], temperature: 0.2 }, timeout60 ) content resp.json()[choices][0][message][content] try: return json.loads(content) except json.JSONDecodeError: return []几个关键点temperature设成 0.2让输出稳定超时设 60 秒避免卡死解析失败返回空数组不要让整个流程崩掉。4.4 结果去重、排序与贴评论拿到所有文件的评审结果后需要合并处理def merge_results(all_results): seen set() merged [] severity_order {blocker: 0, warning: 1, info: 2} for r in all_results: key (r[file], r[line], r[category]) if key in seen: continue seen.add(key) merged.append(r) merged.sort(keylambda x: (severity_order[x[severity]], x[file], x[line])) return merged去重的 key 用文件行号类别避免同一位置重复评论。排序按严重级别优先让评审人先看到重要问题。贴评论时我按级别分组blocker 和 warning 贴到 PRinfo 只写日志def post_comments(pr, results): blocker_and_warning [r for r in results if r[severity] in (blocker, warning)] if not blocker_and_warning: return body ## AI 评审结果\n\n for r in blocker_and_warning: icon [阻断] if r[severity] blocker else [警告] body f{icon} {r[file]}:{r[line]} {r[message]}\n if r.get(suggestion): body f 建议{r[suggestion]}\n pr.create_issue_comment(body)如果存在 blockerCI 脚本最后exit 1阻止合并。4.5 CI 配置示例把上面的脚本串起来CI 配置大概是这样name: ai-code-review on: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Setup Python uses: actions/setup-pythonv4 with: python-version: 3.10 - name: Install deps run: pip install requests pygithub - name: Run AI review env: AI_API_KEY: ${{ secrets.AI_API_KEY }} AI_API_BASE: ${{ secrets.AI_API_BASE }} PR_TOKEN: ${{ secrets.PR_TOKEN }} PR_REPO: ${{ github.repository }} PR_NUMBER: ${{ github.event.pull_request.number }} run: python review.py这个配置在 PR 打开和更新时触发跑完评审脚本。如果脚本返回非零退出码CI 失败PR 无法合并。5. 常见问题与排查技巧实录5.1 AI 返回格式不对怎么办这是最常见的问题。表现是脚本解析 JSON 失败评审结果为空。原因通常是模型输出里带了 markdown 代码块标记比如json ...。解决办法有两个一是在 prompt 里明确要求直接输出 JSON不要用代码块包裹二是在解析前先做清洗def clean_json(content): content content.strip() if content.startswith(): content content.split(\n, 1)[1] content content.rsplit(, 1)[0] return content.strip()两个手段一起用基本能解决。5.2 评审意见太多太碎怎么办早期我遇到这个问题一个 PR 贴出三四十条意见评审人直接崩溃。后来做了几件事提高 info 级别门槛默认不贴。同一文件同一类别的意见合并成一条。限制单次贴出的意见数量超过 15 条只贴前 15 条其余写日志。实测下来一个 PR 贴 5 到 10 条意见是比较舒服的区间。5.3 大 PR 超时或超 token 怎么办大 PR 是绕不开的。我的处理策略单文件 diff 超过 500 行的按 hunk 切分。总 diff 超过 5000 行的只评审改动最大的前 10 个文件其余跳过并在评论里说明。设置单次调用超时 60 秒超时重试一次再失败就跳过该文件。提示不要为了评审大 PR 无限加大 token 限制成本和稳定性都会出问题。宁可少评一点也要保证流程稳定。5.4 团队不认可 AI 意见怎么办这是流程问题不是技术问题。我的经验是先在小范围试点收集反馈调优 prompt。把 AI 定位成辅助而不是裁判明确它不阻断合并除非是 blocker。定期复盘 AI 意见的准确率把数据摆出来用事实说服团队。允许评审人一键忽略某条意见并记录原因用于后续优化。5.5 常见问题速查表问题现象可能原因排查方向解决办法评审结果为空JSON 解析失败看原始返回内容加清洗逻辑优化 prompt意见太多阈值太低统计各级别数量提高 info 门槛合并同类超时diff 太大看单文件行数分批处理设置超时重试误报多prompt 不具体分析无效意见模式补充排除规则加白名单成本高全量评审统计 token 消耗跳过小 PR分级调用模型评论贴不上token 权限不足看 API 返回错误检查 token scope5.6 几个我踩过的坑坑一忘了过滤删除行。早期 AI 对纯删除的代码也评头论足说这里删掉了重要的判空逻辑其实人家是重构。后来在预处理阶段直接跳过纯删除 hunk。坑二prompt 里没写语言。有次评审一个 Go 项目AI 按 Java 的习惯给建议驴唇不对马嘴。后来在 prompt 里动态注入语言类型问题解决。坑三CI 失败但没提示。有次脚本报错退出但 PR 上没有任何提示开发者一脸懵。后来加了异常捕获任何错误都贴一条评论说明AI 评审执行失败请人工评审。坑四token 泄露。早期图省事把 key 写在脚本里差点提交上去。现在全部走 CI 密钥管理脚本里只读环境变量。6. 我目前稳定在用的配置与后续扩展跑到现在我稳定下来的配置是这样的CI 触发Python 脚本中等价位模型temperature 0.2只评审 diffblocker 和 warning 贴评论info 写日志blocker 阻断合并。误报率控制在 10% 以内团队接受度不错。后续我打算扩展几个方向。一是多模型交叉验证blocker 级别的意见用两个模型分别评都认为是 blocker 才阻断进一步降低误报。二是结合静态分析工具把 lint、安全扫描的结果一起喂给 AI让它综合判断减少重复。三是评审历史沉淀把每次评审结果存下来定期分析高频问题反哺到编码规范和培训里。最后分享一个小技巧prompt 里加一句如果代码写得很好请明确说未发现明显问题。这看起来是废话但能让 AI 在没问题时给出明确反馈而不是硬编几条意见凑数。这个改动让我这边的无效意见少了一大截。另外AI 评审的评论里我习惯带上本意见由 AI 生成仅供参考的声明。既是合规要求也是给评审人一个心理预期——AI 说的不一定对最终判断还是靠人。这个定位摆正了整个流程才能长久跑下去。