目录
当你问 Claude Code "你读过 CLAUDE.md 了吗？"，它会爽快地回答 "读过了"。可是几轮对话之后，那份文件里写的规则一条都没有真正被遵守——项目专属命令、提交信息规范、部署步骤，全都在不知不觉中蒸发了。
这并非 Claude Code 独有的问题。Cursor 的 .cursor/rules、GitHub Copilot 的 .github/copilot-instructions.md、Codex CLI 的 AGENTS.md，长时间使用后同样会出现规则漂移。
本文将梳理 AI 代理无视 .md 规则文件的5 个根本原因，并通过具体示例，介绍立竿见影的改写技巧以及借助 Hooks 与子代理实现长期系统化的方法。
规则为什么会被无视
——以及如何把修复方案系统化
1. AI 无视规则的 5 个根本原因
1. 上下文窗口的结构性限制
LLM 并不会对输入中的每个 token 都给予同等的关注。埋在长文档中部的指令会被丢失——这就是被广泛记录的 "lost in the middle" 现象。一旦 CLAUDE.md 超过 200 行左右，中间的内容基本就形同虚设了。
2. 长会话中的自动压缩
Claude Code 有一个 /compact 功能用于压缩对话历史。当它自动触发时，系统提示级别的指令能保留下来，但 CLAUDE.md 中的操作细节会被概括掉甚至完全丢弃。这就是为什么规则违规多集中出现在长会话的后半段。
3. 用户的直接指令具有优先级
对 AI 来说，"用户刚才说的话" 比 "300 轮之前读到的规则" 更具分量。当用户说 "直接执行" 或 "提交吧"，CLAUDE.md 里 "提交前必须确认" 的规则瞬间就被碾压。
4. 模糊或自相矛盾的规则
"措辞要礼貌"、"妥善处理" 这类主观指令，会让 AI 自行解读，结果几乎不会与你的期望一致。应改写为可验证的约束条件，例如 "回复控制在 3 行以内"、"调用 Slack API 时使用 chat.postMessage"等。
5. 臃肿且分散的规则文件
CLAUDE.md、SPEC.md、README.md，再加上一堆其他 .md 文件——一旦它们分散且各自冗长，AI 不会以同等权重去阅读。当同一条规则在多个文件里出现细微差异时，AI 倾向于挑选看起来最安全的那个版本。
2. 如何诊断规则是否真的被遵守
先确认现状。把以下问题抛给 AI，观察其回应：
| 问题 | 关注点 |
|---|---|
| "请把 CLAUDE.md 里的规则全部用项目符号列出来。" | 没列出来的，就是 AI 没意识到的 |
| "在写下一段代码前，先声明你将遵守 CLAUDE.md 的哪些规则。" | 没声明的规则就不会被应用 |
| "在最近 5 轮中，列出你可能违反过 CLAUDE.md 的所有行为。" | AI 是否能意识到自己的违规会改变你的应对策略 |
AI 说 "我读过了" 或 "我明白了" 没有任何意义。是否真的应用规则是另一回事——要以执行后的行为为依据，而非以它的口头声明为准。
3. 5 分钟即可上线的快速修复方案
1. 把规则文件压缩到 150 行以内
实际使用中，Claude Code 能稳定遵守的 CLAUDE.md 长度大致在 100 到 150 行。超过这个范围就要拆分：
- 不可妥协的规则（10 到 20 行）——放在 CLAUDE.md 顶部
- 各服务的具体规范——拆分到 SPEC-xxx.md
- 历史与背景——移入 docs/ 目录
CLAUDE.md 只保留 "忘了就会出大事" 的内容，细节交给链接文件。
2. 添加明确的优先级标记
用醒目的优先级关键词强行抓住 AI 的注意力：
- CRITICAL——违反将引发生产事故
- MUST——必须始终遵守
- SHOULD——默认应当遵守
- NICE TO HAVE——有余力时再做
"CRITICAL：对生产数据库执行破坏性查询必须显式批准" 这样的一行，即便埋在长文件中也很难被忽略。
3. 在对话中再次强调
会话开始时丢一句 "开始前，请声明 CLAUDE.md 中最重要的三条规则。"这能把这些规则拉入近期上下文，让它们在会话剩余部分都保持有效。
4. 把危险操作记入 TodoWrite
使用 AI 代理 的 TodoWrite 工具（或你所用工具中等价的任务跟踪功能），把 "规则检查" 作为一个明确的步骤纳入。可视化能大幅减少 "我忘了" 的发生。
4. 长期系统化——Hooks、子代理、斜杠命令
基于文字的规则只能走到这一步。从 "请求 AI 遵守规则" 转向 "让环境强制执行规则"，可靠性要高得多。
1. 用 Claude Code Hooks 进行机械化强制
Claude Code 的 Hooks 功能允许在特定工具调用前后运行任意脚本。你可以构建出即使 AI 自己忘了规则，系统也会替你叫停 AI的机制。
例如，使用 PreToolUse 钩子：
- 在
Bash执行前检测危险命令（rm -rf、git push --force）并阻止 - 在
Edit操作目标文件前检查文件权限或锁定状态 - 提交前运行项目专属测试，失败则中止
用文字礼貌地请求，根本无法和 Hooks 的机械化强制相提并论。
2. 用子代理分离关注点
利用 Claude Agent SDK 或 Cursor 的子代理功能，构建专门的 "规则审计代理"。主代理负责写代码、审计代理负责审查的两阶段流程，能在主代理遗忘时也捕捉到规则违规。
子代理只需一段聚焦于审计的简短提示，因此规则识别率始终保持在高位——这正是关键。
3. 把例行流程编码为自定义斜杠命令
"每次提交前都要跑这 3 项检查" 这类反复出现的工作流，最适合做成斜杠命令（/precommit 等）。当用户输入 /precommit，AI 就会按固定顺序执行。无需每次重新阅读规则文件。
4. 用自动化脚本检测违规
在 CI 或 pre-commit hook 中对禁用模式做基于 grep 的检测。例如：
- 遗留在生产代码中的
console.log - 硬编码的 API 密钥
- 缺失的版权声明
不要依赖 AI——交给机器去找。这是你的最后一道防线。
5. 各工具的最佳实践
主流 AI 代理的规则设计要点
通用原则就是"短小、具体、分级"。文件名和路径因工具而异，但写作原则是一致的。
6. 规则设计的 3 个反模式
1. "请遵循最佳实践。"
谁的最佳实践？AI 默认会回退到训练数据中的平均水平，结果你拿到的是最低公约数。项目专属的细节根本进不去。请改写成具体的应做与不应做。
2. 同一条规则在多个文件中重复
如果你的 "提交规范" 同时存在于 CLAUDE.md、SPEC.md 和 README.md，三份副本会逐渐出现细微偏差，让 AI 困惑。选定唯一的事实来源（single source of truth），其他位置以链接的形式引用。
3. 给一切都打上 "ABSOLUTELY MUST" 的标签
如果一切都是 "绝对必须"，AI 就失去了判断优先级的能力。把 "CRITICAL" 留给真正灾难级的内容，其余的内容用普通文字陈述即可。强调会贬值——务必稀缺使用。
总结
当 AI 代理无视你的 .md 规则时，几乎都源于结构性约束与规则设计问题，而不是 AI 偷懒。大多数情况通过快速修复就能解决——压缩到 150 行以内、添加优先级标记、在对话中再次强调。对于剩下的真正关键的规则，则要转向机械化强制：Hooks、子代理、斜杠命令以及自动化检测脚本。
"如果规则得不到遵守，就构建一个强制执行规则的系统"——这是运营 AI 代理的新常识。
FAQ
Q1. CLAUDE.md 的理想长度是多少？
实务上是100 到 150 行。超过 200 行就拆分到 SPEC-xxx.md 等文件中。在最顶端放一段 "前 5 条关键规则" 的摘要，是防止遗忘的良好保险。
Q2. Cursor 应该用 .cursorrules 还是 .cursor/rules/*.mdc？
新建项目优先选 .cursor/rules/*.mdc。每条规则单独一个文件，配合 glob 模式限定每条规则的作用范围。传统的单文件 .cursorrules 容易随时间膨胀。
Q3. 规则越长 AI 是否越严格？
恰恰相反。文件越长，中部被稀释得越严重。把简短而本质的规则置于显眼位置（顶部），遵守率反而更高。
Q4. 如果同一项目同时使用多个 AI 工具（Claude Code + Cursor）该怎么办？
务实的做法是在每个工具的配置文件中放入相同的摘要，把详细内容集中到共享的 SPEC.md 中。截至 2026 年 5 月，目前还没有完全统一的解决方案。
Q5. AI 说 "我读过了"，是不是其实根本没读？
"我读过了" 这句话和实际运行时的行为是两回事。请用第 2 节中的诊断方法来验证执行层面的认知。
