文章目录一、Claude Code 如何导航大型代码库二、工具链Harness与模型同等重要CLAUDE.md 文件首要Hooks让设置自我改进Skills按需提供专业知识不膨胀每个会话Plugins分发有效配置LSP 集成赋予 Claude 与开发者在 IDE 中相同的导航能力MCP 服务器扩展一切Subagents将探索与编辑分离组件说明表格三、来自成功部署的三种配置模式3.1 让代码库在大规模下可导航3.2 随着模型智能的演进主动维护 CLAUDE.md 文件3.3 指定 Claude Code 管理和采用的负责人四、将这些模式应用到你的组织原文https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start发表时间2026年5月14日系列Claude Code at scale最成功的 Claude Code 部署在配置、工具和组织结构方面呈现出一套可识别的共性模式。本文是Claude Code at scale系列的开篇涵盖工程团队在企业规模下使用 Claude Code 的最佳实践。Claude Code 已在拥有数百万行代码的单体仓库、存在数十年的遗留系统、横跨数十个仓库的分布式架构以及拥有数千名开发者的组织中投入生产。这些环境带来了小型、简单代码库所没有的挑战——可能是每个子目录的构建命令各不相同也可能是遗留代码分散在没有共享根目录的文件夹中。本文介绍了我们观察到的、在大规模采用 Claude Code 方面取得成功的一些模式。我们用大型代码库来指代广泛的部署场景拥有数百万行代码的单体仓库、历经数十年构建的遗留系统、分布在独立仓库中的数十个微服务或上述任意组合。这还包括运行在团队不常将其与 AI 编程工具关联的语言上的代码库如 C、C、C#、Java、PHP。在这些场景下Claude Code 的表现比大多数团队预期的要好尤其是最近的模型版本。尽管每个大型代码库的部署都受其特定的版本控制、团队结构和积累约定的影响但本文中的模式具有通用性是考虑采用 Claude Code 的团队的良好起点。一、Claude Code 如何导航大型代码库Claude Code 导航代码库的方式与软件工程师相同它遍历文件系统、读取文件、使用 grep 精确查找所需内容并跟踪整个代码库中的引用。它在开发者的本地机器上运行不需要构建、维护或上传到服务器的代码库索引。基于 RAG检索增强生成的 AI 编程工具通过将整个代码库嵌入向量空间在查询时检索相关文本块来工作。在大规模场景下这些系统可能会失效因为嵌入管道无法跟上活跃工程团队的节奏。等到开发者查询索引时它反映的已经是数周、数天甚至数小时前的代码库状态。检索结果可能返回一个团队两周前重命名的函数或者引用一个在上个冲刺中被删除的模块而且没有任何迹象表明两者都已过时。智能体搜索Agentic search避免了这些故障模式。随着数千名工程师提交新代码不需要维护嵌入管道或集中式索引。每个开发者的实例都从实时代码库工作。但这种方法有一个权衡当 Claude 有足够的起始上下文知道去哪里查找时它的效果最好。这意味着 Claude 导航的质量取决于代码库的设置好坏需要通过 CLAUDE.md 文件和 Skills 来分层提供上下文。如果你要求它在十亿行代码库中查找某个模糊模式的所有实例在工作开始之前就会遇到上下文窗口限制。在代码库设置上投入精力的团队会看到更好的结果。二、工具链Harness与模型同等重要关于 Claude Code 最常见的误解之一是它的能力完全由所使用的模型定义。团队关注模型的基准测试及其在测试任务上的表现。在实践中围绕模型构建的生态系统——即工具链Harness——比模型本身更多地决定了 Claude Code 的性能。工具链由五个扩展点构建而成——CLAUDE.md 文件、Hooks、Skills、Plugins 和 MCP 服务器——每个都有不同的功能。团队构建它们的顺序很重要因为每一层都建立在前一层的基础上。另外两个能力——LSP 集成和 Subagents——完善了整个设置。下面我们解释每个组件和功能的作用CLAUDE.md 文件首要这些是 Claude 在每个会话开始时自动读取的上下文文件根目录文件用于全局概览子目录文件用于本地约定。它们为 Claude 提供了做好任何事情所需的代码库知识。因为它们在每个会话中都会加载无论任务是什么所以保持其内容专注于广泛适用的内容可以防止它们成为性能的拖累。Hooks让设置自我改进大多数团队将 Hooks 视为阻止 Claude 做错事的脚本但它们更有价值的用途是持续改进。Stop Hook可以反思会话期间发生的情况并在上下文仍然新鲜时提出 CLAUDE.md 更新建议。Start Hook可以动态加载团队特定的上下文这样每个开发者都能获得适合其模块的正确设置而无需手动配置。对于 lint 和格式化等自动化检查Hooks 确定性地执行规则比依赖 Claude 记住指令产生更一致的结果。Skills按需提供专业知识不膨胀每个会话在拥有数十种任务类型的大型代码库中并非所有专业知识都需要在每个会话中出现。Skills 通过渐进式披露解决这个问题将专业工作流和领域知识卸载出去否则它们会竞争上下文空间仅在任务需要时加载它们。例如安全审查 Skill 在 Claude 评估代码漏洞时加载而文档处理 Skill 在代码变更需要更新文档时加载。Skills 还可以限定到特定路径以便它们仅在代码库的相关部分激活。一个拥有支付服务的团队可以将其部署 Skill 绑定到该目录这样当有人在单体仓库的其他地方工作时它永远不会自动加载。Plugins分发有效配置大型代码库的一个挑战是好的设置可能停留在小团体内。Plugin 将 Skills、Hooks 和 MCP 配置捆绑到一个可安装的包中因此当一名新工程师在第一天安装该 Plugin 时他们将立即拥有与使用 Claude 已久的人相同的上下文和能力。Plugin 更新可以通过托管市场在整个组织中分发。例如我们合作的一家大型零售组织构建了一个将 Claude 连接到其内部分析平台的 Skill以便业务分析师无需离开工作流即可提取性能数据。他们在向业务部门广泛推出之前将其作为 Plugin 进行了分发。LSP 集成赋予 Claude 与开发者在 IDE 中相同的导航能力大多数大型代码库的 IDE 已经在运行 LSP支撑着跳转到定义和查找所有引用等功能。将这一点暴露给 Claude赋予它符号级精度它可以跟踪函数调用到其定义跨文件跟踪引用并区分不同语言中同名的函数。如果没有它Claude 会对文本进行模式匹配可能定位到错误的符号。我们合作的一家某企业软件公司在 Claude Code 推出之前就在全组织部署了 LSP 集成专门为了使 C 和 C 的大规模导航可靠。对于多语言代码库这是最高价值的投资之一。MCP 服务器扩展一切MCP 服务器是 Claude 连接到内部工具、数据源和 API 的方式否则它无法访问这些资源。最先进的团队构建了暴露结构化搜索的 MCP 服务器作为 Claude 可以直接调用的工具。其他团队将 Claude 连接到内部文档、工单系统或分析平台。Subagents将探索与编辑分离Subagent 是一个独立的 Claude 实例拥有自己的上下文窗口它接受一个任务、完成工作并仅将最终结果返回给父级。一旦工具链就位一些团队会启动一个只读 Subagent 来映射子系统并将发现写入文件然后让主 agent 根据完整的信息进行编辑。组件说明表格下表总结了每个组件的功能、加载时机以及我们看到的最常见误区组件是什么加载时机最适合常见误区CLAUDE.mdClaude 自动读取的上下文文件每个会话项目特定约定、代码库知识将属于 Skill 的可复用专业知识放入其中Hooks在关键时刻运行的脚本由事件触发自动化一致行为、捕获会话学习用 Prompt 处理应该自动运行的事情Skills针对特定任务类型的打包指令按需当相关时跨会话和项目的可复用专业知识将所有内容加载到 CLAUDE.md 中Plugins捆绑的 Skills、Hooks、MCP 配置配置后始终可用在整个组织中分发有效设置让好的设置停留在小团体中LSP通过语言特定服务器提供实时代码智能配置后始终可用类型化语言中的符号级导航和自动错误检测认为是自动的MCP 服务器到外部工具和数据源的连接配置后始终可用让 Claude 访问它无法触及的内部工具在基础配置工作之前就构建 MCP 连接Subagents用于特定任务的独立 Claude 实例被调用时将探索与编辑分离、并行工作在同一会话中运行探索和编辑LSP 通过 Plugin 层访问。Subagents 是一种委托能力而不是配置的扩展点。三、来自成功部署的三种配置模式如何为大型代码库配置 Claude Code在很大程度上取决于该代码库的结构方式。尽管如此在我们观察到的部署中三种模式反复出现。3.1 让代码库在大规模下可导航Claude 在大型代码库中提供帮助的能力受限于它找到正确上下文的能力。每个会话加载过多上下文会降低性能而上下文太少则让 Claude 盲目导航。最有效的部署会预先投入精力使代码库对 Claude 可读。以下几个模式反复出现保持 CLAUDE.md 文件精简且分层。Claude 在遍历代码库时会逐级加载它们根文件用于全局概览子目录文件用于本地约定。根文件应该只是指针和关键注意事项其他一切都会变成噪音。在子目录中初始化而不是在仓库根目录。当 Claude 的范围限定在与任务实际相关的代码库部分时它的效果最好。在单体仓库中这可能感觉有违直觉因为工具化通常假设根访问但 Claude 会自动沿目录树向上遍历并加载沿途找到的每个 CLAUDE.md 文件因此根级上下文永远不会丢失。为每个子目录限定测试和 lint 命令。当 Claude 只更改了一个服务时运行完整测试套件会导致超时并将上下文浪费在无关的输出上。子目录级别的 CLAUDE.md 文件应指定适用于该部分代码库的命令。这适用于每个目录有自己的测试和构建命令的面向服务的代码库。在具有深度跨目录依赖关系的编译语言单体仓库中按子目录限定更难实现可能需要特定的项目构建配置。使用.claude/settings.json中的permissions.deny规则排除生成的文件、构建产物和第三方代码。将规则提交到版本控制意味着团队中的每个开发者都获得相同的降噪效果而无需自己配置。在某些代码库中生成的文件本身就是开发工作的主题。从事代码生成器工作的开发者可以在其本地设置中覆盖项目级排除项而不会影响团队的其他成员。当目录结构无法完成这项工作时构建代码库地图。对于代码未整合到常规目录结构的组织在仓库根目录放置一个轻量级的 markdown 文件列出每个顶级文件夹及其内容的一行描述为 Claude 提供了一个目录它可以在打开文件之前扫描。对于拥有数百个顶级文件夹的代码库分层方法效果最好根文件仅描述最高级别的结构子目录 CLAUDE.md 文件提供下一级别的细节随着 Claude 遍历树而按需加载。对于更简单的情况使用提及 Claude 应参考的特定文件或目录可以完成同样的工作。运行 LSP 服务器让 Claude 按符号而非字符串搜索。在大型代码库中对一个常见函数名使用 grep 会返回数千个匹配项Claude 会消耗上下文打开文件以找出哪个是重要的。LSP 只返回指向同一符号的引用因此过滤在 Claude 读取任何内容之前就发生了。设置这需要为你的语言安装代码智能插件和相应的语言服务器二进制文件Claude Code 文档涵盖了可用的插件和故障排除。一个注意事项在某些边缘情况下即使是分层的 CLAUDE.md 方法也会失效例如拥有数十万个文件夹和数百万个文件的代码库或运行在非 git 版本控制上的遗留系统。我们将在本系列的后续部分中解决这些挑战。3.2 随着模型智能的演进主动维护 CLAUDE.md 文件随着模型的演进为当前模型编写的指导可能会对未来模型产生反效果。指导 Claude 度过它曾经难以应对的模式的 CLAUDE.md 文件在下一代模型发布时可能变得不必要或具有主动限制性。例如一条告诉 Claude 将每个重构拆分为单文件变更的 CLAUDE.md 规则可能帮助早期模型保持正轨但会阻止较新模型进行它处理得很好的协调跨文件编辑。为弥补特定模型局限性而构建的 Skills 和 Hooks无论是模型推理的局限性还是 Claude Code 自身工具的局限性一旦这些局限性不再存在就会变成开销。例如一个在 Perforce 代码库中拦截文件写入以强制p4 edit的 Hook在 Claude Code 添加原生 Perforce 模式后就变得多余了。团队应该预期每三到六个月进行一次有意义的配置审查但在主要模型发布后感觉性能停滞时也值得进行一次审查。3.3 指定 Claude Code 管理和采用的负责人仅靠技术配置无法推动采用。做得对的组织也在组织层面进行了投入。传播最快的推出在广泛访问之前进行了专门的基础设施投资。一个小团队有时甚至只有一个人将工具连接起来这样当开发者第一次接触 Claude 时它已经适合开发者的工作流。在一家公司几名工程师构建了一套 Plugin 和 MCP在第一天就可以使用。在另一家公司整个专注于管理 AI 编程工具的团队在推出开始前就准备好了基础设施。在这两种情况下开发者的第一次体验都是富有成效的而不是令人沮丧的采用从这里传播开来。今天做这项工作的团队往往隶属于开发者体验或开发者生产力部门这通常是负责新工程师入职和构建开发者工具的功能。几个组织中正在出现一个新的角色Agent Manager智能体经理——一个致力于管理 Claude Code 生态系统的混合 PM/工程师职能。对于没有专门团队的组织最小可行版本是一个DRI直接负责人一个人拥有 Claude Code 配置的所有权有权对设置、权限策略、Plugin 市场和 CLAUDE.md 约定做出决定并负责保持它们的时效性。自下而上的采用会产生热情但如果没有人集中有效的内容可能会碎片化。你需要有一个人或团队来组装和推广正确的 Claude Code 约定例如标准化的 CLAUDE.md 层次结构或精选的 Skills 和 Plugins 集。没有这项工作知识将停留在小团体中采用将停滞。在大型组织中尤其是在受监管行业的组织中治理问题很早就出现了例如谁控制哪些 Skills 和 Plugins 可用如何防止数千名工程师独立重建相同的东西如何确保 AI 生成的代码经过与人工生成的代码相同的审查流程为了尽早解决这些问题我们建议从一组定义的批准 Skills、必需的代码审查流程和有限的初始访问开始随着信心的建立而扩展。我们观察到通过在早期建立跨职能工作组将工程、信息安全和治理代表聚集在一起共同定义需求并构建推出路线图组织的部署最为顺利。四、将这些模式应用到你的组织Claude Code 围绕常规软件工程环境设计其中工程师是主要的代码库贡献者仓库使用 Git代码遵循标准目录结构。大多数大型代码库都符合这种模式但非传统设置——如具有大型二进制资源的游戏引擎、具有非常规版本控制的环境或非工程师对代码库做出贡献——需要额外的配置工作。我们的指导假设的是常规设置我们描述的模式在许多客户中都很有效。任何剩余复杂性都需要针对你的代码库、工具和组织的具体判断。这正是 Anthropic 的 Applied AI 团队直接与工程团队合作将这些模式转化为你组织特定需求的地方。
【译】Claude Code 在大型代码库中的工作原理：最佳实践与入门指南
文章目录一、Claude Code 如何导航大型代码库二、工具链Harness与模型同等重要CLAUDE.md 文件首要Hooks让设置自我改进Skills按需提供专业知识不膨胀每个会话Plugins分发有效配置LSP 集成赋予 Claude 与开发者在 IDE 中相同的导航能力MCP 服务器扩展一切Subagents将探索与编辑分离组件说明表格三、来自成功部署的三种配置模式3.1 让代码库在大规模下可导航3.2 随着模型智能的演进主动维护 CLAUDE.md 文件3.3 指定 Claude Code 管理和采用的负责人四、将这些模式应用到你的组织原文https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start发表时间2026年5月14日系列Claude Code at scale最成功的 Claude Code 部署在配置、工具和组织结构方面呈现出一套可识别的共性模式。本文是Claude Code at scale系列的开篇涵盖工程团队在企业规模下使用 Claude Code 的最佳实践。Claude Code 已在拥有数百万行代码的单体仓库、存在数十年的遗留系统、横跨数十个仓库的分布式架构以及拥有数千名开发者的组织中投入生产。这些环境带来了小型、简单代码库所没有的挑战——可能是每个子目录的构建命令各不相同也可能是遗留代码分散在没有共享根目录的文件夹中。本文介绍了我们观察到的、在大规模采用 Claude Code 方面取得成功的一些模式。我们用大型代码库来指代广泛的部署场景拥有数百万行代码的单体仓库、历经数十年构建的遗留系统、分布在独立仓库中的数十个微服务或上述任意组合。这还包括运行在团队不常将其与 AI 编程工具关联的语言上的代码库如 C、C、C#、Java、PHP。在这些场景下Claude Code 的表现比大多数团队预期的要好尤其是最近的模型版本。尽管每个大型代码库的部署都受其特定的版本控制、团队结构和积累约定的影响但本文中的模式具有通用性是考虑采用 Claude Code 的团队的良好起点。一、Claude Code 如何导航大型代码库Claude Code 导航代码库的方式与软件工程师相同它遍历文件系统、读取文件、使用 grep 精确查找所需内容并跟踪整个代码库中的引用。它在开发者的本地机器上运行不需要构建、维护或上传到服务器的代码库索引。基于 RAG检索增强生成的 AI 编程工具通过将整个代码库嵌入向量空间在查询时检索相关文本块来工作。在大规模场景下这些系统可能会失效因为嵌入管道无法跟上活跃工程团队的节奏。等到开发者查询索引时它反映的已经是数周、数天甚至数小时前的代码库状态。检索结果可能返回一个团队两周前重命名的函数或者引用一个在上个冲刺中被删除的模块而且没有任何迹象表明两者都已过时。智能体搜索Agentic search避免了这些故障模式。随着数千名工程师提交新代码不需要维护嵌入管道或集中式索引。每个开发者的实例都从实时代码库工作。但这种方法有一个权衡当 Claude 有足够的起始上下文知道去哪里查找时它的效果最好。这意味着 Claude 导航的质量取决于代码库的设置好坏需要通过 CLAUDE.md 文件和 Skills 来分层提供上下文。如果你要求它在十亿行代码库中查找某个模糊模式的所有实例在工作开始之前就会遇到上下文窗口限制。在代码库设置上投入精力的团队会看到更好的结果。二、工具链Harness与模型同等重要关于 Claude Code 最常见的误解之一是它的能力完全由所使用的模型定义。团队关注模型的基准测试及其在测试任务上的表现。在实践中围绕模型构建的生态系统——即工具链Harness——比模型本身更多地决定了 Claude Code 的性能。工具链由五个扩展点构建而成——CLAUDE.md 文件、Hooks、Skills、Plugins 和 MCP 服务器——每个都有不同的功能。团队构建它们的顺序很重要因为每一层都建立在前一层的基础上。另外两个能力——LSP 集成和 Subagents——完善了整个设置。下面我们解释每个组件和功能的作用CLAUDE.md 文件首要这些是 Claude 在每个会话开始时自动读取的上下文文件根目录文件用于全局概览子目录文件用于本地约定。它们为 Claude 提供了做好任何事情所需的代码库知识。因为它们在每个会话中都会加载无论任务是什么所以保持其内容专注于广泛适用的内容可以防止它们成为性能的拖累。Hooks让设置自我改进大多数团队将 Hooks 视为阻止 Claude 做错事的脚本但它们更有价值的用途是持续改进。Stop Hook可以反思会话期间发生的情况并在上下文仍然新鲜时提出 CLAUDE.md 更新建议。Start Hook可以动态加载团队特定的上下文这样每个开发者都能获得适合其模块的正确设置而无需手动配置。对于 lint 和格式化等自动化检查Hooks 确定性地执行规则比依赖 Claude 记住指令产生更一致的结果。Skills按需提供专业知识不膨胀每个会话在拥有数十种任务类型的大型代码库中并非所有专业知识都需要在每个会话中出现。Skills 通过渐进式披露解决这个问题将专业工作流和领域知识卸载出去否则它们会竞争上下文空间仅在任务需要时加载它们。例如安全审查 Skill 在 Claude 评估代码漏洞时加载而文档处理 Skill 在代码变更需要更新文档时加载。Skills 还可以限定到特定路径以便它们仅在代码库的相关部分激活。一个拥有支付服务的团队可以将其部署 Skill 绑定到该目录这样当有人在单体仓库的其他地方工作时它永远不会自动加载。Plugins分发有效配置大型代码库的一个挑战是好的设置可能停留在小团体内。Plugin 将 Skills、Hooks 和 MCP 配置捆绑到一个可安装的包中因此当一名新工程师在第一天安装该 Plugin 时他们将立即拥有与使用 Claude 已久的人相同的上下文和能力。Plugin 更新可以通过托管市场在整个组织中分发。例如我们合作的一家大型零售组织构建了一个将 Claude 连接到其内部分析平台的 Skill以便业务分析师无需离开工作流即可提取性能数据。他们在向业务部门广泛推出之前将其作为 Plugin 进行了分发。LSP 集成赋予 Claude 与开发者在 IDE 中相同的导航能力大多数大型代码库的 IDE 已经在运行 LSP支撑着跳转到定义和查找所有引用等功能。将这一点暴露给 Claude赋予它符号级精度它可以跟踪函数调用到其定义跨文件跟踪引用并区分不同语言中同名的函数。如果没有它Claude 会对文本进行模式匹配可能定位到错误的符号。我们合作的一家某企业软件公司在 Claude Code 推出之前就在全组织部署了 LSP 集成专门为了使 C 和 C 的大规模导航可靠。对于多语言代码库这是最高价值的投资之一。MCP 服务器扩展一切MCP 服务器是 Claude 连接到内部工具、数据源和 API 的方式否则它无法访问这些资源。最先进的团队构建了暴露结构化搜索的 MCP 服务器作为 Claude 可以直接调用的工具。其他团队将 Claude 连接到内部文档、工单系统或分析平台。Subagents将探索与编辑分离Subagent 是一个独立的 Claude 实例拥有自己的上下文窗口它接受一个任务、完成工作并仅将最终结果返回给父级。一旦工具链就位一些团队会启动一个只读 Subagent 来映射子系统并将发现写入文件然后让主 agent 根据完整的信息进行编辑。组件说明表格下表总结了每个组件的功能、加载时机以及我们看到的最常见误区组件是什么加载时机最适合常见误区CLAUDE.mdClaude 自动读取的上下文文件每个会话项目特定约定、代码库知识将属于 Skill 的可复用专业知识放入其中Hooks在关键时刻运行的脚本由事件触发自动化一致行为、捕获会话学习用 Prompt 处理应该自动运行的事情Skills针对特定任务类型的打包指令按需当相关时跨会话和项目的可复用专业知识将所有内容加载到 CLAUDE.md 中Plugins捆绑的 Skills、Hooks、MCP 配置配置后始终可用在整个组织中分发有效设置让好的设置停留在小团体中LSP通过语言特定服务器提供实时代码智能配置后始终可用类型化语言中的符号级导航和自动错误检测认为是自动的MCP 服务器到外部工具和数据源的连接配置后始终可用让 Claude 访问它无法触及的内部工具在基础配置工作之前就构建 MCP 连接Subagents用于特定任务的独立 Claude 实例被调用时将探索与编辑分离、并行工作在同一会话中运行探索和编辑LSP 通过 Plugin 层访问。Subagents 是一种委托能力而不是配置的扩展点。三、来自成功部署的三种配置模式如何为大型代码库配置 Claude Code在很大程度上取决于该代码库的结构方式。尽管如此在我们观察到的部署中三种模式反复出现。3.1 让代码库在大规模下可导航Claude 在大型代码库中提供帮助的能力受限于它找到正确上下文的能力。每个会话加载过多上下文会降低性能而上下文太少则让 Claude 盲目导航。最有效的部署会预先投入精力使代码库对 Claude 可读。以下几个模式反复出现保持 CLAUDE.md 文件精简且分层。Claude 在遍历代码库时会逐级加载它们根文件用于全局概览子目录文件用于本地约定。根文件应该只是指针和关键注意事项其他一切都会变成噪音。在子目录中初始化而不是在仓库根目录。当 Claude 的范围限定在与任务实际相关的代码库部分时它的效果最好。在单体仓库中这可能感觉有违直觉因为工具化通常假设根访问但 Claude 会自动沿目录树向上遍历并加载沿途找到的每个 CLAUDE.md 文件因此根级上下文永远不会丢失。为每个子目录限定测试和 lint 命令。当 Claude 只更改了一个服务时运行完整测试套件会导致超时并将上下文浪费在无关的输出上。子目录级别的 CLAUDE.md 文件应指定适用于该部分代码库的命令。这适用于每个目录有自己的测试和构建命令的面向服务的代码库。在具有深度跨目录依赖关系的编译语言单体仓库中按子目录限定更难实现可能需要特定的项目构建配置。使用.claude/settings.json中的permissions.deny规则排除生成的文件、构建产物和第三方代码。将规则提交到版本控制意味着团队中的每个开发者都获得相同的降噪效果而无需自己配置。在某些代码库中生成的文件本身就是开发工作的主题。从事代码生成器工作的开发者可以在其本地设置中覆盖项目级排除项而不会影响团队的其他成员。当目录结构无法完成这项工作时构建代码库地图。对于代码未整合到常规目录结构的组织在仓库根目录放置一个轻量级的 markdown 文件列出每个顶级文件夹及其内容的一行描述为 Claude 提供了一个目录它可以在打开文件之前扫描。对于拥有数百个顶级文件夹的代码库分层方法效果最好根文件仅描述最高级别的结构子目录 CLAUDE.md 文件提供下一级别的细节随着 Claude 遍历树而按需加载。对于更简单的情况使用提及 Claude 应参考的特定文件或目录可以完成同样的工作。运行 LSP 服务器让 Claude 按符号而非字符串搜索。在大型代码库中对一个常见函数名使用 grep 会返回数千个匹配项Claude 会消耗上下文打开文件以找出哪个是重要的。LSP 只返回指向同一符号的引用因此过滤在 Claude 读取任何内容之前就发生了。设置这需要为你的语言安装代码智能插件和相应的语言服务器二进制文件Claude Code 文档涵盖了可用的插件和故障排除。一个注意事项在某些边缘情况下即使是分层的 CLAUDE.md 方法也会失效例如拥有数十万个文件夹和数百万个文件的代码库或运行在非 git 版本控制上的遗留系统。我们将在本系列的后续部分中解决这些挑战。3.2 随着模型智能的演进主动维护 CLAUDE.md 文件随着模型的演进为当前模型编写的指导可能会对未来模型产生反效果。指导 Claude 度过它曾经难以应对的模式的 CLAUDE.md 文件在下一代模型发布时可能变得不必要或具有主动限制性。例如一条告诉 Claude 将每个重构拆分为单文件变更的 CLAUDE.md 规则可能帮助早期模型保持正轨但会阻止较新模型进行它处理得很好的协调跨文件编辑。为弥补特定模型局限性而构建的 Skills 和 Hooks无论是模型推理的局限性还是 Claude Code 自身工具的局限性一旦这些局限性不再存在就会变成开销。例如一个在 Perforce 代码库中拦截文件写入以强制p4 edit的 Hook在 Claude Code 添加原生 Perforce 模式后就变得多余了。团队应该预期每三到六个月进行一次有意义的配置审查但在主要模型发布后感觉性能停滞时也值得进行一次审查。3.3 指定 Claude Code 管理和采用的负责人仅靠技术配置无法推动采用。做得对的组织也在组织层面进行了投入。传播最快的推出在广泛访问之前进行了专门的基础设施投资。一个小团队有时甚至只有一个人将工具连接起来这样当开发者第一次接触 Claude 时它已经适合开发者的工作流。在一家公司几名工程师构建了一套 Plugin 和 MCP在第一天就可以使用。在另一家公司整个专注于管理 AI 编程工具的团队在推出开始前就准备好了基础设施。在这两种情况下开发者的第一次体验都是富有成效的而不是令人沮丧的采用从这里传播开来。今天做这项工作的团队往往隶属于开发者体验或开发者生产力部门这通常是负责新工程师入职和构建开发者工具的功能。几个组织中正在出现一个新的角色Agent Manager智能体经理——一个致力于管理 Claude Code 生态系统的混合 PM/工程师职能。对于没有专门团队的组织最小可行版本是一个DRI直接负责人一个人拥有 Claude Code 配置的所有权有权对设置、权限策略、Plugin 市场和 CLAUDE.md 约定做出决定并负责保持它们的时效性。自下而上的采用会产生热情但如果没有人集中有效的内容可能会碎片化。你需要有一个人或团队来组装和推广正确的 Claude Code 约定例如标准化的 CLAUDE.md 层次结构或精选的 Skills 和 Plugins 集。没有这项工作知识将停留在小团体中采用将停滞。在大型组织中尤其是在受监管行业的组织中治理问题很早就出现了例如谁控制哪些 Skills 和 Plugins 可用如何防止数千名工程师独立重建相同的东西如何确保 AI 生成的代码经过与人工生成的代码相同的审查流程为了尽早解决这些问题我们建议从一组定义的批准 Skills、必需的代码审查流程和有限的初始访问开始随着信心的建立而扩展。我们观察到通过在早期建立跨职能工作组将工程、信息安全和治理代表聚集在一起共同定义需求并构建推出路线图组织的部署最为顺利。四、将这些模式应用到你的组织Claude Code 围绕常规软件工程环境设计其中工程师是主要的代码库贡献者仓库使用 Git代码遵循标准目录结构。大多数大型代码库都符合这种模式但非传统设置——如具有大型二进制资源的游戏引擎、具有非常规版本控制的环境或非工程师对代码库做出贡献——需要额外的配置工作。我们的指导假设的是常规设置我们描述的模式在许多客户中都很有效。任何剩余复杂性都需要针对你的代码库、工具和组织的具体判断。这正是 Anthropic 的 Applied AI 团队直接与工程团队合作将这些模式转化为你组织特定需求的地方。
