企业官网建设流程全解析

1. 一锅炖的失控：CLAUDE.md 从助手变成麻烦制造者的全过程

我最初接触 CLAUDE.md 的时候，想法很简单：把所有想让 AI 编程助手知道的事情都写进去。项目背景写进去，技术栈写进去，编码规范写进去，测试要求写进去，Git 提交规范写进去，甚至连"遇到问题时不要乱改 API"这种碎碎念也往里面堆。当时觉得，文件里面内容越全，模型就越了解项目，表现自然越好。这个想法在文件只有几十行的时候确实成立，但随着项目推进，文件很快就膨胀到了 600 多行，问题开始接二连三地出现。

这 600 多行大概是这样一个状态：最上面是项目简介，紧接着是"通用原则"，写了大概三十来条，然后突然跳到 Docker 命令速查表，又突然切到代码评审清单，再往后是各种历史遗留的临时决定——"2024 年 3 月之后前端不再使用某个旧组件库"这样的废弃信息还堂而皇之地躺在正文中间。看起来信息量很大，实际上已经变成了一个什么都没有说清楚的信息垃圾场。

1.1 一锅炖文件长什么样

我在某开源项目里第一次意识到问题严重性，是在跑一个看似简单的需求时，模型连续三次给出了完全不同的实现方案。第一次它按照文件开头写的"优先使用组合式 API"去写代码，第二次它把组件拆成了十几个细碎的文件，理由是文件中间某条"保持函数小而独立"的规则，第三次它干脆忽略了我要求的测试覆盖范围，只补了一个冒烟测试。同一个任务、同一个仓库、同一个配置，模型像精神分裂一样反复横跳。

把当时那个 CLAUDE.md 打开细看，问题其实一目了然。整份文件的结构大概是这样的：

# 项目说明 - 项目是一个前后端分离的内容平台 - 后端使用 Python 构建 - 前端使用现代组件化框架 # 通用原则 - 所有代码必须通过 lint 检查 - 提交信息必须以类型开头 - 优先编写可复用组件 - 不要随意引入新依赖 - 后端接口必须带版本前缀 - 样式优先使用设计系统变量 - ...还有三十多条类似条目 # 代码评审清单 - 检查是否有遗留调试日志 - 检查是否有未处理的异常 - 检查是否有明显的性能问题 - ... # Docker 命令备忘 - 构建镜像命令是 xxx - 进入容器命令是 xxx - 查看日志命令是 xxx - ...

这还只是前面两百行的部分。后面又有代码风格指南、数据库迁移流程、特定页面模块的维护注意事项、三四个已经过期的架构决定，以及某一次联调时临时加的"禁止直接修改某个第三方配置"这种一次性约束。整份文件里，哪些是长期有效的，哪些是临时补丁，哪些早已作废，根本区分不出来。

1.2 一锅炖带来的三个连锁反应

第一个连锁反应是模型对长上下文的注意力衰减。AI 编程助手在接收上下文时，对文件开头和结尾内容的记忆往往比中间段落更清晰，准确说是对开头的内容印象更深、对中间部分容易一带而过。当一份 CLAUDE.md 超过几百行后，大量规则堆在中间位置，尤其是我最在乎的那些测试要求和架构约束，模型经常视而不见。文件写得越长，处在"注意力洼地"里的条目就越多。

第二个连锁反应是规则互相冲突。因为文件是线性生长的，早期写的"组件应该尽量小"和后期的"页面级组件可以包含子组件"这种上下文依赖型规则根本没有分层，模型拿到的是相互矛盾的指令集。更麻烦的是，人很难发现 600 行的文件里哪句话和哪句话打架，模型更不会主动去排查规则冲突，它只会随机选一条去执行，表现出来的就是每次生成结果都不一样。

