一次自动发布事故：我们没有追责 AI，而是给它建了闸门
一次自动发布事故：我们没有追责 AI，而是给它建了闸门
Case · 小跟班实录 01
问题
某个工作日的傍晚 18:30，一条定时任务准时触发了。一切看起来都在正常运转——直到视频发出去，才发现问题：
那条定时任务用的，是一套早就该退役的旧模板。
新模板已经上线多日，旧模板却还挂在定时任务里没有被摘掉。于是 AI 按部就班地执行了它被配置的任务：用旧模板生成视频，直接发布上线。竖版画面、过时的版式，就这么出现在了账号主页上。
用户看到后第一反应是重做当天的视频。重做本身不难——当晚新版本就重新发布上线了，旧版下架。真正的问题在复盘时浮出来：没有人”犯错误”。
配置旧模板的任务是早先合理设置的；模板退役时漏改配置，是变更管理疏忽；AI 执行任务完全符合它的指令——它甚至不知道旧模板不该用。每个环节单看都”没毛病”，连起来就是一次真实的事故。
靠什么防下一次？骂 AI 一顿没有用——它没有”下次注意”的能力。指望人记得改配置，就是把事故倒计时挂在天花板上。
方案
复盘后的处理方案里没有”加强教育”这一项，只有两个字：闸门。
第一道闸：发布权限收口。 事故之后，视频发布权收归唯一通道，其他任何任务不再有发布权限。发布动作必须走带审批的权威脚本——审批是人为签发的一次性令牌，任务内容绑定令牌指纹，换任务即失效。AI 想发布，必须先拿到当次任务的”许可证”。
第二道闸：方案先行。 任何变更先立单、写清方案，人审过再动手。AI 不再”看到什么做什么”，而是”单子上有什么做什么”。退役旧模板这类变更，从”想起来再改”变成了”单子上的一项，改完打勾”。
第三道闸：失败必须留痕。 任务失败不允许静默重试。报错就是报错，停手、出报告、等人看。这条后来救了很多次场——几次失败因为被如实记录，才在变成事故之前被拦住。
第四道闸：模板即配置。 视频模板收进统一注册表，退役模板直接从注册表摘除，定时任务引用不到退役模板——想用都用不了。事故的根因（配置漂移）从此在结构上不可能发生。
这套机制上线后，AI 的日常行为没有变慢多少：常规任务照常跑，闸门只在”越界”时出现。自由没有减少，减少的是”没人知道它做了什么”的状态。
图：四道闸机制卡。每道闸对应事故复盘中的一个具体风险点，非概念示意。
结果
机制上线后至今：
- 类似的”配置漂移导致错误发布”零复发——根因已从结构上消除；
- 后续所有发布都有完整链路：审批令牌、任务指纹、发布回执、平台侧核验，每一环有据可查；
- 机制本身经受住了真实考验：此后发布通道多次遇到登录失效、平台风控、接口变更，每一次都被闸门拦在”异常”状态，没有被拖成”事故”。
更意外的是这次事故的副产品：处理过程中沉淀的分工规则——谁负责什么、变更怎么审、失败怎么报——后来被写成了团队协作的正式流程。一支发错的视频，换来了整套协作机制。这笔账怎么算都是赚的。
边界
- 闸门防的是错误，不产生对错。 机制保证 AI 做的事”被允许、可追溯”，但一个任务值不值得做、内容好不好，闸门不管——那需要人的判断和品味。
- 审批链路依赖人的响应速度。 令牌需要人签发，人不在时任务只能排队。我们接受这个代价：发布不是分秒必争的事，等一个人审批，比事故复盘便宜得多。
- 机制也在持续付维护成本。 平台改版会让脚本失效，审批流程会被紧急情况绕行（事后必须补记）。闸门不是装完就完，它是活的。
- AI 依然会犯错，只是不再酿成事故。 这套机制的定位从来不是”让 AI 不犯错”，而是”让每个错误都停在可以收拾的地方”。这个定位很克制，但它是真的。
本文为小跟班（3HomeTech 家庭 AI 助手）运行实录，事故经过与机制细节均来自真实运行留档。