前言
在这个系列里,CI/CD 其实一直在出现——测试指南里提过测试自动化,Git 指南里把 CI 作为 PR 流程的一环。但从来没有一篇文章系统地讲过:怎么把 Claude Code 嵌入 CI/CD 流水线,让它在你不在的时候也能干活。
本地开发时,Claude Code 是你的结对编程伙伴。但它的能力远不止于此——通过 Headless 模式和 GitHub Actions 集成,它可以变成你团队的 7×24 自动化协作者:自动审查 PR、自动修复 lint 错误、甚至从 Issue 直接生成 PR。
这篇文章把 Claude Code 的 CI/CD 能力讲透。
一、为什么要在 CI/CD 中使用 Claude Code
1.1 手动 Code Review vs Claude Code 自动审查
| 维度 | 手动 Code Review | Claude Code 自动审查 |
|---|---|---|
| 响应速度 | 等待审查者有空(几小时到几天) | PR 创建后几分钟内 |
| 覆盖面 | 受审查者精力和专业领域限制 | 系统性检查所有变更文件 |
| 一致性 | 因人而异,标准不统一 | 遵循 CLAUDE.md 中的统一规范 |
| 可用性 | 工作时间、时区限制 | 7×24 全天候 |
| 成本 | 高级工程师的时间 | API 调用费用(通常更低) |
| 深度 | 能理解业务上下文 | 擅长发现模式性问题和潜在 bug |
注意: Claude Code 不是要替代人工 Code Review,而是作为第一道防线。它能快速发现明显问题,让人工审查者把精力集中在架构决策和业务逻辑上。
1.2 Claude Code 在流水线中的位置
代码提交
↓
CI 触发(lint、测试、构建)
↓
Claude Code 自动审查 ← 第一道防线
↓
人工 Code Review ← 聚焦架构和业务
↓
合并
↓
CD 部署
Claude Code 最适合放在 CI 检查之后、人工审查之前。这样它拿到的是已经通过基础检查的代码,审查质量更高。
二、Headless 模式基础
要在 CI/CD 中使用 Claude Code,核心是 Headless 模式——不需要交互式终端,通过命令行参数和管道完成所有操作。
2.1 核心参数
| 参数 | 说明 | 示例 |
|---|---|---|
-p, --print | 非交互模式,执行后直接输出结果 | claude -p "分析这段代码" |
--output-format | 输出格式:text、json、stream-json | claude -p --output-format json "..." |
--max-turns | 限制 Agent 循环次数,防止失控 | claude -p --max-turns 10 "..." |
--model | 指定模型 | claude -p --model claude-sonnet-4-6 "..." |
--allowedTools | 白名单:只允许使用指定工具 | claude -p --allowedTools "Read,Grep,Glob" "..." |
--disallowedTools | 黑名单:禁止使用指定工具 | claude -p --disallowedTools "Bash,Write" "..." |
--permission-mode | 权限模式 | claude -p --permission-mode plan "..." |
2.2 基础用法
简单分析:
# 分析一个文件
claude -p "分析 src/utils.ts 的代码质量,指出潜在问题"
# 管道输入
cat src/utils.ts | claude -p "审查这段代码"
# 分析 git diff
git diff main | claude -p "审查这些变更,指出潜在问题"JSON 输出(适合后续处理):
claude -p --output-format json "分析 src/utils.ts 的代码质量"返回结构:
{
"result": "分析结果文本...",
"is_error": false,
"total_cost_usd": 0.023,
"session_id": "abc123"
}限制工具(安全审查场景):
# 只读模式:只允许读取和搜索,不能修改任何文件
claude -p --allowedTools "Read,Grep,Glob" "审查 src/ 目录下的所有 API 端点安全性"2.3 环境变量
| 变量 | 说明 |
|---|---|
ANTHROPIC_API_KEY | API 密钥(CI 中必须设置) |
CLAUDE_MODEL | 默认模型(可被 --model 覆盖) |
CLAUDE_MAX_TURNS | 默认最大轮次 |
在 CI 环境中,ANTHROPIC_API_KEY 必须通过 Secrets 注入,绝对不要硬编码在配置文件或代码中。
三、GitHub Actions 集成
GitHub Actions 是 Claude Code CI/CD 集成最成熟的方案。Anthropic 提供了官方 Action,开箱即用。
3.1 官方 GitHub Action
# .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
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: |
审查这个 PR 的代码变更。关注:
1. 潜在的 bug 和逻辑错误
2. 安全漏洞
3. 性能问题
4. 代码风格一致性
请用中文回复。这个最基础的配置就能让 Claude Code 在每次 PR 创建或更新时自动审查代码,并把审查结果作为 PR 评论发出来。
3.2 配置选项
anthropics/claude-code-action@v1 支持的主要参数:
| 参数 | 说明 | 默认值 |
|---|---|---|
anthropic_api_key | API 密钥 | 必填 |
prompt | 自定义提示词 | 内置审查提示 |
model | 模型选择 | claude-sonnet-4-6 |
max_turns | 最大轮次 | 10 |
allowed_tools | 允许的工具列表 | 全部 |
disallowed_tools | 禁止的工具列表 | 无 |
timeout_minutes | 超时时间 | 10 |
3.3 自动化 Code Review
更完善的 Code Review 工作流:
name: Claude Code Review
on:
pull_request:
types: [opened, synchronize]
paths:
- 'src/**'
- 'lib/**'
- 'app/**'
jobs:
review:
runs-on: ubuntu-latest
# 跳过 draft PR 和 bot 创建的 PR
if: |
github.event.pull_request.draft == false &&
github.event.pull_request.user.login != 'dependabot[bot]'
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
model: claude-sonnet-4-6
max_turns: 10
prompt: |
你是一个严格但友好的代码审查者。请审查这个 PR 的所有变更。
审查重点:
1. **正确性**:逻辑错误、边界条件、空值处理
2. **安全性**:注入漏洞、敏感信息泄露、权限问题
3. **性能**:不必要的循环、内存泄漏、N+1 查询
4. **可维护性**:命名清晰度、函数复杂度、重复代码
输出格式:
- 🔴 必须修复:阻塞性问题
- 🟡 建议修改:改进建议
- 🟢 做得好:值得肯定的地方
如果没有发现问题,直接说"LGTM"即可,不要硬凑问题。3.4 自动修复 PR
Claude Code 不仅能审查,还能直接修复问题:
name: Claude Auto Fix
on:
issue_comment:
types: [created]
jobs:
auto-fix:
# 只在 PR 评论中触发,且评论包含 /claude-fix
if: |
github.event.issue.pull_request &&
contains(github.event.comment.body, '/claude-fix')
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.issue.pull_request.head.ref }}
fetch-depth: 0
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
max_turns: 20
allowed_tools: "Read,Grep,Glob,Edit,Write,Bash"
prompt: |
根据这个 PR 的审查评论,修复所有提到的问题。
修复后,用 git 提交变更。
提交信息格式:fix: <修复内容的简要描述>使用方式:在 PR 评论中输入 /claude-fix,Claude Code 就会自动读取审查意见并修复代码。
3.5 Issue 驱动开发
最强大的用法——从 Issue 直接生成 PR:
name: Claude Issue to PR
on:
issues:
types: [labeled]
jobs:
implement:
# 只在添加 "claude" 标签时触发
if: github.event.label.name == 'claude'
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
issues: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
max_turns: 30
prompt: |
阅读 Issue #${{ github.event.issue.number }} 的内容。
根据 Issue 描述:
1. 创建一个新分支:claude/issue-${{ github.event.issue.number }}
2. 实现 Issue 中描述的功能或修复
3. 确保代码通过 lint 和测试
4. 创建一个 PR,标题引用 Issue 编号
5. 在 PR 描述中说明实现方案
遵循项目的 CLAUDE.md 中的编码规范。工作流程:创建 Issue → 描述需求 → 添加 claude 标签 → Claude Code 自动实现 → 生成 PR → 人工审查 → 合并。
四、其他 CI 平台集成
不用 GitHub Actions?没关系。Claude Code 的 Headless 模式可以在任何 CI 平台上运行。
4.1 GitLab CI
# .gitlab-ci.yml
claude-review:
stage: review
image: node:20
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
before_script:
- npm install -g @anthropic-ai/claude-code
script:
- |
git diff origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME...HEAD > /tmp/diff.txt
REVIEW=$(claude -p --output-format text --max-turns 10 \
--allowedTools "Read,Grep,Glob" \
"审查以下代码变更,指出潜在问题:$(cat /tmp/diff.txt)")
echo "$REVIEW"
# 将审查结果发布为 MR 评论
curl --request POST \
--header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
--header "Content-Type: application/json" \
--data "{\"body\": \"## Claude Code Review\n\n${REVIEW}\"}" \
"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests/${CI_MERGE_REQUEST_IID}/notes"
variables:
ANTHROPIC_API_KEY: $ANTHROPIC_API_KEY4.2 通用 CI 模式
不管用什么 CI 平台,核心模式都一样:
#!/bin/bash
# scripts/claude-review.sh
set -euo pipefail
# 1. 获取变更
DIFF=$(git diff origin/main...HEAD)
if [ -z "$DIFF" ]; then
echo "没有代码变更,跳过审查"
exit 0
fi
# 2. Claude Code 审查
REVIEW=$(echo "$DIFF" | claude -p \
--output-format text \
--max-turns 10 \
--allowedTools "Read,Grep,Glob" \
"审查这些代码变更。关注 bug、安全漏洞和性能问题。如果没有问题,回复 LGTM。")
# 3. 输出结果
echo "$REVIEW"
# 4. 检查是否有阻塞性问题(可选)
if echo "$REVIEW" | grep -q "🔴"; then
echo "::error::Claude Code 发现了阻塞性问题"
exit 1
fi在任何 CI 平台中调用这个脚本即可:
# Jenkins, CircleCI, Azure DevOps, etc.
- run: bash scripts/claude-review.sh
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}4.3 Docker 方式
如果你的 CI 环境不方便安装 Node.js:
# .claude/Dockerfile
FROM node:20-slim
RUN npm install -g @anthropic-ai/claude-code
ENTRYPOINT ["claude"]# 在 CI 中使用
steps:
- run: |
docker build -t claude-code -f .claude/Dockerfile .
git diff main | docker run -i \
-e ANTHROPIC_API_KEY=${{ secrets.ANTHROPIC_API_KEY }} \
claude-code -p --max-turns 10 "审查这些变更"五、安全最佳实践
在 CI/CD 中运行 AI Agent,安全是第一优先级。
5.1 API Key 管理
✅ 正确做法:
- 使用 CI 平台的 Secrets 管理(GitHub Secrets、GitLab Variables 等)
- 定期轮换 API Key
- 不同环境使用不同的 Key
❌ 错误做法:
- 硬编码在 YAML 文件中
- 提交到 Git 仓库
- 在日志中打印 Key
5.2 工具权限控制
CI 环境中,Claude Code 的���限应该尽可能收紧:
# 只读审查(最安全)
- uses: anthropics/claude-code-action@v1
with:
allowed_tools: "Read,Grep,Glob"
prompt: "审查代码变更"
# 可修复(需要写权限)
- uses: anthropics/claude-code-action@v1
with:
allowed_tools: "Read,Grep,Glob,Edit,Write"
disallowed_tools: "Bash"
prompt: "修复 lint 错误"
# 完整权限(谨慎使用)
- uses: anthropics/claude-code-action@v1
with:
disallowed_tools: "WebFetch,WebSearch"
prompt: "实现这个功能"经验法则: 审查用只读,修复加写权限,实现功能才给 Bash。永远禁止网络工具,除非你确实需要。
5.3 防止 Prompt 注入
CI 中的 Claude Code 会读取 PR 标题、描述、评论等用户输入。恶意用户可能尝试注入指令:
# 不要直接拼接用户输入到 prompt
# ❌ 危险
prompt: "审查这个 PR:${{ github.event.pull_request.title }}"
# ✅ 安全:让 Claude Code 自己读取 PR 信息
prompt: "审查当前 PR 的代码变更,关注安全和正确性"5.4 安全检查清单
| 检查项 | 说明 |
|---|---|
| API Key 在 Secrets 中 | 不在代码或配置文件中 |
| 工具权限最小化 | 只给必要的工具权限 |
| max_turns 有限制 | 防止无限循环消耗 token |
| 网络工具已禁用 | 防止数据泄露 |
| 用户输入未直接拼接 | 防止 prompt 注入 |
| 输出不包含敏感信息 | 审查结果不泄露 secrets |
六、成本控制
CI/CD 中的 Claude Code 调用量可能很大,成本控制很重要。
6.1 模型选择策略
| 场景 | 推荐模型 | 原因 |
|---|---|---|
| 简单 lint 修复 | Haiku | 快速、便宜,足够处理格式问题 |
| Code Review | Sonnet | 性价比最高,审查质量好 |
| 复杂功能实现 | Opus | 需要深度理解和多步推理 |
| PR 描述生成 | Haiku | 模板化任务,不需要强推理 |
# 根据任务选择模型
- uses: anthropics/claude-code-action@v1
with:
model: claude-sonnet-4-6 # Code Review 用 Sonnet
max_turns: 10
# 简单任务用 Haiku
- uses: anthropics/claude-code-action@v1
with:
model: claude-haiku-4-5
max_turns: 56.2 触发条件优化
不是每个 PR 都需要 Claude Code 审查:
on:
pull_request:
types: [opened, synchronize]
paths:
# 只审查源代码变更,忽略文档、配置等
- 'src/**'
- 'lib/**'
- 'app/**'
- '!**/*.md'
- '!**/*.mdx'
jobs:
review:
# 跳过 draft PR
if: github.event.pull_request.draft == false
# 跳过 bot PR
if: github.event.pull_request.user.login != 'dependabot[bot]'6.3 max_turns 策略
| 任务类型 | 推荐 max_turns | 说明 |
|---|---|---|
| Code Review(只读) | 5-10 | 读取 diff + 分析 |
| Lint 修复 | 10-15 | 读取 + 修改 + 验证 |
| 功能实现 | 20-30 | 多文件读写 + 测试 |
| Bug 修复 | 15-20 | 调查 + 修复 + 验证 |
max_turns 是成本控制的最有效手段。设太低会导致任务完不成,设太高会浪费 token。根据任务复杂度调整。
6.4 成本监控
# 使用 JSON 输出获取成本信息
- name: Claude Review
id: review
run: |
RESULT=$(claude -p --output-format json --max-turns 10 "审查代码变更")
COST=$(echo "$RESULT" | jq -r '.total_cost_usd')
echo "cost=$COST" >> $GITHUB_OUTPUT
echo "Claude Code 审查成本: \$$COST"
# 可以设置成本告警
- name: Cost Alert
if: steps.review.outputs.cost > 1.0
run: echo "::warning::Claude Code 单次审查成本超过 $1.0"七、CLAUDE.md 的 CI 适配
Claude Code 在 CI 中也会读取项目的 CLAUDE.md。你可以针对 CI 场景添加专门的规则。
7.1 CI 专用规则示例
# CLAUDE.md
## CI/CD 规则
当在 CI 环境中运行时(检测到 CI=true 环境变量):
### Code Review
- 只关注本次 PR 变更的文件,不要审查未修改的代码
- 审查结果分三级:🔴 必须修复、🟡 建议修改、🟢 做得好
- 如果没有问题,直接回复 "LGTM",不要硬凑问题
- 不要建议重构未修改的代码
### 自动修复
- 只修复明确的问题(lint 错误、类型错误),不要顺便重构
- 每次修复后运行相关测试确认没有破坏
- 提交信息格式:fix: <简要描述>
### 安全
- 不要在输出中包含任何环境变量的值
- 不要读取 .env 文件
- 不要执行网络请求7.2 项目上下文
CI 中的 Claude Code 和本地一样,会读取项目的完整上下文:
CLAUDE.md → 项目规范和 CI 规则
.claude/settings.json → Hooks 和权限配置
package.json → 依赖和脚本
tsconfig.json → TypeScript 配置
.eslintrc → Lint 规则
这意味着你在本地配置好的规范,CI 中也会自动遵守。不需要在 CI 配置中重复写一遍。
八、实战:完整的 PR 自动化流水线
把前��所有内容串起来,构建一个完整的 PR 自动化流水线。
8.1 流程设计
开发者提交 PR
↓
CI 基础检查(lint、测试、构建)
↓
Claude Code 自动审查
↓
审查通过 → 等待人工审查
审查不通过 → 开发者修复 或 评论 /claude-fix 自动修复
↓
人工审查通过
↓
合并
8.2 完整工作流配置
# .github/workflows/claude-pr-pipeline.yml
name: Claude PR Pipeline
on:
pull_request:
types: [opened, synchronize]
paths:
- 'src/**'
- 'lib/**'
- 'app/**'
issue_comment:
types: [created]
jobs:
# Job 1: 自动审查
review:
if: |
github.event_name == 'pull_request' &&
github.event.pull_request.draft == false
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
model: claude-sonnet-4-6
max_turns: 10
allowed_tools: "Read,Grep,Glob"
timeout_minutes: 10
prompt: |
审查这个 PR 的代码变更。
审查重点:
1. 正确性:逻辑错误、边界条件、空值处理
2. 安全性:注入漏洞、敏感信息泄露
3. 性能:不必要的循环、内存泄漏
4. 可维护性:命名、复杂度、重复代码
输出格式:
- 🔴 必须修复(附具体文件和行号)
- 🟡 建议修改
- 🟢 做得好
没有问题就说 LGTM。
# Job 2: 自动修复(评论触发)
auto-fix:
if: |
github.event_name == 'issue_comment' &&
github.event.issue.pull_request &&
contains(github.event.comment.body, '/claude-fix')
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.issue.pull_request.head.ref }}
fetch-depth: 0
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
model: claude-sonnet-4-6
max_turns: 20
allowed_tools: "Read,Grep,Glob,Edit,Write,Bash"
disallowed_tools: "WebFetch,WebSearch"
prompt: |
阅读这个 PR 的所有审查评论,修复提到的问题。
修复后:
1. 运行 lint 确认通过
2. 运行测试确认没有破坏
3. 提交变更,信息格式:fix: <描述>8.3 使用流程
- 开发者提交 PR
- CI 跑 lint 和测试
- Claude Code 自动审查,发表评论
- 如果有问题:
- 开发者自己修复,或
- 在 PR 评论中输入
/claude-fix,Claude Code 自动修复
- 审查通过后,人工审查者做最终确认
- 合并
九、常见问题
Q: CI 中的 Claude Code 和本地有什么区别?
A: 功能完全一样,只是通过 -p 参数以非交互模式运行。它同样会读取 CLAUDE.md、settings.json 等项目配置。主要区别是 CI 中通常会限制工具权限(比如禁止网络访问)。
Q: Claude Code 审查的结果可靠吗? A: 对于模式性问题(空值处理、类型安全、常见安全漏洞)非常可靠。对于业务逻辑的正确性,它可能缺乏上下文。所以建议作为第一道防线,不替代人工审查。
Q: 成本大概是多少? A: 取决于 PR 大小和模型选择。一个中等大小的 PR(改动 200-500 行),用 Sonnet 审查大约 $0.02-0.05。用 Haiku 做简单任务更便宜。一个月下来,中等活跃的团队(每天 5-10 个 PR)大约 $30-50。
Q: 可以让 Claude Code 直接合并 PR 吗? A: 技术上可以,但强烈不建议。Claude Code 应该是辅助工具,最终的合并决策应该由人来做。自动合并的风险太高。
Q: 多个 Claude Code 工作流会冲突吗? A: 不会。每个工作流运行在独立的环境中,有自己的 checkout 和会话。但要注意 auto-fix 工作流推送的 commit 会触发新的 CI 运行,可能导致循环。用条件判断(如检查 commit author)来避免。
Q: 私有仓库可以用吗?
A: 可以。Claude Code 在 CI 中运行时,代码已经 checkout 到本地,不需要额外的仓库访问权限。只需要 ANTHROPIC_API_KEY 和 GitHub token(Actions 自动提供)。
总结
Claude Code 的 CI/CD 集成核心就两件事:
- Headless 模式让 Claude Code 能在任何自动化环境中运行 —
-p参数 + 工具权限控制 + 成本限制,三板斧搞定 - GitHub Actions 官方集成让 PR 自动化开箱即用 — 自动审查、自动修复、Issue 驱动开发,选你需要的组合
从最简单的自动 Code Review 开始,跑通了再逐步加入自动修复和 Issue 驱动。不要一上来就搞全套自动化——先让团队习惯 AI 审查的存在,再慢慢扩展。
推荐阅读
- Claude Code 测试工作流指南 — 测试自动化与 CI 的配合
- Claude Code Git 工作流指南 — Git 操作与 PR 流程
- Claude Code Hooks 指南 — 本地自动化的确定性执行
- CLAUDE.md 完全指南 — 项目规范配置
- Claude Code 性能与成本控制指南 — CI 场景下的成本优化
- Claude Code 安全最佳实践 — CI/CD 中的安全防护
- Claude Code GitHub Actions 官方文档 — 官方集成文档