目录 · 第七章
第七章/43 分钟阅读/08 / 08

设计的未来——个体化、生成式与环境化

假设几年后,一位设计师准备开始一天的工作。

他没有先打开某个固定软件,再从菜单里寻找功能。系统已经根据今天的日程、正在推进的项目和上一次评审留下的问题,组织出一张临时工作台:左侧是三个需要确认的设计决策,中间是可以直接操作的原型,右侧是用户研究中的冲突证据。系统知道他习惯先看问题再看方案,因此没有把生成结果放在最前面;它也知道这个项目涉及医疗数据,所以所有对外动作都停留在草稿状态。

通勤途中,工作台没有被压缩成手机上的小号页面。系统把适合阅读的内容转到屏幕,把需要提醒的内容交给耳机,把原型操作留到办公室。到达公司之后,同一个任务在大屏上恢复,界面根据评审目标增加了比较视图和版本差异。下午,当他需要测试一个新的交互想法时,系统生成了一段可以运行的代码,而不是另一张静态效果图。

这个场景看起来方便,但很快也会暴露问题。系统为什么认为他今天仍然喜欢先看问题?这条偏好来自明确设置,还是根据过去行为推断出来的?它为什么隐藏了其他项目?界面改变之后,原来的功能去了哪里?耳机在公共空间里应该读出多少信息?系统生成的代码是否真的安全?如果用户不再认同这套工作方式,他能否关闭记忆、恢复默认、修改规则,甚至换一个系统继续工作?

因此,设计的未来不能只用“更智能”“更自动”或“没有界面”来概括。真正的变化是,产品开始能够根据具体的人、任务和环境,在运行过程中重新组织自己的内容、界面与行为。设计师不再只交付一个已经完成的对象,而是建立一套产生体验的系统。

这套系统必须同时回答四个问题:它可以依据什么变化,可以变化到什么程度,谁来判断变化是否正确,以及人怎样重新获得控制。

本章将沿着七个方向讨论这个未来:产品如何从统一软件走向个人系统,界面如何从预先固定走向运行时生成,交互如何从单一应用扩展到环境,新设计分支如何形成,产品如何从一次性交付变成持续培育,代码为什么会成为新的设计材料,以及在所有变化之后,设计为什么仍然需要替人保留选择。

7.1 从统一产品到个人系统

工业化软件擅长用同一套产品服务大量用户。

团队会先找到一组相对稳定的共同需求,再通过信息架构、导航、页面和权限,把这些需求组织成可以规模化交付的功能。用户可以修改头像、主题、快捷方式和通知,但产品的基本结构通常不会因为某个人而发生根本变化。

推荐算法已经让内容因人而异。不同用户打开同一个音乐、视频或电商产品,会看到不同歌曲、商品和信息流。但这些变化主要发生在内容层,产品怎样工作、任务怎样完成、用户拥有什么控制,仍然大体相同。

AI 正在把个性化从内容层带入系统层。未来的差异可能不只是“给你看什么”,还包括“系统怎样替你工作”。

7.1.1 个性化从内容层进入系统层

仍以项目管理产品为例。传统个性化可能按照用户角色推荐不同模板,AI 驱动的个人系统则可能进一步改变:

  • 信息怎样组织,哪些内容默认展开;
  • 一个目标被拆成哪些步骤;
  • 哪些工作交给 Agent,哪些保留给用户;
  • 什么情况下自动执行,什么情况下请求确认;
  • 使用文字、图表、表格还是语音表达结果;
  • 记住哪些长期偏好,哪些信息只服务当前任务;
  • 发现风险后怎样提醒和升级。

这样一来,两个用户面对的就不再只是同一产品里的不同内容,而可能是两套不同的工作系统。新手需要更多解释、示例和检查点,专家需要更高信息密度、更少中断和更强批量能力;财务人员关心证据与政策版本,创意人员更需要方案分支和可逆探索;在低风险任务中,系统可以主动完成更多步骤,在资金、隐私或外部承诺面前,则需要降低自动化程度。

可以把这种个体化理解为四个层次。

层次系统可能使用的信息设计问题
明确设定用户选择的语言、密度、语气、权限和工作方式设置是否清楚,改变后何时生效?
长期记忆历史项目、反复出现的偏好、长期目标和合作关系记住了什么,是否准确,能否删除?
行为推断用户经常接受、拒绝、修改或跳过的内容行为是偏好,还是产品限制下的妥协?
当前情境设备、地点、时间、任务、在场他人和风险哪些情境可以被感知,哪些不应该被使用?

这四层不能被混成一个笼统的“系统懂你”。明确设定是用户主动表达,长期记忆来自过去,行为推断只是系统的猜测,当前情境又可能很快变化。它们具有不同的可信度、隐私风险和有效时间,也需要不同的确认与撤回方式。

7.1.2 个人系统依赖的不只是记忆,还有能力编排

一个系统即使记住很多信息,也不一定真正适合用户。它还需要知道有哪些能力可以调用,这些能力之间怎样连接,以及用户允许它做到哪里。

Google Gemini 的官方帮助文档已经把过去对话、连接应用和用户指令组织成 Personal Intelligence 的来源。用户可以开关记忆、纠正信息、删除相关对话,也可以在单次任务中停用个性化或重新生成一个不使用个性化的结果。1 这个案例最值得注意的不是“AI 可以记住用户”,而是记忆本身开始成为需要被设计的产品对象:它有来源、开关、作用范围、纠正方式和删除状态。

Apple 的 App Intents 则展示了另一种系统级结构。应用可以把自己的动作和内容实体用结构化方式提供给操作系统,使系统能够理解屏幕上的对象以及应用可以执行的动作。部分更深入的个人上下文与跨应用动作能力仍被开发文档标记为后续能力,但其接口方向已经很清楚:未来用户不一定先进入每个应用,再分别学习它们的功能;系统可以根据当前目标,在多个应用能力之间完成检索和编排。2

因此,个人系统不是一个无限了解用户的聊天机器人,而是由记忆、能力、权限和当前情境共同构成的工作环境。设计师需要同时设计:系统知道什么、能做什么、为什么现在这样做,以及用户如何改变这些条件。

