AI 交互设计

flowchart LR
  A["AI 交互设计"]
  A --> B["分类：产品与设计"]
  A --> C["关键词：AI Product"]
  A --> D["关键词：交互设计"]
  A --> E["关键词：UX"]
  A --> F["关键词：信任设计"]

AI 的交互和传统软件不一样：输出不确定、延迟可变、可能出错。设计 AI 界面，本质上不是把一个模型接到前端，而是在设计“人如何与一个高能力但不完全可靠的系统协作”。

延伸阅读：

Vercel AI SDK —— AI 交互组件与实现思路

Apple Human Interface Guidelines: Machine Learning —— Apple 的机器学习设计指南

这篇文章会讲什么

ChatGPT 火了之后，很多人以为 AI 交互就是“一个输入框 + 一段流式输出”。这当然是一种形态，但远远不是全部。

真正的 AI UX 难点不在于把回答展示出来，而在于处理一系列传统软件里没那么突出的设计问题：

输出不是确定的，同一个问题可能每次都不一样
响应时间不稳定，几百毫秒到几十秒都可能发生
系统可能“看起来很自信，但其实答错了”
用户不知道该怎么提问，也不知道什么时候该信、什么时候该改
失败不只是“报错”，还包括答偏、答空、答得太泛、答得不可执行

所以 AI 交互设计，本质上是在为一种新的系统特性设计界面语言：概率性、可协作、可纠偏、可追责。

这篇文章会接着上一篇《AI 产品设计方法》往下讲，回答更具体的问题：

AI 产品到底有哪些典型交互形态
什么情况下该用 Chat，什么情况下不该执着于 Chat
如何设计等待、反馈、重试、来源、边界提示
怎样让用户既感受到 AI 带来的帮助，又不被它的不确定性反噬
在工程现实里，AI UX 为什么常常是产品质量的放大器

AI UX 的根本差异

先看定义：传统 UI 主要在组织“确定的功能”，AI UI 则要组织“概率性的能力”。

很多传统软件的交互问题，核心是“用户能不能顺利找到并完成一个明确动作”：点击、筛选、填写、提交、查看结果。而 AI 产品里，用户面对的是一个能力系统，不只是一个动作系统。

这带来几个根本差异。

传统 UI vs AI UI

维度	传统 UI	AI UI
输出	确定、可预测	概率性、可能波动
延迟	通常固定、可预期	可变，且受任务复杂度影响大
错误	多为 bug 或规则问题	包括模型误判、幻觉、上下文缺失、检索噪声
交互方式	点击、选择、表单、导航	自然语言、候选建议、多轮协作、局部编辑
用户角色	操作系统	与系统共同完成任务
设计目标	减少操作摩擦	降低理解成本、建立信任、提供控制权

这意味着什么

AI 不能被当成“黑盒 API 输出区”来设计。用户不只是在等一个答案，而是在持续判断三件事：

系统现在在做什么
我应该相信它到什么程度
如果它错了，我能怎么修

所以 AI 界面的设计重点，不是“看起来像不像聊天机器人”，而是是否回答了上面这三个问题。

一个常见误区

很多产品团队会把 AI UX 理解成“把模型能力可视化”。但更准确地说，AI UX 是在把模型能力产品化。

所谓产品化，意味着你不能只展示能力本身，还要处理：

什么时候触发最自然
输出如何组织才可理解
用户如何编辑、拒绝、重做
什么地方需要证据，什么地方适合建议
什么时候应该自动，什么时候必须确认
什么情况下要承认不知道，而不是硬答

如果这些没设计好，再强的模型也会在用户体验层面显得“不靠谱”。

先别急着做 Chat：交互形态比“会不会对话”更重要

先看定义：Chat 是一种强大的通用容器，但不是所有 AI 场景的最佳界面。

过去一段时间，很多产品的默认动作是：加一个 AI 助手侧边栏，或者放一个聊天窗口。这样做有它的合理性：实现快、认知门槛低、用户一看就懂“这里可以问问题”。

但问题在于，对话是低门槛入口，不等于高效率完成方式。

如果用户的真实任务是“改这段文案”“补全这段代码”“把这 20 行表格转成某种格式”“针对当前页面做一个动作”，那聊天未必是最优交互。因为聊天要求用户额外做很多事：

先想清楚自己的意图
把上下文重新描述一遍
把希望的结果格式说清楚
再从回复里手动挑出可用部分

