设计师的新工作

假设上一章提到的报销 Agent 已经完成开发，并准备接受验收。

团队先检查了它能不能识别票据、匹配费用类型、读取差旅政策和生成报销申请。测试结果不错：主要任务可以完成，页面没有明显卡点，Agent 的处理速度也远快于人工填写。按照传统软件的验收方式，这款产品已经具备上线条件。

但在一次测试中，Agent 引用了旧版差旅政策，把一笔原本合规的酒店费用标记为超标。审批者看到界面上写着“已根据公司政策完成检查”，便直接批准了处理结果。他没有注意到引用文件的更新时间，也没有看到新旧政策之间存在冲突。几天后，员工提出异议，团队却只能找到最终申请，无法完整还原 Agent 读取了什么、为什么这样判断、审批者又看到了哪些信息。

从任务完成率来看，系统只错了一笔；从用户体验来看，操作甚至很流畅。但从人机协作的角度来看，这次失败暴露了更深的问题：系统让人太容易相信，却没有提供足够的判断依据；保留了一个“批准”按钮，却没有让批准者真正理解后果；生成了最终结果，却没有留下可以追溯的证据链。

这说明，可用性仍然重要，但它已经不足以单独定义一款 AI 产品是不是好设计。

传统可用性关注用户能否有效、高效并满意地完成任务。Agent 时代还必须继续追问：系统是否值得在这项任务上被依赖？用户能否看见结果背后的关键依据？系统走偏时能否被及时打断和接管？模型、提示词、工具或政策变化后，原来成立的质量是否还能保持？更长期地看，自动化究竟增强了人的判断，还是让人逐渐失去了判断的机会？

因此，Agent 时代的好设计可以先被概括为一句话：

好设计不仅要帮助人完成任务，还要让结果可验证、过程可追溯、系统可接管、质量可持续，并且不以削弱人的判断力为代价。

本章将从六个方面讨论这套新标准：为什么可用性之外还需要可信、可回溯和可接管；eval 与用户判断怎样组成双层测试；当生产变得便宜后，为什么判断和验收会成为新的瓶颈；产品上线后如何通过运行时治理持续校准质量；判断力弱化为什么可能不会在常规指标里报错；以及设计师应该怎样替用户守住仍然必须由人完成的判断。

5.1　可用性不够了：可信、可回溯、可接管成为新标准

可用性没有失效。一个连目标都说不清、流程经常卡住、反馈难以理解的 Agent，不会因为拥有审计日志和权限系统就自动变成好产品。问题在于，传统可用性通常把系统当作相对稳定的工具，主要评价人能不能顺利操作；Agent 则会理解目标、选择路径、调用工具和改变外部状态，用户即使没有完成多少操作，也可能需要承担最终后果。

当系统开始替人行动，质量标准就必须从“这个工具是否容易使用”扩展到“这段委托关系是否成立”。Microsoft 在人机交互设计指南中也把传统交互原则与 AI 特有问题放在一起：系统需要说明自己能做什么、做得多好，出错时支持忽略、纠正和恢复，并在行为随时间变化时谨慎更新和通知用户。¹

5.1.1　可用性是底线，不是终点

以一款帮助招聘人员筛选简历的 Agent 为例。它可能拥有清楚的界面、很快的响应和较高的任务完成率，招聘人员也可以在几分钟内得到候选人排序。从可用性角度看，这些都是优点。

但如果系统没有说明排序使用了哪些岗位条件，没有暴露材料缺失和相互冲突的地方，招聘人员无法知道它是否把“学校名称”误当成了能力证据；如果候选人被降低优先级后无法申诉，团队也无法追溯当时使用的模型、规则和数据，那么这款产品即使操作简单，仍然不能被认为设计得好。

Agent 产品至少有三层质量需要同时成立。

第一层是任务质量。系统是否完成了用户真正要完成的事情，结果是否准确、有效，成本和时间是否合理。

第二层是协作质量。用户是否理解 Agent 的角色，能否形成恰当依赖，是否在关键节点拥有选择、纠正和接管能力。

第三层是治理质量。系统行为是否可追溯，权限和责任是否清楚，变化能否被监控，错误能否被复盘并转化为下一轮改进。

传统可用性主要集中在前两层中的一部分，而 Agent 时代需要把三层放在同一套标准里。只检查界面是否顺畅，就像只检查一辆汽车的座椅、方向盘和屏幕，却不检查制动、行驶记录和驾驶员能否重新获得控制。

5.1.2　可信不是让用户相信，而是让用户能够判断

“可信”很容易被误解为让 AI 看起来更专业、更确定，或者通过拟人化表达建立亲近感。实际上，越自然、越流畅的解释，有时越容易让用户忽略核验。

更合理的目标不是最大化信任，而是形成恰当依赖：系统正确时，用户愿意使用它；系统错误、证据不足或超出能力边界时，用户能够怀疑、拒绝或转向其他方法。Microsoft 对适当依赖的研究把过度依赖和依赖不足都视为问题，并指出，仅仅增加警告或解释未必有效，相关设计必须通过真实用户研究验证，因为缓解措施本身也可能产生反效果。²

因此，可信体验至少需要帮助用户回答四个问题：

1. 这件事在 Agent 的能力范围内吗？
2. 这次结果依据了什么，还有什么没有被考虑？
3. 如果结果是错的，错误会影响到哪里？
4. 我现在应该直接接受、抽样检查、要求补充，还是自己接管？

这四个问题比一句“内容由 AI 生成，请注意核实”更有用。通用警告把全部判断成本重新丢给用户，却没有告诉他哪里值得核实。好的设计会把不确定性转化成具体的行动提示，例如“政策存在两个版本，请选择适用日期”“三张票据缺少商户信息，需要人工确认”“这封邮件会发送给外部客户，请检查收件人和附件”。

