在面试中遇到一个有意思的问题，关于百万行规模的代码库里，如何用好Claude Code。说实话，当时确实有点措手不及——平时用Claude Code处理几万行的小模块很顺手，但真正在巨型monorepo里实战？确实没有经验。于是老实交代了实际情况，结果面试官反而很耐心地讲了一通。

面完之后越想越不甘心，干脆把这块功课补上。正好Anthropic前不久发了一篇官方博客，专门讲Claude Code在大代码库里的工作机制，以及那些真正把工具用起来的团队都做对了什么。看完才发现，这确实是"小项目用户"容易忽略的知识盲区。百万行级别的代码库，跟几万行完全是两种玩法。

整理出来，既是给自己补课，也是为了让更多人能理解在规模化场景下如何落地。读完这篇，你能搞清楚：

• Claude Code为什么不怕大代码库：它不走RAG那条路，而是像真正的工程师一样在文件系统里游走
• Harness五层扩展点：CLAUDE.md、Hooks、Skills、Plugins、MCP，每层的作用和建设顺序
• LSP集成和Subagents：符号级导航和探索-修改分离的高级能力
• 三个配置模式：规模化可导航、主动维护配置、明确责任人
• 架构师视角的落地取舍：什么时候该投入配置建设，什么时候轻量够用

不管你是准备大厂Agent岗面试的候选人，还是正在团队里推广Claude Code的工程师，这篇都能直接参考。

一、面试官到底想考什么

先说结论。这道题根本不是在考"你会不会用Claude Code"，而是在考你有没有在规模化场景下思考过工具怎么落地。

第一层考点：知不知道大规模代码库的挑战在哪。很多人觉得Claude Code就是"装上就能用"，在小项目里确实如此。但到了百万行级别的monorepo，挑战完全不一样：上下文窗口怎么分配、测试命令怎么限定范围、生成的代码怎么不破坏既有架构。能讲出这些挑战的人，面试官知道你不只玩过Demo。

第二层考点：理不理解harness的概念。很多人觉得Claude Code的能力完全取决于模型。但实际上，围绕模型搭建的整套"脚手架"（harness）才是决定实际表现的关键。模型是引擎，harness是底盘和操控系统。光有引擎没有底盘，跑不快也跑不稳。

第三层考点：有没有配置维护意识。那些真正把Claude Code用得好的团队，都有人专门负责维护配置体系。面试官想听的是：你知不知道CLAUDE.md需要分层写、Hooks需要持续优化、Skills需要按需加载、配置需要定期复盘。

回答"我只跑过几万行"本质上是在说"我没思考过规模化场景"，面试官当然不满足。这道题的筛选作用就在这里——把用过工具的人和理解工具怎么在规模化场景下落地的人分开。

二、为什么Claude Code不怕代码库太大

很多AI编程工具的做法是：把整个代码库做embedding，建一个索引，查询时检索相关片段。这套方案就是RAG。在小项目里没问题，但到了大规模、高频迭代的团队里就会出问题。

为什么RAG在大代码库里会失效？因为embedding pipeline跟不上代码提交速度。等你查询的时候，索引反映的可能是几周甚至几小时前的代码状态。检索出来的函数可能上周就被重命名了，引用的模块可能上个迭代就删掉了。这种情况下检索出来的东西，其实已经过时了。

Claude Code走的是另一条路。它像一个真正的工程师，直接在文件系统里游走——读文件、用grep做精确定位、顺着代码引用一路跟下去。不需要构建索引，不需要上传代码库，永远面对活的、最新的代码。

但这条路也有权衡。Claude的导航能力，很大程度上取决于它一开始有没有"足够的上下文知道该去哪找"。如果你让它在十亿行代码里找一个模糊的模式，很可能还没开始干活，上下文窗口就已经耗光了。

所以那些真正做得好的团队，都在代码库的"可读性"上下了很大功夫。这就是后面要讲的harness配置体系——它的核心目的就是让代码库对AI更友好、更可导航。

三、决定表现的不只是模型：harness五层扩展点

这里有一个常见误解：很多人觉得Claude Code的能力完全取决于用的模型。但实际上不是这样。围绕模型搭建的整套生态，也就是harness（脚手架），才是决定它在实际项目里表现好坏的关键因素。

这套harness由五个扩展点组成，建设顺序很重要，因为每一层都建立在前一层之上：