7.1.3 “更懂你”也可能把过去固化成未来

个体化最容易被忽略的风险,是系统会把过去当成未来。

用户过去经常选择简短回答,不代表他在学习新领域时仍然只想看结论;过去一直独自出差,不代表这次家庭旅行也使用同一预算与节奏;用户在旧产品里反复复制内容到文档,不代表他喜欢这种流程,也可能只是旧产品缺少结构化编辑能力。

行为不等于偏好,重复也不等于认同。如果系统只根据历史行为优化,就可能把用户困在一套越来越顺滑、也越来越狭窄的路径里。

生成式界面的个体偏好也比想象中更难概括。2026 年一项研究让 20 位设计师对同一批 600 个生成界面反复作出成对选择。研究发现,即使参与者都会使用“层级”“整洁”等相似概念,他们对什么是好的层级、这些原则应该怎样排序,仍然存在明显分歧。研究团队因此没有尝试建立唯一的通用审美评分,而是通过简短的成对选择学习个人偏好。3

这个结果提醒设计师,个人系统不能只靠一段“请告诉我你的偏好”的提示词,也不能把某个平均用户模型当成所有人的默认答案。有些偏好难以被语言准确表达,用户可能只有看到两个具体方案时才知道自己更倾向哪一个;有些偏好又会随任务、能力和人生阶段改变。

7.1.4 设计差异,也要设计差异的边界

未来设计师的任务不是替每个用户单独画一套界面,而是设计能够安全地产生差异的规则。

一套可用的个体化机制至少需要满足四个条件。

第一,差异可见。用户应该知道当前体验是否使用了历史记忆、连接应用、位置或其他个人信息,重要结果还需要说明哪些个体化因素真正影响了判断。

第二,差异可改。用户可以纠正错误记忆、修改偏好、调整自动化等级,而不是只能通过反复对话“训练”一个看不见的模型。

第三,差异可暂停。用户能够针对当前任务临时关闭个性化,比较使用与不使用个人上下文时的结果。涉及健康、财务、关系或身份等敏感问题时,这种临时边界尤其重要。

第四,差异可重置。用户需要能够回到默认体验,删除不再成立的假设,并理解重置会影响哪些系统和数据。Google PAIR 的反馈与控制指南也建议允许用户修改过去的反馈,或把模型恢复到非个性化状态,因为人的需求会随时间改变。4

从统一产品到个人系统,并不意味着统一性失去价值。身份、权限、安全、无障碍和关键业务规则仍然需要稳定底座。真正的变化是,设计师要在共同底线之上,为不同的人保留适应空间,同时防止“为你定制”变成“替你决定”。

7.2 从固定界面到运行时界面

传统界面的大部分决定发生在产品上线之前。

团队提前画出页面,定义组件和状态,开发人员把它们实现为软件。用户使用产品时,内容和数据会变化,但页面结构、交互方式与功能边界通常已经确定。

AI 使一部分设计决定可以推迟到任务真正发生时。系统先理解用户要完成什么,再决定应该展示哪些信息、调用哪些控件、组织怎样的步骤。界面因此不再只是一个预先完成的容器,而可能成为系统回应的一部分。

7.2.1 生成内容、编排界面和生成能力不是一回事

讨论运行时界面时,首先需要区分三个层次。

层次变化对象例子主要风险
内容生成固定组件中的文字、图片、数据和图表在既有卡片中生成项目摘要事实错误、质量不稳定
界面编排组件、信息层级、步骤和控件组合针对预算比较生成滑块、表格和图表不可预测、不一致、入口丢失
能力生成新的逻辑、工具、工作流或代码根据目标生成一个临时计算器安全、权限、性能和真实后果

现在很多产品已经在做第一层,第二层正在快速出现,第三层则需要更严格的沙盒、权限、测试和人工确认。把三者都称为“AI 生成页面”,很容易低估它们之间的风险差异。

运行时界面之所以有吸引力,是因为聊天并不适合表达所有任务。比较多个方案时,表格可能比连续对话清楚;调整预算时,滑块和图表比反复修改数字高效;需要确认一组字段时,表单比逐项问答更容易检查;探索系统原理时,一个可以直接操作的模拟器比一段解释更容易理解。

一项关于生成式界面的研究让语言模型根据任务主动生成结构化、可交互的界面。在该研究覆盖的多种任务中,参与者超过 70% 的情况下更偏好生成界面而不是纯对话。5 这个结果不能证明聊天界面会消失,但它说明用户需要的往往不只是另一个答案,而是一个更适合当前任务的操作环境。

7.2.2 运行时生成需要稳定底座

界面可以生成,并不等于系统应该随意生成任意前端代码。

A2UI 提供了一个值得参考的结构。Agent 不直接发送需要执行的 HTML 或 JavaScript,而是用声明式数据表达界面意图;客户端预先提供允许使用的组件与函数目录,并使用自己的可信组件完成渲染。界面结构、数据状态和具体视觉呈现相互分离,生成结果还要经过 schema 验证。6

这意味着运行时界面可以分成三层。

包含内容变化原则
稳定底座身份、权限、安全边界、审计、关键导航、品牌与无障碍基线不应被一次生成自由修改
可变结构信息层级、任务步骤、组件组合、确认点和自动化程度在批准的规则与组件目录内变化
运行内容文本、数据、建议、图表、状态和反馈根据当前上下文实时生成

这种结构和空间设计中的“支撑体—填充体”很相似。建筑的承重、消防和公共设施需要稳定,房间布局、家具和使用方式可以变化;AI 产品中的身份、权限和安全规则是支撑体,组件组合、任务流程和内容则是填充体。灵活性来自层次分离,而不是让所有东西都保持不确定。

如果没有稳定底座,生成式界面会迅速遇到问题。删除动作可能每次出现在不同位置,用户无法形成肌肉记忆;关键确认可能被系统为了“减少步骤”而隐藏;组件虽然视觉统一,却缺少错误状态和无障碍信息;模型生成了看似合理的输入框,却不知道字段需要什么业务校验。

