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

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

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

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

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

第一套方式假设，产品团队已经提前定义好软件可以做什么，用户需要通过固定界面选择功能、安排步骤并完成操作。第二套方式则假设，用户可以先表达目标，系统在运行时解释目标、选择能力、组织步骤并生成结果。用户不再负责每一个动作，却需要说清对象、听众、重点、限制和完成标准，还要判断系统是否真正理解了任务。

这并不意味着第二种方式一定比第一种方式更好。对于调整一行文字的位置、输入一个确定金额、确认一项不可逆操作，固定控件往往更快、更准确，也更容易预测。生成式系统扩大的不是所有任务的效率，而是产品能够处理的问题范围。过去必须由用户自行拆解的开放目标，现在有一部分可以交给系统参与解释。

因此，AI 带来的关键变化不是界面上多了一个输入框，也不是设计师以后不再画页面，而是意图的翻译开始从产品发布前，延伸到产品运行时。

过去，设计师和开发者先把人的目标翻译成有限的功能与流程，用户再把自己的目标翻译成点击、输入和选择。现在，模型开始进入第二次翻译，甚至参与第一次翻译：它不仅响应操作，还可能判断用户想做什么、需要哪些信息、应该采用哪些步骤，以及结果应该以什么形式呈现。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.1.3　意图不是 AI 时代才出现的

现在经常有人把“从功能转向意图”描述为 AI 产品特有的变化。更准确地说，用户意图一直是设计的起点，只是过去的系统很少能够直接处理它。

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

变化不在于产品第一次关心用户想做什么，而在于机器第一次能够在较大范围内参与解释“用户想做什么”。《Designing AI Interfaces》把输入称为人的意图进入系统的位置，同时指出输入既可以是明确说出的一句话，也可以来自当前文档、选中对象和任务上下文。² 这让意图不再只能在用户研究和需求文档里被讨论，也开始成为产品运行时需要处理的内容。

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

所以，AI 没有消除意图翻译。它只是改变了翻译的承担者：过去主要由设计师提前完成、用户在使用中补完；现在，系统也开始在运行时参与其中。

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

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

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

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

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

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

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

固定界面因此不仅是一层视觉包装，也是一套认知脚手架。它把抽象的系统能力变成可见、可学和可重复的动作。

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

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

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

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

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

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

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

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

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

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

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

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

传统软件之所以让人感觉稳定，并不是因为现实世界天然确定，而是因为产品团队把开放的现实收敛成了有限状态。

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

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

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

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

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

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

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

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

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

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

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

这也是为什么成熟软件经常变得复杂。它不是单纯因为团队喜欢增加功能，而是因为越来越多现实差异被写进了产品。一个看似简单的订单系统，背后可能有地区、税率、库存、优惠、退款、权限和合规等大量分支。

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

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

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

这里讨论的差异，不是“过去完全确定，现在完全随机”，而是产品的主要控制方式发生了变化。

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

生成式系统则把模型推断放到了更核心的位置。系统可能先解释用户意图，再决定需要哪些信息，选择调用什么能力，并生成以前没有被逐项定义的结果。Microsoft 的人机 AI 交互研究指出，AI 推断通常发生在不确定性下，系统可能因为任务细节、环境、个性化或持续学习而表现不同，这会直接挑战传统界面强调的一致性和可预测性。⁴

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

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

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

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

这并不意味着规则会消失。恰恰相反，生成空间越开放，越需要固定规则守住权限、数据、格式和风险底线。变化只是产品不再要求团队提前画出每一条可行路径，而是允许系统在受约束的空间里，为当前任务选择一条路径。

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

讨论 AI 产品时，最容易出现的错误，是为了证明新范式成立，把固定界面描述成一种落后的负担。

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

1.4.1　稳定本身就是体验价值

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

1989 年，John Mitchell 与 Ben Shneiderman 曾用 63 名参与者比较固定菜单和按使用频率自动重排的动态菜单。在这项特定任务和当时的界面条件下，动态菜单没有表现出稳定优势，81% 的参与者更喜欢固定菜单。⁵ 这项早期、小规模研究不能直接预测今天的生成式界面，却说明了一个长期存在的问题：系统认为“更适合你”的变化，可能破坏用户已经形成的位置记忆和因果预期。

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

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

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

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

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

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

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

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

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

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

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

