Claude Code 连接器教程：20 分钟完成 GitHub 仓库分拣

在本教程中，我将向您展示如何使用 Claude 连接器（基于 Model Context Protocol 构建）将 Claude Code 连接到 GitHub，并用它从头到尾分拣一个开源仓库。 

整个流程不会克隆任何内容、不需要向量存储、也不会改动目标仓库的任何一行。相反，Claude Code 通过连接器读取问题（issues），并将工件写入您的本地文件系统，您可以先审阅，再决定是否（以及发布什么）。

完成本教程后，您将获得：

• 一个可用的 Claude Code 与 GitHub MCP 的只读令牌配置，
• 一组可复用的提示词，您可以指向任何公共仓库使用，
• 一个针对 langchain-ai/langchain 的完整分拣工件，供您对照参考。

什么是 Claude Code 的 GitHub 连接器（MCP）？

Claude Code 是 Anthropic 推出的基于终端的编码智能体。 

它开箱即用地具备对您的文件系统、shell 和 git 的访问。Claude Code 连接器将其能力扩展到外部上下文，例如 GitHub issues、Linear 工单、Slack 消息、Postgres 查询等——这些是单靠终端无法触达的。

连接器协议称为 MCP（Model Context Protocol），这是一个向大语言模型智能体暴露工具与数据的开放标准。 

Anthropic 维护了一个可直接使用的连接器目录，您也可以自行编写或连接第三方 MCP 服务器。

在本教程中，我们将使用官方的 GitHub MCP 服务器，它通过 Docker 在本地运行。其核心思路包括：

• 作为本地 Docker 容器运行，无需云端中转，凭据仅保留在您的机器上。
• 使用标准的 GitHub 个人访问令牌（PAT）进行认证，无需注册 OAuth 应用。
• 支持限定权限，例如不勾选任何 scope 的 PAT，可对公共仓库进行只读访问，从 GitHub API 层面上杜绝写入。
• 通过 claude mcp add  命令暴露给 Claude Code，随后这些工具在每个会话中可用。

开源分拣以阅读为主、判断为主，出错成本也低。 

让人类阅读并聚类 50 个 issue 很枯燥，而模型能够一次性把所有内容放在上下文中处理。

此外，我们先将输出写成本地文件；分组不佳或草稿拙劣也无损失，您可以在审阅时发现并更正。

Claude Code GitHub 连接器教程：为 langchain-ai/langchain 构建一次分拣

本节中，我们将在 Claude Code 中设置 GitHub 连接器，并对 langchain-ai/langchain 运行四个分拣提示词。它是一个大型机器学习仓库，issue 追踪器确实相当凌乱。总体而言，我们将完成以下内容：

• 通过运行在 Docker 中的官方 MCP 服务器，将 Claude Code 连接到 GitHub，
• 使用零 scope 的 PAT，使连接器从设计上即为只读，
• 运行将结果保存到本地文件的分拣提示词，
• 审阅输出，包括 Claude 拒绝将某些问题聚类为重复的情况。

让我们一步步搭建。

步骤 1：安装 Claude Code 与 Docker 的前置依赖

在设置连接器之前，您需要准备三样东西：

• Claude Code：可按 Anthropic 的 官方安装指南进行安装，
• Docker Desktop：官方 GitHub MCP 服务器在容器中运行，因此需要安装并启动 Docker，
• GitHub 账号：用于在下一步生成 PAT。

准备就绪后，验证 Docker 是否在运行：

docker info | head -5

如果未安装 Docker 或守护进程未启动，您将看到“Cannot connect to the Docker daemon”错误。在 macOS 上，可通过以下方式启动 Docker Desktop：

open -a Docker

Docker Desktop 通常需要 15–60 秒才能完全就绪，在此期间 docker info 会持续报错。与其手动检查，不如用一条简短的等待命令轮询直到守护进程就绪：

until 

