PR 一多最难受的不是改代码而是审代码。Claude Code 这类终端里的 AI 编程工具能把 PR diff 拉进上下文做质量分析但前提是它得有一条稳定换取模型服务的通道不然就会被官方配额、多 Key 切换和模型版本选择这些与代码无关的事情卡住。TaoToken 接住的是这一段先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentblog_pr_review 创建一把 API Key把 Base URL 填成 https://taotoken.net/apiClaude Code 就能通过这条统一通道读取 PR 变更按你给出的审查规则输出带行号和重构建议的评审意见。本文按原文工作流拆开来讲为什么格式检查和代码异味要分层处理、自动化触发层怎么搭、Claude Code 如何接入模型通道、以及让 AI 真正「审得动脑」的提示词怎么写。1. 为什么 PR 审查比写代码更累格式噪音和代码异味混在一起1.1 高级开发者被低价值检查拖住项目迭代越快PR 越密集仓库里积攒的「还能跑但很乱」的代码就越多。代码规范、缩进、未使用变量、临时调试语句这些检查本身没有难度却实实在在消耗高级开发者每天最清醒的几小时。一个人肉正则引擎看了一百行空格问题之后很难再对真正的架构缺陷保持敏锐。更现实的是格式类问题往往在 CI 阶段就已经能被发现但很多团队并没有把这一层自动化。结果就是资深工程师打开 PR第一屏全是「这里少个空格」「这个变量没用到」「console.log 忘删了」。等翻到真正需要判断逻辑的部分注意力已经被磨掉大半。原文本想表达的就是这个矛盾代码审查不该让最高级的人去做最低级的过滤。1.2 代码异味没有一条正则规则能覆盖格式问题适合交给规则代码异味却很难用规则穷尽。举个实际例子function x(a, b) { let y 0; for (let i 0; i a.length; i) { for (let j 0; j b.length; j) { if (a[i] b[j]) { y 1000; break; } } } return y; }缩进、分号、变量声明这些问题ESLint 一眼就能揪出来。但「x、a、b、y 这些名字到底在表达什么」「两层循环能不能用 Set 降成 O(n)」「1000 这个魔数代表什么业务含义」「 会不会触发类型转换」全部需要结合语境才能判断。不同成员对代码规范的理解决定了他能看出哪一层问题人工审查的标准天然不统一。代码异味往往藏在「能跑」和「该重构」之间。它不违反任何一条 lint 规则却会让下一个接手的人多花三倍时间。这一层正是大语言模型擅长的地方理解命名意图、估算圈复杂度、识别重复逻辑、发现敏感信息泄露风险。问题只在于如何把模型稳定接进审查流程而不是每次去网页里复制粘贴 diff。2. 自动化工作流的三层骨架事件触发、静态规则、AI 兜底2.1 Webhook 事件触发让 PR 一更新就进入审查队列要让审查自动化第一步是让系统知道「该审了」。GitHub 的 pull_request 事件天然适合做触发源PR 被创建、被同步更新、被重新打开都是值得重新跑一遍审查的时刻。用 GitHub Actions 可以快速搭出这一层name: pr-review on: pull_request: types: [opened, synchronize, reopened] jobs: diff: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - run: gh pr diff ${{ github.event.pull_request.number }} /tmp/pr.diff env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} - run: cat /tmp/pr.diff这个流水线不负责具体判断只负责把 PR 的变更内容完整落成一个 diff 文件。后续步骤可以读取这个文件做静态分析也可以把它交给 AI。事件驱动的好处是没人需要记得「每次 PR 更新后去手动跑一遍检查」代码提交即自动进入队列。2.2 规则优先ESLint 处理确定性问题事件触发之后第一层过滤应该交给静态分析工具。缩进、未使用变量、空 catch、显式 any这些有明确对错的问题用 ESLint 处理误报率低、执行速度快也不会消耗模型额度。原文的思路是「规则优先AI 兜底」翻译成工作流就是能让正则和 AST 判断的绝不让模型判断。先把规则层跑干净AI 拿到的 diff 就不再被格式噪音污染。AI 每一条响应都集中在真正需要语义理解的问题上评审报告的阅读体验也会好很多。静态规则层还有个额外收益它给了团队一个最低标准哪怕 AI 评审宕机代码格式也不会崩。2.3 AI 兜底LLM 分析复杂度、命名与安全队列负责削峰规则层过滤完之后剩余部分交给大语言模型分析。LLM 适合评估的目标包括函数是否过长、嵌套是否过深、命名是否符合业务语义、异常是否被静默吞掉、改动是否可能引入敏感信息泄露。这些都不是「对错题」而是「好坏题」。耗时是这一层要面对的现实问题。一次完整的 AI 审查可能需要几十秒如果 Webhook 回调同步等结果HTTP 请求会被活活拖死。所以生产环境里通常会把 diff 落盘后放进消息队列由消费端逐个调用模型再把评审结果写回 PR 评论或指定文件。同类历史的评审记录可以缓存同一个 diff 重复触发时直接返回上次结果避免重复花钱。队列 缓存是 AI 审查从 demo 变成基础设施的关键细节。3. 落地Claude Code 经 TaoToken 通道读取 PR diff3.1 先拿 Key去官网创建再把 Base URL 写进 settings.json原文里「给 AI 配置模型 Key 并让它分析 PR 变更」这一步在 Claude Code 里可以拆成两件事先拿到一把能换模型的 API Key再把 Key 和模型通道填进 Claude Code 的环境变量。打开 TaoToken 注册并创建 API Key之后编辑~/.claude/settings.json{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }YOUR_API_KEY 从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentblog_pr_review_key 创建YOUR_MODEL_ID 以官网模型广场当前列表为准不要照抄旧文章里写死的版本号。注意这里的 Base URL 填的是https://taotoken.net/api末尾不要加/v1Claude Code 会自己补路径。网页上打开的官网带 UTM 参数终端里填的接口地址是纯地址两者不要混用。这套配置的本质是让 Claude Code 把模型请求统一发给 TaoToken 提供的兼容通道官方 SDK 和第三方工具都能共用同一把 Key。原先被官方配额和不同厂商模型地址拆散的流程在这里被收敛成一个入口。3.2 把 PR diff 交给 Claude Code两种跑法拉取 diff 只需要一条命令gh pr diff 1024 /tmp/pr.diff把 1024 换成实际的 PR 编号。之所以只拉 diff 而不是把整个仓库塞进去一是省 token二是让 Claude Code 聚焦在变更行上不被无关文件带偏。拿到 diff 文件之后有两种跑法。手动方式是在项目根目录启动 Claude Code然后在对话里输入「读取 /tmp/pr.diff按下面的审查规范输出意见范围只覆盖 diff 中出现的行不要擅自修改仓库文件。」Claude Code 会读取文件并按提示词工作。进阶一点的方式是让 Claude Code 自己执行命令。你只需要在对话框里写「请运行 gh pr diff 1024 /tmp/pr.diff然后读取这个文件按 /docs/review.md 里的规则做代码审查。只输出评审意见不要改代码。」Claude Code 本身能执行 shell 命令这样连手动复制 diff 都省掉了。如果想要完全无人值守的批量扫描可以在 CI 里调用 Claude Code 的非交互模式具体参数以你本地claude --help输出为准不同版本略有差异。3.3 快速验证通道taotoken CLI 与常见排障配置完最怕的不是没效果而是不知道卡在哪一层。可以用 TaoToken 提供的 CLI 快速验证 Key、Base URL 和模型 ID 三者是否串通npm install -g taotoken/taotoken taotoken cc -k YOUR_API_KEY -u https://taotoken.net/api -m YOUR_MODEL_ID开发者只需在终端跑这两条命令。如果 CLI 能正常返回模型回复说明 Key 和通道没问题问题大概率出在 Claude Code 的配置上如果 CLI 也报错就要回头检查 Key 是否复制完整、模型 ID 是否真的存在于模型广场。验证完可以顺手去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentblog_pr_review_check 看一眼这次调用是否被记录这样能确认整条链路确实走通。常见排障其实就两类。401 表示 Key 无效或复制时带了空格404 表示 Base URL 把/v1也拼上去了去掉即可。模型 ID 填错时响应会提示模型不存在去模型广场复制当前列表里的准确 ID 就行别凭记忆敲。4. 提示词工程让 AI 只报代码异味不报格式噪音4.1 角色与维度拿了 Key、配上 Base URL 之后Claude Code 能用但「能用」和「审得好」之间还差一个提示词。原文的观点很明确先给 AI 设定角色再规定审查维度最后约束输出格式。否则它会按照自己的偏好把格式问题、逻辑问题、风格问题混在一起报看起来全实际上没人愿意看。给一份可以直接用的审查提示词你是资深架构师正在做 PR 评审。只审这份 diff 里的「代码异味」不要重复 ESLint 能发现的格式问题。 审查维度 - 圈复杂度是否过高能否拆分 - 变量与函数名是否反映真实意图 - 是否存在重复逻辑或可复用抽象 - 异常路径是否被静默吞掉 - 变更是否引入安全或数据泄露风险 输出格式 1. 问题等级P0 / P1 / P2 2. 文件与行号从 diff 中取出 3. 问题描述一句话说清为什么是异味 4. 重构建议给出可直接参考的代码片断把这段文本按原样贴进对话即可。不用额外解释「你是 AI」之类的话Claude Code 会把这段提示词当作评审标准执行。4.2 结构化输出行号、等级、重构建议评审意见如果是一大段散文阅读成本依然很高。结构化输出才是团队能长期用的形式。当提示词里明确要求「文件与行号」「问题等级」「重构建议」之后Claude Code 给出的结果会接近下面这种形态| 等级 | 位置 | 问题 | 建议 | |------|------|------|------| | P1 | src/utils.ts:24 | 函数命名 x 不能表达意图 | 更名 findCommonAmount | | P2 | src/utils.ts:31 | 魔法数字 1000 含义不明 | 提取为常量 MAX_COMMON_SCORE |带上行号之后开发者不需要在一万行 diff 里重新定位问题。重构建议也能直接复制到本地验证而不是只得到一个「建议优化」的空话。Claude Code 的审查报告应该让人产生「可以直接干活」的感觉而不是「又得看一遍废话」。4.3 规则优先 AI 兜底如何写进提示词最有价值的一步是在提示词里明确告诉 AI格式问题不要报。你在提示词里加一句「不要重复 ESLint 能发现的格式问题」之后Claude Code 会把注意力完全放在语义层。这一步和整个工作流的设计一脉相承静态工具做确定性的清洁AI 做需要判断力的审查。实际使用时还可以把团队规范文档、历史审查记录放进 Claude Code 的上下文让它少问「你们的规范是什么」这类问题。AI 的价值不在替代规则而在补足规则覆盖不到的地方。把边界划清楚误报率和无效评论都会明显下降。5. 这套人机协同给团队留下的三样东西和三个高频疑问5.1 效率、质量、知识沉淀效率是最先被感受到的。格式检查交给流水线代码异味交给 Claude Code高级开发者不再需要对每一行做低水平初审可以把时间留给架构评审和方案设计。质量提升来自两个方向静态规则保证了底线AI 兜底拦住了命名混乱、深层嵌套和安全风险这些过去只能靠 reviewer 个人经验。知识沉淀则是一个容易被忽略的长期收益。当 Claude Code 每次都按照统一维度输出评审意见团队事实上拥有了一份持续累积的代码质量档案。新人接手项目时翻历史 PR 的 AI 评审记录比翻文档更快理解「这个团队在意什么」。流程层的问题闭环比如整改项是否复核归档可以交给项目管理平台完成TaoToken 只负责模型通道这一段不在业务系统里替代表单和审批。5.2 FAQ 与最后一步用同一把 Key 去模型对话验证Q1引入 AI 审查后还需要人工复核吗需要。AI 擅长过滤常规缺陷和明显的代码异味但复杂业务架构、跨模块影响、深层安全漏洞仍需要资深工程师把关。AI 兜底不是替代人工而是让人工从 80% 的低级问题里腾出手来集中处理剩下 20% 的高价值判断。Q2AI 会不会刷一堆误报评论会。降低误报的办法是设置置信度门槛、过滤常见误报规则以及在提示词里划清边界。开发者对某条建议点了「无意义」之后这类反馈应该沉淀回团队规范让后续审查逐步贴近真实偏好。Q3私有仓库跑这套成本高吗diff 本身只是文本单次调用消耗的 token 远小于把整个仓库塞进上下文。配合缓存机制、只在 diff 基础上分析变更行成本是可控的。TaoToken 的用量可以在官网控制台查看不需要凭感觉估算。配置完这条 PR 审查链后建议先去 TaoToken 模型对话 里用同一把 Key 发一条消息确认模型 ID 和 Base URL 没填错要长期给团队做代码审查对照 Coding Plan 看套餐是否够用Key 在 控制台 API Keys 创建Claude Code 环境变量与本文的完整对照可以看 接入文档。