（来源：AI信息Gap）
刚刚，Anthropic 官方发布了一篇毫不起眼的技术博客。
名为「How Claude Code works in large codebases」。
Claude Code 怎么在大型代码库里干活。
但这篇文章讲的内容，可能比一次新模型发布都重要。
先说结论。
「决定 Claude Code 表现上限的，不是模型，是你围绕模型搭的那套脚手架。」
Anthropic 把这套脚手架叫「Harness」。
这篇博客来自 Anthropic 的 AI 应用团队，专门帮企业客户把 Claude Code 部署到百万行级别的代码库里。
百万行代码的单体仓库、几十年历史的遗留系统、分布在十几个仓库里的微服务架构。
他们在这些环境里反复踩坑，总结出下面这套规律。
Claude Code 不做索引。
市面上部分 AI 编程工具选择先用 RAG 把整个代码库做一遍向量嵌入，查询的时候检索最相关的片段。但问题是，当几千个工程师每天都在提交代码，嵌入管道根本跟不上。你查到的函数，可能两周前就被重命名了。
Claude Code 的做法是直接在文件系统里搜索。和人类工程师一样，遍历目录、读文件、用 grep 工具查找关键词、沿着引用跳转。每个开发者查看的都是最新的代码，不存在索引过期的问题。
代价是什么？它需要充足的起始信息，才知道该往哪里找。
Harness，之前爆火的一个词。
Anthropic 把 Claude Code 的整套扩展体系拆分为了七层。
最底层是 CLAUDE.md。每次会话启动时自动加载。根目录放全局规范，子目录放局部约定。Claude 在代码库里移动时，会一路往上找，把沿途的 CLAUDE.md 文件叠加起来读一遍。
这个过程相当于给 Claude 一份地图。但这份地图必须精简。塞太多内容，反而会拖累模型性能。社区经验是单个文件 60 到 120 行最优，200 行封顶。超过之后，后面的规则会被默认降低权重。
再上面一层是 Hooks。这是脚本级别的硬性控制。跟 CLAUDE.md 的「建议」不同，Hook 是百分百强制执行的，Claude 绕不过去。格式化、lint 检查、类型校验，不应该靠 AI 记住，应该靠 Hook 强制执行。
Anthropic 提出了一个反直觉的用法。大多数团队把 Hook 当安全护栏，防止 Claude 犯错。但更高阶的用法是 Stop Hook，每次会话结束时让 Claude 回顾刚才干了什么，自动总结经验并更新 CLAUDE.md。
会话结束，经验沉淀。下次会话，Claude Code 就会更懂你。
然后是技能 Skills。这是按需加载的专家知识。不是每次会话都加载全部知识。比如安全审查 Skill 只在审核代码时加载，文档更新 Skill 只在改了代码之后加载。
Skills 还能绑定路径。支付团队的部署 Skill 只在支付服务目录下激活，别人改其他模块时不影响。
再往上是插件 Plugins。把 Skills、Hooks、MCP 配置打包成一个安装包，通过公司内部插件市场分发。新员工第一天安装，就能拥有和老员工一样的起点。
LSP，语言服务器协议（Language Server Protocol）。让 Claude 用符号级精度导航代码，而不是靠字符串匹配。在大型代码库里，grep 一个常见函数名会返回几千条结果，Claude 得打开大量文件才能判断哪条对。LSP 直接返回同一符号的引用，Claude 还没读文件，过滤就已经完成了。
MCP 服务器（Model Context Protocol），让 Claude 连接内部工具、数据源和 API。最成熟的团队把内部结构化搜索封装成 MCP 工具，Claude 直接调用。还有团队把内部文档系统、工单系统、数据分析平台全接进来了。
最外层是 子代理。它们是独立的 Claude 实例，有自己的上下文窗口。有团队的做法是先派一个只读子代理去扫描某个子系统，把结果写进文件，然后主代理带着完整认知去更新代码。
探索和修改，应该分开进行。
Anthropic 给出了三条实操建议。
第一，在子目录启动 Claude Code，别在仓库根目录。
这条建议在单体仓库里很反直觉。因为工具链通常假设你在根目录操作，但 Claude 从子目录启动时，会自动往上找 CLAUDE.md，根目录的上下文也不会丢失。上下文从一开始就聚焦在相关代码上，不会被百万行无关代码稀释。
第二，测试和 lint 命令要按子目录配置。
只改了一个服务，却运行全仓库的测试，直接超时，上下文全是无关输出。子目录级别的 CLAUDE.md 应该写清楚这个目录用什么命令运行测试、怎么构建。
第三， CLAUDE.md 文件需要定期维护。
模型一直在更新。你给上一代模型写的规则，可能在下一代模型上不适用了。比如你告诉 Claude「每次重构只改一个文件」，早期模型确实需要这个约束来保持稳定。但新模型已经能处理跨文件的协调编辑了，这条规则反而限制了它的能力。
Anthropic 建议每三到六个月重新审查一次配置，每次模型更新后也要检查一遍。
除了技术架构，Anthropic 花了大量篇幅聊一件事，「怎么在公司里推广 Claude Code。」
推广最快的团队，有一个共同点。「在大范围发放访问权限之前，先有一个小团队搭好了基础建设。」
比如这家公司，两个工程师提前搭建了一套 Plugins 和 MCP 配置。团队所有人第一天就能上手。
另一家公司更为激进，专门成立了一个 AI 编程工具管理团队，在大范围推广前就把基础设施全搭好了。
Anthropic 还提到一个新角色，「Agent Manager」。半个 PM + 半个工程师，专门负责 Claude Code 的配置、权限和插件市场。
没有专职团队的公司，最低配是一个 DRI（直接责任人）。一个人管理 CLAUDE.md 层级、设置和权限策略，负责让这些配置跟上模型迭代。
网友热评，「审核 CLAUDE.md 是这篇文章里最被低估的一条建议。CLAUDE.md 用得越久越乱。根本原因不是缺少规则，是过期规则没人清理。这一条的投入产出比，比 LSP 和子代理加起来都高。」
更一个网友表示赞同。
「CLAUDE.md 的架构设计比模型选择重要 10 倍。配置搞错了，5 个并行代理会信心满满地构建出 5 套完全不同的系统。瓶颈是共享状态，不是规模。」
这篇文章发布的时间节点，有点意思。
企业费用管理平台 Ramp 最新数据显示，Anthropic 商业客户占比达到 34.4%，首次超过 OpenAI 的 32.3%。
其中最大的增长点就是 Claude Code。据 SemiAnalysis 报告，Claude Code 贡献了全球 GitHub 公开代码提交的 4%，一个月前这个数字还是 2%。翻了一倍。
Claude Code 年化收入已经达到 25 亿美元。从 0 到 10 亿美元花了 6 个月，从 10 亿到 25 亿只花了 3 个月。
这篇博客标注的是「Claude Code at scale」系列的第一篇。后面还会有针对非 Git 版本控制、超大规模文件夹等特殊场景的内容。
你的 Claude Code 不给力，可能不是模型的问题。
是你还没给它搭好脚手架。
我是木易，Top2 + 美国 Top10 CS 硕，现在是 AI 产品经理。
