设计对象变了——从界面到行为

第一章已经建立了两类决定空间：团队在发布前定义能力、数据、权限、风险和恢复底座，系统在运行时依据意图信号形成可修正的假设，并在边界内选择结果或路径。本章承接这个结论，继续回答一个更具体的问题：当一部分决定进入运行时，页面之外还有哪些内容需要被设计？

这里所说的“设计对象”，是团队必须描述、取舍、原型化并验证的内容。页面、组件和流程仍是设计对象，但已经不够。系统怎样解释用户表达，读取哪些上下文，如何组织计算和行动，受什么权限约束，怎样处理不确定性，以及产生什么结果，也会直接塑造体验。

为了让这些对象始终处于同一个业务情境，本章使用一个综合的差旅报销教学案例。用户把一组票据交给系统，并提出：“帮我完成这次出差报销，超出公司标准的项目先问我。”产品随后可能识别票据、匹配行程、查找政策、生成申请草稿，甚至写入报销系统。这个案例不是对某个现成产品的复述。Anthropic 的治理说明只提供了其中一个机制参照：假设系统发现酒店费用超标且缺少具体政策，它会询问用户是否允许读取公司共享盘中的费用政策，再根据获准取得的信息继续。这里扩大的是数据读取范围，不是任务目标。¹

本书始终把 Agent 定义为能围绕目标连续使用工具、检查结果并继续行动的 AI 系统。模型与工具是系统组件，指令、任务状态、权限、停止条件和反馈共同约束其行为。Anthropic 所说的“模型动态决定过程与工具使用”用于区分预定义工作流和 Agent，是厂商工程分类，不是把 Agent 定义成单一模型。²

本章依次讨论五个问题：模型、工具、Agent 系统与产品体验怎样连接；意图、上下文、计算和结果怎样形成运行时循环；行为合同怎样约束系统；不同来源的不确定性怎样进入设计；哪些对象可以在运行时适配。

2.1　先拆清四个层次

同一个模型可以被装进完全不同的产品。它可以只识别票据，也可以读取公司政策；可以生成草稿，也可以直接提交申请。体验差异不只来自模型能力，还来自工具、状态、权限、控制机制和界面。

因此，讨论“AI 会怎么做”之前，需要先区分四个层次。

表 2-1 从组件到产品体验的四个层次

这四层不是可相互替换的模块。模型和工具组成 Agent 系统，系统再通过产品体验对人可见。模型能识别金额，不说明工具已经获得写入权限；工具能够提交申请，不说明系统可以自行决定何时提交；系统完成了写入，也不说明用户已经看见真实外部状态。把层次混在一起，会让“模型做得到”悄悄变成“产品允许做”，再让“产品允许做”被误写成“用户应承担后果”。

本章讨论系统能力如何被组织成受约束的产品行为。判断、执行与后果怎样在人、系统和组织之间分配，以及人的能动性怎样保留，留到第三章展开。

2.1.1　页面之外还有一条运行时链路

“输入—计算—输出”可以帮助设计师把注意力从页面扩展到中间计算。《Designing AI Interfaces》也把它作为全书的阅读结构，同时说明这三个阶段不是完整故事，还要处理配置、解释、行动、错误和反馈。³ Agent 会保留任务状态、反复获取反馈、调用带权限的工具，并可能改变外部系统。只看三个方框，会漏掉权限检查、循环、失败和副作用。

图 2-1 从系统构成到运行时循环：模型和工具是 Agent 系统的组件，权限与不确定性贯穿循环，结果分为候选内容与外部动作／状态

这条链路不是固定的瀑布流程。系统发现政策冲突后，可以回到上下文或计划；用户修改任务目标后，系统需要重建意图假设；工具返回状态不明时，则要先核对外部系统，不能直接重试。设计师既要定义顺利向前的路径，也要定义折返、停止和恢复条件。

权限也不是链路末端的一次确认。读取票据、检索政策、写入草稿和正式提交分别需要检查；读取范围或任务范围变化时，原来的授权未必继续有效。不确定性同样会出现在每个环节，并沿后续行动传播。

