小项目里你可以直接对 Claude Code 说“给我看下整个仓库”，但在大型单仓或 monorepo 里，这样做往往既贵又慢，还容易让它把上下文浪费在无关目录。官方针对 large codebases 单独写了指导页，核心思路只有一句话：让 Claude 只聚焦与你当前任务真正相关的那一块代码。
先决定从哪里启动
官方文档指出，你从仓库根目录启动还是从子目录启动，会直接影响三个结果：Claude 默认能读写哪些文件、启动时会加载哪些 CLAUDE.md，以及项目级设置是否生效。如果任务只在某个包里，直接从子目录启动通常更高效；如果任务跨多个模块，再从根目录启动。
大型项目的第一条原则：分层上下文
不要把所有规则都堆在一个根目录 CLAUDE.md。更推荐的方式是根目录放仓库总览，例如每个 package 的职责、运行命令和通用规范；子目录再放该区域独有规则。这样 Claude 启动时先得到全局方向，真正读到某个子目录文件时，再加载那部分专项细则。
第二条原则：先概览，再定位
官方 common workflows 里提供了非常实用的读项目提示套路。进入项目后不要立刻问“帮我改”，先让它：
- 给出代码库高层概览。
- 解释主要架构模式。
- 找出和某个功能相关的文件。
- 说明这些文件如何协作。
- 最后再追踪具体执行流程。
这种由宽到窄的方式，比一开始就丢一个模糊需求更稳定。
第三条原则：屏蔽无关内容
官方 large-codebases 页面建议明确阻止读取构建产物、生成代码、vendored dependencies 等高噪音目录。原因很简单：这些文件既占上下文，也会让 Claude 在搜索时命中过多假结果。对前端项目来说，dist、.next、生成的类型文件往往都不值得默认放开。
大仓库里最好怎么提问
- 不要问“项目怎么实现的”，改问“登录流程从前端到数据库经过哪些文件”。
- 不要问“帮我找 bug”，改问“运行某命令时报错，相关文件有哪些”。
- 不要让它全仓扫描后再归纳，先点出模块名、目录、接口名或业务词。
- 先要求概览，再要求调用链，再要求具体修改建议。
什么时候该用子目录启动
如果你长期只维护 monorepo 中的一个 package，从那个子目录里启动 Claude Code 会很划算。官方说明这样做会让启动时只加载当前目录及其祖先目录的 CLAUDE.md，并把文件访问默认限制在这个子树里，天然减少误读和越界修改。需要跨目录时，再通过额外目录授权补上即可。
辅助提效的两个方法
一是使用 Plan 模式，让 Claude 先只读分析，再决定是否修改。二是把长期协作规则沉淀到 CLAUDE.md，再配合更明确的目录边界与模块提示，让它少靠“全文瞎翻”。官方也提到，子目录技能和分层规则在大型仓库里非常有效，因为它们只在相关区域被触发，而不是每次会话都加载全量背景。
一个很实用的提问模板
如果你经常发现 Claude 在大仓库里跑偏，可以固定使用这种提问方式：先说明你现在所在的目录，再点出模块名和目标，例如“我现在在 packages/api，请先概览和订单状态计算有关的文件，不要修改，只告诉我入口、依赖和测试位置”。这种模板的价值在于，它同时限定了目录、主题和动作，让 Claude 更容易把注意力聚焦到真正相关的代码，而不是按关键词到处乱翻。
一旦你找到稳定模板，最好把它写进团队自己的 CLAUDE.md 或说明文档；如果接下来要真正落地改动，也可以先切到 真实功能实战流程 里的分析节奏，再动文件会更稳。
最常见的失败方式
- 从仓库根目录启动，却让它全量扫描一个超大 monorepo。
- 根目录 CLAUDE.md 又长又杂，和当前任务只有一小部分相关。
- 没有屏蔽生成目录，搜索结果被噪音淹没。
- 提示词过大、目标过多，导致 Claude 没法稳定聚焦。
- 还没定位代码就先执行修改，最后回滚成本很高。
总结
Claude Code 读大型项目的关键不是“让它知道更多”，而是“让它知道正确的那部分”。缩小启动范围、分层 CLAUDE.md、先概览后定位、明确目录边界，这四件事做好了，大仓库的可用性会明显提升。接下来如果你想把外部文档或系统也接进来，可以继续看 MCP 配置方法；如果需要先控制修改风险，也可以回到 权限模式配置 先把边界设好。