第三个连锁反应是维护成本爆炸。改一行旧规则怕影响其他部分，加一条新规则又不知道塞在哪里合适。到最后整个文件已经变成了一个"谁都不敢动"的大泥潭，每次更新要么在末尾追加，要么在开头插入，文件的可读性进一步恶化。某次我尝试整理一遍，刚删掉一条看起来过时的依赖说明，转头发现后面还有个脚本流程引用了它，直接被带偏了方向。

这段经历让我意识到，CLAUDE.md 出现问题的根源，不是内容写得不够多、不够细，而是组织结构完全跟不上信息的增长。就像一个抽屉里塞满了螺丝、证件、账单和旧照片，每次找东西都要翻个底朝天，真正的问题不是东西太多，而是从来没有分类过。

2. 分层治理想解决什么：把 CLAUDE.md 当作可演进的文档系统来设计

既然问题出在结构上，自然就想到重构。但我一开始也没想清楚要改成什么样子，只是隐约感觉 CLAUDE.md 不应该是一份"大而全"的文件，而应该是一个"小而稳"的入口，后面跟着一套结构清晰的文档体系。这个思路其实借鉴了软件工程里经典的分层思想。

2.1 软件分层架构给了什么启发

做过服务端开发的人都熟悉表现层、业务逻辑层、数据访问层这套划分方式。每一层有自己的职责，层与层之间有明确的调用方向，改动某一层内部实现时尽量不影响其他层。当时我就想，CLAUDE.md 的治理思路完全可以类比过来：把"模型每次会话都应该知道的稳定内容"当作底层基座，把"特定场景下才需要执行的工作流"当作中间层，把"Docker 命令、测试策略这类操作性细节"当作工具层，把"当前进度、最近决策这一秒都在变的信息"当作状态层。每一层独立维护，主文件只做路由和索引。

这个思路的核心变化是：不再让模型一次性读完整个配置，而是让它在不同阶段按需读取对应模块。并且分层之后，每条规则都有明确归属，规则之间的冲突可以通过"上层覆盖下层、场景规则覆盖通用规则"的优先级关系来解决，而不是靠物理位置的前后顺序决定谁说了算。

2.2 分层治理的两条核心原则

实际设计时，我给自己定了两条非常朴素的原则。

第一条是稳定性从高到低排序。永远不变化的信息往底层放，比如项目身份、技术栈、全局架构约束；经常变化的信息往高层放，比如当前迭代的进度、本阶段要重点关注的模块；中等变化频率的信息放中间，比如工作流定义、操作手册。越稳定的东西越应该被每一个会话看到，越易变的东西越应该从主文件中摘出去。

第二条是全局约束和场景约束分开管理。全局约束是对所有任务、所有模块都生效的底线，比如"不允许在代码中留下调试输出""提交信息必须格式化"，这些留在主文件；场景约束是针对特定任务类型的规则，比如"当你在修改数据库迁移脚本时需要做的检查项"，这些下沉到对应的工作流文件中，平时不占上下文，等真正进入那个场景再加载。

有意思的是，这条原则想通之后，过去很多"不知道该不该写进配置"的犹豫都消失了。判据很简单：如果这条信息只在特定情况下需要，就不值得占用每次会话的上下文预算；如果这条信息是底线级别的，就必须保证模型进来第一眼就能看到。

2.3 明确一个常见误解

分层治理不是要让模型"自己去找资料"。在动手之前，我担心过一个很现实的问题：如果把大量内容从主文件挪到子文件里，模型会不会干脆不读了？后来想明白了，分层治理的正确打开方式是：主文件保留路由表，然后在工作流文件的特定步骤里显式声明"这一步需要加载哪份手册"。也就是说，不是把文件拆散了丢给模型，而是把原来一锅炖的隐式加载，改成通过工作流定义的显式加载。模型不需要自己猜测该不该读某个文件，它只要按流程走，走到的节点自然会告诉它下一步该读什么。

这个理解很关键，它决定了后面整个重构方案的具体形态。

3. 重构方案落地：四层五类的目录结构与职责边界