2.1.2　界面仍然是设计对象，但角色变了

固定界面主要提供能力入口、结构化输入和局部反馈。运行时系统的界面还要承载四类工作：收集意图信号，呈现任务状态，提供核验证据，以及让用户授权、修正和接管。

报销产品仍需要票据列表、字段、异常标记和提交按钮。变化在于，这些界面不再只是让用户亲自完成每一步，还要让用户看见系统已经做了什么、依据什么，以及下一步会影响什么。

因此，界面没有从产品中退场。它从单纯的操作面板，扩展为人与系统共享任务状态的控制面。

2.2　意图、上下文、计算与结果

第一章已经把“意图假设”定义为本书的设计分析概念：系统依据可观察信号，对用户此刻目标形成的临时、可修正解释。它不是用户的真实意图，也不要求产品内部保存一个同名字段。

本章进一步关心这项假设怎样影响后续体验。设计师需要让意图信号、上下文、计算和结果彼此可追踪，避免一次早期误解沿着行动链不断放大。

2.2.1　意图信号需要共同确定目标、对象与边界

自然语言只是意图信号的一种。用户说“把这些费用整理一下”，系统仍然不知道“这些”指刚上传的图片、当前文件夹，还是整段行程；也不知道“整理”是生成清单、制作草稿，还是正式提交。

在报销场景中，三类信号可以相互补充：

1. 显式表达说明目标和例外，例如“生成报销申请，超标项目先问我”；
2. 直接操控明确对象和范围，例如用户选中本次出差的 12 张票据；
3. 上下文提供当前任务所需资料，例如行程订单、组织政策和已授予的偏好。

系统可以根据这些信号暂时形成意图假设，并用复述、预览或关键追问让用户修正。产品不应把“写一条完整提示词”的负担全部留给用户，也不能把沉默当作对高风险动作的授权。

2.2.2　上下文既是能力来源，也是权限边界

上下文是系统在当前任务中获准使用的信息及状态。它可能包含用户明确提供的票据、当前页面、任务历史、组织规则和外部数据。上下文越丰富，系统越可能减少重复询问；读取范围、版本冲突和隐私风险也会随之增加。

设计上下文至少要回答五个问题：来源是什么，为什么与当前任务相关，使用哪个版本，作用范围与有效期是什么，以及用户怎样查看、排除或更新它。

“系统可以获得”不等于“用户已经授权使用”。报销任务需要本次行程，不代表系统可以遍历所有私人日历；用户曾允许读取某个项目，也不代表这项授权可以自动延续到新的高风险任务。上下文发生变化时，系统还要判断已有意图假设和计划是否仍然成立。

2.2.3　计算要呈现任务状态，不公开内部思维

传统产品常用加载动画代表计算。报销 Agent 如果要连续执行识别、检索、分类、计算和写入，一个旋转图标无法告诉用户系统仍在工作、已经卡住，还是偏离了目标。

用户需要的是支持判断的任务状态：当前目标、主要步骤、已经完成的部分、正在使用的资料或工具、遇到的阻碍、下一次需要介入的位置，以及范围是否发生变化。技术日志和模型内部推理不必直接展示；它们既可能增加负担，也未必提供可靠解释。

呈现粒度应随风险变化。只读、低风险、几秒完成的任务可以只显示简短进度；运行时间长、影响范围大或会改变外部状态的任务，需要更清楚的计划、检查点、差异和回执。

2.2.4　结果要区分候选内容与外部状态

模型生成一份报销草稿，和系统已经提交一份申请，是两种不同结果。

候选内容仍有检查和编辑机会。设计重点是来源、完整性、可修改性和版本差异。外部动作则会产生副作用：写入业务系统、发送消息或修改权限后，影响可能扩散到其他人。设计重点随之增加行动预览、重复执行保护、结果回执，以及回退或补偿。

