前几天去面试，三面被问到一个问题："百万行规模的代码库里，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 由五个扩展点组成，建设顺序很重要，因为每一层都建立在前一层之上：
- CLAUDE.md：每次会话自动加载的上下文文件
- Hooks：钩子，让系统持续进化的脚本
- Skills：技能，通过渐进式披露按需加载专业知识
- Plugins：插件，把 skills、hooks、MCP 配置打包成可安装整体
- 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 做符号级导航、测试命令有没有按子目录拆开、团队里有没有专人维护这套配置。
这大概就是"用过工具"和"理解工具怎么在规模化场景下落地"之间的差距。以后再被问到类似的问题，希望能多讲出点东西来。
你在面试里还被问过哪些看着简单但实际上很深的 AI 编程工具相关问题？欢迎评论区交流踩过的坑。