敲定思路之后，我开始设计具体的目录结构。当时的目标是：任何人（包括三个月后的自己）打开仓库，扫一眼目录就能知道每个文件是干什么的、什么时候会被用到、该不该去动它。同时也给自己定了一条规矩——CLAUDE.md 入口文件本身永远不要超过 80 行，一旦有内容想往里面塞，先问问它属于下面哪一层。

最终落地的结构大致是这样：

project-root/ ├── CLAUDE.md └── guides/ ├── principles.md ├── workflows/ │ ├── feature-development.md │ ├── debugging.md │ ├── code-review.md │ └── release-process.md ├── handbooks/ │ ├── test-strategies.md │ ├── docker-commands.md │ ├── git-rules.md │ └── dependency-management.md └── state/ ├── current-context.md └── decision-log.md

下面逐个说明每一层的定位和边界。

3.1 入口主文件：只做身份、原则与路由

重构后的 CLAUDE.md 不再承载任何操作细节，只保留四类东西：项目身份说明、全局底线原则、文件路由索引、加载协议。它的任务不是告诉模型"Docker 构建命令是什么"，而是告诉模型"仓库里有哪些 guide 文件，分别在什么场景下读取"。

我重构后的主文件大概长这样：

# 项目身份 - 项目定位：面向内容创作者的内容管理与发布平台 - 技术栈：前后端分离，后端 Python，前端组件化框架 - 核心架构约束：所有外部访问必须经过网关层 # 全局原则 - 提交信息必须使用规范前缀 - 禁止在代码中遗留调试输出 - 所有后端接口必须有版本前缀 - 新依赖必须经过充分评估 # 文件路由 - guides/principles.md：所有场景的通用细则，会话开始后全部读取 - guides/workflows/feature-development.md：开发新功能时读取 - guides/workflows/debugging.md：排查线上问题时读取 - guides/workflows/code-review.md：执行代码评审时读取 - guides/workflows/release-process.md：准备发布版本时读取 - guides/handbooks/test-strategies.md：编写或修改测试时读取 - guides/handbooks/docker-commands.md：涉及容器操作时读取 - guides/handbooks/git-rules.md：涉及分支与合并时读取 - guides/handbooks/dependency-management.md：涉及依赖变更时读取 - guides/state/current-context.md：每次会话开始时读取 - guides/state/decision-log.md：需要确认历史决策时读取 # 加载协议 - 每次会话开始：读取 CLAUDE.md 与 state/current-context.md - 触发对应场景：读取对应 workflows 文件 - 工作流步骤涉及具体操作：按步骤指示读取对应 handbooks 文件

主文件里每一行都是"索引"级别的内容，没有大段解释、没有历史包袱、没有临时加油站。模型每次进入项目，先看到这份干净的入口，再按路由表去决定要不要继续读别的文件。光这一步，上下文负担就比原来少了一大截。

3.2 原则层：稳定性最高的配置底座

guides/principles.md我把它理解为"全局细则库"，和主文件中高度浓缩的全局原则区分开。主文件只写那些无论如何都必须遵守的底线，细则库里则放需要补充说明的编码风格细则、命名约定、组件设计规范、接口设计约定等内容。这些说法听起来和主文件很接近，但要区分也很简单：如果一条规则在某次会话中不读也不影响大局，它就应该放在细则库里，而不是主文件中。

我给自己定的标准是"七个字：全局、稳定、低变更"。任何有可能在某次迭代中因为业务需要而被打破的临时规则，都不应该放进这一层。这一层是那个"很少有人打开，但一打开就能获得权威答案"的底座。

3.3 工作流层：按场景触发的过程契约

工作流文件是这次重构中收益最大、也最能体现"分层治理"价值的部分。我没有按照技术模块去组织，而是按照真实工作中反复出现的"任务类型"去拆：新功能开发、问题排查、代码评审、发布流程。每个文件都描述这个场景下的完整步骤链条，并在步骤里明确指向对应的操作手册。