“提交成功”也不能只来自模型的语言。产品需要以外部系统返回的申请编号、状态和时间为依据；如果工具超时，系统应先核对真实状态，再决定是否重试。否则，一次不确定的工具调用可能变成重复提交。

2.2.5　生成式 UI 是结果形式之一

当系统可以生成代码，界面本身也可能成为运行时结果。Google Research 在 2025 年 11 月 18 日公开的 Generative UI 项目中，模型在特定工具、提示、后处理和视觉配置下生成网页、游戏、工具和交互结构。随附论文当时仍是审稿中的预印本；公开说明还提到部分生成需要 1 至 2 分钟，并会偶发不准确。⁴

这项条件化实现展示了运行时生成界面的可行性，不能说明动态界面已经成为成熟行业共识，也不能说明所有任务都优于固定界面。它仍处于研究与实验阶段，公开结果只在相应模型、工具、提示、后处理、任务和评估条件下成立。

在产品验证中，可以先采用“固定骨架 + 受约束的动态局部”：账号、导航、权限、高风险操作和关键状态保持稳定，任务卡片、辅助输入、对比视图和结果布局按当前任务组合。动态部分仍要遵守组件语义、品牌、可访问性、性能和失败回退规则。

图 2-2 从意图、上下文与计算到结果的可追踪链

2.3　行为合同：系统能做什么，又受什么约束

当产品只生成内容时，用户主要检查结果。Agent 连续调用工具后，计划、行动顺序、停止方式和外部影响也进入体验。设计师需要描述的，不只是一张最终页面，还有系统在不同条件下应怎样行动。

本书把这种约定称为“行为合同”：团队对系统可观察行为作出的可测试约定。它覆盖允许范围、结果要求、停止条件和恢复方式，不要求产品中存在一份同名文件，也不是把法律责任写进提示词。实际实现可能分布在产品规则、权限系统、工具接口、运行状态、模型指令和界面控制中。

开头的“超出公司标准的项目先问我”只有映射到系统结构，才构成行为合同的一部分。产品可以把它写成权限规则：检测到超标项目后，系统进入“等待用户决定”状态；界面展示票据金额、政策版本、超标差额和拟采取的处理方式；提交工具在用户作出选择前不可调用。若缺少具体政策，系统可以申请读取公司共享盘中的费用政策，授权只覆盖说明的目录与当前任务，不能自动扩展到其他文件或后续任务。

2.3.1　固定工作流与 Agent 需要不同合同

固定工作流由代码预先规定步骤和分支，模型可以参与票据识别或政策解释，但不持续决定整条路径。Agent 则由模型在系统边界内根据工具反馈选择下一步。动态路径适合步骤难以提前确定的开放任务，也会增加延迟、成本和失败组合。²

因此，报销的常规部分未必需要 Agent。票据字段校验、费用限额和审批路由如果已经有清楚规则，可以继续使用固定工作流；政策冲突、资料缺失和复杂例外才可能需要模型参与判断。选择哪种运行方式，本质上是在决定系统拥有多少路径选择权。

2.3.2　行为、权限与责任分别回答不同问题

行为回答系统在某种条件下准备做什么；权限回答它获准读取或改变什么；责任回答谁作出判断、承担职责并处理后果。

模型能识别和分类票据，是能力事实；工具可以提交申请，是技术能力；当前任务是否允许提交，是权限问题；提交前由谁决定、出错后由谁处理，则是责任安排。四者不能从前一项自动推出后一项。

本章可以定义报销 Agent 在政策冲突时暂停、在正式提交前预览，以及只在授权范围内读取资料。至于用户、产品团队和组织怎样分配判断、执行与后果，第三章会继续拆解。

2.3.3　一份行为合同至少覆盖七项内容

表 2-2 行为合同的七项设计内容

这七项用于约束可观察行为，不要求设计师预写模型的每一句话。开放部分可以变化，底线必须稳定：系统可以换一条检索路径，不能越过数据权限；可以提出不同分类，不能隐去冲突；可以调整计划，不能跳过正式提交前的授权。

