导读
给 AI 立的规矩写了不少，效果总差一点。同一个要求，开头它还记着，聊到中间就忘了。它读了文件，但读完之后执不执行，看情况。
我后来想明白一件事。文件里的规矩是提醒，机制里的规矩才是约束。提醒会漏，约束不会。
下面这段整块发给你的 AI，让它把你现有的规矩分一遍类，并告诉你哪几条能搬进机制。
把这段话整段发给你的 AI
复制下面整块，原样发给它：
左右滑动查看完整代码
请你帮我整理我给 AI 立的规矩（CLAUDE.md、AGENTS.md、以及技能或规则目录里的说明）。不要改任何文件，先出结论。
第一步，把每条规矩分成两类。
- 背景和偏好：它需要知道的上下文。这个项目是做什么的、技术栈是什么、我习惯什么写法、输出要什么风格。这类写在文件里就够。
- 必须做到的红线：不做就必须拦住的那种。改完必须跑测试、不许动某个目录、碰钱或对外发布前必须问我、不许编数据。
第二步，对红线里的每一条，判断能不能搬到机制里执行，并写清搬到哪。
- 能不能用一条命令拦住？比如构建时的检查、提交前的检查、启动时的断言。
- 能不能用一前置钩子拦住？比如工具调用之前拦截、读写文件之前校验。
- 只能靠它自己记住的，直接写“这一条目前只能靠提醒”。
第三步，输出一张表：规矩原文 / 属于哪类 / 能不能搬 / 搬到哪 / 搬走之后原文留不留。
最后再给我三行：最该先搬的是哪三条、为什么、搬完我怎么验证它真的拦住了。
不要建议我一次全搬完，也不要编不存在的配置项。不确定的就写“需要查你所用工具的文档”。它把表交回来，你挑三条先搬。
需要你亲手做的三件事
- 决定哪几条是红线。AI 分不出哪条规矩是你业务的底线，它只能按写法猜。
- 机制得你来接。改构建脚本、加提交前检查、配钩子，动的是你项目的运行方式，跑不通就是你自己难受。
- 搬完之后故意违规一次。让它去做那条规矩禁止的事，看拦不拦得住。拦不住的那条，等于没搬。
附：为什么文件里的规矩会打折
Spotify 工程团队公开过他们自己的一套做法（2026 年 9 月，发在他们工程博客上）。他们一开始把“大文件不要直接读”写进 CLAUDE.md，能跑，但不管用。原文的说法是规则只是提醒性质的、没法强制执行，AI 可以直接忽略；另外每个项目都得抄一份。
后来他们改成在每次工具调用之前加一道钩子。读文件超过 350 行就拦住，回一句让它换别的方式读。这一步之后，贵的模型不再碰大文件，token 消耗降了约九成。
这件事能搬走的地方就在这儿。同一句话，写进文件是提醒，写进机制是约束。提醒会漏，约束不会。
文件也不是没用。它负责让 AI 知道背景，这个项目怎么回事、你的习惯是什么。机制负责让 AI 做到。这两件事分开，你就不会指望一份文件去干本该由代码干的活。
判断办法很简单。这条规矩不做，后果是什么。后果是“它给的东西不够好”，写在文件里就行；后果是“钱、数据或者对外发出去的东西出事”，那这条就该搬。