前端学 LLM

AI 产品为什么需要重新设计 UX

很多团队第一次做 AI 产品时，会自然地把 AI 能力塞进已有界面。

搜索页加一个智能回答，编辑器加一个生成按钮，客服系统加一个聊天框，后台系统加一个“AI 助手”。这些改造看起来很快，但上线后常常遇到同一类问题：用户不知道 AI 正在做什么，不知道结果能不能信，不知道错了怎么改，也不知道什么时候应该接管。

这说明 AI UX 不是传统 UX 的小改版。

传统软件的核心体验是确定性操作。用户点击按钮，系统执行规则，结果通常可预测。AI 产品的核心体验是概率性协作。用户给出意图，系统生成候选结果，结果可能有延迟、可能不完整、可能带有不确定性，也可能需要用户在中间修正方向。

所以 AI 产品需要重新设计 UX，不是因为要追求新鲜感，而是因为系统行为已经变了。

传统 UX 默认系统是确定的

传统 Web 产品大多围绕清晰的输入、规则和输出设计。

用户填写表单，系统校验字段。用户点击筛选，系统返回列表。用户保存设置，系统写入数据库。即使过程复杂，产品也可以把它抽象成稳定的状态机：初始、编辑、提交、成功、失败。

AI 产品不同。

同一个输入可能得到不同输出。模型可能需要很长时间生成。中间可能调用检索、工具、工作流或外部 API。输出可能只是草稿，不适合直接提交。用户也可能在生成一半时发现方向错了，需要打断、补充、重试或只接受一部分。

这让传统 UX 的很多默认假设失效：

传统 UX 假设AI 产品里的变化
输入字段清晰用户意图常常模糊，需要澄清和补全
点击后立即反馈AI 可能需要 streaming、排队和分步进度
输出是最终结果AI 输出更像候选草稿或建议
错误来自系统异常错误也可能来自理解偏差、上下文不足或证据缺失
用户只需确认提交用户需要审阅、编辑、选择、拒绝或局部采纳

AI UX 的第一步，是承认系统不是一个稳定函数，而是一个带概率、上下文和执行过程的协作者。

AI UX 的核心矛盾：能力强，但不总是可靠

AI 产品最容易制造期待，也最容易消耗信任。

模型可以写文章、总结文档、生成代码、查询知识库、规划任务、调用工具。用户一旦看到它能完成复杂任务，就会自然提高期待。但模型又会犯一些不符合传统软件直觉的错误：看似流畅却事实错误，看似自信却证据不足，看似理解了需求却改错范围。

这造成一个核心矛盾：

AI 的能力足够强，值得进入关键工作流；但 AI 的输出不够稳定，不能像普通软件结果一样被无条件提交。

因此，AI UX 不能只优化“生成得更快、更漂亮”，还要优化“用户如何判断、控制和接管”。

这条链路里，生成只是中间一步。真正的产品体验发生在上下文、证据、控制和提交之间。

AI UX 需要重新设计等待体验

传统界面的等待通常很短。加载中、骨架屏、进度条就够了。

AI 等待不同。模型可能需要数秒甚至数十秒，用户还不知道系统是在思考、检索、调用工具，还是卡住了。如果界面只显示一个转圈，用户会很快失去耐心。

AI 产品需要更丰富的等待体验：

  • streaming：尽早显示可读结果，降低空白等待。
  • step progress：展示正在理解需求、检索资料、调用工具、整理答案。
  • cancellable state：用户可以停止生成，而不是只能等。
  • resumable state：失败后可以继续、重试或保留已生成部分。
  • partial result：先给可用草稿，再补充证据或细节。

等待体验不是装饰。它直接影响用户是否愿意把 AI 放进真实工作流。

如果用户不知道 AI 还要多久、不知道它现在在做什么、不知道能不能取消，就会把 AI 当成不可控的黑盒。

AI UX 需要重新设计输入体验

传统输入追求字段明确。AI 输入则经常从自然语言开始。

自然语言的好处是低门槛，坏处是不精确。用户说“帮我优化一下这段话”，可能意味着更短、更正式、更像销售文案、更适合老板看，也可能只是纠错。

所以 AI 输入不应该只提供一个大文本框。

更好的输入设计包括：

  • 给用户可选意图：总结、改写、翻译、解释、提取、生成。
  • 根据当前页面提供上下文：选中文本、当前文档、当前客户、当前任务。
  • 让用户指定约束：长度、语气、格式、受众、语言。
  • 在高风险任务前澄清：范围、目标、是否会修改真实数据。
  • 支持示例和模板：降低用户写 prompt 的压力。

