本文永久链接 – https://tonybai.com/2026/05/17/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start
大家好，我是Tony Bai。
在 AI 编码工具普及的今天，我们往往容易陷入一种认知误区：认为只需接入最顶尖的模型，生产力便会随之爆发。然而，当我们将 Claude Code 引入拥有数百万行代码、错综复杂的微服务架构或积淀深厚的遗留系统中时，单纯的“模型能力”往往会触碰到现实的边界。
真正的大规模部署，比拼的并非仅仅是单一模型的推理上限，而是如何构建一套高效的“工程化框架”。如何通过 CLAUDE.md 让 AI 读懂组织的隐性约定？如何利用钩子（Hooks）与插件（Plugins）让工具实现自我演进？又该如何将“代码库地图”转化为 AI 的导航指南？
近期Anthropic发布了一篇名为《How Claude Code works in large codebases: Best practices and where to start》的文章，深度揭露了 Anthropic 团队在企业级场景下的实践智慧，为你揭示如何通过精细化的工程布局，让 Claude Code 真正成为大型代码库中不可或缺的高效协作伙伴。
下面是这篇文章的译文。
最成功的 Claude Code 部署案例都共享了一套跨配置、工具和组织结构的可识别模式。本文是“Claude Code 大规模应用”系列文章的一部分，旨在分享工程组织在大规模环境下使用 Claude Code 的最佳实践。
Claude Code 正应用于数百万行的单体仓库（monorepo）、拥有数十年历史的遗留系统、跨越数十个存储库的分布式架构以及拥有数千名开发人员的组织中。这些环境带来了较小的、更简单的代码库所不具备的挑战，即跨越不同子目录或没有共享根目录的遗留代码，其构建命令各不相同。
本文涵盖了我们观察到的促成 Claude Code 大规模成功部署的模式。我们用“大型代码库”来指代广泛的部署场景：包含数百万行代码的单体仓库、运行数十年的遗留系统、数十个微服务的集合，或以上各种形式的组合。这还包括运行在 AI 工具通常不常关联的语言（如 C, C++, C#, Java, PHP 等）上的代码库。（得益于最近的模型版本，Claude Code 在这些情况下的表现优于大多数团队的预期。）虽然每个大型代码库的部署都由其特定的版本控制、团队结构和累积的约定所塑造，但这些模式在各处具有普遍性，是团队考虑采用 Claude Code 的良好起点。
Claude Code 像软件工程师一样导航代码库：它遍历文件系统、读取文件、使用 grep 查找所需内容，并跨代码库遵循引用。它运行在开发人员的机器上，不需要构建、维护代码库索引或上传到服务器。
基于 RAG（检索增强生成）的 AI 编码工具通过嵌入整个代码库并在查询时检索相关块来工作。在大规模场景下，这些系统可能会失败，因为嵌入管道无法跟上活跃的工程团队。当开发人员查询索引时，它反映的是几周、几天甚至几小时前存在的代码库。检索可能会返回一个两周前重命名的函数，或引用一个在上次推送中已删除的模块，而没有任何过时的提示。
智能体搜索（Agentic search）避免了这些故障模式。没有需要维护的嵌入管道或集中式索引，因为成千上万的工程师在提交新代码。每个开发人员的实例都基于实时代码库中工作。
但这种方法有一个权衡：当 Claude 有足够的上下文知道去哪里时，它效果最好。这意味着 Claude 的导航质量取决于代码库配置的好坏，即通过 CLAUDE.md 文件和技能来分层上下文。如果你要求它在十亿行代码中查找某种模糊模式的所有实例，你在工作开始前就会触及上下文窗口限制。投入精力进行代码库设置的团队会看到更好的结果。
关于 Claude Code 能力最常见的误解之一是它完全由所使用的模型决定。团队专注于模型的基准测试以及它在任务测试中的表现。实际上，围绕模型的生态系统——即“Harness”——比模型本身更能决定 Claude Code 的表现。
该Harness 由五个扩展点构建——CLAUDE.md 文件、钩子（Hooks）、技能（Skills）、插件（Plugins）和 MCP 服务器——每个扩展点服务于不同的功能。团队构建它们的顺序也很重要，因为每一层都构建在前一层之上。LSP 集成和子智能体（Subagents）完善了整个设置。以下，我们解释了这些组件的功能：
CLAUDE.md 文件优先： 这些是 Claude 在每次会话开始时自动读取的上下文文件：根目录用于全局概览，子目录用于本地约定。它们为 Claude 提供无需任何额外操作即可掌握的代码库知识。因为无论任务是什么，它们都会在每次会话中加载，所以确保它们仅包含广泛适用的内容，可以防止它们成为性能负担。
钩子（Hooks）使设置能够自我改进： 大多数团队认为钩子是防止 Claude 做错事的脚本，但它们更有价值的用途是持续改进。一个停止钩子可以在会话期间反思发生了什么，并提出更新 CLAUDE.md 的建议，同时上下文仍然新鲜。启动钩子可以动态加载特定于团队的上下文，因此每位开发人员无需手动配置即可获得适合其模块的设置。对于像代码检查（linting）和格式化这样的自动化任务，钩子可以确定性地强制执行规则，产生比依赖 Claude 记住指令更一致的结果。
技能（Skills）在不使会话臃肿的情况下实现按需专业知识： 在拥有数十个任务的大型代码库中，并非每个专业知识都需要出现在每个会话中。技能通过渐进式披露（progressive disclosure）解决了这个问题，剥离专用的工作流和领域知识，只有当任务需要时才会加载它们。例如，当 Claude 正在评估安全漏洞时，安全审查技能会加载；当进行代码更改且需要更新文档时，文档处理技能会加载。
技能还可以限定在特定路径上，因此它们仅在代码库的相关部分激活。一个拥有支付服务的团队可以将他们的部署技能绑定到该目录，这样当有人在单体仓库的其他地方工作时，它永远不会自动加载。
插件（Plugins）分发工作成果： 大型代码库面临的一个挑战是良好的设置会变得“部落化”。插件将技能、钩子和 MCP 配置捆绑到一个可安装的包中，这样当新工程师在第一天安装该插件时，他们将立即获得与那些一直使用 Claude 的人相同的上下文和能力。插件更新可以通过托管市场（managed marketplaces）在整个组织内分发。
例如，一家大型零售商与我们合作，构建了一个技能，将 Claude 连接到他们的内部分析平台，以便业务分析师无需离开工作流即可获得性能数据。他们在全面推广前将此作为插件分发。
语言服务器协议（LSP）集成赋予 Claude 与开发人员在 IDE 中相同的导航能力： 大多数大型代码库的 IDE 已经在运行 LSP，支持“转到定义”和“查找所有引用”。将此呈现给 Claude 赋予了它符号级精度：它可以跟踪函数调用到其定义、跨文件跟踪引用，并区分不同语言中名称相同的符号。如果没有这一点，Claude 会进行文本匹配，并可能落在错误的符号上。一家企业软件公司在全面推广 Claude Code 之前，在全公司范围内集成了 LSP，专门用于 C 和 C++ 的大规模导航。对于多语言代码库，这是最具价值的投资之一。
MCP 服务器扩展一切： MCP 服务器是 Claude 如何连接到它原本无法触及的内部工具、数据源和 API。最复杂的团队构建了 MCP 服务器，通过将结构化搜索作为 Claude 可以直接调用的工具来暴露出来。其他人则将 Claude 连接到内部文档、票务系统或分析平台。
子智能体（Subagents）分离探索与编辑： 子智能体是一个拥有自己上下文窗口的隔离 Claude 实例，它承担任务、完成工作，并仅将最终结果返回给父智能体。一旦Harness框架就位，一些团队会启动一个只读子智能体来映射子系统并将发现结果写入文件，然后由主智能体进行全面编辑。
下表总结了每个组件的作用、加载时间以及我们常见于每个组件的错误：
你如何为大型代码库配置 Claude Code 取决于代码库的结构。尽管如此，我们观察到的部署中始终出现三种模式。
Claude 帮助大型代码库的能力取决于其查找正确上下文的能力。每次会话加载太多上下文会导致性能下降，而加载太少则会使 Claude 盲目导航。最有效的部署会在前期投入，使代码库对 Claude 可读。以下模式始终出现：
一个警告：存在分层 CLAUDE.md 方法失效的边缘情况，例如拥有数十万个文件夹和数百万个文件的代码库，或非 git 版本控制系统上的遗留系统。我们将在本系列的后续文章中讨论它们的挑战。
为当前模型编写的指令可能会在面对未来模型时产生反作用。引导 Claude 遵循其难以处理的模式的 CLAUDE.md 文件，在下一代模型出现时，可能会变得不必要或起到积极的限制作用。例如，一条告诉 Claude 分解每次重构的 CLAUDE.md 规则可能曾帮助旧模型保持在轨道上，但会阻止新模型完成它所处理的更高级的跨文件编辑。
在模型的推理能力或 Claude Code 自身工具的开销变得不再重要时，这些限制就成了负担。一个截获文件写入以在 Perforce 代码库中强制执行 p4 edit 的钩子，在 Claude Code 增加原生 Perforce 模式后变得多余。
团队应预计每三到六个月进行一次有意义的配置审查，但只要在重大模型发布后感觉性能停滞，也值得进行一次审查。
仅靠技术配置无法推动采用。那些在组织层面也进行了正确投入的组织获得了成功。
传播速度最快的推广都有专门的基础设施投资，而非广泛的全面开放。一个小团队，有时甚至只有一个人，将工具预先配置好，以便开发人员在第一次接触时就适合他们的工作流程。在一家公司，几名工程师在第一天就构建了一套可用的插件和 MCP；在另一家公司，另一个团队在推广前就准备好了基础设施。在这两种情况下，开发人员的首次体验是富有成效的，而不是令人沮丧的，采用也由此蔓延开来。
今天从事这项工作的团队倾向于位于开发人员体验或开发人员生产力部门，这通常是负责新工程师入职和构建开发工具的职能。几个组织中出现的一个新兴角色是智能体经理（agent manager）：一个混合 PM/工程师职能，专门致力于管理 Claude Code 生态系统。对于没有专门团队的组织，最小可行版本是一个 DRI：一个人拥有对 Claude Code 配置的所有权、对设置、权限策略、插件市场和 CLAUDE.md 约定的批准权，并负责保持它们的更新。
自下而上的采用会产生热情，但如果没有人集中管理，就会变得支离破碎。你需要有一个个人或团队组装并倡导正确的 Claude Code 约定（例如标准化的 CLAUDE.md 层级和精选的技能与插件）。如果没有这项工作，知识将保持部落化，采用也会停滞。
在大型组织中，特别是在受监管的行业，治理问题很早就出现了，例如：谁控制可用的技能和插件，你如何防止数千名工程师独立重复做同样的事情，你如何确保 AI 生成的代码经过与人类生成的代码相同的审查流程？为了尽早解决这些问题，我们建议从一套定义的经批准的技能、必需的代码信心构建开始。
我们观察到，组织中平稳的部署是在早期通过让工程、信息安全和治理代表聚在一起共同定义需求并建立推广路线图来建立跨职能工作组。
Claude Code 是围绕传统的软件工程环境设计的，工程师是主要的代码库贡献者，且 repo 遵循标准目录结构。大多数大型代码库都符合这一模式，但非传统设置，例如具有大型二进制资产的游戏引擎、具有非常规版本控制的环境，或非工程师参与的代码库，则需要额外的配置工作。我们的指导假设采用常规设置，并且我们观察到的模式在我们的许多客户中都有效。任何剩余的复杂性都需要针对你的代码库、工具和组织进行具体的判断。这就是 Anthropic 的应用 AI 团队直接与工程团队合作，将这些模式转化为适合你组织特定需求的专业知识的地方。
致谢： 特别感谢来自 Anthropic 应用 AI 团队的 Alon Krifcher、Charmaine Lee、Chris Concannon、Harsh Patel、Henrique Savelli、Jason Schwartz、Jonah Dueck 和 Kirby Kohlmorgen 分享他们在规模化部署 Claude Code 方面的经验，并感谢 Zoox 的 Amit Navindgi 对本文提供反馈。
原文链接：https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
Related posts:
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。