Claude Code 大代码库实战：搞懂 harness 比换 Opus 4.7 更重要

平时在个人小项目上用 Claude Code 一直很顺手，可一旦面对公司那些动辄几百万行的庞然大物，各种水土不服就来了。这些问题，也恰恰是 Anthropic 他们自己每天在填的坑。

为了弄清官方到底是怎么玩的，我深挖了 Anthropic 最近那篇关于大代码库实践的官方博客，还刨出了 Claude Code 创始人 Boris Cherny 的一些心得。把这些一手信息嚼碎消化后，我为你梳理了大代码库下最容易栽跟头的七个深坑，以及如何爬出来。

• Q1: 大代码库下 context 动不动就爆，换个更大的模型能解决吗？
• Q2: CLAUDE.md 到底写多长合适？是不是写得越详细越好？
• Q3: 让 Claude 在大型项目里找个函数，它总翻错文件，怎么办？
• Q4: 一遇到跨几十个文件的大改，Claude 改一半就崩，怎么破？
• Q5: 全组只有我一人用过 Claude Code，怎么把好实践铺开？
• Q6: Claude Code 创始人平时是怎么用他自己的工具的？
• Q7: 什么样的项目其实不太适合用 Claude Code？

别急，我们逐一拆解。

Q1: 大代码库下 context 老爆，是不是模型太小了？

很多人第一反应就是：“context 窗口总不够用，那换一个更大的模型不就行了？”

Anthropic 给出的官方答案很干脆：没用，问题不在模型本身，而在于 Claude Code 如何寻找代码。

你想想，Opus 4.7 已经支持 1M token，能装下两百多万字了。但一个上规模的软件项目，代码行数动辄百万，这还没算上各种依赖库。所以，再大的窗口也注定塞不下整个代码库，这是个物理限制。

那 Claude Code 面对海量代码，是怎么做到“精准找到要改的那几行”的？

业界主流答案是 RAG：把代码切片、生成向量嵌入、存入向量数据库，查询时用相似度来检索。Cursor、Copilot、Windsurf 这些都是这么干的。

可 Claude Code 偏不。它没用嵌入，也没用向量数据库，就靠 grep、读文件、看目录这些最“土”的办法。

Anthropic 把这套方法叫 agentic search，说白了，就是“让 Claude 像一个真正的工程师那样去搜代码”。

Claude 的工作流和一个人类开发者差不多：先用 ls 看一眼项目根目录，然后进入 auth/ 目录瞅瞅，接着 grep 一下“login”找相关函数，再去读 middleware.ts 和 session.ts，读完一个文件再决定下一个看什么，周而复始。

为什么偏偏选这条路？Anthropic 给出了三个让人信服的理由。

第一，索引是会过期的。一个千人团队一天能提交几百个 commit，你的向量索引更新速度根本跟不上。等你搜索时，返回的可能是个两周前就被重命名了的函数。Claude 拿着过时的信息去改代码，自然就崩了。而 agentic search 每次都基于最新代码，没有信息滞后的问题。

第二，几乎零冷启动。在一个百万行级别的代码库上建一次 RAG 索引，时间是十多分钟起步。而 Claude Code 的理念是“打开就能干活”。

第三，代码搜索常常需要精确匹配，而不是模糊相似。你说“帮我找到 getUserById”，向量检索可不管，它会给你返回 getUserByName、getUserByEmail、fetchUserInfo 等一堆“看起来相关”的函数。但在改代码时，很多时候我们要的就是那个独一无二的精确符号，不是一堆相似的。

那 agentic search 的代价是什么？官方的原话是，它非常依赖一个优质的起点 context。如果你不给它清晰的上下文起点，它就得像无头苍蝇一样乱翻，等把项目结构摸透了，context 窗口也被烧得差不多了。

所以，context 爆炸，往往不是模型的锅，是你没给 Claude 一个清晰的工作起点。后面的六个问题，其实都在解决这件事。

