设计的基础假设变了——从确定性软件到生成式系统

假设一位设计师需要把一份几十页的用户研究报告，整理成一场面向管理层的 20 分钟汇报。

在传统软件里，他通常会先创建演示文稿，选择模板，再阅读报告、提炼结论、拆分章节、复制文字、插入图表、调整版式，最后逐页检查内容。软件提供了文本框、图表、对齐、动画和导出等能力，但“这场汇报应该讲什么、按什么顺序讲、哪些内容最重要”，主要由设计师自己判断。为了完成目标，他需要先理解软件拥有哪些功能，再把一个完整目标拆解成许多具体操作。

在生成式系统里，他可以先选中研究报告，然后告诉系统：“请把这份报告整理成一场面向管理层的 20 分钟汇报，重点保留用户问题、业务风险和三项行动建议，所有数据都要标明来源。”系统可能读取文档，提取证据，组织结构，生成页面，再把一份可以继续修改的演示文稿交给他。

序章把系统依据用户表达和当前上下文形成的临时解释，称为“意图假设”。在这个例子中，被选中的报告、用户的要求和当前工作状态都是意图信号。系统依据这些信号，暂时把“整理”解释为制作一份供管理层使用的汇报，再据此形成计划并生成内容与页面。这项假设可以驱动后续计算，但它仍然可能错，也不等于用户已经授权系统采取所有后续动作。

“意图假设”是本书用于分析产品行为的概念，不是行业通用术语，也不要求产品内部保存一个同名字段。设计师需要关注的是：系统依据哪些信号形成判断，这项判断如何影响后续计划与行动，以及用户能否看见和修正它。

两种方式服务的是同一个目标，却建立在两套不同的基础假设上。

第一套方式假设，产品团队已经提前定义好软件可以做什么，用户需要通过固定界面选择功能、安排步骤并完成操作。第二套方式则允许用户先表达目标，由系统形成意图假设，再在运行时选择能力、组织步骤并生成结果。用户可以省去一部分中间操作，但仍需要说清对象、听众、重点、限制和完成标准，并检查系统的解释是否成立。

第二种方式有明确的适用边界。对于调整一行文字的位置、输入一个确定金额、确认一项不可逆操作，固定控件往往更快、更准确，也更容易预测。生成式系统扩展了产品能够处理的问题范围，却不保证每项任务都更高效。过去必须由用户自行拆解的开放目标，现在有一部分可以交给系统参与解释。

因此，AI 带来的关键变化在于，意图翻译开始从产品发布前延伸到产品运行时。界面增加输入框、设计师是否继续画页面，都只是这项变化的表层表现。

过去，设计师和开发者先把人的目标翻译成有限的功能与流程，用户再把自己的目标翻译成点击、输入和选择。现在，模型开始进入第二次翻译：系统接收意图信号，形成可修正的意图假设，再据此选择计划、行动和结果形式。

这一章将回到设计的基础，讨论传统数字产品建立在什么条件之上。理解固定界面、确定路径和直接操控为什么成立，是判断它们今天发生何种变化的前提，也能避免把“AI 改变设计”误解为一次新的工具升级。

1.1　设计一直都在翻译人的意图

用户打开一款产品时，很少是为了使用某个按钮。

他打开购物软件，是为了买到一件适合下周出差的外套；打开图片软件，是为了让照片中的人物更突出；打开报销系统，是为了把一次出差产生的费用交给公司处理。搜索、筛选、框选、填写和提交只是达到目标的手段。

人的目标不能直接进入机器。机器需要接收到可以处理的输入，按照规则改变内部状态，再把结果反馈给人。设计长期承担的工作，就是在人的目标与机器可以执行的动作之间建立一座桥。

1.1.1　从“我想做什么”到“我应该怎样操作”

Don Norman 在《设计心理学》中把人与产品的互动描述为一个从目标到行动、再从结果回到评价的循环。人先形成目标和意图，再选择并执行动作；系统发生变化后，人还需要感知、解释并判断结果是否符合原来的目标。目标与可执行动作之间的距离，被称为“执行鸿沟”；系统状态与人的理解之间的距离，则是“评估鸿沟”。¹

对数字产品来说，界面的作用就是缩短这两段距离。

用户想买一件外套，产品用搜索框、类目、筛选器、商品卡片和购物车，把一个模糊目标变成一组可以执行的动作。用户点击“加入购物车”后，按钮状态、数量角标和价格汇总又告诉他系统发生了什么变化。

如果没有这些界面，用户就需要知道数据库怎样存放商品、系统使用什么命令查询库存、订单接口需要哪些参数。界面把技术结构隐藏起来，并提供一套更接近人类任务的表达方式。

因此，设计同时安排视觉元素与交互关系。一个按钮的名称、一组信息的顺序、一个表单的字段和一条流程的分支，都在回答同一个问题：怎样把用户想做的事，转化为系统能够识别的动作？