比如feature-development.md里会写：

# 新功能开发工作流 1. 明确需求边界 - 阅读 demand 描述，列出验收标准 - 如果需求说明模糊，先向项目维护者确认，不要自行假设 2. 设计改动方案 - 读取 guides/handbooks/architecture-notes.md - 列出受影响模块，标注接口变化 3. 编码实现 - 遵守 guides/handbooks/test-strategies.md - 新功能必须配套至少一层核心测试 4. 本地验证 - 运行 lint 与测试命令 - 确认无调试残留 5. 提交代码 - 按 git-rules.md 的提交规范提交

整个工作流文件的核心特征是：每个步骤都有明确的输入和输出，模型在那个环节不需要自己脑补流程，只要顺着步骤走，按需打开对应的手册文件。这种写法把过去散落在 600 行里的隐性要求，重新组织成了一条一条有先后顺序的显式指令。

3.4 操作手册层：随时查阅但不常驻上下文的工具书

操作手册层就是原来的"命令速查表""测试要求""Git 协作细则"这些内容的去处。它们的特点是：稳定、低频、每次用到时又特别需要精确信息。把它们放在工作流文件通过步骤索引去引用，效果比全部塞进主文件好得多。

举个例子，test-strategies.md里记录了项目不同模块的测试策略：单元测试覆盖哪些目录、集成测试用什么框架、哪些场景必须写快照测试。这些内容如果放在主文件里，每次会话都会白白占用模型的注意力；放在手册层之后，只有进入"编写或修改测试"这个场景时才会被加载，而每次加载时信息都是完整而不过期的。

3.5 状态层：记录正在变化的信息

最后一块是state/目录。最开始我忽略了它，想把"当前迭代进度""近期架构决定"这些内容塞进主文件，结果发现动态内容会不断污染静态规则。后来专门拆出了current-context.md和decision-log.md。

current-context.md的作用是告诉模型"这个项目现在处于什么阶段，最近做了哪些关键改动，当前迭代关注什么模块"。它每次会话都读，但内容一周一更，不涉及任何永久规则。decision-log.md则是重要的架构决策变更记录，记录"为什么当初选择了某个方案"，防止模型在后续任务中提出反向的重构建议。

这五层之间并没有严格的上下级关系，更像是一个吹风机：主文件是开关，工作流是档位，操作手册是配件，状态层是当前温度显示。模型不需要同时捧着全部内容干活，它只需要知道当前档位该用什么配件。

4. 迁移实录：从拆分、改写到验证的完整过程

目录结构设计好了，真正动起手来还要一步步来。这一节我把迁移过程中实际走的路整理成一套可复现的流程，尤其是那些容易忽略的细节，参考价值比最终结果本身更大。

4.1 给旧文件做一次"体检和分诊"

我没有直接提刀拆文件，而是先把原来 600 多行 CLAUDE.md 从头到尾读了一遍，每一条都记录到一张临时清单里。记录项包括：这条内容现在还有效吗？它属于哪一层？它是全局规则还是场景规则？和别的条款有没有冲突？做完之后，我得到了一张混乱程度惊人的表格。

清扫出来的结果比预想的多：真正需要保留的原始条目大概只有原来的一半，剩下的一半要么和别的条目重复，要么已经过期，要么根本不属于配置层面应该管的事情。这一步做完，我才意识到原来的"大而全"假象有多严重——文件里很大一部分内容，模型读了其实是在帮倒忙。

4.2 拆分顺序与关键改写技巧

分诊之后，我没有从最复杂的开始拆，而是先拆最容易的那部分，因为容易拆的内容往往也是边界清晰的稳定内容，可以快速建立新的目录骨架。

拆的顺序是这样的：先处理操作手册层，把命令速查表、Git 规范、测试策略这些内容原样搬过去；然后拆工作流层，把原来分散在文件各处的任务说明整理成完整流程；最后才精简主文件，把全局原则和路由表放进新的入口文件。为什么不先拆主文件？因为主文件在整个结构中是"总开关"，它的设计需要等子文件内容稳定之后再定稿，否则很容易写出一份指向错误的路由表。

