免费POC, 零成本试错
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


我要投稿

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

发布日期:2026-02-25 08:17:57 浏览次数: 1568
作者:三黄工作室

微信搜一搜,关注“三黄工作室”

推荐语

告别昂贵的AI代码审查工具,自己动手搭建更高效的自动化审查流水线,省钱又省心!

核心内容:
1. 传统代码审查的常见痛点与低效问题
2. 四步搭建自动化审查流水线的具体方案
3. 自主搭建审查系统的成本优势与灵活控制

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家

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

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

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

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

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

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

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

  1. CI把代码库checkout下来
  2. 读取PR的diff(改动部分)
  3. 输出一份结构化的Markdown审查报告
  4. 把报告直接贴到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-depth0
      - 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 -

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询