但在深入之前，我们必须先建立一个核心概念，因为它是所有答案的纲领。

这个概念叫 harness。

大伙儿议论 Claude Code 行不行时，总爱先关注模型：“该用 Sonnet 4.6 还是 Opus 4.7？”，“跑分哪个高？”，“要不要升级套餐？”

可 Anthropic 提出一个反直觉的论点：“The harness matters as much as the model”，意即，harness 这套外围“马具”，和模型本身同样重要。

什么意思？就好比你请来米其林三星大厨，他的技艺就是模型能力；但你家的灶台、菜刀、调料架顺不顺手，这些才是 harness。灶台不行，再牛的厨师也难炒出好菜。

Anthropic 的 harness 体系有七层，每一层都建立在前一层之上，依次是：CLAUDE.md → Hooks → Skills → Plugins → MCP，外加两个强力辅助 LSP 和 子 Agent。

听着复杂？别慌，下面几个问题就是按照官方逻辑，一层层为你拆解清楚，带你理解并驾驭 人工智能 时代的新型工程实践。

• Q2 拆 CLAUDE.md 怎么写（含 Hooks）
• Q3 拆 LSP 和子目录启动
• Q4 拆子 Agent 如何与主 Agent 协作
• Q5 拆 Skill、Plugin、MCP 如何打包分发
• Q6 看创始人 Boris 怎么组合使用这七样东西

读完后你会豁然开朗——用好 Claude Code，关键不在模型选型，而在于 把这套 harness 一层层给搭结实了。

context 爆掉，不是模型小，而是你的 harness 没搭好。

Q2: CLAUDE.md 到底写多长合适？写了 1000 行 Claude 反而变笨？

现在我们来拆 harness 的第一层：CLAUDE.md。这也是在大代码库下踩坑最多的一层。

官方的答案非常精确：单文件控制在 200 行以内。 是不是有点出乎意料？毕竟一个项目的规范随便列列就上千行了。

官方的逻辑很直接：CLAUDE.md 在每次会话启动时会被整个塞进 context，写太长就是在跟自己抢地盘。内容超过 200 行后，Claude 开始选择性忽略指令的概率会肉眼可见地上升。

那大型项目规则确实多，怎么办？关键词是：分层。

Anthropic 有一句狠话：“根目录的 CLAUDE.md 只应放提示和关键的坑，其他细节都会变成噪音。”

正确姿势是：根目录文件只放跨包的通用约定（比如“生产数据库千万别动”、“提 PR 前要跑 lint”），然后每个子目录再放自己的 CLAUDE.md，写明模块专属细节。Claude 会自动从你的当前工作目录向上遍历并加载路径上的所有 CLAUDE.md 文件。

但这还远不够。Claude Code 的创始人 Boris 甚至为 CLAUDE.md 的维护放了一句口号：“Ruthlessly edit your CLAUDE.md over time”，也就是“对 CLAUDE.md 下狠手，毫不留情地删减”。

怎么判断某一行该不该留？有个非常实用的“删掉测试法”：面对每一行内容，你问自己，“如果删掉这行，Claude 还会按这条规则办事吗？”如果答案是“会”（该规则是常识或代码已体现），删。答案是“不会”，才值得留。

任何时候，当你发现 Claude 又在犯某个老错误，先别急着往上加新规则，先回头检查 CLAUDE.md，是不是已经冗长到把关键规则给淹没了。

Boris 还分享过团队内部的做法：整个 Claude Code 团队共享同一份提交到 Git 的 CLAUDE.md。一旦有人发现 Claude 做了错事，就立刻把新规则加进去。 这份文件不是“一次写完就放着”的文档，而是一份持续打磨的活文档。

还有条官方建议极易被忽视：每 3 到 6 个月，对你的 CLAUDE.md 做一次地毯式审查。

