前言
三面被问"百万行代码里怎么跑好 Claude Code"是一种什么体验？面试现场一愣，平时在几万行模块里跑得顺风顺水，可巨型 monorepo 这一关确实没实操过。回来翻官方博客补课，发现小项目用户最容易漏掉的，是规模化场景里那套"另一套玩法"。
Claude Code 在大代码库好不好用，主要不是模型的事，而是围绕模型搭的脚手架 harness 配得怎么样------五层扩展点加三套配置模式，这才是百万行场景里真正决定上限的东西。
把原文那段面试对话还原一下，看官追问的逻辑链很清晰：
👔 面试官：你在百万行代码的项目里怎么用好 Claude Code？
🙋♂️ 候选人：说实话，我只跑过几万行的小模块，几百万行规模的还没经验，要不您分享一下？
👔 面试官：那我问问你，为什么 Claude Code 不走 RAG 那条 embedding 索引路线？
🙋♂️ 候选人：因为它直接在文件系统里游走读文件、grep 精确定位，永远面对最新代码，索引不会过期。
👔 面试官：那它在十亿行里找模糊模式为什么会失败？
🙋♂️ 候选人：因为一开始没有足够上下文知道去哪找，上下文窗口很快就耗光了。
👔 面试官：所以决定表现的不只是模型本身，那围绕模型搭的那套生态叫什么？五个扩展点分别是什么？
这段对话基本就把 80% 的人筛掉了------能接住"五层扩展点"的人，才有资格谈规模化落地。这道题考的不是"会不会用"，而是"在规模化场景下有没有思考过工具怎么落地"。
读完这篇文章，你能搞明白：为什么 RAG 那套索引方案在大代码库里跑不动，Claude Code 走了哪条路；harness 五层扩展点 CLAUDE.md / Hooks / Skills / Plugins / MCP 各自干什么、建设顺序为什么重要；LSP 和 Subagents 这两个辅助能力怎么和五层配合；三个反复出现的配置模式 （可导航、维护配置、专人负责 agent manager）；架构师视角的六个工程取舍 ；以及面试话术里 60 分和 90 分的差距在哪几环。
不管你是只会用 Claude Code 跑几万行小模块的开发者，还是在大 monorepo 里挣扎过工具落地的工程师，或者是准备面 AI Agent 岗的候选人，这篇都该收一份。开拆！
一、为什么Claude Code不怕"代码库太大"
先说清楚为什么 Claude Code 不怕"代码库太大"，这是后面所有讨论的前提。大部分 AI 编程工具走的是 RAG 路线：把整个代码库做 embedding、建索引、查询时检索相关片段。这套方案在小项目里没问题，但放到大规模、高频迭代的团队里就会出毛病。
1. RAG 那套索引方案的死穴
embedding pipeline 跟不上代码提交的速度。等你去查的时候，索引反映的可能是几周甚至几小时前的代码状态。检索出来的函数可能上周就被改名了，引用的模块可能上个迭代就删掉了------你拿到的"相关片段"其实已经是过时数据。代码库越大，索引重建成本越高、滞后越严重。代码本体是活的，索引却是几小时前的快照，AI 拿着过期地图找路，撞墙是常态。
2. Claude Code 走的另一条路
Claude Code 不建索引、不上传代码库，而是像一个真正的工程师那样直接在文件系统里游走：读文件、用 grep 做精确定位、顺着代码引用一路追下去。它永远面对的是活的、最新的代码，不存在索引漂移的问题。
这套思路的好处显而易见------代码长什么样它看到的就是什么样。但代价也是真实存在的：Claude 的导航能力，很大程度上取决于它一开始有没有"足够的上下文知道该去哪找"。
3. 十亿行里找模糊模式为什么会失败
如果让它在十亿行代码里找一个模糊的模式，很可能还没开始干活呢，上下文窗口就已经耗光了。这是"按需导航"路线的天花板------它依赖先验的导航方向，没有方向感的盲搜在大库里会迅速耗光预算。
这也是为什么官方博客反复强调：那些真正做得好的团队，都在代码库的"可读性"上下了很大功夫。让 Claude 一开始就有"该去哪找"的明确线索，是这套方案能跑起来的工程前提。后续五层 harness 的核心目标之一，就是给 Claude 提供这个方向感。
二、harness五层脚手架：决定表现的不是模型本身
这里有一个常见误解。很多人觉得 Claude Code 的能力完全取决于用的模型------换个更强的模型，效果就线性变好。但实际上不是这样的。围绕模型搭建的整套生态，也就是所谓的 harness（脚手架），才是决定它在实际项目里表现好不好的关键因素。
1. 五层是什么，顺序为什么重要
这套 harness 由五个扩展点组成，建设顺序很关键，因为每一层都建立在前一层之上：
- 第一层 CLAUDE.md：每次会话自动加载的上下文文件，给 Claude "这个代码库长什么样"的方向感
- 第二层 Hooks：钩子，让整套系统持续进化，不是单纯防错
- 第三层 Skills：技能，通过"渐进式披露"按需加载专业知识
- 第四层 Plugins：插件，把 skills、hooks、MCP 配置打包成可安装整体
- 第五层 MCP servers：让 Claude 连接内部工具、数据源和 API
为什么要按这个顺序？因为连 CLAUDE.md 都没写好，Claude 一上来就没有方向感，后面四层都白搭；Skills 还没建立，Plugins 里打包的内容就是空的。每层都是下一层的地基。
2. 五层之外的两个辅助能力
除了这五个扩展点，还有两个能力值得单独说一下：
- LSP 集成：语言服务器协议。让 Claude 能拿到代码的语义信息------定义跳转、引用查找、类型推断这类静态分析能力，而不是只靠文本匹配瞎猜
- Subagents：子代理。把复杂任务拆给子代理并行处理，主代理只拿结论，节省主上下文窗口
这两个不算"扩展点"，但和五层是配合关系。LSP 给 Claude 加了"语义眼睛"，Subagents 给 Claude 加了"分身术"。五层是横向扩展（增加知识源和能力源），LSP 和 Subagents 是纵向增强（提升单次导航的质量和容量）。
3. 为什么说"决定表现的不是模型本身"
模型是基础，但给的是"通用能力"。一个通用能力很强的模型，丢进完全没配置的百万行代码库里，照样会上下文耗光。harness 做的事情是把通用能力定向化------告诉它仓库约定、给它专业工具、给它连接外部数据源、给它兜底防错。
类比一下：模型是发动机，harness 是底盘和导航。发动机再强，没有导航也会在陌生城市里绕圈子。这也是为什么后面几章要单独拆五层、讲三套配置模式------这些才是规模化场景下真正拉开差距的东西。
三、第一层 CLAUDE.md：每次会话自动加载的上下文文件
第一层是 CLAUDE.md 文件，整个 harness 最底层的地基。它是每次会话自动加载的上下文文件，本质上是给 Claude 一份"这个代码库的入门手册"。
1. 根目录放全局，子目录放局部
CLAUDE.md 的分层机制：根目录放全局信息，子目录放局部约定。比如根目录写"这是一个 TypeScript monorepo，用 pnpm workspace，提交前必须跑 pnpm lint"，而 services/auth/CLAUDE.md 写"这个服务用 OAuth2，所有 token 必须走 Redis 缓存"。
为什么要分层？如果全堆在根目录，每次会话都会加载所有内容，子模块的局部约定会污染全局上下文。分层的好处是------Claude 进到哪个子目录工作，就只加载哪一层，根目录的全局信息始终在场，局部信息按需加载。
2. 内容一定要精炼，不然会拖累性能
这是 CLAUDE.md 最容易被忽视的铁律：它每次会话都会加载，所以内容必须精炼。原文里 Anthropic 反复强调------很多人把 CLAUDE.md 当文档库用，写了几千行，结果每次会话都要先把这几千行塞进上下文窗口，留给实际工作的预算就少了。
正确做法是只放三类信息：导航线索 （代码库入口在哪、模块边界怎么划分、关键命名约定）、强约束 （必须做什么、不能做什么）、不能从代码本身推断出的隐性知识（比如某个 legacy 模块为什么不能动）。
3. 它解决的是"该去哪找"的方向感问题
回过头看第一章那个"十亿行找模糊模式会失败"的问题，CLAUDE.md 就是给它方向感的那一层。它不是给 Claude 答案，而是给 Claude 一张地图------告诉它这个仓库的骨架在哪、哪些区域是高风险区、哪些约定不能违反。
没有 CLAUDE.md 的 Claude Code，就像把一个新员工丢进百万行代码里让他自己摸------他能跑，但效率极低，上下文窗口会被无意义的探索消耗掉。CLAUDE.md 是把"新员工"变成"有 onboarding 文档的员工"的那一层。
四、第二层 Hooks：让系统持续进化的钩子
第二层是 Hooks，也就是钩子。很多人对 hooks 的理解停留在"防止 Claude 做错事"的脚本层面------比如禁止它删某些目录、强制它跑测试再提交。但原文里 Anthropic 强调了一个更有价值的用法：让整套系统持续进化。
1. 防错只是 hooks 的最低层用法
防错型 hooks 当然有用：在 Claude 试图执行危险操作前拦截、在它写完代码后强制跑 lint、在它提交前检查 commit message 格式。这些是"硬约束"，把不可违反的规则用代码而不是提示词实现。但如果只把 hooks 当防错用，就浪费了它真正的能力------防错是"阻止错误发生"，持续进化是"让系统从错误中学习"。
2. 更有价值的用法：让系统持续进化
持续进化型 hooks 的核心思路是：把每次会话中暴露的问题，反向沉淀成新的规则或技能。比如 Claude 反复尝试一个错误的 API 用法，hook 捕获到这个失败模式，自动写进 CLAUDE.md 的"常见错误"小节；Claude 在某次重构里漏掉边界 case，hook 在测试失败后把它抽象成一条新的 Skill；Claude 用了不合规的依赖，hook 拦截后把依赖加进禁用清单。
这种用法把 hooks 从"静态护栏"升级成"动态学习闭环"------系统每次跑都会比上次更懂这个代码库。
3. 为什么 hooks 是第二层
hooks 依赖 CLAUDE.md 提供的基础上下文。如果 CLAUDE.md 都没写清楚仓库约定，hooks 拦截什么、学习什么都没有标准。先有"这个仓库应该长什么样"的定义（CLAUDE.md），才能用 hooks 去校验"实际跑出来是不是这个样子"。顺序一旦反了，hooks 会变成无源之水，要么过度拦截、要么漏拦截。这也是为什么 Anthropic 把建设顺序讲得很死：CLAUDE.md 必须先于 Hooks。
五、第三层 Skills：渐进式披露按需加载专业技能
第三层是 Skills，也就是技能。核心思想是通过"渐进式披露"来按需加载专业知识，避免每次会话都塞满用不上的内容。
1. 渐进式披露是什么意思
渐进式披露（progressive disclosure）的核心是：专业知识不一次性全塞进上下文，而是按需加载。Claude 一开始只看到一个技能的"标题+一句话描述"，当任务真的需要这个技能时，才把完整内容加载进来。
举个例子：大型代码库可能有"如何处理支付回调""如何调试 Kafka 消费者""如何跑端到端测试"等几十个专业技能。如果全写进 CLAUDE.md，每次会话都要加载这几十个技能的完整内容，上下文窗口直接爆掉。渐进式披露的做法是------CLAUDE.md 只列一个技能目录，Claude 在遇到支付回调任务时才加载"支付回调"技能的完整文档。
2. Skills 和 CLAUDE.md 的分工
两者不是替代关系，是分层关系：CLAUDE.md 放"始终在场"的信息------代码库骨架、全局约定、强约束，每次会话都加载；Skills 放"按需在场"的信息------特定场景的专业知识、特定模块的操作手册，只在任务匹配时加载。这种分工的工程价值在于：上下文窗口是稀缺资源，CLAUDE.md 占的是"固定开销"，Skills 占的是"可变开销"。固定开销要压到最小，可变开销要按需触发。
3. 为什么 Skills 是第三层
Skills 依赖前两层：需要 CLAUDE.md 提供代码库骨架（这样才知道有哪些场景需要技能），需要 Hooks 提供沉淀机制（这样遇到新场景才能自动抽象成新 Skill）。没有前两层，Skills 就是一个静态文档库，没有动态生长的能力。
4. Skills 的真正价值在规模化场景
在小项目里，Skills 的价值不明显------代码库就那么大，全堆进 CLAUDE.md 也能跑。但到了百万行级别，Skills 就成了刚需。大代码库的场景数量是指数级增长的------支付、订单、库存、风控、日志、监控、部署、回滚------每个场景都有自己的专业知识和踩坑清单。如果不用渐进式披露，上下文窗口根本装不下。这也是为什么 Anthropic 把 Skills 放在第三层------它是规模化场景下"专业知识管理"的核心机制，是从"小项目能跑"到"大项目跑得好"的关键分水岭。
六、Plugins、MCP、LSP 与 Subagents：打包、连接与辅助
前三层讲完了，剩下 Plugins、MCP 两个扩展点，加 LSP 和 Subagents 两个辅助能力，一起拆。
1. 第四层 Plugins：把扩展打包成可安装整体
Plugins 把 skills、hooks、MCP 配置打包成一个可安装整体。在大型组织里不同团队需要的扩展组合不同------支付团队要"支付回调 Skill + 风控 Hook + 内部账务 MCP"，前端团队要"组件库 Skill + ESLint Hook + 设计系统 MCP"。Plugins 把一组配套扩展打包成可分发单元，新项目 plugin install 一键拿到全套配置。它解决的是"怎么分发"问题，所以排在第四------必须先有三层内容可打，才能打包。
2. 第五层 MCP：连接内部工具和数据源
MCP servers 让 Claude 能连接 Jira 工单、Confluence 文档、内部监控、CI/CD、数据库等外部数据源。如果 Claude 只能读文件系统，它看到的是"代码长什么样"，看不到"这个 bug 是哪个工单报的""这个服务上次部署是什么时候"。MCP 把这些接进来，让 Claude 从"只懂代码"升级成"懂代码也懂上下文"------大代码库里很多 bug 根因不在代码本身，而在代码和历史变更、工单、监控的关联里。
3. LSP 和 Subagents：两个纵向增强
- LSP（语言服务器协议）：给 Claude 语义眼睛。没有 LSP 时找引用靠 grep 文本匹配，碰到同名变量、动态语言就出错。有了 LSP 能精确定义跳转、引用查找、类型推断，在大代码库里导航效率提升是数量级的
- Subagents 子代理：给 Claude 分身术。把复杂任务拆给子代理并行处理，主代理只拿结论。比如跨 5 个模块的重构，派 5 个子代理分别读 5 个模块，每个只返回接口摘要，主代理拿 5 份摘要做决策，主上下文只装摘要不装源码
五层是横向扩展（增加知识源和能力源），LSP 和 Subagents 是纵向增强（提升单次导航的质量和容量）。七者配合，才是在大代码库里跑好 Claude Code 的完整 harness。 
七、三个反复出现的配置模式
Anthropic 结合多个成功部署案例，总结出三类反复出现的模式。这三类不是孤立技巧，而是"把五层 harness 用起来"的工程范式。
1. 模式一：让代码库在规模化下依然可导航
两个典型做法：一是 CLAUDE.md 写得精简分层 ------根目录只放全局骨架，子目录放局部约定，内容控制在"导航线索+强约束+隐性知识"三类，不堆文档。二是不在仓库根目录启动，而是在具体子目录里启动 ------在百万行 monorepo 根目录启动意味着一上来就要面对整个代码库的复杂性；cd 到要工作的子目录再启动，Claude 的初始上下文就限定在这个子模块里，导航范围缩小，效率显著提升。
这个模式的本质是主动给 Claude 缩小搜索空间------大代码库的复杂性客观存在，但单次会话的工作范围可以人为控制，把"百万行"宏观问题降维成"当前子模块几千行"的微观问题。
2. 模式二：随着模型能力进化主动维护 CLAUDE.md
针对旧模型局限性写的规则，换了新模型后可能反而变成束缚。旧模型做不到的事（比如跨文件类型推断），新模型可能已经能做到了。如果 CLAUDE.md 里还写着"必须手动列出所有相关文件因为模型找不到"，新模型反而会被这条规则误导。
原文建议每三到六个月做一次配置复盘。复盘要问的不是"CLAUDE.md 还在不在"，而是"里面的规则还有没有必要"------哪些是新模型已经能自主完成的、哪些已经过时、哪些需要新增。
3. 模式三：明确谁来负责 Claude Code 的管理和推广
那些扩散得最快的团队，往往是在大规模开放使用之前，就先投入一个小团队（有时甚至只有一个人）把工具链搭好。
Claude Code 不是"装上就能用好的"工具。五层 harness 需要有人设计、维护、推广。如果全员同时上手，每个人都在重复踩坑，没有人沉淀经验，工具扩散会是混乱的低效扩散。有些组织出现了新角色 agent manager------专门负责这套工具链的管理推广：维护 CLAUDE.md、收集团队踩坑经验抽象成 Skills、决定哪些场景该用 Plugins 打包、推动配置复盘。
这个模式的本质是工具的规模化落地需要专人负责。不是"谁用谁负责"，而是"有人为工具的整体健康度负责"------这和 DevOps 时代需要 SRE、数据时代需要数据治理负责人是同一个逻辑：新工具范式需要新角色。
八、从架构师视角看 Claude Code 在大代码库的六个工程取舍
前几章把五层 harness 和三套配置模式讲完了，但"知道有什么"和"知道怎么选"是两回事。这一章从架构师视角拆六个工程取舍------每个都是大代码库落地时绕不开的决策点。
1. RAG 索引 vs 文件系统导航：不要试图两套都上
有些团队想"两套都上"------既建索引又允许文件系统导航，以为能互补。这是伪命题：两套并行会带来一致性问题，索引说的和文件系统说的对不上时 Claude 该信谁？而且维护两套成本远高于一套。判断是：既然选了文件系统导航路线，就把配套做透------CLAUDE.md 给方向感、LSP 给语义精度、Subagents 给容量扩展，不在底层路线上骑墙。
2. CLAUDE.md 的精简 vs 详尽：固定开销必须压到最小
常见误区是"写得越详细 Claude 越懂"。实际上每次会话都加载的内容，写得越详细固定开销越大，留给实际工作的上下文预算越少。判断标准是：这条信息是不是"始终在场"才有价值。如果是"偶尔用到"的专业知识，应该走 Skills 按需加载。把 CLAUDE.md 当成"每次会话的入场费"来设计------入场费越低，留给正事的预算越多。
3. Hooks 的防错 vs 进化：别只当护栏用
只把 Hooks 当防错护栏，系统能力是静态的------每次跑都一样。要让系统持续进化，Hooks 必须承担"从错误中学习"的角色，把失败模式反向沉淀成新规则。防错型 Hooks 是底线，进化型 Hooks 是上限。底线必须有（防止删库、防止提交未测试代码），但只有底线没有进化的系统，跑一百次和跑一次没区别。
4. Skills 的颗粒度：太粗不触发，太细触发太频繁
Skills 太粗（一个技能涵盖整个支付系统）会导致触发不准；太细（一个技能只讲一个函数）会导致触发太频繁，上下文反而被占满。判断标准是：一个 Skill 应该对应一个"可识别的工作场景"。比如"处理支付回调""调试 Kafka 消费者"是有明确触发信号的场景（关键词、文件路径、错误类型），Claude 能判断"现在是不是在这个场景里"。颗粒度的本质是"场景的可识别性"，不是内容的多寡。
5. MCP 的接入范围：不是越多越好
常见误区是"能接的全接上"。但每个 MCP server 都会增加 Claude 的工具选择空间，工具太多时 Claude 的工具选择准确率会下降（这是 LLM 工具调用的通病）。判断是：只接"和代码工作强相关"的数据源。Jira 工单（关联 bug 上下文）、CI/CD 状态（关联部署历史）是强相关；全员日历、HR 系统是弱相关，不该接。MCP 接入范围应该按"这个数据源能不能帮助 Claude 更好地理解或修改代码"来筛。
6. 专人负责 vs 全员自治：规模化落地必须有 agent manager
全员自治在小团队里能跑（每个人都改 CLAUDE.md），但到规模化场景就会变成"公地悲剧"------每个人都在加规则，没人删过时规则，CLAUDE.md 越来越臃肿，Skills 越来越碎片，Hooks 互相冲突。规模超过一定阈值（比如 50 人以上使用）必须有 agent manager 角色。这个角色不是"管理员"（不给权限管控），而是"工具链的维护者"------负责配置复盘、Skills 去重、Hooks 协调、Plugins 打包。
九、面试话术：考官想听的是什么
回到这道面试题本身。考官问"百万行代码库怎么跑好 Claude Code"，他想听的到底是什么？
1. 两个常见的错误回答
错误回答一："换个更强的模型就行了。"------把规模化场景的问题简化成了模型能力问题。大代码库的瓶颈从来不是模型不够强，而是 harness 没配好。换个再强的模型，丢进一个没有 CLAUDE.md、没有 Skills、没有 MCP 的百万行 monorepo，照样上下文耗光。
错误回答二："把代码库做 RAG 索引就好了。"------暴露的是对 Claude Code 工作原理的根本误解。Claude Code 不走 RAG 路线，它直接在文件系统里导航。建议给它做 RAG 索引，方向就错了。而且 RAG 索引在大代码库里的过期问题，正是 Claude Code 选择文件系统导航的原因。
2. 高分答题模板：三层结构加一句升华
第一层（基本原理）："Claude Code 不走 RAG 那条 embedding 索引路线，它直接在文件系统里游走，读文件、grep 精确定位、顺着引用追下去，永远面对最新代码。所以代码库再大，它也不需要建索引，不存在索引漂移问题。"
第二层（细节为什么）："但直接在文件系统里导航有个天花板------如果一开始没有足够上下文知道该去哪找，十亿行里盲搜会迅速耗光上下文窗口。所以真正决定表现的是围绕模型搭的 harness 脚手架，五层扩展点：CLAUDE.md 给方向感、Hooks 防错加持续进化、Skills 渐进式披露按需加载、Plugins 打包分发、MCP 连接外部数据源。再加 LSP 提供语义精度、Subagents 节省主上下文。"
第三层（设计哲学）："Anthropic 总结了三个反复出现的配置模式：让代码库可导航（CLAUDE.md 精简分层加子目录启动）、随模型进化主动维护配置（每三到六个月复盘）、明确专人负责（agent manager 角色）。这三套模式的本质是------大代码库里 Claude Code 好不好用是配出来的，不是天生的。"
升华一句："所以这道题考的不是会不会用 Claude Code，而是在规模化场景下有没有思考过工具怎么落地。"
3. 60 分 vs 90 分对比表
| 追问点 | 60 分回答 | 90 分回答 |
|---|---|---|
| 为什么不走 RAG？ | "RAG 索引会过期" | "embedding pipeline 跟不上提交速度，大代码库索引漂移严重，Claude Code 选择文件系统直接导航，永远面对最新代码" |
| 十亿行里为什么会失败？ | "上下文会耗光" | "按需导航依赖先验方向感，没有 CLAUDE.md 给方向时，盲搜会迅速耗光预算------这正是 harness 五层要解决的问题" |
| 五层扩展点分别是什么？ | 能说出两三个 | 能按建设顺序完整说出五层，并解释为什么这个顺序（每层是下一层的地基） |
| 怎么在大代码库里配？ | "写好 CLAUDE.md" | 三套配置模式：可导航（分层+子目录启动）、维护配置（三到六个月复盘）、专人负责（agent manager） |
4. 加分项
时间允许的话，带出以下几点都是加分项：
- LSP 和 Subagents 的配合关系：五层是横向扩展，LSP 和 Subagents 是纵向增强，两者是配合不是替代
- Skills 颗粒度的判断标准：一个 Skill 对应一个"可识别的工作场景"，不是按内容多寡切分
- agent manager 角色的本质：不是权限管控，而是工具链健康度维护------类比 SRE 之于 DevOps
- 配置复盘的判断标准：不是"CLAUDE.md 还在不在"，而是"里面的规则还有没有必要"------旧模型做不到的事新模型可能已经能做到了
能把"五层扩展点"和"三套配置模式"完整说出来，基本就到 90 分。能再带出 LSP/Subagents 的配合关系和 Skills 颗粒度的判断标准，就是 95 分往上了。
总结
回过头看这道面试题，它问的根本不是"你会不会用 Claude Code"，而是"你有没有在规模化场景下思考过工具怎么落地"。核心信息很朴素------Claude Code 在大项目里好不好用，很大程度上是"配出来的"，不是"天生"的。
- Claude Code 不走 RAG 路线，直接在文件系统里导航，永远面对最新代码，但天花板是"没有方向感时盲搜会耗光上下文"
- harness 五层扩展点才是决定表现的关键：CLAUDE.md 给方向感、Hooks 防错加进化、Skills 按需加载、Plugins 打包分发、MCP 连接外部------建设顺序不能乱，每层是下一层的地基
- LSP 和 Subagents 是纵向增强，和五层横向扩展是配合关系，不是替代
- 三套配置模式：可导航（CLAUDE.md 分层加子目录启动）、维护配置（每三到六个月复盘）、专人负责（agent manager 角色）
- 六个工程取舍：底层路线别骑墙、CLAUDE.md 固定开销要压到最小、Hooks 别只当护栏、Skills 颗粒度按场景可识别性切、MCP 只接强相关数据源、规模化必须有 agent manager
- 模型是基础，harness 是上限------真正决定体验上限的，是团队有没有花时间搭这套体系，有没有人专门维护它
这就是"用过工具"和"理解工具怎么在规模化场景下落地"之间的差距。面试场上接不住这道题不丢人，回来把这块功课补上，下次再被问到至少能从"五层扩展点"一路聊到"agent manager 角色"，把对话接住。
欢迎评论区交流你在大型代码库里用 Claude Code 踩过的坑，或者你们团队是怎么配这套 harness 的。