一份会被遵循的 CLAUDE.md
有一个几乎每个人都会掉进去的陷阱：您的 CLAUDE.md 文件会不断膨胀。您遇到一个问题，就加一条规则。又遇到一个，再加一条。不知不觉间，您就有了一个庞大的文件，而 Claude 开始忽略其中的部分内容。这不是 Claude 的缺陷，而是这个文件的运作方式决定的。
需要理解的关键点是，CLAUDE.md 并不是强制执行的配置，而是指导性内容。文件中的每一行都在与其他每一行争夺 Claude 的注意力。文件越长，它与自身的竞争就越激烈，Claude 遵循任何一条规则的可靠性也就越低。所以目标不是把所有事情都写下来，而是让文件保持精简。文件越精简，Claude 实际遵循的部分就越多。
首先，问问 CLAUDE.md 是否是合适的工具
在写一条规则之前，先问问它是否真的属于 CLAUDE.md。有些规则是指导性的，有些规则则是绝不能逾越的硬性底线。这是两种不同的职责。
以"绝不能推送到 main 分支"这样的规则为例。如果您把它写进 CLAUDE.md，您只是在期望 Claude 读到并遵守它。大多数时候它确实会遵守。但对于这种危险程度的事情，"大多数时候"是不够的。这样的硬性规则应该放在 pre-tool-use 钩子（hook）中。
这个区别很重要。钩子是在 Claude 执行某个操作之前运行的代码，它能够真正阻止该操作。所以即使 Claude 确实尝试推送到 main 分支，钩子也会阻止它。这是真正的强制执行，而不是礼貌的请求。把您的硬性规则移到钩子中，让 CLAUDE.md 来处理那些较为柔性的约定。
四个位置
CLAUDE.md 并不只是项目中的一个文件。它可以存在于四个位置，Claude 在启动时会把它们全部一起加载。没有任何内容会被丢弃，它们是叠加生效的。
以下是每个位置的用途：
- 托管策略（Managed policy） —— 由您的平台团队控制的组织级文件。您无法排除它，因此组织策略始终生效。
- 用户（User） —— 您的个人偏好设置，会跟随您在本机上的每一个项目。
- 项目（Project） —— 与团队共享、纳入代码仓库的文件。
- 本地（Local） —— 被 git 忽略。仅供您个人使用的、针对这一个代码仓库的笔记。
最后这个"本地"位置很容易被忽视，但其实非常好用。比如说，您正在自己的分支上进行重构，希望 Claude 在工作时记住一些架构决策。这些内容不适合放进会影响整个团队的共享项目文件中，而应该放在本地文件里，只属于您在这个仓库中的使用。
用导入拆分大文件
当您的项目文件开始变长时，您可以使用"文件路径导入"语法把它拆分成多个部分。不再是一整面文字墙，而是指向其他文件：
@.claude/conventions/code-style.md
@.claude/conventions/testing.md
@.claude/conventions/workflow.md这对于组织内容非常有用。但要清楚它到底带来了什么好处，因为很容易产生误解。当 Claude 启动时，它会把这些被导入的文件内联展开，就放在您引用它们的位置。所以导入能帮您把内容整理得井井有条，但所有内容仍然会被提前全部加载。它们并不会减少 Claude 需要读取的上下文量。使用导入是为了组织内容，而不是为了减轻加载负担。
措辞决定规则是否能被遵守
一旦您确定某条规则应该放进 CLAUDE.md，Claude 是否真的会遵守它，就取决于您如何措辞。大多数规则失败是因为它们太模糊。以下是修正方法。
具体且可核查
不要写"遵循最佳实践"。您自己真的知道这具体指什么吗？如果您都无法核查它是否被遵循，Claude 也同样无法核查。比较一下这两种写法：
- 模糊："遵循 API 路由的最佳实践。"
- 具体："将新的 API 路由放在
src/api/handlers中，每个文件一个路由。"
第二种写法是明确的。您可以直接查看结果，立刻判断是否做对了。这应该是每条规则都要达到的标准。
说明替代方案，而不只是禁止某事
当您告诉 Claude 不要做某件事时，要说明应该做什么来代替。否则您就留下了一个空子。
- 留有空子："不要使用默认导出（default exports）。" 好吧，那该怎么做？
- 堵上空子："使用命名导出（named exports），而不是默认导出。"
第二种写法说明了替代方案，因此没有任何被误解的余地。
强调是一种预算
像"IMPORTANT"和"YOU MUST"这样的词确实会提升一条规则的优先级。但这只是相对于周围其他较为平淡的内容而言。如果每条规则都在"喊叫"，那就没有任何一条能脱颖而出，强调也就失去了意义。所以要把强调当作一种预算来使用。把它花在那两三条一旦被违反就真正会造成严重后果的规则上，让其余规则保持正常的音量。
让文件保持持续修订
您的 CLAUDE.md 文件永远不会"完成"。要把它当作持续被编辑的活代码来对待。
当 Claude 做错事时，不要只是叹口气然后手动修正。要把它当作针对您的 CLAUDE.md 文件的一个 bug 报告。您甚至可以直接告诉 Claude："把这个加到 CLAUDE.md 文件里"，它就会为您写出这条规则。这样一来，每次出问题，文件都会变得更好。
总结
把您的 CLAUDE.md 当作生产代码来对待。如果您无法为某一行内容找到理由，就删掉它。要让文件保持精简且易于遵循：
- 把硬性规则移到钩子中，让它们真正被强制执行。
- 用导入来组织长文件（但要记住，它们并不会减少上下文）。
- 让每条规则都具体且可核查，并说明替代方案。
- 把您的强调预算花在最重要的少数几条规则上。
- 每当 Claude 出错时，持续修订文件。
整个理念很简单：文件越精简，Claude 遵循的部分就越多。