Skip to content
返回 AI 编程

AI 驱动的代码审查自动化

将 AI 审查接入 CI/PR 流水线：触发、提示、门禁和人工兜底。

自动化进阶

为什么

GitHub Copilot 达到约 4 亿美元 ARR（同比增长 281%），2024 年占 GitHub 新增净收入的 40%，证明大规模自动化的投资回报。人工审查是 AI 优先团队的瓶颈：AI 生成 PR 的速度快于人类阅读速度。

在每个 PR 上运行的 AI 审查者数秒内捕获机械问题（缺测试、类型漏洞、范围蔓延），将架构与意图判断留给人类。这使审查与生成同步扩展而非落后。

何时使用

在以下情况自动化审查：PR 数量超过人工审查容量；许多 PR 共享一小集可检规则（测试覆盖、无 any、范围）；或希望 7x24 首轮反馈。安全、架构和产品行为变更保留人工门控。

如何做

1. 选触发：PR 打开和新推送时运行，而非特性分支每次提交。 GitHub Actions：on: pull_request（types: [opened, synchronize]） 2. 为提示词收集 diff 和最小上下文： git diff origin/main...HEAD 仅含 PR 标题、正文和变更文件。不发送整个仓库。 3. 写带具体检查的结构化审查提示词： - 每个新函数是否有测试？ - 是否有 any 类型或未处理 promise？ - diff 是否触及 PR 声明范围外文件？ - 是否有新依赖？列出以供许可证检查。 输出 JSON：{ verdict: 'approve'|'request_changes', comments: [{file, line, severity, message}] } 4. 通过 GitHub API 将 AI 审查发为 PR 评论： POST /repos/{owner}/{repo}/pulls/{pr}/comments 用 bot 标签标记以便人类过滤。 5. 按 verdict 门控。'request_changes' 使 CI 检查失败（初期非阻塞）。 先以建议模式运行 2 周，建立信任后切为阻塞。 6. 人工兜底：始终允许 'ai-review: override' 标签消除误报， 并对安全敏感路径在 AI approve 之上要求人工批准。 7. 追踪准确率：每 PR 记录 AI verdict 与最终人工 verdict。调优提示词 降低误报；嘈杂的 bot 一周内即被忽视。

示例

GitHub Action + Claude 审查 bot（YAML + 提示词）： # .github/workflows/ai-review.yml name: AI Review on: { pull_request: { types: [opened, synchronize] } } jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: { fetch-depth: 0 } - run: | git diff origin/main...HEAD > pr.diff node scripts/ai-review.mjs pr.diff >> "$GITHUB_STEP_SUMMARY" // scripts/ai-review.mjs（核心提示词） const prompt = `你是代码审查者。检查此 diff： 1. 无测试的新函数 2. any 类型或未处理 promise 3. PR 范围外文件 输出 JSON：{ verdict, comments: [{file, line, severity, message}] } Diff： ${diff}`; const result = await callClaude(prompt); const { verdict, comments } = JSON.parse(result); await postPRComments(comments); // GitHub API if (verdict === "request_changes") process.exit(1); // 门控

常见问题

  • ⚠GitHub Actions: "Process completed with exit code 1" → 查带 `##[error]` 的日志行；常见原因是缺环境变量（在仓库 Secrets 设置）。
  • ⚠Error: EADDRINUSE: address already in use :::3000 → 运行 `npx kill-port 3000` 或改配置端口。
  • ⚠Cron 任务静默失败 → 用 `set -e; ...` 包裹并重定向输出到日志；用 `tail -f /var/log/job.log` 验证。
  • ⚠GitHub Actions: "Process completed with exit code 1" → 查带 `##[error]` 的日志行；常见原因是缺环境变量（在仓库 Secrets 设置）。

最佳实践

  • ✓建议模式运行 2 周，测量 AI 与人工 verdict 一致率，再切阻塞。
  • ✓仅发 diff 加 PR 标题/正文给模型；绝不发整个仓库。
  • ✓仅将高严重性评论发为 PR review；其余记入运行摘要。
  • ✓始终提供覆盖标签，并对安全敏感路径要求人工批准。
  • ✓追踪每条规则的误报率，剔除错误率超 20% 的规则。

常见问题解答

AI 代码审查应该立即阻塞 PR 吗？

不应该。先以建议模式运行约 2 周，发评论但不使 CI 失败。测量 AI 与人工 verdict 一致率，建立信任后切阻塞。过早阻塞误报会激怒开发者并导致 bot 被禁用。

该向审查 AI 发送什么上下文？

仅 PR diff 加 PR 标题和正文。绝不发整个仓库——撑爆成本和上下文且很少有用。diff 含变更；PR 正文含意图。这足够做机械检查（缺测试、any 类型、范围）。

如何处理 AI 审查误报？

始终提供覆盖路径：'ai-review: override' 标签消除 bot 的阻塞状态。追踪每条规则误报率，剔除错误率超 20% 的规则。无覆盖的嘈杂 bot 一周内即被忽视。

AI 审查者该查什么，什么留给人工？

AI 擅长机械检查：缺测试、any 类型、未处理 promise、范围蔓延、新依赖。架构、安全和产品行为判断留给人工。安全敏感路径在 AI approve 之上要求人工批准。

如何将 AI 审查评论发到 GitHub PR？

用 GitHub API：POST /repos/{owner}/{repo}/pulls/{pr}/comments，含文件、行号和消息。用 bot 标签标记评论以便人类过滤。仅将高严重性发现发为 PR review；其余记入运行摘要以避免噪声。