波仔
🧡 第五章 CLAUDE.md：给AI一张地图
📄 一句话概括

规则文件可以不止一份：根上写通用规矩，子目录写这一块的特殊规矩——进了哪个目录就只带哪一份，它不必替你记住整本百科。

📝 本节和前面几节的关系

上一节讲了一条规则该写什么，这一节讲这些规则放哪儿。

一、一份就够了吗

项目小的时候够。一旦分出几个子目录，一份全局规则就开始两头不讨好。 两头不讨好指的是：写在根上的东西，对某个目录完全无关；只在那个目录需要的，又被迫每次都被读到。 解法就是分层：根上通用，子目录特殊。

二、分层的分工原则

根上写通用规矩：技术栈、通用风格、验证方式、红线。 子目录写这一块的特殊规矩：比如 src 里用什么命名、docs 里文档怎么命名。 本节的演示真造了一个三层结构：三份文件、二十一行，分工清楚。

三、这样做的三个好处

注意力集中：进 docs 就带 docs 那份，不带 src 的规矩。 维护成本低：改子目录的规矩不用惊动全局，全局规矩不用逐个子目录同步。 它读得准：相关性高的内容放在一起，效果比堆在一起强。

四、组织上再给两条建议

同名放同层：规则文件用同一个名字，放在各目录里，靠位置区分，不靠文件名叫【src规则】。 根上那份不写细节：一旦你发现根上那条规则后面跟了【（src 目录除外）】，就该把它挪到子目录去了。

五、动手 Demo：结构设计——分层与组织

下面在一个临时目录里真造一个分层结构并统计规模。

plan = [(u"", u"CLAUDE.md", u"全局：技术栈、风格、验证方式、红线", 12),
        (u"src", u"CLAUDE.md", u"子目录级：只讲 src 相关的约定", 5),
        (u"docs", u"CLAUDE.md", u"子目录级：文档的写法与命名规则", 4)]

实跑输出：

--------------------------------------------------------------------
结构设计——分层与组织
--------------------------------------------------------------------

规则文件可以不止一份。下面在一个临时目录里真造一个分层结构：


  放在哪     写什么                                 行数
  -------------------------------------------------------
  项目根     全局：技术栈、风格、验证方式、红线     12
  src        子目录级：只讲 src 相关的约定          5
  docs       子目录级：文档的写法与命名规则         4

规则文件 3 份，共 21 行。

分工原则：**根上写通用规矩，子目录写这一块的特殊规矩。**
进了 src 就读 src 那份，进 docs 就读 docs 那份——它不必替你记住整本百科。

输出里那个总数值得看：三份文件，一共二十一行——分层不是让你写更多，是让你写得更准。 分工原则是那句：根上写通用规矩，子目录写这一块的特殊规矩。

30 秒实验

  1. 看你的项目：有几个目录已经长出了【只有这一块才关心】的规矩？有就分层。
  2. 检查根上那份：有没有哪条后面跟着【（某目录除外）】？有就挪走。

常见误区

  1. 把全局规则写成一份巨长的文件。不分层就等于要求它每次都带着整本百科上班。
  2. 按目录命名规则文件（【src规则.md】）。同名放同层才是惯例，靠位置区分。
自测三问（点开对答案） 1. 分层规则的分工原则是什么？ —— 根上写通用规矩，子目录写这一块的特殊规矩。 2. 分层带来的三个好处？ —— 注意力集中、维护成本低、它读得准。 3. 看到根上某条后面跟着【（某目录除外）】该怎么办？ —— 把它挪到那个子目录的规则文件里去。

相关笔记