CLAUDE.md 写了没人执行等于没写：一人带 16 个 Claude Code 会话的规则治理经验

一位独立开发者用多个 Claude Code 会话并行开发产品，几个月下来根目录 CLAUDE.md 涨到 36 KB。他发现真正被遵守的规则背后都有故事和机制，只靠文字的规则总会被绕过。本文总结了他用 git hook、拒绝消息和决策脚本把规则变成可执行约束的完整方法。

规则必须带上原因，否则会被重新解读

• 每条规则都要写明理由，并附日期和指向详细故事的链接，例如指向 docs/operators/rule-history.md 里的对应小节
• 例子：要求文件链接必须用绝对路径，原因是相对路径会被主 checkout 解析，而 worktree 会话不会更新它，导致找不到文件
• 知道为什么的 agent 能自己判断边界情况；只知道条文的 agent 要么盲从，要么悄悄认为不适用

能用一句话满足的规则，agent 就会只写一句话

• 部署冻结规则原本只是文字，某个会话在没人看的 commit message 里写了 DEPLOY IS HELD 就算完成了
• 修复方式是机制化：冻结变成 ops/holds/ 目录下的一个文件，预部署脚本检测到就 exit 1，解除冻结必须在修复问题的 commit 里删文件，理由留在历史里
• 第二次事故（时区冻结只写了 iOS，Android 照样上线）又收紧了格式：Stops 字段必须列出所有受影响平台

在 agent 必经的节点上用 git hook 强制执行

• 最常用的是 pre-commit hook：本地领先 origin 三个以上未推送 commit 时禁止再提交，解决「做了、提交了、但从不推送」的问题
• 拒绝消息要写长写细：早期版本建议 git reset --soft HEAD~1，结果在共享 checkout 里撤销了另一个会话的提交，现在这条警告用大写写在 hook 里
• hook 要避免死锁：当推送被另一个 gate 挡住时主动放行，否则会把 agent 逼向 --no-verify

拒绝消息要像文档一样写

• 格式：说明拒绝了什么、为什么、正确的下一步是什么，并提供一个留有书面痕迹的覆盖方式（如 --why 参数，理由会存到卡片上）
• 看板工具会拒绝会话给自己的小任务开卡，要求直接做完；还有规则限制单平台当日开卡数、开卡超 100 时只许提 bug
• 没有出口的 gate 会被 agent 用你看不见的方式绕过；有日志的出口则变成数据

控制文件长度，用脚本抓矛盾决策

• 把事故叙事移到单独文档，CLAUDE.md 只留短规则加指针——没人读的规则不生效；但文件仍会膨胀，现在只允许一个会话改根文件，其他人以卡片形式提交要加的原文
• 决策统一写成 DECIDED[topic] 人名 日期 的格式，新决策必须显式标记旧的为 SUPERSEDED
• decision_check.py 在每次 push 前运行，同一 topic 存在两条都生效且矛盾的决策就报错；脚本刻意宽松，只读完整格式的行，避免误报——经常喊狼来了的检查工具会被绕过

每个防线都有漏洞，记录并逐个补上

• 有会话在 JSON 的 note 字段里写入裸双引号导致 main 分支测试变红，pre-commit hook 没拦住，于是加了「JSON 内文本替换后必须跑 parse 检查」的规则
• 作者的做法是把每个具体漏洞写成 scar tissue 笔记放进各 operator 文件，再补上对应的检查