设计对象变了——从界面到意图、上下文与行为

假设现在要设计一款差旅报销产品。

在传统软件里，设计师通常会先梳理报销流程，再画出上传票据、识别金额、选择费用类型、填写说明、提交审批和查看进度等页面。用户是主要行动者，系统负责保存信息、校验字段和执行明确规则。设计师只要把每个页面、状态和跳转关系定义清楚，研发就可以把这套流程稳定地实现出来。

如果把同一个产品改造成报销 Agent，设计对象会立即发生变化。用户不再逐张填写票据，而是把一组照片交给 Agent，并告诉它“帮我完成这次出差报销，超出公司标准的项目先问我”。Agent 需要识别每张票据，提取商户和金额，判断费用类型，查找公司的报销政策，将多张票据组织成一份申请，再调用报销系统提交。如果酒店费用超过标准，它还需要判断应该直接停止、向用户解释原因，还是在获得授权后继续查找更具体的政策。Anthropic 在介绍 Agent 工作方式时使用过一个相似的差旅报销案例：Agent 会规划、行动、观察结果、调整计划，并在缺少关键信息时回到用户这里确认。¹

这时，设计师当然仍然需要设计界面，但只画出“上传”和“提交成功”两个页面已经远远不够。真正决定体验的是一连串行为：Agent 如何理解目标，读取什么信息，选择什么工具，按什么顺序行动，在哪里停下来，如何暴露不确定性，出了问题能否恢复，以及用户如何知道它没有越权。

过去，界面几乎等于产品；现在，界面只是用户观察、指导和接管智能系统的一部分。

因此，Agent 时代最重要的变化并不是聊天框取代了按钮，也不是设计师以后不用画界面了，而是设计对象从确定的页面和流程，扩展到了意图、上下文、计算、行为、权限和结果。设计师不再只定义“用户点了什么之后页面怎样变化”，还要定义“系统理解了什么、依据什么行动、哪些事情不能做、行动之后如何向用户证明自己做对了”。

本章将从五个方面讨论这种迁移：确定性软件的旧假设为什么开始松动；设计对象如何从界面扩展到意图、计算与交互；AI 为什么正在从输出文本走向执行行动链；不确定性为什么会成为新的设计材料；以及当界面可以按需生成后，个性化为什么会从附加能力变成核心问题。

2.1　从确定性软件到不确定系统：旧假设是如何松动的

传统软件并非绝对没有不确定性。网络可能中断，定位可能漂移，搜索和推荐系统也早已使用概率模型。但对大部分用户界面来说，团队仍然可以预先定义主要状态和结果：点击“保存”会保存当前内容，选择“按价格排序”会得到明确顺序，表单缺少必填项就不会提交。

这种确定性不只是一种技术特征，也塑造了过去几十年的设计方法。设计师画出页面、流程和异常状态，工程师把它们写成规则，测试人员逐条检查输入和输出是否符合预期。只要需求没有改变，相同输入通常会沿着相同路径得到相同结果。

AI 产品没有完全抛弃这些规则，但在规则之间加入了一个会理解、推断、生成和选择的系统。设计师面对的因此不再是一条唯一的“正确路径”，而是一个带有结果分布的可能性空间。

2.1.1　从“规则有没有写对”到“系统这次会怎么判断”

仍以报销产品为例。传统程序可以规定：金额超过 1000 元时必须上传发票；费用类型选择“住宿”时必须填写入住日期；缺少成本中心时禁止提交。每条规则都可以被清楚写成条件。

但当 Agent 读取一张模糊的酒店小票时，问题会变得不同。它可能把商户名称识别错，可能把税费和房费相加两次，也可能根据过去的经验把这笔支出归入错误类型。即使文字全部识别正确，它仍然可能误解“每晚住宿标准”和“整段行程住宿总额”的区别。

这些错误不一定来自某一行代码写错。模型可能在信息不足时做出了一个看似合理的推断，检索工具可能找到了过期政策，上下文里也可能同时存在两个版本的报销规则。结果越像人写出来的，用户反而越容易忽略其中的错误。

所以，传统软件和 AI 系统的差异不只是“固定输出”和“随机输出”的差异，而是错误形态发生了变化。

2.1.2　真正变化的是中间过程