这其实把系统应该承担的上下文理解责任，转嫁给了用户。

更实用的判断问题

设计 AI 交互前，不妨先问：

用户是在“探索问题”，还是在“完成任务”？

如果用户还没想清楚问题、需要试探、比较、追问，Chat 很合适
如果用户已经在某个具体上下文中完成任务，inline、菜单式动作、局部建议通常更高效
如果用户是熟练用户，要高频触发标准动作，command palette 或快捷操作可能更自然

从工程上看，交互形态应该服从任务结构，而不是服从流行趋势。

三种主流 AI 交互模式

先看定义：Chat、Inline 建议、Command Palette 是最常见的三类 AI 交互形态，它们不是谁替代谁，而是服务不同任务。

三种模式对比

模式	形态	适用场景	代表产品
Chat	多轮对话，一问一答	探索性任务、复杂问题、开放式推理	ChatGPT, Claude
Inline 建议	在编辑器/上下文中直接补全或建议	写作、编码、表格处理、局部改写	GitHub Copilot, Notion AI
Command Palette	快捷键唤起，输入意图并执行动作	熟练用户、高频操作、工作流提速	Cursor, Raycast AI

1. Chat：适合探索，不天然适合执行

Chat 最大的优点是宽容。用户即使表达不精确，也可以通过来回几轮逐渐逼近目标。这让它很适合：

问题还不明确的探索性任务
需要解释、追问、比较的复杂任务
用户不熟悉领域，需要借助系统理清思路
面向通用人群的低门槛入口

但 Chat 也有非常明显的成本：

上下文容易漂移
信息埋在长对话里，后续难回看
执行动作通常还要再手动复制、粘贴、确认
对于局部修改任务，来回对话往往比直接编辑更慢

所以 Chat 更像一个问题空间探索器，不一定是最高效的任务执行器。

2. Inline：最适合把 AI 放进真实工作流

Inline 的优势在于，它不要求用户先“离开当前任务，再去调用 AI”。系统直接在当前上下文中给建议、补全、改写、摘要或下一步候选，用户可以快速接受、忽略或修改。

这类设计很适合：

写作中的续写、改写、提炼
代码中的补全、重构、注释生成
表格和结构化内容中的批量格式转换
当前选区、当前段落、当前对象的局部操作

Inline 模式真正做对的地方，是把 AI 从“另一个界面里的顾问”变成了“任务现场的助手”。

但它也有边界：

不适合需要长推理链和多轮澄清的问题
如果建议太频繁，会形成干扰而不是帮助
如果上下文理解不准，会让用户感觉系统在“乱插话”

所以 Inline 的关键不是“能否补全”，而是是否真的知道何时出现、给什么建议、如何不打扰。

3. Command Palette：给高频、高意图用户的效率层

Command Palette 本质上是把 AI 变成一个高层级操作入口。它适合那些已经知道自己想做什么，只是想更快完成的人。

例如：

“总结当前页面”
“把这段改成更正式的语气”
“生成这段代码的测试”
“根据当前选区生成 PR 描述”

这类模式的价值不在“陪你聊”，而在“少点几下、少切几层菜单、少写一堆重复说明”。

它很适合专业工具、开发者工具、重度效率产品，但对新手不总是友好，因为它默认用户有比较清晰的任务意识。

交互形态的选择，不只是 UI 问题，而是任务建模问题

先看定义：你不是在选一个界面，而是在决定“谁来承担理解上下文和组织任务的成本”。

很多产品最后会组合使用多种形态，这通常是对的。因为同一个产品里，用户可能同时存在三种需求：

我不知道怎么开始，需要先问一问
我已经知道要做什么，需要一个快捷动作
我正在具体编辑，希望 AI 在现场帮我

例如一个写作工具里，完全可以同时存在：

Chat：讨论结构和思路
Inline：针对当前段落改写
Command Palette：快速调用“总结”“扩写”“提取要点”等命令

一个简单的选择框架

可以从三个问题来判断：

1. 任务是开放探索，还是明确执行？

开放探索更适合 Chat；明确执行更适合 Inline 或 Command Palette。

2. 上下文是否天然存在于当前界面？

如果答案是是，那就尽量不要要求用户再用自然语言重复描述一遍。系统应该直接利用当前上下文。

3. 用户是新手，还是高频熟练用户？

