AI 代码审查实操：AI 写的代码让 AI 审靠谱吗（2026）

用 AI 写代码这件事，2026 年已经没什么争议了。真正卡住大家的是下一步：这些代码谁来把关？靠自己一行行读，AI 半小时产出的量你要看两小时，那提效就白提了；完全不看直接合并，线上出事只是时间问题。于是「AI 代码审查」成了刚需——让 AI 来审代码，包括审 AI 自己写的代码。这篇文章不吹工具，只讲三件事：现在有哪三条可落地的路线、各自真实花多少钱、以及 AI 审查最容易漏掉的盲区在哪，哪些环节必须留给人。

先说结论：AI 代码审查是补漏网，不是质量闸门

很多人对 AI 代码审查的期待是错的——他们想要一个「AI 说通过就能合并」的闸门。目前所有主流方案都刻意不这么设计。以 Anthropic 官方的 Code Review 为例，它的检查运行（check run）永远以「中立」结论结束，明确写着不会通过分支保护规则阻止合并；发现的问题只按严重程度分成三档：🔴 重要（合并前该修的 bug）、🟡 小问题（值得修但不阻塞）、🟣 预先存在（代码库本来就有、不是这个 PR 引入的）。CodeRabbit、Copilot 的 PR 审查也是同样的定位：贴评论，不拦你。

这个设计不是厂商保守，而是符合现实：AI 审查的价值在于「覆盖率」而不是「准确率」。人类审查者会累、会跳过大 PR、会只看自己熟的模块；AI 不会，它能对每一个 PR、每一行改动都过一遍，把那些「一眼看不出但确实错了」的东西捞出来。但它同时也会误报，会把风格偏好当问题提。所以正确的用法是：把它当成一张永远在线的补漏网，接在你的流程前面，而不是当成最后一道闸门。

三条路线：本地自查、托管 PR 审查、自建 CI

落地方式无非三种，成本和适用场景差别很大。先看清楚自己属于哪一档，再往下读对应章节，不用三条都上。

如果你是一个人做产品，只需要第一条；团队协作、有 PR 流程了再上第二条；对数据外发有顾虑、或者想用 DeepSeek/GLM 这类国产模型把成本压到几乎为零，走第三条。

路线一：推代码前，先在本地审一遍

这是性价比最高、也最容易被忽略的一步。代码还在你机器上的时候审，改起来没有任何心理负担；等推上去开了 PR 再被指出问题，你已经在「解释」而不是「修改」了。Claude Code 内置了本地审查命令，不需要装任何 GitHub App，在任意会话里直接运行：

# 默认范围：当前分支相对上游领先的提交 + 工作树里未提交的改动
/code-review

# 也可以指定审查目标：文件路径 / PR 编号 / 分支名 / ref 范围
/code-review src/api/auth.ts
/code-review 128
/code-review main...my-feature

# 审完直接把发现应用到工作树（改代码）
/code-review --fix

# 审完把发现作为内联评论发到对应 PR 上
/code-review --comment

它同时报两类东西：正确性 bug，以及复用/简化/效率上的清理项。审查深度跟着会话的 effort 级别走——低级别返回更少但更有把握的发现，high 到 max 覆盖更广、但可能夹带不确定的判断。日常提交用默认档就够，改到核心链路（鉴权、支付、数据迁移）再往上调。

路线二：托管 PR 审查，三家怎么选

团队一旦有了 PR 流程，就该让审查自动跑起来。三家主流方案的定位差别不小，价格结构更是完全不同——有的按人头包月，有的按 token 实报实销，后者在大仓库上很容易超预算。

选型逻辑很直接：做开源项目 → CodeRabbit，公开仓永久免费、不限席位，没有比这更划算的；已经在用 Copilot 套餐、只想顺手加个审查 → 用它自带的；对审查深度要求高、愿意为质量付钱且有 Team/Enterprise 订阅 → Claude Code Review，多代理并行加一道验证步骤过滤误报，是目前噪音控制最讲究的一档。

路线三：自建 CI，把成本压到几乎为零

托管方案好用但贵，而且代码要过第三方。如果你有 CI 基建、或者对代码外发敏感，自建是更实在的选择：在流水线里拿到 diff，拼个提示词丢给模型 API，把返回的结果贴回 PR。核心就这三步，没有魔法。Anthropic 官方也提供了在自己 CI 里跑的路径（GitHub Actions、GitLab CI/CD、GitHub Enterprise Server 自托管实例都覆盖到了），不用非走托管服务。

自建最大的好处是模型可以随便换。审 diff 这个任务对模型要求没那么高，DeepSeek、GLM、Qwen 这类国产模型完全够用，token 价格比国际大模型低一个数量级，一个中型团队一个月的审查成本可能就几十块钱。国内已经有成熟的开源方案可以直接抄，比如 GitLab 侧的自动审查工具，支持接 DeepSeek/OpenAI 等多家模型、Docker 一键部署，还能把审查结果推到钉钉/企业微信/飞书。

如果你用的是托管审查但想在自己的 CI 里做卡点，也可以反过来读它的结果。Claude Code Review 的检查运行输出末尾埋了一段机器可读的严重程度统计，用 gh 加 jq 就能解析出来：

gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'

# 返回形如：{"normal": 2, "nit": 1, "pre_existing": 0}
# normal 是「重要」发现的数量，非零说明有该在合并前修掉的 bug

