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

先做一个设计推演：假设几年后，一位设计师准备开始一天的工作。

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

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

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

这个场景不是对行业时间表的预测，也不是说其中每项能力都已经成熟。它把当前产品、研究原型和设计议题放进同一个情境，是为了看清：一旦产品能够根据具体的人、任务和环境，在运行过程中重新组织内容、界面与行为，设计需要提前处理哪些关系。

因此，设计的未来不能只用“更智能”“更自动”或“没有界面”来概括。更值得讨论的变化是，产品可能从一个预先完成的对象，变成一套在约束内产生体验的系统。

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

本章沿着六个方向展开：产品如何从统一软件走向个人系统，界面如何从预先固定走向运行时生成，交互如何从单一应用扩展到环境，新的问题视角如何形成，产品如何从一次性交付变成持续维护，以及在所有变化之后，设计为什么仍然需要替人保留选择。这里讨论的是方向和条件，不是所有产品都会经历的固定路线。

7.1　从统一产品到个人系统

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

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

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

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

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

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

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

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

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

表 7-1　个体化可能使用的四类信息

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

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

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

Google Gemini 的官方帮助文档把过去对话、连接应用和用户指令组织成 Personal Intelligence 的来源。对符合账户、地区和功能开放条件的用户，产品提供记忆开关、信息纠正、相关对话删除，以及针对单次对话停用个性化或重新生成非个性化结果的入口；这些入口的作用范围和删除生效时间并不完全相同。¹ 这个案例最值得注意的不是“AI 可以记住用户”，而是记忆本身开始成为需要设计的产品对象：它有来源、开关、作用范围、纠正方式和删除状态。

Apple 的 App Intents 则展示了另一种系统级结构。应用可以用 schema 描述自己的动作和内容实体，把实体与界面关联，并声明能够在应用之间传递的类型，使系统获得可发现、可调用的能力描述。² 这不等于所有应用和平台都已经支持任意跨应用编排，却说明应用能力可以从只存在于页面和菜单中，进一步成为系统能够读取的结构化接口。

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

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

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

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

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

生成式界面的个体偏好也比想象中更难概括。2026 年一项预印本研究让 20 位受过训练的设计师对同一批 600 个生成界面作出成对选择。研究发现，即使参与者都会使用“层级”“整洁”等相似概念，他们对什么是好的层级、这些原则应该怎样排序，仍然存在明显分歧。研究团队因此没有尝试建立唯一的通用审美评分，而是通过简短的成对选择学习个人偏好。³ 这项研究检验的是特定数据集上的偏好建模，不是长期产品使用研究；它支持“偏好存在差异”，不能证明任何个体化机制都能持续理解一个人。

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

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

在采用系统级个体化的产品中，设计师的任务不是替每个用户单独画一套界面，而是设计能够安全地产生差异的规则。

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

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

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

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

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

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

图 7-1 从统一产品到个人系统的构成与约束

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

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

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

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

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

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

表 7-2　运行时生成的三个层次

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

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

一项预印本研究让语言模型针对研究选定的查询生成结构化、可交互的界面。在这些比较任务中，参与者有超过 70% 的选择偏向生成界面而不是纯对话。⁵ 这个结果不能代表所有用户和任务，更不能证明聊天界面会消失；它只说明在部分任务中，人们可能需要的不只是另一个答案，而是更适合当前任务的操作环境。

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

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

A2UI 提供了一个可供比较的协议结构。Agent 不直接发送需要执行的 HTML 或 JavaScript，而是用声明式数据表达界面意图；客户端预先提供允许使用的组件目录，并使用本地组件完成渲染。界面结构、数据状态和具体视觉呈现相互分离，消息还可以经过 schema 验证。⁶ 截至本书校订时，公开生产版本为 v0.9.1，v1.0 仍是候选版本；这种协议可以收窄任意代码执行面，但不能单独证明业务权限、数据使用和交互结果已经安全。

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

图 7-2 运行时界面的稳定底座、可变结构与运行内容

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

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

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

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

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

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

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

Google Research 2026 年的一项银行原型研究，让界面根据明确指令、推断需求和实时情境生成新功能或重新组织结构。在 72 人参与的被试内比较中，生成版本的系统可用性量表得分高于固定版本。⁷ 但这个结果来自单一银行原型和短期任务，测量的是感知可用性，不能据此宣布固定界面已经过时，也不能外推生产环境中的安全性。它更有价值的启发是：设计师需要从一个个页面的作者，转向产生界面的原则、规则和约束的设计者。

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

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

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

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

Microsoft Research 在一个 16 人原型研究中也发现，依据当前提示生成的控件可以降低补充上下文的门槛、提高参与者的控制感，但同时会增加认知负荷并降低可预测性。⁸ 这个小样本结果适合用来提出检查问题，不能当作动态控件普遍优于固定控件的结论。设计师不能只问“界面能不能生成”，还要问“变化是否真的降低了用户完成任务的总成本”。

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

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

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

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

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

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

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

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

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

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

系统需要判断：

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

过去，界面主要组织屏幕上的空间；在环境化产品中，设计师还需要组织注意力、时间与物理空间。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图 7-3 环境化交互既要协调多种信号，也要知道何时退场

7.4　从功能清单到八种问题视角

当设计对象从页面扩展到意图、上下文、能力、行为和治理，设计团队需要增加一组问题视角。

下面八项不是新的职业标准，也不要求每个项目和每位设计师全部包办。它们是本书前六章问题的索引：团队可以按任务后果选择所需视角，再让产品、研究、设计、工程、业务、安全和合规角色共同承担。