所以,生成能力越强,设计系统越不能只是一套颜色、字体和圆角。它还需要包含组件语义、适用条件、禁用条件、数据要求、风险等级、状态行为、无障碍规范和验证规则。

7.2.3 设计师从画页面转向设计变化规则

过去,设计师通常决定某个页面最终长什么样。未来,设计师还需要决定一类界面可以怎样形成。

交付物会从一组页面扩展为:

  • 组件和语义目录;
  • 信息进入界面的优先级;
  • 不同任务适合使用的交互模式;
  • 允许变化和必须稳定的区域;
  • 不同风险对应的确认方式;
  • 生成失败后的回退界面;
  • 品牌、无障碍和内容规则;
  • 评价生成结果的 eval 与人工标准。

Google Research 2026 年的一项银行原型研究,让界面根据明确指令、推断需求和实时情境生成新功能或重新组织结构。72 人的对照实验中,生成版本的可用性量表得分显著高于固定版本。7 但这个结果仍然来自单一原型和短期任务,不能据此宣布固定界面已经过时。它更有价值的启发是:设计师需要从一个个页面的作者,转向产生界面的原则、规则和约束的设计者。

新的工作还包括验证“变化本身”是否可用。团队不能只测试某个生成结果,而要测试一组可能性:同一任务多次生成是否仍然保持关键功能,低视力用户是否总能找到主要操作,高风险确认是否会被任何布局省略,语言变长或数据为空时结构是否仍然成立。

7.2.4 固定界面仍然有不可替代的价值

生成不是界面的默认答案。

当任务高频、目标明确、步骤稳定时,固定界面通常更快,也更容易形成习惯。一个每天执行几十次的收银操作,不应该因为系统每次“理解了不同上下文”而改变按钮位置;医疗、财务和设备控制中的关键流程,需要清楚、稳定且可审计;复杂专业工具依赖长期学习形成的空间记忆,如果界面持续重组,适应成本可能高于生成带来的收益。

Microsoft Research 对动态 AI 控件的研究也发现,依据当前提示生成的控件可以降低补充上下文的门槛、提高用户的控制感,但同时会增加认知负荷并降低可预测性。8 这说明设计师不能只问“界面能不能生成”,还要问“变化是否真的降低了用户完成任务的总成本”。

可以用四个变量判断是否适合运行时生成:

  1. 任务变化有多大。长尾、探索和一次性任务更适合生成,重复稳定任务更适合固定。
  2. 错误后果有多大。风险越高,稳定结构、明确确认和可回溯要求越强。
  3. 用户是否依赖熟练度。专家高频操作通常需要保持位置与快捷方式稳定。
  4. 结果能否被验证。生成结构如果无法自动检查和人工审查,就不应直接进入真实执行。

因此,未来界面的形态更可能是固定与生成共存:稳定底座提供认知、品牌和安全连续性,运行时界面为具体任务组织最合适的表达。设计师不再决定每一次界面必须长什么样,但必须决定它不能怎样变化。

7.3 从单一应用到环境化交互

现在大部分数字产品仍然要求用户先找到入口。用户解锁设备、打开应用、进入页面,再向系统表达目标。即使使用语音助手,也通常需要唤醒一个明确的服务。

当模型能够同时处理语言、图像、声音、位置和屏幕内容,交互入口会逐渐附着在用户所处的环境中。汽车、眼镜、耳机、手表、家庭设备、办公空间和公共设施都可能成为同一任务的不同触点。

这不只是“多几个终端”。从单一应用到环境化交互,真正扩大的,是人与系统建立关系的场域。

7.3.1 交互从打开应用转向进入情境

在单一应用中,产品通常知道用户正在使用什么功能。环境化系统面对的情况更加复杂:用户可能正在走路、做饭、开会、驾驶或与他人交谈;他看向一个物体,不一定是在要求系统识别;他提到“那份文件”,可能指眼前屏幕、刚才的对话、桌上的纸张或另一个设备里的内容。

因此,环境化交互不是让系统随时随地回应,而是让系统理解当前情境是否适合介入。

系统需要判断:

  • 用户的注意力现在在哪里;
  • 哪种输入方式最自然;
  • 哪个设备最适合呈现结果;
  • 当前内容是否适合在公共环境中表达;
  • 任务需要立即处理,还是应该延后;
  • 一个设备离线或传感器失效时怎样继续。

过去,界面主要组织屏幕上的空间;未来,设计师还需要组织注意力、时间与物理空间。

7.3.2 多模态的难点是协调,而不是数量

语音、手势、视线、触摸和图像并不是各自独立的功能。用户可能先用视线指向对象,再用语言提出问题;系统用语音给出简短结果,同时在屏幕上显示可以进一步检查的证据;当环境变得嘈杂时,输出需要从声音切换到文字;当用户双手被占用时,系统又要避免要求精确触控。

W3C 的多模态交互框架很早就指出,多模态系统需要交互管理器维持状态与上下文,协调不同输入输出,并根据设备能力、用户偏好和环境变化作出响应。9 这个框架虽然早于今天的大模型,但它揭示的问题没有过时:多模态不是把多个输入方式放在同一张功能列表里,而是让它们共同服务于同一个任务状态。

从设计角度看,至少需要回答四类协调问题。

第一,指代。用户说“这个”“那里”“继续”时,系统如何知道他指向哪个对象和哪段任务?

第二,接力。任务从手机转到汽车、眼镜或电脑时,哪些状态应该跟随,哪些敏感内容不应自动出现?

第三,冲突。语音说“取消”,手势却像是在确认;位置显示用户已到公司,日历却显示他在休假,系统应该相信什么?

第四,降级。摄像头被遮挡、网络中断、环境过于嘈杂或用户无法使用某种模态时,是否还有可理解的替代路径?

7.3.3 空间、身体与在场他人成为设计变量

Google DeepMind 的 Project Astra 展示了环境化助手的一种研究方向:系统可以通过手机摄像头或原型眼镜理解周围对象,在手机与眼镜之间保持对话记忆,并使用搜索、地图、日历等工具继续任务。官方也明确说明它仍是研究原型,由有限测试者参与测试。10