很多 AI 产品仍然保留熟悉的输入框和结果页，所以表面上看，它和传统软件没有太大区别。但用户从输入到输出之间的中间过程已经发生变化。

过去，设计师可以把计算过程大部分交给工程实现。一个按钮背后调用哪个接口、一个列表如何排序，只要不影响用户理解，通常不需要成为核心设计对象。现在，模型选择、上下文拼接、工具权限、检索来源、推理时长和失败重试都会直接改变用户体验。

例如，同一个“帮我整理报销”请求，系统如果只读取票据，会得到一份费用清单；如果同时读取日历和差旅订单，可能自动补全行程；如果继续读取公司政策，就能判断哪些费用超标；如果拥有报销系统的写入权限，还可以替用户完成提交。每增加一层上下文和工具，能力都会提高，但误用信息、泄露隐私和产生外部影响的风险也会扩大。

这说明 AI 产品的体验不能只用最终页面来解释。设计师还要理解系统在中间做了什么，以及这些动作如何改变结果。

2.1.3　不确定不等于不可设计

面对不确定系统，一个常见误区是认为设计师无法再预先定义体验。既然模型每次可能给出不同结果，似乎只能先让它运行，再看会发生什么。

其实，不确定性越高，越需要稳定的外层结构。设计师不一定能规定 Agent 的每一句话，却可以规定它能使用哪些资料；不一定能提前画出每一种生成结果，却可以规定结果必须包含来源、状态和下一步；不一定能预知 Agent 会采用哪条路径，却可以规定高风险动作必须确认、失败后必须停止、所有外部修改必须留下记录。

可以把一款成熟的 AI 产品理解为“确定性外壳包裹概率性能力”。模型负责在开放问题中理解和生成，规则负责守住权限、状态、格式和业务底线，界面负责让人看见关键变化并在需要时接管。

这也意味着，不是所有地方都应该使用最自由的 Agent。Anthropic 在区分工作流与 Agent 时指出，工作流由预先定义的代码路径编排模型与工具，更适合步骤清楚、需要一致性的任务；Agent 动态决定过程和工具，更适合难以预知步骤的开放任务，但会以更高的延迟、成本和风险换取灵活性。² 对设计师来说，这个区别很重要：如果报销规则完全明确，固定工作流可能比一个自由规划的 Agent 更稳定；只有遇到票据异常、政策冲突和复杂例外时，才需要让模型做更开放的判断。

还要再往前一步：如果普通规则、搜索或计算已经能稳定而低成本地解决问题，就没有必要为了“智能”引入模型。AI 不是默认答案，它只在开放输入、复杂模式或动态环境确实超出确定性方案的能力时才有价值。否则，团队只是主动增加了一层延迟、成本和不确定性。⁹

因此，第一项新的设计能力不是把所有产品变成 Agent，而是判断哪里需要确定，哪里可以生成，哪里允许系统自主选择。

2.1.4　设计师需要补上的问题

在确定性软件里，设计评审经常围绕页面是否完整、流程是否顺畅、操作是否容易理解展开。面对不确定系统，还需要补上几组问题：

• 系统这次判断使用了哪些输入和上下文？
• 哪些结果来自事实，哪些结果来自推断？
• 同一任务可能出现哪些合理但不同的路径？
• 什么时候应该追问，什么时候可以继续？
• 哪些错误可以自动恢复，哪些错误必须交给人？
• 系统能力或模型变化之后，原有体验是否仍然成立？

这些问题共同说明，设计对象已经越过界面，进入系统行为本身。

2.2　设计对象的迁移：从界面，到意图、计算与交互

“AI 时代还需不需要 UI”是一个经常被讨论的问题。有人认为自然语言会取代按钮、菜单和页面，用户以后只要说出目标，系统就能完成全部工作；也有人认为聊天框效率低、信息密度小，传统图形界面不会被替代。

这两个判断都只看到了问题的一部分。

自然语言确实会减少一部分输入端界面。用户不必先找到正确功能，再把自己的需求翻译成软件提供的字段和选项。但当系统返回大量信息，需要用户比较方案、检查差异和判断风险时，结构化视觉仍然比一长段文字更有效。人可以用一句话表达“帮我比较三种报销方案”，却更适合在表格里检查金额、政策、缺失材料和风险。

所以，界面不会消失。它会从功能入口，逐渐变成意图表达、结果组织、状态观察、证据验证和人工接管的共同载体。