可信也不等于展示越多技术信息越好。模型概率、完整提示词和原始日志可能很详细，却未必能帮助用户判断。设计师需要把技术状态翻译成与当前任务有关的证据、限制、影响和下一步动作。

5.1.3　可回溯不是展示模型的全部思考过程

当团队要求 AI“可解释”时，常见做法是生成一段听起来合理的说明。但一段说明不一定是证据，也不一定能准确还原系统实际使用了哪些信息。模型甚至可能在得到结果之后，再补出一套流畅的理由。

因此，可回溯不应被设计成“把 AI 的内部思考逐字展示给用户”，而应该保留一条与任务和行动有关的证据链。它至少包括：

• 用户最初设定的目标、范围和限制；
• Agent 实际读取的数据、文件和政策版本；
• 关键决策点使用的规则、证据和冲突信息；
• 调用过的工具、写入过的系统和改变过的状态；
• 哪些动作由 Agent 自动完成，哪些经过人类批准或修改；
• 最终结果、外部回执、失败记录和恢复动作；
• 当时使用的模型、提示词、Skill、权限与配置版本。

对普通用户来说，这些信息不必一次全部展开。界面可以先显示当前结果和两三条关键依据，需要复核时再进入详细轨迹。对审计、客服、风控或工程团队来说，则要能从最终结果回到具体证据和版本。

换句话说，可回溯的目标不是满足好奇心，而是支持验证、纠错与追责。用户需要知道“为什么这个结果值得接受”，团队需要知道“如果结果不对，问题发生在哪一层”。

5.1.4　可接管不是放一个停止按钮

很多产品在界面上提供“取消”“暂停”或“人工处理”，便认为已经保留了控制权。但真正的接管是一段状态迁移，而不是一个孤立按钮。

用户点击停止之后，系统是否真的停止了工具调用？已经发出的请求能不能撤销？部分完成的任务处于什么状态？接管者能否看见 Agent 已经做了什么、还剩什么、哪些假设尚未确认？人工修改后，Agent 是继续执行、重新规划，还是不再介入？这些问题共同决定接管是否成立。

因此，一个可接管的 Agent 至少需要做到：

1. 偏离能够被及时发现，而不是只在最终结果里暴露。
2. 用户能够在任务、步骤或具体对象层级打断系统。
3. 停止后系统进入安全、稳定且可理解的状态。
4. 接管者得到一份包含目标、进度、依据、改动和风险的交接包。
5. 必要时可以回退到检查点，或对无法撤销的后果进行补偿。
6. 接管原因被记录，并进入后续规则、权限或 eval 的修订。

欧盟《人工智能法案》第 14 条对高风险 AI 的人类监督提出了类似方向：负责监督的人需要能够理解系统能力和限制，意识到自动依赖的倾向，正确解释输出，并在适当时忽略、推翻、停止或干预系统。³ 这些要求不是只属于合规团队，它们最终都要通过界面、流程、权限和运行状态变成真实体验。

5.1.5　一套扩展后的质量标准

把以上内容放在一起，可以得到一套更适合 Agent 产品的质量问题：

这张表不是要求所有产品都建设同样重量的机制。一个只帮助用户改写标题的工具，与一个能动资金、筛选候选人或修改生产系统的 Agent，不需要相同的审计深度和接管流程。但无论风险高低，团队都应该明确自己选择了哪些标准，哪些暂时没有覆盖，以及为什么可以接受这种取舍。

5.2　eval 与用户判断：双层测试如何互补

上一章讨论过，设计师和产品经理需要把“怎样才算做得好”写进 eval。但 eval 不等于质量本身，它只是观察质量的一组方法。Agent 的行为既发生在模型、工具和数据构成的系统里，也发生在人与系统建立的协作关系里，因此测试也必须分成两层。

第一层测试系统：Agent 是否稳定完成任务、遵守边界、正确调用工具、处理异常并避免回归。

第二层测试关系：用户能否理解结果、核验证据、识别错误、保留控制，并在真实情境中对后果作出判断。

只测第一层，可能得到一个技术上很强、却让人无法监督的系统；只测第二层，又很难覆盖大量行为组合、边界案例和模型变化。

5.2.1　eval 测的是可重复的系统行为

对传统功能来说，一条测试可能是“输入正确账号和密码后可以登录”。结果相对确定，一次通过通常具有较强的说明力。

Agent 的测试对象更复杂。它可能根据同一句目标生成不同计划，在工具调用失败后选择不同恢复路径，也可能因为上下文顺序、模型版本或提示词细节发生变化。一次成功只能证明它曾经成功，不能证明它会稳定成功。

因此，一套有效的 eval 通常包括五个部分：

1. 任务样本：来自真实工作、历史失败、边界条件和对抗场景。
2. 运行环境：Agent 可以访问的工具、数据、权限和外部状态。
3. 预期标准：哪些结果必须出现，哪些行为绝不能发生。
4. 评分方式：确定性测试、规则检查、模型评分、专家判断或多种方式组合。
5. 重复与分组：同类任务多次运行，并按风险、用户、语言、数据条件和失败类型拆分结果。

Anthropic 在 2026 年总结 Agent eval 实践时指出，Agent 的多轮行动和工具使用使评估更困难，单一评估层无法覆盖全部问题；更完整的方法需要把自动 eval、生产监控、用户反馈、A/B 测试、轨迹审阅和系统化人工评估结合起来。⁴

这说明，eval 不是一个神奇分数，也不是发布前跑一次的考试。它更像一套持续维护的行为样本库：每发现一种重要失败，就把它变成后续可以重复检查的案例。

5.2.2　不要只评最终答案，还要评行动过程

对于一个只生成摘要的功能，最终文本可能是主要评分对象。对于 Agent，只看最终结果会漏掉很多危险行为。

