我们偷偷关掉了CI中的付费AI审查工具，用这招每天省下3小时，代码质量反而上去了

自己搭个AI代码审查机器人，比付费工具香多了。如果你天天都在做PR（Pull Request）代码审查，肯定懂这些痛点：

审着审着人累了，关键问题就漏看了
同样的问题反复出现：命名不规范、缺测试、边界条件没处理
本来以为是“小改动”，结果花45分钟重建上下文

今天和大家讲一个更爽的方案：

每次提交PR，CI自动触发一个即时、结构化的代码审查（正确性、安全性、性能、测试全覆盖），用你自己的LLM（OpenAI / Anthropic / OpenRouter / 本地Ollama）——还不用再掏钱买什么“AI代码审查”订阅服务。

这事儿真没那么复杂。我搭了个审查流水线，它专为工作流自动化设计，跑起来特别顺手。

核心就四步，80%的价值来自20%的工作

整个流水线其实就干四件事：

CI把代码库checkout下来
读取PR的diff（改动部分）
输出一份结构化的Markdown审查报告
把报告直接贴到PR评论区（或者存成artifact也行）

重点来了：最关键的不是选什么模型。

真正决定审查质量的，是你设计的审查规则（也就是prompt/workflow）。好的规则能强制输出有用结构，比如：

把高危问题和格式优化分开说
必须给出具体修复建议和测试用例
明确写清楚“我看了哪些文件”“哪些地方我不确定”

自己搭更省钱

聊天类订阅服务适合人工交互，但CI里的代码审查是另一种玩法：

只在有PR时才跑，不是7×24小时烧钱
用按量付费API，小改动用便宜模型，大重构再上强模型
甚至能跑本地Ollama，边际成本几乎为零

自己搭流水线，模型选型、token上限、触发条件全在你手里控着，不会为“无效审查”白花钱。

动手搭起来：三步搞定

第一步：写个GitHub Action

在仓库里建这个文件：
路径：.github/workflows/ai-code-review.yml

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(linename: AI Code Reviewon:  pull_request:
jobs:  review:    runs-on: ubuntu-latest    permissions:      contents: read      pull-requests: write
    steps:      - uses: actions/checkout@v4        with:          fetch-depth: 0
      - name: 安装 Jazz        run: npm install -g jazz-ai
      - name: 运行代码审查工作流        run: jazz --output raw workflow run code-review --auto-approve        env:          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

几个细节注意下：

--output raw 在CI里好处理，输出直接能捕获
--auto-approve 让流程全自动跑，不用人工确认
权限故意设得最小，安全第一

当然Jazz也支持Anthropic、OpenRouter这些，换环境变量就行，我主要用OpenAI，其他就没太展开讲。

第二步：定义啥叫“好审查”（规则模板）

很多AI审查翻车，就是因为输出一堆“感觉”，没实质内容。好的规则得强制它：

标严重等级（哪些真能搞挂线上）
标置信度（哪些是猜的）
给具体行动项（改哪行、加什么测试）

建个规则文件：
路径：workflows/code-review/WORKFLOW.md

参考模板直接抄：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line---name: code-reviewdescription: 审查PR diff并生成结构化报告autoApprove: read-only---
审查当前PR的代码改动。
输出GitHub风格Markdown，包含：
1) 摘要（2–4个要点）2) 高危问题（正确性+安全性）3) 性能/复杂度隐患4) API/UX陷阱5) 测试缺口+具体测试建议6) 格式优化（命名/可读性）
规则：- 必须具体：指出文件/函数名- 优先最小改动：给最安全的修复方案- 不确定就明说，并建议验证方式- 禁止泛泛而谈（比如“加测试”），必须给具体测试用例

如果你经常被AI审查刷屏的话，这里规则写清楚就省心多了——至少它不会把缩进问题标成P0。

第三步：把审查结果贴到PR评论区

最稳的做法：先生成Markdown文件，再用gh命令贴评论。

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line- name: 生成审查报告  run: jazz --output raw workflow run code-review --auto-approve > review.md  env:    OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
- name: 评论到PR  run: gh pr comment "$PR_NUMBER" --body-file review.md  env:    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}    PR_NUMBER: ${{ github.event.pull_request.number }}

行内标注（inline comment）也能做，但初期真没必要折腾，先把结构化报告跑起来，价值已经够大了。

安全底线：CI里千万别给写权限

如果这篇文章你只记住一点，那就是：

别让CI里的审查代理有写仓库的权限。

审查任务设成read-only就够了。就算工具能执行shell命令或自动提交，90%的价值在只读模式下就能拿到，何必冒风险。

让审查真正有用的小技巧

强制分级：High/Medium/Low标清楚，全标“重要”等于没标
控制误报率：如果连续一周刷假警报，开发者很快就会无视它
按diff大小路由：小PR用便宜模型，大重构再上强模型
要求透明：必须列出“审查了哪些文件”“做了哪些假设”“没查哪些部分”

自己搭个审查机器人，成本可控、规则透明，还能按团队习惯定制。比那些黑盒SaaS香多了，关键是——它真能帮你省下那45分钟重建上下文的时间。

– END –

{{userData.name}}已认证