自然语言也不适合所有细节。用户可以说“把语气变得更正式”，却可能更愿意用滑块调整篇幅；可以说“分析这些数据”，却更适合直接勾选时间范围和比较对象。Microsoft Research 的 Promptions 项目正是把动态生成的结构化选项放进对话，让用户不必通过反复改写长提示词来补充精确要求。⁶

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

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

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

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

所以，更合理的产品结构不是用不确定性替代确定性，而是用确定的外层承载生成的能力。用户知道系统的边界、状态和控制方式，模型则在边界内处理那些过去难以枚举的问题。

1.5　从用户适应软件，到软件理解用户

回顾人机交互的发展，可以看到一条持续变化的线索：用户需要掌握的机器语法越来越少，系统承担的解释工作越来越多。

命令行要求用户写出精确指令；图形界面把指令变成可见对象和操作；搜索允许用户使用更松散的关键词，并由排序系统判断相关性；生成式系统则进一步接受完整句子、文件、图像、语音和当前上下文，尝试从这些信号中推断目标。

这可以被概括为：从用户适应软件，逐渐走向软件适应用户。

但这句话只说对了一半。

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

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

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

语言在这里不是另一种命令行。命令行要求用户使用机器规定的精确语法，生成式系统则尝试接受不完整、自然甚至带有歧义的表达，并补足中间步骤。《Designing AI Interfaces》把从命令行、搜索到 AI 输入的变化概括为一种负担转移：用户不再承担全部语法与检索结构，系统开始承担更多匹配、纠错和解释工作。²

这会降低一部分专业软件的门槛。用户可以先说明想达到什么结果，再逐步学习系统怎样实现，而不必在第一次使用前就理解全部功能结构。

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

软件并没有因为能够处理自然语言，就真正知道用户心里在想什么。

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

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

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

Google 的 People + AI Guidebook 提醒设计者，AI 系统可能随反馈、个性化和更新而变化，产品需要帮助用户建立并持续调整心理模型；当 AI 不确定或无法完成任务时，还应保留不依赖 AI 的完成路径。⁷ 这说明用户仍然需要学习软件，只是学习的内容从“功能放在哪里”，转向“系统怎样理解我、会怎样变化，以及什么时候不应该依赖它”。

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

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

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

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

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

系统理解用户，不是让用户把所有内容写进一条完美提示词，而是让产品用多种通道共同收集足够的意图信号。

1.5.4　界面也可以在运行时被组织

当系统能够解释目标并生成代码，界面本身也开始从固定容器变成一种可能的输出。

Google Research 在 2025 年公布的生成式 UI 研究中，系统会根据具体问题动态生成网页、工具、模拟和交互体验，而不只是把内容填入一个预定义模板。在其评估中，如果暂不考虑生成时间，人类评分者对生成式 UI 的偏好明显高于标准文本或 Markdown 输出，但人工专家设计的页面仍然获得最高偏好；当前实现也存在生成时间较长和偶发不准确。⁸

这个结果说明两个问题。

第一，界面可以更贴近当前目标。解释概率时，系统可以生成一个可以拖动参数的模拟器；规划活动时，可以生成预算、日程和任务看板；比较方案时，可以生成结构化表格，而不必把所有结果塞进一段对话。

第二，运行时生成没有自动解决设计质量。信息层级、可访问性、一致性、速度、错误和跨次使用的稳定性仍然存在。产品越能动态变化，越需要定义哪些规则不能变化，以及怎样让用户在变化中保持方向感。

因此，“软件理解用户”的终点不是一个无所不知的聊天框，而可能是一套会根据目标选择语言、控件、视觉结构和行动方式的系统。

1.6　从工具到行动者

生成内容已经改变了许多产品，但更深一层的变化，是软件开始代表用户连续行动。

传统工具等待操作。生成式功能接受要求并返回内容。Agent 则可能围绕一个目标，读取环境、制定步骤、选择工具、执行动作、观察结果，再决定下一步。