例如，报销 Agent 最后确实生成了一份金额正确的申请，但它可能读取了不该访问的员工资料；代码 Agent 最后通过了测试，却顺手删除了任务范围之外的文件；研究 Agent 给出了正确结论，但引用的是低质量二手材料；客服 Agent 成功解决问题，却在没有授权时承诺了超出政策的补偿。

所以 eval 至少要同时检查结果、过程与边界：

• 结果是否正确、完整并满足用户目标；
• 关键事实是否有证据支撑，来源质量是否合适；
• 工具是否以正确参数、正确顺序被调用；
• Agent 是否遵守数据、权限和行动范围；
• 出现冲突、不确定或高风险动作时是否停下来；
• 失败后是否安全恢复，而不是掩盖问题继续执行；
• 成本、延迟和人工介入量是否仍在可接受范围内。

这里的标准应该尽量来自真实业务，而不是只来自通用模型能力。例如，“邮件文案自然”不能代替“没有泄露内部信息、收件人正确、附件完整、发送前经过必要确认”。

5.2.3　用户测试要从“会不会用”扩展到“会不会判断”

传统可用性测试常让用户完成一项任务，观察他是否找到入口、理解文案、完成操作。Agent 时代还需要设计一些让系统故意不完美的任务，观察用户能否发现、怀疑和处理问题。

例如，可以在一组正确结果里加入一条证据不足的建议，检查用户是否会打开来源；让 Agent 使用一份过期政策，观察用户能否注意版本；让系统在高风险动作前给出一段很流畅但不完整的解释，观察用户是直接批准，还是会查看影响范围和备选方案。

此时研究者不应只问“你觉得这个结果可信吗”，因为用户口头表达的信任和实际行为可能不同。更有价值的观察包括：

• 用户在哪些情况下直接接受，在哪些情况下主动核验；
• 错误出现时，用户能否识别具体问题，而不只是感觉不对；
• 用户是否能找到关键证据、反例和缺失信息；
• 用户能否预测批准、拒绝或修改之后会发生什么；
• 接管后能否继续完成任务，而不是从头开始；
• 用户的自信是否与真实判断准确度相匹配。

换句话说，用户测试不仅要测操作成功率，还要测判断成功率。

5.2.4　四种测试结果代表四种不同问题

把系统 eval 和用户判断放在一起，会得到四种典型结果：

第三种结果有时会被团队误判为“产品没问题，反正用户会检查”。但如果同一种错误不断由人兜底，说明自动化没有真正降低成本，反而把异常处理变成了新的用户劳动。更重要的是，用户这一次发现错误，不代表在时间压力、信息过载或长时间连续审批时仍然能发现。

第二种结果也值得警惕。一个 Agent 可能在 eval 中表现很好，但用户不知道它为什么可靠，也不知道它什么时候会失效。这样的系统短期可能被过度信任，长期也可能因为一次难以解释的错误被彻底放弃。

5.2.5　谁来定义“好”同样需要被设计

并不是所有任务都有唯一正确答案。品牌文案、设计方案、风险判断、诊疗建议和招聘评价，都包含专业经验、情境与价值取舍。此时 eval 的困难不只是评分技术，而是团队内部对“好”没有形成共同标准。

如果两名专家面对同一个案例给出相反判断，直接把他们的选择交给模型学习，只会让系统得到互相冲突的信号。团队需要先找出分歧来自哪里：是目标不同、证据不同、风险偏好不同，还是规则本身没有写清。

对主观任务，可以使用更明确的评分量表，把“感觉不错”拆成准确性、完整性、品牌一致性、风险、可执行性等维度；对高风险任务，可以要求多位领域专家独立评审并记录理由；对模型评分器，也要定期用人工样本校准，检查评分器是否偏向更长、更流畅或更像标准答案的结果。

eval 的价值之一，正是迫使团队把隐含判断说清楚。很多产品不是因为 Agent 不够强而失败，而是团队从来没有共同定义什么结果可以被接受。

5.2.6　验收的对象是一组证据，不是一个演示

当团队验收 Agent 产品时，不应只观看一次理想路径 Demo。更完整的验收包应该包括：

• 核心任务和高风险任务的 eval 结果；
• 失败样本、失败分布与尚未解决的限制；
• 用户能否识别错误、理解后果和完成接管的测试记录；
• 模型、提示词、工具、数据与权限的版本信息；
• 生产监控、告警、回滚和责任人安排；
• 哪些风险已经缓解，哪些残余风险被明确接受；
• 上线后什么情况会触发降权、暂停或重新评审。

这也意味着，设计验收不再只判断界面是否还原。设计师要参与定义行为质量、人类判断和接管标准，并确认这些标准已经被产品、工程、数据、安全、业务和运营共同理解。

5.3　生产变得便宜，判断变得昂贵

生成式 AI 最直观的变化，是把“做出第一版”的成本大幅降低。过去需要一天完成的文案、页面、分析报告和代码，现在可能在几分钟内得到多个版本。团队很容易因此认为效率已经成倍提升。

但真正进入工作流后，新的瓶颈很快出现：谁来判断这些结果是不是正确，哪些可以合并，哪些可以发送，哪些只适合演示，哪些会在未来制造更大的问题？

AI 降低的是生产候选结果的成本，却没有等比例降低承担后果的成本。生成越快，待判断的结果可能越多；Agent 能行动得越远，一次判断涉及的影响范围也越大。

5.3.1　生成数量不等于有效产出

假设一个设计师借助 AI 一天生成了十套页面方案。表面上看，生产力是过去的十倍。但如果十套方案都没有基于真实内容和组件运行，设计师仍然需要逐一检查信息结构、状态、品牌、可访问性和开发成本，团队甚至可能花更多时间争论选择哪一套。

