AI 交互范式与 Copilot 模式设计

AI 产品设计的核心挑战不是"怎么接入模型"，而是"怎么让用户和 AI 协作得自然"。选错交互范式，再强的模型也会让用户觉得别扭。这一讲帮你系统梳理 AI 产品的四种交互范式，并深度拆解当前最主流的 Copilot 模式。

1. 四种 AI 交互范式

AI 产品的交互方式并非只有"聊天框"一种。根据用户的控制程度和 AI 介入时机，可以划分出四种核心范式：

1.1 命令式（Command）

用户主动发出精确指令，AI 执行并返回结果。

特征：一问一答，用户掌握完全控制权
适用场景：搜索引擎增强、代码补全的单行模式、图片生成（输入 Prompt → 输出图片）
代表产品：早期 ChatGPT、Midjourney /imagine 命令
优点：用户预期明确，结果可预测
缺点：要求用户会"提问"，学习成本高；不适合复杂、多步骤任务

用户：把这段文字翻译成英文："人工智能改变世界"
AI：Artificial intelligence is changing the world.

1.2 对话式（Conversational）

多轮对话，AI 保持上下文记忆，像"助手"一样渐进式帮助用户完成任务。

特征：多轮交互，上下文连贯，支持澄清和追问
适用场景：客服、顾问类产品、复杂任务分解
代表产品：Claude、ChatGPT（多轮模式）、Intercom Fin
优点：自然语言门槛低，适合复杂任务
缺点：对话历史管理复杂；用户容易迷失在长对话中

1.3 环境式（Ambient）

AI 在后台持续感知用户行为，主动在合适时机介入，用户无需显式触发。

特征：无感知、低打扰、主动推送
适用场景：智能推荐、异常检测、自动化工作流
代表产品：Google Workspace 的智能建议、Notion AI 的自动摘要、邮件客户端的智能分类
优点：降低用户认知负担，自动化程度高
缺点：用户失去控制感；准确率要求极高（错误介入比不介入更糟糕）

1.4 Copilot 模式

用户主导任务，AI 作为"副驾驶"在旁提供建议、补全、纠错，用户保留最终决策权。

特征：AI 建议 + 人类确认，双向协作
适用场景：写作、编程、设计等创作类工作
代表产品：GitHub Copilot、Microsoft 365 Copilot、Cursor、Notion AI
优点：兼顾效率与控制感；错误成本低（用户可随时拒绝建议）
缺点：设计难度高；建议质量直接影响用户体验

范式	用户控制度	AI 主动性	典型场景
命令式	最高	最低	一次性任务、精确指令
对话式	高	中	复杂任务、顾问场景
Copilot	中高	中高	创作、编程、写作
环境式	最低	最高	自动化、后台感知

2. Copilot 模式深度拆解

Copilot 模式是当前 AI 产品最热门的设计方向，因为它完美平衡了"AI 能力"与"用户控制感"。

2.1 GitHub Copilot：代码世界的范式定义者

GitHub Copilot 是 Copilot 模式的鼻祖，其设计哲学值得每个 AI PM 深入研究。

核心设计决策：

内联建议（Inline Suggestion）：建议出现在光标位置，灰色幽灵文字，用户按 Tab 接受，继续输入则忽略——摩擦力接近零。
触发时机：停止输入约 300ms 后触发，不打断用户思路。
上下文窗口：综合当前文件、已打开的相关文件、注释和函数签名作为上下文。
多候选展示：按 Alt+] 可以浏览多个备选建议，给用户选择权。

关键产品洞察：Copilot 让 AI 成为"键盘快捷键"而非"对话框"，把 AI 嵌入用户已有的工作流，而不是要求用户适应新工作流。

2.2 Microsoft 365 Copilot：企业级 Copilot 的复杂性

Microsoft Copilot 的挑战在于要在 Word、Excel、PowerPoint、Teams、Outlook 等完全不同的场景中提供统一的 Copilot 体验。

设计挑战与解法：

场景	挑战	解法
Word	用户不知道从哪里开始	文档空白时显示"用 Copilot 起草"入口
Excel	数据分析结果难以验证	同时显示 SQL/公式，用户可审查逻辑
PowerPoint	生成的 PPT 风格不符	提供迭代修改对话框，逐步调整
Teams	会议中实时总结干扰注意力	会议结束后生成摘要，不实时打断

2.3 Cursor：下一代 Copilot 的进化方向

Cursor 在 GitHub Copilot 基础上进化出多种模式：

Tab 补全：继承 Copilot 的内联建议
Cmd+K：选中代码块，用自然语言描述修改意图，AI 生成 diff
Composer/Agent 模式：AI 自主读取多个文件、执行命令、完成复杂任务，用户审批关键步骤