1.1.2　设计师和用户共同完成了两次翻译

在传统软件中，这种翻译通常分成两次。

第一次发生在产品发布前。设计师、产品经理和开发人员研究用户任务，再把这些任务拆成产品能力、页面、组件、字段和规则。团队认为用户需要按价格筛选，就设计价格区间；认为报销需要区分交通和住宿，就设计费用类型；认为一张图片需要局部修改，就提供选择、蒙版和图层。

第二次发生在产品使用时。用户理解产品提供的功能，再把自己的具体目标翻译成操作。他需要判断应该进入哪个页面、选择哪个工具、填写什么内容，并按产品规定的顺序完成任务。

这两次翻译塑造了过去几十年的数字产品。设计师决定机器向用户提供什么语言，用户学习这套语言并用它指挥机器。

一个熟练的设计师使用图像软件时，看起来几乎不需要思考，是因为许多翻译已经变成了习惯。他知道怎样建立选区，知道图层和蒙版分别解决什么问题，也知道哪个参数会影响边缘。新用户也许能用一句“把人物留下，换掉背景”说清目标，把它翻译成软件操作却需要一段学习过程。

1.1.3　意图进入了产品的运行过程

用户意图一直是设计的起点。AI 带来的变化，是意图不再只在用户研究和产品定义阶段被处理，也以意图假设的形式进入了产品的运行过程。

固定界面把意图压缩成有限选项。用户想“让这封邮件显得坚定，但不要让客户感觉被冒犯”，传统编辑器只能提供输入、删除、复制和格式调整，语气判断需要由用户自己完成。生成式系统则可以接受这段自然表达，推断用户希望保留的关系与态度，再生成一个候选版本。

机器现在可以在较大范围内参与解释“用户想做什么”。意图信号既可以是明确说出的一句话，也可以来自当前文档、选中对象和任务上下文。² 这些信号共同构成系统此刻用来计算的输入。系统先依据它们形成意图假设，再选择计划与行动；如果信号不足或相互冲突，就需要追问、缩小范围或停止。

不过，“参与解释”不等于“准确理解”。用户说“整理一下”时，系统仍然不知道他想重命名文件、生成摘要，还是重新组织项目；用户说“帮我处理”时，也没有说明系统可以只给建议，还是可以直接修改和发送。自然语言降低了表达门槛，同时也把歧义带进了系统。

因此，AI 没有消除意图翻译，而是改变了翻译的分工：设计师仍在发布前定义能力与边界，用户在使用中提供意图信号，系统在运行时形成可供修正的意图假设，再把它转化为计划或行动。

图 1-1 传统软件与生成式系统中的意图翻译分工

1.2　固定界面是一套预先规定的表达语言

如果把数字产品看成一场人与机器的交流，固定界面就是产品团队提前写好的一套语言。

按钮和菜单像词汇，组件规则像语法，页面流程像允许用户说出的句式，反馈与状态则告诉用户机器是否听懂。用户不能随意向系统表达任何目标，只能使用产品提供的词汇，并按照它规定的方式组合。

1.2.1　图形界面降低了精确语法的负担

在命令行中，用户需要记住命令名称、参数和语法。一个字符写错，系统可能无法执行。图形界面的重要变化，是把许多抽象命令变成可见对象与直接动作。

Ben Shneiderman 在 1983 年提出“直接操控”时，总结了几个重要特征：持续显示用户关心的对象，用物理动作或带标签的控件代替复杂语法，让操作快速、增量、可逆，并让结果立即可见。³ 文件可以被看见和拖动，文字可以先选中再修改，数值可以通过滑块调整。用户不必先写出一条完整命令，而是可以操作一步、观察一步、再决定下一步。

直接操控解释了固定图形界面的一部分价值，但不等同于图形界面的全部。导航、信息结构、协作状态和复杂业务规则同样需要设计；有些任务也会同时使用表单、搜索、快捷键或命令。

这套结构后来成为大量数字产品的基础。它让机器的能力变得可发现，也让错误更容易被控制。用户看到“删除”按钮，会知道系统允许删除；看到按钮变灰，会知道当前条件不允许执行；修改后看到页面立即变化，就能判断操作是否生效。

固定界面因此是一套认知脚手架。它用视觉与交互结构，把抽象的系统能力变成可见、可学和可重复的动作。

1.2.2　界面同时规定“能说什么”和“怎样说”

每一种控件都在限制表达范围。

日期选择器要求用户提供一个符合日历规则的日期；单选框要求几个选项只能选择一个；数字输入框可以限制最大值和最小值；提交按钮把一组信息组合成一次完整动作。这些限制有时会让用户觉得不够自由，却也减少了歧义。