同样，一个代码 Agent 一小时提交了三千行修改，不代表它完成了三千行价值。审查者需要理解修改范围、依赖关系、测试结果和潜在回归。修改越大、上下文越不清楚，人工审查越容易退化成“测试过了就合并”。

因此，AI 时代更有意义的产出指标，不是生成了多少，而是有多少结果被可靠地理解、验证、接受并产生了真实价值。

而且，“验证”不能只看一个总体准确率。《UX for AI》用混淆矩阵提醒设计团队：相同的准确率可以由完全不同的误报与漏报组成；再用 Value Matrix 把每一类错误放回等待、焦虑、误伤、机会损失和业务收益中衡量。⁸ 这不是说所有产品都要展示一张统计矩阵，而是说团队在宣布产出有效之前，必须先回答“错的是哪一种、代价由谁承担”。这是本书采用的判断框架，具体权重仍需由真实业务和受影响用户共同定义。

可以把它区分为三个数量：

• 生成吞吐量：系统产生了多少候选结果或完成了多少动作；
• 审核吞吐量：人和自动机制能够认真检查多少结果；
• 验证后吞吐量：最终有多少结果在证据充分、风险可接受的情况下进入真实使用。

如果生成吞吐量远大于审核吞吐量，积压的不是普通任务，而是尚未被理解的风险。

5.3.2　警惕“验证债务”

在软件开发中，团队会讨论技术债务：为了更快交付而暂时采用的方案，会在未来增加维护成本。AI 工作流还会产生一种验证债务。

验证债务是指团队不断接受“看起来可以”的 AI 结果，却没有建立足够的证据、测试和理解。它可能表现为：大批代码能运行但没人真正理解；大量内容已发布但来源没有核验；自动审批越来越多但规则无人维护；模型不断更新但没有可比较的基线。

验证债务短期不一定报错。相反，它常伴随着速度提升和漂亮的产出数字。问题会在某次模型变化、人员离职、合规审查或严重事故发生时集中暴露：团队不知道系统为什么这样做，也不知道修改哪里不会引发新的问题。

因此，每扩大一段自动化，都应该同时增加相应的验证能力。Agent 能调用新工具，就要增加工具行为的 eval 和监控；能影响更多对象，就要提供影响预览和回退；能生成更大修改，就要支持拆分、diff、测试与责任人审查。

5.3.3　不是所有结果都需要同样检查

解决判断瓶颈的方式不是让人逐字逐项检查一切，那会把 Agent 重新变成昂贵的自动打字机。更合理的方法是按风险分配判断力。

设计师和团队可以用四个变量决定检查强度：

1. 后果：错误会造成多大损失，影响多少人。
2. 可逆性：结果能否低成本撤销、回退或补偿。
3. 新颖性：任务和历史成功案例有多相似，是否出现新环境、新工具或新数据。
4. 可验证性：结果能否通过规则、测试、外部回执或权威证据快速验证。

低风险、可逆、重复且容易验证的任务，可以提高自动化程度，只做抽样复核。高风险、不可逆、新颖或难以验证的任务，则需要更强的专家判断、更完整的证据和更明确的事前确认。

例如，Agent 自动整理会议记录后，用户可以直接修改，风险较低；但如果 Agent 根据会议记录自动修改合同条款并发给客户，即使它过去表现很好，也不应该沿用同样的确认强度。

5.3.4　把结果设计成容易被审查的形状

判断成本不只由任务难度决定，也由输出怎样被呈现决定。

一份几百页的完整报告即使内容大体正确，也很难被认真审查；一个包含几十个文件的大型代码改动，即使附有一句“已完成重构”，也很难让人判断影响。好的 Agent 不只是会生成结果，还会把结果组织成适合人检查的形状。

这通常包括：

• 先展示目标、范围和本次具体改动；
• 把新增、删除、推断和保持不变的内容区分开；
• 将大结果拆成可以独立接受或拒绝的小单元；
• 把证据放在相应结论旁，而不是埋在附录里；
• 对异常、冲突和低把握部分优先排序；
• 显示影响范围、依赖关系和验证结果；
• 支持局部修改、重新运行和比较版本。

这也是为什么 diff 会成为 Agent 时代的重要交互形式。用户不需要重新阅读全部结果，而是先看系统改变了什么，再决定哪些变化值得深入检查。

5.3.5　增加审批按钮不等于增加判断质量

面对 AI 风险，团队很容易不断增加确认弹窗。结果是低风险动作和高风险动作都需要点击“批准”，用户每天面对几十次相似提示，最终形成审批疲劳。

当用户知道“不批准就无法继续”，却没有足够时间和信息进行判断时，批准会退化成仪式。界面保留了人的责任，却没有提供人的能力。

因此，确认机制应该减少无意义判断，把人的注意力集中到真正有分歧、有后果和不可逆的节点。对于可以自动验证的内容，系统应先完成检查；对于重复、低风险的决策，可以让用户设置清楚的规则；只有当任务超出规则、证据冲突或影响显著扩大时，再升级给人。

一个好的审批请求也不应该只问“是否继续”，而应该说明：系统准备做什么，依据是什么，哪里不确定，会影响谁，是否可逆，有哪些备选方案，以及如果用户暂时不处理会发生什么。

5.3.6　把判断能力当作产能建设

过去团队扩大产能，常见做法是增加人、工具和自动化。Agent 时代还需要建设组织的判断能力：领域专家是否参与定义标准，审阅者是否能看到必要上下文，失败是否被整理成案例，团队是否知道什么时候必须停下来。

这类能力可以通过评审量表、样例库、eval 集、审计工具、决策看板和定期校准会议逐步形成。它的目标不是让每个人都检查所有事情，而是让正确的人在正确的节点，以足够低的成本完成必要判断。

