设计思维变了——从流程设计到可能性空间

假设一家公司的产品团队准备设计一个客户退款 Agent。

如果按照传统产品的方式推进，团队通常会先访谈客服和客户，梳理退款流程，再定义订单查询、资格判断、金额计算、主管审批、退款执行和结果通知等页面。设计师制作服务蓝图和可点击原型，邀请用户完成几次退款任务，确认流程容易理解后，再把方案交给研发实现。

这套方法没有错。团队仍然需要理解用户为什么申请退款、客服在哪些环节最耗时、不同角色承担什么压力，也仍然需要验证信息、文案和操作是否清楚。

但如果产品真的变成 Agent，原来的设计过程会立刻遇到一些新问题。Agent 可能根据退款政策自行判断申请是否成立，读取订单和物流信息，计算优惠券、税费和已使用权益，生成对客说明，甚至调用支付工具完成退款。此时，团队不能只研究“客服怎样完成退款”，还要决定“哪些判断可以委托给 Agent”；不能只画一条理想流程，还要验证 Agent 读取了什么、为什么这样判断、是否越过权限、工具失败后怎样恢复，以及同一种任务反复执行时是否仍然稳定。

更重要的是，产品发布后，这些问题不会停止变化。退款政策会更新，模型会升级，工具会增加，用户可能形成新的用法，原来合理的自动化边界也可能失效。一次上线前的用户测试无法覆盖所有变化，一份交付完成的设计稿也不能长期约束系统行为。

因此，Agent 时代的设计思维不是在经典 Design Thinking 后面加一个“使用 AI”的步骤，而是把设计对象从确定的界面和服务流程，扩展到人机分工、上下文、权限、执行循环、评估方法和运行时治理。

可以把这种变化概括为：

从“以人为中心的界面与服务设计”，走向“以人机协作为中心的不确定系统设计”。

本章将讨论六个问题：旧设计思维依赖了哪些确定性假设；为什么新流程需要增加分工、边界、可执行原型、双层测试和持续治理；共情怎样扩展为对委托关系的理解；静态原型为什么要升级为 Agent Loop；五组动作怎样形成循环；以及经典 Design Thinking 中哪些部分仍然有效。

4.1　旧设计思维默认了什么：确定性时代的五个隐含前提

经典 Design Thinking 常被概括为共情、定义、创意、原型和测试。双钻模型则把设计过程组织为发现、定义、发展和交付，通过发散与收敛帮助团队从模糊问题走向具体方案。Design Council 在介绍双钻时，也把它称为对复杂设计过程的一种简化表达，而不是现实项目必须逐格执行的流水线。¹

这些方法最重要的贡献，是让团队不再从内部功能和技术能力出发，而是先理解人的目标、处境和真实问题；不急于锁定第一个答案，而是通过研究、发散、原型和测试不断修正判断。

Agent 时代仍然需要这些能力。问题在于，经典方法形成和普及的主要语境，是确定性较高的产品和服务。这个语境里有五个很少被单独写出来、却长期影响设计工作的隐含前提。

4.1.1　系统行为相对稳定

传统软件当然也会出错，网络会中断，数据会异常，搜索和推荐也早已带有概率性。但对大部分核心操作，团队仍然可以预先写出明确规则：按钮按下后进入哪个状态，表单缺少字段时显示什么，权限不足时能否提交，退款成功后怎样通知用户。

设计师因此可以把一个任务拆成有限状态，再用页面、流程和异常分支描述出来。只要需求和代码没有改变，相同输入通常会沿着相同路径得到相同结果。

Agent 的行为则同时受到模型、提示、上下文、检索结果、工具状态、权限策略和环境变化影响。同一句“帮这位客户退款”，可能因为政策版本、订单状态、历史案例或模型判断不同而走向不同路径。错误也不一定来自某一条规则写错，还可能来自意图误解、过度推断、检索到过期材料、工具调用参数错误，或一段听起来合理但没有证据的解释。

这意味着，设计师不能只定义一条正确路径，还要定义一个可以接受的行为范围：哪些变化合理，哪些结果必须阻断，哪些不确定性需要暴露，系统如何证明自己仍在边界内。

4.1.2　用户是主要行动者

传统产品里，软件提供能力，用户决定什么时候点击、提交、发送、购买或删除。即使系统给出推荐，真正产生外部影响的动作通常仍由用户完成。

Agent 改变了这个责任结构。用户表达的是目标，系统可能自行拆解任务、选择工具、执行多个步骤，并在过程中做出局部决定。用户不再逐步操作每个控件，而是从操作者变成委托者、协作者、审批者或观察者。

因此，“用户完成了任务”不再足以描述体验。设计师还要回答：任务中哪些决定仍由用户做，哪些工作可以让 Agent 代劳，用户在哪些节点必须介入，以及 Agent 做错后谁负责发现和纠正。

4.1.3　界面是主要设计对象

在传统产品中，用户研究的结果通常会转化为信息架构、页面流程、服务触点、组件状态和文案。界面承担了人与系统之间的大部分关系，设计师也能通过界面把主要体验完整表达出来。