为什么？因为模型在持续进化。你三个月前为了约束 Claude 加进去的“每次重构只能改一个文件”，可能在新模型上反而成了枷锁，因为新模型已经能很好地处理跨文件协调编辑了。同样，你为了弥补旧模型弱点写的 Hook 或 Skill，在模型升级后可能就成了多余的负担。

说白了，模型都迭代好几轮了，你的 CLAUDE.md 可能还停在原地。如果你感觉 Claude Code 最近水平怎么都上不去一个台阶，先别怀疑模型，先回去看看你的 CLAUDE.md 是不是过期了。

总结一下 Q2：单文件 200 行内、分层加载、持续狠删、按期审查。

可你可能要问：“我哪来那么多时间天天盯着 CLAUDE.md 改？” 官方的解法叫 Hooks。

Hooks 是 Claude Code 的事件机制，能在“文件编辑后”、“会话开始前”、“工具调用前”这些时间点挂载自定义脚本。

大多数人对 Hook 的认知还停留在“防止 Claude 出错”，比如挂个 Hook 自动跑 lint、格式化代码。这没错，但官方洞察到 Hook 更深层的价值：它的真正力量不是阻止错误，而是让你的整套配置能自我进化。

一个绝佳的例子是“Stop hook”（会话结束钩子）。在每次会话结束时，让 Claude 自动反思：“这次会话里我有没有反复犯什么错？需要写进 CLAUDE.md 吗？”然后 Hook 可以自己去更新 CLAUDE.md。

还有一个例子是“Start hook”（会话开始钩子），它能根据你当前所在的子目录，动态加载该模块特有的上下文。你今天在 payments/ 目录下干活，Hook 就自动拉取支付相关的 Skill；明天切到 auth/ 目录，Hook 就自动换上认证相关的配置。

这样一来，你的 CLAUDE.md 就能被 Claude 自己持续打磨，而不是全靠你手动维护。 Boris 他自己就挂了个 PostToolUse Hook，在 Claude 每次写完代码后自动格式化，把他偶尔漏掉的 10% 格式问题瞬间抹平。

CLAUDE.md 不是一劳永逸的静态文档，而是一份需要持续打磨的活文件。

Q3: 大代码库里让 Claude 找一个函数，总找错文件，怎么办？

拿下了 CLAUDE.md 这层，Claude 总算了解了项目全貌。但更细节的问题来了：让它找一个具体函数，它怎么老是找错文件呢？这个问题在多语言混搭的大型项目里尤其突出，像 C/C++, Java, PHP 这类符号歧义性高的语言。

官方给出的解法是两件事：给 Claude 装上 LSP，并在子目录里启动它。

先说 LSP。它的全称是 Language Server Protocol，看着挺唬人，但本质就是你每天在 VS Code 里用的“转到定义”和“查找所有引用”功能背后的支撑协议。

当 Claude Code 接上 LSP，它搜代码时就不再是简单的字符串匹配，而是按符号来搜。设想一下，你在巨大代码库里 grep 一个 calculateTotalPrice，可能跳出三千个匹配，前端有、后端有、测试也有。Claude 要一个个文件去读、去判断哪个才是你要改的，光这个过程就能把 context 烧个精光。

但有了 LSP，Claude 可以直接问 LSP：“找出跟 OrderService.ts 里的 calculateTotalPrice 同源的所有引用。” LSP 能精准返回 3 个结果，过滤过程在 Claude 开始读文件前就完成了。

Anthropic 在官方博客中把 LSP 称为多语言大代码库下“回报最高的投资之一”，并分享了一个案例：一家做企业软件的公司，在全公司推行 Claude Code 之前，优先级最高的事就是在组织层面统一集成 LSP，为的就是让 C 和 C++ 这种符号歧义高得像天书的语言，也能顺畅地与 Claude 配合。

