AI产品设计中如何划定自主权边界：从确定性到不可逆步骤的划分方法

我们过去设计的是可预测的用户流程。如今，AI 能够自行解读、决策并行动。以下是为什么最艰难的设计决策往往发生在自主性终止的地方。

2025 年 9 月，Thinking Machines Lab 的研究人员将同一个提示词（prompt）通过语言模型运行了 1,000 次。他们将温度（temperature）设置为零，理论上这应该使 token 选择具有确定性。

他们从相同的提示词、模型和设置中得到了 80 种不同的补全结果。

更有趣的是，前 102 个 token 的所有 1,000 个输出都是完全相同的。差异从第 103 个 token 开始，当时模型描述了 Richard Feynman 的出生地。

研究人员将这种变化追溯到在不同服务器批处理条件下计算执行的方式。通过修改实现方式，他们最终使所有 1,000 个输出保持一致。

他们的 研究 证明了一个重要事实：即使你试图让语言模型行为可预测，运行它的底层基础设施仍可能引入变数。

现在想象一下基于该模型构建一个产品。一个创建货运预订、更新客户记录或在系统间移动医疗文档的产品。

问题不在于 AI 能产生不同的答案。这通常正是我们使用它的原因。

问题始于这些答案转化为行动时，而没有人决定流程中哪些部分允许是不可预测的。

几十年来，我们在设计软件时都假设我们知道接下来会发生什么。AI 正使这一假设越来越难以维持。我认为许多早期团队仍然像什么都没改变一样进行设计。

我们过去知道接下来会发生什么

想想过去几十年我们是如何设计数字产品的。

你打开一个应用，选择某样东西，填写表单，点击按钮，然后进入下一步。界面根据预定义规则做出响应。

航班预订是一个很好的例子。选择目的地，选择日期，挑选航班，输入乘客详细信息，付款，然后收到确认。

在该体验背后可能有数百种条件，但设计师和工程团队可以预先定义它们。如果支付失败，显示错误。如果座位不可用，提供另一个选项。如果信息缺失，要求用户补充。

这种思维塑造了我们大多数设计工具和方法。用户流程、线框图、旅程地图、信息架构、设计系统和交互原型。

我们设计状态以及状态之间的转换。我们决定当某人点击按钮、犯错或返回未完成流程时会发生什么。

传统软件从来不是完美确定性的。搜索结果会变化，推荐是个性化的，外部服务可能会失败。但大多数事务性界面的核心行为是由显式规则定义的。

设计师不需要知道某人会预订哪个航班。他们需要知道预订航班的机制是如何运作的。

有趣的是，软件超越显式命令的概念并不新鲜。1993 年，Jakob Nielsen 撰写了关于 非命令式用户界面 的文章。他描述了能够推断用户意图的系统，而不是要求用户通过特定命令传达所有内容。那是 30 多年前的事了。

几十年来，我们一直在构想能够理解意图的软件。只是我们无法以商业上可行的方式构建其中许多体验。

现在我们可以做到了，这改变了设计用户 流程的含义。

用户不再需要定义每一个 步骤

想象一下你正在设计一个报告工具。

以前，用户需要选择数据、配置筛选条件、选择报告格式、生成报告并下载它。界面存在的目的是收集指令。

如今，有人只需写道：“告诉我为什么我们的转化率上个月下降了，以及我们应该调查什么。”

产品可以解读请求、检索信息、比较时间段、识别模式，并决定如何呈现发现结果。

我们从界面中移除了五个步骤，但引入了一种完全不同类型的复杂性。

如果数据不完整怎么办？如果两个仪表板对转化率的定义不同怎么办？如果 AI 生成了一个看似令人信服但实际上错误的解释怎么办？

传统的用户流程无法完全涵盖这些可能性，因为系统现在可以就如何处理该 任务做出决策。

这也是 AI 采用与实际自动化之间的差异变得有趣的地方。

根据 2026 年斯坦福 AI Index，88% 的受访组织报告在 2025 年使用了 AI，高于 2023 年的 55%。然而，在所有几乎全部业务职能中，规模化 AI 智能体部署仍保持在个位数。

公司正在使用 AI，但让它运行有意义的业务流程是一个截然不同的挑战。

要求 AI 起草一封邮件和允许它将那封邮件发送给 4,000 名客户之间有着巨大的区别。