从这个角度来看，AI 带来的生产力上限，不只取决于模型能生成多快，也取决于组织能多快地把生成结果转化成可信结果。

5.4　验收之后：运行时治理如何持续校准标准本身

传统软件在上线后也会出现 Bug，也需要监控和迭代。但只要代码和输入相同，主要行为通常相对稳定。Agent 产品多了一组持续变化的因素：模型会更新，系统提示会调整，工具接口会变化，知识库会增加新材料，权限会扩大，用户也会用它处理团队从未设想过的任务。

所以，发布时通过验收，不代表三个月后仍然满足相同标准。质量不是贴在版本上的永久标签，而是需要在真实运行中不断获得新证据。

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

发布前的 eval 再完整，也只是对有限样本和环境的模拟。真实用户会提出更含糊的目标，上传质量更差的数据，在更复杂的组织关系中使用系统；外部服务会超时，政策会更新，恶意用户也会主动寻找边界。

这并不意味着上线前测试没有价值，而是说测试必须和生产观察连接起来。发布前的 eval 提供基线，生产运行提供新失败和真实分布，两者共同决定下一轮标准。

NIST 的 AI 风险管理框架把 Govern、Map、Measure、Manage 作为贯穿生命周期的四类功能，并明确提出风险管理应持续、及时地进行；AI 系统不仅要在部署前测试，也要在运行期间定期评估，监控生产行为并跟踪新出现的风险。⁵

5.4.2　标准也需要版本管理

很多团队会为模型、代码和提示词保存版本，却把“好”的定义当作一份不会变化的验收文档。实际上，标准本身也会随着业务和风险变化。

例如，早期客服 Agent 只负责起草回复，“不能直接发送”是一条边界；后来产品增加自动发送能力，标准就必须加入收件人、敏感信息、承诺范围、撤回和通知等要求。如果团队只升级功能，不升级 eval、权限和人工介入规则，旧标准会制造虚假的安全感。

因此，每次重要变化都应该能回答：

• 哪个能力、模型、工具、数据源或权限发生了变化？
• 变化影响了哪些用户、任务和风险？
• 哪些原有 eval 仍然有效，哪些需要新增或重写？
• 质量门槛是否改变，谁批准了这种改变？
• 如果结果退化，能够回到哪个稳定版本？

把标准版本化还有一个好处：团队可以解释为什么过去可接受的行为今天不再可接受，也可以比较一次改动究竟改善了什么、牺牲了什么。

5.4.3　运行时需要观察哪些信号

只看调用量、响应时间和错误率，无法完整判断 Agent 的体验是否健康。团队还需要观察与行为和人机协作有关的信号。

一套运行时看板可以包括：

• 任务完成率、关键步骤成功率与失败类型；
• 不同模型、提示词、Skill 和工具版本的表现差异；
• 越权、拒绝、回退、重试和人工接管次数；
• 等待审批的数量、时长与积压趋势；
• 用户对结果的修改比例和常见修改位置；
• 哪些证据被查看，哪些提示总被跳过；
• 高风险动作、异常影响范围和外部回执；
• 用户申诉、客服反馈、近失事件与实际事故；
• 成本、延迟和一次任务需要的人工注意力。

这些数字不能脱离场景解释。接管率上升可能意味着系统变差，也可能意味着新界面让用户终于能发现问题；审批率接近百分之百可能意味着 Agent 很可靠，也可能意味着审批者已经不再认真检查。

因此，看板不只是展示指标，还要支持团队从指标回到样本、轨迹、版本与用户情境。

5.4.4　把一次事故变成治理闭环

当生产中出现问题时，修复当前案例只是第一步。一个完整的治理闭环可以按照以下顺序运行：

发现信号 → 还原情境 → 判断影响 → 临时控制 → 修订规则 → 回放 eval → 小范围发布 → 持续观察

首先，团队通过告警、用户反馈或抽样审阅发现异常；其次，利用轨迹和版本记录还原 Agent 当时看到了什么、做了什么；然后判断影响范围，决定是否暂停能力、降低权限、切回旧模型或通知受影响用户。

临时控制之后，团队再判断根因属于模型能力、上下文缺失、工具错误、权限过宽、界面误导还是人工规则不一致。修订完成后，把真实失败加入 eval，回放相关任务，确认没有修复一个问题又制造新的回归。最后通过小流量或低风险场景逐步恢复，并继续观察。

这条闭环把事故从“运营团队处理了一次投诉”转化为系统能力的更新。没有闭环，同一种错误会被不同用户反复承担。

5.4.5　人工反馈不能未经判断直接变成规则

用户的批准、驳回和修改是重要信号，但不能被系统原样吞下。

一名用户这次把所有邮件改得更口语，不代表整个组织的品牌语气都应该改变；一位审批者为了赶时间批准了异常申请，也不应该被学习成新的政策；两位专家对同一风险给出不同判断，更不能简单按多数票生成规则。

所以，从反馈到系统更新之间还需要一道治理门：先判断反馈代表个人偏好、任务特例、规则缺陷还是普遍模式；再决定它应该进入用户记忆、团队规则、few-shot 案例、Skill、eval，还是需要模型训练。重要更新生效前，还要重新测试其对其他任务的影响。

这里最容易被忽略的是“谁有权改变系统”。用户可以纠正一次结果，不等于每个人都能修改全局政策；领域专家可以定义业务标准，也不等于可以独自扩大数据权限。反馈、规则和权限需要不同的责任人。

5.4.6　治理强度应该跟着风险变化

运行时治理不是要求所有 AI 功能都建设复杂控制中心。对低风险、可逆、容易验证的辅助功能，基础日志、用户反馈、抽样检查和定期回归可能已经足够。对能动资金、改生产数据、影响就业或健康的 Agent，则需要更严格的权限、实时告警、审计、独立评审、演练和熔断。

