1. 为什么 CI/CD 里需要 AI 代码审查

代码审查这件事，做过团队协作的人都有体会：人工 Review 质量参差不齐，有人盯得细，有人只回一句 LGTM；反馈周期长，一个 PR 挂两三天是常态；新人不知道团队规范，反复踩同样的坑。更麻烦的是，当你想把 AI 审查接进 CI/CD 流水线时，会发现每个工具都要单独配一套 Key、一套地址、一套鉴权方式，密钥散落在各个仓库的 Secrets 里，换一个模型就要改一遍配置。

我这次要交付的，就是一套能跑起来的方案：用 TaoToken 作为统一的 API 通道，把 AI 代码审查服务接进 CI/CD，一份 Key 走通所有审查请求，配置集中管理，PR 触发即审查，结果自动回写到协作平台。适合正在搭 CI/CD 流水线、想给团队加一道自动化质量门禁的后端或 DevOps 同学，也适合想先跑通再优化的个人开发者。

核心检索词先摆清楚：AI 自动化代码审查，指的是用大模型对 Git diff 做语义级分析，找出空指针、资源泄漏、注入风险、命名不规范等问题；CI/CD 集成，指的是在 pull_request 事件触发时自动执行审查脚本；TaoToken 统一 API，指的是把模型调用收敛到一个兼容 OpenAI 协议的入口，避免多工具多密钥的混乱。下面从环境准备到配置骨架、再到验证和排障，一步步来。

2. TaoToken 前置准备：统一 Key 与通道

2.1 为什么用统一通道而不是每个工具单独配

传统做法是：ESLint 一套规则、CodeQL 一套查询、AI 审查再单独接一个模型厂商。问题在于，AI 审查这一层如果直接对接多个模型供应商，你会遇到三套鉴权、三套限流、三套计费口径。团队里只要有人换模型，CI 配置就得跟着改，密钥轮换更是灾难。

TaoToken 的思路是把模型调用统一到一个兼容 OpenAI 协议的入口，审查脚本只认一个base_url和一个api_key。这样 CI 里的配置项从 N 个降到 2 个，密钥管理从「每个仓库一套」变成「组织级一套」。对于代码审查这种高频、低单次 token 消耗的场景，统一通道还能让限流和用量统计集中在一处，排查问题不用来回切换后台。

2.2 拿到 Key 和确认接入地址

先到控制台创建 API Key，建议按环境拆分成ci-review这样的命名，方便后续审计。创建入口在控制台的 API Keys 页面：

https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite

接入地址统一用：

https://taotoken.net/api

注意这个地址不加任何查询参数，脚本里直接作为base_url使用。模型对话的调试入口在这里，配好 Key 后可以先在网页里发一条测试消息，确认通道通不通：

https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite

如果你后续要做长期编码辅助或 Agent 类任务，可以了解 Coding Plan，它更适合高频、长上下文的场景：

https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite

接入文档在这里，遇到协议细节可以对照：

https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite

2.3 环境变量约定

CI 里不要把 Key 写进配置文件，统一走 Secrets。约定三个变量：

本地调试时用.env加载，CI 里用平台自带的 Secret 注入。这样同一份脚本在本地和流水线里行为一致，不会出现「本地能跑 CI 报 401」的情况。

3. 可复制配置：config.toml 与 settings.json 骨架

3.1 config.toml：审查任务与规则

这份配置放在仓库根目录的.ai-review/config.toml，描述「审查什么、用什么规则、输出到哪」。字段都给了注释，直接改值即可。

# .ai-review/config.toml [provider] # 统一走 TaoToken 通道，脚本只认这两个字段 base_url = "https://taotoken.net/api" api_key_env = "TAOTOKEN_API_KEY" # 从环境变量读取，不落盘 model = "gpt-4o-mini" # 按控制台可用模型替换 timeout_seconds = 60 max_retries = 2 [review] # 只审查这些后缀的文件，避免二进制和锁文件浪费 token include_ext = [".py", ".js", ".ts", ".go", ".java"] # 单次 diff 超过这个行数就分段送审，防止超上下文 max_diff_lines = 800 # 严重等级阈值，低于此级别不阻断流水线 block_on = ["high", "critical"] [rules] # 每条规则会拼进 Prompt，团队可按需增删 security = true # 注入、越权、硬编码密钥 performance = true # 循环内查询、重复计算 style = true # 命名、注释、魔法数字 concurrency = true # 竞态、锁粒度、死锁风险 [output] # 审查结果同时输出到控制台和文件，供后续步骤上传 format = "markdown" report_path = "ai-review-report.md" # 是否把结果回写到 PR 评论，由 CI 脚本读取此开关 post_comment = true