拿到这个 JSON，你就可以在自己的流水线里定规矩：normal 大于 0 就让流水线失败。等于把「不阻塞」的托管审查，改造成了你自己的质量闸门——但闸门规则握在你手里，而不是厂商手里。

审查规则怎么写，AI 才审得准

开箱即用的 AI 审查默认只盯正确性——会搞挂生产的 bug，而不是格式偏好或缺失的测试覆盖。想让它按你的项目标准审，就得写规则。这里有个很多人搞混的区别：CLAUDE.md 是项目通用上下文，所有任务都读，审查时把新引入的违规算作「小问题」级别；REVIEW.md 才是审查专用指令，会被逐字注入到每一个审查代理的系统提示里，优先级最高。同一条规则写进 REVIEW.md，落地效果比塞在一份又长又杂的 CLAUDE.md 里可靠得多。

# 审查说明

## 「重要」在本仓库的含义

只有会改变行为、泄露数据或阻断回滚的问题才算重要：错误逻辑、
没有加租户范围的数据库查询、日志或报错里带 PII、不向后兼容的迁移。
命名、风格、重构建议最多算小问题。

## 控制噪音

每次审查最多报 5 个小问题，超出的在摘要里写「另有 N 个同类问题」。
如果全部都是小问题，摘要第一句写「没有阻塞性问题」。

## 不要报告

- CI 已经管了的：lint、格式化、类型错误
- src/generated/ 下的生成代码和任何 *.lock 文件
- 故意违反生产规范的测试专用代码

## 每次都要检查

- 新增 API 路由必须有对应的鉴权判断
- 日志里不能出现手机号、邮箱、用户 ID
- 数据库查询必须限定在调用者的数据范围内

写规则时最值得投入的是这四类，按收益排序：

1. 1重新定义「重要」——默认校准是针对生产代码的。文档仓库、配置仓库、原型项目照搬默认档，会被一堆无关紧要的红色标记淹没。
2. 2给小问题设上限——风格和文案可以被无限打磨。不设上限，一个 PR 收到二十条「建议改个名字」，团队三天后就会集体忽略 AI 的评论，工具直接失效。
3. 3写清跳过范围——生成代码、lockfile、vendor 目录、机器创建的分支，以及 CI 已经强制执行的检查，全都该跳过。重复报告是噪音的最大来源。
4. 4要求证据——加一条「关于行为的判断必须给出源码里的 file:line 引用，不能从命名推断」，能显著减少那种听起来很有道理、点进去发现根本不存在的误报。

AI 审 AI 写的代码：四个必须由人兜底的盲区

这是本文最想说清楚的部分。当写代码的是 AI、审代码的也是 AI，有些问题结构性地审不出来——不是模型不够强，是它压根拿不到判断所需的信息。以下四类，无论工具怎么升级，短期内都得靠人。

1. 1业务语义错误：代码写得完全正确，但做的不是你要的事。比如优惠券叠加规则、退款计算口径、权限边界该给谁——这些只存在于你脑子里和产品文档里，AI 审查器看到的只有 diff，它没有「应该是什么样」的参照物，自然审不出「实现得很漂亮但需求理解反了」。
2. 2跨文件的隐性契约：AI 审查看的是这次改动和周边代码，对于「这个字段三个月前在另一个服务里被约定为不可为空」这种散落在历史里的约定，它很难完整重建。改动越是碰到老系统的边界，这类漏检越多。
3. 3同源偏差：用同一个模型写、又用同一个模型审，两边的思维盲区高度重合。它写的时候没想到的边界情况，审的时候大概率也想不到。想缓解，就让写和审用不同厂商的模型——本地用 Claude 写，PR 上让接 DeepSeek 的自建审查再过一遍，比同一个模型自己审自己有效得多。
4. 4运行时与数据现实：并发下的竞态、真实数据量下的慢查询、第三方接口的实际返回格式——这些都不在代码文本里。AI 能提醒你「这里可能有竞态」，但它无法确认线上到底会不会发生。压测、灰度、监控才是这一类问题的答案，指望审查环节解决是找错了地方。

一套能直接抄的落地节奏

• 写完一个功能，推之前先在本地跑一遍审查命令，把明显的问题就地修掉——这一步免费且最省事
• 仓库根目录放一份 REVIEW.md，先只写三条：重要的定义、小问题上限、跳过范围
• PR 审查先开手动或「创建后审一次」，跑两周看看噪音和账单，再决定要不要改成每次推送都审
• 碰钱、碰权限、碰数据删除、碰对外接口的 PR，无论 AI 报没报问题，都必须有人完整读一遍
• 让写代码和审代码用不同厂商的模型，避开同源偏差
• 每月回看一次：AI 报的问题里有多少是真的？如果误报率高到大家开始无视评论，说明该收紧规则而不是换工具

AI 代码审查真正改变的，不是「谁来挑错」，而是质量把关的位置——从「合并前找个人读一遍」，前移到了「每次改动都被完整过一遍」。工具本身几天就能配好，难的是把规则调到既不漏又不吵，以及始终清楚哪些判断不能交给它。如果你正在用 AI 写代码做真实的产品，从测试、审查到部署上线、监控排错这一整条交付链路都需要成体系地补齐，欢迎来 IMAI 看看我们的实战课程。