装 LSP 怎么操作？在 Claude Code 的 /plugin 界面里搜 “lsp”，找到对应语言的 code intelligence plugin（比如 typescript-lsp, pyright-lsp, rust-analyzer-lsp）装好，再用包管理器安装对应的语言服务器二进制程序（pip install pyright, npm install typescript-language-server 之类的），整个过程不超过两分钟。

再说“子目录启动”这件事，这极为反直觉，却是官方博客反复强调的关键一招。大多数新手用 Claude Code，都喜欢 cd 到项目根目录然后直接 claude。小项目没问题，但在一个巨型项目里，这会让 Claude 一启动就把根目录下那可能无比庞大的 CLAUDE.md，以及前端、后端、基础设施所有微服务的规则全部塞进 context。

正确的做法是，直接在你干活的那个子目录下启动 Claude。比如你要改支付服务，就 cd services/payments 然后 claude。

Claude 会自动向上遍历，把根目录的 CLAUDE.md 也加载进来，通用规则不丢；但它会优先加载 payments/ 子目录下的 CLAUDE.md，context 瞬间聚焦到“支付”这一个领域。

除了这两板斧，官方博客还补充了三个锦上添花的细节：

1. 把测试和 lint 命令按子目录写进 CLAUDE.md。Claude 可能只改了支付服务的一个文件，却跑去跑整个项目的测试大套件，几十分钟才出结果，context 就白白烧掉了。每个子目录的 CLAUDE.md 应明确指出“本模块用什么命令测试，怎么 lint”。

2. 用好 .ignore 规则，把生成文件、构建产物、第三方库统统排除。把 permissions.deny 规则提交到 .claude/settings.json，整个团队就能自动共享这些排除项。

3. 项目结构不直观，就在根目录放一张“代码库地图”。一份简单的 Markdown 文件，列清每个顶层文件夹的“一句话简介”就够了。Claude 动手探索前先扫一眼这张图，效率比它自己瞎翻高得多。

让 Claude 学会按符号搜代码、按子目录维度工作，它的精准度会立刻上一个大台阶。

Q4: 跨几十个文件的改动，Claude 总是改一半就崩，怎么救？

现在，Claude 弄清了项目结构，也能精准找代码了。这下总能扛大活了吧？还真未必。遇到重构、迁移、跨服务联动这种大动作，Claude 经常是前半程还在状态，后半程就开始“失忆”——忘记前文、漏掉修改、逻辑对不上。这是大代码库场景下又一高频翻车点。

官方的解方是：面对跨大量文件的改动，正确的解法是利用计划模式将会话拆分 + 派子 Agent 去侦察，而不是写一长篇天书般的 prompt。

你第一反应可能是去改 prompt、改 CLAUDE.md、加更多规则。但 Anthropic 在博客里明确说了：跨文件大改，把任务拆分成多个会话，才是正道。

创始人 Boris 用更直白的话翻译了一遍：“Plour your effort into the plan so Claude can one-shot the implementation”，与其用一个巨长的 prompt 让 Claude 一口气搞定所有事，不如先单独花一轮时间把方案敲死，再拆成多个独立的会话去逐个击破。

具体怎么操练？

第一步：派子 Agent 去探索，让主 Agent 保持 context 绝对干净。

在大型项目中，“读懂这个系统如何工作”本身就要消耗好几万 token。如果你让 Claude 边读代码边改代码，就相当于让一个人边查字典边写文章，顾此失彼。

Subagent 的思路很简单：派一个“小弟”出去侦察，让它读几十个文件把来龙去脉搞清楚，然后写一份简短的 findings 报告回来。主 Agent 看完报告再动手。小弟是在自己独立的 context 窗口里跑，读再多文件烧的都是它自己的 context，和主 Agent 无关。最后交给主 Agent 的，只是一份几百字的扼要报告。

最直接的操作就是告诉 Claude：“先用一个子 Agent 帮我调查一下我们项目里 X 功能是怎么实现的，把发现写进 findings 文件，然后你再回来动手改。”

第二步：会话拆分。

