实战：把 GitHub 接进 Claude Code（MCP）

用 Claude Code 写代码很爽，但写完还是得切到浏览器去建 PR、看 CI、回 issue。这一步割裂感，MCP 能消除——把 GitHub 接进 Claude Code，让 Agent 直接操作仓库、issue、PR、CI，工作流才真正闭环。

一、两条路：远程 MCP Server vs 自建本地

路 A：GitHub 官方远程 MCP Server。 GitHub 提供了官方 MCP Server（HTTPS），直接配置就能用，覆盖 issue/PR/repo/CI 等主流能力。绝大多数人该走这条——不用自己写，维护由官方负责。

路 B：自建本地 MCP Server。 如果你要接的是企业 GitHub Enterprise、或需要 GitHub 之外的自定义能力（公司内部的 project management），自己写一个（用 MCP SDK 包一层 GitHub API）。少数场景才需要。

先走 A，不够再上 B。

二、配置到 Claude Code

在项目的 .mcp.json（随仓库共享）或全局配置里加 GitHub MCP Server：

// .mcp.json
{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer <YOUR_GITHUB_TOKEN>"
      }
    }
  }
}

Token 怎么来：在 GitHub Settings → Developer settings → Personal access tokens（fine-grained）生成一个，只勾必需权限：

• 仓库读取（看 issue/PR/code）
• issue/PR 读写（如果要让 Agent 建 PR、回 issue）
• workflow（如果要触发 CI）

最小权限原则：别用 classic token 给全 repo 权限。fine-grained token 按仓库、按操作粒度授权，泄露了影响面可控。

三、配置 Token 的安全姿势

token 写进 .mcp.json 有泄露风险（误提交进 git）。两个安全姿势：

1. 环境变量 + .gitignore。.mcp.json 里用变量占位，实际值从环境读（Claude Code 支持 env 注入）：

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer ${GITHUB_MCP_TOKEN}" }
    }
  }
}

.mcp.json 进 git，token 放 .env（.gitignore）或系统 keychain。

2. 全局配置而非项目配置。把 github server 配在用户级（~/.claude.json）而不是项目级，token 不进仓库。

四、实际用法：让工作流闭环

配好后重启 Claude Code，它就能调用 GitHub 能力了。几个真正提效的场景：

1. "看一下 issue #123，在当前仓库实现它，提 PR" Agent 读 issue → 理解需求 → 改代码 → 建分支 → 提 PR，并在 PR 描述里引用 issue。全程终端完成。

2. "CI 为什么挂了？" Agent 读最近一次 CI 的日志（通过 MCP 拉构建结果）→ 定位失败的测试/编译错误 → 改代码 → 推上去重跑。

3. "这个 PR 的 review 评论处理一下" Agent 读 PR 上的 review 评论 → 逐条回应（改代码或回复）→ 推更新。

4. "把今天完成的 feature 发个 release note" Agent 读自上次 release 以来的 merged PR → 汇总成 changelog → 发 release。

这些以前都要切浏览器、手动点选，现在一句话。MCP 的价值就是把这些"上下文切换"消除掉。

五、什么该让 Agent 做、什么别

让 Agent 直接操作 GitHub（建 PR、合并、删分支）前，想清楚：

• 读操作放心做：读 issue、PR、CI 日志、代码——只读，零风险。
• 写操作加护栏：建 PR、推分支、回评论——可以做，但合 PR、删分支、改 release 这类不可逆的，建议人工确认（Claude Code 默认对写操作会让你确认，别关掉）。
• 权限收窄：token 只给必需权限，仓库范围限定。Agent 误操作 GitHub 的影响，等于 token 权限的影响面。

六、进阶：组合其他 MCP

GitHub MCP 单独用就很好，但和别的 MCP 组合更强：

• GitHub + Linear/Jira MCP：让 issue 和项目管理工具双向同步。
• GitHub + Slack MCP：CI 挂了自动通知频道。
• GitHub + 数据库 MCP：Agent 查生产数据辅助 debug。

MCP 的真正威力在组合——一旦你的 Agent 同时接通 GitHub + 内部工具，它能跨系统完成"查 → 改 → 提交 → 通知"的完整链路。

七、踩坑提醒

1. Token 权限给最小。Agent 调用的能力上限 = token 权限上限。
2. 大仓库小心。让 Agent"看一下整个仓库"可能拉取过多，限定范围（"只看 src/ 下的"）。
3. rate limit。GitHub API 有速率限制，高频调用会撞限。MCP Server 一般有缓存/合批，但你自己写脚本要注意。
4. 审计。生产仓库让 Agent 操作，最好 PR 上能看出"哪些是 AI 改的"（commit message 或 label 标注），方便 review 时有的放矢。

小结

把 GitHub 接进 Claude Code，是用 MCP 最直接、收益最明显的一步：

• 走官方远程 MCP Server（多数人够用），fine-grained token 最小授权。
• token 用环境变量/全局配置，别硬编码进仓库。
• 读操作放行、写操作加护栏，不可逆操作人工确认。

配好后，你的 AI 编程工作流从"写代码在终端、管 PR 在浏览器"的割裂状态，变成终端里一句话闭环——读 issue、写代码、建 PR、看 CI、回 review 全部一个会话搞定。这就是 MCP 把"被集成"做到极致后的体验：AI 工具不再是孤岛，而是你整个研发链路的一部分。