假设用户要预订一次会议。固定界面会要求他选择日期、开始时间、结束时间、参会人和会议室。产品团队提前决定了哪些信息是必须的、哪些组合无效、冲突时怎样提示。用户可能需要填写多个字段，但系统不必猜测“明天下午找个大家都方便的时间”到底指几点，也不必判断“大家”包含哪些人。

从这个角度看，传统界面是一份预先约定的交流协议。

表 1-1 固定界面中的表达规则

这套语言的优点是明确。产品能做什么，大部分可以从界面中看见；用户完成一次任务后，通常可以用相似方式再完成一次；团队也可以针对每个入口、状态和异常编写测试。

1.2.3　界面没有呈现的能力，通常等于不存在

固定界面的另一面，是产品团队必须提前决定什么值得被做成入口。

如果邮件产品没有“延迟发送”，普通用户就很难使用这项能力；如果报销系统没有某类费用，用户只能选择相近类型或联系人工；如果图像软件没有提供某种处理方式，用户就需要组合多个工具，或者把任务交给其他软件。

理论上，底层代码可以继续增加新能力。但每增加一个功能，团队都需要决定名称、位置、参数、状态、帮助信息和异常处理。功能越多，菜单和页面越复杂，用户发现正确入口的成本也越高。

所以，固定界面既是能力的表达，也是能力的边界。产品团队在发布前选定了一组值得支持的意图，再把它们变成有限的功能语言。用户能够表达什么，很大程度上取决于这套语言里已经有什么。

界面规定用户能怎样表达，状态与规则则规定系统收到表达后怎样响应。两者共同由团队在发布前定义：前者给出入口、对象和操作，后者给出条件、结果、分支与异常。固定界面的可预测性，正是建立在这套预定义关系之上。

图 1-2 固定界面怎样构成预定义的表达语言

1.3　确定性来自提前枚举可能性

传统软件的稳定感来自产品团队对开放现实的收敛，而非现实世界天然确定。这里所说的“提前枚举”，是定义主要状态、规则、分支和可预见异常，不要求穷举现实中的每一种情况。

一个按钮只有几个状态，一张表单只有若干字段，一条业务流程拥有清楚的分支。设计师画出页面与异常，开发人员把它们写成规则，测试人员再检查不同输入会进入哪个结果。团队用大量提前定义的工作，换来了用户使用时的相对确定。

1.3.1　稳定路径是被设计和实现出来的

仍以差旅报销为例。传统系统可以规定：住宿费用必须填写入住日期，金额超过一定范围需要补充说明，缺少发票时不能提交，提交后进入直属主管的审批队列。

每一条规则都对应一组可以观察和测试的状态。

• 条件满足时，按钮可以点击；
• 条件不满足时，系统显示明确提示；
• 权限不足时，用户不能执行；
• 网络失败时，申请保留为草稿；
• 审批完成后，状态从“处理中”变为“已通过”或“已驳回”。

当团队把主要情况列得足够完整，用户会获得一种稳定的因果关系：我做了什么，系统就会怎样回应。设计师也可以用流程图、状态图和可点击原型相对完整地表达产品。

所谓“确定性”，很大一部分来自这种提前枚举。产品不需要在运行时重新理解“什么叫住宿费用”，因为团队已经在数据结构和规则里定义好了；也不需要临时决定审批顺序，因为代码路径已经规定了下一步。

1.3.2　产品边界就是团队能够预先处理的可能性边界

现实中的任务远比流程图复杂。

用户可能丢失票据，可能跨国出差，可能遇到临时政策，也可能同时为多个项目垫付费用。传统系统用标准流程处理一部分复杂性，用异常分支处理另一部分，再把剩下的情况交给人工。

团队能够想到、定义、实现和维护多少状态，产品就能够稳定覆盖多少情况。长尾需求不是完全无法解决，只是每多支持一种情况，通常都要增加新的字段、规则、页面或人工流程。

成熟软件经常变得复杂，主要原因是越来越多现实差异被写进产品，并非团队单纯偏爱增加功能。一个看似基础的订单系统，背后可能有地区、税率、库存、优惠、退款、权限和合规等大量分支。

1.3.3　传统软件也不是绝对确定的

把传统软件称为“确定性软件”，容易产生一个误解：过去的系统每次都会产生完全相同的结果，AI 出现后产品才第一次面对不确定性。

事实并非如此。搜索结果会变化，推荐系统早已使用概率模型，定位和语音识别会受环境影响，网络、库存和协作数据也一直在变化。即使同一个页面，用户在不同时间看到的内容也可能不同。

这里讨论的是产品主要控制方式的变化，不能概括为“过去完全确定，现在完全随机”。

在传统产品中，概率性能力通常被包在相对明确的功能与流程里。推荐列表可以变化，但“加入购物车”仍然有确定含义；搜索排序可以变化，但筛选和分页仍按固定规则工作。团队可以让不确定性停留在某个局部，不必让它控制整条任务路径。

