Copilot 产品

Copilot

Copilot（副驾驶）是嵌入既有工作流的 AI 助手：用户继续用熟悉的软件，AI 在旁边提供建议、补全、生成。它不抢用户的方向盘，而是在用户驾驶时看路况、递提示——人主导、AI 辅助是 Copilot 的第一原则。

Copilot 的价值公式：价值 = 上下文准确度 × 建议及时性 × 用户信任。三者缺一，用户就会把它当成「嵌在工具栏里的对话框」甚至直接关掉。

什么时候选 Copilot 形态（而不是对话产品或 Agent）：

1. 用户是否已有一个高频、固定的工作流？（写代码、写文档、做设计、回邮件）
2. 这个工作流是否产生大量「可预测的下一步」？（补全、续写、起草、总结）
3. 用户是否在意「不离开当前界面」？（切换窗口去聊天是成本）

三条都答「是」，Copilot 是比对话产品更优的形态；若任务需要系统自己跑完多步，则归 Agent 产品 与 工作流自动化 的范畴。

何时不要做 Copilot：

• 任务没有固定工作流（用户每次路径都不同）——对话产品更合适
• 任务需要系统自主完成多步——归工作流/Agent
• 上下文无法自动感知（用户数据在墙外、没有可捕获的信号）——Copilot 失去灵魂，退回对话

形态谱系：上下文源 × 动作粒度

Copilot 不是一个产品，而是一族产品形态。区分它们的是两个变量：

• 上下文源：建议基于什么信息——光标位置、选中内容、整个文件、会话历史、组织知识库
• 动作粒度：AI 能替用户做到哪一步——补一个词、生成一段、改一个选区、执行一个动作

规律：上下文越「贴着用户正在看的东西」、动作越「短、可预览、可撤销」，越像好 Copilot；反过来就滑向对话产品或 Agent。

各形态的差异化设计要点：

• 代码补全：核心是「贴着光标」——读光标前与光标后的代码，补全风格要跟随现有代码风格；误补全的成本最低（删掉即可），但仍要防「补全了用户没写过的 API」
• 文档/办公：核心是「尊重已有内容」——改写不要破坏用户已写好的段落，续写要接得上语气；批量操作（全文改写、翻译）必须给 diff
• 设计：核心是「选中即上下文」——选中图层后的建议直接作用于该图层，批量操作（重命名、填充）要可预览、可撤销
• 数据：核心是「报表即上下文」——建议跟着当前筛选条件走，解释要能追溯到数据来源
• 邮件：核心是「线程即上下文」——起草基于当前线程语气，发送前必须人工确认（不可逆动作）
• 客服工作台：核心是「知识库即上下文」——回复草稿要带引用，供客服核对后发出

与对话产品的本质区别

对话产品的上下文靠用户描述，Copilot 的上下文靠系统感知——这是二者最本质的分工差异。用户在聊天窗里要说清"我要改哪段、改成什么样"；Copilot 不需要，它已经看到光标停在哪、选中了什么。

成本结构也不同：对话产品的成本 = 每次回答的生成成本；Copilot 的成本 = 每次建议的生成成本 包括被忽略的建议——噪音建议不产生价值却烧了 token，还损耗信任。这解释了为什么「触发要保守」不只是体验原则，也是成本原则。

与 Agent 的边界

Copilot 与 Agent 常被混为一谈，但主导权相反：

• Copilot：人主导、AI 辅助。人决定做什么，AI 提供建议、补全、草稿，人确认后生效。风险低，因为每一步都经过人
• Agent：AI 主导、人监督。系统拿到目标后自己规划步骤、调用工具、执行，人在关键节点确认或事后验收

判断句：Copilot 是把判断权留给用户；Agent 是把执行权交给系统。同一条建议，"用户点了才执行"是 Copilot，"系统自己执行完再汇报"是 Agent。Claude Code 的权限分级（Manual 默认只读 / Auto 分类器放行 / 沙箱隔离）展示的正是从 Copilot 到 Agent 的光谱，详见 Agent 产品 与 Agent 与工作流。四类形态（对话 / Copilot / 工作流 / Agent）的完整对比见 Agent 与工作流 的「Agent 与 Chatbot、Copilot、Workflow 的区别」一节。

从对话到 Copilot 的迁移

已有对话产品的团队常想「加一个 Copilot 形态」。迁移路径按依赖顺序排：