在整个拆分过程中，我体会最深的一个改写技巧是：把"要做什么"改成"当什么触发时做什么"。原来的写法是"代码评审时要检查是否有调试日志"，现在的写法是"进入代码评审工作流后，在第 2 步读取 code-review.md，按清单逐项检查"。前者只是静态信息，模型不一定能在关键时刻想起来；后者嵌在工作流中，模型按步骤走的时候自然会遇到它。

另一个容易被忽略的细节是子文件的幂等性：每个文件里的规则不应该依赖其他文件的上下文。比如test-strategies.md里如果写"按照上文提到的项目结构来选择测试目录"，那当模型只加载这个手册而没有加载其他文件时，这句话就是废的。正确写法应该是把项目结构的关键信息直接写进手册，或写清楚查找路径。

4.3 迁移后的验证：怎么知道重构真的有效

重构完成之后，我花了整整一周时间观察模型的行为变化。验证手段有三个。

第一是跑固定的"标准作业"。我挑了三类典型任务，分别是"新增一个后端接口""修改一个前端组件并补测试""排查一个模拟线上问题"，把这些任务各自跑三遍，观察模型是否会主动读取对应的工作流文件，是否遵循了核心规则。重构前跑相同任务时，模型经常忽略中间的测试要求或风格约束，重构后模型的行为稳定了很多，基本不会再出现同一任务三种结果的情况。

第二是盯日志里的读取路径。AI 编程助手的会话过程通常会显示打开了哪些文件。我通过这些日志确认模型是不是真的在工作流节点按需打开了对应的手册文件。如果某个场景下它没有读取预期文件，就说明路由协议写得不够明确，需要把这个触发条件写得更强制一些。

第三是阶段性的"规则体检"。每周抽十分钟，把主文件和工作流文件重读一遍，删掉已经不需要的临时状态，核对有没有新增的规则冲突。因为分层之后文件的规模很小，这种检查比原来翻 600 行要轻松得多。

整个过程下来，最直观的变化是：上下文变轻了，模型行为变稳了，新增规则的时候不用再提心吊胆了。重构前每次改 CLAUDE.md 都像在雷区里动土，重构后感觉像在给自己的文件系统做一次正常的整理。

5. 分层治理的四个关键细节：加载协议、幂等性、冲突优先级与上下文预算

如果前面的内容是"正确做法"，那这一节更像是"做了之后才发现必须注意的深层原理"。这些细节单看都不起眼，但任何一个没处理好，分层方案都有可能出现肉眼可见的倒退。

5.1 加载协议：不让模型自己猜测该读什么

你一定遇到过这种情况：把文件拆好后发现，模型在主文件里看到了路由表，也知道有哪些子文件，但就是不主动去读。原因很简单，模型不是人，它不会像项目成员一样"需要时去文档站检索"。如果你只给它一个路径列表，它不知道该在什么时机点去读，读了又不知道读哪个。

所以要写"加载协议"。协议的核心是条件语句：当某场景触发时，必须读取某文件。这一句最好是命令式的，不加"如果需要参考的话"这种委婉说法。在 CLAUDE.md 主文件中我会用"必须"和"需要时"这类词明确区分强度。

某个工作流文件里可以这样写：

## 开发新功能时 读取文件：guides/workflows/feature-development.md 进入编码阶段前 读取文件：guides/handbooks/test-strategies.md

把这些条件写死之后，模型的行为就从"乱七八糟地猜"变成了"严格按流程走"。一开始可能觉得有点呆板，但配置文件本来就不该追求灵活，它追求的是确定性。

5.2 幂等性：每个子文件必须有独立生存能力

