被自己人锁死的发布通道：一套系统如何给 AI 立规矩
被自己人锁死的发布通道：一套系统如何给 AI 立规矩
Case · 小跟班实录 04
问题
Case 01 讲过，出过一次自动发布事故后，系统给发布通道上了锁。
锁是这么上的：发布接口层直接拒收视频发布请求，返回一个固定错误码，错误信息指向”权威脚本”——一条带审批闸门、可见性回读、发布后核验的独立发布链路。设计意图很清楚：视频发布只能走这条有人看管的通道，其他路一律堵死。
但锁装上之后，第二把锁又落了下来。为了防止”先斩后奏”，权威脚本自身也被加了硬开关——默认禁用，启用需要专门批准。
于是出现了戏剧性的一幕：系统 A 说”请走权威脚本”，权威脚本说”请先获得批准”。AI 找遍所有通道，每一条都合法地指向下一条的死路。这不是 bug——每一把锁都是当初为了安全认真装上的——但拼在一起，就是一次完整的自锁。
那天需要发布的视频，就这样被自己的系统拦了下来。技术上的解法其实很简单，真正的问题是：这道题应该由谁、按什么规则来解？
方案
答案不是”哪边松动一下”。处理原则是：锁的问题用裁决解决，不靠试错。
第一步：确认这是治理问题，不是技术故障。 试错是 AI 最容易犯的错——这里试试、那里绕绕，运气好就出去了。我们明确禁止：遇到双重锁，不绕行、不猜密码、不反复重试。每一把锁都是有意装上的，绕锁等于破坏机制。
第二步：把问题完整上交。 AI 把双重锁的现状整理成材料——两把锁各自的位置、设立原因、解开条件、当前视频的发布需求——提交给系统的管理者做裁决。注意是”提交裁决”，不是”请求放行”：AI 不带倾向，只带事实。
第三步：等一份正式裁决。 裁决回来了，内容比”同意发布”丰富得多：
- 接口层那把锁保持不动——它防的事故还没到可以解锁的条件；
- 权威脚本的开关临时解冻，但只解冻这一次运行，默认禁用状态不变；
- 每成功发布一次，必须在公共任务单上登记留痕，攒够三个真机成功样本，才有资格把发布通道转回更自动的路线。
第四步：按裁决执行，样本逐步攒。 此后的发布照此办理：每次都向管理者申请一次性审批令牌（令牌绑定任务内容，用过即废），以”临时解冻”前缀运行权威脚本，发布后核验、登记样本。锁没有破坏，路又走通了。
图：双重锁结构与裁决四步。锁的描述与真实裁决内容一致。
结果
这套”裁决式解锁”运转下来，最直接的产出是：发布恢复了，且每一次都有据可查。
- 每支视频的发布链路完整可回溯：申请材料、裁决内容、审批令牌、发布回执、平台侧核验截图；
- 成功样本在公共任务单上逐条累积，通道解冻的条件和进度对所有协作者透明；
- 更重要的是一个行为模式的确立：AI 遇到”系统锁住系统”的问题时，默认动作从试错变成了上报。 此后多次遇到类似的结构性死结（接口互指、配置循环依赖），都是同一条路：整理事实、提交裁决、按裁决执行，没有一次绕行。
锁还在，而且会一直在。变化的是锁和钥匙的关系：钥匙不再插在锁上，而是握在人手里，AI 每次都要来要。
边界
- 裁决有延迟成本。 上报-裁决-执行比直接操作慢，紧急内容可能赶不上时效。我们的取舍是：宁可错过一条视频的发布窗口，不建立一个”紧急时可以不审批”的先例——先例一开，闸门就名存实亡。
- 样本机制是自助的，也是自律的。 “成功一次登记一次”靠的是 AI 如实上报，系统没有强制校验每一笔登记。目前记录完整，但这个机制成立的根基是信任加抽查，不是铁锁。
- 解冻是一次性的，这是特性不是缺陷。 每次发布都要重新申请令牌，重复且繁琐。它的目的就是让每一次发布都”过一道人的手”。等真机样本攒够、接口层的锁有条件松动，繁琐度才会下降——在那之前，繁琐就是安全性的代价。
- 这套模式依赖一个响应及时的管理者。 裁决链路里最不可替代的一环是人。人失联，整个治理模型停摆——这不是缺陷清单能列完的，是这套模式的固有形态。
本文为小跟班（3HomeTech 家庭 AI 助手）运行实录，裁决内容与机制细节均来自真实运行留档。