Agent 产品的体验却有很大一部分发生在界面背后。Agent 是否读到了正确政策，是否把历史案例误当成强制规则，是否拥有退款写入权限，是否在金额超限时停止，这些都会直接改变体验，却无法只靠一个结果页面说明。

界面仍然重要，但它的作用正在变化：过去主要帮助用户亲自操作，现在还要帮助用户表达目标、查看依据、观察进度、批准动作、处理异常和随时接管。设计对象也从页面扩展到上下文、行为、权限和证据。

4.1.4　原型可以是静态或半静态的

可点击原型非常适合验证信息是否清楚、导航是否合理、流程是否顺畅。服务蓝图和用户旅程图也能帮助团队理解不同角色与触点的关系。

但静态原型通常展示的是设计师已经选好的状态和路径。它可以演示“Agent 请求确认”的页面，却不能证明 Agent 知道什么时候应该请求确认；可以展示“退款执行失败”的提示，却不能证明系统不会重复调用支付工具；可以展示一条完整计划，却不能证明 Agent 遇到新信息后会正确修改计划。

Agent 产品的关键风险发生在连续行动里。原型如果不能真正读取上下文、调用工具、改变状态、遇到失败并恢复，团队看到的就仍然只是一个关于系统行为的故事，而不是系统行为本身。

4.1.5　主要测试发生在发布前，交付是一个明确终点

传统产品上线后也会看数据、修复问题和持续迭代，但团队通常可以在发布前通过设计评审、用户测试、功能测试和灰度发布发现大部分核心体验风险。设计稿交付、研发实现、测试验收和正式上线，构成了一条相对清楚的项目路径。

Agent 产品发布后，行为仍可能因为模型版本、系统提示、检索内容、工具接口和权限范围变化而发生漂移。一个昨天表现良好的任务，今天可能因为政策库更新而判断错误；一项新工具接入后，Agent 的能动性提高，原有确认点却没有同步调整；用户为了省事反复点击批准，也可能让原本有效的监督逐渐变成形式。

所以，发布不再是设计结束的时间点，而是系统进入真实环境、开始暴露长尾问题的时间点。设计方法必须覆盖运行过程，而不只覆盖上线之前。

4.1.6　旧方法不是错了，而是不够了

把五个前提放在一起，可以看到传统方法与 Agent 产品之间的差距。

经典 Design Thinking 擅长提醒团队理解人，却没有天然提供一套方法来约束一个会自主行动、行为不确定、依赖动态上下文并持续变化的系统。

因此需要扩展的不是“以人为中心”这条原则，而是这条原则在新系统中的实现方式。过去，以人为中心常常意味着让操作更容易；现在，它还意味着让委托更清楚、监督更有效、接管更及时，并保证人在自动化过程中不会失去必要的判断与责任。

4.2　新流程的五个动作：分工→边界→原型→测试→治理

针对前面的五种变化，可以把 Agent 时代的设计过程概括为五组动作：

定义人机分工 → 设计上下文与边界 → 构建可执行原型 / Agent Loop → 用 eval 与用户判断共同测试 → 运行时治理与持续校准

这张流程图需要先加两个说明。

第一，箭头表示一种便于理解的叙述顺序，不代表项目只能按这个顺序执行。现实中，团队经常先做一个粗糙原型，看到 Agent 越权后再修正分工；也可能在 eval 中发现某类失败，再回头收紧权限。五个动作更像五个同时存在的设计对象，而不是五道完成后就不能返回的工序。

第二，这套流程接在问题发现之后，不是替代问题发现。团队仍然需要先判断：这个问题真实吗，值得解决吗，AI 是否比普通规则、搜索或工作流更合适？如果一个确定性流程已经能低成本、稳定地解决问题，就不应为了显得智能而增加 Agent。Anthropic 在区分工作流与 Agent 时也指出，预定义工作流更适合步骤清楚、需要一致性的任务；只有当任务路径难以预先写死、模型需要根据环境动态选择行动时，Agent 的灵活性才值得它带来的延迟、成本和风险。²

4.2.1　定义人机分工：这件事可以委托到什么程度

新流程的第一个动作不是画聊天框，而是定义谁来决定、谁来行动、谁来承担最后责任。

设计团队可以把同一项任务拆成不同自主等级：Agent 只观察和整理；Agent 给出建议；Agent 与用户共同编辑；Agent 准备行动并等待确认；Agent 在低风险范围内自动执行；高风险动作则被禁止或升级给人。

这个刻度不能按产品统一设置。退款 Agent 可以自动读取订单、整理事实和计算初步金额，却在金额超过阈值、政策存在冲突或需要对外承诺时停下来。代码 Agent 可以自动修改测试文件，却不能直接读取生产密钥或部署生产环境。邮件 Agent 可以分类和起草，却不能默认代表用户发送给外部客户。

2025 年的《Levels of Autonomy for AI Agents》把自主性定义为 Agent 被设计成在多大程度上不需要用户介入，并用操作者、协作者、顾问、审批者和观察者五种用户角色描述逐渐提高的自主等级。论文特别强调，自主性不是能力增长后自然发生的结果，而是一项可以独立决定的设计选择：一个能力很强的 Agent，仍然可以因为每一步都必须咨询用户而保持低自主性。³