子文件的幂等性是我吃了亏之后才补上的要求。最早我写docker-commands.md的时候，想着"反正是给模型看的，上下文都是连在一起的"，于是文件里写了一些"如上文所述""参考前面文件"的省略句。结果某次排查容器问题时，模型只加载了这个手册，前面那些文件根本没读，省略句指代的东西全变成了猜测，给出的命令自然偏差很大。

从那以后我给自己立了一条规矩：每个手册文件都必须具备"孤立可读"的特质。即使模型只看到这一个文件，也能完整理解其中的路径、命令和执行前提。该写绝对路径就写绝对路径，该把前置条件列出来就列出来，宁可稍微冗余一点，也不能让文件之间产生顺序依赖。

5.3 冲突优先级：全局、工作流、手册的裁决顺序

分层之后还会出现一个新的问题：工作流里的某条要求，和全局原则里的某条要求，恰好对同一个操作给出了不同意见。比如全局原则说"所有接口必须有版本前缀"，某个具体模块的维护手册却说"该模块内部服务间调用不需要版本前缀"。

这就不只是"拆文件"能解决的问题，而是要建立清晰的优先级规则。我把优先级定为：工作流文件高于操作手册，操作手册高于全局原则，特殊场景高于通用场景。然后用一条显式声明放在主文件的末尾："如各层文件规则冲突，按以下优先级裁决：workflows > handbooks > principles > CLAUDE.md 全局原则。"这个规则听起来像是废话，但如果没有在配置里写明，模型面对冲突时只能随机选择；一旦写明，它就有了明确的裁决依据。

5.4 算清上下文预算：分层不是把文件藏起来，而是把加载变得更精准

有些人对"分层"的理解是"拆出来的部分模型就看不到了，上下文就省了"，其实这个想法只对了一半。模型在做任务时，如果工作流文件说"加载 test-strategies.md"，它一样会把那个文件的内容吞进上下文。分层真正的意义在于：杜绝无关内容的无意义占用，而不是减少必要信息的读取。

我算过一笔简单的账。原来主文件 600 行，每次会话都全部带入，里面可能有 200 行是当前任务根本用不上的内容。分层之后，主文件 60 行起步，模型做任务时按需加载对应的目录内容，实际进入上下文的信息量其实少了 80%，而且每一个进入上下文的信息都有明确用途。这个"用不上就不读，读了的都是需要的"的状态，才是分层的最终目标。

也正是因为算清了这笔账，我在拆分文件时特别注意控制文件数量。不追求拆得越细越好，而是保持"一个任务最多只看两三个手册文件"的轻量体验。假如几十个文件互相引用，那分层就又变回了另一种形式的一锅炖。

6. 重构后踩到的四个新坑：分层带来的新问题与对策

重构不是终点，反而像换了个新环境，接着踩新坑。这里记录四个我在分层之后实际遇到过的问题，每条都附带现象、根因和调整方案，如果你也在做类似优化，可以直接对照着排查。

6.1 坑一：模型读了路由表，却读不到子文件

第一次重构后，我发现模型在会话日志里并没有按预期打开子文件。它看到了 CLAUDE.md 里的文件路径，但没有主动去读取任何 guides 下的内容。排查后发现，问题出在主文件的路由表表述太"被动"——我只是列了路径和用途，没有把"什么场景下必须读"这个触发条件写进主文件。

对策是把路由表改成"场景-文件"的强关联写法，并且在工作流文件里也加一道保险：开始某个环节时直接写"现在读取 xxx 文件"。双重触发之后，模型的行为才稳定下来。这个坑提醒我，配置文件里"自己会找文件"的假设，在任何模型面前都不成立。

6.2 坑二：分层之后反而出现重复规则

分层也会带来一个新的重复源：同一个规则，既放在全局原则里，又放在工作流文件的注意事项里，还往操作手册里写了一遍。表面看是"多写几遍更保险"，实际效果可能正好相反，模型如果读到同一规则的两个稍微不同版本，又会陷入"该听哪个"的摇摆。