2.2.1　用“输入—计算—输出”重新看体验

在《Designing AI Interfaces》中，Louise Macfadyen 用“输入—计算—输出”组织 AI 界面的设计问题。这个结构的价值在于，它迫使设计师不再只看输入框和结果页，而是把中间的计算也纳入体验。⁷

输入是人的意图进入系统的位置。它可以是一句话、一张票据、一个被选中的对象，也可以是系统根据日历、位置和历史任务推断出来的上下文。

计算是系统理解请求、检索信息、选择模型、调用工具、应用规则和生成结果的过程。用户不需要看见全部技术细节，但需要知道系统是否仍在工作、正在做什么、是否遇到阻碍，以及哪里需要自己的判断。

输出也不只是模型生成的一段文字。它可以是一张对比表、一个临时表单、一段代码、一份审批申请，也可以是对外发送邮件、修改文件或提交订单后的真实状态。

这个框架说明，界面仍然重要，但设计师的视野需要覆盖一整条从意图到行动的链路。

2.2.2　意图不是一句提示词

现在很多产品把“意图交互”简单理解为让用户写 prompt。实际上，自然语言只是表达意图的一种方式，而且并不总是最准确。

用户说“把这些费用整理一下”，系统仍然不知道“这些”指当前文件夹、刚上传的图片，还是整个出差项目；也不知道“整理”是重命名文件、生成清单，还是直接提交报销。如果界面允许用户先选中一组票据，再选择“生成报销草稿”，最后用自然语言补充“酒店费用单独标记”，意图会清楚得多。

从这个角度看，用户的意图通常会同时经过三条通道进入系统。第一条是显式表达，例如用户输入或说出“生成报销草稿”；第二条是直接操控，例如用户选中哪些票据、调整哪个字段；第三条是隐式上下文，例如当前所在项目、已经打开的文件、时间和用户之前授予的偏好。⁷

三条通道组合后，系统更容易理解完整意图，但隐式上下文也最容易越界。产品能够读取当前文件，并不代表可以读取整个项目；能够记住用户偏好，也不代表可以把过去的选择自动用于高风险任务。设计师既要让上下文帮助用户少说一点，也要让用户知道系统究竟多看了什么。

因此，更适合 Agent 的交互往往是自然语言与直接操控结合：语言表达目标，点击和框选表达对象，参数和控件表达边界，预览和确认表达决定。设计师真正要做的不是让用户学会写更长的提示词，而是让目标、对象、限制和完成标准能够用最低成本被说清楚。

2.2.3　计算不再只是后台实现

传统产品常用一个加载动画代表全部计算过程。对于几百毫秒完成的确定性请求，这种做法通常足够。但 Agent 可能连续工作几分钟甚至更久，依次搜索、读取、生成、执行和验证。如果仍然只给用户看一个旋转图标，用户无法判断系统是在工作、卡住，还是已经走偏。

这时，计算过程需要被设计成用户能够理解的状态。例如：

• 当前目标是什么，Agent 是否正确理解；
• 它准备执行哪些主要步骤；
• 正在使用哪个数据源或工具；
• 哪些步骤已经完成，哪些步骤失败；
• 是否出现了新的计划或范围变化；
• 下一次需要用户介入的节点在哪里。

展示这些信息并不等于实时公开模型的全部内部推理。用户需要的是能支持判断的行动信息，而不是大量技术日志。设计师要做的是把不可见的计算翻译成合适的进度、证据、差异、警告和控制。

2.2.4　生成式 UI：界面本身也开始成为输出

Google Research 在 2025 年公布的生成式 UI 实验，把这种变化推进了一步：模型不只生成内容，还会根据用户的提示动态生成网页、游戏、工具和交互界面。Gemini 的 dynamic view 可以针对同一个知识主题，为五岁儿童和成年人生成不同内容与功能，也可以为活动规划、概率学习或旅行计划生成不同的交互结构。³

这与过去“把模型生成的文字放进固定聊天气泡”有明显区别。界面不再完全由产品团队预先画好，而可能在运行时根据任务临时出现。更现实的理解不是让模型凭空“画一个界面”，而是让它解释用户意图，再从产品允许的组件、数据、动作和样式规则中选择、组合，有时生成相应的前端代码。