这和第二章讨论的“自主性与能动性是两根不同旋钮”相互呼应。Agent 可以调用多少工具、影响多大范围，是它“能做什么”；执行时是否需要人介入，是它“被允许自主到哪一步”。降低风险时，团队既可以增加确认点，也可以直接收走危险工具。前者会增加用户负担，后者会限制系统能力，选择哪一种，本身就是设计问题。

这一动作的产物不是一句“human-in-the-loop”，而是一张可验证的人机责任图：每个任务阶段由谁发起、谁判断、谁执行、谁确认、谁有否决权，出错后由谁接管。

4.2.2　设计上下文与边界：Agent 凭什么做，又不能做什么

定义分工后，设计团队需要回答第二个问题：Agent 凭什么完成任务？

模型能力只是 Agent 能力的一部分。它还受到上下文、工具、权限、记忆和规则影响。没有退款政策，Agent 无法判断资格；没有订单和支付数据，它无法计算金额；没有品牌语气，它写出的客户通知可能不合适；没有写入工具，它即使判断正确也不能执行退款。

上下文设计要明确：哪些材料由用户提供，哪些由系统检索；信息来自哪里、何时更新；发生冲突时以哪个版本为准；用户能否查看、删除和纠正上下文；输出能否回溯到依据。

边界设计要明确：哪些数据不能读，哪些工具不能调用，哪些字段不能修改，哪些动作必须确认，哪些环境只能查看，以及越界时系统怎样阻断。边界不能只写在提示词里，因为提示词是一种行为引导，不是权限系统。真正高风险的限制必须落实到工具范围、身份认证、读写权限、金额阈值、环境隔离和审计记录中。

Figma 近年的产品变化提供了一个直观例子。它让 Design Agent 读取文件、组件、tokens、布局和样式，通过连接器获取外部工具中的材料，再把团队反复使用的判断封装成 Skills。Figma 对这套能力的解释也很清楚：提示词只是起点，真正决定 Agent 是否理解团队工作方式的是结构化上下文。⁴ 对设计团队来说，这说明用户研究、设计系统、品牌原则和业务规则不能只停留在人读的文档里，还要成为 Agent 可读取、可引用、可检查的工作条件。

这一动作的产物包括上下文地图、数据来源、权限模型、风险边界、规则库和异常处理约定。它们不是后台技术附录，而是体验的一部分。

4.2.3　构建可执行原型：验证 Agent 如何行动

第三个动作是把抽象分工和边界放进一个能运行的 Agent Loop。

可执行原型不一定是完整产品，也不一定连接真实生产系统。它可以使用模拟数据、沙盒工具和人工扮演的模型返回。但它至少要让团队看见一条真实或接近真实的行动链：用户提出目标，Agent 解释理解，读取上下文，形成计划，调用工具，检查结果，在风险点停下，请求人类判断，继续或回退，最后留下结果与轨迹。

这里的重点不是展示模型能生成多漂亮的结果，而是验证系统怎样行动、怎样失败和怎样克制。

微软 HAX Playbook 的做法值得参考。它不是等完整 AI 系统建成后再寻找错误，而是帮助团队提前枚举常见的人机 AI 交互失败，并用低成本模拟方式把这些失败放进早期用户测试。⁵ 对 Agent 原型来说，这意味着第一版就应该包含错误政策、缺失订单、支付工具超时、金额冲突、重复执行和用户拒绝授权等场景。

这一动作的产物包括可运行 Demo、任务 Loop、工具调用流程、异常路径、确认点、回滚方式、轨迹视图和最小可验证工作流。

4.2.4　用 eval 与用户判断共同测试：既测系统，也测关系

可执行原型让团队看见一次真实行为，但一次成功不能证明系统稳定。模型输出具有变化，Agent 又会跨多轮调用工具和修改环境，一个早期小错误可能在后续步骤不断放大。

eval 可以理解为一组可重复运行的任务样本、环境、评分标准和检查方法。它不仅检查最终答案，还可以检查工具是否用对、参数是否正确、是否遵守权限、是否在高风险场景暂停，以及模型或提示变化后是否出现回归。

Anthropic 在介绍 Agent eval 时，把一次评估拆成任务、重复试验、评分器和完整轨迹。由于模型每次可能走不同路径，团队通常需要运行多次，并组合代码检查、模型评分和人工评分。它也强调，没有单一评估层可以抓住所有问题；自动 eval、生产监控和周期性人工审查需要共同工作。⁶

但 eval 不能代替真实用户。它可以判断 Agent 是否遵守规则，却未必能判断用户是否知道什么时候应该怀疑；可以检查确认按钮是否出现，却未必能判断用户是否理解确认后的影响；可以测任务完成率，却未必能发现用户已经把审批当成无意义点击。

所以测试必须有两层：eval 测系统的稳定性、边界遵守、失败模式和回归风险；用户研究、可用性测试与专家审查测意义、信任、控制感、责任和真实场景适配。

这一动作的产物包括 eval 集、失败样本库、行为回归报告、用户测试记录、专家审查、信任校准观察和人工介入分析。

