Claude Code GitHub 文件范围检查清单

客户给 GitHub 链接后，先不要急着让 Claude Code 阅读整个仓库。你要先确认链接类型、文件路径、分支版本、问题范围、是否只读、是否允许修改，以及哪些敏感信息不能碰。清单的作用，是把仓库链接收成一个可审核的小任务。

建议先读 客户给 GitHub 文件时用 Claude Code 怎么限定范围，再搭配 Claude Code 常用命令检查清单 和 /templates 使用。

适合谁

适合客户发来 GitHub 文件、目录、PR、commit 或仓库链接，希望你帮忙看一个明确问题的新手。

也适合你准备做只读诊断时使用。先用清单确认边界，再决定是否需要更多材料。

不适合谁

不适合客户要求你在未授权情况下访问私有仓库、保存密钥、查看真实数据、直接推送代码或处理生产配置的任务。

也不适合把“看一个文件”扩大成全仓库审计、全项目测试或长期维护。

具体步骤

1. 链接类型是什么？文件、目录、PR、issue、commit、分支还是整个仓库。
2. 以哪个版本为准？分支名、commit、tag 或 PR 编号要记录。
3. 要看哪个文件？路径要明确，不要只写“前端文件”。
4. 客户要解决什么问题？语法、构建、样式、接口、逻辑、文案要分清。
5. 是否只读？如果只读，就不要修改、提交或安装依赖。
6. 是否允许小范围修改？允许也要说明修改方式和交付方式。
7. 是否涉及敏感信息？密钥、真实数据、后台链接、内部业务逻辑要脱敏。
8. 是否需要补充上下文？单个文件不够时，先问客户要相关文件。
9. 是否有验证方式？本地检查、截图、测试数据或客户手动验收。
10. 是否写清未覆盖范围？全仓库审计、部署、数据库、长期维护默认不包含。

客户确认模板

我可以先做一轮 GitHub 文件范围诊断。请确认：
- 链接对应的文件、分支或 PR
- 希望检查的具体问题
- 是否只读，还是允许小范围修改
- 是否涉及敏感配置、真实数据或生产环境
- 希望怎样验收诊断或修改结果

这个模板能让客户把模糊链接补成可执行范围。

交付记录模板

查看范围：
版本依据：
相关文件：
已确认问题：
需要补充：
未覆盖范围：
建议下一步：

这份记录可以直接改成交付说明。即使没有修改代码，只读诊断也应该有清楚结果。

判断结果分类

如果文件明确、问题明确、权限低、可验证，可以进入小范围诊断或修改。如果单文件上下文不足，但客户愿意补材料，可以继续诊断。如果需要私有权限、生产配置、数据库或全仓库审计，就不要按普通小单处理。

分类要发给客户看。客户看到你的判断依据，后续追加范围时也更容易重新确认。

版本记录示例

链接类型：GitHub 文件
版本依据：main 分支，客户 2026-06-03 提供
检查文件：components/PricingCard.tsx
问题范围：按钮文案和卡片条件渲染
未覆盖：全仓库审计、部署、接口数据、权限配置

这类记录能放进交付说明，也能作为后续复盘依据。客户如果切换分支或更新文件，就需要重新确认。

追加材料清单

如果单文件无法判断，优先向客户要最小材料：调用该文件的页面、脱敏错误原文、复现步骤、测试数据说明。不要一次要求整个仓库权限。

补材料时也要说明用途。例如“需要调用方文件，是为了确认这个组件传入的数据结构”。客户更容易配合，也更少担心你越界。

交付前复核

发送结果前，确认交付说明里有四个字段：查看范围、版本依据、判断结论、未覆盖范围。缺少任何一个字段，客户都可能误以为你看过更多内容。

如果你做了修改，还要补提交方式：是给修改建议、发 patch、还是由客户自己改。不要默认你会推送到客户仓库。

客户验收写法

GitHub 文件检查的验收可以很简单：客户确认指定文件、指定问题和建议下一步是否准确。如果进入修改，则验收方式可以是本地构建通过、截图符合预期或客户在测试分支确认。

验收不要写成“你看看”。要写“请在指定分支确认该文件修改后，原报错不再出现”。越具体越稳。

风险提醒

不要把仓库链接里的敏感路径、业务逻辑或日志片段随意复制到外部工具。需要使用时先脱敏。

不要把能打开的 GitHub 页面理解为完整授权。访问、修改、提交、部署是不同权限。

免责声明

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

CTA：收到 GitHub 链接后，把这份清单放进 /templates；需要客户确认话术时，用 /tools/proposal-generator 起草后人工复核。