计划的审阅与编辑

在建这块界面之前，先给这笔交易定价。

做计划审阅的动机是站得住的，也有充分记载：逐动作的关卡会造成确认疲劳，而疲劳会把关卡磨成一道形式——这正是审批与确认体验详细梳理过的机制。把决定抬到计划这一层是显而易见的修法。它也是一笔交易，而其中有一项没人会写到白板上。

把两边的算术都做一遍。一个十二步的任务，每步一道关卡，代价是用户被打断十二次，而每一次都带着一份完全确定的载荷：那个实际的文件、那个实际的收件人、那个实际的金额。同一个任务放在一次计划批准之后，代价是被打断一次，带着十二个意图。打断少了十一次。而每个决定所含的信息量，从「将被写入的确切字节」降到了「一句关于大概会写入什么的话」。

这里有一个问题，能定下你的计划到底是否可审阅：在这份计划里，点出一个这样的步骤——在它前一步跑完之前，它的参数就已经完全确定了。对于一份「先读数据库再更新若干行」、或者「先搜仓库再改文件」的计划，诚实的答案通常是：第一步之后一个也没有。往下的一切都由一个尚不存在的结果来参数化。这不是你规划器的毛病——这正是先规划再执行的用处。但这意味着计划承载不了那次批准，因为被批准的那样东西并不在它里面。

「可编辑」的含义得比一个文本框更多，而那次编辑得活过重新规划。

只读的计划会教用户略读。一份可编辑的计划挣得到注意力，因为读者有了去看的理由——而那个理由必须是：改动会留下。四种编辑手段几乎覆盖了用户真正想要的全部，按被想要的频率从高到低排：

• 删掉一步。遥遥领先的最常见编辑，也是用户最常出于智能体推断不出的理由而想做的那一种——这步是别人的活儿、或者昨天已经做过、或者它碰的那个系统正在迁移当中。
• 给一步加约束。不是「别搜」，而是「只搜 packages/api」。这正是用户那些未被表达出来的上下文进入系统的地方，而它比任何量级的提示词工程都更值钱，因为它专属于这一次运行。
• 钉住一个取值。用户知道目标分支、成本中心、收件人是谁。让他们在计划里把它定死，就省掉了后头一次澄清提问，以及一整类的猜错——关于何时该问、何时该假设，见澄清式提问。
• 重排顺序。很少需要，而且照办的代价很高，因为顺序通常编码着一条用户看不见的数据依赖。把它放在最后提供，而且要带着解释拒绝，而不是悄悄重排。

现在说决定这一切是否当真的那部分：智能体会重新规划。总会有什么东西回来得不一样，于是计划在运行中途被重新生成。如果用户删掉的那一步又冒出来了，或者他们的约束因为只活在计划对象里、而不是活在指令里而被丢掉了，那你就教会了他们：这道控制是装饰品——而这一课会推广到你产品里的每一道控制上去。编辑必须被从计划里提升出来、放进这次运行的常设约束里，让规划器在每一次重新生成时都重新读到它们。一次删除是一条禁令，不是一个 diff。

把计划所做的那两个承诺分开，因为用户只读其中一个。

一份计划默默断言了两件不同的事，而界面几乎总是展示头一件，同时用户正在给第二件定价。

• 作用域——这次运行会碰到的那一套系统、文件、记录与人。这就是可触达集合，也正是任务作用域主张你该明确说出来、而不该让读者从一串动词里自行推断的那样东西。
• 自主度——这些步骤里，哪些会回来问、哪些不会。用户压倒性地假定，凡是要紧的事都会再问他们一次。而大多数计划界面并没有做出这样的承诺，它们背后的大多数智能体也没有守住这样一条。

把两者都做成逐步可读。一个三值标记就够了——auto、ask、ask-with-payload——而要紧的是第三个，因为它正是那条承诺：在那件不可逆的事发生之前，实际的参数会被摊出来看。然后把汇总值摆到台面上，因为它是用户真正想要、却没人去显示的那个数：这份计划有九步，会打断你两次。一个知道自己会被问两次的用户，会把计划当掌舵来读，然后继续过他的一天。一个不知道的用户会把它当合约来读，而且读错了。

哪些步骤拿哪个标记，这是个后果问题、不是个「听起来像不像」的问题，而分级的做法早已梳理清楚：按可逆性与爆炸半径来设关卡，不按动词听着有多戏剧性。撤销与可逆性是这里的输入——一个你能干净撤销的步骤不需要 ask，而一个你撤不回来的步骤，不管看着多日常，都绝不该是 auto。

计划会漂移。把 diff 摊出来，而只在这个 diff 越了线时才重新问。

