首页 / 文章 / CI 中的 Claude Code：对每个 Pull Request 运行代理式代码审查、测试生成与自动修复

AI技术

CI 中的 Claude Code：对每个 Pull Request 运行代理式代码审查、测试生成与自动修复

✍️ zhirenhun 📅 2026/8/2 👁 268 阅读 ⏱ 40 分钟

Claude Code在CI中的应用：在每个拉取请求上运行智能代码审查、测试生成与自动修复

本文在人工智能辅助下撰写，并经过人工监督与审核。

为什么CI中的智能代码审查会改变一切

大多数CI失败会浪费数小时进行手动干预，因为传统机器人只会标记问题，却从不修复它们。开发人员提交一个拉取请求，代码检查器失败，测试中断，然后必须有人从当前工作中切换上下文来诊断和修补问题。这种上下文切换在团队中不断累积，直到维护CI卫生的成本超过了它所提供的价值。

以自动模式运行的Claude Code通过在CI流水线中扮演自主智能体来解决这一问题。当拉取请求触发工作流时，Claude Code会审查差异、生成缺失的测试、尝试修复失败，并将结构化反馈作为审查评论发布——全程无需人工干预。开发人员获得的是可操作的修复方案，而不是错误日志。

这种区别至关重要。传统CI机器人负责检测和报告。智能CI则负责检测、修复和记录。投资回报率体现在两个方面：减少常规问题的合并时间，以及保留用于真正需要人类判断的架构决策的认知能力。

核心要点

Claude Code在自动模式下，可无人值守地运行于CI流水线中，安全分类器会在执行前拦截危险命令。
智能CI在单个工作流中完成代码审查、测试生成和自动修复——消除了手动上下文切换的循环。
生产部署需要成本控制（每次拉取请求的令牌预算）、受限的文件权限以及退出条件，以防止失控执行。
GitHub Actions、GitLab CI和Azure DevOps都通过环境变量和密钥管理支持Claude Code集成。
目前有效的模式是范围受限、职责单一的智能体——一个负责审查，一个负责测试生成，一个负责自动修复——而不是让一个智能体尝试完成所有任务。

Claude Code自动模式：在CI流水线中无人值守运行

自动模式使Claude Code能够在不进行交互确认的情况下执行命令。智能体接收任务，规划一系列操作，并将其运行完成，同时一个分类器模型会审查每个命令，以防止超出定义范围的权限升级或文件系统访问。这一安全层在CI中至关重要，因为智能体在拥有仓库写入权限和环境机密的环境中运行。

这里的失败模式微妙但代价高昂。没有自动模式时，Claude Code会在每个命令上暂停等待交互式批准。在CI中，没有终端可以进行交互，因此工作流会一直挂起直到超时。启用自动模式后，智能体会继续运行直至完成，或触发安全阻止，这两种情况都会为拉取请求产生可用的结果。

配置自动模式需要设置CLAUDE_AUTO_MODE环境变量，并在工作流清单中定义权限范围。该范围限制智能体可以读取或修改的文件。代码审查智能体应能查看整个差异，但只能写入临时评论文件。测试生成智能体需要源代码的读取权限和测试目录的写入权限。

为拉取请求设置Claude Code

智能体化CI的入口点是GitHub Actions工作流，它在拉取请求事件时触发。该工作流检出仓库、安装Claude Code，并使用与特定PR差异相关的任务描述来调用它。

// .github/workflows/claude-review.yml
name: Claude Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write

    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Full history for accurate diffs

      - name: Install Claude Code
        run: npm install -g @anthropic/claude-code

      - name: Run Code Review
        env:
          CLAUDE_API_KEY: ${{ secrets.CLAUDE_API_KEY }}
          CLAUDE_AUTO_MODE: true
          CLAUDE_SCOPE: "read:**/*.{ts,tsx,js,jsx},write:.claude/review.md"
          PR_NUMBER: ${{ github.event.pull_request.number }}
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
        run: |
          claude --task "Review the diff between $BASE_SHA and $HEAD_SHA. 
          Focus on type safety, error handling, and performance implications. 
          Write findings to .claude/review.md with specific line references and suggested fixes."

      - name: Post Review
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const review = fs.readFileSync('.claude/review.md', 'utf8');
            await github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: review
            });

此配置清晰分离了关注点。CLAUDE_SCOPE变量防止代理在审查期间修改源文件。任务描述将代理的注意力锚定在特定的质量维度上。GitHub Script操作将结果作为评论发布，将其保存在PR时间线中供将来参考。

审查步骤与现有的CI检查并行运行。如果构建失败，Claude Code仍会根据diff执行审查。如果测试失败，单独的工作流会处理自动修复。与顺序阶段相比，这种并行执行减少了总流水线时间。

在CI中自动生成测试和自动修复故障

