客户给 GitHub 文件时用 Claude Code 怎么限定范围

客户发来 GitHub 链接时，新手很容易直接把整个仓库当成任务。更稳的做法是先问清：要看哪个文件、哪个分支、哪个问题、是否只读、是否需要修改、如何验收。Claude Code 能帮助你理解文件和上下文，但不能替你决定仓库访问边界。

这篇适合搭配 Claude Code 项目客户问题检查清单、Claude Code 常用命令检查清单、Claude Code 交付说明检查清单 和 /templates 使用。

适合谁

适合客户给出 GitHub 文件链接、PR 链接、仓库片段或单个报错文件，希望你帮忙看问题的新手。你可以先做只读检查，再判断是否适合小范围修改。

也适合客户说“帮我看看这个仓库哪里有问题”的场景。这个说法太大，第一步应该是把仓库请求拆成文件、问题、环境和验收方式。

不适合谁

不适合没有授权就访问私有仓库、复制敏感配置、查看密钥、处理真实数据或推送代码的任务。链接能打开，不代表你有权扩大使用范围。

也不适合把单文件检查自然扩展成全仓库重构、全项目测试、部署修复或长期维护。这些都需要重新确认范围。

具体步骤

第一，确认链接类型。客户给的是单个文件、目录、PR、issue、commit 还是整个仓库？不同链接对应不同范围。

第二，确认分支和版本。GitHub 文件在不同分支可能内容不同。让客户说明以哪个分支、commit 或 PR 为准。

第三，确认问题范围。客户希望你看语法错误、业务逻辑、构建报错、文案、样式还是交付说明？不要把“看看”当成无限检查。

第四，先做只读检查。读取文件、搜索相关函数、查看相邻配置、理解调用关系。不要先改文件、安装依赖或推送提交。

第五，判断是否需要更多上下文。单文件无法解释问题时，可以请求客户补充相关文件、脱敏日志或复现步骤，而不是偷偷扩大到全仓库。

第六，写清交付结果。说明你看了哪些文件、发现什么、建议下一步、哪些范围没有覆盖。

可复制客户问题

为了限定范围，请先确认：
1. 以哪个 GitHub 文件、分支或 PR 为准？
2. 你希望我检查哪一个具体问题？
3. 是否只需要诊断，还是允许小范围修改？
4. 是否涉及密钥、真实数据、后台或生产配置？
5. 修完或诊断完成后，你希望怎样验收？

这组问题能把“帮我看看仓库”变成可执行的小任务。

只读诊断怎么写

只读诊断可以交付：已查看文件路径、相关上下文、可能问题、需要客户补充的材料、是否建议继续修复。比如“已查看 app/page.tsx 和相邻组件，问题更可能来自数据为空时的渲染分支；需要补充复现截图和测试数据”。

如果客户只授权看单个文件，就不要默认查看配置、密钥、私有目录或其他业务文件。需要额外上下文时，先让客户确认。

版本证据怎么保存

GitHub 文件会变化，所以记录版本很重要。交付说明里可以写分支名、commit 短哈希、PR 编号或客户截图时间。否则客户改了文件后再回来看，你很难证明当时检查的是哪一版。

如果客户只给网页链接，可以提醒对方确认当前链接是否就是要检查的版本。对新手来说，这一步很小，但能避免“你看的不是这个版本”的争议。

需要追加上下文时怎么说

单文件不够判断时，不要自己扩大范围。可以回复：“仅凭这个文件还不能确认原因，需要补充调用它的组件、报错原文或复现步骤。”把需要的材料列成最小清单，客户补齐后再继续。

这样做比直接读完整仓库更稳，也更符合小单范围。Claude Code 越是能读很多文件，你越要主动限定它读什么。

风险提醒

不要把私有仓库内容、内部路径、token 片段或客户业务逻辑原样发给第三方工具或公开聊天。先脱敏，再只保留必要上下文。

不要把 GitHub 链接当成完整授权。项目前要确认访问权限、修改权限、提交方式和验收边界。

免责声明

本文仅供学习和项目流程参考，不构成安全、法律、财务或平台合规建议。Claude Code 功能、GitHub 权限和客户项目规则可能变化，发布前需要人工复核。项目前请确认授权、脱敏、测试环境和交付边界。

CTA：收到 GitHub 链接后，先用 /templates 记录文件路径和范围；需要给客户写确认问题时，用 /tools/proposal-generator 起草后人工复核。