1. 接入宿主上下文：识别用户当前文件/选区/光标，这是 Copilot 与对话唯一的本质区别
2. 建议式输出：把「一段回答」改成「可直接落地的增量」（补全、改写、生成草稿），并支持一键应用
3. 低打断呈现：结果出现在用户视线内而非新窗口，接受/忽略成本降到一次按键

混用形态是常态：对话负责「开放式提问」（Notion AI 的问答、ChatGPT 式的全局提问），Copilot 负责「就地动作」（选中改写、续写、总结）——两者共用同一模型与知识，只是入口与交互不同。

核心设计问题

1. 上下文感知

上下文来源分级

Copilot 的价值来自对用户当下状态的理解。上下文按来源离用户远近分级，每级的信息量与隐私成本递增：

原则：能用低级别解决的，不上高级别。代码补全读光标前几百 token 就够；要生成整页周报才需要会话与知识库。每升一级，都问一句：这一级的信息真的让建议变好了吗？

上下文工程

上下文工程决定「喂什么、不喂什么」：

• 喂什么：与当前任务直接相关的内容——选区、附近代码、当前文档结构、用户最近动作
• 不喂什么：无关文件、历史噪音、敏感数据、权限外内容
• 预算：上下文窗口有限，按「离任务远近」排序，超出窗口的截断或摘要
• 优先级：显式选中 > 当前文件 > 会话摘要 > 组织知识检索

与 Agent 架构与多智能体 的上下文工程同理：模型只看到精心挑选的上下文，质量才能稳定；把整个仓库塞进去，建议会被无关内容稀释。

上下文窗口预算示例（按 8k 窗口估算）：

截断策略：不是「从末尾截」，而是按相关度排序后取前 N 段——无关内容宁可不要，也不要挤掉高优先级片段。

上下文构建的工程组件

从「用户动作」到「模型输入」之间是一条装配线，每个环节都影响上下文质量：

• 事件捕获：监听光标、选区、滚动、切换文件等信号，判断"用户正在做什么"
• 权限检查：当前上下文是否在用户授权范围内——读取前先查权限，而不是读取后再过滤
• 检索与裁剪：从文件/仓库/知识库中取相关片段，按相关度排序截断
• 编排进 prompt：按「系统指令 → 当前任务 → 上下文片段 → 用户意图」的顺序组装，上下文放错位置会被模型忽略

感知失效的退化路径

自动感知不会永远成功：权限被拒、文件未保存、检索为空、信号抖动。此时要设计退化路径，而不是静默给一个无关建议：

1. 感知失败 → 不弹建议（零噪音），或
2. 感知不确定 → 弹「基于选中内容」的建议并标注依据，或
3. 明确询问用户——但询问本身是打断，只在用户主动调用时才允许

2. 低打断设计

触发时机

建议何时出现，比建议内容更重要。两类触发：

• 显式调用：用户按快捷键、点按钮、输入命令前缀触发。零打断，但要求用户记得"有这功能"
• 自动建议：系统检测到合适时机主动弹出。体验好，但误触发即噪音

自动建议的触发信号按可靠度排序：光标在空白处停留 → 选中一段文字 → 刚写完一句话 → 用户行为模式（如总是手动删除第一段）。触发规则宁可保守——晚一点出现，好过打断心流。

再加一条硬性约束：频率限制与冷却——同一位置短时间内只弹一次、同一会话内建议次数设上限；触发规则与冷却参数本身要可配置、可 A/B 测试。

建议质量门槛

每条建议上线前有质量门槛，低于门槛不弹出：

• 与上下文的匹配度：建议是否贴着用户正在做的事
• 长度与动作匹配：小动作给大建议 = 噪音
• 置信度：模型自评或规则过滤

产品上实现为「延迟/抑制」策略：低置信建议不展示、只进日志用于离线分析，高置信建议才弹出。宁可少弹，不可乱弹——误触发建议 = 信任损耗，一次离谱建议的伤害需要十次好建议弥补。

噪音经济学与采纳率

Copilot 的北极星指标是建议采纳率：

• 采纳率 = 被接受的建议数 / 展示的建议数
• 拆解：触达率（建议被用户看到的比例）× 采纳率（看到后被接受的比例）
• 噪音率 = 被忽略的建议数 / 展示的建议数（与采纳率互补，衡量"打扰"）