docker info >/dev/null 2>&1; do sleep 2; echo "waiting..."; done && echo "Docker ready"

一旦打印出 Docker ready，即可继续。

步骤 2：创建一个只读 GitHub 令牌

在完成 Docker 设置后，前往 github.com/settings/tokens，生成一个新的经典令牌。

注意：保持所有 scope 均不勾选。未设定 scope 的令牌仍可通过 GitHub API 读取公共仓库，这已满足我们的需求。未选择任何 scope 时，该令牌无法在 GitHub 上执行写入、修改或删除，无论我们让 Claude 做什么。这是由 GitHub 端强制执行的硬性保证，并非对智能体行为的承诺。

生成后请立即复制并保存令牌，然后在您的 shell 中导出：

export GITHUB_PERSONAL_ACCESS_TOKEN="ghp_your_token_here"

如果您已在 Claude Code 会话中，可能会想用 ! 前缀直接在 shell 中运行导出命令（例如，! export GITHUB_PERSONAL_ACCESS_TOKEN="..."）。 

但由于 ! 会启动一个临时子 shell，命令结束后该变量就会消失，Claude 也无法看到它。

要在不将令牌粘贴进模型提示的情况下安全设置令牌，您有两种选择：

1. 输入 /exit 退出 Claude，在常规终端中运行导出命令，然后重新启动 claude。
2. 或者，将令牌保存在工作目录下的本地 .env 文件中，Claude Code 在启动时会自动读取。

在不回显令牌本身的情况下，验证两项前提均已就绪：

docker info | head -3
echo "Token set: ${GITHUB_PERSONAL_ACCESS_TOKEN:+yes}"

若变量存在，第二条命令会打印 Token set: yes；若为空，则打印 Token set: （冒号后无内容）。 

这比直接 echo 令牌更安全，因为不会有令牌以明文写入 shell 历史的风险。

步骤 3：在 Claude Code 中注册 GitHub 连接器

官方 GitHub MCP 服务器以 Docker 镜像的形式提供。 

我们使用 claude mcp add 将其注册到 Claude Code：

claude mcp add github \
  -e GITHUB_PERSONAL_ACCESS_TOKEN=$GITHUB_PERSONAL_ACCESS_TOKEN \
  -- docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN \
  ghcr.io/github/github-mcp-server

这里的两个 -e 不是笔误：

• 第一个 -e（位于 -- 之前）为 Claude Code 启动的 MCP 进程设置环境变量，
• 第二个 -e （位于 docker run 参数中）指示 Docker 将该变量转发进容器。

若遗漏任一处，容器将以空令牌启动，从而无法通过 GitHub API 进行认证。

验证连接器是否注册成功：

claude mcp list

您应看到：

github — docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server —  Connected

如果显示 Failed to connect，最常见的两种原因是 Docker 未运行，或未在运行 claude mcp add 的同一 shell 中导出 GITHUB_PERSONAL_ACCESS_TOKEN。

步骤 4：基础连通性检查

现在 GitHub 令牌已设置。接下来创建一个工作目录并打开 Claude Code CLI：

mkdir demo && cd demo
claude

claude 命令会在当前目录启动一个交互式会话。 

分拣过程中 Claude 写入的任何文件都会保存在这里。 

然后提出一个简单的只读请求，确认连接器正在使用：

Using the GitHub MCP connector, fetch the 5 most recently updated open issues in langchain-ai/langchain. Just list titles and numbers.

Claude Code 第一次使用 GitHub 工具时会提示您批准。 

请批准只读工具，如 list_issues、get_issue、search_issues 等。 

如果 Claude 回退为使用 curl 调用 GitHub 公共 API 而不是使用 MCP 工具，说明连接器未加载。请退出会话并重启。

成功运行会返回类似如下的结果：

一旦您看到通过 MCP 返回的真实 issue 编号，我们就可以开始实际分拣了。

步骤 5：生成待办摘要