测试生成和自动修复需要对存储库的写权限，如果代理生成格式错误的代码，这会引入风险。缓解策略是两阶段工作流：代理写入功能分支，然后人工审查代理的提交，再合并到目标分支。

// .github/workflows/claude-auto-fix.yml
name: Claude Auto-Fix

on:
  pull_request:
    types: [opened, synchronize]
  workflow_run:
    workflows: ["CI"]
    types: [completed]
    branches-ignore:
      - claude-auto-fix-*

jobs:
  fix:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    permissions:
      contents: write
      pull-requests: write

    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.ref }}
          token: ${{ secrets.GITHUB_TOKEN }}

      - name: Create Fix Branch
        run: |
          FIX_BRANCH="claude-auto-fix-${{ github.event.pull_request.number }}-$(date +%s)"
          git checkout -b "$FIX_BRANCH"
          echo "FIX_BRANCH=$FIX_BRANCH" >> $GITHUB_ENV

      - name: Install Dependencies
        run: npm ci

      - name: Run Tests to Capture Failures
        id: test
        continue-on-error: true
        run: npm test 2>&1 | tee test-output.log

      - name: Claude Auto-Fix
        if: steps.test.outcome == 'failure'
        env:
          CLAUDE_API_KEY: ${{ secrets.CLAUDE_API_KEY }}
          CLAUDE_AUTO_MODE: true
          CLAUDE_SCOPE: "read:**/*,write:src/**/*.{ts,tsx,test.ts,test.tsx}"
          CLAUDE_TOKEN_BUDGET: 50000
        run: |
          claude --task "Analyze test-output.log and fix the failing tests. 
          Generate missing tests for any new functions in the diff that lack coverage. 
          Ensure all fixes maintain type safety and existing test patterns. 
          Commit changes with a descriptive message."

      - name: Push Fix Branch
        run: |
          git config user.name "claude-code[bot]"
          git config user.email "claude-code[bot]@users.noreply.github.com"
          git push origin "$FIX_BRANCH"

      - name: Create PR for Fixes
        uses: actions/github-script@v7
        with:
          script: |
            await github.rest.pulls.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: `🤖 Auto-fix for PR #${{ github.event.pull_request.number }}`,
              head: process.env.FIX_BRANCH,
              base: '${{ github.event.pull_request.head.ref }}',
              body: `Automated fixes generated by Claude Code for failing tests in PR #${{ github.event.pull_request.number }}.

              Review the changes carefully before merging.`
            });

CLAUDE_TOKEN_BUDGET 环境变量为智能体在此任务中的令牌总使用量设定了上限。如果没有此限制，失控循环——智能体生成导致新失败的代码，然后尝试修复这些失败——可能会迅速消耗配额。对于大多数测试套件，50,000 个令牌的预算通常足以覆盖诊断、代码生成和验证。

这里采用了一种防御性模式。智能体写入单独的分支，从不直接写入 PR 分支。这形成了一个人工审批门禁：开发人员审查自动修复 PR，确认更改正确后，将其合并到原始 PR 中。如果自动修复引入了回归，开发人员将关闭自动修复 PR 并手动处理该问题。

具体到测试生成，任务描述应参考现有测试套件的模式。如果项目使用具有特定断言风格的 Vitest，提示词中必须包含示例。如果没有这种锚定，Claude Code 会默认使用通用的 Jest 模式，这些模式可能与项目的约定不匹配。

对比：Claude Code vs 传统 CI 机器人 vs 人工审查

传统的 CI 机器人能够检测违规行为，但从不修复它们。人工审查能够捕获问题，但随着团队扩大，扩展性不佳。Claude Code 则处于中间地带：它自动修复机械性问题，同时将复杂问题标记出来供人工审查。

这里的含义是，智能体式 CI 不会取代人类在架构决策、安全边界或产品需求方面的审查。它取代的是修复 lint 错误、添加缺失的空值检查以及生成样板测试等机械性重复工作。当一个团队每天合并数十个 PR 时，节省的时间会不断累积。

传统机器人在一致性方面表现出色。它们执行样式规则时不知疲倦。智能体式 CI 擅长修复。它应用的修复方案遵循人类会使用的相同模式，但无需付出上下文切换的成本。人工审查擅长判断。人类能够捕捉到看似无害的更改所隐含的安全影响，而这些是任何静态分析工具都无法标记的。

有效的模式是将三者结合起来。传统机器人首先作为快速门禁运行。如果它们失败，Claude Code 会尝试自动修复。如果自动修复成功，PR 将进入人工审查阶段，以处理非机械性问题。如果自动修复失败，开发人员将收到机器人的报告以及 Claude 对修复未能收敛原因的分析。

生产模式：成本控制、受限权限与安全分类器