这就是 UX 变得比仅仅让界面看起来智能重要得多的地方。

非确定性与确定性

我认为有必要澄清术语，因为我们往往将这些概念混为一谈。

确定性系统遵循预定义的逻辑。给定相同的相关输入和状态，相同的规则会产生相同的 输出。

非确定性系统可以在表面上相同的条件下产生不同的结果。对于生成式 AI，谈论概率行为、解释和不确定性通常更有用。

思考验证电子邮件地址和理解电子邮件 含义之间的区别。

检查电子邮件地址是否具有正确格式是一项确定性任务。

理解传入的消息是投诉、预订请求还是价格咨询需要解释。

现在将这种解释连接到实际的工作流。

如果 AI 判定它是预订请求，它可能会创建发货单。如果判定它是投诉，它可能会升级问题。如果识别出价格咨询，它可能会准备报价单。

用户没有明确选择一个工作流。系统 选择了。

所以是的，输出可能是非确定性的 UI。措辞会变化，内容会变化，有时甚至屏幕上出现的内容结构也会 变化。

但更大的问题是 UX。

用户需要了解系统在做什么，预测他们行动的后果，纠正错误，并知道何时可以信任一个 结果。

你可以设计一个漂亮的 AI 界面，拥有出色的排版、流畅的动画和完美打磨的聊天组件。但如果底层系统做出的决策让用户无法理解或纠正，那么体验就是 破碎的。

困难的部分在于设计产品被允许对该响应做什么。

最大的错误是让一切都变得非确定性

有一种假设认为，AI 产品的自主性越强，它就越好。

既然 AI 可以理解信息，为什么还要让人们填写表单？既然智能体可以决定该做什么，为什么要使用预定义的工作流程？

这些问题都很合理。但仅仅因为 AI 能够解释信息，并不意味着它应该负责执行由此产生的每一个动作。

而且，仅仅因为一个产品使用了 AI，并不意味着其中的所有东西都必须以概率方式运行。

事实上，一些更有趣的 AI 产品正在反其道而行之。它们刻意结合确定性和非确定性系统，精确决定每个系统在何处接管控制权。

许多失败源于将本应是表单的东西变成了非确定性的。

这对早期阶段的创始人尤其相关。将每一次交互都变成提示词是很诱人的，因为这会让产品感觉更高级。

但有时，一个表单、一个预定义的工作流程或一个简单的确认按钮正是体验所需要的。

两个产品特别能说明这一点。

Routine Labs：让 AI 构建工作流程，而不是在运行时即兴发挥

Routine Labs 致力于自动化现有遗留软件内部的流程，特别是在医疗保健领域。其方法很有趣，因为 AI 用于帮助构建自动化，而生产环境的执行遵循确定性工作流程。

想象一家医疗诊所需要在多个应用程序之间处理文档。一份血液检测报告到达后，需要被识别、与患者同意书进行核对，并上传到德国的电子患者记录（称为 ePA）。

传统上，必须有人在各个系统之间切换，找到正确的信息，检查必要的条件，并手动完成流程。

一个完全自主的 AI 智能体可能会尝试每次都解释并导航那个过程。

Routine 采取了不同的方法。

据该公司称，其混合引擎使用生成式 AI 来创建自动化，但在生产环境中运行的工作流遵循可重复、有日志记录的逻辑。在其医疗保健网站上，Routine 还声明在生产操作期间不使用 AI，也不将个人数据传输给 LLM。

这是一个非常深思熟虑的产品决策。不确定性集中在构建自动化阶段，在那里流程可以被定义和检查。生产执行被设计为可预测的。

现在想想这对 UX 意味着什么。

用户不一定需要与智能体对话。他们需要知道正在运行什么自动化，哪些步骤已完成，是否处理了正确的文档，以及是否有事情需要他们的关注。

Routine 公开的产品示例展示了正是这种类型的工作流程：搜索血液检测，检查 ePA 同意书，并上传文档。

界面可以通过熟悉模式（如状态指示器、执行历史和审查步骤）来传达进度和异常情况。不需要聊天机器人。

而这正是这种方法有趣的地方。智能只在能增加价值的地方使用，而不会让整个体验依赖于模型每次都能正确解读流程。