4.2.5　运行时治理与持续校准：发布之后仍然在设计

第五个动作是让系统在真实环境中持续可见、可管和可改。

运行时治理要回答：当前有哪些 Agent 在运行，它们属于谁，访问了哪些数据和工具，哪些动作被批准或拒绝，哪些任务频繁失败，哪里发生过越权、回滚和人工接管，模型或规则更新后体验是否退化，以及新的失败是否已经进入 eval 集。

NIST 的 AI 风险管理框架把 Govern、Map、Measure、Manage 组织成贯穿生命周期的持续活动，并明确提出 AI 系统应在部署前测试，也要在运行中定期测试。它特别说明这些动作不是按顺序完成的检查清单，风险管理需要随着环境、知识和影响变化不断更新。⁷

对于高风险系统，这种持续监督也不只是最佳实践。《欧盟人工智能法案》第 14 条要求高风险 AI 系统通过适当的人机界面接受有效的人类监督，并指出监督强度要与风险、自主程度和使用情境相称。⁸ 这说明“有人负责”不能只写进制度文件，还必须转化为人真的看得见、看得懂、来得及干预的产品机制。

这一动作的产物包括 Agent 看板、审计日志、权限复查、模型与提示版本记录、异常告警、回滚策略、持续 eval，以及把真实反馈写回规则和测试集的更新记录。

4.2.6　流程的重量应该跟着风险走

五个动作不代表每个 AI 功能都要使用同样厚重的方法。

一个只在本地整理草稿、结果可以随时撤销的助手，可能只需要简化的人机分工、少量边界案例和基础回归测试。一个会动用资金、读取敏感数据、修改生产系统或对外发送承诺的 Agent，则需要完整的责任图、权限隔离、可执行原型、严格 eval、人工审批和运行时审计。

团队可以用四个变量决定流程重量：风险有多高，结果是否可撤销，影响半径有多大，系统判断是否有足够证据。

这套流程不是审美上的新潮框架，而是从 Agent 的新风险中推导出来的方法。风险在哪里，设计动作就应该补到哪里。

4.3　从共情到定义委托关系：旧方法为什么不够了

在经典 Design Thinking 中，共情帮助设计师理解用户说了什么、做了什么、感受到什么，以及表面需求背后真正的问题。Agent 时代不但没有降低共情的重要性，反而扩大了需要被理解的处境。

过去，设计师主要共情一个正在使用工具的人；现在，还要共情一个把任务交出去、等待系统行动、检查系统结果，并可能为系统后果负责的人。

4.3.1　用户想要结果，不等于愿意交出全部过程

用户说“我希望退款更快”，不等于愿意让 Agent 自动批准所有退款；说“我不想重复填写信息”，不等于同意系统读取全部历史订单；说“帮我回复客户”，也不等于允许系统直接发送。

传统需求研究很容易把“希望减少麻烦”翻译成“提高自动化程度”。但效率只是委托关系中的一个变量。用户还会关心自己是否理解过程、能否改变目标、能否保留最后决定、出错后是否有机会补救，以及责任是否被系统悄悄推回自己。

所以，共情阶段要多问三类问题。

第一类是保留什么。任务中有哪些判断承载了用户的专业经验、价值立场、关系维护或法律责任，不能因为系统能做就全部交出去？

第二类是何时介入。用户希望每一步确认、只在异常时介入，还是在任务结束后抽查？不同角色、不同风险和不同熟练度可能需要不同答案。

第三类是如何安心。用户需要看见什么依据、影响范围和退出方式，才愿意让 Agent 继续？用户说“不信任 AI”时，真正缺少的可能不是一句免责声明，而是可验证证据和可执行控制。

4.3.2　把任务拆成决定、行动和责任

定义委托关系时，不能只按页面或功能拆任务，更适合把每个环节拆成三层。

决定层回答“谁判断”。例如退款资格是由规则判断、Agent 建议，还是主管决定。

行动层回答“谁执行”。即使人做了决定，系统也可以负责查找订单、计算金额和调用退款工具。

责任层回答“谁确认后果并处理例外”。系统自动执行不代表系统可以承担组织责任；人点击确认也不代表他在信息不足时真的拥有有效判断。

这三层经常被一个“自动化”概念混在一起。事实上，Agent 可以自动收集资料，却不自动决定；可以自动生成建议，却不自动执行；也可以在清楚规则内自动执行，但把异常升级给人。分开之后，设计师才能在减少操作负担的同时保留必要判断。

4.3.3　从一句设计挑战，扩展为一份委托假设

传统问题定义可能写成：“如何帮助客服更快、准确地处理退款？”

Agent 时代还需要补充一份委托假设：

Agent 可以读取当前退款所需的订单、物流和政策，在规则明确且金额低于阈值时整理事实并建议结果；涉及政策冲突、特殊费用、重要客户或高金额时必须升级给人；任何对外通知和实际退款在第一阶段都要由客服确认；用户可以查看依据、修改金额、拒绝执行并接管任务。

这份假设不是最终答案。它把团队对自主程度、上下文、边界、确认和接管的初步判断写清楚，等待原型和测试推翻。