2.3.4　合同要映射为状态和真实控制

行为合同需要映射成产品状态与真实控制。“等待授权”不能只是一句提示：系统必须停止创建受限动作，相关工具也必须拒绝未授权调用。用户暂停任务后，产品要核对正在进行的外部操作，再报告已完成、未开始和状态不明的部分。界面呈现目标、依据、差异和回执，是让合同可见；权限闸门、工具限制、检查点和停止条件，才让控制实际生效。

用户何时介入、以什么角色监督或接管，以及怎样承担判断与后果，留到第三章讨论。

图 2-3 行为合同的七项核心内容及其产品化落点

2.4　把不确定性设计成状态与选择

本章所说的“不确定性”，是系统对目标、信息、推断、执行状态或行动后果缺少充分把握。下面五类是本书用于定位问题的诊断视角，彼此可能重叠，也不构成完备分类。它们不能被压缩成一个统一的模型分数。

2.4.1　不同来源需要不同处理

表 2-3 五类不确定性及其设计动作

五类不确定性还会相互传播。假设一张酒店票据的金额边缘模糊，系统首先面对信息不确定性；模型仍然给出金额和费用类型时，又产生模型判断的不确定性；如果这个金额决定费用是否超标，误读便会继续影响用户对提交后果的判断。设计师需要标出传播链上的来源和受影响对象，不能只在最终结果旁显示“置信度 82%”。

不确定性与风险也要分开。风险描述某个结果可能造成的损失及影响；不确定性描述系统或人对当前情况缺少多少把握。一笔金额和收款方都已明确的大额转账仍然可能是高风险动作；一张金额模糊但只用于个人草稿的票据，也可能不确定却影响很小。实际风险取决于场景、后果、影响范围、可逆性和恢复条件，不能由不确定性高低直接推出。

能力边界、错误修正、服务范围和适配控制都应成为可见状态和可执行动作，而不能只写进免责声明。Amershi 等人的人机 AI 交互指南中，G1、G2、G9、G10、G14 和 G17 分别涉及说明能力与表现、支持纠正、在不确定时缩小服务、解释原因和提供全局控制，可作为检查项。⁵

图 2-4 不确定性来源与处理动作的分流关系

2.4.2　错误分布比总准确率更接近现实后果

即使只看系统对“是否超标”的判断，也不能只看总准确率。团队要把真实情况与系统标记交叉检查：

1. 费用真实超标，系统也标为超标，说明这笔异常被发现；
2. 费用没有超标，系统却标为超标，会增加用户或财务人员的复核；
3. 费用真实超标，系统却没有标记，可能造成违规提交或直接损失；
4. 费用没有超标，系统也没有标记，这笔费用可以按常规流程继续。

第二种和第三种都属于错误，现实代价却不同。成本敏感学习研究说明了分类错误可以具有不对称代价这一一般问题，但不会替报销产品给出自动阈值。⁶ 团队仍要结合政策、影响对象和恢复条件，决定哪些项目自动通过、哪些需要复核，以及哪些必须停止。

图 2-5 总准确率相同，错误分布与影响可能完全不同

2.4.3　解释要帮助判断

解释不是越多越好。公开全部提示词、内部推理和技术日志，可能增加负担，也可能让一段流畅叙述制造过度信任。

与当前决定直接相关的信息更有价值：系统用了哪一版政策，哪些字段来自票据，哪些内容经过推断，资料之间是否冲突，下一步会改变什么，以及用户还有哪些选择。低风险任务可以默认折叠细节，高风险节点再展开证据、差异和影响。

解释的目标是降低核验成本，不是说服用户相信系统。

2.4.4　失败要进入原型

如果原型只演示模型表现最好的一次，团队测试到的只是一个样片。团队可以在完整系统建成前枚举人机交互失败，并用低成本方式模拟，以便提前设计恢复路径；Hong 等人的 HAX Playbook 研究提供了这一方法的实践框架。⁷ 这类模拟用于发现交互失败与改进恢复设计，不能替代安全、可靠性或生产环境验证。

