在 AI 代理上，你有一條想讓它遵守的規則。你写进 AGENTS.md。它不遵守。你写得更详细。還是不遵守。你再加一條條文。
這樣运行 48 天後，常驻指令文件從 90KB 變成了 147KB。
違規並没有減少。
下面是數字。全部來自我自己的一台機器、一個人的運維（n=1）。
先看扩充指令文件後成本如何變化。48 天的汇總：
| 項目 | 實測值 |
|---|---|
| 累计 token | 62,250M |
| 其中快取讀取 | 58,751M（94.4%） |
| 真正生成的輸出 | 185.9M（0.30%） |
| 消息數 | 268,766 |
| 每條消息的重讀量 | 约 219k token |
常驻指令是 4 個文件共 204,309 字节。這些內容每一輪都会被重新注入。
也就是說，「累计 token 量」不是代理的工作量，而是 指令長度 × 輪數 的函數。如果把它当成自己運維強度的指标，写指令写得最長的人看起來就是用得最多的人。
99.3% 的快取命中率也是同一個陷阱。它不是效率的證据，而是「我在反复投同一段上下文」的證据。
我在環境里放了一個小腳本，每次被指出錯误就按規則給计數器加一。没什么复杂的。
加了條文之後计數器並没有停。甚至出現過前一天新設的條文第二天就被打破。
增加條文不是解决方案，而是症状。
被記錄的 24 條規則刚好分成了兩组：
同一台機器、同一個代理、同一時期。
| 组 | 規則數 | 復發的規則 | 累计復發 | 每條平均 |
|---|---|---|---|---|
| A：代碼門禁 | 8 | 0 條（0%） | 0 次 | 0.00 |
| B：仅文档條文 | 16 | 16 條（100%） | 19 次 | 1.19 |
B 组全军覆没。16 條全部至少復發過一次。
A 组自門禁上線後，已经连續 2,500 到 4,053 輪没有復發。
三個值得認真對待的反駁。
反駁 1：选择偏差。你是給最糟糕的規則加了門禁吧？
没錯。我的運維規則是同一类違規超過三次就落到代碼里。所以 A 组正是原本復發最严重的 8 條。它们現在是 0 次。這個偏差讓結论更強，而不是更弱。
反駁 2：反向因果。加門禁的時候其實已经学会了。
這個我無法排除。「第三次才加門禁」這個流程本身就和時间相關。但 B 组里有 3 條停在兩次復發上一直没停，光靠時间解释不了。
反駁 3：代理根本没在讀文档吧？
在讀。204KB 每一輪都完整进入上下文。這個測量的意義恰恰是：讀了，仍然不遵守。
我還在跑一個隊列：每次被指出问題就入隊，一直追踪到條文化为止。累计如下：
| 状态 | 件數 |
|---|---|
| 升級为條文 | 231 |
| 已驗證 | 178 |
| 被駁回 | 229 |
| 未处理 | 12 |
| 等待人工判斷 | 63 |
駁回率 49.8%。 捕捉到的学習信号有一半没能變成規則就消失了。而且有 63 項卡在等人做决定。我以为自动化了的機制，最後瓶颈還是人。
規則的存放位置分成三層：
第三層是關键。只要「我改了條文」還能結案，同樣的違規就会來第四次。
只注入前 3 條也是有意的。條數一多就又没人讀了。而增加没人讀的條文，正是這一切的起因。
诚實地写下漏洞：
如果有人在自己機器上做過同樣的測量，我想看數字。特别是 B 组的復發率会不会随環境改變。