1. CLAUDE.md：每次会话自动加载的上下文文件
2. Hooks：钩子，让系统持续进化的脚本
3. Skills：技能，通过渐进式披露按需加载专业知识
4. Plugins：插件，把skills、hooks、MCP配置打包成可安装整体
5. MCP Servers：让Claude连接内部工具、数据源和API

除了这五个扩展点，还有两个能力值得说：LSP集成（语言服务器协议，让Claude像IDE一样精确导航到符号定义、查找所有引用）和Subagents（子袋里，把"探索代码库"和"实际改代码"分开）。

下面逐层拆开讲。

四、第一层：CLAUDE.md文件

CLAUDE.md是每次会话启动时自动读取的上下文配置文件，构成整个harness的基石。

分层结构：根目录放全局信息（项目概览、架构约定、通用规范），子目录放局部约定（该模块的特殊规则、依赖说明、测试方式）。因为每次都会加载，内容一定要精炼，不然会拖累性能。

实战建议：

• 根目录CLAUDE.md控制在50行以内，只放最核心的架构约定和导航信息
• 子目录CLAUDE.md放该模块的"陷阱提示"——哪些代码不能动、哪些接口有特殊约束
• 写一个"代码库地图"列在根目录，说明每个顶层文件夹是做什么的，帮AI快速定位

常见坑：很多人把CLAUDE.md当文档写，洋洋洒洒几百行。结果每次会话光加载上下文就消耗大量Token，AI还抓不住重点。记住：CLAUDE.md是导航不是说明书。

五、第二层：Hooks钩子

很多人以为Hooks只是用来"防止Claude做错事"的脚本，但其实它更有价值的用法是让整套系统持续进化。

防错型Hook：比如PreToolUse hook拦截危险操作（删库、改生产配置），PostToolUse hook在每次文件修改后自动跑lint。

进化型Hook：这是更高级的用法。比如用一个stop hook在会话结束的时候反思刚才发生了什么，然后自动提出CLAUDE.md的更新建议。如果这次会话发现了某个模块的特殊约束没写在CLAUDE.md里，hook会提示你补上。这样配置文件就会随着使用越来越完善。

实战建议：

• 从防错型hook起步，先挡住"删库跑路"级别的风险
• 用一周之后加进化型hook，让配置自动迭代
• Hook脚本也要Code Review，别让hook本身变成新的故障源

Hooks的本质是：把团队的最佳实践固化成自动执行的规则，而不是靠人记着。

六、第三层：Skills技能

Skills的核心思想是通过渐进式披露来按需加载专业知识，避免每次会话都塞满用不上的内容。

按需加载机制：比如安全审查的技能只在做安全评估时才加载，文档处理的技能只在需要更新文档时才加载。Skills还可以绑定到特定路径，只在代码库的对应部分生效。

为什么需要Skills？如果把所有专业知识都塞进CLAUDE.md，上下文窗口会被撑爆，AI反而抓不住重点。Skills解决的是"专业知识什么时候该出现"的问题——不是全部预加载，而是用到时才调出来。

实战建议：

• 把高频通用知识放CLAUDE.md，低频专业知识放Skills
• Skill的描述要写清楚触发条件，让AI知道什么时候该调它
• 团队共享的Skill打包成Plugin（下一层），新人装上就能用

Skills的本质是：把知识从"全部常驻"变成"按需加载"，像按需导入模块而不是全局引入。

七、第四层：Plugins插件和第五层：MCP Servers

Plugins插件的作用是把skills、hooks、MCP配置打包成一个可安装的整体。这样做是为了解决一个问题："好的实践留在少数人手里传不出去"。

新人装上插件的第一天，就能拥有和老员工一样的上下文和能力。不需要老员工手把手教"这个项目要注意什么"，插件已经把这些知识固化下来了。

MCP Servers是让Claude能够连接到内部工具、数据源和API。比如连接到内部的日志系统、工单系统、监控平台，让AI不只能看代码，还能看运行时数据。

两层的关系：Plugin是分发载体，MCP是连接能力。Plugin里可以包含MCP配置，装一个Plugin就同时获得了知识（Skills）、规则（Hooks）和连接（MCP）。

实战建议：

• 先把团队最佳实践沉淀成Skill，再打包成Plugin分发
• MCP按需接入，别一开始就连一堆内部系统，上下文太杂反而干扰AI
• Plugin要有版本管理，配置更新时全团队同步升级