采纳率不高时，优先优化什么时候给建议（触发与门槛），而非建议的质量——把好建议在错误时机给出，用户根本不会读。Nielsen 的可用性启发式（1994）对应到 Copilot 就是三条：建议必须可忽略、可纠正、不阻塞。

异步 vs 同步

• 同步：生成结果立即出现在光标处/侧栏，用户短暂等待（如补全、短总结）
• 异步：生成在后台进行，用户可继续编辑，完成后提醒（如整页周报、PPT 生成）

同步建议必须非阻塞（non-blocking）：生成中用户继续打字，结果随时可放弃，不打断输入流。异步任务要给出进度与预期时长，完成后以轻量提醒呈现，不弹窗轰炸。原则：用户永远可以"继续做自己的事"，是低打断的底线。

建议的呈现形式

一次只展示一条主建议（候选可翻页），多条建议并行展示等于把决策成本转嫁给用户。

3. 建议的信任

• 短：建议默认只给最小可行动单元（补全一个词、一段、一个动作），长内容放"展开"
• 可预览：给出 diff/对比，用户一眼看到"采纳后变成什么"
• 可修改：建议不是黑盒，用户能在采纳前编辑
• 高风险建议显式确认：自动改写代码、自动发送邮件、批量替换——先展示 diff，确认后执行，并保留撤销
• 引用与来源：建议基于某段代码/文档时标注来源（如"参考了 src/utils.ts 第 42 行"），用户可跳转核对

信任是逐步建立的：先只读（补全、建议）→ 再可撤销写（改写、生成）→ 后高价值写（自动发送、批量执行）。每一级都要有对应的可见性与确认机制，参考 Agent 产品 的「代理权要赚取，不要授予」。

信任生命周期：

• 教育期（前几次使用）：建议要保守、可预期，让用户快速理解"它能做什么、不会乱来"
• 稳定期：按采纳率与噪音率调优触发与质量门槛
• 放大期：信任积累后才开放更高风险能力（自动执行类），并以评测证据支撑

学习信号：用户修改后采纳的建议是金矿——它告诉你"模型差在哪一步"（长度、语气、结构）。把修改行为回流为评测样本与 prompt 优化输入，比只看采纳/忽略两分法信息量大得多。

领域边界：医疗、法律、金融等高风险领域，Copilot 的定位是「建议」而不是「代劳」——给草稿、给依据、给风险提示，最终判断与责任在用户。这类场景建议自带边界提示（"以官方页面/专业人士为准"），并以「只建议、不自动执行」为默认。

4. 评测：采纳率是北极星

线上指标（量）：

线下评测（质）：

• 人工抽检：按场景采样"展示过的建议"，标注相关/有用/噪音三档
• 回归集：固定一批代表性场景，模型或规则升级后跑一遍，防止建议质量回退
• 分层分析：按形态（补全/改写/生成）、按上下文级别（L1-L4）拆分采纳率，定位薄弱环节

实施步骤建议：

1. 先埋点（展示、接受、忽略、修改后接受四个事件），跑一周拿到基线
2. 按场景分层看采纳率，找出最差的两个场景（通常触发问题多于质量问题）
3. 改触发/门槛 → A/B 测试验证 → 稳定后纳入回归集
4. 模型升级时跑回归集，防止「能力变强但建议变吵」

评测体系的方法论见 评估与评测。

5. 嵌入形态与分发

• 产品形态决策：插件/扩展（IDE、浏览器扩展）、内嵌面板（宿主应用内侧栏）、API 嵌入（把 Copilot 能力授权给其他产品）。决策依据：宿主应用的可扩展性、分发渠道（商店/企业内网）、控制权（谁决定更新节奏）
• 与宿主应用的权限模型：读取范围（当前文件？整个项目？）、写入范围（只插入光标处？可以改其他文件？）、自动执行范围（仅建议，还是可以执行动作）。权限模型决定风险边界，参考 Agent 产品 的「权限最小化」
• 企业部署：管理员开关（按部门/角色启用功能）、策略控制（哪些能力可关、数据是否可出境）、审计日志。B 端客户关心的不是功能列表，而是"能关掉什么"
• 失败与降级：宿主离线、模型不可用、权限被撤销时，Copilot 应降级为「不弹建议」而不是报错打断；异步任务失败要保留现场、可重试，参考 工作流自动化 的失败处理
• 与宿主应用的生命周期：宿主升级时插件 API 变更怎么办；Copilot 功能开关要随宿主启动/禁用同步，避免"宿主都关了 Copilot 还在弹"