3.2 settings.json：CI 触发与协作同步

这份配置放在.ai-review/settings.json，描述「什么时候触发、结果同步到哪」。CI 脚本读它来决定行为。

{ "trigger": { "events": ["pull_request"], "actions": ["opened", "synchronize", "reopened"], "branches": ["main", "release/*"], "skip_draft": true, "skip_labels": ["skip-ai-review"] }, "collaboration": { "comment_on_pr": true, "comment_prefix": "[AI-Review]", "notify_channel": "slack", "channel_webhook_env": "SLACK_WEBHOOK_URL", "assign_on_critical": ["@tech-lead"] }, "cache": { "enabled": true, "key_by": "commit_sha", "ttl_hours": 24 } }

skip_labels是个实用开关：给 PR 打上skip-ai-review标签就跳过审查，适合紧急热修或纯文档改动。cache按 commit sha 缓存结果，同一个 commit 重复触发不会重复消耗 token。

3.3 审查脚本骨架

脚本负责取 diff、拼 Prompt、调 TaoToken、解析结果。核心逻辑如下，语言用 Python，依赖只有requests。

# .ai-review/review.py import os, subprocess, json, sys, requests BASE_URL = os.environ.get("TAOTOKEN_BASE_URL", "https://taotoken.net/api") API_KEY = os.environ["TAOTOKEN_API_KEY"] MODEL = os.environ.get("REVIEW_MODEL", "gpt-4o-mini") def get_diff(base_ref="origin/main"): # 取当前分支相对基线的 diff，只保留目标文件 out = subprocess.run( ["git", "diff", f"{base_ref}...HEAD", "--unified=3"], capture_output=True, text=True, check=True ) return out.stdout def build_prompt(diff: str) -> str: return f"""你是资深代码审查员，请审查以下 diff。 要求： 1. 按 [严重等级][问题类型][文件:行号][描述][建议] 输出。 2. 严重等级只用 critical/high/medium/low。 3. 只报真实问题，不要泛泛而谈。 4. 若某文件无问题，不必列出。 diff: {diff} """ def call_model(prompt: str) -> str: resp = requests.post( f"{BASE_URL}/v1/chat/completions", headers={"Authorization": f"Bearer {API_KEY}"}, json={ "model": MODEL, "messages": [{"role": "user", "content": prompt}], "temperature": 0.2, }, timeout=60, ) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] if __name__ == "__main__": diff = get_diff() if not diff.strip(): print("no diff, skip") sys.exit(0) report = call_model(build_prompt(diff)) with open("ai-review-report.md", "w", encoding="utf-8") as f: f.write(report) print(report)

temperature设 0.2 是为了让审查结果稳定，同一段代码多次审查结论一致，避免「这次说有问题下次说没问题」的尴尬。

4. 接入 CI/CD 并验证请求

4.1 GitHub Actions 工作流

把审查步骤挂到pull_request事件上，完整 YAML 如下：

name: AI Code Review on: pull_request: types: [opened, synchronize, reopened] branches: [main, "release/*"] jobs: ai-review: runs-on: ubuntu-latest permissions: contents: read pull-requests: write steps: - uses: actions/checkout@v4 with: fetch-depth: 0 # 必须，否则拿不到基线 diff - uses: actions/setup-python@v5 with: python-version: "3.11" - name: Install deps run: pip install requests - name: Run AI review env: TAOTOKEN_API_KEY: ${{ secrets.TAOTOKEN_API_KEY }} TAOTOKEN_BASE_URL: https://taotoken.net/api REVIEW_MODEL: gpt-4o-mini run: python .ai-review/review.py - name: Post comment if: always() uses: actions/github-script@v7 with: script: | const fs = require('fs'); const body = fs.readFileSync('ai-review-report.md', 'utf8'); await github.rest.issues.createComment({ owner: context.repo.owner, repo: context.repo.repo, issue_number: context.issue.number, body: `[AI-Review]\n\n${body}` });