Routine 是一个例子，展示了如何在保持实际执行确定性的同时构建 AI 原生产品。

Zauber：让 AI 处理模糊性，但使不确定性可见

Zauber 从另一个方向着手解决同样的问题。

它为海运和空运货代构建 AI 代理，在 Outlook 等现有工具中运行，并与 CargoWise 等系统集成。

货运代理是 AI 的一个有趣环境，因为大量的运营工作依赖于对非结构化信息的解读。

电子邮件、PDF、装箱单、不断变化的运输细节、特殊指令以及不完整的文件。信息来自不同来源，且并不总是 一致。

操作员可能会收到一封请求预订运输的电子邮件，附带装箱单，并且在对话中的某个地方更改了交付日期。

传统上，某人会阅读所有内容，解读请求，检查细节，并手动将信息输入到预订 系统。

Zauber 使用 AI 来处理大部分这种解读工作。

其代理可以读取费率请求，识别相关的运输细节，检索费率，并准备供审查的报价。对于创建预订，它们可以从电子邮件和文档中提取信息，并在 CargoWise 中填充必要的字段。

但最有趣的部分在于该产品如何处理无法 验证的信息。

根据 Zauber 的产品页面，如果申报价值缺失或体积与装箱单不符，系统会标记差异而不是猜测。操作员在创建预订之前确认信息。

想象一下，电子邮件说货物的体积为 58.4 m³，而装箱单说是 60.03 m³。

AI 已经完成了大部分工作，但界面应该使这种不一致可见，显示信息来源，并让操作员解决 它。

产品不是要求用户填写每个字段，而是引导他们的注意力集中在两个重要的字段上。这是一种不同的工作流程设计方式。

关于 Zauber，还有一个我喜欢的细节。其产品文档描述了监控代理会话，包括工作流程何时将控制权交还给人类操作员。交接本身成为公司可以观察、衡量和改进的事情。

Routine 和 Zauber 使用不同的架构，但它们做出了类似的决定。它们不把自主性视为全有或全无的功能。

它们决定 AI 应在何处解读信息，确定性规则应在何处接管，以及用户需要在何时介入。

为什么出色的 AI 演示可能变成糟糕的产品

这里有一个简单的计算，解释了为什么这些决定很重要。

想象一个包含十个步骤的工作流程。每个步骤有 95% 的概率正确完成，并且所有十个步骤都必须成功。假设结果是独立的，整个工作流程成功的概率是：

一个在每个单独步骤都有 95% 可靠性的工作流程，端到端成功的可能性只有大约 60%。

这是一个简化示例，并非实测的 AI 失败率。真实系统具有依赖关系、验证机制、重试和恢复机制，这些因素会改变结果。但它说明了为什么仅靠模型准确率不足以作为产品指标。

AI 可能在大多数情况下正确提取信息。如果它没做到呢？如果一个错误的值被传递给另一个系统怎么办？如果操作成功了但确认失败了呢？如果智能体重复执行操作并创建了重复项怎么办？

很多产品看起来很棒，是因为我们设计和测试的是成功版本。

当模型第一次感到困惑时，真正的产品体验才刚刚开始。传统设计工具的局限性正是在这里显现出来。

Figma 原型非常适合展示预定义状态。它在展示可能的输出分布、可变的执行路径或每 50 次运行中发生一次的故障方面并不特别擅长。

这并不意味着 Figma 无关紧要。这意味着静态屏幕不再足以验证我们正在设计的行为。

如果我们忽视这一点会发生什么？

一种常见的失败是“完成假象”。

智能体声称它更新了记录、发送了电子邮件或创建了预订。但也许它只是准备了该操作。也许 API 失败了。也许系统保存了错误的信息。

如果界面将模型的响应显示为操作成功的证明，用户就没有可靠的方法来知道实际发生了什么。

另一种情况是隐藏的不确定性。从文档中提取的信息可能看起来与从数据库中检索到的已验证信息完全一样。界面赋予两者相同的视觉权重，尽管其中一个是解释性内容，而另一个是权威数值。

然后是相反的问题：过度的人工监督。

一些产品通过要求用户批准所有事情来解决不确定性问题。但如果某人必须审查 100 个决策，且其中 98 个始终是正确的，他们最终会停止关注。

你自动化了原始工作，并用一份新工作取代了它：监督自动化流程。

