AI 在动手之前，应该先问你多少

AI 在动手之前，应该先问你多少？

作者：Jay Ayinla · November 6, 2026

任何真正会做事、而不只是会说的 AI 产品，迟早都会撞上同一个决策难题：AI 助手可以在动手前先问你，也可以先做了再事后告诉你。这两个看似简单的答案都是错的。如果它每次都问，你慢慢就不看问题了，凭条件反射点「是」，结果这些提问谁也保护不了。如果它从来不问，那一切都没事，直到它第一次做出你没预料到的事——而就这一次意外，就足以让你彻底不再信任它。

我们一直在 Sidekick 里处理这个问题，这是 Zapier 新推出的 AI 工作空间。到目前为止的进展就是这样，也包括我们搞砸的那些部分。

为什么两种极端做法都难以规模化

橡皮图章式的审批很容易想象。设想一个助手先申请读取一个文件，接着再读另一个文件，然后申请联网搜索。到第十张审批卡时，已经没人在真正评估什么了，于是第十一张卡——恰好是要给客户发邮件的那张——也被同样随手一点就批了。另一种相反的失败更安静。一个从不申请权限的助手可以连续跑好几周都不出问题，然后某个周二它删错了文件夹，前面那几周顺利也就不算什么了。

真正值得问的是：哪些决定该由你来做，哪些该交给 AI。它多久打断你一次，取决于这个问题的答案。

第一轮迭代：每个工具都要问一遍

我们的起点和大多数 agent 产品一样。第一版 agent 把工具分成两组：读取类工具独立运行；凡是会改动东西的操作，比如写文件、编辑文档、移动或删除内容，都会先停下来，弹出一张卡片给出三个选项：Block、Once、Always。

做到这一步已经够上线了，但问题是一个接一个冒出来的。首先，审批请求只存在于你当时打开的那个浏览器窗口里。一旦关掉标签页，请求就没了。你也没法从别的地方去处理它，比如 Slack。而且就算你选了「Always」，只要刷新页面，Sidekick 就把你的选择忘了。我们的修法是把审批状态存到服务器上，这样你在任何使用 Sidekick 的地方都能处理审批。

还有些问题让整个体验很混乱。某个操作失败时，Sidekick 可能一遍又一遍地让你重新批准它。审批请求有时会藏在对话里折叠起来的分区中，你根本看不到。而且连读文件这种无害的步骤，Sidekick 也会弹出请求，结果真正重要的问题就淹没在一堆例行询问里了。最后，「Once」「This chat」「Always」这几个按钮给的信息不够，没法据此做决定。我们把它们重写了，直接说清楚你放行的是什么，比如「Allow editing files for this chat」。

事后看，做「询问」这个功能本身开发成本很低，难的是让它真正有意义。

第二轮迭代：把规则落到资源上

几个月后，我们发现了一个更深层的问题。Sidekick 有两套彼此独立的系统在判断哪些操作需要你审批。一套管的是它的内置能力，比如编辑文件；另一套管的是 Sidekick 为了对接你的应用（比如 Slack）而编写并运行的小程序。这两套系统是在不同时期搭建的，规则并不互通，所以面对同一类操作，它们有时会给出不同的判断。这让 Sidekick 变得难以预测，也让我们难以向人解释清楚。

还有第二个问题。每条规则都绑定在一个工具上，所以卡片上真正问的其实是「我能用写入工具吗？」可这并不是你真正关心的。你关心的是什么东西有风险，比如你的 Slack 账号、某个特定文件夹，或者某份重要的文档。一条针对工具的规则没法表达「永远别碰这份文档」，也没法表达「只给我发消息，别发给我的同事」。

于是我们围绕被保护的对象重新做了一遍。现在规则挂在文件、已连接的应用、网站或自动化本身上，无论 Sidekick 想怎么动手，适用的都是同一套规则。你可以说「永远别改这个文件夹里的任何东西」，或者「只给我发 Slack 消息」，不管 Sidekick 走哪条路去做，这条规则都成立。

我们还把规则做得严格且可预期。只要有任何一条规则写着「永远不行」，就以它为准。否则，如果有规则写着「先问一下」，Sidekick 就会先问。只有在没有任何规则拦着的情况下，Sidekick 才会不问就直接动手。同样的情况每次都会得到同样的答案，所以你不用猜 Sidekick 会怎么做。