fetch-depth: 0是关键，默认浅克隆拿不到origin/main，diff 会为空，脚本直接跳过，你会以为审查没生效。

4.2 验证请求是否成功

本地先跑一遍，确认通道通、Key 有效、模型可调：

export TAOTOKEN_API_KEY="sk-你的key" export TAOTOKEN_BASE_URL="https://taotoken.net/api" export REVIEW_MODEL="gpt-4o-mini" # 造一个带问题的 diff 测试 git checkout -b test-review echo 'password = "hardcoded123"' >> demo.py git add demo.py && git commit -m "test: add demo" python .ai-review/review.py

预期输出里应该能看到类似[critical][security][demo.py:1][硬编码密钥][改用环境变量或密钥管理服务]的条目。如果返回 401，检查 Key 是否带多余空格；如果返回 404，检查base_url是否误加了/v1后缀——脚本里已经拼了/v1/chat/completions，base_url只到/api。

4.3 成功结果长什么样

审查报告写入ai-review-report.md，PR 评论区出现带[AI-Review]前缀的评论，内容按严重等级分组。CI 日志里能看到Run AI review步骤耗时通常在 10 到 30 秒，取决于 diff 大小。如果配置了block_on = ["high", "critical"]，脚本在检测到高危问题时以非零码退出，流水线变红，起到质量门禁作用。

5. 本篇常见错排查

5.1 diff 为空导致审查跳过

最常见的原因是actions/checkout没设fetch-depth: 0，浅克隆下git diff origin/main...HEAD拿不到基线。另一个原因是分支名写错，base_ref默认origin/main，如果你的主干叫master或develop，要在脚本里改掉，或者用github.base_ref动态传入。

5.2 401 与 403 的区分

401 是鉴权失败，通常是 Key 无效、过期或带了换行符。CI Secrets 里粘贴 Key 时容易带上尾部空格，建议在脚本里API_KEY.strip()。403 是权限或额度问题，检查 Key 是否绑定了正确的项目、额度是否耗尽。这两种错误在 TaoToken 控制台的用量页面都能看到对应记录，对照时间点排查很快。

5.3 超时与上下文超限

diff 太大时，单次请求会超时或超出模型上下文。config.toml里的max_diff_lines = 800就是干这个的，超过就按文件分段送审。分段时注意保留每个文件的完整 hunk，不要把一段 diff 从中间切断，否则模型会误判语法。实测下来，把大 PR 拆成多个小请求，总耗时反而更短，因为单次请求的排队时间减少了。

5.4 审查结果不稳定

同一段代码两次审查结论不同，多半是temperature太高。设到 0.2 以下，并在 Prompt 里明确「只报真实问题」。另外，模型对「风格问题」的判断主观性较强，如果团队不想被命名规范刷屏，把style = false关掉，只留安全和性能规则。

5.5 PR 评论重复刷屏

pull_request的synchronize事件在每次 push 时都会触发，如果每次都新建评论，PR 很快被刷满。解决办法是用cache按 commit sha 去重，或者改用「更新已有评论」而不是「新建评论」——通过comment_prefix找到上一条[AI-Review]评论并编辑它。这个逻辑在settings.json的collaboration段里预留了开关，按团队习惯取舍。

6. 团队协作落地与后续接入

审查结果要真正影响协作，得让它出现在大家本来就会看的地方。PR 评论是最自然的入口，配合assign_on_critical在出现高危问题时自动 @ 技术负责人，避免问题被淹没在通知流里。Slack 或飞书通知作为补充，适合非 PR 场景，比如定时对主干做全量扫描。

密钥管理上，建议按环境拆 Key：CI 用一把只读审查权限的 Key，本地开发用另一把，轮换时互不影响。TaoToken 控制台可以给 Key 加备注和查看用量，定期审计哪些 Key 还在用、哪些该回收。

如果你后续想把审查能力扩展到更多场景，比如在 IDE 里做实时提示、或者接 Agent 做自动修复，统一通道的价值会更明显——换模型只改一个REVIEW_MODEL变量，脚本和 CI 配置都不用动。接入细节对照文档即可：

https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite

需要新建或轮换 Key 时走这里：

https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite

先把上面这份config.toml和settings.json复制进仓库，跑通一次本地审查，再挂到 CI 上。第一步能出报告，后面优化规则和协作流程就是水到渠成的事。