在生产环境中部署智能体CI需要三项控制：防止成本失控的令牌预算、限制爆炸半径的受限文件权限，以及阻止危险操作的安全分类器。

令牌预算根据计费约束设置在仓库级别或每个PR级别。按仓库设置的月度预算可防止单个恶意或配置错误的PR耗尽组织配额。按PR设置的预算可确保多个PR同时到达时资源分配公平。代价是复杂性：按PR预算需要在工作流运行之间跟踪状态，通常存储在仓库密钥或数据库中。

受限权限使用glob模式定义读写边界。审查智能体需要read:**/*，但write:.claude/review.md。测试生成智能体需要read:src/**/*,read:tests/**/*和write:tests/**/*.test.ts。重构智能体需要更广泛的写权限，因此其预算应更低，且其输出应始终落在审查分支上。

安全分类器在命令执行前运行。分类器模型评估命令是否尝试提升权限、访问网络资源或修改声明范围之外的文件。如果分类器标记某条命令，智能体会收到错误并必须选择替代方法。这一点很重要，因为提示可能包含微妙的注入攻击，诱使智能体运行curl或rm -rf。

开发人员最常遇到的故障模式是范围配置错误。如果范围过窄，智能体无法完成任务，工作流会静默失败。如果范围过宽，智能体在尝试修复局部问题时可能会修改无关文件。解决方案是试运行模式，让Claude Code记录其预期操作而不执行，使开发人员能够在启用自动模式前验证范围正确性。

对于管理多个仓库的团队，共享工作流配置模板可减少配置漂移。该模板定义标准范围、预算和任务描述。各个仓库通过仓库变量覆盖特定值。这种集中化避免了一个团队发现关键安全改进而其他团队继续运行易受攻击配置的情况。

真实世界的CI集成：GitHub Actions、GitLab CI和Azure DevOps

GitHub Actions提供了最直接的集成方式，因为它原生支持密钥、矩阵构建和可重用工作流。前面显示的工作流清单在GitHub托管的运行器上运行，但有合规要求的团队可以使用预装了Claude Code二进制文件的自托管运行器。

GitLab CI需要一个包含Claude Code二进制的Docker镜像，因为GitLab的运行器不会在作业之间保留全局npm安装。推荐的做法是基于node:20-alpine构建自定义Docker镜像，并预装Claude Code。然后，该镜像会出现在.gitlab-ci.yml配置中：

# .gitlab-ci.yml
claude-review:
  image: registry.gitlab.com/yourorg/claude-code:latest
  stage: review
  only:
    - merge_requests
  script:
    - export CLAUDE_API_KEY=$CLAUDE_API_KEY_SECRET
    - export CLAUDE_AUTO_MODE=true
    - export CLAUDE_SCOPE="read:**/*.{ts,tsx,js,jsx},write:.claude/review.md"
    - claude --task "Review the merge request diff for type safety and error handling. Write findings to .claude/review.md."
    - |
      curl --request POST \
        --header "PRIVATE-TOKEN: $CI_JOB_TOKEN" \
        --form "body=<.claude/review.md" \
        "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/notes"

Azure DevOps 使用管道变量来存储机密，并同时支持 YAML 和经典编辑器管道。YAML 方法为管道定义提供了版本控制：

# azure-pipelines.yml
trigger:
  - none

pr:
  branches:
    include:
      - main
      - develop

pool:
  vmImage: 'ubuntu-latest'

steps:
  - checkout: self
    fetchDepth: 0

  - task: NodeTool@0
    inputs:
      versionSpec: '20.x'

  - script: npm install -g @anthropic/claude-code
    displayName: 'Install Claude Code'

  - script: |
      export CLAUDE_API_KEY=$(CLAUDE_API_KEY)
      export CLAUDE_AUTO_MODE=true
      export CLAUDE_SCOPE="read:**/*.{ts,tsx,js,jsx},write:.claude/review.md"
      claude --task "Review PR diff focusing on async error handling and null safety. Output to .claude/review.md."
    displayName: 'Run Claude Code Review'

  - task: GitHubComment@0
    inputs:
      gitHubConnection: 'github-connection'
      repositoryName: '$(Build.Repository.Name)'
      id: $(System.PullRequest.PullRequestNumber)
      comment: |
        $(cat .claude/review.md)

对于在多语言环境中运作的团队来说，跨平台的差异至关重要。GitHub Actions 提供了最丰富的预建操作生态，可用于发布评论、创建 issue 和管理标签。GitLab CI 与 GitLab 内置的代码审查功能提供了更紧密的集成。Azure DevOps 可与企业合规工具集成，并支持复杂的审批工作流。