生成式系统则把模型推断放到了更核心的位置。系统可能先解释用户意图，再决定需要哪些信息，选择调用什么能力，并生成以前没有被逐项定义的结果。这类推断会随任务细节和环境变化，也会挑战传统界面强调的一致性和可预测性。⁴

1.3.4　决定从发布前移动到了运行时

确定性软件和生成式系统最重要的差异，可以理解为“决定在什么时候发生”。

过去，团队在发布前决定用户能做什么、任务怎样分步、每一步通向哪里。运行时，软件主要执行已经写好的规则。

现在，团队仍然需要定义能力和边界，但一部分具体决定被推迟到运行时。模型根据用户输入和上下文，判断这次任务应该怎样解释、组织和完成。同一句请求，在不同文件、不同用户和不同环境中，可能得到不同的结构与步骤。

这并不意味着规则会消失。生成空间越开放，越需要固定规则守住权限、数据、格式和风险底线。团队不再预先画出每一条可行路径，而是定义可用能力和边界，允许系统在这个空间里为当前任务选择路径。

图 1-3 从发布前的固定映射到运行时协商

运行时选择只说明部分决定发生在使用过程中。系统是否属于 Agent，还要看模型是否持续控制多步工作流和工具使用，以及系统是否具备完成判断、停止条件和移交机制。1.6 节将具体区分这些运行形态。

1.4　固定框架带来了稳定，也带来了限制

固定界面能够延续几十年，是因为它解决了许多重要问题。用户可以看见能力，形成空间记忆，预测操作结果，并在出错后回到熟悉位置。团队也可以控制性能、测试路径、说明责任，并让大量用户使用同一套稳定流程。这些价值不会因运行时生成的出现而消失。

1.4.1　稳定本身就是体验价值

用户对一款软件熟悉之后，常常能在没有仔细阅读的情况下完成操作。他知道保存在哪里，知道关闭窗口会发生什么，也知道怎样撤销。界面位置和行为的稳定，逐渐变成一种外部记忆。

1989 年，John Mitchell 与 Ben Shneiderman 招募了 73 名大学生，剔除 10 份不完整或受程序、设备故障影响的数据后，有效样本为 63 人。参与者以不同顺序使用固定菜单和动态菜单，分别完成两组相同的 12 项任务。实验使用键盘光标键选择菜单项；动态菜单按照每位参与者的选择频率持续重排，把最常使用的项目放在顶部。⁵

首次使用动态菜单的一组耗时显著更长；完成第二组任务时，两种菜单的耗时已无显著差异，菜单样式对操作次数和错误数也没有显著影响。事后询问中，81% 的有效参与者更偏好固定菜单。研究者还在现场观察到，部分参与者会记住菜单项的相对位置，并在菜单重排后感到迷失；这是观察性解释，不是单独测量的认知结论。

这项研究以学生和计算机新手为主，测试的是键盘操作的菜单，不能直接预测今天的生成式界面。它能支持的判断更窄：自适应变化可能带来学习与控制成本，团队需要同时评估效率、位置稳定性和用户偏好。

对于高频、明确和高风险的任务，固定结构尤其重要。输入支付金额、选择药物剂量、确认删除范围时，用户需要知道字段的含义和动作的后果，而不是每次面对一个重新生成的表达方式。

固定界面还可以降低验证成本。一个经过测试的日期组件不必在每次任务中重新生成，一条明确的业务规则也不必交给模型反复解释。确定的部分越稳定，团队越能把注意力留给开放问题。

1.4.2　固定能力目录难以覆盖长尾目标

固定框架的限制也来自同一个原因：团队必须提前决定支持什么。

大多数用户共享同一套页面，复杂目标需要被拆成统一步骤，无法归类的需求则进入“其他”或人工服务。用户越专业，越可能发现产品只覆盖了常见路径；用户越不熟悉软件，越可能不知道应该把目标拆成哪些操作。

假设一位用户希望“把最近三个月客户反馈中与续费风险有关的问题找出来，按影响程度分组，并给每组附上原始证据”。在传统分析软件中，他可能需要导出数据、清洗字段、设置筛选、建立标签、编写公式和制作图表。每一项能力都存在，但完整目标没有对应的单一入口，用户必须自己设计工作流。

产品也可以为这个目标增加一个功能。问题是，下一位用户可能想按地区比较，另一位想结合销售记录，还有人希望使用自己的风险标准。开放目标会迅速产生组合爆炸，团队很难为每一种组合都设计按钮和页面。

生成式系统的价值，就出现在这些难以提前枚举的区域。它不必为每个目标增加永久入口，而可以根据当前数据、要求和限制临时组织一条处理路径。

1.4.3　开放表达也会带来新的负担

固定选项让用户受到限制，空白输入框则可能让用户无从开始。

当产品只显示“你想做什么”时，用户需要知道系统能做什么，知道哪些背景应该说明，也要能够把模糊想法写成有效要求。表达空间扩大后，发现能力、控制结果和修正误解的责任可能重新回到用户身上。

