怎样写一份 Claude 真正会遵守的 CLAUDE.md？

CLAUDE.md 不是强制配置——为什么越长越不被遵守

CLAUDE.md 是一个你写下项目指引（编码规则、结构、注意事项）的文件，Claude Code 会在每次会话时一并读取。但它不是被强制执行的配置。它不会被代码检查并拦下，只是 Claude 参考的指令文本，可能遵守，也可能漏掉。

所以把规则不断堆进一个文件会适得其反。文件越长，规则彼此竞争，那些打破就会出问题的核心指令被大量琐碎指令淹没，遵守得也就越不精准。诀窍不是“写更多”，而是“保持精简”。下面五点就是方法。

CLAUDE.md 究竟合不合适——硬性规则放进 hook

终端中，一个 hook 以“never push to main”的消息拦下向 main 的推送，说明这是无论权限设置如何都会拦下的项目级 hook——一道刻意的护栏。 — hook 真正拦下“never push to main”——是强制，不是请求（Anthropic 官方视频）

写规则之前先问：这条真的该进 CLAUDE.md 吗？像“绝不直接推送到 main”这种必须强制的规则应放进 pre-tool-use hook，而非指令。hook 被设计为在 Claude 尝试该动作的那一刻就将其中断。它不是“希望被遵守的请求”，而是“违反时真正拦下的阻断”。

区别在于：CLAUDE.md 的一行是你希望 Claude 遵守的东西，hook 则是在违反时真正让它停下的东西。生产部署、强制推送、删除生产数据库这类打破就会很痛的规则，应移到 hook，而不是在 CLAUDE.md 的一行里喊“IMPORTANT”。这样 CLAUDE.md 更短，而必须强制的东西也确实被强制。

CLAUDE.md 存在于四处——managed、user、project、local

以图标和说明整理 CLAUDE.md 存在的四处的示意图——Managed Policy（组织，不可排除）、User（个人，全部项目）、Project（团队共享）、Local（被 git 忽略，本仓库个人笔记）。 — CLAUDE.md 的四处：managed policy、user、project、local——全部一起加载（Anthropic 官方视频）

CLAUDE.md 不只是项目文件夹里的一个文件，它存在于四处。managed policy 是组织级文件，由平台团队管理，你无法排除。user 是应用于你机器上所有项目的个人设置。project 是你与团队共享的文件。local 被 git 忽略，是本仓库中只属于你的个人笔记。

Claude 会把这些记忆文件全部一起加载。什么都不会被丢弃，组织策略始终生效。所以“在我重构这个冲刺期间，请一直记着这些架构决定”这类只属于你的临时上下文，应放进 local，而不是共享的 project 文件。关键是不要把所有人都该看到的规则，与你自己的临时笔记混在一起。

用 @路径 import 拆分——但要知道它带来什么

编辑器中打开的 CLAUDE.md，带有注释“Split into topic files for readability — all still load at launch”，三行 @路径 import（如 @.claude/conventions/code-style.md），下方是 ## Rules 部分。 — @路径 import 帮你整理，但在启动时就地内联展开，并不减少上下文（Anthropic 官方视频）

当 CLAUDE.md 变大，@路径 import 语法能把指令拆分到多个文件。写下类似 `@.claude/conventions/code-style.md` 就会把那个文件的内容链接到此处。把代码风格、测试、工作流拆成主题文件，能让庞大的 CLAUDE.md 更易维护。

但要清楚 import 到底做了什么。启动时，Claude 会把被 import 的文件就地内联展开，紧挨着引用它的文件。所以 import 能帮你整理大文件，但既然一切仍在开头一并加载，它并不减少上下文（token）用量。别误以为“我拆开了所以变轻了”——整理和减少上下文是两回事。

措辞决定遵守度——要具体，并指名替代方案

一份全部以“Don't”形式写成的 CLAUDE.md 约定清单——“Don't use default exports”“Don't use any”“Don't put business logic in components”等。 — “Don't use default exports”含糊且没有替代方案——“Use named exports”更好（Anthropic 官方视频）

同一条规则，怎么写会决定 Claude 遵守的程度，而多数规则失败是因为含糊。第一，要具体、可核对。“遵循最佳实践”——连人都说不清究竟指什么，别指望 Claude 会自觉遵守。应写成可核对的，比如“新的 API 路由放在 src/api/handlers，一个文件一个”。

第二，不要只是禁止——指名替代方案。“不要用默认导出”把该用什么留了个开口，解释空间就还在。“使用具名导出，而非默认导出”则把缝隙堵上。若只说别做什么，Claude 可能挑个错误的替代，所以要指出应该做什么。

强调是一种预算——省着用 IMPORTANT

一份 CLAUDE.md 的“HARD RULES — DO NOT BREAK THESE”清单，每一行都堆满 YOU MUST NEVER、IMPORTANT、CRITICAL 之类的大写强调。 — 给每条规则都加 YOU MUST、IMPORTANT，就没有一条突出——强调只留给两三条（Anthropic 官方视频）

强调也有预算。IMPORTANT 和 YOU MUST 会抬高一条规则的优先级，但只是相对于它周围更安静的规则而言。给每一行都加上 IMPORTANT、YOU MUST，就等于什么都没强调。全都在喊，真正要紧的就消失了。

所以强调只用在两三条打破真的会痛的规则上。其余用平实的陈述句写，必须强制的就移进 hook（如前所述）。你越省着用强调，留下的强调就越有分量。

CLAUDE.md 要持续修订——出错时当作缺陷报告

终端中用户输入“Ok, put in the CLAUDE.md file”，让刚刚定下的规则被加进 CLAUDE.md。 — 看到错误后，让 Claude“加进 CLAUDE.md 文件”，它就会写下规则（Anthropic 官方视频）

CLAUDE.md 不是写一次就完的文档，而是要不断修订的。当 Claude 做错时，把它当作针对 CLAUDE.md 的缺陷报告。看清哪里、为何出错后，对 Claude 说“把这条作为规则加进 CLAUDE.md”，它就会替你把规则写成文字。

这样 CLAUDE.md 会依据你真正遇到的问题逐步变得精准。从真实失败中提炼出的规则，比你凭空想象预先塞入的规则被遵守得好得多，冗余也少得多。

结论——像对待生产代码一样对待 CLAUDE.md

像对待生产代码一样对待 CLAUDE.md。每一行都应能自证其存在的价值，凡是你无法自证的行，就删掉。必须强制的移进 hook，变大的文件用 @路径 import 整理。

并且把只适用于某一处的约定收窄到只在那里加载（例如放进相应子目录的 CLAUDE.md，就只在你于该文件夹工作时被读取）。文件越精简，Claude 遵守得越多。归根结底，让 Claude 遵守你的 CLAUDE.md 的，不是你写了多少，而是你克制了多少。