请添加图片描述

TL;DR

Addy Osmani 在最新博文中指出：AI 写代码的速度已经远超人类审查代码的速度，代码审查成了新的瓶颈。本文从零搭建一条 AI 驱动的自动审查流水线——用 Claude Code 作为审查引擎，Git pre-push hook 触发，自动检查逻辑错误、安全漏洞和代码风格，审查结果直接写入 PR 评论。全文代码可直接运行。

1. 为什么代码审查成了新瓶颈？

Addy Osmani 在 2026 年 6 月 15 日的博文《Agentic Code Review》中抛出了一个尖锐的观点：过去两年，我们花了大量精力让 AI 写代码更快——Copilot 补全、Claude Code 自动生成、Cursor 一键重构——但审查端几乎没有任何加速。结果就是，写代码的时间从两小时压缩到了五分钟，但审查那五分钟产出的代码，仍然需要半小时。

他在 Google 与团队合著的白皮书《The New Software Lifecycle》中讨论了这个问题：当 AI 辅助让代码产出速度提升数倍时，传统的审查流程——每次提交都需要另一个工程师逐行阅读——就成了整个软件交付链中最慢的一环。

解决方向不是让人类审得更快，而是让 AI 审第一遍。人类从审查者升级为审查结果的质量把关者。这篇文章就从零搭建这样一套流水线。

2. 整体架构

整套流水线分为四个环节：

  1. Git Hook 触发：pre-push 阶段自动运行，不阻塞提交但拦截推送
  2. Diff 提取：获取即将推送的变更内容
  3. AI 审查引擎：Claude Code 读取 diff，按规则执行审查
  4. 结果投递：审查报告写入文件，可选推送到 GitHub PR

用一张流程图来描述：

git push
  → pre-push hook 触发
    → git diff 提取变更
      → Claude Code 分析（安全性 + 逻辑 + 风格）
        → 生成审查报告
          → 写入 .code-review/report.md
          → (可选) 推送 PR 评论

请添加图片描述

3. 环境准备

首先确保安装了 Claude Code：

# 安装 Claude Code（需要 Node.js 18+）
npm install -g @anthropic-ai/claude-code

# 验证安装
claude --version

确认 Git 仓库已初始化，且在项目根目录下有 .git/hooks/ 目录。

4. 编写审查规则文件

AI 审查需要一个明确的检查清单。在项目根目录创建 .code-review/rules.md：

# AI Code Review 规则

## 安全性（高优先级）
- [ ] 是否存在 SQL 注入风险（字符串拼接 SQL）
- [ ] 是否存在 XSS 风险（未转义的用户输入输出到 HTML）
- [ ] 是否存在硬编码的密钥、Token、密码
- [ ] 是否使用了不安全的加密算法（MD5、SHA1 用于密码）
- [ ] 文件上传是否校验了类型和大小

## 逻辑正确性（中优先级）
- [ ] 是否存在空指针 / undefined 访问风险
- [ ] 异步操作是否正确 await 或处理 Promise
- [ ] 循环边界条件是否正确（off-by-one）
- [ ] 错误处理是否覆盖了异常路径
- [ ] 是否有未使用的变量或导入

## 代码风格（低优先级）
- [ ] 函数是否超过 50 行（建议拆分）
- [ ] 是否存在超过 3 层的嵌套
- [ ] 命名是否清晰表达意图
- [ ] 是否存在重复代码块

这套规则参考了 Addy Osmani 在《Agentic Code Review》中提到的分层审查思路——安全性永远第一，风格问题不要阻塞合并。

5. 编写审查脚本

创建 .code-review/review.sh：

#!/bin/bash
# AI Code Review 脚本
# 用法: bash .code-review/review.sh

set -e

REVIEW_DIR=".code-review"
RULES_FILE="$REVIEW_DIR/rules.md"
REPORT_FILE="$REVIEW_DIR/report.md"
DIFF_FILE="$REVIEW_DIR/diff.txt"

mkdir -p "$REVIEW_DIR"

# 1. 提取未推送的 diff
BRANCH=$(git rev-parse --abbrev-ref HEAD)
REMOTE="origin/$BRANCH"

if git rev-parse --verify "$REMOTE" >/dev/null 2>&1; then
  # 远程分支存在，对比差异
  git diff "$REMOTE...HEAD" > "$DIFF_FILE"
  echo "📋 对比 $REMOTE...HEAD"
else
  # 新分支，对比 main
  git diff origin/main...HEAD > "$DIFF_FILE" 2>/dev/null || \
  git diff origin/master...HEAD > "$DIFF_FILE" 2>/dev/null || \
  git diff HEAD~1 > "$DIFF_FILE"
  echo "📋 新分支，对比 main/master"
fi

# 2. 检查是否有变更
if [ ! -s "$DIFF_FILE" ]; then
  echo "✅ 无代码变更，跳过审查"
  exit 0
fi