报销原型至少要覆盖四种状态：顺利生成草稿，缺少关键信息，工具执行失败，以及需要人工接管。团队应观察用户能否发现问题、理解原因、修正受影响部分并继续，不能只记录任务最终有没有完成。

2.4.5　变化发生在稳定承诺之内

Agent 可以选择不同检索路径，不能访问未授权资料；可以生成不同布局，不能移动或隐藏高风险控制；可以提出不同方案，不能抹去不利证据；可以适配用户偏好，不能擅自提高权限。

不确定性成为设计对象，意味着团队要明确哪些内容允许变化、变化范围有多大，以及越过边界后怎样停止和恢复。它不意味着追求随机和惊喜。

2.5　运行时适配的对象与稳定边界

第一章说明一部分决定可以在运行时发生，但“运行时决定”不等于“为每个人决定”。讨论适配时，需要把三条互不替代的轴分开：

1. 决定时点：内容、界面或路径是在发布前确定，还是在运行时确定；
2. 适配依据：系统依据通用任务条件、当前情境，还是与当前用户有关且获准使用的信号；
3. 改变对象：系统改变内容、界面组织，还是能力与任务路径。

三条轴彼此正交。运行时适配可以只依据票据数量和设备尺寸，不涉及用户差异；情境适配可以让所有处于同一情境的人获得相同结果，也不一定是个体化。个体化体验至少要使用与当前用户有关且获准使用的信号，例如用户明确设置的信息密度偏好或组织角色。⁸

2.5.1　内容、界面组织与能力路径

表 2-4 运行时可适配的对象及其稳定边界

内容变化会影响用户看见什么，界面组织会影响用户怎样理解和操作，能力与路径变化则会影响系统实际做什么。越接近权限与外部动作，通常越需要严格的治理；这不是固定的风险等级。实际风险仍由场景、后果、影响范围、可逆性和恢复条件共同决定。

2.5.2　个体化不需要永久画像

个体化可以依据当前任务中的用户信号，不必建立无边界的长期画像。报销产品可以根据用户获准使用的组织角色，向普通员工显示对应政策解释，向财务人员显示核验字段；也可以使用用户主动设置的信息密度偏好。产品要说明信号来自哪里、为何与任务相关、何时失效，以及怎样关闭或恢复默认设置。

如果产品只是根据“异常项目超过 20 项”切换为表格，这属于情境适配；如果它进一步依据当前用户获准使用的角色和明确偏好调整字段与解释，才包含个体化。无论使用哪种依据，适配都不能暗中扩大数据访问、工具能力或提交权限。

2.5.3　先固定边界，再开放适配

账号、隐私、权限与审计入口需要保持稳定；高风险动作的确认、停止方式和结果回执不能随布局变化而隐藏；对象名称、状态含义、错误反馈和恢复方式也要保持一致。品牌与可访问性要求同样适用于运行时结果。

固定界面已经能清楚解决问题时，没有必要动态生成；用户需要形成熟练操作时，也不应反复重排关键位置。运行时生成可以减少逐个制作候选变体的工作，却不会自动完成业务规则、可访问性、性能和安全验证。设计系统需要为动态组合提供允许使用的组件、语义和约束，并准备生成失败时的稳定回退。

这一节的落点是明确哪些对象可以在运行时适配、适配依据是否合法，以及哪些边界始终不变。“每个人都看到不同界面”不是运行时适配的目标。偏好学习、长期反馈和系统随时间演化的问题，留到后文讨论。

图 2-6 运行时适配的三个对象与不应越过的边界

本章小结

当一部分产品决定进入运行时，设计对象从页面与流程扩展到一组相互连接的系统对象。

第一，模型层、工具层、Agent 系统层和产品体验层需要分开描述。模型只是 Agent 系统的组件；工具提供外部能力；状态、权限、停止与反馈机制把它们组织成系统；界面让用户理解和控制这套系统。

