AI编程工具链：AI 代码审查——让 AI 帮你 Code Review

2026-08-18 AI代码审查编程工具教程

没人帮你看代码，是独立开发者最大的隐性风险

写代码的人都承认 Code Review 有用，但独立开发者和小团队有个尴尬的现实：没人帮你审。

大厂有专职的 review 流程，每个 PR 至少两个同事过目，过不了别想合主干。你一个人写代码，写完自己点「合并」，bug 直接进生产。我在微软那几年养成的习惯是「没有 review 的代码不进主干」，出来做独立开发后，这个习惯差点没保住——因为你找不到那个帮你看代码的人。

AI 恰好补上了这个空位。而且它有一个人类同事没有的优势：24 小时在线，审一次不要钱，永远不会嫌你代码写得烂。

但这篇文章得先把丑话说在前面：AI 审查不是万能的。它审得出你漏掉的空指针，审不出你产品方向对不对。搞清楚它的能力边界，你才知道该信它哪句话、该忽略哪句话。

AI 擅长审什么，不擅长审什么

先把边界划清楚。这张表是我用 AI 审了快一年代码后的真实感受：

审查类型	AI 表现	说明
语法 / 类型错误	⭐⭐⭐⭐⭐	静态检查器都能干的活
空指针 / None 处理	⭐⭐⭐⭐⭐	一眼看出哪里可能为 None
SQL 注入 / XSS 等安全漏洞	⭐⭐⭐⭐⭐	训练数据里有海量安全案例
资源泄漏（文件、连接）	⭐⭐⭐⭐	能发现没 close 的句柄
代码坏味道（重复、过长函数）	⭐⭐⭐⭐	能给出重构建议
命名 / 可读性	⭐⭐⭐⭐	主观，但通常靠谱
并发 / 竞态条件	⭐⭐⭐	需要给足上下文
业务逻辑正确性	⭐⭐	需要你解释「什么是对」
架构权衡	⭐⭐	见仁见智，AI 只会给教科书答案
性能瓶颈	⭐⭐	需要 profiling 数据配合

一句话总结：AI 擅长审「代码写得对不对」，不擅长审「需求理解得对不对」。 前者是确定性的技术问题，后者是判断力问题。

AI 代码审查的标准流程

我用 AI 审代码的完整流程画成一张图，下面逐环节讲：

AI 代码审查工作流

第一层：静态检查（免费，别跳过）

在让 AI「深度审」之前，先把机器能自动查的查掉。语法、类型、依赖漏洞、代码格式——这些是确定性的，不需要 AI，用现成工具就能跑：

# Python：ruff 一站式搞定 lint + 格式
pip install ruff
ruff check .          # 检查
ruff check . --fix    # 自动修复能修的

# 依赖漏洞扫描
pip install pip-audit
pip-audit

# JS/TS 项目
npx eslint .
npm audit

这一层能过滤掉一半以上的「低级问题」。等把 AI 叫来的时候，它只需要专注在真正需要「理解」的问题上，效率高得多。

第二层：AI 深度审查

这才是 AI 的主场。审查时给足上下文，让它关注静态检查查不出来的东西——逻辑错误、边界条件、安全漏洞、资源管理。

一个可复用的审查 prompt 模板，我直接贴出来：

你是一名资深代码审查者。请审查下面这段代码，按以下维度逐一检查：

1. 正确性：逻辑是否有错误？边界条件（空值、越界、除零）是否覆盖？
2. 安全性：是否存在 SQL 注入、XSS、路径遍历、敏感信息泄露？
3. 资源管理：文件句柄、数据库连接、网络连接是否正确关闭？
4. 并发：是否存在竞态条件、线程安全问题？
5. 可维护性：命名是否清晰？函数是否过长？是否有重复代码？

输出要求：
- 每个问题单独编号，按严重程度排序（🔴 严重 / 🟡 建议 / 🔵 优化）
- 每个问题给出：出问题的代码行、为什么有问题、具体怎么改（附代码 diff）
- 如果没有发现问题，明确说「未发现问题」，不要为了凑数编造

环境：Python 3.11 + FastAPI + SQLAlchemy 2.0 async
以下是代码：
[粘贴代码]

关键点有两个：一是让 AI 按维度检查而不是自由发挥，这样它不会漏掉「安全」这种容易忽略的维度；二是要求它给出具体 diff 而不是「建议优化」这种废话。

第三层：人工复核

AI 的输出必须经过你的眼睛。这不是不信任，而是 AI 审查的固有缺陷决定的——它会有误报（把对的代码说成有问题）和漏报（真 bug 没看出来）。误报尤其烦人，多了之后你会对 AI 的结论产生「狼来了」效应。

复核的原则：🔴 严重级别的问题逐条看，🟡 建议扫一眼，🔵 优化类直接跳过。把复核时间控制在几分钟内，不要让 AI 审查变成新的负担。

实战：让 AI 审一段有问题的代码

直接上真实例子。下面这段 Python 是我从某个项目里扒出来的真实代码（脱敏处理），你能看出几个问题？

def get_user_profile(user_id, db_conn):
    query = f"SELECT * FROM users WHERE id = {user_id}"
    cursor = db_conn.cursor()
    cursor.execute(query)
    row = cursor.fetchone()
    name = row[1]
    email = row[2]

    if not email:
        email = "unknown@example.com"

    profile = {
        "name": name.upper(),
        "email": email,
    }
    return profile

我把它和上面的审查 prompt 一起丢给 Claude，它返回了四个问题，按严重程度排序：