但生成式 UI 并不意味着设计系统失去作用。Google 的实现仍然依赖工具、系统指令和后处理，也允许产品规定统一风格。官方测试同时承认，当前生成有时需要一分钟以上，结果还会出现不准确。换句话说，运行时生成降低了预先制作每一种界面的必要性，却没有消除性能、一致性、品牌、可访问性和质量检查。

更现实的产品形态很可能是“固定骨架 + 动态局部”。全局导航、账号、权限、高风险操作和核心心智模型保持稳定；任务卡片、对比视图、辅助输入和结果布局根据当前意图变化。固定部分给用户方向感，动态部分提高适配性。

2.2.5　从画页面到定义生成规则

当界面能够动态生成后，设计师的工作不会消失，而会从设计每一个结果，转向设计产生结果的规则。

这套规则至少包括：系统可以使用哪些组件；不同任务应该匹配表格、图表、步骤还是表单；哪些信息必须始终可见；哪些操作不能被动态隐藏；不同状态如何表达；品牌语气和视觉风格如何保持；动态界面失败时怎样退回稳定版本；以及生成结果如何满足键盘操作、屏幕阅读器和不同设备的要求。

过去设计师交付一个页面，研发按页面实现；现在设计师还要交付一套界面语法，让系统知道什么情况下可以怎样组合，什么情况下必须保持不变。

这就是设计对象的第一次完整迁移：界面仍在，但界面背后的意图、计算和生成规则开始与界面本身同等重要。

2.3　从输出文本到行动链：AI 不再只是被使用的工具

早期生成式 AI 产品的主要能力是回答问题和生成内容。用户提出一个请求，模型返回一段文字、一张图片或一段代码。无论结果是否正确，影响大多停留在当前对话里，真正的复制、发送、修改和提交仍然由用户完成。

Agent 改变了这条边界。

Anthropic 将 Agent 定义为能够在完成任务时自行决定过程和工具使用的 AI 模型。它与聊天机器人的实际差异，是 Agent 会在一个循环里规划、行动、观察结果、调整，再继续，直到任务完成或需要人类输入。¹ 一旦模型拥有文件、浏览器、邮件、日历、数据库和业务系统等工具，输出就不再只是内容，而会变成现实中的副作用。

这里需要区分模型、工具和 Agent 三个层次。模型接收请求并生成结果；工具让模型能够读取外部信息或执行特定动作；Agent 则在模型和工具之上增加目标管理与动态规划，自己决定下一步该做什么。⁷

这一区分可以避免把所有带有 AI 的自动化都称为 Agent。一款产品可能只需要模型，也可能需要模型与几个受控工具，只有当任务确实需要动态决定步骤时，才需要更高的自主性。

2.3.1　从一次回答到一个循环

聊天产品的基本单位是一次回复，Agent 产品的基本单位则是一条 loop。

一条最小的 Agent loop 通常包括：理解目标，制定或选择下一步，调用工具，观察环境反馈，判断是否达到目标，再决定继续、重试、换路或向用户求助。

这个过程看起来接近人类完成复杂工作的方式，也正因为如此，它会带来传统界面很少面对的问题。计划可能改变，步骤数量可能无法预知，某个工具可能返回意料之外的信息，一次看似局部的操作也可能影响后续全部步骤。

以报销 Agent 为例，一条行动链可能如下：

如果产品只展示最终的“提交成功”，用户无法知道前面是否发生过错误。设计师需要把一条行动链拆成可以理解、检查和接管的结构。

2.3.2　能力、权限与责任不能混在一起

Agent 能完成一件事，不代表产品应该允许它默认完成。

模型可以生成一封邮件，工具可以发送邮件，但“起草”和“发送”是两种完全不同的权限；Agent 可以计算退款金额，也不等于它应该决定退款；它可以修改代码，也不等于可以直接部署生产环境。

传统界面通常把权限理解为用户能否进入某个页面、点击某个按钮。Agent 时代的权限需要进一步拆成读取、生成、修改、执行和对外影响。每上升一级，设计师都要重新考虑确认方式、可撤销性、影响半径和审计要求。

所以，Agent 产品设计不能只画出“能力清单”，还要画出行动边界。能力属于技术事实，授权属于用户选择，责任属于产品与组织安排，三者必须被分别定义。

2.3.3　不是每条行动链都要交给 Agent 自由规划