第三步返回了一个意外，规划器重新生成，于是这次运行现在执行的是一份用户从没见过的计划。这正是那个「让计划批准比不批准更糟」的失效模式，因为用户相信自己审过了什么，而他审过的那件工件已经不存在了。每一次批准都是对一个早已挪动过的世界的断言——通论见检查时刻到使用时刻，而一块计划界面正是大多数产品所交付的、最长的那个这种窗口。

修法是一份带重问规则的计划 diff，而那条规则必须是机械的，否则它活不过一次赶工期。

• 把批准过的那份计划当作工件留着，而不是当作一次渲染。你没法去 diff 一个你重新生成过的字符串。把计划存成带作用域标注的结构化步骤，这样「这个变了吗」才是一次计算、而不是一次判断。
• 当 diff 新增了一个系统、放宽了作用域、或加进了一个不可逆步骤时，就重新问。三个条件，都能用代码去查。其余的一切——重排、重试、一个结果证明没必要的步骤——都在时间线里展示出来，而不停下这次运行。
• 把漂移展示在用户本来就在的地方。运行视图上一条写着「计划变了：新增一个系统」的横幅会被读到。一封邮件不会；而一个在他正切到另一个标签页时弹出来的模态框，本身就是一个打断问题。
• 把漂移数出来，并在事后展示。「这次运行执行了你批准的那九步中的八步，外加第四步时新增的两步」是一份诚实的运行后摘要，而它正是那句能校准「下一份计划值不值得读」的话。

四种情形里，计划界面是个错误的产品决定。

计划审阅已经变成一项默认配置，这意味着它现在正被加到那些并不因此受益的智能体上。下面每一种，都是这块界面的代价高于其回报的情形。

• 任务比计划还短。如果生成并读完这份计划所花的墙上时间比执行它还多，那你建的是一道减速带。少于大约三步，就跳过它：跑起来，然后给一个撤销。
• 这次运行是只读的。没有任何不可逆之事，所以没有什么要授权，而计划仅剩的那份活儿是掌舵——而一个做得好的流式视图做得更好，还不带关卡。把这块界面留给有副作用的运行。
• 用户评估不了这份计划。一份引用了六个内部服务的计划，对一个只认得其中四个的人来说是不可审阅的；而照旧去问，就是在制造一枚橡皮图章，同时把问责转移给最没能力承担它的那个人。这和智能体产出的复核队列里「98% 通过率的复核队列是一道坏掉的控制」是同一道算术。诚实的答案是一个更窄的智能体，不是一份更长的计划。
• 任务在不变地重复。如果每个星期二的计划都一样，那你是在要一个人去重新批准一套流程。把它提升为一套保存下来、带版本的流程，只在它变更时审阅一次——这正是用户自撰技能与规格驱动的智能体开发从两头伸手去抓的同一样东西。

而在它确实站得住脚的地方，它挣得的是双份：计划是整次运行里纠正一次误解最便宜的那个点，而它也是随时间抬高自主度上限的天然位置——因为「编辑率随信任积累而下降」恰恰就是渐进式自主所要的那种证据。

给三个数字装上仪表，并且要舍得把这块界面删掉。

计划审阅异乎寻常地容易评估，因为用户的行为会直接告诉你这块界面有没有在起作用。三个比率，每一个都挂着一项行动。

• 编辑率。用户在开始之前改动计划的比例。这就是这个功能的全部正当理由所在：如果它贴近零，那用户是在不读就批准，而你是用你撤掉的那十二道关卡换来了一枚橡皮图章。低于百分之几，要么是计划真的对——那就别再展示它，把关卡留在不可逆的步骤上——要么是它读不懂，而这两者你可以用停留时长区分开。
• 批准后重新规划率。计划在被批准之后发生实质变更的频率。高比率意味着规划器在计划阶段就是在猜，于是那次审阅是演戏；修法是往前规划得更短，而不是规划得更好。一个发出三个有把握的步骤、然后重新规划的规划器，比一个发出九个推测性步骤的更诚实。
• 完成后干预率。一份计划被批准之后的撤销、回滚与道歉。这是唯一一个能告诉你「计划批准到底有没有保护到谁」的数字，也是团队不会把它回连到计划界面上的那一个。如果它在你上线计划审阅之后没有下降，那这块界面就不是一道控制。

三个都按用户分段，因为汇总值会藏起那个要紧的模式：新用户会编辑计划，老手不会，而跑那些后果重大的任务的恰是老手。一个「保护价值恰好随着利害升高而衰减」的功能，需要把关卡留在下游——这正是本页从开头起一直在做的那个论证。