Cursor 的进化路径揭示了一个趋势：Copilot 模式正在向 Agent 模式演进，差异在于 AI 的自主决策权边界。

3. 为 AI 不确定性设计

AI 输出不是确定性的，这是设计 AI 产品最大的挑战。

3.1 置信度可视化

不要让用户以为 AI 的输出都是"正确答案"。

策略一：显式置信度标注

AI 建议的药物剂量：500mg（⚠️ 请医生确认，我对此类场景的把握度约为 70%）

策略二：多方案并列

提供 2-3 个差异化方案，而非单一"最优解"，让用户感知到存在不确定性。

策略三：来源引用

如果 AI 基于特定知识作答，显示来源让用户可以验证（Perplexity 的核心设计）。

3.2 渐进式披露（Progressive Disclosure）

不要一次性把所有 AI 能力堆给用户。

三层披露模型：

层级	内容	触发方式
第一层	最常用的 1-2 个 AI 功能	默认显示
第二层	进阶功能（自定义参数、模式切换）	点击"更多选项"
第三层	高级设置（Prompt 模板、API 参数）	专家模式或设置页面

案例：Notion AI 写作助手默认只显示"继续写作"和"改善写作"，点击"更多"才展示翻译、摘要、更改语气等选项。

3.3 错误恢复设计

AI 会犯错，产品必须让用户能优雅地"从 AI 错误中恢复"。

撤销机制：AI 的任何操作都应该可以一键撤销
编辑能力：AI 生成的内容用户可以直接编辑，不要做成"只读"输出
重试入口：明显的"重新生成"按钮，支持带修改意图重试（"更简洁地重新生成"）

4. Human-in-the-Loop 设计

Human-in-the-loop（HITL）：在 AI 决策流程的关键节点保留人类审批或干预的机制。

4.1 何时必须加入 HITL

场景类型	HITL 必要性	理由
高风险操作（删除数据、发送邮件）	必须	错误代价不可逆
输出影响他人（发布内容、客户沟通）	必须	品牌/法律风险
用户对 AI 能力不熟悉	建议	建立信任需要时间
低风险、高频、可逆操作	可选	过多确认会让用户疲劳
纯个人场景（私人笔记整理）	不必要	错误成本低，效率优先

4.2 HITL 的三种形态

形态一：批准门（Approval Gate）

AI 完成任务后暂停，等待用户明确批准才执行。

适用：高风险操作，如批量发邮件、删除文件
体验：GitHub Copilot Agent 提交 PR 前需要用户审批

形态二：建议模式（Suggestion Mode）

AI 给出建议，用户选择接受/忽略，不接受也不影响当前工作流。

适用：写作助手、代码补全
体验：Google Docs 的智能写作建议

形态三：事后审查（Post-hoc Review）

AI 自动执行，但保留完整日志，用户可事后查看和撤销。

适用：邮件分类、日历自动安排
体验：Gmail 的智能归档，可在"已归档"中查看并撤销

5. Chat vs. Embedded AI：选型决策框架

一个高频争论：应该做独立的 Chat 界面，还是把 AI 能力嵌入现有工作流？

决策矩阵

维度	Chat 界面更合适	Embedded AI 更合适
任务性质	开放式探索、信息查询	明确任务、现有工作流增强
用户场景	用户"不知道自己要什么"	用户有明确目标，AI 是加速器
上下文来源	用户在对话中提供	产品本身有丰富上下文（代码库、文档库）
产品阶段	早期验证、快速上线	深度整合、差异化竞争
用户学习成本	高（需学会提问）	低（在熟悉界面中使用）

结论：大多数成熟 AI 产品最终走向"Chat + Embedded"混合模式——Chat 用于复杂探索，Embedded AI 处理高频场景。

实际案例

Notion：Chat 对话框（Ask AI）+ Embedded AI（选中文字直接调用）
Linear：Embedded AI 写 Issue 描述 + Copilot 模式规划 Sprint
Figma：插件形式的 Embedded AI + 独立的 AI 生成界面

核心 Takeaways

先选范式，再设计交互：命令式、对话式、Copilot、环境式各有适用场景，混用时需明确主范式。
Copilot 的本质是"零摩擦建议"：建议出现要自然，接受要容易，拒绝要无感。
为不确定性设计：渐进式披露、置信度标注、来源引用，让用户知道 AI 不是万能的。
HITL 的核心问题是"代价"：错误代价越高，越要加人工干预节点。
Chat vs. Embedded 不是非此即彼：成熟产品都走向混合模式。

下一讲：RAG 产品设计实战 — 当你的 AI 需要"读懂"企业私有知识库时，怎么做产品决策？