把 Claude 接入 GitHub 开发与审查流程

在 GitHub 评论里写一句 @claude，就能让 Claude 读仓库、修改代码、提交 PR。但接入之后，真正需要弄清楚的是：谁能触发它、它能改什么、结果发到哪里，以及一次任务会消耗多少额度。

原文围绕 Claude Code GitHub Actions，串起安装、自动审查、权限和成本控制。结论很明确：它适合接边界清楚的小任务，也适合充当 PR 的第二位读者；要用进团队流程，工作流约束比一句提示词更重要。原文称资料核对于 2026 年 10 月 29 日，涉及快速变化的配置，不能把它当成永久有效的说明书。

先分清：你要的是自动改代码，还是自动审查

名字相近的几个入口，维护责任不同。

anthropics/claude-code-action 在你的 GitHub runners 上运行，工作流、凭证、权限都由团队配置。它能响应 @claude，也能通过 prompt 在指定事件上自动执行。接工单、修 CI、定时整理信息，属于这一类。

托管的 Code Review 则运行在 Anthropic 基础设施上，面向 Team、Enterprise，不需要维护 YAML。它用多个 agent 阅读变更，再验证、去重、按严重程度整理发现，输出行内评论、摘要和名为 Claude Code Review 的检查。Quick、Standard、Deep 三档中，Standard 是默认档，越深入成本越高。

但托管审查不会构建或运行代码，也不会批准、阻止 PR，检查结果不会以失败结束。启用 Zero Data Retention 或 HIPAA 配置的组织不能使用它。

如果只想在推送前检查自己的分支，本地 /code-review 就够了，各计划均可使用。Claude Code in the cloud 是云端会话入口，Agent SDK 则适合 GitHub 之外的自动化，不能混为同一个产品。

安装 Action 的快捷路径是进入仓库运行 claude，再执行 /install-github-app。前提是拥有仓库管理员权限，并安装 GitHub CLI、完成 gh auth login。它会安装 App、保存 secret、推送工作流分支，并打开待创建 PR 的页面，合并后才算接通。该命令只支持 github.com。

手动安装则需要 App、secret 和 .github/workflows/ 下的工作流。API key 使用 ANTHROPIC_API_KEY，传入 anthropic_api_key；订阅凭证由 claude setup-token 生成，保存为 CLAUDE_CODE_OAUTH_TOKEN，传入 claude_code_oauth_token。

个人项目可以考虑订阅 token，但任务会占用个人额度。团队使用 API key 更容易交接，因为 OAuth token 绑定生成者的订阅，人员离开或套餐变化都可能让自动化失效。

自动审查跑绿了，为什么 PR 上没有评论

Action 不再需要通过 mode 选择模式：没有 prompt 是交互模式，提供 prompt 就是自动化模式。

交互模式默认识别完整单词 @claude，/claude 和 @claude-bot 不算，触发词可用 trigger_phrase 修改。自动化模式则默认把结果写进运行日志，任务成功不等于已经发布审查。

下面这段原文配置解决的是「PR 更新后，自动审查并发表评论」：

name: Code Review
on:
  pull_request:
    types: [opened, synchronize, ready_for_review, reopened]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      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 }}
          plugin_marketplaces: "https://github.com/anthropics/claude-plugins-official.git"
          plugins: "code-review@claude-plugins-official"
          prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
          claude_args: '--allowedTools "mcp__github_inline_comment__create_inline_comment"'

重点是 --comment 和最后一行 --allowedTools：前者要求发布评论，后者让 Action 启动负责行内评论的 MCP 服务。即使 skill 的 frontmatter 已声明工具，原文仍要求保留这一行。

这里代码权限是只读；评论能力由 Action 的认证和工具配合提供。审查者不需要推送代码，没必要照搬改代码任务的写权限。

按原文描述，这套审查会跳过草稿、已关闭、被判断为自动化或过于简单的 PR，以及已有 Claude 评论的 PR。因此，配置监听 synchronize，也不能直接推断每次追加提交都会重新审查。原文没有把重复审查策略解释清楚。

公开仓库的 fork PR 还有凭证限制：GitHub 不向这类运行提供 secrets，示例只适用于同仓库分支。旧安装也要留意，v2.1.229 之前生成的审查工作流只把结果写入日志，需要更新。

权限要分层，评论入口不能等同于授权入口

能在评论里看见一条指令，不代表就应该执行它。

