发现这件事时，我的第一反应是有点慌乱。
不是因为一个 AI 任务失败了。任务失败很常见，重跑就是了。真正让我慌的是，它根本没有告诉我自己失败了。
它接了单，没有报错，然后非常有礼貌地消失了。
这种同事在绩效沟通时通常最难聊。
慌乱的不是任务，是支柱
我已经慢慢习惯把信息和决策的前置部分交给 AI。
它们去找资料、检查状态、整理变化，再把结果送到我面前。我做摄入、判断和后续决策。
这个分工给我腾出了很多精力，也让我不知不觉把它当成了一根支柱。
直到这次才发现，这根支柱并不稳定。它甚至不一定“砰”地倒下，只会悄悄停止传递信息，然后让后面所有看似正常的判断都站在旧地基上。
我把“已接单”当成了“正在工作”
这次走火的结构很简单：
- 任务被触发；
- 系统表示已经接收；
- 后面长时间没有新产物；
- 也没有任何明确错误；
- 直到另一层检查发现最后观测信号已经过期。
问题不在于 AI 偶尔会掉线。任何系统都会。
问题在于，我只设计了“开始”和“完成”，却没有定义什么证据能够证明它正在运行。
每个任务都要有六个答案
后来我为这类任务补了一张检查卡：
- 最后观测信号：最近一次可信的运行证据是什么？
- 更新频率：正常情况下，多久应该出现一次新证据？
- 超时阈值：多久没有新证据，就不再继续相信它正常？
- 可验收产物：什么文件、数据、页面或回执才算完成？
- 失效接手人：谁负责发现、停止、重试或改路？
- 恢复回执：重启之后，如何证明工真的继续了？
委托不等于删除自己的判断能力
这次之后，我没有得出“不要把信息工作交给 AI”的结论。
前置工作依然值得委托。否则人又会被拖回无穷无尽的搜集、整理和刷新里。
但委托一层工作，不能连同对这一层的审计能力一起交出去。
我不需要每次都重做 AI 的工作，但必须知道它最后一次交付了什么、这份交付有多新、什么时候应该停止依赖它。
不然的话，省下的不是时间，只是把不确定性延迟到了更难收拾的地方。
带队原则 +1
启动不是运行，没报错不是健康，重启也不是恢复。每一层都要有自己的证据。
这篇是《一个人怎么让多个 AI 不互相打架》之后的一次真实运行记录。控制层不只要分工，还要能发现谁已经悄悄离开了工位。