p302. 超越对话框：七种 AI 交互设计模式

对话界面是 AI 产品的默认选择，但每种场景都有更优的专属模式。本章系统梳理当前业界已验证的七种核心模式，并提供选型逻辑。

3.2.1 七种核心交互模式

模式一：行内补全（Inline Completion）

AI 在用户正在编辑的位置直接给出建议，用户通过极低成本的操作（Tab 键）接受或忽略。

典型产品：GitHub Copilot（代码补全）、Gmail Smart Compose（邮件补全）、Notion AI（文档续写）

设计关键点：

• 建议必须在视觉上与用户已输入的内容有明确区分（灰色预览文字 vs 黑色正文）
• 接受操作必须是零思考成本的（一键接受，不需要做任何判断）
• 拒绝操作必须是零成本的（继续打字就自动消失，不需要显式关闭）
• 延迟要求极高：建议必须在用户停顿后 100–300ms 内出现，否则会打断打字节奏

数据飞轮闭环：用户每次 Tab 接受 = 正样本；继续打字忽略 = 隐式负样本。Copilot 通过这个机制每天采集数百万条隐式偏好数据，无需用户做任何额外操作（详见 p306 §3.6.2）。

设计洞察：行内补全的”幽灵文字”（Ghost Text）设计把”AI 建议”和”用户正在写的东西”放在同一个视觉层级，而不是弹出一个对话框。这消除了上下文切换的认知代价——这是它被大量复制的根本原因。

---

模式二：选区操作（Selection-Based Action）

用户选中一段内容（文字、代码、数据），触发上下文菜单，对选中内容执行 AI 操作（翻译、改写、解释、修复、提炼）。

典型产品：Notion AI（选中文字→弹出 AI 操作栏）、Cursor（选中代码→Cmd+K 编辑指令）、Google Docs AI

设计关键点：

• AI 操作的结果应直接替换或标注在原位，而非跳转到新窗口
• 必须支持一键撤销（Undo），因为原地替换的错误成本远高于对话框中的错误
• 提供预设操作（翻译、简化、扩展）降低用户构思 prompt 的负担
• 选区范围隐式限定了 AI 的操作边界，大幅降低了”AI 会动哪些内容”的不确定性

设计洞察：选区操作是”表达焦虑”（见 p301 §3.1.1）的一个优雅解法——用户不需要用语言描述”对第三段第二句做 X 操作”，直接选中然后选择操作即可。选区本身携带了意图的空间定位信息。

---

模式三：侧边栏助手（Sidebar Assistant）

在用户的主工作区旁边提供一个 AI 对话面板，AI 可以感知主工作区的内容并提供上下文相关的帮助。

典型产品：GitHub Copilot Chat（IDE 侧边栏）、Microsoft 365 Copilot（Office 侧边栏）、Cursor Chat

设计关键点：

• 侧边栏不应抢占主工作区的视觉焦点——用户的核心任务在主区域
• AI 的建议需要有”应用到主区域”的一键操作（Apply / Insert / Replace），而非让用户手动复制
• 侧边栏的对话上下文应自动包含主工作区的当前内容（当前文件、选中代码、光标位置），减少用户重复提供上下文的负担

与RAG的关系：侧边栏助手的”感知主工作区内容”本质上是一种实时的上下文注入——将用户当前的文件、选中内容等作为动态 context 注入 Prompt 中（m201 System Prompt 设计），类似 RAG 但来源是用户当前工作状态而非外部知识库。

---

模式四：Generative UI（动态生成界面）

AI 不仅生成文本，还生成交互组件——表格、图表、表单、日历卡片、地图——用户可以直接在生成的组件上操作，而非仅仅阅读文字。

典型产品：ChatGPT（天气查询返回可视化卡片）、Perplexity（搜索结果返回结构化摘要 + 来源卡片）、Claude Artifacts（生成可运行的代码/可编辑的文档）

技术基础：LLM 通过 Function Calling（c10 §10.2）调用工具并返回结构化数据，前端根据返回的数据类型动态渲染对应的 UI 组件。Vercel AI SDK 的 Generative UI 功能允许 LLM 直接流式输出 React 组件。

设计关键点：