热身任务是纯只读。我们希望在开展其他操作前先绘制问题追踪器中的内容地图。

Prompt:
Using the GitHub MCP connector, pull the 50 most recently updated open issues from langchain-ai/langchain. 
Read their titles, bodies, and labels. Group them by likely area — bugs, feature requests, documentation, questions, and "needs more info." 
For each group, give me a count and 3-5 representative issue numbers with a one-line reason. Save as backlog-summary.md in the current directory.

Claude Code 通过连接器获取问题、阅读并按领域进行分组，同时列出具有代表性的 issue 编号，并将其写成一份 markdown 文件。仅此一份文件，就能让维护者在 60 秒内快速扫一眼，判断接下来这一周将面对哪些事情。

步骤 6：标注可能的重复项

重复检测是智能体真正发挥价值的地方。 

让人类通读 50 个 issue 并按潜在问题聚类很乏味，而模型可以将它们全部纳入上下文，发现关键词搜索容易错过的重合点。

Prompt:
From the same 50 issues you already pulled, identify clusters of likely duplicates: issues describing the same underlying problem, even if titles differ. For each cluster, output issue numbers, a one-sentence shared-problem description, and confidence (high/medium/low). Save as duplicate-candidates.md.

以下是我这次运行中 Claude 实际产出的结果：

此输出中最有意思的是第 2 至第 4 个聚类。 

一个天真的基于关键词的重复检测器可能会把这四个聚类全部关闭为重复。 

Claude 则明确拒绝将它们视为重复。 

它将其标注为同一子系统下的组件聚类，但根因各异，并告知哪些应实际关闭（仅聚类 1），哪些应联合分拣但保持打开。

这正是谨慎的人类分拣者应有的行为，也正是“先写本地文件再审阅”这种模式值得多走一步的原因。 

如果我们直接连到 GitHub API 并自动关闭 Claude 标注的所有项，就会误关掉三个真正的缺陷。

步骤 7：审阅，然后决定是否发布

这正是本地文件模式的核心意义。 

在任何内容触及 GitHub 之前，检查每个由 Claude 保存的 .md 文件，看看分组是否符合您的直觉。 

高置信度的聚类是否真的看起来是重复？选读 2–3 条草拟回复，检查是否符合您的表达风格。

如果您想真正发布评论或应用标签，有两种方式：

• 手动：您可以自行将草稿粘贴到 GitHub。对于一次性在他人仓库进行分拣，这样做很好，且常常是正确选择。
• 在您拥有的仓库上授权写入：生成一个具有 repo scope 的单独 PAT，将其作为独立连接器条目添加（例如 github-write），然后重新运行提示词，要求 Claude 应用标签并发布评论。Claude Code 在首次使用每个写入类工具时都会请求批准。

写入路径的关键安全措施是将读写令牌分离。

结语

在本教程中，我演示了如何通过 MCP 将 Claude Code 连接到 GitHub，并用它端到端分拣一个真实的开源仓库。 

无需自建 GitHub 机器人或接入 webhooks，该流程通过官方 GitHub MCP 服务器读取问题，将四类分拣工件写为本地文件，并在您审阅后再决定发布何物。

更广泛的启示是，连接器让 Claude Code 不仅是编码智能体，更成为能读取您工具并为您准备可审阅成果的助手。 

合理的默认策略是在您审阅之前，将这些成果保留在本地；当您对这一模式建立信任后，可在错误成本较低的环节选择性地放权让智能体执行操作。

接下来，您可以从以下方向扩展该项目：

• 在您拥有的仓库上添加具备写入能力的连接器，这样在审阅后标签与评论可自动应用，
• 串联 Linear 或 Slack 连接器，将分拣决策同步到团队工作流，
• 将提示词做成计划任务的 CI 作业，产出每周一次的分拣 PR，
• 或将上述提示词泛化为一个可复用的 Claude Code 斜杠命令，适用于任意仓库 URL。