新手更需要可见、可引导的入口；熟练用户更在意少一步、快一步、不断流。

很多不必要的 AI 交互摩擦，都来自于这个判断没做清楚。

信任设计：不是让用户“相信 AI”，而是让用户知道什么时候该信、为什么能信

先看定义：AI 产品里的信任，不来自一句“我们的模型很强”，而来自系统是否把依据、边界和不确定性表达清楚。

AI 交互里，最危险的不是出错，而是让用户在不该信的时候信了它。

所以信任设计不是“提升好感度”的包装层，而是产品机制的一部分。用户需要通过界面快速判断：

这是事实、推测，还是建议
这段输出有没有来源支撑
这次回答基于哪些上下文
系统对这个结论到底有多大把握
如果这次不靠谱，我怎么验证或修正

常见的信任设计手段

手段	作用	示例
引用 / 来源	让输出可追溯、可验证	检索问答中的引用链接、原文片段
不确定性表达	降低伪确定感	“根据现有信息”“可能”“我不确定”
边界承认	避免过度自信	“我没有足够依据回答这个问题”
生成标识	区分 AI 输出与人工内容	“AI 生成草稿”“建议版本”
过程可见性	帮助用户理解系统依据	展示使用了哪些文件、选中了哪些上下文

但不要过度迷信“confidence”

很多产品喜欢讨论是否应该展示 confidence score。这个想法听起来合理，但在实际设计里要非常谨慎。

原因是：

模型分数并不总能准确映射“这次回答是否可信”
用户容易把数字理解成精确承诺
一个“82% 可信”的展示，未必真的比“基于 3 个来源总结”更有帮助

所以大多数时候，比起给一个抽象分数，更有价值的是：

给出处
给证据片段
给限制条件
给“我不知道”的能力

重点不在于“有没有置信度 UI”，而在于用户能否做出合理判断。

诚实比自信更稀缺

一个成熟 AI 产品必须学会在合适的时候说：

我不知道
信息不足
这个结论依赖某个前提
这里有多个可能解释
我建议你查看原文或进一步确认

这听起来像是在“降低体验”，其实恰恰是在保护体验。因为 AI 最伤信任的时刻，不是它拒绝，而是它一本正经地胡说八道。

信任不只是“答案展示”，还包括动作边界

如果 AI 不只是回答问题，还会触发动作，比如发邮件、改文档、调接口、执行命令，那么信任设计就更重要。

这时用户不只是在判断“它说得对不对”，还在判断“我敢不敢让它做”。所以对于执行型 AI，通常要有更明确的机制：

操作前预览
关键参数可见
高风险动作二次确认
可撤销
操作记录可追踪

在这种场景里，“确认框”不是保守，而是把控制权还给用户。

加载与等待状态：等待不是空白时间，而是交互的一部分

先看定义：AI 的等待体验不是“加个 loading”就够了，而是要根据任务时长和任务性质设计不同反馈机制。

传统软件里的等待，很多时候只是网络或计算延迟； AI 产品里的等待，则常常与“系统正在生成、检索、推理、调用工具、整理结果”相关。用户会天然产生更多心理活动：

它是在正常处理，还是卡住了？
为什么这次比上次慢？
是不是我问题提得不对？
我现在应该等，还是取消？
它最后会给我什么样的结果？

所以等待设计不能只是美化时间，而是帮助用户理解当前状态，降低不确定性带来的焦虑。

一个更实用的时间分层

响应时间	设计重点	推荐策略
< 2 秒	不要过度打断节奏	轻量 loading，尽快出结果
2–10 秒	用户会开始关注等待	Streaming、阶段性反馈、可取消
> 10 秒	等待本身已成体验问题	分步进度、后台处理、通知、保留上下文

1. Streaming：降低“空白等待”，但不要把它神化

Streaming 的最大价值，不只是“看起来更快”，而是让用户更早进入判断状态：

这是不是我想要的方向
我要不要打断它
是否已经有部分内容可用
这次输出的质量大概如何

但 Streaming 也不是越多越好。

在某些场景里，逐 token 输出会制造问题：

内容前半段还没稳定，后半段又接着来，阅读负担重
结构化结果在未成型前很难看
用户容易把中间态误当最终态
对屏幕阅读器和无障碍支持更复杂