“能调用工具”也不等于“必须使用 Agent”。

如果一条任务的步骤稳定、规则清楚、失败成本高，预先定义的工作流通常更合适。例如员工报销可以使用固定流程完成票据识别、字段校验和审批路由，只在遇到政策例外时调用模型解释或请求人工判断。这样既能利用 AI 处理非结构化信息，又能保留关键业务流程的可预测性。

相反，如果任务本身开放，无法提前知道要搜索多少来源、修改多少文件或经过多少轮比较，Agent 的动态规划才更有价值。Anthropic 对工程实践的建议也是先使用最简单的方案，只在确有需要时增加 Agent 复杂度，因为自主能力往往会同时增加延迟和成本。²

从设计角度看，选择工作流还是 Agent，本质上是在选择系统拥有多大的行为自由。自由越大，越需要明确观察、停止、升级和恢复机制。

2.3.4　行为合同成为新的设计对象

当产品能够行动时，设计师需要为它定义一份行为合同。这份合同不一定是一份单独文档，但至少应该回答以下问题：

1. Agent 的目标是什么，完成的判断标准是什么？
2. 它可以读取哪些上下文，哪些信息禁止访问？
3. 它可以使用哪些工具，每个工具允许做到哪一步？
4. 哪些动作可以自动完成，哪些动作必须先预览或确认？
5. 什么情况下应该停止、追问、降级或交给人？
6. 已经完成的动作如何撤销、补偿或回滚？
7. 过程和结果如何留下可查记录？

过去设计师主要定义用户行为：用户怎样点击、怎样输入、怎样完成任务。现在还需要定义系统行为：Agent 应该怎样行动、怎样克制、怎样承认不知道，以及怎样把决定权交还给人。

2.3.5　界面从操作面板变成协作控制面

传统界面帮助用户亲自操作工具；Agent 界面则要帮助用户委托、观察和接管行动。

这类界面至少需要呈现五种信息：目标是否理解正确，当前计划和进度，正在使用的工具与数据，产生外部影响前的行动预览，以及完成后的结果和变更记录。高风险任务还需要暂停、修改目标、降低权限、撤销和升级给专家的入口。

这并不意味着所有 Agent 都要显示复杂看板。低风险、几秒钟完成的任务可以只保留简洁反馈；运行时间长、影响范围大或涉及外部系统的任务，则需要更完整的状态和控制。界面的复杂程度应该由风险、持续时间、可撤销性和用户介入频率决定。

当 AI 从给答案走向做事情，产品体验的核心也从“结果写得好不好”转向“这条行动链是否值得被委托”。

2.4　不确定性成为设计材料

在传统设计中，颜色、字体、空间、层级、动效和反馈都可以被视为设计材料。它们不是最后的装饰，而是设计师用来组织信息、引导行为和建立感受的基本元素。

AI 产品又增加了一种材料：不确定性。

不确定性过去常被当作需要隐藏的技术缺陷。团队希望模型准确率更高、回答更稳定、错误更少，似乎只要模型继续进步，设计就可以回到确定性软件的老路。模型能力当然会提高，但只要系统需要解释开放意图、处理不完整信息和面对变化的环境，不确定性就不会完全消失。

设计师真正需要做的，是区分不同的不确定性，并为它们设计不同的表达和处理方式。

2.4.1　五种常见的不确定性

第一种是意图不确定。用户说“把这个处理一下”，系统不知道对象、范围和完成标准。解决办法不是猜得更勇敢，而是通过选择对象、补充上下文或提出关键问题缩小歧义。

第二种是信息不确定。系统缺少资料、来源过期或数据彼此冲突。这里需要显示来源、时间和缺口，而不是用流畅语言把冲突抹平。

第三种是模型不确定。同样输入可能得到不同分类、摘要或方案。设计师需要考虑是否提供多个候选、允许重试、让用户编辑，或把高风险判断交给更稳定的规则和人工。

第四种是工具与环境不确定。接口可能失败，权限可能不足，网页结构可能变化，Agent 也可能无法确认一次外部操作是否真正成功。这里需要明确执行状态、重试条件和结果回执。

第五种是后果不确定。系统知道自己准备做什么，却无法确定这项操作会不会触发更大影响。例如修改一个共享文件可能打断其他人的工作，发送一封邮件可能形成商业承诺。这里需要行动预览、影响范围和必要审批。

