面试官皱眉：-Claude Code 你用了半年，CLAUDE.md 多少行了？-我说两千多，他：那今天就到这吧
公众号名称：吴师兄学大模型
作者名称：吴师兄
发布时间：2026-06-19 10:02
大家好，我是吴师兄。
之前 写过几篇 Claude Code 的机制：SKILL.md 怎么按需加载、它怎么记住一个大代码库。
今天接着往下，讲一个我自己踩了坑才想明白的事，CLAUDE.md 到底该怎么维护。
上周有个学员去面大模型工程岗，简历上写”熟练使用 Claude Code 半年，深度定制工作流”。面试官来了兴趣，问了句看着很随意的话：
“Claude Code 用了半年，你的 CLAUDE.md 现在多少行了？”
“两千多行吧，“他答得挺顺，“项目约定、代码规范、踩过的坑，想到什么往里加。”
面试官没夸他勤快，问了一句：“那这两千行，模型每一轮对话都得从头重读一遍？”
他愣住了，这笔账他从没算过。
面试官接着说：“CLAUDE.md 每次会话自动加载进上下文，你写多少，模型每轮就读多少。两千行两万多 token，一次会话来回几十轮，光重读这一个文件就是几十万 token。更糟的是，真正高频用到的可能就二三十行，剩下全是噪声，把那二三十行也淹了。”
又追一层：“哪些该进 CLAUDE.md，哪些该做成 skill？项目从 A 切到 B，你怎么保证 A 的约定不串到 B 上？”
他没接上。他一直把 CLAUDE.md 当”备忘录”，以为写得越全越好，从没想过它有成本，更没想过要分层、要精简、要隔离。
后来找我复盘，他说这道题点醒他一件事：CLAUDE.md 不是写出来的，是维护出来的。今天就把这套维护方法讲透。
一、CLAUDE.md 不是越全越好，它是每轮都要付的”常驻成本”
先把最关键的一个认知摆正：CLAUDE.md 里的每一行，都是要在每一轮对话里重复付费的。
很多人把 CLAUDE.md 当成一个”知识库”，觉得写得越全，模型越懂我的项目。这个直觉在 RAG 那套按需检索的世界里成立，但在 Claude Code 这里正好反过来。CLAUDE.md 是会话启动时就自动注入上下文的，它不是按需读取，是常驻。你写两千行，模型这一轮读两千行，下一轮还读两千行，每一轮都从头读。
这跟 skill 是两套完全不同的加载逻辑。skill（SKILL.md）走的是渐进式按需加载：默认只把名字和一句话描述放进上下文，模型判断这次任务用得上，才把完整内容读进来。一个不常用的复杂流程放进 skill，不用的时候它几乎不占上下文；同样的内容塞进 CLAUDE.md，哪怕一个月用不上一次，也得每轮陪读。
所以”两千行 CLAUDE.md”真正的代价有两层。
第一层是 token。两千行中文加代码，一行平均十几个 token，整份大概两万多，一次正经的开发会话来回三四十轮很正常，光是重复读这一个文件就能滚到七八十万 token。这是实打实的钱和延迟。
第二层更隐蔽，是注意力被稀释。这才是大头。模型的注意力是有限的，你把二三十条真正高频的硬约束，和一千多行”某次调试随手记的临时笔记”混在一起，那二三十条就被埋了。
我自己就栽过一个很典型的 case。有个数据迁移项目，我在 CLAUDE.md 里写过一条很重要的约定：“任何迁移脚本执行前必须先 dump 一份备份”。但这条当时是随手加的，落在文件第 1500 行附近，前后全是些零碎的环境配置。结果连着三四次，模型生成迁移脚本时都直接跳过了备份这一步。我一开始以为是模型不靠谱，后来才反应过来，不是它没读到，是这条被一千多行噪声淹了，权重根本提不起来。我把这条拎出来，放到文件最前面的”硬约束”区，单独一段，立刻就守住了。同一个模型、同一句话，只是换了个位置。
这件事让我彻底改了对 CLAUDE.md 的态度：它不是越全越好，是越精准越好。写进去的每一行都得对得起它每轮的占用。
这里我得说句可能得罪人的话，有个流行做法我一直不认同：网上很多教程让你跑个 /init 自动生成一份大而全的 CLAUDE.md 就完事。我正相反。/init 生成的初稿，我拿到手第一件事是删，删到只剩每轮都真用得上的那几条。生成容易，维护难，自动生成的那份恰恰是最不该原样留着的。
CLAUDE.md 常驻加载 vs Skill 按需加载
CLAUDE.md 常驻加载 vs Skill 按需加载
二、什么才该进 CLAUDE.md：高频、稳定、跨会话
既然每行都要付费，判断标准就清楚了。一条信息该不该进 CLAUDE.md，看三个条件，三个都满足才进：
高频。 这条信息是不是几乎每次会话都会用到。比如项目的构建命令、测试怎么跑、代码风格约定，这些基本每次都碰得到，进。一个季度才用一次的发布流程，不进。
稳定。 这条信息是不是长期不变。项目的目录结构约定、技术栈选型，半年都不会动，进。当前正在调的某个 bug、这周的临时分支策略，下周就过时了，不进，写进去就是给未来的自己埋雷。
跨会话。 这条信息是不是换个会话还需要。架构上的”反直觉陷阱”，比如”这个服务看着是无状态的，其实依赖一个全局缓存，改它要小心”，这种每个新会话都得知道，进。某次对话里临时确定的一个参数，这次说清楚就行，不进。
三个条件像一个漏斗，能同时穿过的东西其实不多。我自己维护的项目级 CLAUDE.md，绝大多数控制在一百行出头，再多就要警惕了。
那些没穿过漏斗的，分别有自己的去处：
| 信息类型 | 特征 | 该放哪 |
|---|---|---|
| 构建/测试命令、代码规范、架构陷阱 | 高频、稳定、跨会话 | CLAUDE.md |
| 复杂但不常用的专项流程（如发布、压测、数据回滚） | 低频、稳定、自成一套 | 做成 skill，按需加载 |
| 一次性任务的上下文、临时参数 | 用完即弃 | 当前对话里说清楚，不落盘 |
| 大段参考文档、API 全量清单 | 体量大、偶尔查 | 单独文件，用 @路径 按需引入 |
重点说一下 CLAUDE.md 和 skill 的分界，这也是面试官最爱追的。判断很简单，就一句话：这套东西是不是每次都要、是不是稳定。 每次都要又稳定的，进 CLAUDE.md；偶尔才要、但要的时候是一整套动作的，做成 skill。一个典型例子：日常的代码风格约定进 CLAUDE.md，因为每次写代码都用得上；而”线上数据库回滚的完整 checklist”做成 skill，因为它一个月用不上一次，但真用的时候是十几步的严谨流程，平时让它每轮陪读纯属浪费。
还有个边界也得提一句：如果你只是临时跑个一次性脚本，根本不会有第二次会话，那连 CLAUDE.md 都不用建。 直接在对话里把要求说清楚就行，为一次性的活儿去维护一份常驻文件，是给自己加负担。CLAUDE.md 的价值建立在”重复”上，没有重复，它就是纯成本。
三、分层维护：项目级、全局级、skill 级各管一段
想明白了”什么该进”，下一个问题是”进哪一层”。CLAUDE.md 不是一个文件，是一套分层的体系，放错层会出两种问题：要么该共享的没共享，要么该隔离的串了味。
全局级，～/.claude/CLAUDE.md。 这是你个人的、跨所有项目的偏好。比如”回答用中文""提交信息别写废话""默认用 pytest 不用 unittest”。它只在你这台机器上生效，不进任何项目的 git。放这层的判断标准是：这条偏好换个项目还成立吗？成立，就该上提到全局，别在每个项目的 CLAUDE.md 里抄一遍。
项目级，项目根目录的 ./CLAUDE.md。 这是这个项目特有的、要跟团队共享的约定。它进 git，团队每个人拉下来都生效。构建命令、目录约定、这个项目特有的架构陷阱，放这层。判断标准反过来：这条只对这个项目成立、且队友也需要知道吗？是，就放项目级并提交。
skill 级，SKILL.md。 前面说的那些低频但成套的专项流程，放这层，按需加载，不占常驻上下文。
这三层之外还有两个常用的补充手段。一个是子目录 CLAUDE.md：大仓库里某个子模块有自己特殊的约定，可以在那个子目录单独放一份，只有在那个子树里干活时才加载，不污染主上下文。另一个是 @路径 引入：CLAUDE.md 里可以用 @docs/architecture.md 这种写法把外部文件按需带进来，既保持主文件干净，又能在需要时引用大块内容。
分层的核心好处是各管各的、互不串味。我见过最常见的错误，是把个人偏好（“我喜欢用 tab 缩进”）写进了项目级 CLAUDE.md 提交上去，结果全组的 Claude Code 行为都被你一个人的习惯带跑了。这种就是典型的放错层。
CLAUDE.md 的三层维护结构
CLAUDE.md 的三层维护结构
四、定期精简：什么信号说明它该瘦身了
CLAUDE.md 会膨胀，这是必然的，因为往里加东西的动作很轻，删东西却需要判断。所以得有意识地定期精简。下面几个信号一出现，就说明该动手了。
信号一，行数越界。 项目级 CLAUDE.md 超过两三百行，先别急着加新的，回头看看有没有过时的。我的经验阈值是项目级一百多行、全局级几十行，超了就该警惕。
信号二，模型反复忽略某条指令。 这是个特别强的信号，前面那个备份的 case 就是。如果你发现某条明明写了的约定，模型老是不遵守，先别怪模型，大概率是它被埋太深了。要么把它提到最前面的硬约束区，要么说明它已经不重要了可以删。
信号三，出现”上次那个 bug""临时先这样”这类字眼。 这些都是会过时的临时信息，混进了常驻文件。定期搜一遍这类词，基本都能清掉一批。
信号四，同一件事写了两遍。 文件长了就容易重复表达，重复的内容不光占地方，还可能前后矛盾，让模型无所适从。
精简的手法也简单：高频硬约束往顶部提，单独成段、显眼；低频成套的流程下沉成 skill；过时的、临时的直接删；大段文档挪出去用 @ 引。精简不是一次性的活，我大概每两三周会扫一遍主力项目的 CLAUDE.md，每次都能删掉三五十行，删完模型的表现反而更稳。
想到啥加啥的臃肿版 vs 分层精简版
想到啥加啥的臃肿版 vs 分层精简版
五、和 git worktree 配合：项目切换时怎么隔离上下文
最后讲面试官追的那个隔离问题：项目或任务一切换，怎么保证上下文不串味。
CLAUDE.md 是跟着目录走的，这一点正好可以利用 git worktree 来做隔离。worktree 能让同一个仓库的不同分支，签出到不同的物理目录，每个目录是独立的工作区。你在 worktree A 里干活，加载的就是 A 目录那套 CLAUDE.md 加上下文；切到 worktree B，是另一套。两个并行的任务，各自带各自的约定和临时状态，互不污染。
这套配合在两个场景下特别实用。
一个是并行开发。你同时推进两个特性，一个在主 worktree，一个在新建的 worktree。两边可能有不同的临时约定（比如 B 这个特性要临时关掉某个校验），这些临时信息可以写进各自 worktree 的本地 CLAUDE.md，不会互相干扰，特性合并完，连同那份临时上下文一起清掉就行。
另一个是风险隔离。要做一个大改动、心里没底，开个独立 worktree 去试，所有探索性的、可能很乱的上下文都圈在那个目录里，把握不准就整个删掉，主工作区一点不受影响。
这里也得讲代价，别把 worktree 用成万能药。每个 worktree 是一份完整的工作目录签出，磁盘和心智都有成本，开太多自己都管不过来。它适合”短期、并行、要隔离”的任务，不适合拿来当长期分支管理。真正长期的项目级约定，还是该老老实实沉淀进提交进 git 的那份项目级 CLAUDE.md，而不是散在一堆临时 worktree 里。
面试怎么答 CLAUDE.md 维护这道题
面试官问”你怎么维护 CLAUDE.md”，最差的答法是”想到什么加什么”。这等于告诉对方你没意识到它有成本。按下面四步答，能显出你是真维护过。
先点出成本本质（20 秒）： “CLAUDE.md 是每次会话自动注入上下文的，写多少模型每轮就读多少。它不是越全越好，越全反而越稀释注意力，把真正高频的约定淹掉。所以核心不是写，是维护和精简。”
再讲准入标准（30 秒）： “我用三个条件筛：高频、稳定、跨会话，三个都满足才进 CLAUDE.md。低频但成套的专项流程做成 skill 按需加载；一次性的临时信息就在对话里说，不落盘；大段文档用 @ 路径按需引入。”
然后讲分层（30 秒）： “分三层。个人跨项目的偏好放全局 ～/.claude/CLAUDE.md；项目特有、要跟团队共享的约定放项目级 ./CLAUDE.md 并提交 git；低频专项流程做成 skill。放错层是常见坑，比如把个人缩进习惯写进项目级提交上去，把全组带跑。”
最后讲隔离（20 秒）： “项目或任务切换用 git worktree 做隔离，CLAUDE.md 跟着目录走，每个 worktree 各带各的上下文，并行开发和高风险探索都不会串味。但 worktree 有磁盘和心智成本，只适合短期并行隔离，长期约定还是沉淀进项目级 CLAUDE.md。”
能把”成本、准入、分层、隔离”这四层讲全，面试官就知道你不是只会跑 /init，是真把它当一个要持续治理的东西在用。
写在最后
CLAUDE.md 这东西，门槛低到几乎没有，建个文件往里写就行。也正因为门槛低，绝大多数人都停在”想到啥加啥”这一层，攒出一个两千行、每轮陪读、还把重点淹了的大文件。
真正的功夫不在写，在持续地删和分层。判断每一行配不配每轮的占用，把高频稳定的留在 CLAUDE.md，把低频成套的沉进 skill，把临时的挡在对话里，再用 worktree 把并行任务隔开。这套东西做下来，你的 Claude Code 才是越用越顺，而不是越用越钝。
今天这道题，只是 Claude Code 工程化的一个切面。真正备面的时候，光看懂一篇不够，你得自己维护过一份会膨胀的 CLAUDE.md，亲手删过、分过层，还得见过同一个点被面试官从不同角度追问的样子。Claude Code 这块的关联面试题，我按公司和难度分好放在了官网题库，地址是 www.wushixiongai.com。
我是吴师兄，我们下篇文章见。
往期推荐
滴滴面试官追问：“Claude Code 自动帮你记了什么？你翻过 MEMORY.md 文件吗？“我打开一看，里面存的全是废话
面试官说：“有 Claude Code 就够了，要什么记忆系统？“我问他 CLAUDE.md 放了什么，他答不上来
字节面试官追问：“你用 Claude Code 搭的 Deep Research，跑到第18步还记得第3步查的数吗？“我说窗口开大点，他冷笑：算过 token 账吗
内容效果不满意？点此反馈