设计师需要避免两种情况：一种是因为治理复杂，就把高风险能力藏在一句免责声明之后；另一种是把所有任务都设计成重型审批，让用户失去使用价值。

更合理的做法，是先明确风险容忍度，再决定哪些信号必须实时看见，哪些异常必须自动拦截，哪些变化必须重新验收，以及什么条件下系统应该被降权、暂停或下线。

5.5　一个不会在 eval 里报错的风险：判断力弱化

前面的标准仍然主要关心系统是否做对、用户是否能监督，以及组织能否持续治理。但还有一种风险很难在短期测试中出现：系统表现越来越好，用户也越来越满意，人的判断力却在长期使用中逐渐弱化。

这种现象常被称为 deskilling，可以理解为某项知识、技能或判断因为长期不再被练习而退化。它不一定意味着人会“变笨”，也不应该被夸张成使用 AI 必然造成的结果。更准确的说法是：当产品持续替用户完成本来用于形成理解的关键步骤，而用户只负责接受结果时，某些能力失去练习机会的风险会上升。

5.5.1　判断力弱化是怎样发生的

判断力通常不是在一次使用中消失，而是在分工变化中逐步发生。

一开始，AI 帮助用户生成候选方案，用户仍然会比较和修改。后来，系统能够直接给出一个完成度很高的结果，用户只做少量润色。再后来，团队的时间和产量指标都建立在 AI 速度上，用户没有足够时间从头理解，只能检查有没有明显错误。最终，“检查”又退化为看结果是否流畅、格式是否完整和测试是否通过。

这条路径可能发生在很多领域：学生能提交答案却不能解释解法；设计师能生成界面却说不清信息结构；工程师能合并代码却无法定位问题；分析师能得到结论却不了解数据条件；审批者不断点击批准，却逐渐失去识别异常的敏感度。

最危险的时刻不是 AI 经常出错时。系统不可靠时，人反而会保持警惕。真正的风险往往出现在系统大多数时候都正确、表达又非常流畅时，人开始认为逐项检查不再值得。

5.5.2　为什么常规指标看不见它

判断力弱化常常伴随短期指标改善。任务完成更快，用户满意度更高，产出数量增加，错误也可能暂时没有上升。eval 测的是系统表现，只要 Agent 仍然做得好，它不会报告用户是否还会独立完成任务。

普通用户测试也很难发现这个问题。一次一小时的测试可以观察用户是否理解当前界面，却无法证明他连续使用半年后还能发现深层错误。用户本人也未必能准确感知能力变化，因为只要 AI 始终可用，很多缺口不会暴露。

Microsoft Research 在对 319 名知识工作者、936 个实际使用案例的研究中发现，受访者对生成式 AI 的信心越高，报告的批判性思考越少；同时，批判性思考并没有完全消失，而是更多转向信息验证、结果整合和任务管理。⁶ 这项研究主要基于自我报告，不能单独证明长期能力因果退化，但它提示设计师：人的思考位置正在变化，不能只用任务速度评价这种变化。

5.5.3　生产力工具与学习工具有不同目标

生产力工具希望减少步骤、绕过阻力，让用户更快到达结果。学习和能力形成却经常需要用户在阻力中练习：自己回忆、尝试、犯错、比较、解释并修正。

这两种目标并不总是冲突。AI 可以提供个性化提示、即时反馈和针对性练习，也可以承担机械工作，让人把注意力放在更高层判断上。问题在于，产品必须先说清楚当前追求的是完成任务，还是帮助用户形成能力。

一项近千名高中生参与的数学学习现场实验提供了一个有启发性的对比：学生使用不受约束的生成式 AI 辅助时，练习阶段表现提高，但在无法使用 AI 的考试中表现下降；加入教学护栏、限制系统直接给答案后，这种负面影响得到缓解。⁷ 这不能直接推论所有工作场景都会发生同样结果，但它说明，同一种模型被设计成“答案机器”还是“学习脚手架”，会产生不同的长期结果。

因此，效率模式和学习模式不应该混在一起。赶时间完成一封低风险内部邮件，可以让 AI 直接起草；培养新员工理解合规政策，则不应该让系统永远替他做完整判断。

5.5.4　哪些判断不能轻易外包

不是所有技能都值得被保留。很少有人会因为计算器削弱心算速度，就主张取消电子表格。技术进步本来就会让一些操作性技能变得不再重要。

真正需要保留的，通常是以下几类判断：

• 一旦错误，会产生重大或不可逆后果；
• 需要承担法律、伦理、专业或组织责任；
• 当前没有稳定外部方法可以快速验证；
• 是审查 AI 结果的前提能力；
• 会影响目标、价值取舍和“什么值得做”；
• 是学习更高阶能力必须经过的基础练习。

例如，设计师不一定要手工绘制每一个图标，但需要判断信息层级、用户目标和交互后果；工程师不一定要手写所有样板代码，但需要理解架构、数据和安全边界；医生可以使用 AI 辅助整理信息，却仍要对诊断证据、患者情境和治疗取舍负责。

当某项能力既是生产能力，又是监督 Agent 的能力时，更不能在没有替代机制的情况下完全外包。否则组织会出现一个悖论：AI 产出越来越多，能够认真审查这些产出的人却越来越少。

5.5.5　用长期指标观察人的变化

如果判断力弱化是长期风险，团队就需要增加长期观察，而不是只看即时满意度。

可以考虑以下指标：

