#AI Copilot 的交互形态有哪些

AI Copilot 不是一个固定组件。

它不是“页面右下角放一个聊天机器人”，也不是“给每个输入框加一个生成按钮”。Copilot 的本质，是在用户当前工作流里提供上下文相关的智能协助。它可以表现为聊天框、侧边栏、内联操作、命令面板、自动补全、批量处理、审阅面板，也可以是一个可观察的工作流执行器。

选择哪种形态，取决于用户正在做什么、上下文在哪里、结果是否需要审阅、动作是否会修改真实数据，以及用户希望 AI 多主动。

如果交互形态选错了，再强的模型也会显得别扭。

#Copilot 的核心不是聊天，而是上下文协作

一个合格的 Copilot 至少要理解三件事：

• 用户当前所在的对象：文档、代码、表格、客户、工单、页面、任务。
• 用户当前想完成的动作：解释、改写、生成、检查、补全、执行、比较。
• 用户希望结果如何进入工作流：展示建议、修改草稿、生成 patch、提交动作或等待确认。

聊天只是其中一种表达方式。它适合用户意图不清、需要多轮澄清、需要探索和追问的场景。但当用户已经选中一段文本、正在编辑一行代码、正在处理一个表格字段时，聊天框反而可能增加操作成本。

Copilot 设计的关键，是让 AI 出现在任务发生的位置，而不是让用户离开任务去和 AI 对话。

#形态一：聊天式 Copilot

聊天式 Copilot 是最通用的形态。

它适合开放问题、模糊需求、探索式任务和多轮澄清。例如知识库问答、数据分析解释、产品咨询、编程问答、运营策略讨论。用户不一定知道自己要什么，AI 可以通过对话逐步收敛。

它的优势是灵活。自然语言输入成本低，多轮上下文容易理解，也容易承载解释、引用和追问。

但聊天式 Copilot 也有明显限制：

• 用户需要自己描述上下文。
• 输出常常停留在文本层，难以直接进入工作对象。
• 多轮对话容易变长，关键信息被淹没。
• 对明确任务来说，聊天可能比按钮慢。

产品工程上，聊天式 Copilot 需要把对话记录、引用来源、工具调用、上下文选择和结果版本分开建模。不要把所有东西都塞进 message content，否则后续很难做引用、重试、审计和局部采纳。

适合聊天的典型入口包括：

• “问这个文档”
• “帮我分析这份数据”
• “解释这段错误日志”
• “根据当前项目给我一个方案”
• “继续追问”

#形态二：侧边栏 Copilot

侧边栏 Copilot 适合用户需要一边看主内容、一边和 AI 协作的场景。

它常见于文档、CRM、客服、数据看板、代码平台和内部系统。主区域保留用户工作对象，侧边栏提供问答、建议、摘要、下一步行动和引用来源。

侧边栏的价值在于“不打断主任务”。用户可以查看原文、选中内容、拖入上下文，同时在旁边获得 AI 建议。

侧边栏通常应该具备：

• 当前对象摘要。
• 可见的上下文范围。
• 引用来源和证据片段。
• 快捷动作，例如总结、改写、提取、生成回复。
• 把结果插入主区域的按钮。
• 历史建议和版本对比。

侧边栏不适合承载所有功能。如果它变成一个杂物间，用户会迷失。好的侧边栏应该围绕当前对象组织，而不是围绕模型能力组织。

#形态三：内联 Copilot

内联 Copilot 是最贴近工作流的形态。

用户选中一段文本、一个代码块、一行表格或一个 UI 区域，AI 直接对这个局部对象执行操作。常见动作包括改写、解释、翻译、扩写、缩短、修复、生成测试、提取字段、转换格式。

内联形态的优势是上下文明确。用户不需要说“这段话”，因为选择本身就是上下文。

内联 Copilot 适合这些场景：

• 文档编辑器里的 selected text rewrite。
• IDE 里的 inline code fix。
• 表格里的按列生成或抽取。
• 邮件编辑器里的语气调整。
• 设计工具里的局部文案建议。
• 后台系统里的字段补全或摘要。

内联 Copilot 的 UX 重点是局部控制：

• 预览 AI 修改。
• 展示 diff。
• 支持 accept、reject、partial accept。
• 保留原文。
• 允许继续给反馈。

对编辑型产品来说，diff view 往往比完整替换更可靠。用户不是想看 AI 表演，他们想知道 AI 改了哪里，能不能只接受其中一部分。

#形态四：命令面板 Copilot

命令面板 Copilot 适合高频、可组合、跨页面的动作。

它通常通过快捷键唤起，例如类似 command palette 的界面。用户可以输入“总结当前页面”“把选中内容转成英文邮件”“从这份合同提取风险条款”“创建一个跟进任务”。

命令面板的优势是快。它不像聊天那样强调连续对话，而是强调从意图到动作的短路径。

它适合：

• 专业用户。
• 多功能复杂系统。
• 有明确对象和动作的场景。
• 需要键盘优先的效率工具。
• 需要把 AI 能力和普通命令放在一起的产品。