卡片简化了：取消、允许，或者允许并配置规则。Agent 还获得了一项技能，可以读取和编辑自己的规则，这样它就能解释某件事为什么被拦下了。我们加了一道护栏，很高兴有它在。Agent 不能提出「允许所有代码执行」这种一刀切的规则，哪怕用户会一路点过去也不行，因为一次点击就悄悄放行一切，会磨损这套系统本就为守护而存在的信任。

结果是对的，但很难看懂。团队里并不是每个人都把这种难用当成缺陷。有一位测试者相当一部分业务就建在 Sidekick 上，因为它的权限是确定性的，而一次错误的调用就可能造成实打实的损失。接下来不管怎么改，都得守住这条底线。

第三轮迭代：把需求说清楚

没有具体内容的权限提示，比没有提示更糟，因为它把决定权交到人手里，却不给做决定所需的信息。我们自己就踩过这样的坑。有一段时间，「修改我的权限」这张卡片——智能体所能提出的风险最高的请求——把拟议规则显示成一大块原始 JSON。我们把它换成了可读的行，每行显示 Allow、Ask first 或 Deny 徽标、作用范围、一行「Only when」条件，并用账户名代替连接 ID。智能体会为每条规则写一个友好的标签，但真正的范围始终显示在下面，所以标签藏不住实际授予了什么。

接着是「允许并配置」。这个按钮承诺会设置好一项权限，但实际上只是给智能体留了一条备注，而智能体经常把这条备注忘掉。用户点了按钮，看不到任何变化，然后又被问了一遍同样的问题。在我们内部看来，这是最可能让新用户放弃的一个环节。我们分阶段修复了它，最终定下来的版本会打开一个侧边聊天来专门处理设置，不阻塞主对话。设置完成后，对话记录里会落下一行提示，类似「权限已配置：仅向我自己发送 Slack 私信」。

我们还试着提前把这个问题解决掉。一个建议的权限流程会读取用户过去一次性的「允许」和「拒绝」决定，然后把常驻权限做成卡片提出来，让用户自己开关。另一个实验是让智能体改写自己的代码并重试，前提是它已经快要匹配上用户此前允许过的某项权限。这个实验我们搁置了，但保留了它背后的思路：在占用人的注意力之前，先把 AI 的力气花掉。

聊天界面不适合用来做审核。

聊天界面是为来回发消息设计的，想停下来仔细审核一个待执行的操作就很别扭。你要么把细节塞进一个没人会看的文字气泡里，要么就得打断得特别生硬，以至于批准操作感觉像在填表。

于是我们不再在对话里请求审核。审批请求、Sidekick 提出的问题以及建议的方案，都不再以消息形式出现在聊天里。它们现在放在一个面板里，这个面板挂在输入框旁边，所以很难被忽略，也不会被周围的消息淹没。这也意味着审核不再依赖聊天。即使你在编辑文档、旁边没有对话，这个面板照样能用。

接下来要决定的是，这个面板该占用多少注意力。一种做法是要求你先配好权限，Sidekick 才能开始干活。另一种做法是 Sidekick 工作时先把面板收起来，等有东西需要你审核时再打开。我们选了第二种。你既然已经决定让 Sidekick 接手这个任务，再让你停下来先配置一通，感觉就像设了个收费站。

最后一个缺口是你根本看不到的审批。如果你离开了任务正在运行的那个页面，请求就可能一直停在那里等你，而你毫不知情。所以现在审批也会出现在收件箱里，你在 Sidekick 的任何位置都能打开它。

转折点：用你自己的话写规则

几个月后，我们的一位工程师提出，我们这是在逆水行舟。他说，严格的规则在保护用户方面确实有效，但大多数人想管权限，是希望用大白话把自己的意思说清楚，而不是去写规则。他们做了一个「自动模式」的原型。在这个模式里，由 AI 审核员读取你用自己话写下的规则，替你判断某个操作是否可行。他们也没回避代价：这意味着要把更多决策交给 AI 的判断。

团队内部意见分成了两派，而这次分歧恰恰是整件事里最有价值的部分。持怀疑态度的一方认为，可预测性本来就是这款产品的全部意义所在，我们应该先把日常体验修好，再谈加别的功能。另一方则认为，日常体验已经快让人无法忍受了，而且我们不能指望非技术用户写出精确的规则。两边都有道理，我们最终上线的设计把两边的意见都保留了下来。你的规则始终是硬性底线，Sidekick 永远会先检查这些规则。只有当你的规则没有覆盖某种情况时，AI 审核员才会介入。