• 无辅助表现：暂时没有 AI 时，用户还能否完成关键判断；
• 错误识别率：面对看起来合理但有问题的结果，用户能否发现；
• 理由质量：用户是否能说明为什么接受、修改或拒绝；
• 修改深度：用户是在换词润色，还是能够改变结构、假设和方向；
• 迁移能力：用户能否把在一类任务中形成的判断用于新任务；
• 置信度校准：用户的自信是否与真实正确率相匹配；
• 接管质量：异常时，用户能否理解状态并安全继续；
• 专业成长：新手是否逐步减少对完整答案的依赖，开始处理更复杂问题。

这些指标不适合每次任务都测，也不应被用来监视个人。它们更适合在培训、关键岗位、阶段性研究和高风险系统中，以透明、合适的方式观察整体趋势。

5.5.6　目标不是保留所有困难，而是保留有价值的困难

讨论判断力时，很容易把所有摩擦都浪漫化，好像用户做得越多越好。实际上，重复录入、机械排版、查找固定资料和搬运数据并不会自动带来更深理解。糟糕的流程也不应该因为“能锻炼用户”而被保留。

设计师需要区分无价值摩擦和生产性摩擦。无价值摩擦消耗注意力，却不增加理解；生产性摩擦会迫使用户在关键处比较证据、表达理由、作出选择或练习一项仍然需要的能力。

好的自动化应该拿走机械负担，把人的精力留给目标、例外、价值和后果，而不是拿走全部判断，再把最终责任留给人。

5.6　设计师最后的责任：替用户守住判断力

设计师不需要站在 AI 的对立面，也不应该把“必须由人完成”当作职业保护。很多原本需要设计师、编辑、工程师或分析师亲自执行的工作，确实会被更高效地自动化。

设计师需要守住的不是旧工作量，而是人在新分工中的有效能动性：用户可以少做，但不能在看不懂、无法推翻和不能接管的情况下承担责任；用户可以依赖 AI，但不应该因此失去审查 AI 所必需的能力。

5.6.1　先说清楚产品要把人变成什么角色

设计一项 AI 能力之前，团队可以先问：长期使用后，我们希望用户在这项任务中成为什么样的人？

如果系统的目标是帮助专家提高吞吐量，AI 可以承担收集、整理和生成初稿，专家保留复杂判断与最终签署。如果目标是帮助新手学习，AI 应更多提供提示、反问、示例和反馈，逐步减少帮助，而不是每次直接交付完整答案。如果目标是处理低风险重复劳动，系统可以高度自动化，只在人需要时提供抽查和恢复。

同一个产品甚至可以提供不同模式：

• 执行模式：追求速度，由 Agent 完成较多步骤；
• 协作模式：人与 Agent 轮流生成、比较和修改；
• 学习模式：优先提示和反馈，保留用户练习；
• 审查模式：Agent 主动寻找证据缺口、反例和潜在风险。

模式不是换一个按钮名称，而是改变系统何时给答案、何时追问、展示什么证据，以及哪些决定必须由人完成。

5.6.2　在任务开始前保留目标判断

判断力保护的第一步发生在生成之前。用户至少需要有机会说明目标、成功标准、限制和不希望发生的事情。

如果 Agent 一接到模糊指令就直接完成所有工作，用户很容易根据生成结果倒推自己的目标，最后被系统带着走。相反，产品可以先让用户选择优先级、确认受众、定义不可改变的条件，或对几个方向进行比较。

这并不意味着每次都填一张长表。低风险任务可以通过自然语言和默认值快速开始；高影响任务则应该把关键标准外化。例如，在生成候选人筛选规则前，先让招聘团队确认哪些条件真正与岗位有关，哪些敏感属性不能使用，哪些情况必须人工评审。

当用户参与定义“好”的标准，他后续才有依据判断 Agent 的结果，而不是只判断自己喜不喜欢。

5.6.3　在执行过程中提供判断支架

好的判断支架不是替用户再做一次决定，而是降低理解和比较的成本。

常见方式包括：

• 把结论与对应证据放在一起，并标出材料日期和来源；
• 主动显示缺失信息、冲突、假设和低把握部分；
• 提供两个以上有意义的方案，并说明主要取舍；
• 允许用户请求反例、反方意见或失败预演；
• 把大任务拆成几个真正需要决定的节点；
• 显示本次改动与上一个版本的差异；
• 在高影响动作前展示影响预览和可逆性；
• 让用户能够局部修改，而不是只能整体接受或重新生成。

这些设计共同减少一种危险状态：用户面对一个完成度很高的整体结果，只能凭感觉点“接受”。

5.6.4　把摩擦放在最有价值的位置

设计师可以为不同任务安排一份“摩擦预算”。低风险、可逆、容易验证的动作尽量顺畅；高风险、不可逆、证据冲突或需要学习的节点，保留少量但有信息价值的停顿。

例如，系统不必在每封内部邮件发送前重复警告，但当收件人首次包含外部地址、附件来自内部空间或内容涉及价格承诺时，应该暂停并说明变化。学习产品不必阻止学生获得帮助，但可以先让他尝试一步，再给分层提示，最后才展示完整解法。

有价值的摩擦应该满足三个条件：用户知道为什么被打断；系统提供了足够信息帮助判断；完成判断后，结果会真实改变后续行为。如果只是多点一次按钮，它不会提高判断力，只会训练用户更快地跳过提示。

5.6.5　让反馈帮助用户形成自己的标准

许多 AI 产品把反馈简化成点赞和点踩。这些信号有利于团队统计偏好，却很难帮助用户形成判断。

在重要任务中，系统可以让用户说明“哪一处不对”“违反了什么标准”“希望以后怎样处理”，并把这些选择变成可见的个人或团队规则。下次 Agent 遇到相似情况时，不只是自动套用，还可以告诉用户“本次按照你上次确认的规则处理”。

这样做有两个作用。第一，Agent 的个性化更可控，用户知道系统学到了什么；第二，用户的判断被外化为可以复用、讨论和修订的标准，而不是每次从感觉出发重新修改。