把这些问题全部压缩成一个“置信度 82%”通常不够。意图、数据、模型、工具和后果的置信度来自不同位置，也需要不同的人处理。设计师应该优先告诉用户“哪里不确定、为什么重要、现在可以做什么”，而不是只给一个看似精确的数字。

即使只看模型结果，也不能只看一个总准确率。把一张正常票据误判为异常，会增加人工复核；把一笔真实异常误判为正常，则可能造成直接损失。两套系统的准确率可以相同，误报和漏报的分布及现实代价却完全不同。《UX for AI》用 Value Matrix 把真阳性、真阴性、误报和漏报分别放回真实业务后果中比较。⁹ 对设计师来说，这会直接决定自动化边界：误报代价高，就要提高执行门槛；漏报代价高，就要扩大检查范围并把可疑项交给人。阈值、确认和人工接管不应该由一个好看的百分比决定，而应该由错误发生后谁会受影响、能否撤销以及代价多大来决定。

2.4.2　把不确定性变成状态和控制

微软 HAX Toolkit 总结的 18 条人机 AI 交互指南中，有多条都在处理不确定性：让用户知道系统能做什么、做得有多好；系统错误时支持高效修正；无法确定目标时缩小服务范围；解释系统为什么这样做；谨慎更新和适配，并提供全局控制。⁴

这些原则背后有一个共同思路：不要只在文案里提醒“AI 可能犯错”，而要把不确定性变成可操作的界面状态。

例如，当系统不能确定两张票据是否重复时，可以并排展示并让用户选择；当政策来源冲突时，可以暂停提交并标出两个版本；当工具无法确认是否写入成功时，应该先查询外部状态，而不是直接再提交一次；当 Agent 准备扩大读取范围时，应明确说明为什么需要以及会访问什么。

用户真正需要的不是被反复告知系统不完美，而是拥有处理不完美的办法。

2.4.3　解释的目标是帮助判断，不是说服用户

透明度并不是越多越好。把所有提示词、思考过程、日志和工具返回值同时展示出来，会增加用户负担，也可能让一段流畅解释制造过度信任。

更有价值的解释通常与当前决定直接相关：系统使用了哪些关键资料，为什么选择这项动作，有没有冲突信息，这个结果会产生什么影响，以及用户还能选择什么。

对低风险任务，默认展示结果和少量依据即可；对高风险任务，需要展开证据、变化范围和替代方案；对专业用户，可以继续提供更细的日志和参数。解释应该分层，而不是把所有复杂性平均倒给每个人。

2.4.4　把失败设计提前

传统原型经常先展示理想路径，错误状态在开发后期补齐。AI 产品如果沿用这种习惯，很容易只演示“模型表现最好的一次”，忽略真实使用中必然出现的模糊输入、错误检索、工具失败和意外后果。

微软 HAX Playbook 的核心做法，是在完整系统建成前主动枚举人机交互失败，并用低成本方式模拟这些失败，让团队提前设计恢复路径。⁵ 对设计师来说，这意味着原型不应只测试 Agent 能不能成功，还要测试：它不知道时会怎样表达，做错时用户能否发现，被纠正后能否继续，以及失败后有没有留下不可恢复的副作用。

一个 AI 原型至少应该包含一条成功路径、一条信息不足路径、一条工具失败路径和一条人工接管路径。只有这样，团队测试的才是系统，而不是一段精心挑选的演示。

2.4.5　不确定系统仍然需要稳定承诺

用户可以接受结果存在变化，但很难接受产品的底线也跟着变化。

Agent 可以选择不同搜索路径，但不能忽然访问未授权数据；可以生成不同界面，但关键操作不能每次换位置；可以提出不同方案，但不应隐藏不利证据；可以根据上下文调整语气和内容，却不能擅自改变用户已经设定的风险偏好。

因此，不确定性作为设计材料，并不是追求随机和惊喜，而是在稳定承诺之内保留适应空间。设计师需要明确哪些内容允许变化，哪些原则永远不变。

2.5　个性化为什么变得空前重要：生成成本的坍缩

个性化并不是 AI 时代才出现。电商会根据浏览记录推荐商品，音乐平台会生成个人歌单，新闻应用会调整内容排序。传统个性化主要是在团队预先准备好的内容、模块和路径中进行选择：系统判断用户属于哪一类，再把相应版本展示出来。

