技术 · 熟练
它跳过测试时，说的是哪一句话？
把借口提前写下来，拒绝就比遵守更麻烦
写规则的人大多写成「你应该做 X」，而 agent 失败时用的从来不是「我不做 X」这句话。它说的是「这个改动很小所以不用跑测试」「测试环境本来就不稳定」「我先提交再补」—— 每一条听起来都成立。反合理化表（anti-rationalization table）做的就是把这些理由提前逐条写下来，并当场驳回，让「照规矩办」变成阻力最小的那条路。这一页给的是这张表怎么写：先收集它实际说过的话（不是你以为它会说的），再给每条一条可执行的替代动作，最后把校验点钉在动作上而不是态度上。
方法 · 一图看懂
1
先抄原话，不抄想像 — 回看三次它真的偷懒的记录，把它当时的原句抄下来；⛔ 不写「它可能会说……」
2
一条借口配一条替代动作 — 驳回要给出口（「改动小 ⇒ 也跑单测，只要一条」），只有否定句的表是无效的
3
校验点钉在动作上 — 「必须跑过 X 命令并把输出贴出来」，⛔ 不写「要认真」「不要偷懒」这类态度词
4
表要比技能短 — 一张表只治一类毛病；写成长篇规范之后，它又回到「读了但没记住」
原理 · 为什么有效
为什么态度类规则没有用：因为它不可核。「认真一点」既不能被满足也不能被违反，模型无法据此改变行为；而「跑过 npm test 并把最后 20 行贴给我」是一个可以被检查的动作。为什么要把借口写死：因为捷径是模型在压力下的默认输出 —— 当任务难度上升、上下文变长时，它会更倾向选择省事的路径；提前把这条路径标注成「已知的错路」，等于在它比较两个选项之前就把其中一个划掉。判据一句话：你的规则里有多少条，是能被检查「有没有做」的？剩下的那些，基本只是在安慰写规则的人。
适用场景
适合谁：给团队写 AGENTS.md / 技能包 / 项目规则的人；反复在同一类问题上堵漏的人（每次都有人在 review 里说「测试呢」）；把 agent 接进有质量要求的流程（上线、报价、财务）的人。不适合谁：一次性脚本、随手问一句的用法（那时没有「流程」可守）；也⛔ 不适合用它替代真正的自动化门禁 —— 表是提示层，CI 才是闸门，两层各有位置。
自测 · 5 问
表里的每一条借口，是不是它真的说过的话（能不能指出是哪一次、哪一句）
每一条驳回后面有没有配一个具体动作（命令 / 文件 / 要贴出来的输出）
有没有混进态度词（认真 / 仔细 / 尽量 / 不要偷懒）—— 出现即删，换成可检查的动作
这张表是不是长到没人再看：能不能在 30 秒内读完；读不完就拆成两张
有没有一条是「先做完再补」—— 任何允许延后的条款，都要写明「补」的判据与期限
怎么上手 · 验证步骤
第一轮只治一类毛病：挑那个最常发生的（多数是「没跑测试就说做完了」），照原话抄一条借口、写一条替代动作、钉一个校验点，然后故意让它在一个小改动上试一次。你会发现真正的收益不在它变乖了，而在你能一眼看出它有没有照做 —— 这一步才让规则开始起作用。
收工时数一件事：这一轮里，这张表拦下了几次？ 一次都没有不一定是好事 —— 可能是任务太简单，也可能是你的校验点还没被触发。判据是「我能不能在结果里指出它照做了的痕迹」。