在 CI 中构建自己的 AI 代码审查代理

Source: Dev.to

请提供您希望翻译的文章正文内容，我将按照要求保留源链接、格式和技术术语，仅翻译正文部分。谢谢！

手动 PR 评审的问题

如果你整天进行 PR 评审，你已经知道其中的痛点：

• 评审者在疲惫时会遗漏内容。
• 同样的评论会一直重复（命名、测试、边界情况）。
• “快速 PR”会变成 45 分钟的上下文重建。

AI 驱动的解决方案

想象一下，每个 pull request 都能通过 CI 自动使用您选择的模型（OpenAI、Anthropic、OpenRouter，或本地 Ollama 实例）即时获得结构化的代码审查（正确性、安全性、性能、测试），且无需额外支付“AI 代码审查”订阅费用。

关键不在于模型，而在于 审查准则（提示/工作流），它强制形成有用的结构：

• 将高风险问题与小毛病区分开。
• 要求提供具体的修复方案和测试建议。
• 必须说明“我查看了什么”和“我不确定的地方”。

为什么基于 CI 的审查是有道理的

• Chat 订阅非常适合交互式使用，但 CI 代码审查遵循不同的定价模式：仅在 PR 发生时运行。
• 您可以使用按使用付费的 API，为小的差异路由更便宜/更快的模型，或运行本地模型（Ollama），其边际成本接近零。
• 使用 DIY 流水线，您可以控制模型选择、最大 token、运行时机以及什么算是“值得审查”的。

你最终会得到

• 一个在每个 PR 上运行的 GitHub Action。
• 一个输出结构化 Markdown 评审的代码审查工作流。

GitHub Action 定义

在你的仓库中创建文件 .github/workflows/ai-code-review.yml：

name: AI Code Review
on:
  pull_request:

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write

    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install Jazz
        run: npm install -g jazz-ai

      - name: Run code review workflow
        run: jazz --output raw workflow run code-review --auto-approve
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

注意

• --output raw 在 CI 中使用方便（易于捕获/重定向）。
• --auto-approve 使该步骤完全无人值守。
• 权限设置刻意保持最小化。

如果你想使用除 OpenAI 之外的其他提供商，请将环境变量替换为对应提供商的变量（Anthropic、OpenRouter 等）。

评审标准（提示）定义

创建文件 workflows/code-review/WORKFLOW.md。这是你的代理将运行的提示：

---
name: code-review
description: Review PR diff and produce a structured report
autoApprove: read-only
---

Review the current PR diff.

Output GitHub‑flavored Markdown with:

1. **Summary** (2–4 bullets)  
2. **High‑risk issues** (correctness + security)  
3. **Performance / complexity concerns**  
4. **API / UX footguns**  
5. **Test gaps + concrete test suggestions**  
6. **Nitpicks** (style/readability)

**Rules**  
- Be specific: reference files/functions.  
- Prefer minimal diffs / smallest safe fix.  
- If you’re unsure, say so and propose how to verify.  
- No generic advice (“add tests”) — propose exact test cases.  
- Rank issues (High/Medium/Low).  
- List files reviewed, assumptions, and what was not checked.

捕获并发布审查

添加步骤到 GitHub Action，将审查写入文件并在 PR 上发表评论：

- name: Generate review markdown
  run: jazz --output raw workflow run code-review --auto-approve > review.md
  env:
    OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

- name: Comment on PR
  run: gh pr comment "$PR_NUMBER" --body-file review.md
  env:
    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    PR_NUMBER: ${{ github.event.pull_request.number }}

稍后可以进行内联注释，但它们并非获取即时价值所必需。

最佳实践检查清单

• 只读模式：将 autoApprove 保持为只读用于审查任务；不要让代理修改仓库。
• 问题排序：强制代理对问题进行等级排序（高/中/低）。如果所有问题都标记为“重要”，则没有任何问题是重要的。
• 误报预算：如果审查在一周内噪声过多，开发者会忽视它。相应调整评估标准。
• 模型路由：对小型 PR 使用廉价模型，对大型重构使用更强大的模型。
• 透明度：要求代理列出已审查的文件、所作假设以及未检查的内容。

实际案例

Jazz 仓库使用 Jazz 进行代码审查和发布说明。请在此查看工作流文件：https://github.com/lvndry/jazz/tree/main/.github

---

感谢阅读！