CHANGED_FILES=$(git diff --name-only "$REMOTE...HEAD" 2>/dev/null || \
  git diff --name-only origin/main...HEAD 2>/dev/null || \
  git diff --name-only HEAD~1)

echo "📝 变更文件:"
echo "$CHANGED_FILES"
echo ""

# 3. 构建审查 prompt（写入临时文件，避免 diff 中特殊字符破坏 shell）
PROMPT_FILE="$REVIEW_DIR/prompt.txt"

cat > "$PROMPT_FILE" <<'ENDOFPROMPT'
你是一位资深代码审查专家。请根据以下审查规则审查代码变更，输出 Markdown 格式的审查报告。

## 审查规则
ENDOFPROMPT

cat "$RULES_FILE" >> "$PROMPT_FILE"

cat >> "$PROMPT_FILE" <<'ENDOFPROMPT'

## 代码变更
ENDOFPROMPT

# 将 diff 内容逐行追加，避免 shell 转义
echo '```diff' >> "$PROMPT_FILE"
cat "$DIFF_FILE" >> "$PROMPT_FILE"
echo '```' >> "$PROMPT_FILE"

cat >> "$PROMPT_FILE" <<'ENDOFPROMPT'

## 输出格式
请按以下结构输出审查报告：

### 审查摘要
- 变更文件数：N
- 发现的问题数：N（高优先级 X / 中优先级 Y / 低优先级 Z）

### 高优先级问题 🚨
（如有）逐条列出，每条包含：
- **文件**：路径 + 行号
- **问题**：描述
- **建议**：修复方案

### 中优先级问题 ⚠️
（同上格式）

### 低优先级问题 💡
（同上格式）

### 总体评价
一段话总结这次变更的质量和建议。

注意：
- 如果没有发现某类问题，写"无"即可
- 问题描述使用中文
- 不要编造不存在的问题
- 代码风格类问题给出具体建议但不要阻塞合并
ENDOFPROMPT

# 4. 调用 Claude Code 进行审查
echo "🤖 正在调用 AI 审查引擎..."
claude -p "$(cat "$PROMPT_FILE")" > "$REPORT_FILE" 2>/dev/null || {
  echo "❌ Claude Code 调用失败，请检查是否已安装并登录"
  exit 1
}

# 5. 输出结果
echo ""
echo "========================================="
cat "$REPORT_FILE"
echo "========================================="
echo ""
echo "✅ 审查报告已保存到 $REPORT_FILE"

赋予执行权限：

chmod +x .code-review/review.sh

6. 接入 Git Pre-Push Hook

创建 .git/hooks/pre-push：

#!/bin/bash
# Pre-push hook：推送前自动运行 AI Code Review

echo ""
echo "🔍 正在运行 AI Code Review..."
echo "================================================"

# 运行审查脚本
bash .code-review/review.sh
REVIEW_EXIT_CODE=$?

echo "================================================"

if [ $REVIEW_EXIT_CODE -ne 0 ]; then
  echo "⚠️  审查过程出错，但仍允许推送（审查失败不应阻塞开发）"
fi

# 检查是否有高优先级问题（排除内容为"无"的情况）
if grep -q "高优先级问题 🚨" .code-review/report.md 2>/dev/null; then
  # 提取"高优先级问题"到下一个"###"之间的内容
  HIGH_SECTION=$(sed -n '/### 高优先级问题/,/###/p' .code-review/report.md)
  if echo "$HIGH_SECTION" | grep -q "^\- \*\*文件\*\*"; then
    echo ""
    echo "🚨 警告：审查发现安全问题！"
    echo "   报告位置: .code-review/report.md"
    echo ""
    read -p "   是否仍要继续推送？(y/N): " CONFIRM
    if [ "$CONFIRM" != "y" ] && [ "$CONFIRM" != "Y" ]; then
      echo "❌ 推送已取消"
      exit 1
    fi
  fi
fi

echo "✅ 审查完成，继续推送..."
exit 0

chmod +x .git/hooks/pre-push

7. 手动运行与验证

在实际推送之前，可以先手动跑一次审查脚本确认一切正常：

# 做一些代码变更
echo "console.log('test')" >> src/test.js
git add src/test.js
git commit -m "test: 验证 AI Code Review"

# 手动运行审查
bash .code-review/review.sh

你应该会看到 Claude Code 输出一份 Markdown 格式的审查报告，包含对这次变更的安全性、逻辑和风格检查。

8. 扩展到 GitHub PR 评论

上面的脚本把审查结果写到了本地文件，但在团队协作中更实用的做法是把结果自动贴到 Pull Request 里。这里给出一个扩展脚本 post-to-pr.sh：

#!/bin/bash
# 将审查报告发布为 PR 评论
# 前置条件：安装 GitHub CLI (gh) 并已登录

REPORT_FILE=".code-review/report.md"
PR_NUMBER=$(gh pr view --json number -q ".number" 2>/dev/null)

if [ -z "$PR_NUMBER" ]; then
  echo "⚠️ 未检测到关联 PR，跳过评论"
  exit 0