原文列出两道执行前检查：issue、PR 事件的触发者必须拥有仓库写权限；所有事件中的 bot actor 默认被拒绝，除非列入 allowed_bots。放行特定无写权限用户，需要 allowed_non_write_users，并提供自己的 github_token。

还要区分 App 安装权限与 job 的 permissions。官方 App 被多个 Claude 功能共用，授权范围远超 Action 需要的 Contents、Issues、Pull requests，GitHub 又不允许安装时只接受其中一部分。组织若只允许必要权限，可以创建自定义 GitHub App，但它仅覆盖 Action，托管 Code Review 和网页 auto-fix 仍需要官方 App。

具体到 job，改代码任务才需要 contents: write；actions: read 让它读取 CI 结果，id-token: write 用于默认 GitHub App 认证。工具范围还应通过 --allowedTools 约束，特定命令可以用 Claude Code hooks 阻断。

另一处容易踩坑的是 CI：如果传入 github_token: ${{ secrets.GITHUB_TOKEN }}，默认 GITHUB_TOKEN 创建的提交不会触发后续工作流。原文建议恢复 Action 默认的 App 认证，或使用自定义 App token，并检查 CI 是否监听 push、pull_request。

项目规则也有信任边界。CLAUDE.md 每次运行都会读取，适合放项目约束；具体操作流程放进按需加载的 skills。托管 Code Review 的 REVIEW.md 从基准或默认分支读取，不采用当前 PR 修改后的版本，避免贡献者顺手改变审查规则。

限制轮数还不够，时间和并发也要管

一次任务同时消耗 GitHub Actions 分钟数和模型用量。API key 走 API 计费，OAuth token 占订阅额度，原文没有给出每个 PR 的平均价格。

它提供的轮数配置是 claude_args: "--max-turns 5 --model claude-sonnet-5"，并建议用 timeout-minutes: 15 限制运行时间。轮数、时间都不是金额硬上限，代码量和上下文长度仍会影响开销。

下面的原文配置按 issue 或 PR 编号限制并行运行：

concurrency:
  group: claude-${{ github.event.issue.number || github.event.pull_request.number }}
  cancel-in-progress: false

注意 cancel-in-progress: false：它不取消正在运行的任务，不能理解为后来的评论都会被忽略。

请求质量同样影响成本。「修复 UserDashboard.tsx 在 user.profile 为 null 时的 TypeError，并增加修复前失败的测试」，比「修一下 dashboard」更容易收敛。设计没确定时，先问方案，再让它实现。

定时任务也遵循相同逻辑。原文示例使用 cron: "0 9 * * *"、--model claude-opus-5-5，并授权 mcp__github__list_commits,mcp__github__list_issues。普通文本 prompt 默认没有 shell 或 GitHub API 工具，要通过 --allowedTools 或 settings 中的 permissions.allow 开放。任务只从默认分支运行，公开仓库连续 60 天无活动会被关闭调度，结果默认仍在日志里。

我的判断

我认同它先约束权限、再考虑自动化范围的顺序。前端空值修复、文档修正、依赖更新都有较明确的验收条件；「提升整个应用性能」则连瓶颈在哪里都没定义，直接交给 agent 很容易得到难以评估的大改动。

但原文没有提供修复成功率、审查误报率、单次成本，也没有比较人工审查、Action 插件和托管服务。开头「二十分钟出现 PR」是作者的经历描述，不能当作交付时效承诺。托管服务的多 agent 验证流程，也不能直接推出它审得更准。

对只需要审查的 Team、Enterprise，托管方案能减少 YAML 维护；需要执行命令、跑检查、接工单的团队，Action 更灵活。两者都应保留人工审查，尤其是认证、计费和数据删除代码。

原文末尾已经截断，不能替作者补出未提供的后续结论。

能拿来做什么

• 先用一个验收条件明确的前端或 Node 小问题试运行，在请求中写出文件、复现条件、预期行为和测试要求，再检查 PR 是否真的满足这些条件。
• 接自动审查时，同时验证运行日志和 PR 评论，重点检查 --comment、行内评论工具，以及当前 PR 是否属于跳过范围。
• 团队统一管理 API 凭证，将轮数、超时、并发和版本固定集中到可复用工作流；高权限 Action 可按原文建议固定完整 commit SHA。
• 把团队稳定规则压缩进 CLAUDE.md，不要把每项任务的操作手册都塞进去。原文用 600 行文件提醒成本问题，但没有给出最优长度，取舍应围绕规则是否必要。