Q1大代码库下 context 老爆是不是模型太小了不少人的第一反应是这个「context 不够那是不是该换更大模型」Anthropic 官方答案是换模型没用问题不在模型在 Claude Code 怎么找代码。你想啊Opus 4.7 已经支持 1M token 了换算下来两百多万字。但一个像样点的项目动辄几百万行代码再算上依赖库就更夸张了。再大的窗口也塞不下整个代码库这是物理上的事。那 Claude Code 在大代码库下怎么解决「精准找到要改的那几行代码」的业内的主流答案是 RAG把代码切片、做 embedding、塞向量数据库要查的时候用相似度召回。Cursor、Copilot、Windsurf 走的都是这条路。但 Claude Code 偏偏不走。它连 embedding 和向量数据库的影子都没有就靠 grep、读文件、看目录这种最朴素的方式。Anthropic 给这套办法起了个名字叫 agentic search翻译过来就是「让 Claude 像 agent 一样去搜」。Claude 像一个真人工程师一样先ls看根目录、再进auth/看里面有啥、grep 一下「login」找到相关函数、再读middleware.ts和session.ts读一个文件决定下一步读什么循环往复。为什么 Anthropic 选这个反主流的路线官方博客给了三个理由。第一索引会过期。千人团队每天提交几百个 commitembedding pipeline 根本跟不上。等你查的时候索引里返回的可能是两周前已经被重命名的函数。Claude 拿着过期信息推理代码自然就崩了。agentic search 每次都基于当下的代码没有这个问题。第二冷启动几乎为零。RAG 在百万行代码库上建一次索引要十几分钟Claude Code 是「打开就能用」。第三精确匹配向量干不了。你说「帮我看下 getUserById」向量召回会返回 getUserByName、getUserByEmail、fetchUserInfo 一堆「相关」函数。代码很多时候要的就是精确不是相似。那 agentic search 的代价是什么Anthropic 在博客里有一句关键的原话它严重依赖一个好的起点 context。如果你不给它清晰的起点它就会乱翻等摸清楚结构 context 已经被烧得差不多。所以 context 爆不是模型小是你没给 Claude 一个好的起点。下面 6 个问题就是在解决这件事。但在拆这 6 个问题之前得先建立一个核心概念因为它是后面所有答案的总纲。这个概念叫harness。很多人讨论 Claude Code 强不强的时候第一反应是看模型「我用 Sonnet 4.6 还是 Opus 4.7」「benchmark 哪个分高」「要不要升 Max 套餐」但 Anthropic 在博客里抛了一个挺反直觉的论点原话叫「The harness matters as much as the model」翻译过来就是harness 跟模型一样重要。什么意思Anthropic 说大家评估 Claude Code 时都盯着 benchmark 看模型表现但在实际生产中围绕模型搭的那套外壳对最终效果的影响比模型本身还大。打个比方。你请了个米其林三星大厨到家里给你做饭他厉不厉害是模型能力但你家里有没有趁手的灶台、菜刀、调料架、抽油烟机这才是 harness。灶台不行再牛的厨师也炒不出锅气。Anthropic 的 harness 一共七层每层都建立在前一层基础上CLAUDE.md → Hooks → Skills → Plugins → MCP再加两个增强LSP 和子 agent。听着多其实下面几个 Q 就是按官方顺序一层一层把它们拆透Q2 拆 CLAUDE.md 怎么写含 Hooks 怎么挂Q3 拆 LSP 和子目录启动Q4 拆子 agent 怎么和主 agent 协作Q5 拆 Skill、Plugin、MCP 怎么打包分发给团队Q6 看创始人 Boris 怎么把这七样东西组合起来用读完你就明白用好 Claude Code 不是搞定模型选型而是把这套 harness 一层一层搭起来。context 爆不是模型小是你的 harness 没搭好。Q2CLAUDE.md 到底写多长合适写了 1000 行 Claude 反而变笨那我们就从 harness 第一层开始拆也就是 CLAUDE.md。这一层是大代码库下踩坑最多的一个。Anthropic 官方答案非常具体单文件控制在 200 行以内。听起来是不是有点吃惊毕竟一个项目的规范规则随便列列就上千行了。官方的逻辑也很简单CLAUDE.md 每次启动都被整个塞进 context写太长就等于在跟自己抢空间。超过 200 行之后Claude 开始忽略指令的概率会肉眼可见上升。那大代码库下规则确实多怎么办关键词是分层。Anthropic 在博客里有句原话挺狠的「根目录的 CLAUDE.md 应该只放指针和关键的坑其他细节都会变成噪音。」正确做法是 root 文件只放跨包通用约定比如「生产数据库千万别动」「提 PR 前要跑 lint」每个子目录再放自己的 CLAUDE.md 写模块细节。Claude 会自动从当前目录往上走树把沿途每个 CLAUDE.md 都加载进来。但这还不够。Claude Code 创始人 Boris 还为 CLAUDE.md 维护放过一句口号当 slogan「Ruthlessly edit your CLAUDE.md over time」翻译过来就是对你的 CLAUDE.md 下狠手毫不留情地删。怎么判断 CLAUDE.md 该不该留某一行有个特别实用的检查法对每一行你都问自己「如果删掉这行Claude 还会按这条规则做事吗」答案是「会」常识或代码已经体现就该删答案是「不会」才值得留。任何时候你发现 Claude 还在反复犯某个错先别急着加新规则先去看看 CLAUDE.md 是不是已经太长把规则淹没了。Boris 还分享过 Anthropic 内部团队怎么维护这份文件整个 Claude Code 团队共享一份 CLAUDE.md 提交到 git一旦发现 Claude 做错了什么就立刻加进 CLAUDE.md。这份文件在他们那里不是「写一次放着」的文档而是持续打磨的活文件。还有一条 Anthropic 官方建议特别容易被忽略每 3-6 个月对你的 CLAUDE.md 做一次完整审查。为什么因为模型在进化。你三个月前为了约束 Claude 写的「每次重构只改一个文件」可能在新模型上反而变成了枷锁新模型已经能做跨文件协调编辑了旧规则反而把它捆住了。同样为了弥补旧模型某个弱点写的 Hook、Skill模型升级之后可能直接成多余负担。说白了模型都已经往前跑了你的 CLAUDE.md 可能还停在三个月前。如果你感觉 Claude Code 最近用得怎么都上不去一个台阶先别怀疑模型先回去看你的 CLAUDE.md 是不是过期了。总结一下 Q2 的官方答案单文件 200 行以内、分层加载、持续狠删、每 3-6 个月审查一次。不过你可能会问「我哪有时间天天盯着 CLAUDE.md 改」官方对这个问题也有解法叫Hooks。Hooks 是 Claude Code 的事件钩子机制在「编辑完文件之后」「会话开始之前」「工具调用之前」这些时间点上挂脚本做事。大多数人对 hook 的认知停留在「防止 Claude 做错事」比如挂一个 hook 自动跑 lint、自动 format。这没毛病但官方点出来一个反直觉的洞察hook 真正的价值不是阻止 Claude 做错事而是让你的整套设置自我进化。举个例子。挂一个 Stop hook在每次会话结束时让它自动反思「这次 Claude 有没有什么常犯的错误要不要写进 CLAUDE.md」然后 hook 自己改 CLAUDE.md。或者挂一个 Start hook根据你当前所在子目录动态加载这个模块特有的 context今天在payments/下就自动拉支付 skill明天换到auth/下就换成认证相关。这样一来你的 CLAUDE.md 是被 Claude 自己持续打磨的不再需要你手动维护。Boris 自己挂了一个 PostToolUse hook 给 Claude 写完的代码自动跑格式化把偶尔遗漏的 10% 格式问题直接抹平。CLAUDE.md 不是写一次的文档是一份持续打磨的活文件。Q3大代码库里让 Claude 找一个函数总找错文件怎么办CLAUDE.md 这层搞定之后Claude 知道了「这个项目长啥样」。但接下来还有个更细节的问题让它找一个具体函数它老是找错文件。这个问题在多语言大代码库C/C/Java/PHP 这种符号歧义高的语言里特别突出。Anthropic 官方答案是两件事装 LSP 在子目录里启动 Claude。先说 LSP。LSP 全称叫 Language Server Protocol。听着挺唬人但其实你天天都在用平时你在 VS Code 里点「go to definition」「find references」背后跑的就是它。Claude Code 接上 LSP 之后搜代码就不再是按字符串 grep而是按符号搜。举个例子。你在大代码库里 grep 一个getUser函数可能返回三千个匹配前端有、后端有、测试也有。Claude 得一个个读文件判断哪个是你真要改的光这个过程就能把 context 烧光。但有 LSP 之后Claude 直接问 LSP「找跟auth/login.ts那个 getUser 同源的所有引用」。LSP 一口气返回精确的三个过滤工作在 Claude 读文件之前就完成了。Anthropic 官方博客直接把 LSP 称作多语言大代码库下「one of the highest-value investments」并讲了一个真实案例有家做企业软件的公司在全公司铺 Claude Code 之前专门先把 LSP 集成在组织级别铺开就是为了让 C 和 C 这种符号歧义高得离谱的语言能跟 Claude 配合得动。装 LSP 怎么操作在 Claude Code 的/plugin里搜「lsp」找到对应语言的 code intelligence plugintypescript-lsp/pyright-lsp/rust-analyzer-lsp等等装上再装对应的语言服务器二进制pip 装 pyright、npm 装 typescript-language-server 之类。整个过程不超过两分钟。再说子目录启动这件事这是反直觉但官方博客被反复强调的一条。大多数人第一次用 Claude Code习惯都是cd到项目根目录然后claude。在小项目没毛病但在大代码库里这会让 Claude 一上来就把根目录那个超大的 CLAUDE.md 全部加载进 context前端后端 infra 所有微服务的规则全来一遍。官方博客原话叫「Initializing in subdirectories, not at the repo root」。正确做法是直接在你要改的子目录启动。比如要改支付服务就cd services/payments然后claude。Claude 会自动往上走树把根目录的 CLAUDE.md 也加载进来通用规则不丢但优先加载payments/子目录的 CLAUDE.mdcontext 立刻聚焦到「支付」一个领域。除了 LSP 和子目录启动官方博客还提了三个小细节配合起来效果更好第一测试和 lint 命令按子目录写进 CLAUDE.md。Claude 改了支付服务里一个文件结果它跑整个项目的测试套件几十分钟才出结果context 也跟着烧光。每个子目录的 CLAUDE.md 应该明确写「这块用什么命令测怎么 lint」让 Claude 只跑该跑的那一部分。第二用.ignore规则把生成文件、构建产物、第三方代码排除掉。把permissions.deny规则提交到.claude/settings.json整个团队就能自动共享这些排除规则不用每个人手动配。第三目录结构不直观时在根目录放一张「代码库地图」。一份简单的 markdown 文件列出每个顶层文件夹的一句话说明就够。Claude 在动手探索之前先扫一眼这张地图比让它瞎翻一通要快得多。让 Claude 按符号搜代码、按子目录工作准确率立刻翻倍。Q4跨几十个文件的改动Claude 总是改一半就崩怎么救Claude 知道了项目结构、也能找准代码了。这下总能干大活了吧还真不一定。重构、迁移、跨服务联动这种「大动作」上Claude 经常前半段还在状态后半段就开始忘前面、漏改、改错。这是大代码库下另一个高频翻车点。Anthropic 官方答案跨大量文件的改动正确解法是把任务拆成多个会话 用 subagent不是写更长的 prompt。很多人第一反应是改 prompt、改 CLAUDE.md、加更多规则。但 Anthropic 在博客里明说过跨大量文件的改动正确的解法是把任务拆成多个会话。Boris 还把这句话翻译得更直白「Pour your effort into the plan so Claude can one-shot the implementation」意思是与其用一个超长 prompt 让 Claude 一次搞定所有事不如先单独花一轮把方案敲定再分多个会话去实现。具体怎么做第一步派 subagent 出去探索主 agent 留着干净的 context。大代码库下「读懂这个系统怎么工作」本身就要烧掉好几万 token。让 Claude 一边读代码一边改代码相当于让一个人一边查资料一边写论文。Subagent 的思路特别简单派一个小弟去探索让他写一份 findings 报告回来主 agent 看完报告再动手。小弟在独立的 context 窗口里跑读了几十个文件烧的是自己的 context跟主 agent 没关系。他最后只把几百字摘要给主 agent。最简单的操作就是直接跟 Claude 说「先用 subagent 调查一下我们项目里 X 是怎么实现的写成 findings 文件再回来动手改。」第二步会话拆分。会话 1 只做探索写 plan 不动代码会话 2 加载 plan 实现一个模块跑通测试会话 3 实现下一个模块。每个会话都从干净 context 开始plan 文件做桥梁串联。第三步跑大型迁移用/batch。如果你的改动是「整个项目从一个框架迁到另一个」「把几十个文件的某种调用全部替换」这种大规模迁移Claude Code 已经直接内置了一个专门工具叫/batch。用法是这样的先用对话方式把迁移方案敲定然后它一次性派出几十个并行 subagent每个在独立 git worktree 里跑、自测、开 PR。你不用守屏幕跑完直接给你一堆 PR 等 review。这就是创始人 Boris 本人正在用的工作流以前要自己手撸的多 agent 编排现在一行命令就搞定。跨大文件改动救不回来的不是 prompt是会话边界。Q5团队里只有我一个人会用 Claude Code怎么推广前面 3 个 Q 解决的都是「你自己一个人怎么把 Claude Code 用顺」。但接下来这个问题就升级了你用得飞起旁边的同事还在用 demo 版怎么办这是个组织层面的问题也是 Anthropic 官方博客花了不少篇幅讲的一块。Anthropic 官方答案先把好实践做成 skill再用 plugin 打包分发出去再用 MCP 把团队内部系统接进来最后得有人维护这套东西。听着有点多我们一步一步来。第一步先把高频操作做成 skill什么是 skill你可以理解成「针对某个具体任务的 SOP」。比如「这个项目的数据库迁移怎么做」「这个微服务上线的标准流程」这些都是 skill 该干的事。Skill 跟 CLAUDE.md 最大的区别在一个词按需加载。CLAUDE.md 每次会话都全文加载跟你这次任务有没有关系都加载skill 不是它只在 Claude 判断「当前任务需要」的时候才加载平时静静躺在仓库里不占 context。官方有个专门的词叫 progressive disclosure渐进式披露讲的就是这个机制。Boris 还说过一句话特别值得记下来「如果一件事你一天做超过一次就把它做成 skill。」一个大项目里高频操作就那么几十种每个都做成 skill 全队共享效率立刻是几何级提升。skill 还可以绑定到特定路径。「支付服务部署 skill」绑定到services/payments/只有 Claude 在这个目录下工作时才加载避免「改前端代码结果支付 skill 也来凑热闹」这种 context 污染。第二步用 plugin 把好实践打包分发但 skill 本身还在每个人的本地没法共享。这就引出了 plugin。大公司里有个经典问题好的工具配置永远只在小圈子里流传。某个高级工程师本机配置了三十个 skill、十几个 hook、五个 MCP server他用 Claude Code 爽得飞起。但旁边的实习生啥都没配体验就跟用了个 demo 版差不多。Plugin 就是解决这个问题的。它本质上是一个安装包把 skill、hook、MCP、LSP 配置打包在一起。新人入职第一天 install 一下立刻和团队所有人有一样的 Claude Code 能力。官方博客讲过一个特别接地气的案例一家大型零售公司搭了个 skill 让 Claude 连内部数据分析平台业务分析师不用切工具就能拉销售数据。这个 skill 起初只是少数人的本地配置后来打包成 plugin 全公司铺开整个公司业务分析效率被拉高一个档次。公司还可以建自己的 plugin marketplace。谁有更好的实践就更新到 marketplace 里全公司一起受益。第三步用 MCP 把团队内部系统接进来光有 skill 和 plugin 还不够。大代码库下的工作往往不是孤立的得跟团队的 Slack、Jira、内部 wiki、数据库、监控系统都联动。这个连接的桥梁叫MCP serverModel Context Protocol。装一个 Slack MCPClaude 就能搜公司 Slack 消息装一个 BigQuery MCP它就能跑数据查询装一个 Sentry MCP它就能拉线上错误日志。听着很强但官方在这块特别提醒了一个反直觉的点别太早上 MCP。很多团队 CLAUDE.md 都还没写好hook 也没挂就着急忙慌接各种 MCP结果反而把 context 搞得更乱。MCP 是 harness 里最后才该上的一层前面的基础没搭好MCP 接进来的数据就是噪音。正确的顺序是先把 CLAUDE.md 和 skill 打磨好 → 再用 plugin 打包分发 → 最后才上 MCP 把外部世界接进来。第四步得有人负责维护但官方还点出来一个更关键的事光把工具堆起来不够得有人负责维护。Anthropic 观察到推广最顺的组织都有一个共同点在大面积铺开之前会先安排一小队人甚至一两个人把整套基础设施搭好然后才放开访问。开发者第一次摸 Claude Code 就能跑通第一印象如果是「这东西不好使」后面要翻盘就太难了。官方博客里点出了一个正在浮现的新角色叫Agent Manager半 PM 半工程师专门负责 plugin 分发、CLAUDE.md 规范、skill 审批这些事。规模小一些的团队没条件设这个岗位也没关系至少要有一个 DRI直接责任人把 Claude Code 的配置维护起来有拍板权决定哪些 skill / plugin 上、哪些不上。没有人盯着这件事再好的 plugin 也会变成「张三两年前搭的没人会改」的部落知识。好实践不再是个人玩具而是组织资产。Q6Boris 自己平时怎么用 Claude Code前面 4 个 Q 把官方答案讲完了你可能会好奇那 Claude Code 的创始人自己平时是怎么用的这一节其实是个彩蛋但读完你会发现里面藏着创始人对 Claude Code 用法的全部理解。Boris Cherny 是 Claude Code 的创始人他分享过一段让我看完直接破防的话「我同时在终端里跑 5 个 Claude再加 5 到 10 个跑在 claude.ai/code 上并行处理不同任务。」听着是不是有点不可思议但他的这套 setup 其实很值得拆解里面藏着创始人对 Claude Code 用法的全部理解第一他不用--dangerously-skip-permissions。他明确说过自己用/permissions命令把常用的安全命令预先加白名单避免一遍遍点确认但又不放弃权限审计。第二他几乎所有复杂任务都从 Plan Mode 开始。先跟 Claude 把方案敲定再切到 auto-accept 模式让它一发命中地把代码写出来。第三他挂了一个 PostToolUse hook 给 Claude 写完的代码自动跑格式化把 Claude 偶尔遗漏的 10% 格式问题直接抹平避免后面 CI 挂掉。第四他把每天做超过一次的事都做成了 slash command 或 skill。Boris 有句名言「如果一件事你一天做超过一次就把它做成 skill。」他自己有个/commit-push-pr命令一天用几十次避免重复 prompt。第五他给整个 Claude Code 团队共享一份 CLAUDE.md提交到 git。一旦发现 Claude 做错了什么就立刻加进去是一份持续打磨的活文件。把这 5 件事串起来看你会发现创始人对 Claude Code 的态度不是「装上就用」而是把它当成一个会进化的工作伙伴每天都在喂它新规则、新工具、新工作流。这才是大代码库下用好 Claude Code 的底层心态。创始人对 Claude Code 的态度不是「装上就用」而是「每天打磨它」。Q7什么样的项目其实不适合用 Claude Code讲了这么多 Claude Code 在大代码库里有多能打最后还得给你泼一盆冷水它也不是万能药。这是最后一个问题也是 Anthropic 官方博客说得最坦诚的一块。官方原话是这样的「Claude Code 是围绕传统软件工程环境设计的假设工程师是代码库的主要贡献者仓库用 Git代码遵循标准目录结构。」也就是说下面这几种场景 Claude Code 用起来会比较吃力游戏引擎那种大量二进制资源的项目Claude 没法读你的 3D 模型、贴图、音频用非常规版本控制系统的项目比如老牌的 Perforce / Subversion / 自研 VCS需要额外配置才能跑顺非工程师为主贡献的代码库比如产品经理改产品文档、设计师改 Figma 配置文件这些场景 Claude Code 的 harness 不太对得上官方在博客结尾建议这种非常规场景需要更多定制化配置他们的 Applied AI 团队会专门跟客户对接。换句话说Claude Code 当下最擅长的还是「Git 工程师 标准目录」这个最大公约数。如果你的项目正好踩在这几个非常规场景上别死磕找官方支持渠道才是正解。Claude Code 不是万能药最擅长的是「Git 工程师 标准目录」这个最大公约数。最后到这里7 个问题的官方答案就说完了我把这 7 个答案浓缩成 3 句话送你第一Claude Code 在大代码库不是「装上就能用」是要在 harness外围基建上花一次性功夫的。第二最高 ROI 的三个动作是CLAUDE.md 砍到 200 行以内 在子目录启动 Claude 装 LSP。这三件事做完体验立刻不一样。第三跨大文件改动、团队推广、CLAUDE.md 维护这些大代码库下的硬骨头官方都给了具体答案Boris 自己也在用你照抄就行。现在你可以打开你公司的项目对照这 7 个问题逐一过一遍看看哪几个你已经做对了哪几个还差一截。
