1. 为什么要把Claude Code搬进CI工作流先说个我自己的场景。团队里PR评审一直是个瓶颈小改动还好遇到跨模块的改动光靠人肉review一遍少说也得二三十分钟而且经常漏掉一些潜在风险。我最早把思路放在给Claude Code写一个本地脚本在pre-push钩子里跑一遍代码检查效果还行但问题也很明显只有我本地有配置换个同事的电脑就跑不起来再一个本地的Node版本、Claude Code版本、提示词脚本都各不一致结果压根没法统一。后来我研究了一圈发现Claude Code本身提供了比较完善的非交互模式non-interactive mode配合命令行参数和CI工具链完全可以直接跑在GitHub Actions的runner里。也就是说我们可以在云端创建一个完全干净的运行环境拉取最新代码让Claude Code自动完成代码审查、Bug扫描、安全检查甚至可以自动提交修复PR。整个过程不依赖任何人的本地环境只要写入工作流文件的Agent就能在任何一次push或者PR触发时自动执行。这有多大价值举个真实例子我们有一个后端服务改了数据库表结构之后迁移脚本写得不规范靠代码review其实很难发现问题因为是运行时才会暴露的。后来我用Claude Code在CI里加了自动审查它会根据改动内容自动对比历史迁移文件识别出缺少索引或默认值处理不当的情况通过在PR评论里给出具体修改建议准确率比我们预期高很多。从那以后我就认真把Claude Code和GitHub Actions的集成当做一个正式项目来推进。这篇文章适合谁第一已经在用Claude Code做本地代码辅助、想把它提升到团队级自动化水准的人第二在GitHub上维护开源项目、希望减少重复性issue处理和维护工作的人第三想了解如何安全地在CI环境里使用大模型API、但不想踩太多坑的人。我会从环境准备、密钥管理、坑点排查到完整的可运行工作流一步步拆开来讲为你提供一份可以直接抄作业的方案。2. 动手前的工程决策哪些任务适合放进CI里跑哪些不适合2.1 先给Claude Code在CI里的角色定个位在写第一行YAML之前我先花了点时间想清楚Claude Code在自动化流程里到底该扮演什么角色。这不只是为了图省事而是为了避免把CI工作流变成一个随意调用API的黑箱这既浪费钱也难以维护。Claude Code最擅长的场景可以归纳为三类基于上下文的代码理解类任务比如这个PR改了哪些文件、影响面有多大、有没有潜在风险它通过读取diff和代码库结构来推理不依赖固定的规则模板比传统静态检查工具灵活得多。重复性文档和代码维护任务比如根据代码改动自动更新CHANGELOG、修正过时的注释、补充缺失的JSDoc注释这类任务有明确输入输出适合在CI里批处理。质量门禁与风险预警类任务比如在合并前自动扫描提交的代码里是否存在密钥硬编码、SQL注入模式或者不安全的依赖使用Claude Code能以接近代码评审者的视角来识别这些问题。不适合在CI里跑的也有三类一是涉及敏感数据读取和业务私密逻辑深度交互的任务因为API请求内容会经过第三方模型服务安全边界要做额外的判断二是执行时间过长、容易受外部网络或第三方接口状态影响的任务因为CI超过30到60分钟往往就会触发平台超时三是结果不具备确定性、需要和团队反复沟通才能定型的设计类任务这类场景更适合本地交互式使用而不是放到无人值守的自动化流程里。2.2 触发方式与成本预期我建议从pull_request开始GitHub Actions的触发方式五花八门push、pull_request、schedule、workflow_dispatch都可以。但接入API型工具时我强烈建议先从PR触发做起而不是全局push触发。原因很简单PR本身就代表一个待审查的变化有明确的目的适合让Claude Code去分析而每次push到任意分支都会触发不仅API消耗大增还容易产生大量噪音输出。另外一个容易被忽视的点是运行成本和额度控制。Claude Code默认会调用Anthropic API一次代码审查的token消耗通常在几万到十几万之间具体取决于仓库规模和改动范围。如果团队用的是付费账号就需要特别注意触发频率。我的建议是在workflow文件里加上一个简单的过滤逻辑比如只对main分支的PR、只对代码文件的PR生效。在Actions的YAML里可以通过paths参数来控制触发条件比如on: pull_request: types: [opened, synchronize] paths: - src/** - tests/** - !docs/**这样只有改动src或tests目录下的文件时Claude Code才会跑一遍审查。docs目录下的文档变更则直接跳过既省了额度也省了代码审查机器人的无意义评论。2.3 版本锁定与可复现性原则CI环境最大的风险之一就是不可复现性。Claude Code更新频繁今天跑通的工作流可能下个月就因为某个CLI参数变更而失败。我不建议在工作流里写总是安装最新版更好的做法是明确指定版本。实际的安装方式可以直接用npm在Actions的step里指定版本号- name: Install Claude Code run: npm install -g anthropic-ai/claude-code1.0.x这里把版本固定到某个中间版本既不会因为小版本的升级而意外失效又能拿到该大版本内的最新修复。如果你的项目已经用package.json管理依赖也可以把anthropic-ai/claude-code作为devDependency加入再通过npx claude调用这样版本完全跟着项目走。不过一个要注意的细节是把Claude Code放进项目依赖的话任何一个开发者clone仓库后执行npm install都会把Anthropic SDK装到本地有些对依赖体积敏感的项目不太喜欢这种方式所以这个取舍看团队的实际要求。3. 核心工作流基于PR自动审查的完整YAML实现3.1 工作流骨架与权限设计现在开始写真正的工作流。我的目标很明确当开发者向main分支提交PR时在CI环境里启动Claude Code它以非交互模式读取PR的代码改动进行分析然后把审查结果作为评论发布到PR里。先从最基础的骨架开始name: Claude Code PR Review on: pull_request: types: [opened, synchronize] paths: - src/** - tests/** permissions: contents: read pull-requests: write jobs: review: runs-on: ubuntu-latest env: ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}这里有个细节值得展开讲一下permissions字段。GitHub Actions的GITHUB_TOKEN默认权限在不同设置下并不相同如果仓库的Actions配置开启了限制那么默认权限可能是只读的。而我们后续要用gh pr comment往PR里写评论就必须要pull-requests: write权限。很多人第一次跑工作流失败往往就卡在这里日志里报的是Resource not accessible by integration排查了一圈才发现是权限没给够。密钥方面我建议把Claude Code的API密钥存储在仓库的Settings - Secrets and variables - Actions里命名为ANTHROPIC_API_KEY。不要在workflow里直接写明文密钥也不要图省事直接把本地环境变量文件塞进CI配置。如果用的是Anthropic Console生成的密钥建议单独创建一个用于CI的key不要和本地开发共用同一个这样即使未来需要轮换密钥也不会影响开发机的缓存配置。3.2 检查代码与安装CLI接下来是checkout和安装步骤。很多人直接在step里用默认的actions/checkoutv4这在大部分场景没问题但如果你想让Claude Code的PR评审结果包含diff信息需要特别注意fetch深度。默认checkout只拉取当前提交的代码不包含合并基础merge base所以无法准确计算PR相对于目标分支的变更范围。我通常这样做- name: Checkout code uses: actions/checkoutv4 with: fetch-depth: 0fetch-depth: 0会拉取完整的git历史。对于大型仓库这会增加不少时间和存储开销。更折中一点的方式是fetch-depth: 2或者通过ref属性单独指定目标分支来获取合并基础具体的做法是先取一遍目标分支再取当前分支。但为了普适性和成功率我建议在初始阶段直接使用完整历史省去很多细节层面的麻烦。安装Claude Code这一步需要结合Node环境- name: Setup Node.js uses: actions/setup-nodev4 with: node-version: 20 - name: Install Claude Code run: npm install -g anthropic-ai/claude-codeNode版本不要用太老的Claude Code的CLI对Node版本有一定的要求至少18以上我用20一直很稳。安装时如果网络环境特殊还可以给npm配置registry镜像但GitHub官方runner自带npm源大部分情况能直接装上。可以在安装完后跑一句claude --version确认版本方便排查问题。3.3 核心执行非交互模式下如何让Claude Code审查PR这是整个工作流的灵魂。Claude Code本地使用时是交互式终端可以一个问题接着一个问题来回对话但在CI里没有tty设备也没有人可以跟进输入所以必须使用非交互模式。我常用的方式是claude -p 你是一名资深代码评审专家请审查当前PR的代码改动重点关注潜在Bug、安全漏洞、代码风格一致性问题。给出具体的修改建议并输出简洁的Markdown格式报告。-p参数也写作--print的作用就是非交互模式Claude Code会直接读管道输入执行完请求后把结果输出到stdout然后退出。这是一种非常干净的执行方式适合CI场景。如果你需要更复杂的逻辑比如让Claude Code自动执行多个命令或读取多个文件可以加--verbose看详细执行过程也可以把提示词写得更具体。关于提示词我的经验是越具体越好。一个模糊的审查这个PR得到的结果往往也是泛泛而谈。我更推荐把审查范围、关注重点、输出格式都写在提示词里。比如我们在团队内部用的是这样一段较长但是效果稳定的提示词你是团队的资深代码评审助手。请基于当前git diff进行代码审查。 重点关注 1. 逻辑错误和边界条件处理不当的问题 2. 安全风险包括但不限于注入、敏感信息泄露、不安全的反序列化 3. 性能和可维护性隐患 4. 与项目常见模式的偏离 输出要求 - 使用Markdown格式按严重程度从高到低排列 - 每个问题需要给出对应的文件路径和行号如果可确认 - 同时给出具体的修改建议注明建议的理由 - 如果发现无明显问题直接回复没有发现明显问题不要为了凑数而强行找问题为什么强调最后一条因为如果提示词里不约束输出长度Claude Code倾向于热情地给出6个改进建议哪怕代码已经写得不错也会为了显得认真而硬找出几个问题。这种无效评论不仅让人反感加上还要消耗额外的token和API费用得不偿失。3.4 把结果写回PR评论区Claude Code跑完之后stdout里就是一份Markdown格式的审查报告接下来只需要把这份报告通过GitHub CLI写回PR。这一步的做法是在step中设置id来捕获上一步的输出- name: Run Claude Code Review id: review env: ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} run: | REVIEW_OUTPUT$(claude -p …提示词…) echo review_outputEOF $GITHUB_OUTPUT echo $REVIEW_OUTPUT $GITHUB_OUTPUT echo EOF $GITHUB_OUTPUT - name: Post Review Comment env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | gh pr comment $PR_NUMBER --body $REVIEW_CONTENT这里有几个值得注意的小技巧GITHUB_OUTPUT是GitHub Actions新版输出变量的标准方式不要再用被废弃的set-output命令。多行输出的处理非常容易踩坑直接用echo可能会把换行符吃掉或者导致YAML解析错误用heredoc包裹就能安全通过。获取PR编号可以通过${{ github.event.pull_request.number }}直接拿到不需要额外解析。GH_TOKEN用的是Actions自动注入的GITHUB_TOKEN不需要手动创建独立的Personal Access Token。但正如前面说的这要求工作流的permissions里声明了pull-requests: write。3.5 完整工作流文件直接可用的版本把上面所有内容组合起来一份可以直接粘贴到.github/workflows/claude-review.yml的完整版本如下name: Claude Code PR Review on: pull_request: types: [opened, synchronize] paths: - src/** - tests/** permissions: contents: read pull-requests: write jobs: claude-review: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv4 with: fetch-depth: 0 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: 20 - name: Install Claude Code run: npm install -g anthropic-ai/claude-code - name: Run Claude Code Review id: review env: ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} run: | REVIEW_OUTPUT$(claude -p 你是团队的资深代码评审助手。请基于当前git diff进行代码审查。重点关注1. 逻辑错误和边界条件处理不当的问题2. 安全风险3. 性能和可维护性隐患4. 与项目常见模式的偏离。输出要求使用Markdown格式按严重程度从高到低排列每个问题给出文件路径和修改建议。如果无明显问题直接回复没有发现明显问题。) echo review_outputEOF $GITHUB_OUTPUT echo $REVIEW_OUTPUT $GITHUB_OUTPUT echo EOF $GITHUB_OUTPUT - name: Post Review Comment env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} PR_NUMBER: ${{ github.event.pull_request.number }} run: | gh pr comment $PR_NUMBER --body ${{ steps.review.outputs.review_output }} - name: Fail on critical issues if: contains(steps.review.outputs.review_output, 严重) run: | echo 发现严重问题PR无法自动通过 exit 1最后一个step是一个可选的质量门禁逻辑如果Claude Code在评论里标记了严重级别的关键词就让整个job失败从而阻止PR自动合并。这种方式可以结合仓库的branch protection规则来设置必须让Claude Review通过才能合并从而把大模型变成团队流程里的一个自动守门人。当然这里的关键词匹配非常粗糙只适合作为初级玩法后面我会聊更精细的结构化输出方案。4. CI环境里最容易翻车的五个坑与完整排查链路4.1 权限配置导致的Resource not accessible by integration这个错误是我见过频率最高的。现象是gh pr comment执行时报错显示无法访问PR评论API但工作流本身确实触发了。根因基本都能锁定在两方面一是仓库的Actions权限设置二是workflow里permissions声明缺失。排查链路可以按顺序来先看报错是不是发生在Post Review Comment这一步并确认报错内容是Resource not accessible by integration打开workflow文件的permissions字段确认是否包含pull-requests: write如果没有加上如果加了还是不生效去仓库的Settings - Actions - General查看Workflow permissions设置选择Read and write permissions然后重新触发工作流看是否恢复正常。这一步还有个小概率的原因如果你在同一个job里先调了actions/checkout又用了gh命令而gh依赖的GITHUB_TOKEN可能被checkout步骤以不安全的方式传递导致权限丢失。通常的做法是在需要使用token的step里显式指定GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}就像我在示例里做的那样而不是依赖全局环境。4.2 fetch-depth不足导致Claude Code看不到完整diff第二种高发问题是Claude Code执行时分析了半天结果产出的报告里全是我无法判断改动范围之类的废话。究其原因往往是actions/checkout只拉取了当前提交没有拉历史记录git diff结果为空或只有一个commit的信息。Claude Code在非交互模式下看不到有效的diff自然只能凭着当前文件快照做宽泛解读。排查步骤在Run Claude Code Review之前插入一个临时调试step执行git log --oneline -5和git diff HEAD~1 --stat看看历史记录和差异是否存在。如果输出显示只有一个commit说明fetch-depth过浅在checkout中改成fetch-depth: 0或显式指定fetch-depth: 2。对于在pull_request事件下的运行还可以考虑让Claude Code直接比较github.event.pull_request.base.sha和github.event.pull_request.head.sha但这需要对提示词和脚本做更多的定制我在生产环境里暂时没有选择这种方案。这个坑最麻烦的地方在于它不是直接报错而是静默地输出低质量结果不仔细看审查报告根本发现不了。所以我建议在刚开始搭建时一定要让Claude Code的提示词明确提及基于当前git diff进行审查并加上--verbose跑一次看看它到底读到了什么。4.3 多步骤的引用与输出传递错误第三种坑属于Actions语法层面的常见失误。比如在Post Review Comment里直接引用steps.review.outputs.review_output如果上一把执行因为某个小错误没写id或者GITHUB_OUTPUT的值没成功保存评论区就会得到一串空的Markdown或者直接报未找到步骤输出。排查时最直接的办法是查看Actions日志中steps展开后的内容。如果发现表达式被原样输出而不是替换为实际值那基本是因为当前job中缺少对应的id或上下文路径不对。用${{ steps.review.outputs.review_output }}的前提是定义了这个输出的step必须拥有id: review且该step的run脚本里确实把值写进了环境。这两个条件缺一不可。4.4 API密钥误用和日志泄漏风险在CI里使用API密钥最大的危险不在于密钥本身被偷而在于输出内容意外写入日志。Claude Code在某些情况下会输出调试信息、环境变量或提示词展开内容如果这些内容里包含密钥日志里就会留下明文一旦日志公开或者被恶意读取后果很严重。我做的预防措施有三层第一在workflow的env里加载密钥而不是在run命令中内嵌第二给Claude Code的执行step加上ANTHROPIC_API_KEY这个变量但同时在step级别设置set -e和合适的日志级别第三考虑在Actions的日志脱敏设置里把ANTHROPIC_API_KEY加入脱敏规则。虽然GitHub本身会对标注为secret的值做日志打码但API密钥出现在进程的stdout里时未必总能被自动识别所以自己做好预防更稳妥。4.5 并发运行导致API额度爆炸团队人多起来之后会出现一种只有一台CI在跑时一切正常一旦同时开几个PRAPI额度瞬间爆掉的情况。本质上是每个job独立调用了Claude Code没有做集中的并发控制。我的做法是给工作流加上concurrency配置concurrency: group: claude-review-${{ github.event.pull_request.number }} cancel-in-progress: false这里按PR编号做分组同一个PR内的多个job不会同时跑但不同PR之间可以并行。如果需要全仓库串行就把group改成claude-review-main这样同一时间只有一个Claude Code在执行成本可控但代价是多个PR会排队等待评审时间变长。具体怎么取舍取决于团队的PR并发量和API预算。三个月的实测下来我推荐按PR分组因为同一PR内的synchronize事件和opened事件产生的job才最需要避免重复不同PR之间的并行通常在预算允许范围内。5. 深入机制Claude Code的非交互执行模式与提示词工程细节5.1 -p模式的真正行为机制很多人把claude -p和通过管道往一个非交互式终端里输一行字划等号这个理解不全面。-p模式实际上是Claude Code启动一个轻量级的Agent会话在该会话中它可以像交互模式下一样自己决定调用哪些工具比如读取文件、执行命令、搜索代码等只不过没有人类在后面继续下达新指令。这意味着什么意味着即使你在提示词里写了请审查当前git diffClaude Code也可能会自己去运行git status、git diff、甚至逐个打开相关文件来获取上下文而不是仅仅依赖输入的那一句话。这既是一个优势——它能自主获取更完整的信息也是一个风险——它可能会在CI沙盒里执行你预期之外的命令。为了控制这种行为我建议在提示词里明确限制工具使用范围比如你只能运行git log、git diff、git show这三个命令来获取代码变更信息。不要执行任何修改代码的命令也不要运行测试。如果你的场景需要Claude Code自动修改代码并提交PR那就需要换一套提示词并加上相应的工具授权。这个差异在本地交互模式下感觉不明显因为你可以随时叫停但在CI里一旦跑起来就是无人值守所以限制工具边界是必须做的安全配置。5.2 如何让输出更结构化而不是一坨Markdown如果你的工作流只是把Claude Code的输出原样贴到PR评论里那问题不大。但如果你想通过Claude Code的输出结果来控制CI流程比如决定是否让job失败那纯文本Markdown的解析就非常不可靠翻车概率极高。我用的方案是让Claude Code以JSON结构化输出关键判断项然后再通过命令行工具去解析JSON字段。一个简单的提示词片段审查结束后在报告末尾单独输出一个JSON片段不包含在代码块中格式如下 {critical_issues: 0, warnings: 3, summary: 一句话总结}然后CI脚本里用python3 -c或者jq去提取critical_issues字段大于零就让job失败。这个方式的优点是稳定、明确不会因为Claude Code多写了一行我认为还不错导致误判。缺点是提示词偶尔会被模型忽略所以我在实际执行时会写得更明确请确保JSON片段是输出内容的最后一段不要放在代码块中否则系统无法解析。加了这句之后失败率明显下降。5.3 多文件仓库的上下文管理不该让Claude Code读整个仓库Claude Code在非交互模式下很勤快如果你不给它边界它会自己探索整个仓库。在一个几万文件的monorepo里这会导致两个后果一是token消耗剧增二是探索时间过长CI job耗时可能会从几分钟膨胀到二三十分钟甚至超过平台限制。我的解决思路是预处理diff信息并把它直接塞进提示词里作为附带上下文而不是让Claude Code自己去看代码。具体做法是先在CI里生成diff摘要DIFF_CONTENT$(git diff origin/main...HEAD -- src tests | head -c 8000)然后拼到提示词里以下是本次PR的完整diff内容只截取前8000字符 diff$DIFF_CONTENT/diff 请基于以上内容进行代码审查不要运行git diff命令也不要读取额外文件。这样做的优势是Claude Code的工作量被严格限制在输入上下文里它不需要漫无目的地读文件执行时间大幅缩短token开销也稳定可控。缺点是diff非常长的PR会被截断可能漏掉尾部内容但对绝大多数常规PR来说这种方式的效果和稳定性要好得多。如果你处理的PR规模真的极大那就应该让工作流先把diff拆分成多个块分多次调用Claude Code最后合并结果这个我放到后面的进阶部分说。6. 进阶玩法让Claude Code在Actions里从评论员变成执行者6.1 自动修复并提交PR的分支模式前面提到的PR审查只是动口不动手进阶玩法是让Claude Code真的改代码、跑测试、提交修复然后推送回PR分支。这种模式一旦跑稳团队效率会提升一个量级但也要非常小心地控制风险。我把这种工作流称为自动修复机器人核心逻辑是工作流被标记为workflow_dispatch手动触发或者通过label比如auto-fix指定触发checkout后Claude Code以claude -p --allowedTools Edit, Write, Bash的方式执行修复任务任务完成后检查git status是否有改动如果有改动commit、push然后通过gh pr comment告诉开发者我已经提交了自动修复请再次检查;如果没有改动通过评论告诉开发者代码检查通过无需修改。在这个流程里权限配置比之前更严格。要让Claude Code能运行git push需要contents: write权限同时GITHUB_TOKEN自动关联了当前repo的读写能力。但这也意味着一个失控的提示词可能导致Aagent向你的主干分支推送恶意修改。我强烈建议使用独立分支开发并在分支保护规则里禁止任何非人工review的代码直接合并到main分支。实际操作中我建议只在feature分支上开启自动修复main分支的改动必须经过人工review。6.2 定时任务夜间自动安全检查另一个我在团队里落地得很成功的场景是定时安全巡检。把工作流触发条件设为on: schedule: - cron: 0 2 * * *每天凌晨2点跑一次。此时checkout主分支然后让Claude Code执行如下任务扫描代码里是否有硬编码密钥、依赖中是否有已知的高危版本、是否存在明显的安全反模式输出一份Markdown报告并提交到一个固定的issue里。这样做的好处是团队每天早上打开issue就能看到一份安全巡检日报不需要任何人工执行成本。这套定时任务比PR审查更稳定因为没有diff变化输入是相对固定的代码快照。需要注意的一点是GitHub的schedule事件有最短间隔限制最低粒度是5分钟一次而且实际触发时间可能会有延迟但这种场景完全够用。6.3 接入本地或在第三方模型端点关于模型选择很多团队受限于账号或者网络环境不一定能直接用官方的Anthropic API。Claude Code在CI里发挥价值的核心其实是Agent的流程控制能力它本身设计上支持自定义API端点这也为接入第三方兼容服务或者你本地环境部署的本地模型留出了空间。实际做法是通过环境变量指定模型端点ANTHROPIC_BASE_URLhttps://your-api-endpoint.example.com ANTHROPIC_AUTH_TOKENyour-token在Node环境中ANTHROPIC_API_KEY仍然是主要的认证变量但如果你要接的是兼容Anthropic协议的服务商优先按他们的文档设置ANTHROPIC_BASE_URL和对应的token。这个方案的关键在于你使用的模型端点必须兼容Anthropic的Messages API格式否则Claude Code无法驱动工具调用。我在自建环境和一些第三方接入方案上试过只要端点协议对齐工作流本身几乎不需要改。使用这个方案的时候CI集成层面的成本控制更友好因为你可以把预算成本汇聚到你自己的模型服务上而不是按次计费的官方API。但这也意味着你要自己负责模型服务的高可用和延迟如果夜间调度时模型服务刚好在重启CI job就会直接失败。如果你正在考虑这条路线建议在workflow里加上失败重试逻辑或者把定时任务与服务健康检查做联动。7. 把工作流做到更稳日志、监控与团队协作规范7.1 每次调用都留痕Claude Code在CI里的执行过程本质上是一系列API调用和工具操作的组合。要想排查问题、优化成本就必须留痕。我建议在每个job里加上一个收集Claude Code执行日志的步骤把stdout和stderr分别存到claude-log-${{ github.sha }}.txt作为artifact上传。- name: Upload Claude Code log if: always() uses: actions/upload-artifactv4 with: name: claude-review-log path: claude-log-*.txt别小看这一步。当出现提示词执行结果不符合预期、API反复报错或者成本异常飙升时这些日志是唯一能还原现场的资料。而且if: always()很重要——即使前面的step因为严重问题而退出失败日志依然会被保留下来。7.2 团队规范里要写清楚的三件事Claude Code接入CI之后有几个规范层面的问题需要团队事先达成共识否则很容易出现机器人在吵架的混乱局面。谁来查看评论每条PR上多了一个机器人的评论默认情况下所有开发者都要看但如果评论内容太泛久而久之大家就会忽略它失去门禁的意义。自动修复的边界是什么Claude Code自动改代码时哪些类型的修改可以做比如lint修复、注释补全、版本号更新哪些必须人工介入比如业务逻辑重构、接口设计变更这个边界不写清楚自动修复甚至会变成事故源头。人工review依然是第一责任主体。大模型输出的审查意见可以参考但不能作为代码可以合并的充分条件。团队需要有明确的配合关系Claude Code负责出报告、给出建议工程师负责确认并做最终决策。我在实际推行过程中给团队立了一条执行约定Claude Code的审查意见如果涉及阻断级别问题PR不能自动合并但如果只是建议、提示级别的意见开发者有权忽略并说明原因。这既保留了自动化的效率也避免了机器人说不行就必须不行这种教条化的工作方式。8. 实测下来的几个关键数值与调优建议跑了一段时间以后我积累了一些相对有参考意义的数字可以给你一个预期参考在一次中等规模改动约500行代码的PR审查任务中Claude Code实际运行时间大约在1到3分钟之间token消耗大约8万到15万其中输入token占大头因为我们把diff和仓库结构塞进了context。如果使用默认的探索式审查、不限制文件读取范围运行时间可能翻倍token消耗也可能增长50%以上。如果觉得Token成本偏高我的建议顺序是先限制上下文让Claude Code只读diff再把输出格式改成结构化的JSON摘要减少冗长的叙述最后再考虑切换模型版本比如从更贵的旗舰模型降级到更轻量的模型来完成简单的文档类任务。模型的取舍要看任务复杂度但我个人的经验是代码审查这类任务的核心价值在Agent的工具调用和流程控制模型本身的能力差距固然存在但上下文管控和提示词设计的优化空间往往更大。另外还有一个很容易忽略的点GitHub Actions的job运行时间是有上限的公开仓库的workflow一般有6小时限制私有仓库限制更严格一些。如果你的仓库特别大、Claude Code的探索任务特别重建议在workflow里设置timeout-minutes: 30之类的显式超时这样即使遇到异常情况比如网络卡住或者模型服务挂起也不会无限期占用runner产生不必要的费用。你还可以在同一个工作流里并行跑多个收集任务的step比如一个step负责审查前端代码一个step负责审查后端代码最后汇总结果。这种做法能缩小单次任务的上下文范围提高并行效率缺点是需要在脚本层面合并多个输出团队里如果有人不熟悉shell脚本这个方案就会变成一个维护负担。我在最后一个实际运行场景里是把Claude Code工作流与仓库的Codeowners文件做了联动只有对应模块的owner才会被自动到PR评论里其它无关人员不会被机器人打扰。这个联动只涉及一点点GitHub Actions的脚本书写但对团队体验的提升非常明显避免了每个PR都提醒全组人的骚扰感。你可以根据仓库规模来决定要不要做到这一步。