自然语言也不适合所有细节。用户可以说“把语气变得更正式”，却可能更愿意用滑块调整篇幅；可以说“分析这些数据”，却更适合直接勾选时间范围和比较对象。Microsoft Research 的 Dynamic PRC 研究原型会根据当前提示和对话历史，生成单选、复选或文本控件，再用这些选择细化回答。⁶

在一项由 16 名熟悉生成式 AI 的技术专业人士参加的受控研究中，参与者完成了 6 项代码解释、复杂主题理解与技能学习任务。他们整体更偏好动态方案，并报告了更强的控制感和更低的上下文表达门槛；同时，他们也更难预判某个动态控件会怎样影响输出。这项小样本研究只支持特定理解任务中的原型机制，不能推广为所有 AI 界面的普遍效果。

因此，新旧范式不应该被理解为聊天框与按钮的竞争。固定控件擅长表达确定对象、范围和参数，自然语言擅长表达开放目标和例外，生成式能力擅长处理尚未被做成功能入口的组合。好的产品会根据任务，把三者组织在一起。

1.4.4　AI 扩大设计空间，并没有取消固定框架

生成式系统可以让过去无法被产品化的长尾问题进入软件，但不代表所有部分都应该生成。

登录、权限、支付、版本、审计和关键状态仍然需要稳定规则；常用操作仍然值得保留为按钮；用户反复执行的成熟流程，可能更适合被固化为模板或工作流。当输入开放、规则难以维护、环境变化较大或任务步骤难以预先确定时，运行时生成可能更有价值；如果确定性方案已经足够，就没有必要增加生成环节。

实际产品可以用确定的外层承载生成能力。固定部分让用户知道系统的边界、状态和控制方式，模型则在边界内处理过去难以枚举的问题。

图 1-4 固定框架、运行时生成与混合方案

1.5　系统开始参与运行时翻译

命令、图形界面、搜索和自然语言没有线性替代，而是在许多产品中长期共存。它们把不同负担分配给用户和系统：命令要求用户掌握精确语法，图形界面把一部分语法变成可见对象，搜索承担相关性匹配，生成式系统则尝试从句子、文件、图像、语音和当前上下文中推断目标。

从这些交互方式可以观察到一种负担转移：用户可能少承担一部分语法记忆、功能检索和步骤拆解，系统则多承担匹配、纠错和解释。直接操控与 Dynamic PRC 分别提供了两个具体例子，但它们不能证明一条适用于所有产品的单向历史规律。³⁶

1.5.1　机器开始承担更多解释工作

在固定软件中，用户需要先找到正确功能。如果他想把一张照片的背景换掉，就要知道选择、蒙版和图层在哪里；如果他想比较一组数据，就要知道筛选、透视表或公式应该怎样使用。

生成式系统允许用户从目标开始。用户可以先选中照片，再说“保留人物，把背景换成傍晚的城市街道”；也可以选中表格后提出“比较三个地区最近六个月的退款原因，并标出异常变化”。系统再根据当前对象和要求选择能力。

语言在这里不是另一种命令行。命令行要求用户使用机器规定的精确语法，生成式系统则尝试接受不完整、自然甚至带有歧义的表达，并补足中间步骤。

在对象和边界能够由上下文、直接操控或结构化控件补充的任务中，这种方式可能降低用户首次使用某些专业能力的操作门槛。它没有取消学习成本：用户仍需判断系统读了什么、怎样解释要求，以及结果是否可以采用。

1.5.2　“理解用户”仍然是一种推断

处理自然语言只让软件获得了更多推断信号，无法让它直接知道用户心里在想什么。

系统看到的是用户输入、选中对象、当前页面、历史对话、文件内容和被允许读取的其他信息，再根据这些信号推断最可能的目标。信号越丰富，结果可能越贴近情境；与此同时，隐私、误用和越界风险也会提高。

用户说“帮我安排下周的项目会议”，系统可能需要知道项目成员、时区、日历空闲和会议时长。但能够访问日历，不代表可以读取所有私人日程；知道过去会议通常是一小时，也不代表这次应该自动采用相同设置。

因此，所谓从“人适应机器”走向“机器理解人”，增加了一种新的协商关系，没有彻底移除用户的学习成本。系统需要说明自己使用了哪些上下文，用户需要判断这些上下文是否正确，也需要在误解发生时能够低成本纠正。

用户仍然需要学习软件，只是学习的内容从“功能放在哪里”，转向“系统使用了什么信号、会如何变化，以及什么时候不应该依赖它”。产品需要帮助用户建立并调整心理模型；当 AI 无法完成任务时，还应保留不依赖 AI 的完成路径。⁷

1.5.3　最自然的表达不一定是最有效的表达

人类可以用语言说明目标，也会用手指出对象、用表格比较差异、用滑块控制程度。所谓自然交互，不应该只剩下聊天。

