GitHub MCP 进阶：让 LLM 深度参与代码协作的实战用法

简介

在 MCP 基础系列 中我们介绍了 GitHub MCP 的基础用法（查 Issue、读 PR）。本文聚焦进阶场景：自动化 Issue 分类、批量 PR 管理、Release Notes 生成、仓库健康度分析、代码迁移辅助。

核心能力回顾

工具类别	工具名	用途
Issue	create_issue / get_issue / list_issues	Issue 管理
PR	create_pull_request / get_pull_request / list_pull_requests	PR 管理
Review	create_branch / create_or_update_file	代码操作
Search	search_repositories / search_code	仓库/代码搜索
Branch	list_branches / merge_branch	分支管理
File	get_file_contents / create_or_update_file	文件操作

进阶 1：自动化 Issue 分类

场景

开源项目每天收到大量 Issue，人工分类耗时。用 LLM + GitHub MCP 自动化：

1. list_issues → 获取所有未标签 Issue
2. LLM 分析 Issue 内容 → 推荐标签（bug/feature/question/duplicate）
3. LLM 分析 → 推荐优先级（P0/P1/P2/P3）
4. LLM 分析 → 推荐负责人
5. 自动添加标签与评论

Prompt

你是 Issue 分类专家。请对以下 GitHub Issue 自动分类：

## Issue 信息
- 标题：{title}
- 内容：{body}
- 已有标签：{labels}

## 分类规则

### 类型标签
- bug：报告功能错误
- feature：请求新功能
- question：使用疑问
- duplicate：与已有 Issue 重复
- enhancement：改进建议
- documentation：文档问题

### 优先级
- P0：阻断性问题（核心功能不可用）
- P1：严重问题（影响主要流程）
- P2：一般问题（有 workaround）
- P3：小问题或建议

### 负责人推荐
根据 Issue 涉及的模块，推荐最合适的负责人：
- 前端：@frontend-team
- 后端：@backend-team
- 文档：@docs-team
- 基础设施：@devops-team

## 输出
{
  "type_label": "bug",
  "priority": "P1",
  "assignee": "@backend-team",
  "summary": "一句话总结 Issue",
  "suggested_response": "给提交者的回复模板"
}

进阶 2：批量 PR Review 管理

场景

维护多个仓库时，每天有大量 PR 待 Review。用 LLM 做初筛：

1. list_pull_requests → 获取所有待 Review PR
2. get_pull_request → 获取 PR 详情（改动文件、diff）
3. LLM 分析 → 代码质量评分 + 风险评估
4. LLM 生成 → Review 评论
5. 自动评论或标记"待人工 Review"

Prompt

你是资深代码审查员。请对以下 PR 做初步 Review：

## PR 信息
- 标题：{title}
- 描述：{description}
- 改动文件：{changed_files}
- Diff：{diff}

## Review 维度

### 1. 代码质量（1-5 分）
- 命名是否清晰
- 函数是否过长
- 是否有重复代码
- 是否有注释

### 2. 逻辑正确性（1-5 分）
- 边界条件是否处理
- 异常处理是否充分
- 是否有潜在 Bug

### 3. 安全性（1-5 分）
- 输入验证
- SQL 注入风险
- XSS 风险
- 权限检查

### 4. 性能（1-5 分）
- N+1 查询
- 不必要循环
- 内存泄漏

### 5. 可维护性（1-5 分）
- 单一职责
- 耦合度
- 可测试性

## 输出
{
  "quality_score": 4,
  "issues": [
    {
      "file": "src/api.js",
      "line": 42,
      "severity": "warning",
      "message": "缺少输入验证",
      "suggestion": "添加 zod schema 验证"
    }
  ],
  "overall": "approve/request_changes/comment",
  "review_comment": "Review 评论文本"
}

进阶 3：自动生成 Release Notes

场景

发版时需整理 Release Notes，手动翻 PR 记录耗时。用 LLM 自动生成：

1. list_pull_requests(merged_since=last_release) → 获取合并的 PR
2. LLM 分析 PR → 分类（feature/bugfix/refactor/breaking）
3. LLM 生成 → 结构化 Release Notes
4. create_or_update_file → 写入 CHANGELOG.md

Prompt

你是 Release Notes 生成器。请基于以下已合并 PR 生成 Release Notes：

## 版本信息
- 版本号：{version}
- 上一版本：{last_version}
- 发布日期：{date}

## 已合并 PR 列表
{merged_prs}

## 输出格式

## {version} ({date})