先单独用一个会话进行探索、制定 plan，不写代码；接着开启一个新会话，加载 plan 去实现一个独立模块并跑通测试；再开新会话实现下一个模块。每个会话都从干净的 context 开始，plan 文件就是连接不同会话的桥梁。

第三步：对于大型迁移，直接用 /batch。

如果你的改动属于“把整个项目的框架从 A 迁到 B”或者“把几十个文件里某种调用全部替换”这种规模化操作，Claude Code 已经内置了专门的工具叫 /batch。

用法很简单：先用对话方式敲定迁移方案，然后一条命令，它就能一次性派出几十个并行的子 Agent，每个在独立的 Git worktree 里干活、自测、开 Pull Request。你甚至不用死守屏幕，过一会儿回来直接收获一堆待 Review 的 PR。

这就是创始人 Boris 本人在用的工作流。以前需要自己动手写的多 Agent 编排逻辑，现在一行命令就打包搞定。

跨大文件改动救不回来的，往往不是 prompt 不够长，而是你没有定义一个清晰的会话边界。

Q5: 团队里只有我一个人会用 Claude Code，怎么推广？

前面解决的都是“个人如何用好 Claude Code”的问题。但现实很快会逼着你面对下一个难题：你用得风生水起，身边的同事可能连它有什么本事都不知道，怎么办？

这是一个组织层面的大难题，Anthropic 的官方博客也花了浓重的笔墨来探讨。

官方的完整通关路线图是这样的：先把你的好实践沉淀为 Skill → 再用 Plugin 将其打包分发给团队 → 最后用 MCP 将团队的内部系统接入 → 并且，这一切都得有个负责人。

听着步骤有点多？我们一步一步看。

第一步：将高频操作固化为 Skill

什么是 Skill？你可以把它理解成针对某个具体任务的标准作业程序。比如“这个项目的数据库迁移怎么做？”、“这个微服务的上线标准流程是什么？”，这些都是 Skill 该负责的事。

Skill 和 CLAUDE.md 最大的一个区别就是：按需加载。

CLAUDE.md 是每次会话无差别全量加载；而 Skill 则不然，它平时就静静躺在你的技能库里，只有当 Claude 根据当前任务判断“这个 Skill 我用得上”时才会被加载，完全不占多余的 context。官方给这个机制起了个专业名词，叫“渐进式披露”。

创始人 Boris 有句话特别值得记住：“如果一件事你一天做超过一次，就把它做成 Skill。”一个大项目里的高频操作其实就那么几十种，要是每个都沉淀成团队共享的 Skill，整体效率提升是指数级的。

Skill 还可以按路径绑定。“支付服务部署 Skill”就绑定到 services/payments/ 目录，只有当 Claude 在这个目录下干活时才加载，完全解决了“改前端代码，结果支付 Skill 也跑出来凑热闹”这种 context 污染问题。

第二步：用 Plugin 打包好实践并分发

但 Skill 本身还在你本地，无法共享。这时就轮到 Plugin 出场了。

大公司里有个永恒痛点是：好的工具配置永远只在少数人的“小圈子”里流传。那个技术大牛本机配置了三十个 Skill、十几个 Hook、五六个 MCP 服务器，他用 Claude Code 简直飞起。但旁边的实习生啥都没配，体验可能跟试用版一样。

Plugin 就是来解决这个问题的。它本质上是一个安装包，能把 Skill、Hook、MCP 配置、LSP 设定全都打包在一起。新人入职第一天，一个 install 命令执行完，瞬间就有了和团队里的技术骨干一模一样的 AI Agent 开发能力。

官方博客讲了个很接地气的案例：有家大型零售公司，内部做了个 Skill 让 Claude 能直连内部数据分析平台，业务分析师不用切工具就能拉数据。起初这只是少数人的本地配置，后来被做成 Plugin 全公司分发，整个业务分析效率被拉高了一个量级。