当然，个人偏好不能自动覆盖组织规则，单次纠正也不能直接升级为全局策略。设计师需要把反馈对象、适用范围和生效方式说清楚。

5.6.6　定期验证人是否仍然有能力在环内

“人在环内”不能只看流程图上是否存在人工节点，还要看这个人有没有时间、信息、技能和权力完成判断。

对高风险或长期自动化任务，团队可以进行周期性演练：让审阅者处理包含已知错误的样本，检查他能否发现；模拟 Agent 中断，验证接管者能否恢复；比较有无 AI 时的关键任务表现；复盘一段时间内用户的批准理由是否越来越空洞。

如果人已经无法有效审查，就不能继续把“最终由人批准”当作安全保证。团队需要降低 Agent 权限、改善判断支架、重新培训人员，或引入独立复核。

这和自动驾驶中的接管问题相似：长期不参与环境判断的人，很难在突然收到警报时立刻恢复完整情境意识。好的系统不能在平时拿走全部参与，在出事时又把全部责任瞬间还给用户。

5.6.7　设计评审需要增加一组问题

在 Agent 产品进入验收前，设计师可以用下面的问题进行最后检查：

1. 用户知道自己委托了什么，又保留了什么吗？
2. 系统正确时，用户能看见足够证据快速接受吗？
3. 系统错误时，用户有真实机会发现，而不是只能事后申诉吗？
4. 结果能回到数据、版本、行动和责任吗？
5. 用户能在合适层级停止、纠正、回退和接管吗？
6. 自动 eval 与真实用户判断是否都被测试过？
7. 上线后，团队知道看哪些信号、由谁处理、何时降权吗？
8. 审批是否提供了作出决定所需的信息，而不只是转移责任？
9. 长期使用后，用户仍然能解释、修改和审查关键结果吗？
10. 这项自动化拿走的是机械负担，还是拿走了用户仍然需要的判断？

如果这些问题没有答案，那么产品即使已经能运行、能生成、能通过一次演示，也还没有完成设计。

本章小结

Agent 时代，好设计的标准发生了六个相互关联的变化。

第一，可用性仍然是底线，但不再是终点。评价对象从“用户能否顺利操作一个工具”，扩展到“人与一个会判断和行动的系统能否建立合理委托关系”。

第二，可信、可回溯和可接管成为新的质量底线。可信不是让用户相信，而是帮助用户形成恰当依赖；可回溯不是展示一段流畅理由，而是保留目标、证据、行动、版本和责任；可接管也不是一个停止按钮，而是一段安全、完整的状态迁移。

第三，测试必须由 eval 和用户判断共同完成。eval 测系统的稳定性、边界、工具行为和回归，用户研究测理解、证据使用、错误识别、控制感与接管。一个系统既要做得对，也要让人有能力判断它是否做对。

第四，生产变得便宜后，判断和验证会成为新的瓶颈。团队不应只统计生成数量，而要关注验证后的有效产出；通过风险分层、可审查输出、自动检查和有意义的升级，把人的注意力放在真正需要判断的位置。

第五，验收不再是终点。模型、提示词、工具、数据、权限和使用环境会持续变化，质量标准也必须被版本化，并通过生产监控、审计、复盘和持续 eval 不断校准。

第六，判断力弱化需要成为显式设计对象。短期速度、满意度和任务成功不能证明用户长期仍然拥有理解、审查和接管能力。设计师需要区分执行与学习，保留有价值的摩擦，并定期验证“人在环内”是否仍然有效。

本书从设计对象、用户角色、设计思维、设计师工作和评价标准五个方面讨论了 AI 对设计的改变。它们最终指向同一件事：设计不再只是安排人与界面的关系，而是在安排人的目标、Agent 的能力、上下文、权限、行动、证据、责任和长期成长之间的关系。

界面仍然重要，审美仍然重要，可用性也仍然重要。但当一个系统开始替人理解和行动时，设计师还需要回答一个更根本的问题：

我们是在帮助用户获得更大的能力，还是只让他更快地交出判断？

真正好的 AI 产品，不会要求人继续完成所有步骤，也不会把人缩减成最后一次点击。它会让机器承担适合机器的规模、速度和重复，让人保留目标、价值、例外和后果的判断；它既提高效率，也让用户知道系统为什么值得依赖、什么时候应该怀疑，以及需要时如何重新拿回控制。

这可能是 Agent 时代设计师最后、也最不应该被自动化的一项责任：替用户守住判断力。

¹ Saleema Amershi et al., “Guidelines for Human-AI Interaction,” CHI 2019，https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/ 。

² Mihaela Vorvoreanu et al., Fostering Appropriate Reliance on GenAI: Lessons Learned from Early Research, Microsoft Research, 2025，https://www.microsoft.com/en-us/research/publication/fostering-appropriate-reliance-on-genai-lessons-learned-from-early-research/ 。

³ European Union, Artificial Intelligence Act, Regulation (EU) 2024/1689, Article 14，https://eur-lex.europa.eu/eli/reg/2024/1689/oj 。

⁴ Anthropic, “Demystifying evals for AI agents,” 2026，https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents 。

⁵ NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023，https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ 。

⁶ Hao-Ping Lee et al., “The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers,” CHI 2025，https://doi.org/10.1145/3706598.3713778 。

⁷ Hamsa Bastani et al., “Generative AI without guardrails can harm learning: Evidence from high school mathematics,” Proceedings of the National Academy of Sciences, 2025，https://doi.org/10.1073/pnas.2422633122 。

⁸ Greg Nudelman and Daria Kempka, UX for AI, Wiley，章节 “Confusion Matrix: How Can Accurate AI Be Wrong?” 与 “Value Matrix: The AI Tool for the Real World”；本地转述见 素材/书摘-第3轮-UX-for-AI.md。