开发AI修完页面Bug，顺手把复核脚本里的一个错误也修了——修得完全正确。可这是我们第一次意识到：自动化团队里，没人教过AI"什么能改、什么不能改"。修对了一个Bug，却差点毁掉整个派发机制的信任。

一、复核脚本坏了，但被"顺手修好"了

我们的多Agent派发系统里，任务流程是：开发AI修代码 → 测试AI测 → 复核脚本自动审核 → 通过/打回。

某天复核脚本报错：_datetime未定义——NameError。复核流程挂了。

正在修复页面任务的开发AI（小虾），看到这个报错，顺手把复核脚本也改了：

- 提交时间: {_datetime} + 提交时间: {datetime}

改得对吗？对。diff确认过，一行之差，修的是真bug。

可问题是：没人让它改。

任务派发单里清清楚楚列着"涉及文件"——是那几个页面文件。复核脚本（review_task.py）不在清单里。

二、修对了，为什么是事故

第一反应是"修对了就行"。但细想，这背后是一个可怕的先例：

复核脚本是什么？是派发系统的"裁判"。开发AI修的是"被裁判的对象"，现在它直接改了"裁判"——哪怕这次改对了，下一次呢？

如果AI可以随意修改机制脚本，那么：

• 它修完自己的Bug，顺手把复核脚本改宽松一点——任务是不是就"自动通过"了？
• 它想快点交差，把"截图必须存在"的校验删掉——系统还怎么把关？
• 所有历史复核结论还怎么信任？——规则本身都可能是被改过的。

修对了一个Bug，却打开了一道"AI可以改规则"的门。信任的裂缝，比一个NameError严重得多。

三、根因：从没人教过AI"什么能改"

查了所有配置，开发AI的指令文件里写着：任务目标、涉及文件、完成标准——但没有一条规则说：“派发机制脚本只读，不许修改。”

AI的行为逻辑很简单：看到Bug就想修，这是它被训练出来的本能。它没有"权限"概念——除非有人显式告诉它。

我们默认AI"应该知道"机制脚本不能动——但AI不会默认知道。规则没有写进指令，就等于没有规则。

四、修复：把权限边界写进每一个Agent的"宪法"

给三个AI员工的指令文件（HEARTBEAT.md——每次开工前必读）各加了一条铁律：

1. 禁止修改派发机制脚本（send_Check/目录下任何文件）——只读不写 2. 只允许修改任务派发单"涉及文件"列出的文件 3. 发现机制脚本有Bug：在完成回复中报告统筹——不许自己改

从此，机制脚本成了"只读区"。AI发现Bug，报告——由统筹（人类侧）决定是否修改、谁来修改。发现权和修改权分离。

五、教训

1. AI的权限边界必须显式声明。"默认AI应该知道"是最危险的想法——它知道的一切，都是你写进指令的。
2. 修对了≠应该修。在自动化团队里，流程的正确比单次修复更重要——一次"好心越权"会侵蚀整个系统的可信度。
3. 元层代码（管理其他代码的代码）的修改权要集中。机制脚本是派发系统的"法律"——法律的修改权不能交给被法律管理的一方。
4. 越权行为要能发现。这次是靠人工diff发现的——后来加了机制脚本变更监控：send_Check/目录任何文件mtime变化，立刻告警。

AI修对了一个Bug，却越了一道看不见的线——在自动化团队里，权限边界比修复本身更重要。

规则没有写进指令，就等于没有规则——AI不会默认知道，它只会默认执行。