公司甚至还能建起自己的 Plugin 市场。谁有更好的实践就更新到市场里，全公司雨露均沾，共同进步。

第三步：用 MCP 接入内部系统

光有 Skill 和 Plugin，还不够。大代码库下的工作从来不是孤岛，你需要和团队的 Slack、Jira、内部知识库、监控系统联动。这个连接的桥梁就是 MCP server。

装个 Slack MCP，Claude 就能搜索公司聊天记录；装个 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 审核等这些事。

规模再小一点的团队，没条件设新岗位也没关系，至少要有一个明确的直接责任人把 Claude Code 的配置生态维护起来，并且有拍板权决定哪些 Skill、Plugin 该上，哪些不该上。没有人盯着，再好的 Plugin 也会慢慢烂成“张三两年前搭的，现在谁也不敢动”的部落知识。

好实践不应是某个人的私人玩具，而应沉淀为整个组织的技术资产。

Q6: Boris 自己平时是怎么用 Claude Code 的？

前面几个问题基本把官方的最佳实践讲透了。你也许会好奇，那 Claude Code 的老大 Boris Cherny 他自己平时是怎么用的？

这部分像个彩蛋，但细品之下你会发现，这里面藏着创始人对 Claude Code 用法的全部深层理解。

Boris 分享过一段让我看了直接破防的话：“我会在终端同时开着 5 个 Claude，另外再在 claude.ai/code 上跑 5 到 10 个，用它们并行处理不同的任务。”

听着是不是有点天方夜谭？但他的这套工作 setup，完全值得细细拆解：

1. 他从不用 --dangerously-skip-permissions。他明确说过，自己会用 /permissions 命令把常用的安全命令预先放进白名单，避免一次次点确认打断思路，但又不放弃底层权限的安全审计。

2. 他几乎所有复杂任务，都从 Plan Mode 起步。 先和 Claude 把方案聊透、敲定，然后再切到自动确认模式让它一枪命中地将代码写出来。

3. 他挂了个 PostToolUse Hook，用于代码的自动格式化。 把 Claude 偶尔会遗漏的 10% 格式小问题就地解决，避免后续 CI 流程挂掉。

4. 他把每天做超过一次的事，都做成了 Slash Command 或 Skill。 Boris 的名言又来了：“如果一件事你一天做超过一次，就把它做成 Skill。” 他自己就有一个 /commit-push-pr 的命令，一天能用几十次，省去了重复输入相同 prompt 的时间。

5. 他给整个 Claude Code 团队共享一份 CLAUDE.md，提交到 Git 仓库里。 一旦发现 Claude 做错了什么，这条新规则就会被立刻加进去，确保它是一份不断进化的活文件。

把这五点串起来看，你会发现，创始人对 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 + 工程师 + 标准目录”这个经典模式。

最后

到这里，七个坑的官方解法和解题思路就全说道完了。我想把所有的答案，浓缩成三句最真诚的建议送给你：

第一，Claude Code 在大代码库里，绝不是“装上就能飞”，它需要你在这个 harness 上，投入一次性的集中精力去搭建和打磨。

第二，回报率最高的三个动作是：把 CLAUDE.md 砍到 200 行以内 + 坚持在子目录启动 Claude + 装上 LSP。把这三件事做完，你会立刻感到体验上的质变。

第三，跨文件大改、团队推广、CLAUDE.md 持续维护……这些大代码库里的硬骨头，官方其实都已经给出了非常具体可抄的答案。它的亲生父亲 Boris 自己就在用，你直接“抄作业”就行了。

现在，不妨就打开你公司的项目，对照这七个问题，逐一做个体检，看看哪几项你已经做到位，哪几项还差一口气。

参考资料：Anthropic 官方博客《How Claude Code works in large codebases: Best practices and where to start》: https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start

希望这篇源自 云栈社区 的深度解读，能帮你建立起对 Coding Agent 工程体系的系统认知。用好工具，永远是从理解其设计哲学开始的。