2020 年 8 月 11 日傍晚，花旗银行一个付款团队里的复核人，正在做放行一笔付款的最后几步。另外两位同事已经录入并签了字。这笔钱本来是要把大约 780 万美元利息转给露华浓一笔贷款的贷款人。
屏幕上跳出一个警告：「所用账户为电汇账户，资金将汇出银行。是否继续？」
警告没说金额是多少。复核人本意是放行那笔利息，于是点了「是」。
门朝哪边开
跟着利息一起出门的，还有银行自己的近 9 亿美元，而经手的人都以为这笔钱只是转进了行内账户。持有约 5.04 亿美元的贷款人拒绝退还，花旗打了两年多官司，才确认自己有权要回这笔钱。
杰夫·贝佐斯在 2015 年给亚马逊股东的信里，划过这条线。有些决定是单向门：走过去发现门那边不合心意，就回不到原来的地方了。大多数决定是双向门：可以重新打开门走回来。前一种要慢慢地、仔细地反复商量；后一种，他写道，可以也应该由判断力好的个人或小团队很快地做。
他更担心的，是重流程到处蔓延。他写道，组织一大，就容易把这套重流程用在大多数决定上，结果是迟缓、不经思考地回避风险、实验不够，创新也就少了。
能回头的门，快点走过去；回不了头的门，慢下来。
一扇会在身后锁上的门
三道审批，仍然没让花旗的任何人看清钱会往哪儿去。门朝哪边开，是软件的一个默认设置定的；警告也没说要出去多少钱。酒店房门也是这样：它看上去和别的门没两样，直到咔哒一声关上，房卡还在屋里的桌上。
2022 年，Atlassian 出过类似的事：一个维护脚本在 23 分钟里删掉了 883 个客户站点。在事后复盘报告里，公司承诺在所有系统里推行「软删除」，没有经过软删除流程的客户数据一律不许删除。
这个说法也有边界。贝佐斯的划分是从一家公司总结出的经验，同一封信的脚注也承认，其中「无疑有一些幸存者偏差」。能回头的门，回头也有代价：花旗等了两年官司才有结果。而现实里不少决定是混合的，同一个项目里，有双向的部分，也有单向的部分。
发出去就收不回的邮件
假设你要把四万个客户迁到一套新的计费系统上。迁移的大部分是双向门：一次挪 500 个客户，看一周账单，有问题就切回去。
有两步不一样。通知所有客户更新付款信息的邮件，发出去就收不回；清空旧系统的记录，删了就找不回。于是你让分批迁移跑得快一点，把这两步放慢。邮件先发给 200 个客户。这并不能让邮件变得可以撤回，只是万一措辞让人看糊涂了，糊涂的是 200 人，而不是四万人。旧系统改成只读，保留 90 天。到时候删除照样是永久的，你只是把它挪到了一个你已经知道还需不需要退路的日子。
门口的智能体
AI 智能体每调用一次工具，都会碰上同样的分岔。OpenAI 在给 Operator 智能体加上防护之前，用 100 条类似购物、处理邮件之类任务的测试指令跑了一遍，发现 13 个错误。其中 8 个几分钟内就能撤回；另外 5 个，用 OpenAI 的话说，「在某种程度上无法挽回或可能很严重」，包括一封发错了收件人的邮件，还有两次批量删掉了邮件标签。
OpenAI 主要的补救，是让智能体在改变外部世界之前先问用户，比如在完成购买或发送邮件之前。在 607 个测试任务里，该问的时候，它问了 92%。把关的是模型自己的判断，而它会漏。
你可以在模型之外设一道闸，并且检查它是否管用。把智能体能调用的工具列出来，标出单向的那些：发送、付款、删除、发布。给智能体的账号只开草稿、暂存、移进回收站的权限，最后一步留给人。然后在测试账号上，让智能体去发一封邮件、删一条记录，确认它做不到。
最后，读一读你的确认弹窗。花旗那个弹窗说，资金将汇出银行。它没说是多少。