为什么一个简单的AI功能，开十场会还是无法上线？丨FDE重新理解决策权

今天聊一个不少AI团队都遇到的典型场景。

一个客服Agent已经通过测试了。它草拟的回复，在抽样评测里质量稳定，业务部门那边等着上线，因为客服团队的工单积压已经快扛不住了。

结果呢？上线评审会上，安全部门担心用户数据在调用过程中泄露。法务担心Agent在回复里做出没有授权的承诺——比如随口答应一个退款期限。品牌团队担心语气失控，在客诉场景里说错话。IT担心新组件影响主系统稳定性。每个部门派来的人，都带着自己的专业判断和真实的风险认知。

然后呢？每一轮评审会议都会至少新增一项验证要求——毕竟，增加要求不需要担责。

第八场评审会的时候，模型版本更新了。之前跑的那批测试证据，全部失效，需要重做。

客服团队实在等不及了，几个组长开始自己在浏览器里用外部工具处理工单——没有日志，没有审计，没有任何治理。一个原本要被管起来的风险，变成了一个完全看不见的风险。

十场会开完了，仍然没有任何一场会试着回答这三个问题：

---

先承认：多方参与不是官僚主义

面对这种局面，最容易得出的结论是"流程太重、会议太多，应该精简"。

但安全、法务、品牌、IT的担心，都是真实的风险控制。一个Agent直接面对客户说话，它确实可能泄露数据、确实可能做出有法律效力的承诺、确实可能砸掉品牌调性。把这些部门排除在外，换来的不是效率，是一次迟早会发生的事故。

更重要的一点是：

业务知道客户要什么，但不知道数据在调用链路里怎么流转；安全知道链路风险，但不判断不了一句回复在法律上算不算承诺；法务懂承诺的边界，但读不懂评测指标意味着什么。风险横跨准确性、隐私、安全、合规、品牌和业务结果，每个人手里都只有一块拼图。

所以把人拉齐，是对的。组织的默认解释——"共识还不充分""风险信息还不完整""再拉一轮相关方""再测一轮大家就放心了"——在这个前提下，听起来非常合理。

但是，

。你可以把泄露风险从"可能"降到"极低"，但降不到零；你可以把错误承诺的概率压到千分之一，但压不到零。如果组织的隐含标准是"等所有人都放心了再上"，那么这个标准就不可能被满足。等待，于是变成了一种无法自我终止的状态。

---

每个人都能拦住，但不必给出决定

——只要说一句"我这边还有顾虑"，事情就推进不下去。但与此同时，。

这两件事叠在一起，就构成了隐形的一票否决。它不需要任何人真的投反对票，甚至不需要任何人明确反对——只要每个人都保留一点顾虑，决定就永远不会发生。

这个结构之所以稳定，是因为它对每个参与者都是理性的。提出一项新要求，成本为零，收益是"我尽到了专业责任"；宣布"可以了"，成本是万一出事你要负责，收益是别人的项目上线了。在一个没有明确定义决定权的组织里，

。

有些决策慢是真的因为数据不足、法定程序未走完、技术验证还没做完——那种慢是必要的，不该被优化掉。本篇要处理的，是另一种慢：信息其实已经够了，但没有人有义务做出决定。

---

一个反直觉的参照：写清条件，也消不掉模糊

到这里会有一个自然的反应：那把条件提前写清楚不就行了？把红线、阈值、触发条件都预设好，到时候按表执行，不就快了吗？

Anthropic有一份公开的"负责任扩展策略"（Responsible Scaling Policy，简称RSP），目前更新到v3.4（2026年7月生效），核心思路正是"如果-那么"的预设条件：如果模型能力越过某个阈值，那么就必须启用对应的更严格保障措施。

经过两年多的实践，它也同时承认：

有些情况下，模型能力明显在"接近"阈值，却很难判定是否已经"确定跨过"——因为模型评估这门科学本身，还不足以给出决定性的答案。官方把这种状态称为"模糊地带"（zone of ambiguity）。

"所以组织必须明确谁在模糊中做出决定、并把依据留下来"，这是FDE从这个事实里做出的工程推论。

既然指标本身不能自动给出答案，那么"按表执行"就不可能覆盖所有情形。总会有一刻，数据摆在桌上，但数据不说话。那一刻组织要么有一个明确的人做出决定，要么就一直开会。

---

AI在这里放大了什么

上线评审，传统IT项目里也有，但AI在四个地方不太一样。

传统软件的验收是确定性的：这个功能按规格做到了没有，答案是或否。概率性系统没有这种终点，它只有"错误率降到多少"。这让"再等等看"从一种谨慎，变成了一种可以无限延长的姿态——因为永远还能再降一点。

