一、三份模板长什么样

React 前端那份：pnpm 管包、src/components 放组件、src/pages 放页面、zustand 管状态、 Tailwind 管样式、不许写 class 组件。 Node 后端那份：pnpm 管包、src/routes 放路由、src/middleware 放中间件、Prisma 做 ORM、pino 打日志、 不许手写 SQL。 Python 数据那份：uv 管包、src 放源码、data/raw 放原始数据、polars 做处理、matplotlib 画图、 不许用 pandas 的 inplace。

三份都是九条，看着都挺合理。合理是因为它们各自在自己的项目里都成立。

二、换一个环境，八条对不上

把三份都放到「Python 数据项目」这个环境里检查：命令有没有、目录在不在、依赖装没装。 结果很难看：React 那份九条里对得上一条，Node 那份也是九条对一条，只有 Python 那份九条全对。 对得上那一条还是「不要写 class 组件」这种风格条款——它不依赖任何环境，所以在哪儿都算成立。

这个结果说明一件事：模板的绝大部分内容是有环境前提的。前提不对，内容就作废。

三、对不上的三种坏法

最轻的是白写。模型看到「用 pnpm」，扫了一眼发现没有 pnpm，退回 npm。这条规矩等于没写，但也不出事。 重一点的是误导。模型可能真的去跑 pnpm install，报错，再花几轮试别的。 这几轮的钱和时间是你自己给的。 最重的是静默走偏。 「组件放 src/components」这条，如果模型真按它建了目录，项目里就会多出一个没人用的空目录。

更麻烦的是这个空目录以后会有人往里放东西——因为它在 CLAUDE.md 里写着。 一条过时的规矩，会长出一个真的目录。 所以抄模板的第一件事不是删，是核对。核完再删。

四、三份里真正能通用的

按字面完全相同比，三份都出现的是零条。 按意思比会多一点：「提交前跑检查」三份都有，只是命令不同——前端后端是 pnpm lint， 数据项目是 uv run ruff。 真正通用的是那一类跟工具无关的规矩：提交前跑检查、新代码要配测试、不提交密钥、改动要小步。

这些可以抽成一份「跨项目通用规则」，放在用户层（上一节的第二层）。具体命令留在项目层。 这样分层之后，换项目只需要重写项目层那九条，通用那几条跟着人走。

五、三份模板并排看

把三份的核心条目抽出来对比，差异一眼就看清了：

三列里只有「测试」这一行后半段能互通——都指向「有测试要跑」这个意图，但命令本身各不相同。 这张表也解释了为什么模板不能跨栈复用：每一行都绑在具体工具上，只有最后一行是纯风格条款。 所以更稳的做法是把它拆成两份：一份写「要不要测试、要不要格式化」这类意图，放用户层跨项目用； 一份写具体命令，放项目层按栈重写。

六、本章小结

第二章讲记忆。四节各管一段，收在一句话上：记忆不是存得多，是每轮只带该带的。 2.1 说清为什么必须往外搬：模型无状态，记忆靠重送，窗口是每轮都要付费的。 2.2 讲五层的划分与叠加：企业、用户、项目、目录、会话，越具体越赢，而目录层是按位置加载的， 这是省钱的抓手。

2.3 讲根目录那份怎么写：可判定原则、四段骨架、一百行以内。 2.4 讲带条件的规则：什么该常驻、什么该按路径加载，宽窄怎么取舍。 2.5 把三份模板放在一起，证明抄模板必须先核对命令、目录、依赖三样。

下一章换一个粒度：记忆管的是「每条会话都知道的事」，而技能管的是「用到才需要知道的事」。 两者的分界线，就是下一章的开头。

七、动手 Demo：三套模板丢进同一个项目，有几条对不上

三份模板各九条，都来自真实项目的典型写法。 环境定为「Python 数据项目」：命令只有 uv，目录只有 src 与 data/raw， 依赖只有 polars 与 matplotlib。 逐条检查三样：命令能不能跑、目录在不在、依赖装没装。再算一遍三份之间真正重合的有几条。

env = {
    u"command": set([u"uv"]),
    u"dir": set([u"src", u"data/raw"]),
    u"dep": set([u"polars", u"matplotlib"]),
}
for text, kind, val in TPL[name]:
    if kind == u"style":        # 风格条款不依赖环境，直接算通过
        ok += 1
    elif val in env[kind]:
        ok += 1
    else:
        bad += 1

