Anthropic 实战经验：Claude Code 在大型代码库里怎么用好，
这篇文章基于他们观察到的真实部署——百万行 monorepo、跑了几十年的遗留系统、横跨几十个 repo 的分布式架构。

1. Claude Code 的导航方式
不是 RAG，是 Agentic Search。
传统 AI 编码工具靠向量嵌入整个代码库，然后在查询时检索相关块。问题是嵌入管道跟不上活跃团队的提交速度——你查到的可能是两周前改过名的函数，或者上个 Sprint 已经删掉的模块。
Claude Code 的做法更像一个工程师：直接遍历文件系统、读文件、用 grep 精准定位、顺着引用跳转。没有需要维护的集中索引，每个开发者都在用最新的代码库。
代价是：需要足够的起始上下文才知道去哪找。

2. Harness 比模型本身更重要
这是文章最核心的观点：Claude Code 的表现，由围绕模型搭建的"工具生态"决定，而不只是模型本身。
Harness 由 7 个扩展点组成，有优先级顺序——
1）CLAUDE.md：最先配置。每次会话自动加载的上下文文件，根目录放全局约定，子目录放局部规范。保持精简，别把什么都塞进去。
2）Hooks：在关键节点触发的脚本。更有价值的用法是"自我改进"——stop hook 在会话结束时反思发生了什么，并建议更新 CLAUDE.md；start hook 动态加载团队特定上下文。格式检查这类事情交给 hook 做，比让 Claude "记住规则"更可靠。
3）Skills：按需加载的专项能力包。不是每个任务都需要全部知识。安全审查的 skill 只在做漏洞评估时加载，文档更新的 skill 只在代码变更后触发。也可以绑定到特定路径，支付服务的部署 skill 只在那个目录下自动激活。
4）Plugins：把 skills + hooks + MCP 配置打包成可安装的包，解决"好配置只在小圈子里流传"的问题。新工程师第一天装上插件，就能获得老手一样的上下文和能力。
5）LSP 集成：让 Claude 获得 IDE 级别的代码导航能力。没有 LSP 时，Claude 靠文本匹配可能找到错误的同名函数。有了 LSP，"查找所有引用"直接返回指向同一个符号的引用，而不是几千条字符串匹配结果。C/C++ 等语言尤其值得优先投入。
6）MCP Servers：连接内部工具、数据源和 API。成熟团队会把结构化搜索暴露成 Claude 可直接调用的工具。
7）Subagents：用于拆分"探索"和"编辑"。只读 subagent 负责映射某个子系统并把结果写入文件，主 agent 再基于完整信息进行编辑。

3. 让大型代码库对 Claude 可导航
几个关键操作：
1）CLAUDE.md 分层管理，根目录只放关键指引，子目录补充局部规范
2）在子目录里初始化，不要总在 repo 根目录——让 Claude 聚焦到真正相关的范围
3）用 .ignore 文件排除生成文件、构建产物和第三方代码，减少噪音
4）没有清晰目录结构的代码库，在根目录放一个 markdown 文件做"目录索引"，列出每个顶层文件夹的一行说明

4. 定期维护 CLAUDE.md
模型迭代会让旧的 CLAUDE.md 规则失效甚至起反效果。比如"每次重构只改单文件"这条规则，可能是为旧模型的局限性写的，对新模型反而是约束。
建议每 3-6 个月做一次配置审查，大版本模型发布后也值得专门回顾一次。

5. 组织层面同样重要
Anthropic 观察到的规律：推广最顺的组织，在大规模上线前就有专人先把工具链搭好。工程师第一次用就是顺手的体验，采用率才会扩散。
没有专门团队的话，最低配置是一个 DRI——一个人负责 Claude Code 配置、settings.json、插件市场和 CLAUDE.md 规范的所有决策。
底层自发采用会产生热情，但没有人来汇总和推广什么是有效的，知识会停留在小圈子里，采用率就会停滞。

访问：claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start

#HOW I AI# #程序员#