前两篇记了两个教训：一条铁律——给 AI 配的长期记忆只能有一份真相源，不能分散在几个地方各记各的；一条规矩——记忆只能由一家 AI 写入，别的几家只读，要添东西先投到收件箱等归并。
这第三课更琐碎一些，不关记忆，关指令本身。
我现在同时用三个 AI 编程工具。一个是主力，干活最多；另外两个各有长处，轮班上场。三个工具都需要一份指令文件告诉它：我是谁、我偏好什么、哪些事该做哪些事别碰。
最早的做法很直觉：给每家手写一份，大意差不多，但各有些针对工具特性的小差异。写完那天，三家的行为高度一致，令人短暂地以为”问题已解决”。
一周后就不对了。
原因很具体：我改了主力工具的指令——加了一条行为规则，删了一条过时的约定——改完顺手就继续用了。另外两家的文件还停在旧版本上。又过几天，某个工具的做法让我觉得别扭，查了半天才发现它在忠实执行我两周前已经删掉的规矩。
它没有错。制造混乱的人是我。
用软件工程的话说，这叫”配置漂移”——同一套规则有三份拷贝，改了一份忘了另外两份，时间一长就各说各话。做过运维的人都知道，三台服务器的配置一旦漂移开来，bug 会从你想不到的角落冒出来。
后来收敛出的办法不复杂，甚至有点笨：只维护一份指令原件，放在一个固定的地方；写一个同步脚本，每次改完原件跑一遍，由脚本自动生成三个工具各自需要的入口文件。入口文件不许手改——改了也白改，下次同步一律覆盖。
核心约束只一条：人只改原件，不碰生成物。
听着像常识。实际操作起来，随手改某个工具的入口文件比去找原件、改原件、跑脚本要快得多，每一次省事的冲动都在邀请你绕过流程。而每一次绕过，都在制造下一次漂移。
记忆那边的纪律亦是同理。三家工具都能读我积攒的笔记——关于偏好、工作习惯、过往决策的几百个文件——但只有一家有权直接写入。另外两家发现值得长期记住的东西，只能写一条候选投到收件箱，由主力工具定期归并。限制写入权限，并非不信任那两家。两个写入者同时改一份文件的后果，比延迟归并几小时要严重得多——这一点上一篇已经吃过亏了。
三课攒下来，隐约有一条线串在里面：跑偏的根源，每一次都不在工具身上。AI 不会自己决定去哪里找真相——你给它哪份指令，它照办；AI 也不会自己决定谁有权写记忆——你的流程决定的。出问题的那个环节，从头到尾是操作者本人：改了一处忘了另外两处的是你，嫌跑脚本麻烦直接手改的也是你。
工具越听话，操作者的纪律就越是那个真正的瓶颈。