一份可用的委托假设至少包含七项内容：

1. 用户真正想完成的目标是什么；
2. Agent 负责哪些决定和行动；
3. 人保留哪些决定与否决权；
4. Agent 可以使用哪些上下文和工具；
5. 哪些情况必须追问、暂停或升级；
6. 用户怎样查看、修改、撤销和接管；
7. 怎样判断这次协作既有效又没有越界。

4.3.4　用人机责任图验证委托是否成立

仍以退款 Agent 为例，可以先画一张简化的人机责任图。

这张图的价值不只是分配工作，而是暴露依赖关系。假如 Agent 要判断资格，却没有获得当前政策，就说明上下文不完整；假如人要审批高额退款，却看不到金额构成和历史动作，就说明审批只是形式；假如支付失败后没有可靠回执，系统就不能安全自动重试。

人机责任图因此不是画完后交给研发的组织图，而是后续上下文、权限、界面、原型和 eval 的共同索引。

4.3.5　不要只访谈用户想委托什么，还要观察他们怎样监督

用户在访谈中常会高估自己愿意检查的程度。面对抽象问题时，人可能说“每一步都要让我确认”；真正使用后，又会因为频繁弹窗产生审批疲劳。相反，一些用户说“全部自动就好”，遇到一次意外操作后才发现自己需要更早看见计划和影响范围。

所以委托关系不能只靠态度问卷定义。设计师还要在可执行原型中观察：用户在哪些节点真的停下来检查，哪些解释能帮助判断，哪些确认只是机械点击，什么时候希望系统主动，什么时候觉得被打扰，出错时能否找到接管入口。

更成熟的设计不是固定一个对所有人相同的自主等级，而是在业务底线内允许不同任务和用户调整。但调整必须有保护：高风险下限不能被轻易关闭，权限扩大要有明确说明，系统也不能只因为用户连续批准几次，就在后台悄悄把“需确认”升级为“自动执行”。

从共情到定义委托关系，真正增加的不是一张新图，而是一种新的研究视角：理解人怎样把事情交出去，怎样保留判断，以及怎样在不亲自完成每一步的情况下仍然拥有任务。

4.4　从静态原型到可执行 Agent Loop

传统原型让团队提前看见产品。Agent 原型还要让团队提前经历产品的行为。

一个只有聊天框和结果卡片的原型，可能看起来已经很像 AI 产品，但只要每一次结果都是设计师预先写好的，它验证的仍然主要是界面表达，而不是 Agent 的行动能力。

4.4.1　静态原型看不见四类关键风险

第一类是理解风险。用户目标含糊时，Agent 会追问还是擅自补全？它复述的目标是否遗漏了关键限制？

第二类是执行风险。Agent 会选择什么工具、用什么参数、按什么顺序行动？一次失败会不会触发重复写入？

第三类是边界风险。Agent 是否会为了完成目标扩大读取范围，顺手修改用户没有要求的内容，或把建议误当成授权？

第四类是恢复风险。上下文缺失、工具超时、结果冲突或用户中断后，系统能否停止、保存当前状态、回退已经完成的动作，并把任务交还给人？

这些风险都发生在页面之间和系统内部。团队如果只评审理想结果，就会把最需要设计的部分留到上线后。

4.4.2　最小可执行 Loop 包含什么

复杂 Agent 的内部实现可以不同，但从体验角度看，一个最小可执行 Loop 通常包含以下状态：

目标 → 理解 → 计划 → 行动 → 观察 → 判断 → 继续 / 追问 / 回退 / 终止

目标是用户希望完成的事情和成功标准。理解是 Agent 对对象、范围和限制的解释。计划是准备采取的步骤和工具。行动是真实或模拟的工具调用。观察是读取环境返回的事实。判断是对当前结果是否足以继续的检查。最后，系统可能继续执行，也可能因为信息不足、风险过高或用户反对而追问、回退或终止。

每个状态都需要同时设计三层内容。

如果原型只有界面层，就无法验证行为；如果只有行为日志，真实用户又无法判断和介入；如果没有规则层，所有安全边界都只是希望模型自觉遵守。

这里不必把“可执行”误解为一开始就建设完整后台。《UX for AI》建议把低保真的 Figma 或便签界面接到最小可运行模型：界面仍然可以粗糙，但模型响应、工具结果和失败必须真实发生。⁹ 这种组合让团队用较低成本同时观察交互表达与模型行为，也避免精致的静态稿掩盖核心假设尚未经过运行验证。

4.4.3　先原型失败路径，再装饰成功路径

AI Demo 很容易挑选一次最顺利的生成结果。这样做适合展示能力，却不适合发现产品问题。

设计团队可以在第一轮原型里主动加入几种失败：用户没有说退款对象；政策库里存在两个版本；订单缺少支付记录；Agent 算出的金额与支付系统不一致；执行工具超时但实际已成功；用户在第三步改变目标；主管拒绝审批并要求修改理由。

然后观察系统是否能够：识别缺口而不是猜测，显示冲突而不是抹平，查询外部真实状态而不是盲目重试，保留已经完成的工作，解释哪些动作已发生，并让人以合理成本接管。

