浏览 AI 知识库
GitHub MCP 怎么用：查询 Issue 和 PR，写操作前先确认
用 GitHub MCP 查 Issue 不需要默认给全仓库写权限。先锁定组织、仓库和只读 scope，确认查询结果无误后，再为确有需要的写动作单独授权。
按实际操作顺序推进
每完成一段就检查当前输出，确认结果符合预期后再继续。
只查一个 Issue，为什么不该先交出整个仓库的写权限
GitHub MCP 使用了全仓库写权限 Token，只为查询一个 Issue；第一次搜索又因仓库同名选错组织。
- 仓库与账号范围明确
- Token 为最小权限
- 写操作有独立预览和确认
动手前，把材料和不能改的部分定下来
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 目标仓库 `acme/demo-app`；任务只读取 Issue #42 与相关 PR；写评论需另行确认。 |
| 不能越过的边界 | Token 限定组织、仓库和只读权限；先回读仓库全名；任何评论、合并、关闭和标签修改都视为写操作。 |
| 要交付的结果 | 仓库范围、只读查询与写前审批 |
GitHub MCP 怎么用，从“确认身份和仓库”开始做
确认身份和仓库
记录 GitHub 用户、组织、目标仓库和可见范围，避免个人与工作账号混用。
审查 Token
使用最小 scope、有效期和资源范围，凭证不写入提示、配置截图或仓库。
运行只读查询
读取指定 Issue 或 PR 的标题、状态和链接，结果必须指向真实仓库。
验证越界
查询未授权仓库应失败，区分资源不存在、无权限和认证问题。
写前显示预览
评论正文、目标仓库、编号和动作先回显，由人确认后再执行；合并或删除更需单独授权。
先确认账号和仓库，再读一个 Issue 的状态
| 层级 | 输入 | 预期 | 失败分支 |
|---|---|---|---|
| 身份 | 当前用户、组织和目标仓库 | 与任务授权一致 | 账号不对先停止，不读取其他仓库 |
| 查询 | 指定 Issue 编号 17 | 返回标题、状态、链接和更新时间 | 区分不存在与无权限 |
| 越界 | 未授权仓库的同编号 Issue | 请求失败且不泄露正文 | 收窄 Token scope |
| 写入预览 | 准备评论草稿但不提交 | 显示仓库、编号、正文和动作 | 未经批准不发送 |
仓库、Issue 和账号均为演示输入；完整 Token 不进入提示、截图或仓库。
完成后的仓库范围、只读查询与写前审批
范围记录固定 owner/repo，首次查询返回 Issue 标题、状态和 URL；PR 查询结果可回到 GitHub 页面。写评论工具未授权，Token 日志已遮罩。
为什么“只读查询正确，后续写操作仍可能选错对象”还不能交付
只读查询正确，后续写操作仍可能选错对象
- 原因
- 没有在确认页重复显示仓库、Issue 与正文
- 怎么改
- 写前生成预览，人工核对对象和影响后再单独授权