因此，Streaming 更适合长文本生成、开放式回答、逐步成型的内容；而结构化输出、复杂表格、分步骤工作流，有时更适合“先给骨架，再填内容”或“分阶段完成”。

2. 进度提示：不要假装精确，要帮助用户建立预期

如果一个任务会比较久，系统应该告诉用户它在做什么，而不只是放一个转圈图标。

好的进度提示不一定非要给百分比。很多 AI 任务其实很难估算线性进度。相比之下，更诚实也更实用的方式包括：

正在检索相关资料
正在生成初稿
正在整理为表格格式
正在检查引用和来源
正在调用外部工具

这种阶段式反馈比伪精确的“63%”更可信。

3. Skeleton：适合结构已知、内容待填的界面

如果用户期待的是一个报告、卡片列表、表格、表单草稿、分析结构，那么 skeleton 往往比单纯 loading 更好。因为它提前告诉用户：结果大概会长什么样。

这件事在 AI 产品里很重要。因为用户等待的不只是“有内容”，更是在猜“最后会不会是我能用的形式”。

4. 长任务要能取消、后台化、回来接着看

当任务超过十秒甚至更久时，体验重点已经不只是“如何展示等待”，而是“如何不绑架用户”。

成熟产品应该考虑：

可取消
可离开当前页面
完成后通知
中间结果或最终结果可回看
失败后不必从头再来

很多 AI 体验之所以显得笨重，不是因为模型慢，而是因为整个等待过程把用户锁死在原地。

一个明确的反模式

避免“假 typing 动画”。

如果系统其实是在等模型返回，却用“像真人一样正在打字”的方式展示，很容易误导用户，也会让等待显得更长、更不透明。更好的做法是明确告诉用户：AI 正在生成、正在检索、正在分析。

诚实的系统，通常比拟人的系统更可信。

错误处理：AI 的“错”不只有一种，界面也不能只有一句“出错了”

先看定义：AI 产品里的错误处理，关键不是提示本身，而是帮用户判断“出了什么问题、值不值得重试、有没有别的路可走”。

传统产品里的错误提示，很多时候面向的是明确失败：接口挂了、权限不够、参数错误、网络断了。而 AI 产品里的“错误”更复杂，至少包括四类：

系统级错误：超时、调用失败、服务异常
能力级错误：模型理解错、生成错、幻觉、格式不对
数据级错误：上下文缺失、检索不到、材料冲突
任务级错误：用户目标太模糊、约束不足、问题本身超出能力边界

如果这些错误都被折叠成一句“出错了，请重试”，用户就不知道下一步该怎么办。

更有用的错误处理模式

模式	含义	示例
重试机制	允许快速再来一次	“重新生成”“再次尝试”
局部重做	不必整段重来	仅重写某段、重跑某一步
优雅降级	AI 失败时仍给可用结果	推荐失败 → 展示热门项；总结失败 → 展示原文
部分成功保留	已有成果不要丢	表格生成失败一列，保留已完成部分
人工介入	高价值问题可切换到人工	客服机器人转人工、审批前人工复核
明确边界提示	告诉用户问题超出能力	“当前资料不足，无法可靠回答”

文案原则：具体、诚实、可行动

差的错误文案：

出错了
请求失败
Something went wrong

好的错误文案应该至少回答一件事：用户现在能做什么。

例如：

生成超时了，请点击重试
当前资料不足，建议补充文件或缩小问题范围
这类问题需要引用来源，暂时无法在无资料情况下可靠回答
我没能完成最后一步，但前面的分析结果已保留

重点不在“写得礼貌”，而在“帮助用户恢复任务”。

一个常被忽视的设计点：失败后保留什么

很多 AI 产品一失败，就把用户刚才的输入和中间结果都清空。这会非常伤体验。更合理的做法通常是保留：

用户原始输入
已上传或已选择的上下文
之前成功完成的中间结果
用户对输出做过的编辑
当前任务的参数设置

因为用户真正反感的，不只是失败，而是失败后还要从头劳动一遍。

反馈机制：不是为了“收个赞踩”，而是让用户参与系统校正

先看定义：好的反馈设计既服务用户当下的纠偏，也服务系统长期优化，但前提是不要为了收集信号而制造额外负担。

AI 产品天然适合建立反馈闭环，因为输出不是固定的，系统需要不断知道：

用户是否采纳
用户改了什么
哪些建议经常被拒绝
哪些错误最常见
哪些场景质量明显下降