我后来做了一遍严格的"规则去重"，每个文件保留唯一的规则来源。工作流文件里只写流程，不重复全局原则；操作手册里只写方法，不重复原则层的动机。如果某条全局规则需要在某个环节被强调，我会在对应步骤里写"遵守全局原则中的提交规范"，而不是把整条规范又抄一遍。

6.3 坑三：状态文件依然会过期

我在重构后的一段时间里，还是下意识地把"最近决定""当前踩的坑"写进工作流文件里，结果这些动态内容很快和文件里的静态约束混在一起，导致一份本来描述"新功能开发流程"的文件，中间突然插了一段"当前迭代已知问题"。

这个问题的解法还是回归到层的边界：动态信息只准进 state 目录。养成习惯之后，每次迭代结束我都会去更新current-context.md，把过期的临时约定从工作流和手册中清出去。这也验证了分层设计的初衷——把变化的信息和不变的信息隔离，否则再优雅的目录结构也会被习惯打败。

6.4 坑四：拆得太碎导致加载成本上升

还有一段时间我陷入了"过度拆分"的误区，把一个手册文件拆成了四五个更小的文件。表面上每个文件都更聚焦了，实际使用中却发现模型要连续打开好几个文件才能完成同一个操作，中间还可能丢失文件间的衔接信息，最终效果反而不如拆成一个中等大小的完整手册。

后来我给单文件的行数设了一个大致范围：主文件 40~80 行，每个手册文件控制在 100~200 行左右，工作流文件按场景控制在 150 行以内。这样既不需要每次载入长篇大论，又不至于因为拆得太碎而破坏信息的整体性。

7. 日常维护节奏：让分层治理真正"活"下去

重构方案做完了，坑也踩了，最后想聊一聊怎么让这套结构不随时间的流逝慢慢腐烂。分层治理不是一次性的整理，而是一种需要持续维护的文档习惯。

7.1 新规则进场的三步检查

我现在给项目加任何新规则之前，都会强制问三个问题：这条规则是不是不加也行？如果必须加，是否已经存在于某个文件里？如果没有，它该放进哪一层？这三个问题走下来，能拦下一大半"一时冲动加进去"的临时条款。

第一次问"是不是不加也行"，是为了控制总体规则量，避免配置文件重新膨胀；第二次问"是否已有同类规则"，是为了防止重复；第三次问"该进哪层"，等于是让每条新规则一出生就找到自己的位置。一开始这套流程有点麻烦，但执行几周之后就成了肌肉记忆，加规则的速度反而比原来更快，因为不用再纠结塞哪里了。

7.2 每次迭代结束后的十分钟扫雷

我还养成了一个小习惯：每次迭代结束之后花十分钟做一次"扫雷"。扫雷的内容包括三块：检查current-context.md是否还符合最新状态，清理已经完成的临时约束；查看工作流文件里有没有及时发现的新流程需要补充；用文档里的冲突优先级快速过一遍，确认新增规则没有和既有规则打架。这十分钟和整个迭代相比微不足道，但它能保证下一轮迭代开始的时候，配置文件永远是最低噪音的状态。

7.3 一点体会

这次从一锅炖到分层治理的重构，带给我最大的收获不是"文件变小了""模型变听话了"这些表面结果，而是让我重新理解了配置文件的性质：它本质上不是一份给人读的说明书，而是一个小型的、面向 AI 的文档系统。既然是系统，就必须讲究结构、边界和演进方式。

把 CLAUDE.md 当作一套可以持续演进的文档体系来维护之后，我加配置再也不手抖了，模型的行为也稳定了非常多。如果你手头也有一份越写越大的 CLAUDE.md，正处在"不知道从哪下手"的阶段，我建议你从今天开始先做一件事：打开文件，把每一条内容都问一句——这句话放在哪个环境里会有人需要，还是说它根本不该存在？这一步做完，你的重构就已经完成大半了。