结论：把 AI 编程智能体接进 CI，第一个该落地的场景是「只读的自动评审」，不是自动提交代码。先用 pull_request 触发让智能体输出评审意见，跑两周把误报率压下去，再开 workflow_run 失败自愈；顺序反过来，你会同时收获一堆污染主干的 bot 提交和一次刹不住的循环触发。
为什么 CI 是 AI 编程真正的放大器
本地用智能体写代码，瓶颈从来不是生成速度，而是反馈回路太长：写完 → 自己跑测试 → 看报错 → 再改。 CI 的价值在于把这条回路变成无人值守的确定性事件——每次推送都强制跑一遍，结果可追溯，失败有记录。
Anthropic 官方的 claude-code-action 与 GitHub 官方的 Agentic Workflows 都指向同一个方向：把智能体从”对话框里的助手”变成”仓库里的一个自动化角色”。差别在于前者是 Action，配置在 .github/workflows/；后者用 Markdown 描述意图，再由 gh aw 扩展编译成 Workflow 。
三种接入模式与权限分级
先按风险给三种模式分级，再决定开哪个。这张表是我在实际仓库里收敛出来的划分方式：
| 模式 | 触发方式 | GitHub 权限 | 风险等级 | 建议上线顺序 |
|---|---|---|---|---|
| 自动 PR 评审 | pull_request: [opened, synchronize] | contents: read + pull-requests: write | 低（不写代码） | 第 1 个开 |
| @提及交互 | issue_comment 含触发词 | contents: write、issues: write | 中（按需改代码） | 第 2 个开 |
| CI 失败自愈 | workflow_run: [completed] 且结论为 failure | contents: write + pull-requests: write | 高（自动提交） | 最后开 |
权限不是形式主义。contents: read 是评审模式的安全边界——即使提示词被注入，智能体也推不动任何代码。
最小可用配置：自动 PR 评审
这是最值得先落地的一段 YAML，官方 Action 的写法已经足够简洁：
name: Auto PR Review
on:
pull_request:
types: [opened, synchronize]
paths-ignore: ['**.md', 'docs/**']
jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
id-token: write
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 1
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: |
REPO: ${{ github.repository }}
PR NUMBER: ${{ github.event.pull_request.number }}
请只检查三件事：逻辑错误与边界条件、安全隐患（注入/越权/数据泄露）、新增代码路径是否有测试覆盖。
用 gh pr comment 发表结论，不要在消息里输出长篇评审。
claude_args: |
--allowedTools "Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"
--max-turns 4三个必须写进去的参数
--max-turns：硬性轮次上限。自动评审给 4 轮足够（读 diff 、看上下文、发评论），交互模式给 6，自愈模式最多 8 。不设上限是预算失控的头号原因。--allowedTools：白名单。评审模式只需要gh pr相关的只读命令，把 Bash 全开等于把仓库写权限交给模型。paths-ignore：文档改动不触发评审。否则每个 README 修正都要烧一次调用。
从评审走向自动修复：三条护栏
失败自愈是收益最高也最容易翻车的模式。开之前先把这三条写进 workflow：
- 分支前缀隔离：让智能体只往
fix/auto-ci-${{ github.run_id }}这类分支推，并在提示词里明确”不要处理以 fix/auto-ci- 开头的分支”，否则它修完再推会再次触发自己，形成无限循环。 - 并发控制：加
concurrency: { group: auto-fix-${{ github.ref }}, cancel-in-progress: true }，保证同一分支同时只有一个自愈任务在跑。 - 强制人工闸门：只开 draft PR，并默认需要 CODEOWNER 审核才能合并。自动修复的正确定位是”产出候选补丁”，不是”直接进主干”。
成本怎么控
智能体进 CI 后最大的隐性成本是触发频率 × 单轮上下文。三条见效最快的手段：
fetch-depth: 1浅克隆，别让智能体拉全量历史塞进上下文。- 评审范围限定：用
paths只对src/auth/**、src/api/**这类关键目录做安全评审，其余路径走普通流程。 - 结构化输出用于分流：让智能体输出 JSON（如严重程度 + 是否阻断），流水线据此决定要不要 @ 人，避免每条 PR 都打扰人工。评审标准本身可以直接复用我们整理过的 AI 代码评审清单，比每次在提示词里重写一遍稳定得多。
为什么不推荐一上来就用 GitHub Agentic Workflows？
Agentic Workflows 的思路很漂亮——用 Markdown 写意图，gh aw 编译成 Workflow，改需求也用自然语言。但它目前仍是 public preview，且编译产物 .lock.yml 需要和源文件一起提交管理。
对已经有一套 CI 约定的团队，我建议先用官方 Action 把评审跑通，把”AI 意见到底准不准”这个问题验证清楚，再考虑换声明式的写法。工具形态是次要的，评审质量才是主要矛盾。
上线前的检查清单
- 密钥只放
secrets，绝不进仓库文件；能用 OIDC 就别用长期 API Key 。 - 权限块按最小集写，评审模式不要给
contents: write。 - 先在一个低活跃度仓库跑一周，统计误报率和平均耗时。
- 自愈模式的分支前缀隔离必须先于自动提交上线。
安全侧的检查项可以直接对照 AI 生成代码安全审查清单；如果想让本地智能体和 CI 里的行为保持一致，把规则抽成 Claude Code Hooks 复用，比两边各写一份提示词可靠。
评论 (0)