不同平台的凭据管理方式各有差异，但都遵循一种常见模式：将 Claude API 密钥存储在平台的机密管理器中，在运行时将其作为环境变量注入，绝不要记录它或写入磁盘。对于有密钥轮换策略的组织，集成应支持从外部保管库（如 HashiCorp Vault 或 AWS Secrets Manager）读取，而不是使用静态的平台密钥。

智能体 CI 的未来：当前有效的方法与应避免的陷阱

目前有效的模式是限定范围、职责单一的智能体。一个智能体负责代码审查并发布评论；另一个智能体生成测试；第三个智能体针对特定失败类别尝试自动修复。这些智能体独立运行，每个都有自己的令牌预算和权限范围。

应避免的做法：一个试图处理所有任务的单一整体式智能体。其失败模式是级联复杂性。如果智能体的审查任务失败，其测试生成任务就永远不会运行；如果测试生成消耗了全部令牌预算，自动修复就永远不会执行。结果是不可预测的，使得调试 CI 失败比 Claude Code 出现之前更加困难。

2026 年正在兴起的模式是声明式智能体编排。开发者不再编写命令式任务描述，而是在清单中声明期望的结果：“所有新函数都必须有测试；所有失败的测试都必须自动修复；所有 PR 都必须有审查评论。”编排层决定调用哪些智能体、以什么顺序、以及使用多少预算。

另一个有前景的方向是成本感知调度。当 PR 到达时，编排层会根据差异（diff）大小和历史使用模式估算每个智能体的令牌成本。如果估算成本超过每个 PR 的预算，编排层会选择一部分智能体来运行，或请求人工批准以增加预算。这避免了 5000 行重构在单次工作流运行中消耗一周配额的情况。

开发者应避免在没有人监督的情况下使用智能体 CI 进行架构审查或安全审计。Claude Code 擅长检测类型错误、缺失的空值检查和模式不一致。它无法评估数据库架构迁移是否会导致停机，或者 API 更改是否破坏与移动客户端的向后兼容性。这些问题需要人类根据系统级上下文做出判断，而目前没有任何智能体具备这种上下文。

采用智能体CI的团队应首先在非关键存储库中进行代码审查和测试生成。衡量Claude建议的准确性、无需修改即可合并的自动修复百分比，以及合并时间的缩短。使用这些指标来校准token预算和权限范围，然后再扩展到生产存储库。在几十个PR内，投资回报率（ROI）就会变得清晰：花在机械修复上的时间减少，用于设计讨论的时间增多。

常见问题

在CI中运行Claude Code，每个拉取请求的成本是多少？

成本取决于diff大小、任务复杂度和模型层级。对于一个典型的修改了200行的PR，代码审查任务大约消耗5,000-10,000个token（输入和输出合计），在Claude 3.5 Sonnet上花费0.15-0.30美元。测试生成和自动修复任务更昂贵，对于复杂修改通常达到20,000-50,000个token（0.60-1.50美元）。团队应设置每个PR的预算，并监控实际使用情况以优化成本。

Claude Code能自动修复静态分析检测到的安全漏洞吗？

当给出静态分析报告并允许访问受影响的文件时，Claude Code可以针对已知漏洞模式应用补丁。但是，它不应成为安全修复的唯一机制。推荐的模式是：静态分析检测问题，Claude Code生成建议补丁，人类安全工程师在合并前审查补丁。这可以防止智能体在修复原始漏洞的同时引入不同漏洞的情况。

在自动修复工作流中，如果Claude Code生成了错误的代码，会发生什么？

两阶段工作流（智能体写入特性分支，人类在合并前审查）可防止错误代码到达目标分支。如果自动修复引入了回归，开发者关闭自动修复PR并手动处理问题。此外，CI流水线在创建PR之前对自动修复分支运行测试，因此大多数回归都会被自动捕获。

在拉取请求激增期间，如何防止Claude Code耗尽API配额？

在工作流级别使用作业并发组实现速率限制。GitHub Actions支持concurrency键，当同时运行的任务过多时，这些键会对作业进行排队。在所有Claude Code工作流中设置全局并发限制，以限制并行执行。例如，concurrency: claude-code-${{ github.repository }}确保每个存储库一次只运行一个Claude工作流。

Claude Code是否支持包含多种语言的monorepo？

是的，但作用域配置会变得更复杂。为每种语言定义独立的作用域：TypeScript 使用 read:packages/typescript/**/*,write:packages/typescript/tests/**/*.test.ts，Python 使用 read:packages/python/**/*,write:packages/python/tests/**/*_test.py。使用单独的工作流或条件步骤来调用特定于语言的代理。Claude API 本身与语言无关；代理会根据其在代码库中观察到的模式进行调整。

以上涵盖了在 CI 中运行 Claude Code 的基本模式。在生产环境中应用这些模式，你将立刻看到不同：更少的上下文切换、更快的 PR 合并，以及为真正需要人类洞察力的架构决策保留认知能力。