常见反馈类型

类型	作用	实现
显式反馈	快速判断结果主观满意度	点赞 / 点踩
修正反馈	获取高价值纠偏信号	用户直接编辑 AI 输出
Regenerate	给用户“再试一次”的低摩擦入口	重新生成、换一种写法
解释反馈	帮助定位问题类型	“不准确 / 太长 / 太泛 / 风格不对”
行为反馈	通过采纳或跳过推断有效性	是否接受补全、是否复制、是否撤销

但要注意：不是所有反馈都值得显式索取

很多产品会在每次回答下面都放一排反馈按钮，结果用户基本不点。这是正常的，因为大多数用户的主要目标是完成任务，不是帮系统打标。

更高价值的反馈，往往来自自然行为：

接受了哪条建议
改了多少
哪一段被保留
是否直接删除整段输出
是否在看到结果后立即重新提问

这些隐式反馈通常比“thumbs down”更贴近真实使用。

反馈设计的关键，不只是“收”，更是“闭环”

设计反馈机制时，至少要想清楚三件事：

这类反馈会进入哪里？ 是用来做质量监控、改 prompt、调检索，还是训练排序器？
用户为什么愿意给？ 是否有足够低的摩擦，或者能换来立即改善？
反馈是否影响当下体验？ 比如用户说“太长”，那系统能不能下一轮就更短，而不只是默默记下来？

如果反馈只被收集，却从不反映在产品改善上，用户很快会觉得那只是装饰。

新手引导与预期管理：空输入框不是自由，往往是茫然

先看定义：大多数用户不是不会使用 AI，而是不知道这个产品在当前场景里“最值得拿来干什么”。

空白输入框看起来简洁、开放、强大，但对很多用户来说，它代表的是：

我该问什么？
它到底擅长什么？
我要描述到多细？
我能让它直接帮我做什么？
它会不会胡说？

所以 AI 产品尤其需要 onboarding，不是为了教用户写提示词技巧，而是为了建立任务心智。

新手引导真正要做的几件事

1. 教会用户“在这个产品里，可以怎样使用 AI”

不是泛泛地教“如何写 prompt”，而是具体到产品任务：

你可以让它总结当前文档
你可以选中一段内容让它改写
你可以上传资料后再提问
你可以要求它按某种结构输出
你可以在结果不满意时继续追问或局部修改

用户需要的是“可操作起点”，不是抽象方法论。

2. 设定正确预期，而不是制造全能幻觉

要明确告诉用户：

AI 可能会犯错
某些回答依赖你提供的上下文
它更适合做哪些类型的任务
哪些高风险结果需要你确认
有时它会拒绝或要求补充信息

这不是在降低转化，而是在降低失望。

3. 设计首轮成功体验

好的首轮体验不一定是“最惊艳”，而是“最快感知到价值”。所以第一次使用时，应尽量避免让用户自己从零构造问题，而是提供：

示例 prompt
一键示例任务
基于当前上下文的推荐动作
模板化入口

比如“帮我总结这篇文章”“把这段改得更简洁”“根据这个 PR 生成摘要”，都比一个完全空白的输入框更容易触发真实价值。

预期管理不是 onboarding 一次就结束

AI 产品里的预期管理是持续性的。它还会体现在：

回答前的提示
生成中的状态说明
输出中的来源和边界
错误时的解释
执行动作前的确认

所以它不是一个首屏问题，而是一整条交互链路的问题。

无障碍与包容性：AI UI 往往动态、文本密、状态多，更容易把这件事做差

先看定义：AI 产品的无障碍不是附加项，因为它的核心交互本来就高度依赖文本、动态更新和状态变化。

很多 AI 产品的界面天然包含这些挑战：

大量流式更新内容
长文本和多轮历史
依赖颜色表达状态差异
动态插入建议卡片或工具结果
键盘焦点在输入框、结果区、操作栏之间频繁切换

这些都让无障碍设计更容易被破坏。

至少要关注这些问题

1. 键盘可及性

所有关键操作都应该能通过键盘完成，包括：

发送
停止生成
重新生成
采纳建议
拒绝建议
展开引用
在消息与操作按钮之间跳转

2. 屏幕阅读器对动态内容的处理

流式输出如果逐字朗读，体验会很差；完全不播报，又会丢失状态。更合理的做法通常是按句、按块或在阶段完成后播报。