命令面板设计要注意两点。

第一，命令需要结构化。用户输入自然语言后，系统应该解析为 action、target、args，而不是把整句直接丢给模型执行。

第二，高风险命令需要确认。比如“把这些客户都标记为流失风险并发通知”，必须进入确认界面，而不是由 Copilot 直接执行。

#形态五：自动补全和幽灵文本

自动补全是最轻量、最主动的 Copilot 形态。

它常见于代码编辑器、搜索框、邮件、文档和表单。AI 根据当前位置预测用户接下来可能输入什么，并以 ghost text、候选列表或 Tab 接受的方式呈现。

它的优点是低打扰。用户可以无视建议，也可以快速接受。

但自动补全对质量和时机要求很高：

• 延迟必须低。
• 建议不能频繁闪烁。
• 候选长度不能过长。
• 接受和撤销必须顺手。
• 不能遮挡用户正在输入的内容。
• 不应该在敏感字段里自作主张。

自动补全不是生成长文的最佳形态。它更适合局部、短、可预测的内容，例如代码下一行、邮件短语、查询条件、表单字段、标题候选。

工程上，自动补全通常需要防抖、取消请求、光标上下文、局部缓存和模型降级策略。用户输入很快，后端响应过慢时，旧建议必须被丢弃。

#形态六：审阅和 Diff Copilot

当 AI 会修改用户已有内容时，审阅形态比纯生成更重要。

比如代码修改、合同润色、报告重写、配置变更、SQL 优化、知识库更新。用户需要看见“修改前”和“修改后”，并决定接受哪些改动。

审阅型 Copilot 应该提供：

• diff view。
• 修改原因。
• 风险提示。
• 文件或段落级 accept/reject。
• 局部接受。
• 回滚。
• 版本记录。

这种形态的核心不是让 AI 直接写入，而是让 AI 生成 patch。用户审阅 patch，再提交到真实工作流。

这类设计尤其适合高价值内容，因为它把 AI 的不确定性限制在可审阅的变更里。

#形态七：工作流 Copilot

当 Copilot 不只是回答，而是要执行多步骤任务时，就需要工作流 UI。

例如“帮我整理这个客户的历史沟通，生成跟进邮件，创建 CRM 任务，并提醒销售”。这不是一条消息可以承载的交互，而是一个包含检索、总结、生成、确认和执行的流程。

工作流 Copilot 应该展示：

• 当前步骤。
• 已完成步骤。
• 每一步输入和输出。
• 工具调用结果。
• 等待用户确认的动作。
• 失败原因和恢复入口。
• 最终提交记录。

工作流 UI 的目标是让 Agent 可观察、可中断、可恢复。用户不需要知道模型内部推理，但需要知道系统正在执行哪个业务步骤。

#产品工程视角：为不同形态设计统一协议

虽然 Copilot 有很多形态，但后端不应该为每个 UI 单独发明一套 AI 接口。

更稳妥的做法，是设计统一的交互协议：

type CopilotRequest = {
  surface: 'chat' | 'side_panel' | 'inline' | 'command_palette' | 'autocomplete' | 'workflow';
  intent: string;
  target: {
    type: 'document' | 'selection' | 'record' | 'table' | 'code' | 'page';
    id?: string;
    range?: unknown;
  };
  constraints?: {
    tone?: string;
    length?: 'short' | 'medium' | 'long';
    format?: string;
  };
};

UI 形态可以不同，但底层都应该表达：用户在哪个 surface 发起请求、目标对象是什么、意图是什么、约束是什么、结果如何被应用。

这样才能统一做权限、日志、Eval、成本统计、模型路由和安全策略。

#常见坑

第一个坑，是把 Copilot 等同于聊天。

聊天很通用，但很多任务需要的是内联修改、命令执行或 diff 审阅。强行聊天化会增加用户负担。

第二个坑，是没有上下文边界。

Copilot 必须明确知道自己能看什么、不能看什么。侧边栏如果默认读取整个系统，既有隐私风险，也会让结果难以解释。

第三个坑，是建议太主动。

自动弹出、自动改写、自动执行，都会让用户产生被打扰和失控感。AI 的主动性要和任务风险匹配。

第四个坑，是结果无法进入工作流。

如果 AI 只能给一段文本，用户还要复制、粘贴、整理、修正，Copilot 就只是一个外部工具。真正的 Copilot 应该能把建议变成可采纳的 patch、字段、任务或草稿。

第五个坑，是每种形态各做一套后端。

这会导致日志断裂、权限不一致、成本不可控、Eval 难以复用。UI 可以多样，协议和治理应该统一。

#小结

AI Copilot 的交互形态很多：聊天、侧边栏、内联操作、命令面板、自动补全、审阅 Diff、工作流 UI。它们不是谁替代谁，而是服务不同任务密度、上下文位置和风险等级。

好的 Copilot 设计，不是把 AI 放在页面旁边，而是把 AI 放进用户正在工作的动作里。它既要足够聪明，也要足够克制；既要能生成，也要能审阅、确认和回滚。