产品层要把“写 prompt”转化成“表达任务”。用户不应该被迫学习模型喜欢什么格式，系统应该把业务任务翻译成稳定的上下文和结构化参数。

AI UX 需要重新设计输出体验

AI 输出不能默认当作最终答案。

在很多场景里，它更像一个可以编辑、比较和采纳的草稿。比如邮件草稿、代码 patch、SQL 查询、知识库回答、报告摘要、客服回复、运营文案。用户需要知道哪些内容来自证据，哪些是推理，哪些可以直接使用，哪些需要复核。

输出体验至少要回答四个问题：

  1. 这是什么类型的结果：答案、草稿、建议、计划还是执行结果？
  2. 它依据什么生成：引用、工具结果、上下文片段还是模型常识？
  3. 用户可以怎么处理：复制、编辑、局部接受、重试、追问、提交？
  4. 它有什么限制：不确定、缺证据、超权限、工具失败、数据过期？

这也是为什么 AI 产品常常需要 citation、diff view、版本对比、局部采纳和可编辑结果。它们不是高级功能，而是把概率性输出变成可工作的产品结果。

产品工程视角：AI UX 是状态设计

从工程上看，AI UX 不只是组件设计，而是状态设计。

一个可靠的 AI 交互至少包含这些状态：

type AIInteractionState =
  | 'idle'
  | 'collecting_context'
  | 'generating'
  | 'waiting_for_tool'
  | 'waiting_for_user'
  | 'completed'
  | 'stopped'
  | 'failed'
  | 'expired';

每个状态都应该对应清晰的 UI、用户可执行动作和后端记录。

状态用户需要看到用户可操作
collecting_context正在读取哪些上下文取消、调整范围
generating正在生成的内容停止、继续输入反馈
waiting_for_tool正在调用什么工具查看参数、取消
waiting_for_user等待确认什么动作批准、拒绝、修改
completed最终结果和来源编辑、采纳、重试
failed失败原因和已保留内容重试、降级、反馈

如果后端只有一条“message”，前端就很难做出好的 AI UX。你需要 run、step、tool call、source、version、approval、feedback 等更细的产品工程对象。

前端视角：不要把 AI 只做成聊天框

聊天框是 AI 产品里最通用的入口，但不是所有任务的最佳形态。

聊天适合探索、问答、澄清和开放式协作。可是很多生产力场景更适合 inline action、命令面板、侧边栏、自动补全、批量操作或 workflow UI。

例如：

  • 写作工具里，选中文本后直接 rewrite 比打开聊天框更顺手。
  • 表格工具里，按列批量抽取比逐条对话更高效。
  • IDE 里，diff patch 比纯文本代码建议更可靠。
  • 企业后台里，确认面板比一句“是否继续”更安全。
  • Agent 执行任务时，step timeline 比聊天消息更可审计。

AI UX 的目标不是让所有界面都变成 ChatGPT，而是把 AI 能力放到用户原本工作的地方。

常见坑

第一个坑，是把 AI 输出当成最终事实。

如果界面没有引用、没有不确定性表达、没有复核入口，用户会误以为系统已经完成了判断。AI 产品应该避免把草稿包装成结论。

第二个坑，是只做生成，不做控制。

用户需要停止、重试、编辑、局部接受、恢复和撤销。没有控制感的 AI 会显得很聪明，但不可用。

第三个坑，是把 prompt 暴露给用户。

让用户在空白输入框里写完整指令，看似灵活，实际会把产品设计责任推给用户。好的 AI 产品会提供任务入口、上下文选择和约束控件。

第四个坑，是等待状态太贫乏。

长时间转圈会让用户怀疑系统坏了。AI 产品应该展示进度、阶段、工具调用和可取消动作。

第五个坑，是没有把 UI 状态和后端 run 状态对齐。

前端显示“已停止”，后端还在执行工具；用户确认的是一个参数，执行时却用了另一个参数；这些都是产品工程事故。

小结

AI 产品需要重新设计 UX，是因为 AI 改变了软件的基本交互假设。

它不是确定性按钮，而是概率性协作；不是一次性结果，而是可审阅草稿；不是纯前端效果，而是贯穿上下文、生成、证据、控制、确认和提交的产品工程系统。

好的 AI UX 会让用户看见过程、理解依据、保持控制，并在关键时刻接管。它不要求用户盲目信任 AI，而是让用户有能力判断什么时候可以使用 AI。