fi

if [ ! -f "$REPORT_FILE" ]; then
  echo "⚠️ 未找到审查报告"
  exit 1
fi

# 查找是否已有 AI Review 评论
COMMENT_ID=$(gh pr view "$PR_NUMBER" --json comments -q \
  ".comments[] | select(.body | startswith(\"🤖 AI Code Review\")) | .id" 2>/dev/null | head -1)

REPORT_CONTENT=$(cat "$REPORT_FILE")

if [ -n "$COMMENT_ID" ]; then
  # 更新已有评论
  echo "📝 更新已有审查评论..."
  gh pr comment "$COMMENT_ID" --body "🤖 AI Code Review（已更新）

$REPORT_CONTENT" 2>/dev/null || echo "⚠️ 更新评论失败"
else
  # 创建新评论
  echo "📝 创建审查评论..."
  gh pr comment "$PR_NUMBER" --body "🤖 AI Code Review

$REPORT_CONTENT" 2>/dev/null || echo "⚠️ 创建评论失败"
fi

在 pre-push hook 末尾加上一行即可自动发布：

# 追加到 pre-push hook 末尾
bash .code-review/post-to-pr.sh

9. 踩坑与最佳实践

踩坑 1：diff 太大导致 Claude Code 超时

如果一次推送包含几十个文件的变更，diff 可能会超过 Claude Code 的上下文窗口。解决方案是在 review.sh 中限制 diff 大小：

# 在提取 diff 后加入大小检查
DIFF_SIZE=$(wc -c < "$DIFF_FILE")
MAX_SIZE=50000  # 50KB

if [ "$DIFF_SIZE" -gt "$MAX_SIZE" ]; then
  echo "⚠️ Diff 过大 (${DIFF_SIZE} bytes)，仅审查变更量最大的 5 个文件"
  git diff --name-only "$REMOTE...HEAD" | head -5 | xargs git diff "$REMOTE...HEAD" -- > "$DIFF_FILE"
fi

踩坑 2：审查报告干扰 git 操作

pre-push hook 中如果有 read -p 交互提示，在某些 CI 环境或 GUI Git 客户端中会导致推送卡死。建议在生产环境去掉交互确认，改为直接输出警告并记录日志：

# CI 友好版本：检测是否在交互终端中
if [ -t 0 ]; then
  read -p "是否仍要继续推送？(y/N): " CONFIRM
else
  echo "⚠️ 非交互环境，自动跳过确认"
  CONFIRM="y"
fi

踩坑 3：规则文件不要过于严苛

Addy Osmani 在博文中特别强调：AI 审查的定位是辅助，不是替代。风格类规则（函数长度、嵌套深度）设置为"建议"而非"强制"，避免开发者对审查结果产生抵触。

最佳实践清单

  • 安全性规则放第一优先级，问题数超过 0 就警告
  • 风格问题只做建议，不要阻塞推送
  • 定期回顾审查报告，如果某条规则频繁被忽略，说明它可能不切实际
  • 在团队中推行前，先用两周时间收集数据（不阻塞推送），确认误报率可接受
  • .code-review/ 目录加入 .gitignore，审查报告不提交到仓库

10. 这套流水线背后的思路

Addy Osmani 在《Agentic Code Review》中提出了一个关键框架：审查的三个层次。

第一层是机械检查（格式、lint、类型检查），这些传统工具已经做得很好。第二层是语义理解（逻辑错误、安全漏洞、边界条件），这是 AI 审查的核心价值所在。第三层是设计判断（架构是否合理、抽象是否恰当），这目前仍然需要人类来做。

本文搭建的流水线覆盖了第二层——让 AI 在每次推送前执行语义级的代码审查。人类审查者不再需要逐行检查空指针和 SQL 注入，而是把精力集中在架构设计和业务逻辑上。

用 Osmani 的话来说：代码审查的未来不是 AI 替代人类，而是 AI 让人类审查者升级为更高层次的质量决策者。

参考资料

# git # 人工智能 # elasticsearch
Logo
DeepSeek技术社区

欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。

更多推荐

cover

谋定而后动：Claude Code 的 /plan 与 /task 深度实战指南

avatar DeepSeek技术社区

Claude的编辑能力：3个提升内容质量的实践方法

规则：1.不逐词翻，用中文自然表达 2.文化差异内容换成本土化表述 3.保持原文语气 4.翻译后在文末标注做了特殊处理的项目。Claude的核心优势不在内容生成，在内容优化。Prompt模板：请按以下规则润色：1.拆分超过50字的句子 2.删除重复观点 3.确保段间自然过渡 4.保持原有语气 5.修改后列出具体改动项。阶段二：按大纲逐段生成——每段200字以内、开头一句话点明结论、中间用具体案例展

avatar DeepSeek技术社区
cover

终端里的 AI 驾驶舱：Claude Code 斜杠命令深度解析

avatar DeepSeek技术社区