八、LSP集成和Subagents子袋里

除了五层扩展点，还有两个高级能力值得单独讲。

LSP集成（语言服务器协议）

有了LSP，Claude就能像在IDE里一样精确导航到符号定义、查找所有引用，而不是靠字符串模式匹配瞎猜。

为什么重要？在百万行代码库里，光靠grep找符号定义是不够的。一个叫process的函数可能有几十个同名匹配，grep分不清哪个是定义、哪个是调用。LSP能精确定位到符号的真实位置，还能找到所有引用点，这对跨文件重构至关重要。

Subagents（子袋里）

这个能力可以把"探索代码库"和"实际改代码"分开。你可以先用一个只读的子袋里去摸清一个子系统的情况，把它写成文件，然后再让主agent带着完整信息去动手改。

为什么这么设计？探索代码库会消耗大量上下文窗口（读几十个文件、跟着引用链跳转）。如果探索和修改在同一个会话里做，探索完之后上下文已经快满了，留给实际修改的空间不够。分成两个agent，探索结果固化成文件，主agent拿到的就是精炼后的信息，上下文利用率最高。

实战建议：

• LSP集成是标配，百万行级别代码库必开
• Subagents在做大规模重构时用，小改动不需要
• 子袋里的探索结果要存成文件，方便复用和Code Review

九、三个反复出现的配置模式

Anthropic结合多个成功部署的案例，总结出三类反复出现的模式。

模式一：让代码库在规模化下依然可导航

• 把CLAUDE.md文件写得精简分层
• 不在仓库根目录启动，而是切到具体子目录再启动。Claude会沿目录树向上遍历，把路径上的CLAUDE.md全部读进来，全局信息不会丢
• 按子目录限定测试和lint命令范围，避免改了一个服务就跑全量测试导致超时
• 用.ignore文件排除生成文件和第三方代码
• 对于目录结构本身不够清晰的代码库，在根目录写一个"代码库地图"，列出每个顶层文件夹是做什么的

模式二：随着模型能力进化，主动维护CLAUDE.md

你针对旧模型的局限性写的规则，换了新模型之后可能反而变成束缚。比如"每次重构都必须拆成单文件改动"这种规则，可能是为了让老模型别跑偏，但新模型完全有能力做跨文件的协调修改。

建议每三到六个月做一次配置复盘，或者在模型大版本更新后专门检查一次。把不再需要的旧规则删掉，给新模型更大的发挥空间。

模式三：明确谁来负责Claude Code的管理和推广

那些推广最快的团队，通常在大规模放开使用之前，就先安排一个小团队（有时甚至只有一个人）把工具链搭好。这样做的目的是让员工第一次用的时候就是顺畅的体验，而不是从零开始摸索。

有些组织里出现了一个新角色叫"agent manager"，介于产品经理和工程师之间，专门负责维护整套Claude Code生态。如果没有专门的团队，至少也要有一个DRI（唯一责任人），对配置、权限策略、插件市场、CLAUDE.md规范拥有决策权和维护责任。

十、从架构师视角看Claude Code的规模化落地

前面讲的五层扩展点和三个配置模式是Anthropic官方总结的最佳实践。但真到了落地阶段，架构师要面对的不是"要不要上全套配置"，而是"上到什么程度、先上哪几层"。

取舍一：配置投入 vs 团队规模

完整的harness五层体系（CLAUDE.md + Hooks + Skills + Plugins + MCP）需要专人维护，适合50人以上的工程团队。10人以内的团队，CLAUDE.md + 基础Hooks就够用，上Skills和Plugins的维护成本反而大于收益。判断准则：代码库超过50万行、或团队跨3个以上子团队，才值得投入完整harness建设。

取舍二：RAG vs 文件系统导航的混合策略

Claude Code走文件系统导航路线，但不代表RAG完全没用。混合策略在大代码库里更实际：用RAG做"初筛"（快速定位到相关模块），用文件系统导航做"精读"（在模块内做精确修改）。纯文件系统导航在十亿行代码里会耗光上下文，纯RAG又有过时问题，两者配合能取长补短。

取舍三：Subagents的使用门槛

Subagents把探索和修改分开，听起来很美好，但实际使用有门槛：子袋里的探索结果质量取决于prompt设计，prompt不好探索结果就是垃圾。建议起步阶段先手动做探索（自己读代码、写摘要给主agent），跑顺了再自动化成Subagents。别一上来就追求全自动，容易翻车。