这不一定是更好的产品。

还有一个问题是错误决策在原本可靠的系统中蔓延。AI 可能会识别出错误的客户，随后每一个确定性步骤都完美执行，却更新了错误的记录。

系统完全按照设计运行，但业务结果是错误的。

这让我们意识到，仅仅设计错误状态是不够的。我们需要设计解释、验证、执行和恢复之间的关系。

我在早期团队中如何着手设计这一点

今天从事新的 AI 产品开发时，我会首先将工作流程映射到三个类别：确定性、模糊性和不可逆性。

这是一项简单的练习，但它迫使你做出那些在你专注于演示时容易忽略的决定。

确定性步骤是具有明确规则的操作。验证必填字段、检查权限、检索记录和防止重复操作。这些通常应通过传统软件处理。

模糊性步骤需要解释。阅读电子邮件、理解文档、分类请求或起草回复。这就是 AI 变得有用的地方。

不可逆或高影响步骤是指具有重大后果的操作。例如发送外部邮件、发起付款、修改敏感记录或提交预订。这些操作需要明确的权限边界、验证机制，并在适当情况下引入人工审批。

一旦你梳理了这些步骤，许多产品决策就会变得更加清晰。你可以确定模型真正需要的地方、界面需要传达的内容，以及哪些操作绝不应静默执行。

接下来我会做的是停止将 AI 输出本身视为界面。对于许多 B2B 产品，我更倾向于让模型返回结构化信息，并由确定性组件进行渲染 。

如果智能体提取了预订信息，用户应该看到标准的预订界面，而不是一段解释模型发现了什么的文字段落。模型负责填充卡片内容，它不需要发明 卡片。

让我们用一个大家都熟悉的例子：预订 航班。

你要求 AI 助手为你和 Ania 预订周五前往里斯本的早班机，并于周日傍晚 返回。

首先是模糊部分。模型必须解读“早班”和“傍晚”的含义，弄清楚你指的是哪位 Ania，并根据你之前的预订做出一些假设。

UI 不会给你一长串聊天回复，而是呈现一个结构化的草稿。你可以看到模型理解了什么、每个假设的来源，并纠正任何看起来错误的地方。目前尚未完成任何 预订。

然后是确定性验证。系统会根据航空公司的数据和预定义规则，检查实际航班可用性、乘客详细信息、票价条件和价格。

一切检查无误。有两个座位可用，可退款票价为 €398，且在你的预算范围内。界面显示经过验证的预订摘要，无需让你逐一查看每项 检查。

现在到了有趣的部分。

你点击预订，但在预订完成前，可退款票价已售罄。唯一剩下的选项是 €342，但它是不可退款的。

从技术上讲，它更便宜，甚至符合你的预算限制。但这并不是你最初同意的 内容。

这就是界面需要改变的地方。UI 不应让智能体自行选择更便宜的机票，而应解释发生了什么，保留所有仍然有效的信息，并询问你是想预订不可退款票价还是寻找其他 选项。

纵观整个流程，有趣之处在于边界如何变化。模型可以解读请求，但不能设定价格或执行预订。规则和实时系统处理验证。当可退款票价突然不可用时，系统会停止并将决策权交还给 用户。

以下是这些边界在同一 预订中如何运作：

一次预订，三个不同级别的自主权。系统可以解读、验证并准备操作，但将控制权交还给用户的规则会根据后果而变化。

这就是为什么我认为我们不能再将 AI 工作流设计为一系列预设屏幕 的原因。

同一任务在解读、验证和执行之间切换。看似简单的决定可能在瞬间就需要人工判断。

而且界面必须能够处理这种情况，而不会让用户从头开始整个流程。

没有必要显示置信度分数或解释模型做出的每一个决定。在假设重要时展示它们，将常规检查保持在后台，并在发生变化时明确后果。

困难的部分在于设计它们之间的过渡。

对行为进行原型设计，而不仅仅是快乐路径

我也会更早地转向可工作的原型。

像 Cursor、Lovable、v0 和 Claude Code 这样的工具使得构建连接到实际模型行为的界面变得更容易。你仍然可以从 Figma 开始，但在某个时刻你需要看到变异性而不是想象它。

重复运行相同的场景。尝试不同的措辞。使用不完整的文档。给系统提供相互冲突的指令。将失败转化为评估案例。