一个只输出建议的系统，错了还有人兜底；一个直接给客户发回复、直接改工单状态的Agent，错误具有更强的不可逆性。不可逆性一高，要求参与决定的部门就更多——这是完全理性的反应，但它同时也让需要协调的权限数量上升。

审批走到一半，模型版本更新了，之前的测试证据失效。传统系统的审批对象在审批期间是静止的，AI系统不是。

前面说过，没人掌握完整拼图。这意味着"等一个人想清楚"在结构上不可行，必须靠一套接口把分散的判断归拢起来。

这四条合起来，指向一个结论：AI项目不可能等到不确定性消失再做决定。所以组织真正需要的，不是一个更长的验证流程，而是

。

---

FDE重新理解决策权

之前的文章「裁定接口设计：不是审批流程，是风险边界」处理的是

的判断交接——什么时候该由人介入、什么时候可以让系统自己走。本篇处理的是另一端：。

FDE对决策权的理解是：

同一个人，在低风险可逆的决定上可以直接拍板，在高风险不可逆的决定上只有建议权，这不矛盾。权限跟着决策的性质走，不跟着职级走。

具体要拆成五种，混在一起就会长出前面那个隐形否决：

：提供专业输入，但不决定结果。这是绝大多数参与者应该拥有的权限，它一点也不低级——高质量的输入是好决定的前提。

：只有在触发预先约定的红线时，才能直接阻断。关键在"预先约定"和"可检验"——比如"用户身份证号会进入第三方接口"，这是能被验证的事实，不是感受。

：这一条是为未被预见的风险留的。AI风险里确实存在事先枚举不出来的新型问题，如果所有否决条件都必须提前写好，组织就会为了流程完整而压掉真正的弱信号。所以任何参与者遇到重大的、未预见的风险时，都可以暂时阻断——但必须说明依据，必须自动升级到最终决定人，并且必须在限定时间内由最终决定人确认。

：有权代表组织接受剩余风险。这是最常缺失的一环——大多数卡住的项目，缺的不是分析，是没有人愿意具名说"这部分风险我承担。"

：在信息不完美时，仍然必须做出选择。这个"必须"是义务，不是特权。

五种权限分开之后，还有一条边界必须守住，否则整套东西会滑向"指定一个大领导拍板"：

注意，这不等于"所有责任都集中在同一个人身上"。在真实的组织里，最终决定人、风险所有者、业务结果负责人、法律责任主体，很可能本来就不是同一个人，硬要拧成一个，反而制造新的权责错误。要保证的是这条链

：每一项被接受的风险，都能找到一个具名的承接者；每一个承担后果的人，都有一条进入决定的通道。

---

决策接口表：把拍板的接口设计出来

FDE的工作不是替组织拍板——那既不合适，也不可持续。FDE要做的，是把拍板的接口设计出来。这张表就是交付物。

它包含：决策对象；必须提供输入的角色；每个角色可否决的

；风险接受人；最终决定人；决定截止时间；超时后的预设状态；以及决定和依据的留痕位置。

让它区别于一张审批流程图的，是背后这几条规则。

写得出触发条件的，登记为条件否决权；写不出但确实担心的，走临时止损权那条通道——可以叫停，但要说明依据并自动升级。这样做的目的，是消灭"我担心，所以永远不上线"这种既不用说明理由、也不用承担后果的中间态。

风险接受人一栏是空的时候，仍然可以开会——开的是风险识别会、信息澄清会，目的就是把风险找出来、把归属定下来。但它不能作为正式的决策会议。

低风险、可逆、小范围的，超时可以进入限时试点或自动升级；高风险、不可逆、影响外部主体的，超时必须默认不放行、或退回安全模式。

功能进入上线评审前建立这张表；范围或风险等级发生变化时重审；争议真的发生时，按表执行，而不是临时开会讨论谁说了算。

---

写在最后

一个AI功能开十场会还上不了线，通常不是因为参与的人太多，也不是因为大家不够专业。恰恰相反，每个人都很专业，每个人的顾虑都成立。问题在于，组织从来没有区分过：谁在提供意见，谁能在什么条件下否决，谁有权接受剩余风险，以及最后，谁必须做出决定。

于是每个人都拿到了一点模糊的阻拦权力，没有人承担明确的决断义务。

让每个人的专业意见以确定的方式进入决定，同时让决定真的能够发生——这两件事不冲突。

不过，就算权限已经分清楚了，还有一种更难的僵局在等着：安全说必须加密，那会让响应慢一倍；业务说响应必须快，否则客户会走；法务说数据不能出境，那意味着换掉整个方案。这一次没有人越权，也没有人拖延，每个部门的要求单独看都完全正确，而且都有依据。当正确和正确直接撞在一起，组织要靠什么决定，这次到底牺牲哪一边？