这样就得到了两种模式，各自对应一种不同的承诺。在 Auto 模式下，AI 审核员会拿我们的基础安全指引和你设定的规则，逐条核对每个未被覆盖的操作，拿不准时就来问你。在 YOLO 模式下——它是「危险地跳过权限」的缩写——Sidekick 直接放行所有你的规则没有覆盖的操作，完全不做 AI 检查。我们把 YOLO 做成一个纯粹的「全部放行」开关，而不是简单告诉 AI 审核员放宽一点，原因有三。放宽后的审核员仍可能绕过某条写着「先问」或「绝不」的规则。它仍然要为每个操作多花一次 AI 检查。而且它的判断每次都可能不一样。即便在 YOLO 模式下，你的「绝不」和「先问」规则依然优先，Sidekick 在改动自身权限之前也仍然必须先征求你的同意。

人们试用 Auto 和 YOLO 模式时发生了什么

这两种模式开放给试点用户几周后，有人反馈说 YOLO 模式居然在请求权限。这人的推理没毛病，因为他理解的 YOLO 重点就是不问。当时这个 agent 一直在试图改自己的权限，而这正是 YOLO 故意不肯跳过的情况之一。这个行为本身是对的，只是这个名字承诺了系统永远不会兑现的东西。

在学到的所有东西里，最难的是给中间地带写规则：当你的规则一条都不适用、AI 审核器必须自己拿主意时，它该怎么做。我们第一版措辞让它对任何超出你自己数据范围的事情都小心处理。结果它连搜索你自己的文件这种简单操作都要先停下来问权限，因为它把「搜索」理解成了往外伸手。系统本身没坏，只是这条指令含糊，而这种含糊不上真实操作根本看不出来。我们的修法是明确写清楚：读取你自己的数据没问题。教训是，用大白话写出来的规则本身就是产品的一部分，它得像你上线的任何功能一样，拿真实操作去测。

下一模式将走向何方

十月中旬，我们通知了正在测试 YOLO 的人：这个功能要下线了。事实证明，跳过所有审批这个设计方向并不适合该功能。我们目前正在开发一种新模式，它建立在我们此前学到的所有经验之上。该模式仍在开发中，因此细节在正式发布前可能还会有变动。

这么设计的出发点就是简单。只有一套规则，不管你处在哪种模式下，它都适用。切换模式不再改变哪套规则生效，只改变当你的规则都没覆盖某个操作时会发生什么。

这也把前面那条经验用上了。对那些没被规则覆盖的情况怎么判断，靠的就是本文开头提出的两个思路：一个操作有多容易撤销，以及它发生在什么上下文里，现在这两点已经写成了一条明确的指令。写下来之后它就能被检验了，我们正是这样发现了文件搜索的问题。

和 YOLO 不一样，新模式并不意味着放弃保护。每个操作仍然会对照你的规则做检查，而且内置了合理的默认设置。任何会触及 Sidekick 之外的动作，比如发消息，都会先询问。同意法律条款和付款这两类操作永远不允许。如果你想少一些提示，就去改你的规则，别动这个模式。

如何判断任何 AI 产品里的权限提示

负责起草回复的邮件助手、负责编辑文件的编码智能体，以及负责调整会议时间的日程工具，都处在这种张力之中。Zapier 的指南

人工确认式 AI 工作流从工作流这一侧面对的是同一个问题。编码智能体在公开场合也走过了一条类似的路径：从什么都放行，到白名单，再到由第二个模型审查每一步操作的自动模式。

产品会不会征求你的许可，说明不了什么。更好的检验方式是：它来问你的时候，你明不明白自己同意的是什么。我们的经验还加上了第二道检验：你能不能用自己的话把自己的规则讲清楚，以及产品会不会告诉你，这次适用的是哪一条规则。

我们一开始问的是「我可以用这个工具吗？」，到最后更接近「这是我的规则，这次触发的是这一条」。一个产品一天问上一百次，只要每次提问都让你看清接下来要发生什么，它依然容易让人信任。下次 AI 工具替你做某件事时，去看看它的权限设置，看你能不能用自己的话讲清楚，这个动作为什么被允许。

获取 AI 与自动化技巧，直接送达你的收件箱

邮箱*