3. 重要状态不能只靠颜色

比如“高风险建议”“已验证来源”“生成失败”，都不应只靠红绿颜色表达，还要有文字、图标或结构提示。

4. 等待和生成状态需要可感知

例如使用 aria live 区域或明确的文字说明，让用户知道系统正在生成、已暂停、已完成或失败。

5. 长对话要便于导航

对话式产品很容易堆成长页面，用户回看历史会很困难。应该考虑消息分组、跳转、折叠、锚点、摘要化历史等辅助能力。

无障碍在 AI 产品里不是锦上添花，因为这类系统本来就在处理“解释、状态、控制权”这些对所有用户都重要的事情。无障碍做得好，往往也会带来整体 UX 的提升。

反模式：AI 交互最容易踩的坑

1. 隐藏 AI 局限，假装它是稳定正确的

这是最危险的做法。一旦用户在关键场景里发现它会编、会漏、会乱猜，信任会迅速崩塌。比起制造“无所不能”的幻觉，更重要的是让系统边界清晰。

2. 用 Chat 包装一切

不是所有问题都适合聊天。如果本质是局部操作、批量动作、结构化填写，强行用对话承载，只会让用户多做描述工作。

3. 过度拟人化

例如过多使用“我在想一想”“让我帮你认真研究一下”，或者模拟真人打字节奏。适度拟人化可以让产品更亲切，但过度拟人化会掩盖系统真实边界，让用户误判能力和责任。

4. 没有重试与撤销

AI 的本质决定了“再试一次”是正常需求，不是异常路径。如果没有 regenerate、回退、撤销、局部重做，用户会很快失去耐心。

5. 只给结论，不给依据

特别是在知识密集或风险较高的场景中，这几乎等于让用户盲信系统。来源、证据、上下文依据不一定要每次都大篇幅展示，但必须在需要时可见。

6. 把所有失败都归咎于用户输入不好

“试试换个问法”有时是合理建议，但不能成为默认甩锅模板。如果系统经常需要用户靠提示工程自救，说明产品还没有把应有的复杂性吸收掉。

7. 把“会说”误当“会做”

一个系统能输出很像样的步骤说明，不代表它真的能帮用户完成任务。如果结果不能方便地采纳、编辑、执行、落地，它的价值就会停留在语言层，而不是任务层。

一个更接近实战的 AI 交互检查清单

在设计或评审一个 AI 界面时，可以用下面这些问题快速自查：

任务与形态

这个场景真的适合 Chat 吗？
用户是在探索问题，还是执行明确动作？
当前界面里是否已经有足够上下文，没必要再让用户复述？

信任与边界

用户凭什么相信这次输出？
系统有没有在必要时承认不知道或资料不足？
高风险内容有没有来源、提示或确认机制？

控制与纠偏

用户能否轻松重试、局部修改、撤销、拒绝？
AI 失败时，有没有可走的降级路径？
部分成功的结果是否被保留？

等待与状态

如果要等 5 秒、15 秒、30 秒，界面分别怎么表现？
用户能否知道系统正在做什么？
长任务能否取消、后台处理、回来继续看？

新手与老手

新手是否知道从哪里开始？
熟练用户是否有更快的路径？
是否同时兼顾了引导性和效率性？

如果这些问题答不清，这个 AI 交互大概率还停留在“把模型结果显示出来”的阶段，离真正成熟的 UX 还有距离。

小结

AI 交互设计的核心，不是把界面做得“像聊天”，而是把一个不确定、可变、会犯错的能力系统，组织成一个可理解、可控制、可纠偏的用户体验。

真正重要的，不外乎几件事：

根据任务选对交互形态，而不是默认上 Chat
让用户理解系统的依据、边界和不确定性
把等待设计成有信息的状态，而不是空白时间
把错误处理成可恢复的路径，而不是一句泛化报错
给用户足够的控制权：重试、修改、撤销、确认、回退
用 onboarding 和持续预期管理减少“会用门槛”
在无障碍和长尾使用场景上保持克制和完整性

一句更凝练的话是：

好的 AI UX，不是让用户觉得“它像个人”，而是让用户觉得“我始终知道它在做什么、哪里值得信、哪里需要我接手”。

这也是 AI 交互真正区别于传统界面的地方：你设计的不只是路径和控件，更是用户与一个概率性系统之间的协作关系。