失败原型并不要求团队一开始就接入所有真实系统。可以用“绿野仙踪”方法，由团队成员在后台模拟模型或工具；也可以用固定失败脚本、沙盒数据和有限工具做最小实现。关键是让参与者真的面对不确定结果并作出判断，而不是只对一段理想流程发表评论。

4.4.4　把确认设计成有信息的决定

可执行 Loop 经常会暴露一个问题：团队虽然设置了人工确认，但确认者并没有足够信息。

一个有效确认至少要回答：Agent 准备做什么，为什么这样做，将使用或修改哪些对象，影响范围有多大，结果是否可撤销，还有哪些备选方案。如果用户只能看到“是否继续”，human-in-the-loop 就可能只是把系统责任转移给一个无法判断的人。

不同风险需要不同确认强度。低风险、可撤销的修改可以在执行后提供撤销；中等风险动作适合先显示差异；高风险或不可逆动作需要展示依据、影响范围和明确授权，必要时还要由具备专业能力的人复核。

设计师要测试的不是确认弹窗有没有出现，而是用户能不能在有限时间内做出有根据的决定。

4.4.5　Loop 还需要一条反馈链

一个能检查、回退和继续的 Loop 具有容错能力，但不一定会从错误中变好。

如果用户每次修改金额、拒绝建议和接管任务都只保存在聊天记录里，同样的错误下次还会重复。运行时治理最终会变成人类不断兜底，而不是系统持续校准。

所以原型还要包含一条反馈链：人的批准、修改、驳回和接管怎样被结构化记录；记录进入规则库、Skill、案例集还是产品需求；新的规则由谁审核；生效前要跑哪些 eval；不同审阅者给出冲突判断时怎样处理。

反馈不能不加判断地自动变成系统规则。一个用户的一次性偏好可能不适合全部人，某次紧急处理也可能违背常规流程。更稳妥的方法是先保存案例与理由，归类重复模式，由负责角色确认，再更新边界、上下文或 eval。

因此，可执行原型的完整目标不是“让 Agent 跑通一次”，而是让团队看见一个闭环：系统行动，人类判断，结果留下证据，证据能够推动下一轮设计。

4.4.6　怎样判断原型已经提供了有效证据

一个 Agent 原型不需要达到生产质量，但至少应该回答几项关键问题：

• 同一任务运行多次时，哪些路径会变化，哪些承诺保持稳定；
• Agent 使用的上下文、工具和权限是否与任务匹配；
• 用户能否看见关键状态、依据和外部影响；
• 高风险动作是否会在规则层被阻断或升级；
• 失败后是否能确认真实状态并安全恢复；
• 人的介入是否被记录，并能进入下一轮测试和规则更新。

当原型能提供这些证据时，设计评审才不再只讨论界面像不像最终产品，而是开始讨论这套人机协作是否值得被交付。

4.5　五件事如何互相喂养：一个循环，而不是一条流水线

如果把五组动作理解成一条线，团队很容易制造新的瀑布流程：研究结束后锁定分工，分工结束后锁定边界，边界结束后才做原型，测试通过后交给运营治理。这样的结果，仍然无法处理 Agent 产品最重要的事实——很多关键问题只有系统真正行动后才会出现。

更准确的关系是：

分工提出假设，边界把假设变成约束，原型让约束面对真实行为，测试把行为变成证据，治理让真实世界继续产生新证据；新证据再回到下一轮分工与边界。

4.5.1　第一版分工只是待验证假设

团队在项目开始时可能认为，低于 500 元的退款可以自动执行。但原型运行后发现，有些低金额订单涉及已使用权益或外部平台，虽然金额不高，处理后果却复杂。此时，分工不能只看金额，还要加入订单类型和可撤销性。

相反，团队也可能一开始要求所有对客通知都人工确认。用户测试后发现，标准状态通知内容固定、影响较低，频繁确认只会造成机械点击。团队便可以让系统自动发送标准通知，把人工判断留给包含承诺、补偿或争议处理的内容。

这说明分工不是根据“AI 看起来能不能做”一次决定，而是根据失败样本、用户负担和实际后果反复调整。

4.5.2　边界由越权案例不断补全

团队很难在白板上枚举所有边界。Agent 可能没有违反任何显式规则，却为了完成任务做了用户没有预期的合理补全。例如用户让它“处理这笔退款”，Agent 同时取消了尚未发货的补寄订单；从效率上看似乎合理，从授权范围看却已经越界。

原型和真实运行中出现的此类案例，需要被写回权限模型和 eval。团队可以规定退款任务默认只处理资金，不得自动改变物流和售后工单；如果确实需要联动，必须先展示完整影响并重新授权。

边界因此不是一份完成后封存的禁止清单，而是一套从案例中持续生长的行为合同。

4.5.3　eval 与用户判断互相校准

eval 可以大规模运行同类任务，发现某个模型版本在政策冲突场景中的失败率上升，也可以检查高风险动作是否都触发了审批。但评分标准本身从哪里来，仍然需要人的判断。