这个案例的重要性不在于预测所有人都会佩戴同一种设备,而在于它让现实环境成为交互上下文。用户不再需要先把世界翻译成文字,系统可以看到他看到的物体、屏幕和位置。但感知能力越强,设计问题也越接近空间、社会关系与身体经验。

例如,眼镜在会议中显示一条提醒,用户能看到,但对面的人是否知道系统正在记录和分析?助手在商店里主动比较商品价格可能很有用,在朋友家里识别物品并推断价值则可能显得冒犯。语音在独处时自然,在地铁、电梯和诊室里可能泄露隐私。视线可以降低操作成本,也可能让用户担心“看过”是否等于“选择”。

Apple 的 visionOS 设计指南建议根据任务选择满足目标的最低沉浸程度,并优先考虑视野、姿势、运动和身体舒适,而不是默认追求完全沉浸。11 这条原则也适用于所有环境化 AI:技术能够出现,不代表它应该占据更多注意力;系统看得见,不代表它应该持续解释;界面可以铺满空间,不代表空间应该被界面占满。

环境化产品会增加一组传统 App 不常处理的设计变量:

  • 距离:信息离用户多远,是否需要移动身体;
  • 方向:内容从哪里出现,声音从哪里传来;
  • 可见性:只有用户看见,还是在场他人也能看见;
  • 持续性:内容停留多久,用户离开后是否继续存在;
  • 领地:系统是否进入了家庭、工作、公共与亲密空间;
  • 礼仪:什么时候主动出现会帮助人,什么时候会打断人与人的关系。

7.3.4 环境化系统必须知道什么时候不出现

“无处不在”不是环境化交互的质量标准。一个持续监听、持续提醒、持续猜测目标的系统,很可能比一个需要主动打开的应用更令人疲惫。

好的环境化系统需要拥有沉默、等待和退出的能力。

首先,主动介入应该有可理解的触发条件。系统可以在风险、截止时间或用户明确设定的场景中提醒,但不能只因为“可能相关”就不断争夺注意力。

其次,感知范围应该可见。摄像头、麦克风、位置和身体数据何时开启,哪些信息被保留,是否会跨设备共享,用户与在场他人都需要获得适当提示。

再次,跨设备接力不能只追求无缝。无缝意味着状态连续,也可能意味着隐私边界消失。手机里的健康问题不应自动出现在会议室屏幕,家庭设备中的对话也不应因为用户走进汽车就默认继续播放。

最后,系统需要保留非智能路径。传感器无法判断情境时,用户仍然应该能够用清楚的按钮、文字或人工服务完成任务。环境化交互的成熟,不是让界面彻底消失,而是让合适的界面在合适的地方出现,并在不合适的时候退到背景。

7.4 从功能设计到新的设计分支

当设计对象从页面扩展到意图、上下文、能力、行为和治理,一组新的设计分支会逐渐形成。

这些分支不一定立即变成八种独立岗位。更准确地说,它们是设计师面对智能系统时必须增加的八种问题视角。

设计分支需要回答的核心问题可能产生的交付物
意图设计系统怎样理解、澄清、分解和修改用户目标?意图层级、澄清策略、目标版本和冲突处理
上下文设计什么信息在何时进入系统,怎样共享、保留和遗忘?上下文地图、来源与新鲜度、记忆范围和删除机制
委托关系设计人与 AI 怎样分工,何时转移控制与责任?人机责任图、自治等级、确认与接管点
不确定性设计系统怎样表达未知、推断、冲突和风险?不确定性分类、证据、路由与兜底策略
Agent 行为设计系统怎样计划、执行、观察、调整和停止?行为状态机、工具策略、权限与失败恢复
生成式 UI 设计界面怎样在运行时安全、稳定地形成?组件目录、生成规则、约束、验证与回退界面
eval 设计怎样把“真正做得好”变成可重复检查的证据?任务样本、评分标准、轨迹检查与人工评审
运行时治理设计上线后怎样发现漂移、事故和新风险?监控信号、事件分级、版本、降权和恢复机制

以旅行 Agent 为例,用户说“帮我安排一次轻松的家庭旅行”,这句话同时触发了八类设计问题。

“轻松”到底意味着每天少去几个景点,还是减少换酒店和长距离移动?这是意图设计。系统是否可以读取家庭成员、预算、签证、学校假期和健康信息,这是上下文设计。它可以提出方案、预订可退酒店,还是能够直接付款,这是委托关系设计。机票价格会变化、天气预测不稳定、不同家庭成员偏好冲突,这是不确定性设计。

系统接下来怎样搜索、比较、规划和调用预订工具,是 Agent 行为设计。方案应该用地图、日历、价格曲线还是聊天呈现,是生成式 UI 设计。怎样判断行程真的“轻松”而不只是景点数量少,是 eval 设计。供应商接口变化、误订、退款失败和长期偏好漂移怎样被发现和处理,则属于运行时治理设计。

传统产品常把这些问题分别藏在产品、设计、算法、工程、运营与合规的工作中。未来设计的一个重要变化,是把它们放回同一段人机关系里。用户看到的是一个连续体验,团队也需要用连续的方式设计责任、证据和后果。

设计师不一定要成为模型研究员、安全工程师或法律专家,但需要知道何时问题已经超出界面,应该邀请谁共同作出决定。新设计分支的价值,不是制造更多术语,而是防止团队继续用一张页面覆盖一个行为系统。

7.5 从交付产品到培育系统

传统产品也会持续迭代,但团队通常仍然可以定义一个相对明确的发布版本:需求完成、设计验收、测试通过,产品上线。

AI 系统更难保持这种稳定。模型会更新,知识库会过期,工具接口会变化,用户会把系统带进原来没有考虑的情境,组织政策和社会规范也会改变。相同输入在不同时间可能得到不同计划,系统能力还会因为新工具和新权限扩大。

因此,AI 产品更像一个需要持续培育的系统。

7.5.1 上线只是进入真实分布的开始