### 🎉 新功能
- {feature} (#{pr_number})

### 🐛 Bug 修复
- {bugfix} (#{pr_number})

### ♻️ 重构
- {refactor} (#{pr_number})

### ⚠️ Breaking Changes
- {breaking_change} (#{pr_number})

### 📦 依赖更新
- {dependency} (#{pr_number})

## 要求
1. 用户友好的语言（非技术细节）
2. 每个 PR 一句话总结
3. Breaking Changes 需加粗
4. 按 PR 重要性排序

进阶 4：仓库健康度分析

场景

评估一个开源仓库是否值得使用或贡献：

1. search_repositories → 获取仓库信息
2. list_issues → 分析 Issue 处理速度
3. list_pull_requests → 分析 PR 合并速度
4. get_file_contents → 检查文档质量
5. LLM 综合分析 → 健康度报告

Prompt

你是开源项目评估专家。请分析以下 GitHub 仓库的健康度：

## 仓库数据
{repo_data}

## 评估维度

### 1. 活跃度
- 最近提交时间
- 提交频率
- 贡献者数量
- Star/Fork 增长

### 2. 维护质量
- Issue 平均关闭时间
- PR 平均合并时间
- 未响应 Issue 数量
- 是否有活跃维护者

### 3. 代码质量
- 是否有测试
- 是否有 CI/CD
- 是否有 Lint 配置
- 是否有贡献指南

### 4. 文档质量
- README 完整度
- 是否有 API 文档
- 是否有示例
- 是否有 Changelog

### 5. 社区健康
- 贡献者指南
- 行为准则
- 讨论区活跃度
- 是否有赞助

## 输出
| 维度 | 评分（1-10） | 依据 |
|------|-------------|------|

## 总体评估
- 健康等级：A/B/C/D/F
- 推荐使用：是/否/观望
- 推荐贡献：是/否
- 风险提示：...

进阶 5：代码迁移辅助

场景

把旧框架代码迁移到新框架（如 Vue 2 → Vue 3、Class Component → Hooks）：

1. get_file_contents → 读取源文件
2. LLM 分析 → 识别需迁移的模式
3. LLM 生成 → 迁移后的代码
4. create_branch → 创建迁移分支
5. create_or_update_file → 提交迁移代码
6. create_pull_request → 创建迁移 PR

Prompt

你是代码迁移专家。请把以下代码从 {from_framework} 迁移到 {to_framework}：

## 源代码
{source_code}

## 迁移规则
{migration_rules}

## 要求
1. 保持功能等价
2. 使用目标框架的最佳实践
3. 保留原有注释
4. 标注迁移变更（新增/删除/修改）
5. 生成迁移说明文档

## 输出
1. 迁移后的代码
2. 变更清单
3. 迁移注意事项
4. 测试建议

进阶 6：多仓库批量操作

场景

管理多个微服务仓库，批量更新依赖或修改配置：

1. search_repositories(org=myorg) → 获取所有仓库
2. 遍历每个仓库：
   a. get_file_contents(package.json) → 检查依赖版本
   b. 如需更新：
      - create_branch("update-deps")
      - create_or_update_file(package.json) → 更新版本
      - create_pull_request → 创建 PR
3. 汇总报告

注意事项

1. Token 权限：GitHub Token 需有 repo 权限才能创建 PR/Issue。
2. Fine-grained Token：推荐用 Fine-grained Token 限制仓库范围。
3. Rate Limit：GitHub API 每小时 5000 次请求，批量操作需注意。
4. 大型仓库：list_issues 默认分页，需处理分页逻辑。
5. Diff 大小：大 PR 的 Diff 可能超出 LLM 上下文，需分文件处理。
6. 自动操作风险：自动创建 PR/Issue 需人工确认机制，避免误操作。
7. 评论频率：自动评论可能被视为 spam，需控制频率。
8. 私有仓库：Token 需有私有仓库访问权限。

安全最佳实践

• 最小权限 Token：只授予必要仓库与权限
• 审计日志：记录所有自动操作
• 人工确认：高风险操作（合并 PR、删除分支）需人工确认
• 沙箱测试：先在 fork 仓库测试自动化流程
• Token 保密：Token 不写入代码，用环境变量

与其他 MCP 的协同

组合	场景
GitHub MCP + Filesystem MCP	读取本地代码 + 提交到 GitHub
GitHub MCP + Postgres MCP	分析 Issue 数据存入数据库
GitHub MCP + Brave Search MCP	搜索相关 Issue/PR 解决方案
GitHub MCP + Memory MCP	记住仓库的代码规范与偏好

小结

GitHub MCP 的进阶用法核心是自动化工作流：Issue 分类、PR Review、Release Notes、健康度分析、代码迁移。掌握这些，就能让 AI 成为你的代码协作副驾驶。

GitHub MCP 进阶系列下一篇将讲 GitLab MCP：GitLab 平台的 AI 集成方案。