如果 eval 只检查“是否完成退款”，Agent 可能用不合适的政策完成任务；如果只检查“是否请求确认”，系统又可能在每一步都请求确认，以牺牲体验换取高分。设计师、产品、工程、业务专家和真实用户需要共同定义什么叫好：结果正确只是基础，还要考虑证据是否充分、介入是否及时、操作负担是否合理、错误是否可发现与恢复。

反过来，用户测试中出现的问题也需要转化为可重复案例。一次访谈里，客服发现 Agent 容易把“建议补偿”写成“承诺补偿”，这不应该只停在研究报告里，而应该加入 eval 集，检查不同模型和提示版本是否仍然保持措辞边界。

因此，eval 不是工程团队独立维护的技术指标，用户研究也不是设计团队独立保存的洞察。两者需要共享失败样本和成功标准。

4.5.4　治理数据决定下一轮设计重点

发布前测试能够覆盖已知风险，真实环境会带来团队没有想到的任务、组织习惯和异常组合。

运行时看板不应该只显示调用次数、成本和完成率，还要显示与人机协作有关的信息：哪些任务经常被接管，哪些动作经常被拒绝，哪些解释被反复展开，哪些审批几乎总被直接通过，哪些权限长期没有使用，哪些错误会造成重复操作或影响外部用户。

这些数据可以推翻原来的设计假设。频繁接管可能说明 Agent 能力不足，也可能说明上下文不够；长期直接通过的审批可能说明任务可以自动化，也可能说明用户已经疲劳；某项权限从未使用，可能应该收回，而不是为了未来可能用到一直保留。

治理的价值不是证明系统一直正常，而是让团队知道下一轮应该研究什么、收紧什么和简化什么。

4.5.5　人的反馈要进入系统，但不能被系统直接吞下

五组动作之间最容易断开的地方，是人工反馈。

用户驳回了 Agent 的决定，运营人员修正了政策，设计师调整了确认方式，工程师修复了工具重试，但这些变化如果分别留在聊天记录、工单、设计稿和代码里，系统就没有形成共同记忆。

团队可以建立一条最小反馈路径：每次重要失败保存任务、上下文、轨迹、结果、人的判断和修正理由；由相应 owner 归类为能力问题、上下文问题、权限问题、界面问题或规则问题；再决定更新提示、工具、政策、设计、权限或 eval；更新完成后重新运行相关样本，并记录是否真的改善。

这条路径需要保留人的审核。不同客户、地区和业务线可能有不同标准，两个专家也可能对同一案例判断不一致。系统面对冲突时应该标记并升级，而不是用多数票自动形成一条看似稳定但缺少责任人的规则。

4.5.6　允许顺序颠倒，要求证据闭环

现实项目可以从不同位置开始。

有些团队先从用户研究和委托假设开始；有些团队已经有一个可运行 Demo，需要从失败路径反推边界；有些成熟产品先在生产监控中发现行为漂移，再补 eval 和责任图。顺序不同不是问题，问题是五类证据是否最终连起来。

只要证据能够闭环，团队就不必为了遵守流程而假装每一步已经想清楚。Agent 时代更诚实的设计方式，是明确哪些内容只是当前假设，用可执行行为检验它，再把结果写回共同事实。

4.6　什么依然有效：传统 Design Thinking 保留下来的部分

设计思维变了，不等于过去的方法应该被废弃。

如果团队只学习权限、eval 和 Agent 架构，却不再理解人的需求，就可能做出一个技术上受控、实际上没有价值的系统；如果团队只追求系统完成率，却不问用户是否愿意委托，就会把自动化效率误当成好体验。

真正变化的是经典方法的对象和责任范围。

4.6.1　共情仍然有效，但角色变多了

过去共情使用者，现在还要共情委托者、监督者、审批者、接管者和责任承担者。

设计师要理解的不只是“完成任务时哪里麻烦”，还包括等待 Agent 时是否焦虑，审查大量结果时是否疲劳，面对流畅解释时是否容易过度信任，系统出错后是否知道自己能做什么，以及长期使用后是否仍然拥有必要判断。

用户仍然是设计中心，但“以人为中心”不再等于“让人完成每一步”，而是让人在不同自主等级下仍然保有知情、选择、否决和接管能力。

4.6.2　问题定义仍然有效，但要同时定义非目标和边界

越强的 Agent 越容易把一个模糊问题做大、做偏和做过头。

因此问题定义不仅要写清用户目标和业务目标，还要写清为什么使用 Agent、哪些部分不需要 AI、当前版本明确不做什么、哪些结果不能接受，以及什么情况下应该停止而不是继续尝试。

一份好的定义不是鼓励系统尽可能完成任务，而是让团队知道“完成”必须满足哪些边界。

4.6.3　创意发散仍然有效，但不只发散功能和页面

Agent 产品的创意空间不只有聊天入口、结果卡片和自动化功能。团队还可以发散不同的人机分工、上下文获取方式、权限等级、确认策略、失败恢复、证据表达、人工介入点和反馈机制。

例如，面对同一类退款任务，创意不一定是“让模型判断得更准”，也可以是先用确定规则筛出大部分明确案例，只让 Agent 处理材料整理和模糊例外；或者让 Agent 给出多个带证据的方案，由专家选择；也可以降低 Agent 能动性，让它只生成可执行计划，不直接调用资金工具。