上线前测试只能覆盖团队已经想到的任务和风险。真实用户会使用更混乱的资料、更含糊的目标和更多意外组合,也会把系统用于团队没有预料到的场景。

NIST 的 AI 风险管理框架把治理、映射、测量和管理设置为贯穿系统生命周期的持续活动。其部署后要求包括收集用户和相关角色的输入,提供申诉与覆盖,处理退役、事件响应、恢复与变更管理,并把可衡量的持续改进活动纳入系统更新。12

从设计角度看,这意味着发布不是设计结束,而是设计获得真实证据的开始。团队需要知道用户怎样理解系统、哪些错误没有被发现、哪些确认只是形式、哪些个性化开始偏离当前需要、哪些生成界面破坏了稳定性,以及哪些原本低风险的能力因为使用方式变化变成了高风险行为。

空间设计中有“使用后评价”:建筑交付之后,设计者继续观察真实的人如何使用、绕开和改造空间。AI 产品也需要类似机制。系统在真实环境中怎样被使用,往往比上线前演示更能暴露设计假设。

7.5.2 三种反馈不能进入同一条学习回路

“系统会从反馈中学习”听起来合理,但不同反馈具有完全不同的含义。

反馈类型例子合理处理方式
个人偏好“以后默认给我看详细版本”在用户可见、可修改和可重置的个人范围内生效
任务纠正“这张发票应该归到差旅,不是办公用品”修正当前结果,是否成为长期规则需要进一步判断
事故与风险Agent 使用旧政策、越权发送或错误付款进入事件复盘,更新 eval、权限、规则和系统版本

如果把一次任务纠正直接变成全局规则,系统可能为了修复一个用户的特殊情况而制造新的错误;如果把所有拒绝都当成偏好,用户为了检查结果而作出的修改也可能被误读;如果事故只被记录为一次差评,团队就无法发现权限和治理问题。

Google PAIR 的指南强调,团队需要说明反馈会怎样改变 AI、多久产生影响,并让用户理解反馈的范围。4 这意味着反馈机制不能只有赞和踩。设计师需要让用户表达“事实错误”“不符合我的偏好”“缺少证据”“这次任务例外”“系统不应该做这件事”等不同含义,团队才能把反馈路由到正确层级。

7.5.3 设计师需要维护失败、版本和质量标准

培育系统并不是每天人工修正模型输出,而是建立让系统能够被持续观察、校准和约束的机制。

设计师需要维护的内容会包括:

  • 真实失败与近失事件;
  • 用户修改、拒绝和接管的原因;
  • 代表性任务与边界样本;
  • 组件、规则、提示词、模型和工具版本;
  • 个体化假设和记忆的来源;
  • 自动化等级与权限变化;
  • 质量标准、eval 和人工评审结果;
  • 事故后的修复、降权、回滚和通知。

这些工作会改变“设计完成”的定义。一张界面通过评审,并不能证明它在新的数据、模型和任务中继续成立;一条规则曾经有效,也不能保证用户目标变化后仍然合理。设计师需要把规则当成可以被证据推翻的假设,而不是永远正确的规范。

7.5.4 自我进化也需要变化说明和回退

未来产品可能拥有更强的自我调整能力。它会根据用户直接命令增加功能,也会从反复出现的需求中推断新的工作方式,并实时改变界面和自动化程度。

但“系统会自己进化”不应成为回避责任的理由。越是能够变化,越需要让人知道:什么发生了变化,为什么变化,依据了哪些反馈,影响哪些任务,是否经过验证,以及怎样恢复上一版本。

对个人用户来说,重要变化应该进入可理解的记录,例如“根据你最近三次修改,摘要默认从三段调整为五点;你可以撤销”。对团队来说,模型、提示词、工具、权限和设计规则要能够分别版本化,出现问题时才能定位变化来源。

自我调整还需要速度分层。输出格式和临时布局可以快速变化,业务政策、权限和高风险行为应该经过更慢的评审与验证。并不是所有部分都应该用同一种“实时学习”速度。

从交付产品到培育系统,设计师的角色会从塑造一个完成品,扩展为维护一组长期关系:系统与用户目标的关系,行为与规则的关系,反馈与变化的关系,以及能力增长与责任边界的关系。

7.6 代码成为新的设计材料

第五章讨论过,设计师需要用代码构建可运行原型,并把设计系统、Skill 和上下文带进 Agent 工作流。放到本章,代码还代表一个更长远的变化:设计材料开始从静态对象变成可运行系统。

未来优秀的设计师不一定是写最多代码的人,而是能够把意图、行为、界面、规则和真实后果连接起来的人。他知道什么时候应该快速生成,什么时候必须停下来验证;知道什么可以交给 Agent,什么仍然需要专业人员作出判断。

7.7 设计最终仍然是在为人保留选择

个体化、生成式与环境化,都在试图降低人与系统之间的摩擦。

个人系统减少重复设置,运行时界面减少寻找功能,环境化交互减少打开应用和翻译意图,Agent 减少手工执行,代码生成减少从想法到实现的距离。

这些变化可以增强人的能力,也可能悄悄缩小人的选择。

7.7.1 越顺滑的系统,越可能隐藏决定

个人系统会根据过去预测用户需要什么,因此可能不再展示其他可能;运行时界面会为当前任务选择“最合适”的控件,因此可能隐藏系统没有选中的功能;环境化助手在用户开口之前主动出现,因此可能把推测变成默认意图;持续学习会吸收用户反馈,因此产品规则可能在用户没有意识到时改变。

当所有决定都被包装成便利,用户可能只看见最后一条路径。

问题不在于系统做了选择。任何界面都在排序信息、设置默认和限制行为。新的风险在于,这些选择开始实时发生、因人而异,而且不一定留下稳定页面让用户比较。设计如果只优化步骤和点击,就可能在提高效率的同时降低可见性。

7.7.2 选择权需要变成具体的产品能力

“以人为本”不能只停在价值口号。它至少应该被转化为六种可以检查的产品能力。

