1. 为什么 PR 一多代码审查就成了瓶颈团队从 3 个人涨到 8 个人之后我最直观的感受不是需求变多了而是 PR 列表开始堆积。以前两个人互相看一眼就能合并现在一个 PR 挂两天没人审是常态。更麻烦的是人工审查在疲劳状态下特别容易漏掉关键问题——上周就有一个空指针判断被漏过去上线后半夜报警。我试过用现成的 SaaS 审查工具但要么按人头收费太贵要么对私有仓库支持不好。后来想明白一件事审查这件事本质上是「把 diff 喂给模型让它按固定维度输出报告」那完全可以自己搭一条流水线。核心诉求有三个每次 PR 自动触发、审查结果直接评论到 PR 里、模型调用通道要稳定不能三天两头鉴权失败。这里的关键卡点其实不在 GitHub Actions而在模型调用的 Base URL。很多教程让你直接填官方端点但实际跑起来会遇到两个问题一是流水线环境里网络出口不稳定二是 Key 管理分散在各个仓库的 Secrets 里换一次要改十几个地方。所以这篇的重点是把 Cursor 里配置的 Base URL 统一改到 TaoToken让本地开发和 CI 走同一条通道Key 也只维护一份。整套方案适合谁适合 3 到 20 人的研发团队尤其是已经在用 Cursor 做日常开发、想让 PR 审查也自动化的场景。你不需要自己写复杂的 prompt 工程Cursor Agent 会帮你生成审查脚本你只需要把配置和 workflow 拼起来。下面从环境准备开始一步步给出可复制的片段。2. 前置准备TaoToken 通道与 Cursor Base URL 配置在动手写 workflow 之前先把模型调用通道打通。这一步做对了后面 CI 里就不会出现莫名其妙的 401 或者连接超时。TaoToken 的作用是提供一个统一的 API 入口你可以在官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 了解它的接入方式API 地址是 https://taotoken.net/api。先说 Key 怎么拿。进入控制台后创建 API Key建议按用途分一个给本地 Cursor 用一个给 CI 用。这样万一 CI 的 Key 泄露你只需要在 TaoToken 控制台吊销那一个不影响本地开发。Key 的格式通常是一串以特定前缀开头的字符串复制后先存到密码管理器里别直接贴在代码里。接下来是 Cursor 的配置。Cursor 支持自定义模型的 Base URL路径在设置里的 Models 面板。你需要填三个东西Base URL、API Key、Model ID。Base URL 填https://taotoken.net/api注意不要带多余的斜杠。API Key 填刚才创建的那把。Model ID 根据你要用的模型填比如做代码审查可以用claude-3-7-sonnet-20250219这类标识具体以 TaoToken 文档里列出的为准。配置片段大概长这样你可以对照着填{ baseUrl: https://taotoken.net/api, apiKey: sk-你的TaoToken密钥, model: claude-3-7-sonnet-20250219 }填完之后在 Cursor 里发一条测试消息比如「用一句话解释什么是幂等性」。如果能正常返回说明通道通了。如果报错先检查 Base URL 有没有多写/v1之类的后缀TaoToken 的 API 路径以文档为准不要自己拼。这里有个容易踩的坑Cursor 的配置界面在不同版本里位置不太一样有的在 Settings 的 Models 标签下有的需要点齿轮图标进高级设置。找不到的话直接在 Cursor 里搜「Base URL」关键词。另外本地配置和 CI 配置要分开管理本地用个人 KeyCI 用仓库 Secret不要混用。通道打通后你还需要一个 GitHub 仓库和基本的 Actions 权限。仓库的 Settings 里要能创建 SecretsActions 要允许运行。这些是 GitHub 侧的基础操作不展开。重点是把 TaoToken 的 Base URL 和 Key 准备好下一步写审查脚本时直接引用环境变量。3. 可复制配置审查脚本与 workflow YAML这一节是整篇的核心给出可以直接复制粘贴的文件内容。你需要创建两个文件一个是 Python 审查脚本code_reviewer.py一个是 GitHub Actions 的 workflow 文件.github/workflows/ai-review.yml。先看审查脚本。它的逻辑很简单读取 diff 文件拼一段 prompt调用模型输出 Markdown 报告。关键点在于 Base URL 要从环境变量读这样本地和 CI 可以共用同一份代码。下面是我实测可用的版本#!/usr/bin/env python3 # code_reviewer.py - 自动化代码审查脚本 import os import sys import anthropic # 从环境变量读取配置CI 和本地共用 BASE_URL os.environ.get(TAOTOKEN_BASE_URL, https://taotoken.net/api) API_KEY os.environ.get(TAOTOKEN_API_KEY) MODEL_ID os.environ.get(REVIEW_MODEL, claude-3-7-sonnet-20250219) client anthropic.Anthropic( api_keyAPI_KEY, base_urlBASE_URL, ) def load_diff(file_path: str) - str: with open(file_path, r, encodingutf-8) as f: return f.read() def review_code(diff: str) - str: prompt f你是一位资深代码审查专家。请审查以下 PR 的代码变更输出结构化报告。 审查维度 1. 严重问题安全漏洞、逻辑错误、性能瓶颈 2. 改进建议可读性、最佳实践、潜在边界情况 3. 亮点如果有 要求 - 每个问题标注文件和大致行号 - 输出 Markdown 格式 - 如果没有严重问题明确标注「未发现严重问题」 变更内容diff {diff} response client.messages.create( modelMODEL_ID, max_tokens2000, messages[{role: user, content: prompt}], ) return response.content[0].text if __name__ __main__: if len(sys.argv) 2: print(用法: python code_reviewer.py diff_file) sys.exit(1) diff load_diff(sys.argv[1]) if not diff.strip(): print(无代码变更) sys.exit(0) report review_code(diff) print(report)注意anthropic这个库支持自定义base_url参数这是把请求指向 TaoToken 的关键。如果你用的 SDK 版本不支持升级到最新版即可。然后是 workflow 文件。它定义了触发条件、运行环境和评论发布逻辑name: AI Code Review on: pull_request: types: [opened, synchronize, ready_for_review] jobs: review: runs-on: ubuntu-latest permissions: pull-requests: write contents: read steps: - name: Checkout code uses: actions/checkoutv4 with: fetch-depth: 0 - name: Setup Python uses: actions/setup-pythonv5 with: python-version: 3.11 - name: Install dependencies run: pip install anthropic - name: Get PR diff run: | git diff origin/${{ github.base_ref }}...HEAD pr.diff - name: Run AI review env: TAOTOKEN_BASE_URL: https://taotoken.net/api TAOTOKEN_API_KEY: ${{ secrets.TAOTOKEN_API_KEY }} REVIEW_MODEL: claude-3-7-sonnet-20250219 run: python code_reviewer.py pr.diff review.md - name: Post review comment uses: actions/github-scriptv7 with: script: | const fs require(fs); const review fs.readFileSync(review.md, utf8); const prNumber context.payload.pull_request.number; const comments await github.rest.issues.listComments({ owner: context.repo.owner, repo: context.repo.repo, issue_number: prNumber }); const botComment comments.data.find(c c.user.type Bot c.body.includes(AI 审查报告) ); if (botComment) { await github.rest.issues.deleteComment({ owner: context.repo.owner, repo: context.repo.repo, comment_id: botComment.id }); } await github.rest.issues.createComment({ owner: context.repo.owner, repo: context.repo.repo, issue_number: prNumber, body: ## AI 审查报告\n\n${review} });这里有几个细节值得说。fetch-depth: 0是必须的否则拿不到完整的 diff。permissions里pull-requests: write是发评论的权限少了会报 403。删除旧评论的逻辑是为了避免每次 push 都堆一条新评论保持 PR 干净。最后在 GitHub 仓库的 Settings → Secrets and variables → Actions 里新建一个 Secret名字叫TAOTOKEN_API_KEY值填你的 TaoToken Key。注意 workflow 里引用的名字要和这里一致。4. 验证请求一次 PR 触发与结果确认配置写完之后必须做一次端到端验证确认整条链路能跑通。这一步不要跳过很多问题只有实际触发才会暴露。先创建一个测试分支随便改点东西git checkout -b test/ai-review echo console.log(hello) test.js git add . git commit -m test: 添加测试文件 git push origin test/ai-review然后在 GitHub 上基于这个分支创建 PR。创建后几秒内Actions 标签页应该能看到一个名为「AI Code Review」的 workflow 开始运行。点进去看日志重点关注几个阶段Checkout 是否成功、pip install 有没有报错、Get PR diff 生成的 pr.diff 是否非空、Run AI review 有没有正常输出。如果一切顺利大约 10 到 30 秒后PR 的评论区会出现一条以「AI 审查报告」开头的评论。内容大概是这样的结构## AI 审查报告 ### 严重问题 - 文件 test.js 第 1 行生产环境使用 console.log 建议改用日志库 ### 改进建议 - 添加文件末尾换行符 - 考虑使用 use strict 模式 未发现安全漏洞或逻辑错误看到这条评论说明 Base URL 指向 TaoToken 的配置生效了Key 鉴权也通过了。你可以再 push 一次提交观察旧评论是否被删除、新评论是否更新。这个「删除旧评论再发新评论」的行为是 workflow 里那段 github-script 实现的验证它能正常工作很重要否则 PR 会被评论淹没。验证阶段还要留意一个点diff 的获取方式。我用的是git diff origin/${{ github.base_ref }}...HEAD三个点表示对比 merge base这样只包含当前分支的变更不会把主分支的无关改动带进来。如果你的仓库有特殊的分支策略可能需要调整这个命令。如果评论没出现先看 Actions 日志里哪一步失败了。最常见的是Run AI review这一步报错日志里会打印具体的异常信息。把错误信息复制出来对照下一节的排查表处理。5. 常见报错排查401、连接失败与空报告这一节整理我在搭建过程中真实遇到过的报错以及对应的解决思路。你遇到问题时可以按这个顺序排查。报错一401 Unauthorized 或 authentication_error这是最常见的。原因通常是 Key 无效、过期或者环境变量名对不上。排查步骤先在 TaoToken 控制台确认 Key 还在有效期内然后检查 GitHub Secret 的名字是否和 workflow 里${{ secrets.TAOTOKEN_API_KEY }}完全一致大小写敏感最后确认脚本里读取的是TAOTOKEN_API_KEY而不是别的名字。如果本地能跑通、CI 报 401基本就是 Secret 没配对。报错二连接超时或 connection error如果日志里出现连接失败、超时之类的信息先确认TAOTOKEN_BASE_URL填的是https://taotoken.net/api没有多余路径。然后检查 workflow 里这个环境变量有没有正确传递。有时候是 runner 的网络波动重跑一次 workflow 就能过。如果持续失败可以在脚本里加一行打印BASE_URL的日志确认实际用的地址是什么。报错三No module named anthropic这是依赖没装。检查 workflow 里是否有pip install anthropic这一步以及它是否在Run AI review之前执行。如果用了 requirements.txt确认文件里包含 anthropic。报错四审查报告为空或只有「无代码变更」说明 diff 文件是空的。原因可能是fetch-depth: 0没加导致 checkout 的是浅克隆拿不到 base 分支。也可能是github.base_ref在你的触发条件下为空。检查 workflow 的on配置确保是pull_request事件。另外如果 PR 只改了二进制文件或空文件diff 也可能为空这是正常现象。报错五评论发布失败提示 403这是权限问题。确认 workflow 里有permissions: pull-requests: write。如果仓库的组织策略限制了默认 token 权限可能需要在仓库 Settings → Actions → General 里把 Workflow permissions 改成「Read and write permissions」。报错六OAuth 或 token 相关错误如果日志里出现 OAuth 字样通常和 GitHub 的 token 权限有关而不是 TaoToken 的问题。检查actions/github-script用的 token 是否有发评论的权限。另外如果你在 Cursor 里配置时遇到 OAuth 流程那是 Cursor 客户端自己的登录机制和 CI 里的 API Key 调用是两回事不要混淆。排查时有个通用技巧在脚本里加print语句把关键变量Base URL、模型 ID、diff 长度打印出来。CI 日志里能看到这些输出比盲猜快得多。6. 把通道固定下来让流水线长期稳定整套流程跑通之后真正决定它能不能长期用下去的不是脚本写得多漂亮而是调用通道稳不稳定。我见过太多团队一开始用得好好的过两个月因为端点漂移或者 Key 管理混乱流水线悄悄挂了没人发现。把 Base URL 统一到 TaoToken 的好处在这里体现得很明显本地 Cursor 和 CI 走同一个入口配置只有一份换 Key 或者调整模型时改一处就行。你可以在 TaoToken 控制台看到每个 Key 的调用情况方便做成本监控。如果团队规模扩大还可以按项目拆分 Key做更细的权限隔离。如果你还想进一步优化有两个方向值得做。一是加缓存用actions/cache缓存 pip 依赖能把 workflow 时间缩短几秒。二是加审查门禁当报告里出现严重问题时让 CI 失败阻止合并。实现方式是在 workflow 末尾加一步- name: Check for critical issues run: | if grep -q 严重问题 review.md; then echo 发现严重问题请修复后重新提交 exit 1 fi这样审查就不只是「给个建议」而是真正卡住了质量底线。当然门禁的严格程度要按团队情况调太严会拖慢迭代太松又没意义。最后说下 Key 的获取和文档入口。API Key 在 TaoToken 控制台创建接入细节可以看官方文档。如果你还没配好本地 Cursor 的 Base URL建议先把本地跑通再上 CI这样出问题时能快速区分是通道问题还是 workflow 问题。模型对话功能可以用来快速验证 Key 是否有效不用每次都跑完整流水线。整套配置下来从零到 PR 自动出审查评论熟练的话半小时内能搞定。真正花时间的不是写代码而是把 Base URL、Key、Model ID 这三件套在每个环节对齐。对齐之后剩下的就是让它安静地跑你专注写业务代码。