表 7-3　智能系统设计的八种问题视角

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

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

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

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

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

图 7-4 智能系统设计的八种问题视角

7.5　从一次性交付到持续维护与再验

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

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

因此，具有模型、工具和运行时变化的 AI 产品，需要持续维护与再验。下文偶尔使用“培育”这个比喻，指的是团队对版本、反馈、失败和质量主张的生命周期管理，不是系统在无人负责的情况下自行学习或成长。

7.5.1　真实使用会产生新的证据

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

NIST 的 AI 风险管理框架把治理、映射、测量和管理设置为贯穿系统生命周期的持续活动。框架提出的部署后工作包括收集用户和相关角色的输入，建立申诉与推翻机制，处理退役、事件响应、恢复与变更管理，并把可衡量的持续改进活动纳入系统更新。¹² 这些是自愿性风险管理框架中的活动，不是对所有产品一概适用的法定要求。

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

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

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

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

表 7-4　三类反馈及其处理路径

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

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

图 7-5 三类反馈需要分流、授权与回退

7.5.3　团队需要维护失败、版本和质量主张

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

设计师需要参与组织、并与相应责任角色共同维护的内容包括：

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

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

7.5.4　受控适应需要变化说明和回退

未来产品可能拥有更强的适应能力：根据用户明确设置改变输出和界面，或在获准范围内根据反复出现的需求提出新的工作方式。适应不等于自主生效；影响业务规则、权限和真实后果的变化，仍然需要由有权角色评审、验证和发布。

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

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

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

从一次性交付到持续维护，设计工作的范围会从塑造一个完成品，扩展为参与维护一组长期关系：系统与用户目标的关系，行为与规则的关系，反馈与变化的关系，以及能力增长与责任边界的关系。谁能修改规则、批准版本、扩大权限和处理事故，仍要由组织明确指定，不能笼统归给“设计师”。

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

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

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

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

7.6.1　越顺滑的系统，越可能隐藏决定

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

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

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

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

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

表 7-5　把选择权转化为可检查的产品能力

OECD 的人本 AI 原则把个人自主、人类能动性和监督列为重要保障。UNESCO 的 AI 伦理建议进一步提出，人可以在有限情境中选择让渡控制，但最终责任与问责仍要归属于相应的人或法律实体；在数据治理框架中，个人还应能访问和删除自己的个人数据，并获得纠正决定与损害补救的机制。¹³¹⁴ 这些原则的适用方式仍受具体法律、角色和情境约束，不能被压缩成一个让末端用户独自承担后果的“同意”按钮。

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

图 7-6 把抽象的选择权落实为六种产品能力

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

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

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

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

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

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

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

第一章解释了确定性软件的基础假设为什么发生变化。第二章把设计对象从界面扩展到意图、上下文、能力、行为、表达和治理。第三章讨论用户怎样从操作者变成委托者、监督者和否决者。第四章把设计思维从规定单一路径扩展为管理可能性空间。第五章重新定义好设计：不仅要有任务与使用质量，还要检查行为边界、校准依赖、回溯、接管恢复、长期影响，以及特定情境中的判断能力保护。第六章再讨论设计师怎样把代码、设计系统和结构化交付材料带进 Agent 工作流。

来到最后一章，这些变化汇合成一组有条件的方向：产品可能更个体化，部分界面可能在运行时形成，交互可能进入更多环境，设计会扩展出新的问题域，系统也需要在上线后持续维护。代码、模型和规则如何成为设计材料，已经由第六章具体展开。

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

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

AI 产品可以让用户更少学习软件结构，更少重复执行步骤，也更少在不同工具之间搬运信息。判断这种产品是否优秀，不能只看它省掉了多少步骤，还要看它是否要求用户用便利交换控制：人能否知道系统正在怎样理解自己，能否修改这种理解；机器承担规模、速度和重复之后，目标、价值、例外和后果是否仍交给有信息、有权力也有职责的人判断。

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

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

本章小结

本章提出六个相互关联的未来方向。它们是供团队检验的设计命题，不是行业发展的必经阶段。

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

第二，部分界面可以在运行时形成。生成内容、编排界面和生成能力具有不同风险。在采用这种方式的项目中，设计师不仅画页面，还要定义稳定底座、组件语义、生成规则、权限、回退和验收标准。固定界面仍然适合高频、稳定、高风险和依赖熟练度的任务。

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

第四，设计需要增加意图、上下文、委托关系、不确定性、Agent 行为、生成式 UI、eval 和运行时治理等问题视角。它们未必成为独立岗位，也不要求单个设计师全部负责，但能帮助团队看见页面之外的系统问题。

第五，具有运行时变化的产品需要从一次性交付走向持续维护与再验。真实使用会产生新证据。个人偏好、任务纠正和事故风险需要进入不同反馈回路，模型、工具、权限、规则和质量主张都需要被持续观察、版本化、验证和回退。

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

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

¹ 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 。

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

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

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

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

⁶ A2UI, “A Protocol for Agent-Driven Interfaces” 与 “A2UI Specification,” 当前稳定版 v0.9.1、v1.0 候选版，访问于 2026 年 8 月，https://a2ui.org/ ，https://a2ui.org/specification/ 。

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

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

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

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

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

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

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

¹⁴ UNESCO, Recommendation on the Ethics of Artificial Intelligence, 2021，尤其第 35—43、54—55、73 段，https://www.unesco.org/en/legal-affairs/recommendation-ethics-artificial-intelligence 。