澄清规则简单，决定哪个文件负责规则最难

不久前我问 Codex：

你了解我的工作模式和趋势吗？有没有什么负面性的东西值得我复盘呢？

这位AI 助手一聊起我工作模式中的bug，就发狠了，忘情了，没命了！给我写了6条罪状。

今天来聊聊第二条“责任漂移”。

啥是责任漂移

正常互联网哪有人这么说话。听起来像某种 SaaS 公司周会上飘出来的词，左手拿着流程图，右手拿着责任矩阵，嘴里还念着 alignment。

我问它，能不能说点人话。

说人话就是这条规则到底该听谁的，没分清。同一条规则散在好几个地方。automation 里写一点，skill 里写一点，comment prompt 里写一点，wiki 里也写一点。平时都像能管事，真要上班了，却来回抢控制权。

automation、skill、comment prompt、hook、wiki 各自有职责，但你有几次把 guidance 塞进 automation，把 schedule 当唯一 owner，把 hook 权限和远端通道混在一起。

我想狡辩。

有的自动化无法通过简单的automation prompt就能处理好，我喜欢像skill一样处理，有文件澄清步骤，有文件澄清命令使用，有文件澄清filter偏好和进一步加工的prompt。

狡辩到一半，想起一次事故

有一回我改了某个 automation 的 schedule，把运行时间挪了。改完就关窗口了。guidance 文件里还写着旧时间，于是到店一运行、两个文件开始各说各话，schedule 说在新的点跑，guidance 告诉 agent 你是在旧的点运行的任务。agent 该信哪个？

这次它挑了这一个，下一次它可能挑另一个。

挑这个动作，就是概率性的，你无法保证每一次都挑对。

这次事故反而帮我把狡辩想清楚了。

我喜欢像 skill 一样组织自动化，文件多，本身没出过事。出事的只有一处。「什么时候跑」这一个判断，同时住在 schedule 和 guidance 两个文件里。我改了其中一个，另一个还以为自己说了算。文件多不致病，多个文件各执一词才致病。

所以狡辩一半成立。多文件无罪，罪在我从来没指定过哪个文件是「时间规则」的发言人。

Codex 的解法，我核了一遍

我原样留着Codex 的复盘里最极端的那段解法：

只有两种 owner 记录值得存在：一是执行入口本来就会读它，比如 reentry/SKILL.md；二是机器会检查它，比如 automation_drift.py、audit_skill_links.py。其余“我写一下原则”的东西，默认降级成讨论纪念品。

很有意思的想法，但我没有直接信，偷偷让 Claude 确认了一遍。

一半是真的。projects/fieldcraft/README.md 里确实写着「Linear project description 是第一落点，本文件只管本地材料合同」，这就是它说的健康镜像，镜像自己声明「我不替代谁」。automation_drift.py 和 audit_skill_links.py 也真在跑，机器会检查的 owner 记录确实存在。

另一半是它自己发挥的。它说「按 meta-skill 的解法，owner 要回答五件事」，我翻了 skill 原文，里面写的是 job、output、exclusions、constraints、standards，五问版本是 Codex 自己揉出来的。它还建议给 daily digest 补一个 drift check，但 automation_drift.py里早就有一个守着相关边界的检查。

方向没大错，事实打了折扣。

这大概就是处理 AI 复盘的合理姿势，引用可以照抄，应用之前必须核实。不核实就收编，等于把我的大脑替换成了Codex。

我改，但只改一点点

Codex 提供的解法有个漂亮工作名，「Owner = 入口权 + 更新权 + 验证权」。它提出的具体解法有三个方向，给每类判断放到唯一一个负责文件 里；让镜像文件写明自己不替代谁；新建一个drift check检查点梳理反复出错的位置。

我掂量了一下，只有第一层是简单且方便的，另外两层都费劲且用处不大，镜像文件不一定有存在的必要， drift check要写脚本还要养脚本。

所以我最终做的，只有把所有混线排查一遍，只保留一个 owner。

冲突才是正题

排查完，感觉脑子里多了很多对优化 agent 文件处理的规则思路。

规则当然可以放到不同文件里，规则文件很多也是可以的，同一个判断短期写在两个地方，也未必马上出事。

真正的冲突在事故发生那一刻，两个文件给出两个答案，agent 只能挑一个信。owner 这个概念的全部用处，就是在那一刻给出仲裁。平时它只是文件头上的一行注释。

我也越来越觉得，这是 agent schedule 这类系统绕不开的核心，它要处理的从来都是冲突。因为文件搜索不会因为只找到一条规则，本质上来说他在一次搜索中，是可以出现同时面临很多个语义有差异规则的场景的。

澄清一条规则简单，但它必须只被一个文件管理，才能避免以上的情况。