这三个层级可以这样区分：

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

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

前一种体验主要需要判断信息是否正确。后一种体验还需要判断系统是否读了正确材料、使用了正确规则、选择了合理步骤、拥有适当权限，并且没有在缺少信息时擅自继续。

当 AI 只生成一段文字，错误主要停留在内容层；当它开始调用工具，错误就可能变成错误的文件修改、订单、消息或权限变化。设计对象因此从“系统说了什么”，扩展到“系统做了什么”。

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

软件代表用户行动并不是全新的想法。早在 1999 年，Eric Horvitz 就在混合主动式界面研究中讨论了直接操控与界面 Agent 应该怎样结合。他指出，自动服务可能错误猜测用户目标、选择不恰当的行动时机，或忽略行动的成本，因此系统需要根据不确定性、收益和风险决定自动执行、与用户对话还是不行动。⁹

当时的系统能力与今天的语言模型相差很大，但设计问题具有连续性：机器什么时候应该主动，人什么时候应该掌握控制，系统怎样从人的纠正中调整，以及错误行动会造成多大代价。

今天的变化在于，模型可以处理更开放的语言和非结构化资料，也能使用越来越多数字工具。过去只适用于少数明确场景的界面 Agent，开始进入写作、编程、研究、客服、办公和业务流程。

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

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

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

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

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

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

1.6.4　行动者不是人格，而是一种需要约束的产品角色

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

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

从设计角度看，真正重要的不是 AI 像不像人，而是它的能动性有多大：能够读取什么，能够修改什么，能够影响谁，能够连续行动多久，以及走偏后是否还能被停止。

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

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

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

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

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

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

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

“帮我整理报告”可能指修改结构、统一语言、提炼摘要或制作汇报；“找个合适时间”涉及哪些人、多久、线上还是线下，也可能没有写清。系统需要判断哪些内容可以根据上下文合理推断，哪些内容必须追问。

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

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

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

选中的文件、当前页面、历史对话、用户偏好、组织规则和外部数据，都可能帮助系统理解任务。但“系统能够获得”不等于“用户已经授权使用”，历史偏好也不一定适合当前任务。

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

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

当软件只响应单次点击时，用户通常知道下一步会发生什么。Agent 可能在一句委托后执行多个步骤，还会根据中间结果修改计划。

产品不一定需要展示全部内部计算，但需要让用户理解系统当前目标、主要步骤、已经完成什么、即将影响什么，以及计划变化是否超出了原来的范围。

这意味着“过程”第一次大规模成为用户体验的一部分。

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

整理临时草稿、读取公开资料和移动资金，不应该拥有相同的自主程度。

设计师需要根据行动后果、可逆性、敏感程度和系统可靠性，决定哪些步骤可以自动执行，哪些只能提供建议，哪些必须先获得授权。自主性不是整款产品的一个开关，而是任务中每一类行动的不同上限。

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

系统可能遇到事实缺失、规则冲突、价值判断和高风险例外。继续猜测也许能让流程看起来更顺畅，却可能把不确定性隐藏成一个自信结果。

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

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

生成错误内容可以修改，发送错误消息、删除数据或完成交易却未必能够真正撤销。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/ 。

² Louise Macfadyen, Designing AI Interfaces, O’Reilly Media, 2026，章节 “Inputs”“Discovery”“From Multics to Google Search: The Shifting Burden” 与 “Direct Manipulation”；本地文件见 converted-epubs/Designing AI Interfaces/sections/。

³ 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://doi.org/10.1145/67243.67247 。

⁶ Microsoft Research, “Promptions helps make AI prompting more precise with dynamic UI controls,” 2025，https://www.microsoft.com/en-us/research/blog/promptions-helps-make-ai-prompting-more-precise-with-dynamic-ui-controls/ 。

⁷ 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/ 。

⁹ Eric Horvitz, “Principles of Mixed-Initiative User Interfaces,” CHI 1999，https://doi.org/10.1145/302979.303030 。

¹⁰ Anthropic, “Building effective agents,” 2024，https://www.anthropic.com/engineering/building-effective-agents 。

¹¹ OpenAI, “A practical guide to building agents,” https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/ 。