🔴 SQL 注入：user_id 直接拼进 SQL 字符串。如果 user_id 来自外部输入，攻击者可以注入任意 SQL。应该用参数化查询。
🔴 无空值检查：cursor.fetchone() 可能返回 None，直接 row[1] 会抛 TypeError。用户不存在时应该返回明确的 404 而不是 500。
🟡 资源泄漏：cursor 用完没有 close()。短脚本无所谓，长连接的服务会慢慢耗尽连接。
🔵 业务逻辑可疑：邮箱不存在时塞一个假的 unknown@example.com，下游如果拿这个地址发邮件会静默失败，不如返回 None 让调用方决定。

四个问题里，前两个是真正会出事故的（安全漏洞 + 线上 500），第三个是慢性病，第四个是设计问题。如果没人审，这段代码大概率会带着前两个问题上线。

AI 给的修复 diff（关键部分）：

def get_user_profile(user_id, db_conn):
    # 参数化查询，杜绝 SQL 注入
    cursor = db_conn.cursor()
    cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
    row = cursor.fetchone()

    if row is None:          # 空值检查
        return None

    name, email = row[1], row[2]
    try:
        profile = {
            "name": name.upper(),
            "email": email if email else None,
        }
        return profile
    finally:
        cursor.close()        # 保证资源释放

30 秒审完，两个高危问题直接毙掉。你自己盯这段代码，可能要等到线上出事了才发现。

把 AI 审查接进 CI，让它每次 PR 自动跑

手动审查只能覆盖你有空的时候。真正省心的是把审查接到 CI 里——每次开 PR 自动审，结果直接贴在 PR 的评论区。

两条路：用现成工具，或者自己写脚本。

现成工具里我用过最好的是 CodeRabbit。GitHub App 一键安装，开 PR 后自动审，逐条评论在对应代码行上，还能自动「学习」你对误报的标记（你点「忽略」，下次类似的就不报了）。免费额度对个人项目够用。

如果你想自己掌控，用 GitHub Actions 跑一个审查脚本也不难。下面是个最小可用版本，用 Claude API 审 diff：

# .github/workflows/ai-review.yml
name: AI Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Get diff
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > /tmp/pr.diff
      - name: AI review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          pip install anthropic
          python scripts/ai_review.py /tmp/pr.diff
      - name: Post comment
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const review = fs.readFileSync('/tmp/review.md', 'utf8');
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: review
            });

scripts/ai_review.py 里就是读 diff、调 Claude API、把结果写到 /tmp/review.md。核心逻辑就二十几行：

import sys, os
from anthropic import Anthropic

diff = open(sys.argv[1]).read()

prompt = f"""你是资深代码审查者，审查下面的 git diff。
按严重程度输出问题（🔴/🟡/🔵），每个问题附具体修改建议。
不要重复 diff 内容，只输出问题清单。没有明显问题就输出"未发现问题"。

<diff>
{diff}
</diff>"""

client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
msg = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=2000,
    messages=[{"role": "user", "content": prompt}],
)

open("/tmp/review.md", "w").write(msg.content[0].text)

这套东西搭一次，之后每个 PR 都有一个「免费的同事」自动帮你过一遍，不用记得手动触发。

工具怎么选

市面上 AI 代码审查的入口很多，按场景选：

工具	适合场景	优势
CodeRabbit	开源项目 / 长期维护	全自动、逐行评论、学习误报
GitHub Copilot Code Review	在 GitHub 上日常用	原生集成，一键要 review
Claude Code / Cursor	本地提交前审查	吃下整个仓库，上下文最全
审查 Prompt + Web 版	单段代码、临时问	零配置，直接贴代码
自建 CI 脚本	想完全掌控	成本最低、可定制

我的日常是：小改动在 Cursor 里顺手让 AI 扫一眼，开 PR 用 CodeRabbit 自动审，重要模块单独用 Claude 深度审。 三个层次，成本从低到高，覆盖从「随手」到「上生产」的所有场景。

三个必须记住的坑

坑一：别让 AI 只审 diff，不审上下文

很多问题只在上下文里才暴露——比如改了函数 A，但函数 B 依赖 A 的旧返回值。审查时尽量带上相关文件，而不是孤零零的一段 diff。

坑二：误报烦人，但漏报致命

AI 偶尔会把对的代码说成有问题（误报），也会漏掉真 bug（漏报）。前者烦，后者要命。所以高危改动（支付、鉴权、数据迁移）永远不要只依赖 AI 审查，你自己还得过一遍。

坑三：AI 审代码，但不替你负责

AI 说「没问题」不代表真的没问题，AI 说「有问题」也不代表你一定要改。最终拍板的是你。这跟用 AI 调 bug 是同一个道理——AI 定位，你决策。

总结

AI 代码审查对一个独立开发者最大的价值，不是「发现更多 bug」，而是给你一双第二眼睛，让你重新拥有大厂才有的「代码有人看」的安全感。

静态检查先行，AI 专注「理解型」问题
用结构化 prompt，让 AI 按维度审查、附具体 diff
接进 CI，让审查变成自动的、无痛的
高危改动永远人工兜底

这篇文章讲的是「审」，下一篇我会讲 AI 怎么帮你「测」——从单元测试写到 E2E，把 AI 编程工具链继续往下走。

AI编程工具链系列：
1. Prompt Engineering 实战手册
2. AI Debugging：让AI帮你修bug
3. 👉 AI 代码审查：让AI帮你 Code Review（本文）
4. AI 自动化测试——从单元测试到 E2E（下一篇）
5. AI 驱动的完整开发工作流