实跑输出：

--------------------------------------------------------------------
三套模板丢进同一个项目，有几条对不上
--------------------------------------------------------------------

  三份 CLAUDE.md 各九条，都来自真实项目的典型写法。
  现在把它们挨个放到「Python 数据项目」这个环境里检查。

  ① 逐份检查：命令、目录、依赖在不在
  --------------------------------------------------------------------
| 模板 | 条数 | 对得上 | 对不上 | 对不上的依赖 |
|---|---:|---:|---:|---|
| React 前端 | 9 | 1 | 8 | pnpm、src/components、src/pages、tailwind、zustand |
| Node 后端 | 9 | 1 | 8 | pino、pnpm、prisma、src/middleware、src/routes |
| Python 数据 | 9 | 9 | 0 | — |


  ② 对不上的那些，会怎么坏事
  --------------------------------------------------------------------
  最轻的是白写：模型看到「用 pnpm」，发现没有 pnpm，退回 npm，这一条等于没写。
  重一点的是误导：模型可能真的去跑 pnpm install，报错，再花几轮试别的。
  这不是模型的错，是你告诉它这个仓库用 pnpm。
  最重的是静默走偏：「组件放 src/components」这条，如果真按它建了目录，
  项目里就会多出一个没人用的空目录，而且以后真有人往里放东西。
  ! 所以抄模板的第一件事不是删，是【核对三样】：命令跑不跑得通、目录存不存在、依赖装没装。
  三样都对得上，那条才留。

  ③ 三份里真正通用的部分
  --------------------------------------------------------------------
  按字面完全相同来比，三份都出现的只有 0 条。
  按意思比会多一点：「提交前跑检查」三份都有，只是命令不同——前端是 pnpm lint，后端是 pnpm lint，
  数据项目是 uv run ruff。
  这说明模板之间能直接搬的东西非常少，真正通用的是「提交前跑检查」这一类跟工具无关的规矩，
  具体命令必须按项目改。
  ! 所以别指望拿一份模板套三个项目。
  能复用的是背后那张检查清单：命令跑不跑得通、目录存不存在、依赖装没装、有没有禁区。

①这张表是本节的靶子：两份八条对不上，一份全对。 「对不上的依赖」那一列把问题点得很具体：pnpm、src/components、zustand、prisma， 这个项目里一个都没有。 ②三种坏法按严重程度排：白写、误导、静默走偏。 最值得一提的是第三种。一条过时的规矩会长出一个真的目录——因为它写着，所以有人（模型或人）会照它做。 ③按字面比，三份重合零条；按意思比，「提交前跑检查」三份都有。 这个差别说明：模板能复用的是「要做检查」这个意图，不是「跑 pnpm lint」这条命令。 所以通用规则放用户层（跨项目），具体命令放项目层——上一节的五层在这里落地了。

30 秒实验

1. 造第四份模板：Go 服务端。写九条，然后按同样的三样检查一遍。它跟 Python 环境有几条对得上？
2. 把 React 那份里对不上的八条逐条改写，让它适配 Python 环境。改写后还剩几条是原意？
3. 把你自己的通用规则抽出来（提交前检查、配测试、不提交密钥），写成用户层的一份文件， 看它跟三个项目各自的 CLAUDE.md 有没有冲突。

常见误区

1. 直接抄一份网上的 CLAUDE.md。 里面一半规矩有环境前提，你不核对就搬，轻则白写，重则长出一个不该有的目录。
2. 只核对命令，不核对目录和依赖。三样里缺一样，那条规矩就不能留。
3. 以为模板可以跨技术栈复用。演示里两份八条对不上，只有风格条款通用。
4. 把通用规则写在项目层。换个项目就得重抄一遍，而且容易抄漏。
5. 配完不试。让它按这份配置干一件小事，是最快发现「这条不对」的办法。

记忆层讲完了，下一章换粒度：从「每轮都在的规矩」换到「用到才读的知识」，也就是技能。

• ☐ （本篇完，下一篇 3.1 从 CLAUDE.md 到 Skills：知识的两个维度）

相关笔记

• 写作范式：可判定原则
• 条件化规则：条件化规则的宽窄
• 五层记忆：五层里的用户层
• 🐎 Claude Code 实战 · 索引