案例走查：客服 Copilot 从 0 到 1

以「客服工作台 Copilot」为例，走一遍完整设计：

1. 场景与形态：客服坐席在工单系统里处理客户会话——高频、固定界面、大量重复劳动（读历史、写回复）。形态选「内嵌面板」：在工单详情右侧展示建议，客服不离开工作台。

2. 上下文设计：

隐私边界：L3/L4 默认只读摘要；客户数据不进训练；管理员可关闭任一来源。

3. 低打断设计：触发 = 客服选中客户消息或点击「起草回复」按钮（显式为主、自动为辅）；质量门槛 = 与当前消息相关且带引用，否则不弹；呈现 = 行内草稿卡片，一键应用、可编辑后发送；异步 = 长回复在侧栏生成，不阻塞继续读消息。

4. 信任：草稿必须带引用（"依据知识库 FAQ-42"）；发送按钮在草稿区之外，AI 永不直接发送——不可逆动作留在人手里。

5. 评测：触达率（按钮点击率与自动建议展示率）、采纳率（草稿被应用的比例）、噪音率、审核后的发送率；人工抽检"被忽略的草稿是否其实有用"。

走查要点：每一步都回到三个问题——感知了什么上下文？什么时候给建议？用户如何确认？答不上来，就是设计没闭合。

常见坑

• 弹窗轰炸：每条建议都弹、低价值建议也弹，用户被迫关掉整个功能——触发要保守，低于门槛不弹
• 建议与上下文无关：读不到用户正在做的事，给出"看起来通用、实则没用"的建议——先解决上下文，再谈建议质量
• 上下文泄漏：把不该喂的数据喂给了模型（权限外文档、隐私数据、客户信息）——上下文边界是产品红线，详见 数据隐私与用户控制
• 无法关停：用户找不到关闭按钮、或关闭后无感知——低打断的前提是"随时可退"，关停要一键、要持久
• 把 Copilot 做成第二个对话框：嵌在工具栏里的聊天窗，失去自动感知就失去灵魂——Copilot 的第一要务是感知上下文，不是聊天
• 建议时机不对：打断心流（写一半被弹窗覆盖、生成结果抢走焦点）——异步化、非阻塞
• 忽略用户已有习惯：Copilot 要适配工作流，不是让用户适配它——先观察用户怎么做事，再设计建议时机
• 只盯采纳率，忽视触达率：采纳率 100% 但触达率 1%，说明建议几乎没出现——两个指标要一起看
• 一次开放全部能力：新用户第一天就收到批量改写、自动发送类建议，信任还没建立就被吓跑——按信任生命周期分阶段放能力

设计评审清单

设计评审时逐项过：

• 上下文：每个能力点明确感知哪个级别（L1-L4）？低级别够用时是否上了高级别？权限检查在读取前还是读取后？
• 触发：显式调用入口是否明显？自动建议的触发信号是否保守？有无频率限制与冷却？
• 呈现：建议是否短、可预览、可修改？高风险动作是否有 diff 与确认？是否阻塞了用户正在做的事？
• 信任：引用与来源是否可见？能否一键忽略/关停/撤销？能力是否按信任生命周期分阶段开放？
• 隐私：哪些数据进了模型、用户是否知情可控？对照 数据隐私与用户控制 逐条核对？
• 度量：采纳率/触达率/噪音率埋点是否齐备？有无回归集防质量回退？
• 分发：权限模型（读/写/执行）是否最小？企业侧能否按策略关停？

来源说明

本文由本站撰写整理，综合参考以下权威来源：

• Anthropic — Building Effective Agents：工作流与 Agent 的区分、透明度与工具设计（人机协作边界）
• Claude Code — Best Practices：验证闭环、权限模式、checkpoint 回退（建议信任与可撤销）
• Claude Code — Security：权限模型、数据边界（嵌入形态与权限模型）
• OpenAI — Agents 指南：Agent 定义与能力边界（与 Copilot 的对照）
• Nielsen, 1994, 10 Usability Heuristics：可忽略、可纠正、不阻塞的可用性启发式（低打断设计）
• 本站 Agent 产品、数据隐私与用户控制、评估与评测：交叉引用

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用