取舍四：配置复盘的节奏

官方建议三到六个月复盘一次，但实际节奏要看模型迭代速度。如果用的是快速迭代的模型（每月都有新版本），建议每月做一次轻量复盘（只看CLAUDE.md有没有过时规则），每季度做一次深度复盘（全面检查五层配置）。复盘的核心问题是：哪些规则是给旧模型加的限制，新模型已经不需要了？

取舍五：agent manager角色的必要性

不是所有团队都需要专职agent manager。判断准则：如果Claude Code的使用者超过20人、或配置文件（CLAUDE.md + Skills + Hooks）超过10个，就需要一个DRI。否则兼职维护就行，但要有明确的"出问题找谁"的责任人。

这五个取舍点的共同特征是：没有标准答案，只有适合当前团队规模和代码库阶段的方案。架构师的价值不是把官方最佳实践全搬过来，而是判断当前场景需要哪几层、能省掉哪几层。

十一、给一线开发者的Claude Code配置清单

理论讲完了，落到具体执行层面，给正在用或准备用Claude Code的开发者几条可以这周就开始落地的建议。

1. 先写CLAUDE.md，别裸跑

很多人装完Claude Code就直接开始用，什么配置都不写。在几千行的小项目里勉强行，到了几万行以上就会明显感觉AI"找不到北"。第一步永远是写CLAUDE.md：项目用什么语言、什么框架、目录结构是什么、测试怎么跑、有哪些不能动的代码。哪怕只写20行，也比裸跑强十倍。

2. 从子目录启动，别从根目录启动

在大型monorepo里，从根目录启动意味着Claude要面对整个代码库。在具体的子目录里启动，Claude会自动向上遍历加载沿途的CLAUDE.md，既不丢失全局信息，又能聚焦到当前模块。这个习惯从第一天就该养成。

3. 测试命令按子目录限定

改了一个微服务就跑全量测试，CI超时黄花菜都凉了。在CLAUDE.md里写清楚每个子目录的测试命令范围，让Claude改完代码只跑相关测试。这一步零成本，但能省掉大量等待时间。

4. Hooks从防错起步，再上进化型

先加一个PreToolUse hook拦截rm -rf和生产环境配置修改，挡住"删库跑路"级别的风险。用一周之后再加stop hook做配置自动建议。别一上来就搞复杂的进化型hook，先跑稳防错型。

5. Skills按需加，别一次堆太多

先识别出团队最常重复的工作（比如代码审查、文档生成、安全扫描），把这些沉淀成Skill。一次加一个Skill，跑两周确认有效果再加下一个。一次堆十个Skill会让AI无所适从，不知道什么时候该调哪个。

6. 指定一个DRI，哪怕是你自己

配置文件没人维护就会腐烂。哪怕团队只有3个人，也要明确"CLAUDE.md归谁管、Hooks归谁管"。没有责任人的配置体系，活不过三个月。

这六条建议的共同思路是：配置建设是渐进式的，不是一次性工程。先写CLAUDE.md、先从子目录启动、先加防错hook，跑稳了再演进到完整harness。别被"五层扩展点"绑架，适合当前阶段的配置才是好配置。

总结

回过头来看这个面试问题，其实还挺公平。它问的根本不是"你会不会用Claude Code"，而是"你有没有在规模化场景下思考过工具怎么落地"。

核心信息很朴素：Claude Code在大型项目里的表现，靠的是"配置调出来"的，不是模型自带的。模型能力是底座，但真正决定体验上限的，是团队愿不愿意花时间搭CLAUDE.md、Hooks、Skills、Plugins这套体系，有没有专人持续维护。

回到主线，整条逻辑就三句话：模型是引擎、harness是底盘、配置是调校。

• 模型是引擎：决定能力上限，但不决定实际表现
• harness是底盘：五层扩展点把模型能力转化为实际生产力
• 配置是调校：根据代码库规模和团队阶段，调整配置投入程度

如果再回答一次这个问题，大概会说：几万行的小模块和几百万行的大仓库，差距不在模型能不能读懂代码，而在你有没有把CLAUDE.md分层写好、有没有用LSP做符号级导航、测试命令有没有按子目录拆开、团队里有没有专人维护这套配置。

这大概就是"用过工具"和"理解工具怎么在规模化场景下落地"之间的差距。以后再被问到类似的问题，希望能多讲出点东西来。