这种方式有一个明显限制。每增加一种页面、内容和流程，团队都要重新设计、开发、测试和维护。用户差异很多，但产品不可能为每个人预先制作一套软件，所以大部分个性化最终只能停留在推荐顺序、默认值、主题和少量内容变化上。

生成式系统改变的不是个性化需求，而是生产个性化体验的成本结构。内容、代码和界面可以在运行时组合，团队不必提前穷举全部结果。这使产品第一次有机会根据用户当下的任务、能力、设备和环境，临时生成更适合这一刻的表达方式。

2.5.1　从“人群画像”到“此时此刻”

传统个性化经常依赖长期画像：用户过去买过什么、看过什么、属于哪个年龄和消费群体。画像有价值，但它总是在用过去解释现在，也容易让产品过度收集数据。

《Sentient Design》把更细的适配称为 individualized experience，可以理解为“个体化体验”。它不只记住用户偏好，更关注当前情境。例如，同一份 30 页报告，用户在办公室可能需要可筛选的图表，准备开会时可能需要五分钟摘要，开车途中则更适合音频。内容没有改变，适合的媒介、密度和操作方式却不同。⁸

这种个体化并不要求系统知道一个人的全部历史。当前目标、设备状态、时间限制和用户主动提供的偏好，往往已经足以形成有价值的适配。对设计师来说，这比无边界地收集用户数据更克制，也更容易解释。

2.5.2　生成成本下降，不等于总成本消失

Google 的生成式 UI 实验展示了按提示生成完整交互体验的可能性。系统可以针对儿童和成人采用不同内容和功能，也可以根据任务生成画廊、模拟器或规划工具。用户不再只能从产品预先准备的应用目录中选择，而可以得到为当前问题临时构建的界面。³

从生产角度看，每增加一个变体的边际制作成本确实在下降。过去新增一个页面需要设计师画稿、工程师开发、测试人员验证；现在模型可以复用组件和规则即时组合出候选结果。

但这里必须保持克制。生成仍然消耗算力和时间，动态结果仍然需要评估，错误界面可能比错误文本造成更大误导，品牌和可访问性也不能靠模型自动保证。Google 的研究明确提到，当前实现有时需要一分钟以上，并会出现不准确。因此，成本不是消失，而是从“逐个制作”转移到了算力、规则、验证和治理。

这也是为什么生成式 UI 时代设计系统会更重要。没有稳定组件、语义、权限和评价标准，系统虽然能快速生成很多界面，团队却无法确认哪些界面可以使用。

2.5.3　个性化的对象不只是视觉风格

真正有价值的个性化，不是让每个人看到不同颜色和圆角，而是让系统根据任务改变信息与行动方式。设计师可以从五个层次考虑：

1. 内容：同一主题需要哪些信息，语言深度如何变化；
2. 结构：适合用文本、步骤、表格、图表还是模拟器；
3. 交互：用户应该直接操作、与 AI 协作，还是委托 Agent 执行；
4. 媒介：当前更适合视觉、语音、触觉还是多模态组合；
5. 自主程度：系统只能建议，还是可以准备材料、等待确认或自动完成低风险动作。

其中，前四层改变体验如何呈现，第五层会改变人和系统的责任关系，因此必须更加谨慎。产品可以根据用户熟练度减少解释，却不应该仅凭行为推断就擅自提高 Agent 权限。

2.5.4　先定义什么不变，再定义什么可以变

动态体验最容易犯的错误，是把“更适合用户”理解为“每次都应该不一样”。如果导航、概念、关键操作和安全边界不断变化，用户无法形成稳定心智模型，个性化反而会变成不可预测。

设计师可以先把产品拆成稳定层和适配层。

稳定层帮助用户理解产品，适配层帮助产品理解当下任务。好的个性化不是两者取其一，而是在不破坏稳定承诺的前提下减少无关信息和操作。

2.5.5　偏好不能只靠系统猜

个性化还有一个经常被忽略的问题：设计偏好本身很主观。2026 年一项关于生成式 UI 个性化的研究，让 20 名受过训练的设计师反复比较同一批生成界面，结果发现他们在层级、整洁度和信息密度上的判断存在明显分歧。研究进一步发现，通过少量成对选择学习个人偏好，比只让用户写一句提示词更有效。⁶