一句“把这里改得更简洁”如果配合已经选中的段落，就比单独输入一段说明更准确；一句“给我三个方案”如果配合预算、日期和风险等级控件，就比让系统猜测所有限制更可靠。

可以把新的意图表达理解为三种方式的组合：

1. 用自然语言表达目标、原因和例外；
2. 用直接操控明确对象、范围和局部修改；
3. 用结构化控件表达参数、选择和不可含糊的约束。

系统要形成可用的意图假设，需要让产品用多种通道收集足够的意图信号，不能把责任全部推给一条所谓“完美提示词”。

1.5.4　运行时决定也会改变输出形式

当系统能够解释目标并生成代码，界面本身也可以成为一种输出。对同一项任务，系统可能返回文本，也可能在运行时组织表格、模拟器或临时工具。Google Research 的生成式 UI 实验展示了这种可能。⁸

本章只需要确认：运行时决定可以延伸到输出形式。生成式界面的实现、评估、延迟与准确性边界，留到下一章讨论。

1.6　从工具到行动者

本书把 Agent 定义为能围绕目标连续使用工具、检查结果并继续行动的 AI 系统。模型参与判断下一步，工具负责读取信息或改变外部状态；模型只是这个系统的一部分。

生成内容已经改变了许多产品，但更深一层的变化，是软件开始代表用户连续行动。为了判断系统拥有多大的路径选择权，需要把响应式工具、生成式功能、预定义工作流和 Agent 分开。外部影响很重要，却不是唯一边界：预定义工作流同样可以写入数据库，Agent 也可以先完成一段只读研究。

表 1-2 四种运行形态的路径与控制边界

表中的分类用于分析运行结构，不是产品等级。一个系统在运行时选择内容或界面，并不会自动成为 Agent；关键在于模型是否持续控制多步工作流和工具使用。

图 1-5 响应式工具、生成式功能、预定义工作流与 Agent

1.6.1　“给我一个答案”和“替我完成任务”不同

用户问“怎样报销这次出差”，系统可以返回政策与操作说明；用户说“帮我完成这次报销”，系统则可能读取票据、匹配行程、判断类型、填写申请并调用报销工具。

前一种体验会产生可审查的候选内容。设计师需要让用户核对来源、发现遗漏、比较差异并编辑结果。候选内容也可能误导判断，但在被采用之前，用户通常还有检查机会。

后一种体验还会产生外部动作的副作用。系统一旦写入报销平台、发送消息、下单或修改权限，影响可能立刻扩散到其他人和系统。设计师因此还要处理目标对象、授权范围、行动预览、重复执行保护、结果回执，以及撤销或补偿。内容风险与行动风险都要审查，但两者的发生位置和恢复方式不同。

1.6.2　自动化与直接操控的关系是一个长期问题

软件代表用户行动并不是全新的想法。1999 年，Eric Horvitz 在混合主动式界面研究中，把系统是否提供自动服务写成一个决策问题：系统根据证据估计用户具有某个目标的概率，再比较行动与不行动的结果效用。论文随后把“询问用户”加入选择，用两个阈值划分不行动、询问和行动。²

这套模型并不要求系统显式计算期望值；阈值也可以由设计者或用户设定。本书只借用它的决策结构，说明主动行动必须同时考虑目标判断与行动后果。它研究的是当时的混合主动界面，不能直接证明今天的 LLM Agent 应采用同一种内部实现。

1.6.3　Agent 把路径选择推迟到任务执行中

Anthropic 在 2024 年的工程指南中区分了工作流与 Agent：工作流通过预先定义的代码路径组织模型和工具；Agent 则是由模型动态决定过程和工具使用的系统。前者更适合步骤清楚、需要一致性的任务，后者更适合路径难以提前确定、需要灵活判断的任务。⁹

这一区别正好对应本章讨论的两套基础假设。

在固定工作流中，团队设计好 A 之后进入 B，满足某个条件再进入 C。模型可以参与某一步，例如提取票据内容，但整条路径仍然由代码控制。

在 Agent 中，团队提供目标、工具和规则，系统在运行时决定先查什么、后做什么，遇到缺失信息时是否询问，工具失败后是否换一种方法。路径不再只是界面的跳转关系，也成为模型行为的一部分。

OpenAI 的 Agent 实践指南也把 Agent 描述为代表用户独立完成任务的系统：模型管理工作流执行，工具用来获取上下文和采取动作，系统在失败时应能停止或把控制权交还给用户。该指南还指出，Agent 更适合复杂判断、难以维护的规则和大量非结构化数据；如果确定性方案已经足够，就没有必要增加 Agent。¹⁰

两份资料都属于厂商工程分类，不是统一的学术标准。本书采用它们的共同边界：Agent 是包含模型、工具、指令、状态和控制机制的系统；模型是否控制多步工作流，是区分 Agent 与普通生成式功能、预定义工作流的关键问题。