新的设计思维会把“减少 Agent 自由度”也视为一种有价值的创意，而不是能力不足。

4.6.4　原型仍然有效，但原型对象从界面扩展到行为

原型的本质一直是用较低成本把想法变成可以讨论和检验的材料。这个原则没有改变。

改变的是，Agent 产品要原型的不只是页面，还有上下文、计划、工具调用、权限阻断、异常恢复、人类接管和反馈写回。静态原型仍然可以验证界面表达，可执行原型则验证系统行为，两者不应互相替代。

团队可以先用低保真页面讨论信息层级，再用沙盒 Loop 验证权限和失败，最后把两者合在真实任务中测试。原型不必一步到位，但必须覆盖真正高风险的假设。

4.6.5　测试仍然有效，但一次满意不再代表稳定

最终体验仍然发生在人身上，所以用户测试不会被 eval 取代。设计师仍然要观察用户是否理解、是否完成任务、是否感到可控，以及产品是否适合真实情境。

但 Agent 的系统行为需要在大量任务、边界条件和版本变化中重复验证。传统用户测试回答“人怎样体验这个系统”，eval 回答“系统是否持续做出符合要求的行为”，生产监控回答“真实世界是否出现了我们没想到的问题”。三者共同构成新的测试结构。

4.6.6　发散与收敛仍然有效，但循环会持续到发布之后

双钻中最值得保留的不是四个阶段的名称，而是不断发散可能性、再根据证据收敛判断的习惯。

Agent 产品同样需要这组节奏。团队先发散可能的人机分工和失败模式，再根据原型与研究收敛第一版边界；上线后，新的运行数据再次打开问题空间，团队重新定义、原型和测试。

因此，发布后的治理不是在设计流程外面增加一个运营尾巴，而是下一轮双钻的输入。设计不再以交付文件结束，而是围绕系统行为持续进行。

可以用下面这张表概括保留与扩展的关系。

所以，Agent 时代并不需要一套与经典 Design Thinking 完全断裂的新宗教。它需要的是把旧方法推进到新的设计对象上：共情不只理解使用，定义不只描述问题，原型不只展示界面，测试不只发生一次，交付也不再意味着结束。

本章小结

Agent 时代，设计思维发生了六个相互关联的变化。

第一，旧流程依赖的确定性前提开始松动。系统行为不再完全稳定，用户不再是唯一行动者，界面不再是全部设计对象，静态原型无法覆盖连续行动，上线也不再是明确终点。

第二，设计流程增加了五组动作：定义人机分工，设计上下文与边界，构建可执行 Agent Loop，用 eval 与用户判断共同测试，以及在运行中持续治理。它们不是新的固定流水线，而是一组风险驱动、可按场景裁剪的设计对象。

第三，共情扩展为对委托关系的理解。设计师不仅要知道用户想要什么，还要知道用户愿意交出什么、必须保留什么、何时介入，以及怎样在不亲自完成每一步时仍然拥有任务。

第四，原型从演示界面升级为验证行为。好的 Agent 原型需要让目标、计划、工具、状态、失败、确认、接管、回退和反馈真实或近似真实地发生。

第五，分工、边界、原型、测试和治理会互相喂养。第一版设计只是待验证假设，失败案例和运行数据会不断写回责任、权限、规则与 eval。

第六，经典 Design Thinking 的核心仍然有效。共情、定义、发散、原型、测试和迭代没有消失，只是对象从“人怎样使用产品”扩展到“人与一个会行动的不确定系统怎样共同完成任务”。

如果说传统设计思维主要回答的是“如何以人为中心设计一个好用的产品”，那么 Agent 时代还要回答：

如何设计一个可委托、可理解、可验证、可接管，并能在真实运行中持续校准的人机协作系统？

这套方法也会直接改变设计师的工作。设计师不能只交付页面和流程，还要参与构建可运行原型，把团队知识组织成 Agent 可读取的上下文，定义责任和权限，并与产品、工程和业务共同维护 eval 与验收标准。下一章将继续讨论：当设计过程发生这些变化后，设计师具体要做什么，又要交付哪些新的东西。

¹ Design Council, “The Double Diamond turns 20,” 2023，https://www.designcouncil.org.uk/fileadmin/uploads/dc/Documents/Press_Releases/The_Double_Diamond_turns_20_-_9_May_2023_Final.pdf 。

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

³ K. J. Kevin Feng, David W. McDonald, Amy X. Zhang, “Levels of Autonomy for AI Agents,” 2025，https://arxiv.org/abs/2506.12469 。

⁴ Figma, “Figma’s design agent, now with custom tools and greater context,” 2026，https://www.figma.com/blog/agent-custom-tools-context-skills/ 。

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

⁶ 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://doi.org/10.6028/NIST.AI.100-1 。

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

⁹ Greg Nudelman and Daria Kempka, UX for AI, Wiley，章节 “Combine Low-Fi UX Tools and Sophisticated AI Models”；本地转述见 素材/书摘-第3轮-UX-for-AI.md。