Anthropic 关于 构建有效代理的研究区分了预定义工作流和动态决定自己步骤的代理。它还建议从能解决问题的最简单架构开始。

并非所有事情都需要一个代理。有时，包含一个智能步骤的固定工作流更有用、成本更低，并且显著更易于测试。

对于实际实现，结构化输出、模式、状态机、执行日志和人工审批机制有助于使这些边界成为现实。像 LangGraph 和 LangSmith 这样的工具可以支持有状态的工作流、追踪和评估。

这些工具都不能消除模型的不确定性。它们帮助你设计一个知道当不确定性出现时该做什么的产品。

最后，我会衡量比 AI 完成任务频率更有用的东西。我会衡量工作流需要多少人类注意力。

例如：
人们需要纠正输出的频率有多高？这些纠正需要多长时间？代理需要干预的频率有多高？有多少任务实际上正确完成而没有产生额外工作？

一个自动化了 80% 流程但使剩余 20% 变得痛苦的代理可能节省不了多少时间。目标是减少实现可靠结果所需的总努力。

最艰难的决定是给予多少控制权

对于创始人来说，这就是 UX 变成产品战略的地方。

给 AI 太少的自主权，你就构建了一个昂贵的助手，用户仍然需要做所有的工作。给它太多，用户就必须信任他们无法检查或预测的决定。

没有普遍的答案，因为后果在工作流之间各不相同。起草一封电子邮件不同于发送它。准备预订不同于创建预订。从医疗文档中提取信息不同于修改患者记录。

而且边界不一定是永久性的。

工作流可能始于每个动作都需要批准。在数百次成功执行和可测量的可靠性证据之后，某些步骤可以变为自动。其他步骤可能始终需要人类参与，因为错误的代价太高。

这也改变了我对待从零到一产品的方式。

与其承诺自动化整个业务运营，我会从一个痛苦的工作流开始，使其可测量，理解其例外情况，并逐步扩展。

“我们的 AI 处理您的整个货运操作”听起来可能令人印象深刻。

“我们将收到的发货请求转化为经过验证、随时可创建的预订”是一个更清晰的产品承诺。

你可以衡量节省的时间。你可以了解哪里出了问题。你可以在引入更多自主性之前建立信任。

对于早期初创公司而言，信任是比令人印象深刻的演示更有用的资产。

设计边界，而不仅仅是流程

几十年来，我们专注于让软件更易于人们导航。我们规划用户旅程，移除不必要的步骤，并使界面更具可预测性。

现在我们越来越多地设计代表用户执行部分工作的软件。我们需要了解系统知道什么、假设什么、可以验证什么，以及在信息不完整时允许它做什么。

我们需要决定系统何时应该行动、何时应该询问、何时应该停止。也许最重要的是，我们需要接受并非 AI 原生产品的每个部分都能从更多的 AI 中受益。

有时最好的决定是让模型解释某些内容并将执行交给确定性软件。
有时是准备一个操作并请求确认。
有时是承认没有足够的信息来继续。

Routine Labs 和 Zauber 是有用的例子，因为它们将这些边界作为其产品架构的一部分，而不是将其视为事后补充。

下一代产品设计不仅仅关乎让界面更智能。它关乎决定产品可以安全吸收多少不可预测性。

如果你是该领域的创始人，请选取你最重要的工作流程，并将每个步骤标记为确定性的、模糊的或不可逆的。你可能会发现关于你正在构建的产品比你从另一个关于使用哪个 AI 模型的对话中学到的更多。

你的 AI 不需要每次都以相同的方式运行。
但你的用户需要知道他们可以依赖什么。

参考文献

• Thinking Machines Lab, Defeating Nondeterminism in LLM Inference (2025)
• Stanford HAI, 2026 AI Index Report
• Jakob Nielsen, Noncommand User Interfaces (1993)
• Microsoft Research, Guidelines for Human-AI Interaction (2019)
• Anthropic, Building Effective Agents
• Routine Labs
• Zauber, Product

Routine Labs 和 Zauber 的例子基于其公开可用的产品描述，而非独立的生产测试。

每个人都在构建 AI 代理。谁在设计停止按钮？最初发表于 Medium 上的 UX Collective，人们在那里通过突出显示和回复这个故事来继续讨论。