1.6.4　行动者是一种需要约束的产品角色

把 AI 称为“行动者”，很容易让人产生拟人化理解，好像系统拥有自己的目标与责任。

本章所说的行动者，只表示软件可以在授权范围内选择和执行一段行动。它的目标来自用户与产品，能力来自模型和工具，边界来自权限和规则，责任仍然需要由使用者、团队和组织明确承担。

从设计角度看，关键问题是系统的能动性有多大：能够读取什么，能够修改什么，能够影响谁，能够连续行动多久，以及走偏后是否还能被停止。它像不像人，不影响这些边界的设定。

一个只生成草稿的系统和一个可以直接发送邮件的系统，可能使用同一个模型，却是两种完全不同的产品。能力相似，不代表授权应该相同；结果看起来正确，也不代表过程没有越过边界。

当软件从工具变成行动者，界面也不再只负责提供操作入口，还要帮助用户理解目标、观察过程、判断关键节点并在需要时接管。后续章节会继续展开这些问题，本章先把它们归纳为六个新的设计入口。

1.7　新设计面对的六个基本问题

在确定性软件中，产品团队也会讨论用户目标、数据、权限和异常，但许多问题可以被固定流程吸收。用户亲自逐步操作，界面天然展示当前步骤，系统也很少在没有操作的情况下连续改变外部状态。

当模型开始参与解释与行动，这些问题不能再只留在后台。它们会直接决定用户是否理解系统、是否愿意委托，以及出错后能否恢复。

下面继续使用开篇的报告汇报案例。用户希望系统读取研究报告，为管理层制作一场 20 分钟汇报。这个看似清楚的委托，仍然需要依次回答六个问题。

1.7.1　系统如何理解用户意图？

用户说出的通常不是一份完整规格。

“帮我整理报告”可能指修改结构、统一语言、提炼摘要或制作汇报。开篇的要求补充了听众、时长、重点和来源规则，系统才有条件形成较具体的意图假设。它仍需判断哪些内容可以根据上下文推断，哪些内容必须追问。

设计师过去主要定义用户如何选择功能，现在还要定义系统如何发现歧义、怎样复述目标，以及用什么方式让用户低成本补齐对象、限制和完成标准。

1.7.2　系统依据了哪些上下文？

同一句请求放在不同上下文中，会产生不同结果。

选中的研究报告、当前页面、历史对话、用户偏好、组织规则和外部数据，都可能帮助系统理解任务。但“系统能够获得”不等于“用户已经授权使用”。制作这次汇报需要读取哪一版报告，是否可以引用访谈原话，是否允许结合其他项目材料，都要有清楚边界。

设计师需要考虑上下文从哪里来、何时生效、用户能否看见和删除，以及系统引用了错误或过期信息时怎样纠正。

1.7.3　系统准备采取什么行动？

系统可能先提取证据，再归纳问题、组织论点、生成图表和排版页面。中途发现数据冲突后，它还可能调整结构。产品不需要展示全部内部计算，但需要让用户理解当前目标、主要步骤、已经完成什么、即将生成或修改什么，以及计划变化是否超出原来的范围。

过程由此成为用户判断委托是否仍在轨道上的依据。

1.7.4　哪些事情可以自主完成？

在这场汇报中，提取标题、生成大纲和制作候选页面，可以先自动完成；删除被系统判断为“次要”的反例、改写敏感访谈原话，或把文件分享给管理层，则需要更严格的检查和授权。

设计师需要根据行动后果、可逆性、敏感程度和系统可靠性，决定哪些步骤可以自动执行，哪些只能提供建议，哪些必须先获得授权。自主性需要按行动分别设定上限，无法用整款产品的一个开关概括。

1.7.5　哪些事情必须交还给用户决定？

系统可能发现两组数据口径冲突，不确定哪项用户问题最值得管理层关注，或者无法判断一段原话能否对外展示。继续猜测会把事实缺失和价值判断隐藏在一份完整汇报里。

好的设计需要识别“必须问人”的节点，并向用户提供足够的判断材料。交还控制权不能只是弹出一句“是否继续”，还要说明为什么需要决定、有哪些选择、每种选择会产生什么影响。

1.7.6　系统走偏后如何打断、回退和追责？

如果系统一开始误解了听众，后续论点、数据密度和页面结构都可能随之走偏。候选汇报可以回到大纲检查点重新生成；已经共享给管理层的文件或已经发出的消息，则未必能够真正撤回。

因此，产品需要考虑怎样停止正在运行的任务，怎样保留检查点，哪些动作可以回退，哪些只能补偿，以及事后如何还原系统使用的上下文、工具、权限和人工决定。

恢复能力需要与系统能力同时定义，不能等设计完成后再补一个“撤销”按钮。