第二，意图信号、意图假设、上下文、任务状态、计算、工具行动、结果和反馈共同组成运行时链路。“输入—计算—输出”可以作为起点，不能掩盖循环、权限、失败与外部副作用。

第三，系统行为与约束需要形成可检查的行为合同。团队要定义目标、上下文、工具、权限、停止、恢复和记录，但不能把系统能力、行动授权与责任承担混为一谈。

第四，意图、信息、模型、工具环境和后果认知提供了五个非互斥的诊断视角。不同来源需要不同的状态、证据、追问、限制和恢复机制；不确定性与风险也不能相互替代。

第五，运行时适配要分清决定时点、适配依据与改变对象。内容、界面组织和能力路径都可以变化，但稳定概念、高风险控制、权限、回执和恢复机制不能随适配漂移。

本章说明了系统可以做什么、怎样做以及受什么约束，还没有回答谁应作出判断、谁执行、谁处理外部后果。下一章将沿用差旅报销场景，讨论委托之后用户角色怎样变化，判断、执行与后果如何分配，以及产品怎样保留人的理解、拒绝、接管与停止能力。

¹ Anthropic, “Trustworthy agents in practice,” 2026 年 4 月 9 日，https://www.anthropic.com/research/trustworthy-agents 。文中的差旅报销情境是假设案例，位于 Policy 产品治理说明中，不是效果研究；它只支持“信息不足时先询问用户是否允许读取公司共享盘中的费用政策”这一机制。

² Anthropic, “Building effective agents,” 2024 年 12 月 19 日，https://www.anthropic.com/engineering/building-effective-agents 。该工程指南把 workflow 描述为预定义代码路径，把 agent 描述为由 LLM 动态决定过程与工具使用的系统，并讨论环境反馈、检查点、人类反馈与停止条件。这里采用其工程分类，不把 Agent 定义为单一模型，也不视为统一学术标准。

³ Louise Macfadyen, Designing AI Interfaces, First Edition, O’Reilly Media, 2026 年 3 月，First Release 2026 年 3 月 11 日，第 1 章 “Reading This Book: The Input-Computation-Output Structure”。作者明确说明三段结构不是完整故事，并继续处理配置、解释、行动、错误和反馈。

⁴ Google Research, “Generative UI: A rich, custom, visual interactive user experience for any prompt,” 2025 年 11 月 18 日，https://research.google/blog/generative-ui-a-rich-custom-visual-interactive-user-experience-for-any-prompt/ 。官方说明所述实现依赖特定模型、工具、提示、后处理与视觉配置；随附论文当时为审稿中的预印本。部分生成需要 1 至 2 分钟，并会偶发不准确，因此本章只把它作为研究与实验阶段的条件化可行性案例。

⁵ Saleema Amershi et al., “Guidelines for Human-AI Interaction,” CHI 2019，https://doi.org/10.1145/3290605.3300233 。本章对应 G1、G2、G9、G10、G14 与 G17，不把指南当作具体产品效果证据。

⁶ Charles Elkan, “The Foundations of Cost-Sensitive Learning,” IJCAI 2001, pp. 973–978，https://cseweb.ucsd.edu/~elkan/rescale.pdf 。论文支持分类错误代价可能不对称这一一般判断，不为报销场景提供具体阈值。

⁷ Matthew K. Hong, Adam Fourney, Derek DeBellis, and Saleema Amershi, “Planning for Natural Language Failures with the AI Playbook,” CHI 2021，https://doi.org/10.1145/3411764.3445735 。研究支持在自然语言 AI 产品部署前枚举理想与失败场景，并用低成本方式支持早期原型讨论；这类活动不能替代安全、可靠性与生产环境验证。

⁸ Josh Clark with Veronika Kindred, Sentient Design: Crafting Intelligent Interfaces with AI, Rosenfeld Media, 2026, Chapter 1, pp. 18–19。该处区分 personalized 与 individualized；本章只保留 “individualized” 的术语来源，三条适配轴、改变对象和稳定边界均为本书框架。