能力用户应该能够做什么设计需要提供什么
知道理解系统使用了什么上下文、为什么给出当前结果来源、个体化标记、关键依据和变化说明
选择看到真实替代方案,比较不同目标和取舍分支、对比、默认项说明和影响预览
调整修改目标、记忆、界面和自动化程度可编辑偏好、权限刻度和局部设置
拒绝不使用某项个体化或自动化,转向其他路径暂停、关闭、跳过与非 AI 方案
恢复撤销动作、纠正结果、申诉并重新接管版本、回滚、补偿、人工升级和证据链
离开清除记忆、导出必要数据并退出系统删除、可携带性、退订和清楚的后续影响

OECD 的人本 AI 原则把个人自主、人类能动性和监督作为重要保障。UNESCO 的 AI 伦理建议也强调,人可以在有限情境中选择依赖 AI,但最终责任不能由 AI 取代,个人应拥有数据访问、删除和补救机制。1415

这些原则最终都需要通过设计落地。一个关闭按钮如果藏在多层设置里,拒绝就不是低成本选择;一个批准按钮如果没有提供证据,选择只是责任转移;一个记忆删除入口如果无法说明影响范围和生效时间,退出也不完整。

7.7.3 设计不是保留最多选项,而是保留形成选择的能力

替用户保留选择,并不意味着所有任务都要展示十种方案,也不意味着系统不能自动完成重复工作。选项过多同样会增加负担。

真正需要保留的是用户形成选择的能力:他知道目标是什么,能够看见关键差异,理解后果,在需要时改变路径,并拥有承担责任所需的信息与权力。

因此,AI 可以帮助用户搜索更多方案、模拟后果、发现冲突和完成执行,但不应该悄悄替用户决定什么值得追求。系统可以根据过去偏好安排一次旅行,却不能把过去的生活方式当成用户永远不变的价值;可以生成一个高效工作流,却不能因为效率更高就取消用户保留的学习、协商和判断过程。

有些摩擦应该被消除,例如重复录入、格式转换、机械查找和低价值等待;有些摩擦则应该被保留,例如理解目标、比较价值、确认不可逆后果和处理利益冲突。设计师需要分辨两者,而不是把“步骤更少”当成唯一进步。

7.7.4 未来设计师仍然在设计人与世界的关系

本书从一个变化开始:人与机器之间的关系,正在从人操作工具,转向人表达意图并委托机器行动。

第一章解释了确定性软件的基础假设为什么发生变化。第二章把设计对象从界面扩展到意图、上下文、能力、行为、表达和治理。第三章讨论用户怎样从操作者变成委托者、监督者和否决者。第四章把设计思维从规定单一路径扩展为管理可能性空间。第五章讨论设计师如何使用代码、设计系统、新交付物和 Agent 改变工作。第六章重新定义好设计:不仅可用,还要可信、可回溯、可接管、可持续,并且不削弱人的判断力。

来到最后一章,这些变化汇合成一个更完整的未来:产品会更个体化,界面会在运行时形成,交互会进入环境,设计会扩展出新的问题域,系统会在上线后持续生长,代码、模型和规则会成为设计材料。

但技术能力不会自动给出设计方向。系统能够理解更多,不代表应该知道一切;能够生成更多,不代表每次都应该变化;能够行动更远,不代表可以替人承担责任;能够无处不在,也不代表应该占据人的全部注意力。

设计的价值,仍然在于为能力建立秩序,为变化规定边界,为不确定性提供理解,为行动保留责任,也为人保留重新选择的机会。

未来最好的 AI 产品,可能让用户更少学习软件结构,更少重复执行步骤,也更少在不同工具之间搬运信息。但它不会要求用户用这些便利交换全部控制。它会让人知道系统正在怎样理解自己,允许人修改这种理解;会替人完成适合机器的规模、速度和重复,同时把目标、价值、例外和后果留给真正需要负责的人。

当软件开始越来越像一个行动者,设计师要做的,不是让机器看起来更像人。

而是让人在与机器共同生活和工作时,仍然能够理解、选择、改变,并成为自己目标的定义者。

本章小结

设计的未来会沿着七个相互关联的方向展开。

第一,产品会从统一软件走向个人系统。个性化从推荐内容扩展到信息结构、工作流、Agent 角色、自动化程度、记忆和确认方式。设计师需要让差异可见、可改、可暂停和可重置,防止系统把过去固化成未来。

第二,界面会从预先固定走向运行时形成。生成内容、编排界面和生成能力具有不同风险。未来设计师不仅画页面,还要定义稳定底座、组件语义、生成规则、权限、回退和验收标准。固定界面不会消失,它仍然适合高频、稳定、高风险和依赖熟练度的任务。

第三,交互会从单一应用扩展到环境。多模态的关键不是输入数量,而是共享上下文、协调状态、跨设备接力和根据注意力选择合适的表达。位置、距离、身体、在场他人、隐私与社会礼仪都会成为新的设计变量。

第四,设计会逐渐形成意图、上下文、委托关系、不确定性、Agent 行为、生成式 UI、eval 和运行时治理等新分支。它们未必立即成为独立岗位,但会成为设计智能系统时不可缺少的问题视角。

第五,产品会从一次性交付变成持续培育。上线只是进入真实分布的开始。个人偏好、任务纠正和事故风险需要进入不同反馈回路,模型、工具、权限、规则和质量标准都需要被持续观察、版本化、验证和回退。

第六,代码会成为新的设计材料。设计师面对的不再只是图形和界面,还有模型、数据、上下文、规则、权限、Agent 与运行时状态。理解这些材料不等于包办工程,而是让设计判断更早进入真实行为。

第七,所有未来方向最终都要回到人的选择权。好的系统应该让用户能够知道、选择、调整、拒绝、恢复和离开。设计不是让机器替人决定一切,而是在机器拥有更多能力之后,重新安排人如何理解、参与和负责。

AI 改变设计,最终改变的不是某个工具、某个界面或某个岗位,而是人怎样把意图交给机器,机器怎样把行动带回世界,以及设计怎样守住两者之间的边界。


1 Google, “Get personalization with memory of your past Gemini chats” 与 “Connect your Google apps to personalize your Gemini experience,” Gemini Apps Help,https://support.google.com/gemini/answer/16598469 ,https://support.google.com/gemini/answer/16598406 。

