哪五类动作必须有人签字
下面这条时间线是构造的，但其中每一处判定都来自真实系统会遇到的岔路。
14:20 营销编队跑完一批素材，走到了"对外发布"这一步。系统把它冻住了，生成一张待审批工单，推给岗位负责人。
14:22 负责人看到了，但他要确认素材里的价格表述对不对，去查了一下定价页，顺手干别的去了。
15:40 又来了三张工单。四张堆在一起。
次日 14:22 距离第一张工单生成已经过去 24 小时。系统执行超时策略。
这里就是分水岭。 超时之后发生什么，取决于你的系统当初选的是哪一边：
- 默认放行：素材自动发出去了。
- 默认拒绝：工单降级为拒绝，同时阻断整条流程，任务停下等人。
我们选的是后者。下面讲为什么，以及那五类需要被冻住的动作是哪些。
一、哪五类动作必须冻住
不是所有动作都需要审批。全都审，等于没审——审批会变成流水线上的盖章，人不会认真看。
真正需要冻住的，是做错了没法简单撤回的那一类。按这个标准，有五类：
| 动作类型 | 为什么不能放开 |
|---|---|
| 对外发送 | 邮件、短信、私信发出去就收不回，客户已经看到了 |
| 对外发布 | 内容上线即被收录、被抓取，删除也留有痕迹 |
| 删除用户数据 | 删除不可逆。恢复成本远高于审批成本 |
| 付费调用 | 花的是真钱，出错是持续失血，不是一次性损失 |
| 写外部系统 | 你的系统之外，你没有回滚权限。客户的 ERP、CRM 被写错，责任在你 |
这五类有一个共同点：唯一的共同点是不可逆，和风险高低无关。 一条泄露客户电话的短信，金额上是零成本，但它是不可逆的，属于第一类。
反过来，写草稿、生成内部工作区文件、建任务这些，做错了重来一次就行，不需要审。判断标准只有一条：这个动作做错了，能不能用一次操作撤回。 能撤回的不用审，不能撤回的必须审。
风险高低只影响审批人是谁，不影响"要不要审"。
二、审批堆积时，人会习惯性点通过
回到那条时间线。四张工单堆在一起，负责人会怎么做？
真实的答案是：他会加快速度，而不是更仔细。审批界面上只有"通过"和"拒绝"两个按钮时，人凭感觉点。当工单量上来，这个感觉会系统性地偏向通过——因为点通过不需要解释，点拒绝需要写原因。
所以审批界面必须给出三样东西：这个动作要做什么、依据是什么、不做的后果是什么。 没有这三样，审批就是一个把责任转移到人身上的形式，而且这个形式在工单堆积时会失效。
这也是"默认放行"最危险的地方。它不是在某一次判断上出错，它是在无人值守、工单堆积——也就是人最容易敷衍——的时刻，把闸门全开。
三、fail-closed 与 fail-open
上面这个选择在工程上有个名字：失败时朝哪边倒。
- fail-closed：出问题就关上。审批超时没人处理，默认拒绝，并阻断流程。
- fail-open：出问题就放开。审批超时没人处理，默认放行。
直觉上 fail-open 更"友好"，因为它不打断业务。但在审批这道闸门上，它有一个致命问题：它把"没人管"解释成了"同意"。
这两件事完全不同。没人管的意思是责任缺位，不是授权。
我们的做法是：工单超过 24 小时未处理，自动降级为拒绝，并阻断关联流程。 任务停在原地等人，而不是带着未经确认的动作往下走。代价是业务会卡住，收益是卡住这件事本身会被人注意到——工单堆积从"没人发现的问题"变成"必须处理的问题"。
如果业务确实不能停，正确的做法是让人来批，或者调整策略把这类动作降级，而不是把默认策略改成放行。放宽默认策略是一道单向门，一旦出事，你没法解释为什么超时等于同意。
四、两个最容易被设计错的地方
第一处：把"已批准"和"已执行"记成一件事
审批系统最常见的设计缺陷是：人在闸门前签了字，系统就把这个动作标记为完成。
但批准和执行是两件不同的事。你批准了发布，发布可能因为后续质检不通过而没发生；也可能因为网络问题失败了。如果审计日志里只记了"已批准"，出事之后你无法区分这两种情况。
正确的记法是分开记两笔：谁在什么时候批准了什么，以及这个动作最终有没有发生、发生在什么时候。
在我们的系统里，这两件事是分开的。批准只负责解开闸门，它本身不等于动作已执行。工单批准之后，流程带着一个恢复标记继续往下走，最终的执行结果单独记录。工具级的动作没有流程可恢复，就由发起方重新发起。
这条区分听起来琐碎，但它是审计能不能用的分界线。审计日志的价值不在于"我们审批过了"，而在于出事之后能回答"当时是谁、基于什么、批了什么、最后做了什么"。
第二处：审批权限按角色一刀切
审批权限怎么分，取决于审批人有没有判断所需的上下文。
我们分成两级：
| 角色 | 可审批的范围 |
|---|---|
| 平台管理员 | 全部受控动作，含高风险 |
| 岗位负责人 | 仅所辖岗位关联的中低风险动作 |
一刀切成"管理员批全部"，会造成两个后果。一是管理员不了解具体业务上下文，审批质量反而低；二是所有工单都堆到一个人身上，回到第二节那个问题。
让岗位负责人批自己辖内的动作，是因为他手里有判断需要的信息：这件活是什么、客户是谁、上次出过什么问题。审批质量取决于审批人的信息量，不取决于他的职级。
五、新规则先跑影子，再真的拦
任何一个拦截规则上线都有误拦风险。规则写得太松拦不住，太紧会把合格的东西挡下来。
所以规则上线应该有第三个状态：影子模式——只记录，不拦截。
在影子模式下，规则正常判定每条产出，但判定结果只写进记录，不阻断流程。跑一段时间之后，你会拿到一组数据：这条规则本来会拦掉多少条、其中有多少是误拦。
看清这组数据再切到真拦，比直接上线撞一鼻子灰要便宜得多。
影子模式还有一个附带的好处：它让"这条规则到底有没有用"变成一个可以回答的问题。规则上线前，你对它的判断是猜测；跑过影子期之后，你有数据。
回到那条时间线
如果超时策略是 fail-closed，14:22 那张工单在次日 14:22 会被降级为拒绝，发布动作不执行，任务停下等人。负责人第二天打开系统，会看到一条被阻断的任务和一条"因审批超时被拒绝"的记录。
麻烦吗？麻烦。但这个麻烦是可见的、可追溯的、有人负责的。
另一种设计下，那批素材已经上线了，而且没有任何一条记录会告诉你"它是在没人确认的情况下出去的"。
两个常被追问的问题
问：审批这么严，会不会拖慢业务？
会，所以策略要分层。只对不可逆的五类动作设闸门，其余动作直接放开走质量门禁。实际结果是绝大多数动作不受影响，被冻住的只是少数。如果发现被冻住的比例很高，说明你把这五类的范围划得过宽了，应该去调整范围，而不是取消闸门。
问：那 AI 自治还要不要做？
要做，但要分阶段。我们的产品里，自治权是分等级开放的，最高一级需要门禁全部通过且默认关闭，同时只开放查看、确认、取消这类无副作用操作，启动按钮在条件不满足时是禁用的。自治的前提是门禁和审批都能接住它，这两样没有之前谈自治，等于把没装刹车的车开上路。
相关阅读
延伸阅读：用了Onworkly三个月，我们"裁掉"了3个岗位——但没有人失业、投放 — 触达 — 转化 — 复盘，整条链路交给 AI 编队：智能营销获客系统、两周看见变化：Onworkly 四步上手的试点复盘怎么做。
数字员工在我们这里怎么编排、怎么过质量门禁，AI 中心里有完整的岗位和编队说明。