L2.15.1execute-by-assumption设计研究
直接假设一种解释并执行比追问快，但会放大误解的代价
别名: 径直执行 · 默认一种解释 · assume-and-run
概念解释
用户说「订个位子」。系统按两人、今晚七点、附近那家店直接订完，因为这是最常见的解释。对话少了一轮，错的时候代价从「再问一句」变成「改订单、道歉、可能付取消费」。按假设执行（execute-by-assumption）赢的是时延，输的是误解被写进世界之后的清理。快，是因为跳过了共同注意；贵，是因为跳过的那一步正是发现走错的机会。
这条不讨论该不该问、问多少。它只钉住这个交换：把解释权从对话里拿走，误解的成本就从语言层搬到世界层。
机制
歧义在语言里是正常的。人与人靠下一轮修正来便宜地收口；系统若把第一解释当成已接地的意图并调用工具，修正必须走工具的反操作。反操作往往不对称：订位可以取消，发出的邮件、对外的付款、已经通知的第三人，反操作要么没有，要么丢人。
默认解释还带频率偏见。最常见的解释对群体最优，对这次用户可能最错（八人聚餐被订成两人）。系统越「懂行」，越敢跳过追问，越容易把高频脚本套到低频情境上。用户看到的是果断，不是假设。
怎么研究
选带工具后果的任务（订位、发信、改权限），给有两种合法解释的指令。条件：先问再做 / 按众数解释直接做。因变量：完成时间、错误执行率、错误之后的恢复成本（步骤数、是否不可逆）、用户在错误发生前是否意识到系统做了假设。
恢复成本必须单独测。只报「任务成功」会把直接执行算赢——成功里混着「碰巧猜对」。把猜对和问清分开，才能看见放大的那一截代价。
边界
只读、可随时换一条的生成（再写一句口号）几乎没有世界层代价，按假设执行是合理默认。用户刚刚用同一解释成功过、且间隔很短，沿用上次解释接近共同注意，不算盲目假设。高风险领域即使解释看起来唯一，也应把假设说出来再做；看起来唯一不等于真的唯一。
怎么落地
- 凡是会碰到世界边界的动作（对外发送、付款、改别人的数据），禁止把未确认的解释直接送进工具。先把将要执行的解释摊开。
- 纯生成、可一键换掉的结果，允许按众数解释先做，但要在结果旁用一句人话标出假设，便于发现走错。
- 不要把果断当成能力展示。少一轮对话省下的秒，对不上一次错误订位。
- 验证：用同一句「订个位子」跑两个账号画像（二人晚餐 / 八人聚餐）。直接执行条件下，至少有一个画像会订错；记录改订和取消的步骤。改成先摊开解释后，两个画像都应在执行前看到人数。看不到人数却已经产生订单，就是假设被写进了世界。