这说明“AI 会自动懂我”不应该成为产品前提。用户需要有低成本方式表达偏好，例如在两个结果中选择、调整信息密度、固定某种布局、关闭某类推断，并能随时查看和重置系统记住的内容。

个性化应该是一段可协商关系，而不是系统在后台形成一个用户无法理解的秘密画像。

Google PAIR 把这种关系进一步描述为共同学习：用户的反馈会改变系统，系统变化后的建议又会影响用户下一步行为。¹⁰ 因此，个性化的成本不只发生在生成和验证阶段，还包括解释系统记住了什么、一次反馈何时生效，以及怎样撤销旧反馈。只允许用户不断“训练”系统，却不给查看、修改、重置和关闭的入口，个性化就会从适配能力变成无法审计的行为漂移。

2.5.6　个性化的目标是适配任务，不是制造差异

当生成变便宜后，产品很容易把“千人千面”本身当作卖点。但用户并不需要为了不同而不同的界面。他们需要的是在当前场景下，更快看见相关信息，更容易表达目标，更少承担无意义操作，并在重要时刻保留判断和控制。

如果固定界面已经能清楚解决问题，就没有必要动态生成；如果用户需要长期形成熟练操作，也不应该每次重新安排布局；如果个性化依赖敏感数据，却只带来微小便利，成本可能高于收益。

所以，个性化变得空前重要，不是因为所有界面都必须无限变化，而是因为统一体验不再只是技术和生产成本造成的必然选择。设计师需要更主动地回答：哪些差异真正影响任务，系统应该根据什么适配，适配之后如何让用户理解并控制。

本章小结

Agent 时代，设计对象发生了五次相互关联的迁移。

第一，从确定性路径迁移到受约束的可能性空间。设计师不能只定义唯一正确流程，还要理解不同结果从哪里来，哪些变化可以接受，以及错误时如何恢复。

第二，从界面迁移到意图、计算和交互。自然语言、直接操控、上下文、工具调用、动态界面与结构化输出共同组成体验，界面仍然存在，但不再是设计的全部。

第三，从内容输出迁移到行动链。Agent 会规划、调用工具并改变外部世界，能力、权限和责任因此必须被分别设计。

第四，从隐藏不确定性迁移到使用不确定性。意图、信息、模型、工具和后果的不确定性需要被转化成状态、证据、追问、确认和恢复机制。

第五，从有限的预制个性化迁移到运行时个体化。生成降低了制作变体的边际成本，也把成本转移到算力、验证和治理。设计师要先守住稳定层，再决定哪些内容可以根据此时此刻发生变化。

这些迁移最后都指向同一个事实：设计师不再只画出用户如何操作软件，还要塑造软件如何理解、行动和克制。

当系统开始代表用户行动，用户的角色也会随之改变。过去的用户是操作者，现在的用户还会成为委托者、协作者、审批者、监督者和否决者。下一章将继续讨论这种变化：用户如何从亲自完成每一步，转向与一个拥有部分自主能力的系统共同完成任务。

¹ Anthropic, “Trustworthy agents in practice,” 2026，https://www.anthropic.com/research/trustworthy-agents 。

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

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

⁴ Microsoft HAX Toolkit, “Guidelines for Human-AI Interaction,” https://www.microsoft.com/en-us/haxtoolkit/library/ 。

⁵ Microsoft HAX Toolkit, “HAX Playbook,” https://www.microsoft.com/en-us/haxtoolkit/?p=109 。

⁶ Yi-Hao Peng, Samarth Das, Jeffrey P. Bigham, Jason Wu, “Efficient Personalization of Generative User Interfaces,” 2026，https://arxiv.org/abs/2604.09876 。

⁷ Louise Macfadyen, Designing AI Interfaces, O’Reilly Media, 2026。

⁸ Josh Clark with Veronika Kindred, Sentient Design: Crafting Intelligent Interfaces with AI, Rosenfeld Media, 2026。

⁹ Greg Nudelman and Daria Kempka, UX for AI, Wiley。

¹⁰ Google People + AI Research, “Mental Models” 与 “Feedback + Control,” People + AI Guidebook，https://pair.withgoogle.com/guidebook-v2/chapter/mental-models/ ，https://pair.withgoogle.com/guidebook-v2/chapter/feedback-controls/ 。