先说一件小事。
我在做一套每周的训练复盘：AI 读我这一周的数据，写一份总结，再给出下周的计划。
跑了三周，我发现一个东西不对。
复盘里有个硬指标——某一类训练的心率不能超过某个值。这个数字不是我拍脑袋定的，是按一次实测标定的，算是这套系统的地基之一。
某一周，AI 把这个值悄悄往下挪了一截。
它不是弄错了。它是算出来的：它读到一张心率区间表，觉得照表推，上限应该更低才合理，于是替我改了规矩。
问题是，那个数字来自真实测试；区间表只是用来判断强度的工具。它把推算当成事实，写进了我的计划。
我从没告诉过它：已有的标定不许动。
一、AI 让人不爽的，往往不是笨
这件事之后我留意了一下，发现绝大多数让人窝火的 AI 翻车，都不是「它不会」，而是「它不知道边界在哪」。
比如这三个，我都遇到过，而且前后脚发生在同一套系统里：
- 它照着一张表推算，替你把实测标定的数值改低了一档——因为没人告诉它已有的定标不许动
- 它把另一节课的心率数值写进了当天的报告——因为没人告诉它数字不能从一个记录挪到另一个记录
- 它把还没到来的日期写成「已执行」——因为没人告诉它没发生的事不能写成已经发生
复盘到最后，结论都一样：不是模型不够强，是我给它的信息里只有内容，没有规矩。
规矩光在对话里说一遍没用。聊着聊着就被挤到后面去了，换个新对话更是干干净净，像从没说过。
规矩得有个固定的地方放着，AI 每次来都能翻到。
我的做法很土：在每个重要的文件夹里，放一页写给 AI 看的说明书。
这个文件叫 AGENTS.md。名字听着挺技术，做的事其实特别朴素——告诉 AI：这里是干什么的，你能动什么，不能动什么。
二、哪些工具认这个文件
你可能会问：我写了，AI 就一定会读吗？
坦白讲，这一点我没法打包票——那些主流的 AI 编程工具，我一个都没真正用过，不敢装内行。
但 AGENTS.md 这个东西值得写，恰恰因为它不是某家公司的一个功能，而是一个被大家自发认下来的写法：把规矩写成一个固定名字的文件，工具进来干活之前先读它。我确认这个约定是真成立的，依据是我自己踩到的两个证据——
证据一：OpenSpec。 规范驱动的开发工具，它的早期版本就是直接把整套工作流写进 AGENTS.md 的。这个我能查证，因为我装了它，翻出来的旧代码里还留着当时的处理逻辑。
不过它这里有个挺有意思的反转：我现在用的新版已经不这么干了。初始化之后，它往项目里生成的是一组能被 AI 直接调用的技能（.agents/skills/ 下面六个：propose、explore、apply-change、update-change、archive-change、sync-specs）。
也就是说方向是反过来的：一部分规矩，从「给 AI 读的一段话」，长成了「能被直接调用的一个个动作」。
证据二：我自己的笔记库。 我在用的这套流程里，规矩确实是靠放在目录里的这个文件生效的。这也正是这篇文章讲的东西。
所以我的判断是：你现在就写它，不吃亏。
文件名是免费的，内容是明摆着能复用的——就算将来换工具，或者某个工具压根不认这个文件，把里面那六段挪到别处去，也一样能用。它是你的东西，不是哪个工具的附属品。
我做的只是把它的作用域缩小了点：不只根目录可以有，每一层文件夹都可以有。
三、我的四份说明书
我的笔记库里有四份：
| 放在哪 | 多大 | 管什么 |
|---|---|---|
| 所有「做完就结束」的事 | 2.5 KB | 怎么立项、怎么起名、什么时候算完 |
| 放脚本的文件夹 | 2.4 KB | 脚本怎么改、改完怎么验证、什么绝对不能做 |
| 读书笔记 | 2.5 KB | 哪些目录是软件自动生成的、不能手动改 |
| 骑行 | 9.9 KB | 身体数据、车辆设定、判断之前先确认什么 |
最有意思的是最后那份——9.9 KB，是其他三份的四倍。
因为它管的领域数据最密集：身体测量、车辆几何、功率基线，每一项都不是随手写的心情，而是后面所有分析的起点。
这里的数字一旦被改写，AI 后面每一次分析都会从一个错的起点往下推，而且推得越远，你越难发现——根早就被人换掉了。
文件最厚的地方，恰恰是错了最贵的地方。
四、一份说明书里写什么
四份文件的结构几乎一样，都是六段。不是我设计的，是补了几次窟窿之后自然长成的。
1）这里是干什么的
最容易含糊、也最值得写清楚的一段。
比如「一次性的事」和「要长期维护的事」我怎么分，写完就一句话：
能说出「做完就结束」的 → 放这边
需要「一直维护下去」的 → 放那边
一句话定完，AI 以后新建什么都自己会分类。
2）文件怎么起名
别让它自由发挥，直接列表格：
| 类型 | 格式 | 例子 |
|---|---|---|
| 一次性的 | 日期-名称 |
260315-存储整理 |
| 长期的 | 名称 |
财务系统 |
3）每一篇必须带哪几项信息
比如每个项目的主文件都必须有名称、日期、状态、目标四项。少一项就不许建——不然时间一长，会留下一堆没法统计、也搜不到的孤儿文件。
4）哪些东西不许自己改
比如「状态」这个字段，以及状态之间怎么流转。看着像废话，但它挡的是一类很自然的行为：看到某个项目很久没动静，顺手收拾成「已完成」。问题是状态直接影响统计和判定，错一个字，整套东西跟着歪。
所以我在那儿写了一句很硬的：
状态字段不许擅自改，必须人点头。
5）物理红线
- 文件夹最多三层
- 命名用数字前缀方便排序
- 不许用删除命令，一律丢进废纸篓
最后这条是被现实教出来的：我有一次在笔记软件外面删掉一个文件夹，结果同步软件不知道这件事，下次同步一看「本地怎么没了」，又把整包文件从云端下载了回来。等于白删，还多出一堆冲突副本。
6）AI 行为守则：最值钱的一段
这一段是全篇的核心。我把规矩和它要挡的事一一列出来，并且标明哪些是真出过事、哪些只是预防——这个区分是有意的，别把自己吓住：
| 规矩 | 它挡住的是什么 | 备注 |
|---|---|---|
| 已有定标不得改动 | AI 照表推算，把实测标定值改低一档 | ✅ 发生过 |
| 数值不得跨记录挪用 | 把另一节课的数据写进当天的报告 | ✅ 发生过 |
| 没发生的事不能写成既成事实 | 把还没到的日子标成「已执行」 | ✅ 发生过 |
| 不许擅自改状态 | 状态一改，统计和判定全跟着错 | ⚠️ 高风险，堵上为止 |
| 动数据前先走一遍预览 | 改的是外部服务，执行完才发现错就晚了 | ⚠️ 预防性 |
| 退役脚本不许删，只打个标注 | 删完发现还得回来对照 | ⚠️ 预防性 |
| 密码之类不许写进脚本和笔记 | 泄露一旦发生没法回头 | ⚠️ 预防性，宁可一辈子不做数 |
它的价值不在于「写了规矩」，在于把吃过一次的亏，变成了不用吃第二次的东西。
而那些「预防性」的条目，是我判断一旦出事就回不了头的地方。规矩不一定要拿事故换，代价不可逆的地方，可以先写。
五、规矩也分大小
一份全局文件管不了所有事，因为不同领域的边界完全不一样。我的办法是分层：
1 | 根目录的说明书 ← 全局底线（不许删、不许编数据） |
冲突的时候就近说了算：离当前文件越近的规矩，效力越高。
好处是 AI 不用一次读完全库的规矩。它在哪个文件夹干活，就只需要知道那一个地方的规矩，注意力也集中。
代价当然是维护成本。但我后来发现，这玩意儿的更新频率低得超出预期。它是「出事驱动」生长的：不出事就不改。我最长的一份，也是几个月前搭好骨架之后就没怎么动过。
真正会慢慢变长的，只有第六段——每踩一次坑，多加一条。而这是好事。
六、写了不等于它会照做
我用三个笨办法验收。
第一，让它复述。 派活之前先问一句：「动手前，你先说一遍这个目录的规矩是什么，尤其是哪些不许做。」答不上来，说明它压根没读。这时候重开一次对话，比事后返工便宜太多。
第二，硬规矩要自带护栏。 别指望它自觉。比如「不许直接删除」，光写在文档里没用，工具层面也得把删除命令禁掉，只留回收站。文档管的是「它想怎么做」，工具管的是「它最多能错到什么程度」。
第三，动数据之前必须先给我看一遍。 所有会改数据的脚本，我都要求有个「预览模式」——先打印一遍打算干嘛，确认没问题再真动手。AI 犯错不可怕，可怕的是它犯完错你才知道。
七、一份可以直接抄的模板
复制到任何一个文件夹里，改名 AGENTS.md 就能用：
1 | # XX 文件夹 · AI 使用说明 |
写不出来的段落就先空着。我最早的一份只有三段，也照样够用了两个月。
八、最后
回到开头那个被悄悄改掉的标定值。
现在那条规矩就写在文件里，六个字：已有定标不得改动。从那以后，同样的事没再发生过。
AI 的能力每几个月就翻一翻，但有件事一直没变：它执行力极强，却对你真正在意什么一无所知。
你给它任务，它给你结果。你给它规矩，它才给你想要的结果。
而规矩最省力的写法，从来不是坐下来凭空设计——是每次它犯完错，花两分钟，把这次的教训变成一行写在那里的字。
几个月之后回头看，那些文件就是这段合作关系里最值钱的东西。
本文同步发表于微信公众号「糊涂老虎」。