2 Apple Developer, “Apple Intelligence” 与 “Providing contextual cues to Apple Intelligence and Siri,” https://developer.apple.com/apple-intelligence/ ,https://developer.apple.com/documentation/appintents/providing-contextual-cues-to-apple-intelligence-and-siri 。

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

4 Google PAIR, “Feedback + Control,” People + AI Guidebook,https://pair.withgoogle.com/guidebook-v2/chapter/feedback-controls/ 。

5 Jiaqi Chen et al., “Generative Interfaces for Language Models,” arXiv:2508.19227, 2025,https://arxiv.org/abs/2508.19227 。

6 A2UI, “A Protocol for Agent-Driven Interfaces” 与 “A2UI Protocol v0.9,” https://a2ui.org/ ,https://a2ui.org/specification/v0.9-a2ui/ 。

7 Piyush Arora et al., “Self-Evolving Systems: Moving Beyond Deterministic Interfaces to Adaptive Generative Interfaces,” Google Research, 2026,https://research.google/pubs/self-evolving-systems-moving-beyond-deterministic-interfaces-to-adaptive-generative-interfaces/ 。

8 Microsoft Research, “Tools for Thought — Dynamic UI for AI lowers the barrier for steering AI outputs,” https://www.microsoft.com/en-us/research/project/tools-for-thought/ 。

9 W3C, Multimodal Interaction Framework, 2003,https://www.w3.org/TR/mmi-framework/ 。

10 Google DeepMind, “Project Astra,” https://deepmind.google/models/project-astra/ 。

11 Apple Developer, “Designing for visionOS,” Human Interface Guidelines,https://developer.apple.com/design/human-interface-guidelines/designing-for-visionos 。

12 NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023,https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf 。

13 Figma, “Config 2026: New Materials, New Tools and a More Expressive Canvas,” 2026,https://www.figma.com/blog/config-2026-recap/ 。

14 OECD.AI, “Human-centred values and fairness (Principle 1.2),” https://oecd.ai/en/dashboards/ai-principles/P6 。

未来优秀的设计师不一定是写最多代码的人,而是能够把意图、行为、界面、规则和真实后果连接起来的人。他知道什么时候应该快速生成,什么时候必须停下来验证;知道什么可以交给 Agent,什么仍然需要专业人员作出判断。

7.7 设计最终仍然是在为人保留选择

个体化、生成式与环境化,都在试图降低人与系统之间的摩擦。

个人系统减少重复设置,运行时界面减少寻找功能,环境化交互减少打开应用和翻译意图,Agent 减少手工执行,代码生成减少从想法到实现的距离。

这些变化可以增强人的能力,也可能悄悄缩小人的选择。

7.7.1 越顺滑的系统,越可能隐藏决定

个人系统会根据过去预测用户需要什么,因此可能不再展示其他可能;运行时界面会为当前任务选择“最合适”的控件,因此可能隐藏系统没有选中的功能;环境化助手在用户开口之前主动出现,因此可能把推测变成默认意图;持续学习会吸收用户反馈,因此产品规则可能在用户没有意识到时改变。

当所有决定都被包装成便利,用户可能只看见最后一条路径。

问题不在于系统做了选择。任何界面都在排序信息、设置默认和限制行为。新的风险在于,这些选择开始实时发生、因人而异,而且不一定留下稳定页面让用户比较。设计如果只优化步骤和点击,就可能在提高效率的同时降低可见性。

7.7.2 选择权需要变成具体的产品能力

“以人为本”不能只停在价值口号。它至少应该被转化为六种可以检查的产品能力。

能力用户应该能够做什么设计需要提供什么
知道理解系统使用了什么上下文、为什么给出当前结果来源、个体化标记、关键依据和变化说明
选择看到真实替代方案,比较不同目标和取舍分支、对比、默认项说明和影响预览
调整修改目标、记忆、界面和自动化程度可编辑偏好、权限刻度和局部设置
拒绝不使用某项个体化或自动化,转向其他路径暂停、关闭、跳过与非 AI 方案
恢复撤销动作、纠正结果、申诉并重新接管版本、回滚、补偿、人工升级和证据链
离开清除记忆、导出必要数据并退出系统删除、可携带性、退订和清楚的后续影响

OECD 的人本 AI 原则把个人自主、人类能动性和监督作为重要保障。UNESCO 的 AI 伦理建议也强调,人可以在有限情境中选择依赖 AI,但最终责任不能由 AI 取代,个人应拥有数据访问、删除和补救机制。1415

这些原则最终都需要通过设计落地。一个关闭按钮如果藏在多层设置里,拒绝就不是低成本选择;一个批准按钮如果没有提供证据,选择只是责任转移;一个记忆删除入口如果无法说明影响范围和生效时间,退出也不完整。

7.7.3 设计不是保留最多选项,而是保留形成选择的能力

替用户保留选择,并不意味着所有任务都要展示十种方案,也不意味着系统不能自动完成重复工作。选项过多同样会增加负担。

真正需要保留的是用户形成选择的能力:他知道目标是什么,能够看见关键差异,理解后果,在需要时改变路径,并拥有承担责任所需的信息与权力。

因此,AI 可以帮助用户搜索更多方案、模拟后果、发现冲突和完成执行,但不应该悄悄替用户决定什么值得追求。系统可以根据过去偏好安排一次旅行,却不能把过去的生活方式当成用户永远不变的价值;可以生成一个高效工作流,却不能因为效率更高就取消用户保留的学习、协商和判断过程。

有些摩擦应该被消除,例如重复录入、格式转换、机械查找和低价值等待;有些摩擦则应该被保留,例如理解目标、比较价值、确认不可逆后果和处理利益冲突。设计师需要分辨两者,而不是把“步骤更少”当成唯一进步。

7.7.4 未来设计师仍然在设计人与世界的关系

本书从一个变化开始:人与机器之间的关系,正在从人操作工具,转向人表达意图并委托机器行动。