• 组件的设计语言必须与宿主应用一致（不能像外嵌的 iframe）
• 交互组件必须有明确的加载状态（Skeleton Screen）和错误状态（Fallback UI）
• 用户在生成的组件上的操作（点击、修改、选择）应被捕获为反馈信号

设计洞察：Thesys 的 Generative UI 研究报告指出，纯文本 AI 输出导致严重的”信息过载”——用户描述”被细节淹没、只能扫读、找不到重点”。当相同信息以结构化的 UI 组件呈现时，用户的信息获取效率和满意度显著提升。Generative UI 不是花哨的功能，而是对 AI 产品信息架构的根本性改进。

---

模式五：画布/白板模式（Canvas）

用户和 AI 共同在一个二维空间中协作——AI 生成的内容不是线性的对话流，而是可以自由拖拽、连接、分组的节点。

典型产品：ChatGPT Canvas（文档和代码的并排编辑）、Miro AI（思维导图中的 AI 辅助）、tldraw

设计关键点：

• 适合需要非线性探索的任务（头脑风暴、架构设计、内容规划）
• 用户可以同时看到多个 AI 输出的变体并直接比较
• AI 的修改需要在视觉上留下痕迹（diff 视图），用户可以逐条接受或拒绝

---

模式六：后台 Agent / 异步任务（Background Agent）

AI 在后台自主执行复杂任务，用户提交任务后可以离开，完成后收到通知。

典型产品：Devin（后台编程 Agent）、OpenAI Deep Research、Claude Deep Research

设计关键点：

• 需要提供 Dashboard 式的进度界面（当前步骤、已完成步骤、预计剩余时间）
• 用户必须能在任何时刻介入——暂停、修正方向、取消
• 最终输出应提供可审计的执行日志（Agent 做了什么、看了什么、为什么做这个决策）
• 关键决策点应主动推送通知让用户确认，而非事后才告知

与 c11 System 2 的关系：Test-Time Compute 场景（o1/R1 长时间推理）必然要求异步 UI——用户不能同步等待 30–180 秒的推理时间，产品需要从”实时对话”范式切换到”任务提交 + Dashboard 监控”范式。这是 System 2 模型对产品设计的最直接影响。

---

模式七：嵌入式 AI / Invisible AI（隐形 AI）

AI 能力完全嵌入现有产品流程中，用户甚至感知不到”在使用 AI”——拼写检查、智能排序、自动分类、推荐排列。

典型产品：Notion 的自动属性填充、Figma 的 AI 布局建议、Linear 的智能任务分配

设计关键点：

• 用户不需要主动触发 AI——AI 在后台持续工作
• 结果以微妙的方式呈现（排序变化、标签建议、高亮提示），不打断用户的主工作流
• 用户随时可以覆盖 AI 的判断（手动修改排序、删除标签），且覆盖操作应被记录为反馈信号
• 这是”AI 渗透率最高但 AI 存在感最低”的形态——也是最难设计的形态

设计洞察：Invisible AI 的设计挑战在于”恰好够用的透明度”——AI 改变了某个东西，用户需要知道是 AI 改的（否则会困惑），但又不能让 AI 的存在感太强（否则会分散注意力）。Notion AI 在属性填充时用浅紫色边框标注”AI 建议”是一个好的平衡点。

---

3.2.2 交互模式的选型逻辑

场景特征	推荐模式	理由
用户在做创作/编辑，需要实时辅助	行内补全 + 选区操作	零打断、零上下文切换
用户需要 AI 帮助理解/分析当前内容	侧边栏助手	AI 感知主工作区上下文
用户需要查询信息或完成结构化任务	Generative UI	输出即操作，无需手动转化
用户需要非线性探索或多方案比较	画布模式	二维空间支持并行比较
任务复杂且耗时，用户可以等待	后台 Agent	异步执行，进度可见
AI 能力嵌入日常工作流，无需用户触发	Invisible AI	最高渗透率、最低摩擦
以上都不匹配，或用户需要开放式对话	对话界面	灵活性最高，万能兜底

核心原则：对话界面应该是兜底选项，而非默认选项。

相关概念卡：Agent 与工具调用、Function Calling、RAG、System 2 TTC 模块一关联：c10 Function Calling 机制、c11 System 2 异步 UI 模块二关联：m201 Prompt 设计、m207 Agent 失败模式 上一章：p301 交互范式跃迁 下一章：p303 克服空白画布综合症