把这六个问题放在一起，可以看到设计基础假设的完整变化。

图 1-6 生成式系统面对的六个基本设计问题

表 1-3 确定性软件的常见假设与生成式系统的新问题

这些问题为后续设计工作提供了入口，也会继续改变设计对象、用户角色、设计方法、交付物和评价标准。把它们整理成界面清单，并不能替代对系统行为的判断。

本章小结

过去几十年的数字产品，大多建立在一套相对稳定的假设上。

第一，人的目标需要被翻译成机器能够执行的动作。设计师把常见目标做成功能、控件与流程，用户再学习这套语言，把自己的具体目标拆成操作。

第二，固定界面是一套预先规定的表达语言。它用可见对象、结构化输入和即时反馈降低了精确语法的负担，也决定了用户可以向系统表达什么。

第三，软件的确定性主要来自提前定义。产品团队列出主要状态、规则、分支和可预见异常，把开放现实压缩成可实现、可测试和可维护的可能性空间；这不等于穷举现实。

第四，固定框架同时带来价值与限制。它稳定、清楚、可预测，却难以覆盖不断组合的长尾目标，复杂任务仍然需要用户理解工具并自行设计步骤。

第五，生成式系统把一部分翻译与路径选择推迟到了运行时。用户可以先表达目标，系统再结合对象和上下文生成内容、结构、界面与步骤。自然语言并不会取代所有控件，新的体验更可能是语言、直接操控与结构化约束的组合。

第六，当模型在边界内持续控制多步工作流和工具使用，系统才进入本书所说的 Agent 形态。设计因此必须回答意图、上下文、计划、自主性、人工决定和错误恢复等新问题。

AI 没有让传统设计失效。按钮、页面、规则、流程和直接操控仍然是稳定体验的重要基础。产品现在可以在固定结构之外表达一部分运行时能力。设计师需要同时处理两种空间：一部分由团队提前确定，另一部分由系统在运行时生成。

下一章将把这些运行时部分作为设计对象，继续讨论意图、上下文、计算、权限、行为和结果怎样与界面共同构成体验。

¹ Don Norman, The Design of Everyday Things, Revised and Expanded Edition, 2013/2014，https://jnd.org/books/the-design-of-everyday-things-revised-and-expanded-edition/ 。

² “意图假设”是本书的设计分析概念。Eric Horvitz, “Principles of Mixed-Initiative User Interfaces,” CHI 1999，https://doi.org/10.1145/302979.303030 。论文以可观察证据推断用户目标概率，支持“系统对用户目标的判断具有不确定性”这一较窄主张；它没有把“意图假设”定义为通用术语或系统必须保存的独立字段。

³ Ben Shneiderman, “Direct Manipulation: A Step Beyond Programming Languages,” Computer, 16(8), 1983, pp. 57–69，https://doi.org/10.1109/MC.1983.1654471 。

⁴ Saleema Amershi et al., “Guidelines for Human-AI Interaction,” CHI 2019，https://doi.org/10.1145/3290605.3300233 。

⁵ John Mitchell and Ben Shneiderman, “Dynamic versus static menus: an exploratory comparison,” SIGCHI Bulletin, 20(4), 1989, pp. 33–37，https://www.cs.umd.edu/~ben/papers/Mitchell1989Dynamic.pdf 。论文最初招募 73 名大学生，有效样本为 63；76% 为大学一、二年级学生，多数几乎没有计算机经验。研究对象是键盘菜单，结果不宜外推到现代生成式界面。

⁶ Ian Drosos et al., “Dynamic Prompt Middleware: Contextual Prompt Refinement Controls for Comprehension Tasks,” CHIWORK 2025, 2025 年 6 月，https://doi.org/10.1145/3729176.3729203 ；Microsoft Research 项目页：https://www.microsoft.com/en-us/research/publication/dynamic-prompt-middleware-contextual-prompt-refinement-controls-for-comprehension-tasks/ 。研究包含 38 人形成性调查与 16 人受控实验；受控实验测试的是理解任务中的 Static PRC 与 Dynamic PRC 原型。

⁷ Google People + AI Guidebook, “Mental Models,” https://pair.withgoogle.com/guidebook-v2/chapter/mental-models/ 。

⁸ Google Research, “Generative UI: A rich, custom, visual interactive user experience for any prompt,” 2025，https://research.google/blog/generative-ui-a-rich-custom-visual-interactive-user-experience-for-any-prompt/ 。

⁹ Anthropic, “Building effective agents,” 2024 年 12 月 19 日，https://www.anthropic.com/engineering/building-effective-agents 。这里采用的是 Anthropic 当时的工程分类，不代表统一的学术定义。

¹⁰ OpenAI, “A practical guide to building agents,” https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/ 。官方网页与 PDF 未标明发布日期或版本号，访问于 2026 年 8 月 9 日；这里采用访问时的工程指南口径，不代表统一的学术定义。