第一章解释了确定性软件的基础假设为什么发生变化。第二章把设计对象从界面扩展到意图、上下文、能力、行为、表达和治理。第三章讨论用户怎样从操作者变成委托者、监督者和否决者。第四章把设计思维从规定单一路径扩展为管理可能性空间。第五章讨论设计师如何使用代码、设计系统、新交付物和 Agent 改变工作。第六章重新定义好设计:不仅可用,还要可信、可回溯、可接管、可持续,并且不削弱人的判断力。

来到最后一章,这些变化汇合成一个更完整的未来:产品会更个体化,界面会在运行时形成,交互会进入环境,设计会扩展出新的问题域,系统会在上线后持续生长,代码、模型和规则会成为设计材料。

但技术能力不会自动给出设计方向。系统能够理解更多,不代表应该知道一切;能够生成更多,不代表每次都应该变化;能够行动更远,不代表可以替人承担责任;能够无处不在,也不代表应该占据人的全部注意力。

设计的价值,仍然在于为能力建立秩序,为变化规定边界,为不确定性提供理解,为行动保留责任,也为人保留重新选择的机会。

未来最好的 AI 产品,可能让用户更少学习软件结构,更少重复执行步骤,也更少在不同工具之间搬运信息。但它不会要求用户用这些便利交换全部控制。它会让人知道系统正在怎样理解自己,允许人修改这种理解;会替人完成适合机器的规模、速度和重复,同时把目标、价值、例外和后果留给真正需要负责的人。

当软件开始越来越像一个行动者,设计师要做的,不是让机器看起来更像人。

而是让人在与机器共同生活和工作时,仍然能够理解、选择、改变,并成为自己目标的定义者。

本章小结

设计的未来会沿着七个相互关联的方向展开。

第一,产品会从统一软件走向个人系统。个性化从推荐内容扩展到信息结构、工作流、Agent 角色、自动化程度、记忆和确认方式。设计师需要让差异可见、可改、可暂停和可重置,防止系统把过去固化成未来。

第二,界面会从预先固定走向运行时形成。生成内容、编排界面和生成能力具有不同风险。未来设计师不仅画页面,还要定义稳定底座、组件语义、生成规则、权限、回退和验收标准。固定界面不会消失,它仍然适合高频、稳定、高风险和依赖熟练度的任务。

第三,交互会从单一应用扩展到环境。多模态的关键不是输入数量,而是共享上下文、协调状态、跨设备接力和根据注意力选择合适的表达。位置、距离、身体、在场他人、隐私与社会礼仪都会成为新的设计变量。

第四,设计会逐渐形成意图、上下文、委托关系、不确定性、Agent 行为、生成式 UI、eval 和运行时治理等新分支。它们未必立即成为独立岗位,但会成为设计智能系统时不可缺少的问题视角。

第五,产品会从一次性交付变成持续培育。上线只是进入真实分布的开始。个人偏好、任务纠正和事故风险需要进入不同反馈回路,模型、工具、权限、规则和质量标准都需要被持续观察、版本化、验证和回退。

第六,代码会成为新的设计材料。设计师面对的不再只是图形和界面,还有模型、数据、上下文、规则、权限、Agent 与运行时状态。理解这些材料不等于包办工程,而是让设计判断更早进入真实行为。

第七,所有未来方向最终都要回到人的选择权。好的系统应该让用户能够知道、选择、调整、拒绝、恢复和离开。设计不是让机器替人决定一切,而是在机器拥有更多能力之后,重新安排人如何理解、参与和负责。

AI 改变设计,最终改变的不是某个工具、某个界面或某个岗位,而是人怎样把意图交给机器,机器怎样把行动带回世界,以及设计怎样守住两者之间的边界。


1 Google, “Get personalization with memory of your past Gemini chats” 与 “Connect your Google apps to personalize your Gemini experience,” Gemini Apps Help,https://support.google.com/gemini/answer/16598469 ,https://support.google.com/gemini/answer/16598406 。

2 Apple Developer, “Apple Intelligence” 与 “Providing contextual cues to Apple Intelligence and Siri,” https://developer.apple.com/apple-intelligence/ ,https://developer.apple.com/documentation/appintents/providing-contextual-cues-to-apple-intelligence-and-siri 。

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

4 Google PAIR, “Feedback + Control,” People + AI Guidebook,https://pair.withgoogle.com/guidebook-v2/chapter/feedback-controls/ 。

5 Jiaqi Chen et al., “Generative Interfaces for Language Models,” arXiv:2508.19227, 2025,https://arxiv.org/abs/2508.19227 。

6 A2UI, “A Protocol for Agent-Driven Interfaces” 与 “A2UI Protocol v0.9,” https://a2ui.org/ ,https://a2ui.org/specification/v0.9-a2ui/ 。

7 Piyush Arora et al., “Self-Evolving Systems: Moving Beyond Deterministic Interfaces to Adaptive Generative Interfaces,” Google Research, 2026,https://research.google/pubs/self-evolving-systems-moving-beyond-deterministic-interfaces-to-adaptive-generative-interfaces/ 。

8 Microsoft Research, “Tools for Thought — Dynamic UI for AI lowers the barrier for steering AI outputs,” https://www.microsoft.com/en-us/research/project/tools-for-thought/ 。

9 W3C, Multimodal Interaction Framework, 2003,https://www.w3.org/TR/mmi-framework/ 。

10 Google DeepMind, “Project Astra,” https://deepmind.google/models/project-astra/ 。

11 Apple Developer, “Designing for visionOS,” Human Interface Guidelines,https://developer.apple.com/design/human-interface-guidelines/designing-for-visionos 。

12 NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023,https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf 。

13 Figma, “Config 2026: New Materials, New Tools and a More Expressive Canvas,” 2026,https://www.figma.com/blog/config-2026-recap/ 。

14 OECD.AI, “Human-centred values and fairness (Principle 1.2),” https://oecd.ai/en/dashboards/ai-principles/P6 。

15 UNESCO, Recommendation on the Ethics of Artificial Intelligence, 2021,https://www.unesco.org/en/legal-affairs/recommendation-ethics-artificial-intelligence 。