第 34 篇 Copilot 与嵌入式 AI：把能力缝进工作流
小系列〔产品形态进阶〕第 1 篇 · 定位：能力进入既有工作流，控制权在人、AI 是副驾；衔接《第 11 篇：交互设计》的控制粒度与《第 21 篇：结构化输出与系统集成》的契约。
一、嵌入式 AI 与独立 AI 应用的取舍
给产品加 AI，第一道分叉不是"用什么模型"，而是"把能力放在哪"。答案只有两条路：嵌进用户已经在用的工具里（嵌入式 AI、Copilot 形态），或者另起一个独立 AI 应用让用户专门来用（独立 AI 应用、AI 工具站形态）。这两条路的差别，本质是用户注意力和数据放在哪里，以及产品要为"上下文搬运"付出多少代价。
嵌入式 AI 的底层假设是：用户的主业不在 AI 上，而在那个宿主工具里------写代码在 IDE、改文档在文档编辑器、看数据在 BI 面板。AI 只是主业里的一个子步骤，最好就在那个步骤发生的位置出现，做完即走。独立 AI 应用的假设相反：这个 AI 任务本身就是用户今天专门要做的事，值得开一个新窗口、建立新习惯。
选错路的成本很高。把本该嵌入的能力做成独立应用，用户每次都要把上下文从宿主复制到新工具、再把结果粘回去，摩擦吞掉了大半价值；把本该独立的任务硬塞进宿主，又会受宿主 UI 和权限的层层约束，能力被削成阉割版。下面的维度表用来在立项时快速定性。
| 维度 | 嵌入型（Copilot） | 独立型（AI 应用） | 适用判断 |
|---|---|---|---|
| 上下文获取成本 | 低，宿主已有状态可直接读取 | 高，用户需手动搬运或授权拉取 | 用户已在某工具里高频操作 → 嵌入 |
| 用户习惯 | 顺势，不新建习惯 | 需新建入口与心智 | 任务是现有习惯的子步骤 → 嵌入 |
| 可控性 | 受宿主 UI 与权限约束 | 完全可控，可重做交互 | 需定制交互范式 → 独立 |
| 开发成本 | 高，要对接宿主集成与生命周期 | 中等，从零搭但无宿主耦合 | 已有成熟宿主且集成成本可控 → 嵌入 |
| 适用场景 | 高频、流程固定、嵌入点清晰 | 任务独立、需沉浸、无现成宿主 | 见决策矩阵 |
决策矩阵（定性，非打分）：当用户"已经长期住在一个工具里、AI 只是该工具内的一步、嵌入点明确"时，嵌入型几乎总是更优；当"AI 任务本身就是目的、跨多个宿主、需要全新交互语言"时，独立型更合理。一个常见误判是"我们有个 App，所以什么都该嵌进去"------嵌入的前提是宿主本身就是高频主场景，而不是只要有个壳就往里塞。
实际立项时，这个取舍还受组织惯性干扰：工程团队往往偏向独立应用，因为不用和宿主团队扯接口、权限与发版节奏；业务团队更想要嵌入，因为用户就在那里。产品经理要当裁判，用"用户会不会为了这个功能专门开一个工具"这一个反问来破局------答案若是否定，嵌入的摩擦再大也得忍，因为独立应用的获客成本会更高。反例同样常见：把一个本该独立的创作工具硬塞进办公套件，结果受套件 UI 栅格、权限模型与发版周期层层限制，能力被削到只剩演示能看。
二、嵌入位置设计：入口放哪、如何触发
嵌入位置决定了用户要在多大代价下才能用到能力。三类典型位置，集成深度递增：
- 行内（inline）：在光标处、选区旁直接出现，如代码补全、文案续写。集成最深，心流打断最小，但只适合"产出物直接落在当前位置"的任务。
- 侧边面板（side panel）：常驻一侧，承载多轮、需要上下文累积的任务，如问答、改写建议。不打断当前编辑，但占用界面空间。
- 命令/快捷键（command palette）：幂等、可复用的动作入口，如"总结这段话""转成表格"。对重度用户极快，但对新用户隐形。
触发方式同样关键，它直接决定"打扰感"来自产品还是来自用户。
| 触发方式 | 典型场景 | 优势 | 风险 |
|---|---|---|---|
| 主动建议（proactive） | 检测到可优化处自动浮出 | 零操作发现价值 | 噪声、打断、信任透支 |
| 被动唤起（reactive） | 用户点按钮或选中后触发 | 安全、可控、不打扰 | 发现成本高、使用率低 |
| 快捷键（shortcut） | 熟练用户的幂等动作 | 极快、可预期 | 新用户不可见 |
融合度要与任务关键性匹配。关键链路（如直接改用户文档）应当做成原生 UI、可逆、有预览；边缘链路可以用轻量浮层甚至 iframe，降低开发成本。一个常被忽视的原则：嵌入越深，越要尊重宿主自身的交互惯例------按钮样式、快捷键冲突、撤销栈都要与宿主一致，否则用户会感觉"这不是一个东西"。
嵌入位置的另一个隐形变量是"被发现成本"。再强的能力，如果用户不知道在哪触发，等于没有。侧边面板常驻虽占空间，却保证了可见性；命令式虽快，却依赖用户先知道有这个命令------所以两者常要配合：用一次轻提示把用户引到命令，之后用户自行养成快捷键习惯。还要注意宿主自身的组件模型：嵌入点若违背宿主的扩展机制（如插件沙箱、iframe 安全策略），集成会处处掣肘，立项前就要和宿主侧确认扩展点是否开放、能读到哪些事件，否则嵌入深度会被技术约束卡死在浅层。
三、上下文获取：AI 怎么知道用户在做什么
嵌入式 AI 相比独立应用的最大优势，是能零成本拿到用户正在做什么。但这份上下文必须被精确设计，否则要么拿不到、要么拿太多。三类上下文源：
| 上下文类型 | 获取方式 | 隐私风险 | 产品建议 |
|---|---|---|---|
| 宿主状态 | 读取当前文档/页面/应用模式 | 中，可能含敏感内容 | 只取任务必需字段，声明用途 |
| 选中内容 | 用户高亮选区作为输入 | 低，用户主动授权 | 默认以选区为首要输入 |
| 页面语义 | 解析当前实体（如订单号、客户） | 高，涉及业务数据 | 做实体级脱敏，不整页上传 |
权限与隐私边界是不可妥协的底线。原则只有几条，但每一条都对应一次事故：第一，只取任务必需的上下文，不整页、不常驻监听；第二，在宿主内明示"本次会读取什么"，让用户有预期；第三，明确数据去处------是本地推理还是上传云端，企业场景还要回答数据驻留与留存期；第四，给用户"划掉不要带走的片段"的能力，尤其是主动建议默认带走的上下文；第五，绝不静默外传，任何跨出宿主边界的读取都要可追溯。
嵌入式 AI 的信任，很大程度建立在"它只读它该读的"这一点上。一旦用户感觉"它在偷看整块屏幕"， adoption 会断崖下跌，且很难挽回。
上下文还有新鲜度与完整性的陷阱。宿主状态是动态的，用户刚删了一段、AI 却基于删除前的快照给建议，就会给出早已过时的内容。产品要定义"上下文快照的采集时机"------是触发时实时取，还是订阅变更事件保持最新，二者在复杂宿主里实现成本不同。另一类是部分上下文导致的误判：AI 只看到选区，却不知道选区所在的文档全局语境，可能给出局部正确、全局冲突的建议。该暴露全局还是只给局部，要在任务层面定清楚，而不是默认全给------那又回到隐私问题。上下文的"度"，本质是在效果与边界之间找平衡点。
四、编辑与可控性：就地编辑、可采纳可改可弃
这是衔接《第 11 篇：交互设计》控制粒度的关键落点。嵌入式 AI 的建议，必须有三种明确状态：采纳、修改后采纳、丢弃。任何"直接替用户改好、不让人确认"的设计，都在透支控制权。
- 就地编辑：建议应落在原处、可继续改，而不是弹出一个新窗口让你抄回去。
- 可改：用户能在采纳前改 AI 的产出，而不是"要么全收要么全弃"。
- 可弃：一键丢弃且零残留，丢弃不应留下半个格式或幽灵标记。
- 可溯源：标明哪一段是 AI 生成的，方便用户审阅与后续追责。
- 可逆：所有采纳都能被宿主的撤销栈撤回，AI 动作不应绕开宿主撤销。
呼应控制粒度：当任务风险低（如润色一句文案），可默认采纳并保留撤销；当任务风险高（如删一段、改一个数值），必须先预览、后确认。控制粒度的设计不是体验细节，而是"用户敢不敢用"的分界线------可控性不足，能力再强也会被弃用。
就地编辑还会撞上"冲突"问题：用户和 AI 同时改同一段。理想是 AI 只产出"待采纳的建议层"，不进入真实文本，用户采纳后才合并；若用户先手改了那段，AI 的建议要能识别"基准已变"并提示，而非硬覆盖。这要求宿主编辑器和 AI 建议层之间有差异比对能力。另一点是"部分采纳"------用户想留 AI 写的三句里的两句，这种粒度在行内补全里最难做，往往要降级成"整段替换加用户再改"。产品要诚实承认哪些粒度做不到，而不是承诺一个体验上实现不了的部分采纳，否则用户每次都发现"说好的局部采纳"其实是整段替换。
五、不打断心流：时机与节奏
嵌入式 AI 的成败，常常不在能力，而在"出现的时机"。心流是稀缺资源，打断一次，恢复要数倍时间。时机的设计要可预期：
- 该出现：用户主动触发时、做出选区时、停在某个自然停顿点（如刚写完一段、刚打开一个空模板）时。
- 该消失：用户已开始手动编辑、建议已过期（上下文变了）、任务已结束、或用户连续忽略多次时。
- 该安静：用户正在连续输入时，不要弹建议；用轻量提示而非模态框；主动建议要有"这次别烦我"的降级开关。
节奏上，主动建议要克制。一条经验：主动建议的"出现频次"和"单次价值"应该成反比------频次越高，单次必须越准、越轻。把主动建议当成通知来发，产品会很快被静音。被动唤起与快捷键承担高频动作，主动建议只用于"高置信、低打扰"的少数场景。
节奏设计还有一层是"批量与单条"。多条独立建议不要一条条弹，应聚合成一个可逐项处理的面板，让用户一次性审完，既降打扰又提效率。主动建议的频次上限建议做成可配置的产品参数（变量），并按用户画像分：新手多给引导型建议、老手少给只给高价值。还要设计"善意消失"------用户连续采纳高价值建议后，可适当降低出现频率，把主动权交还用户；反之若用户频繁忽略，应自动降级该类型建议，而不是机械重复。心流保护的本质，是把"出现与否"当成产品决策而非模型输出，由产品节律而非模型随机性来决定。
六、与宿主系统的数据契约
这是衔接《第 21 篇：结构化输出与系统集成》契约思想的地方。嵌入不是"调一下模型"，而是要和宿主之间定义清楚三件事：输入给什么、输出怎么回写、失败怎么兜底。
| 契约环节 | 要定义的内容 | 失败兜底 |
|---|---|---|
| 输入 | 给 AI 哪些上下文、脱敏规则、字段 schema、版本号 | 缺字段则降级或转人工，不猜 |
| 回写 | 写回宿主哪个字段、什么格式、是否幂等、是否需要确认 | 写入前二次业务校验，超阈冻结 |
| 失败 | 区分拒答/解析失败/超时，各自走哪条链路 | 中性降级值，不污染宿主数据 |
复用结构化输出的几条纪律：字段越少越好（失败率随字段数连乘下降）；枚举优于自由文本但留 other 出口；让 AI 出"参数"而非"计算结果"，真正的落库计算交给宿主确定性代码；长文本必限长。写入型嵌入还要加"暂存---确认---提交"三态，尤其是会改用户真实数据的动作。契约的归宿很明确：模型负责尽量给对，产品负责给定对的结构和错的结构各自的去向------嵌入式场景里，错的去向常常是"别碰宿主数据"。
嵌入式契约还有版本演进问题：宿主升级、模型换版，契约字段会增减，必须用 schema_version 协商，且遵循"新增字段可选、删除字段先标废弃再下线"的兼容节奏，否则一次宿主发版就可能让 AI 功能集体报错。另一个被忽视的点是"回写冲突"：宿主自己也在改那个字段，AI 回写时要用乐观锁或合并策略，避免覆盖用户刚做的编辑。失败链路里，嵌入式场景最该警惕的是"降级值污染宿主"------降级只能给中性占位（如"暂无法生成"），绝不能填一个看似合理的值进用户真实文档，否则污染的是用户自己的资产，信任损失比独立应用严重得多，且用户很难意识到自己文档被悄悄改写。
七、度量嵌入效果：别只看"用了没"
嵌入式 AI 最容易制造虚假繁荣：功能被展示、被点击、被试用，但用户的主业指标没变好。度量必须穿透到"主业"。
| 指标 | 定义 | 陷阱 |
|---|---|---|
| 采纳率 | 建议展示后被采纳/修改采纳的比例 | 高展示量稀释，看相对采纳而非绝对 |
| 节省时长 | 采纳后相比手动操作的耗时差 | 自报不准，需用行为日志估算 |
| 宿主核心指标 | 对宿主主业指标的归因影响（如编辑时长、错误率） | 相关性≠因果，需 holdout 对照 |
| 留存/频次 | 嵌入功能是否提升宿主使用频次 | 可能被新功能 novelty 短期拉高 |
避免"功能用了但主业没变好"的核心是做对照：拿一组不曝光建议的用户做 holdout，比较主业指标差，才能证明嵌入真的创造了价值而非制造了热闹。vanity 指标（曝光量、点击量）只能用于诊断体验问题，不能作为价值证明。采纳率要结合"采纳后是否被回退"一起看------被采纳又很快删掉的，等于没采纳。
度量还要区分先行与滞后。采纳率、节省时长是相对滞后的结果指标；先行指标是"建议的相关度""用户从展示到采纳的时延""被采纳建议后续被编辑的比例"------这些能在价值真正形成前预警体验问题。仪表盘上要同时挂两类，且把"采纳后被回退"单列，因为它最尖锐地反映"建议看着对、用着不对"。最后，嵌入效果的归因要有耐心：主业指标的提升往往有滞后窗口（用户要先养成使用习惯），holdout 对照的实验周期要足够长，用一周数据下结论容易误判为"没用"，实则只是习惯未成。度量的目的不是证明功能存在，而是证明主业真的变好。
嵌入式 AI 设计检查清单
text
嵌入式 AI 设计检查清单（立项/评审逐项打勾）
─────────────────────────────────────
[ ] 取舍：用户是否长期住在该宿主、AI 是否只是子步骤？是→嵌入，否→考虑独立型
[ ] 位置：嵌入点是否在任务发生处？行内/侧栏/命令三者是否按任务关键性选对
[ ] 触发：主动建议是否只在高置信低打扰场景？被动/快捷键是否覆盖高频动作
[ ] 上下文：只取任务必需字段？是否声明用途并允许用户划掉敏感片段
[ ] 隐私：数据本地还是云端？企业场景是否回答驻留与留存？是否可追溯
[ ] 可控：建议是否三态(采纳/改/弃)？是否就地编辑、可溯源、进宿主撤销栈
[ ] 心流：是否在输入中不打扰？是否有"别烦我"降级？过期建议是否自动消失
[ ] 契约：输入 schema/回写字段/失败链路是否定义？写入是否三态提交
[ ] 容错：降级是否为中性值(不污染宿主)？拒答/解析失败/超时是否分流
[ ] 度量：是否设 holdout 对照主业指标？是否同时看"采纳后被回退"率
[ ] 融合：UI/快捷键/撤销是否尊重宿主惯例？是否让用户感觉"是一个东西"一页速查
text
Copilot 与嵌入式 AI · 一页速查
─────────────────────────────
取舍：用户住宿主+AI是子步骤→嵌入；AI即目的+跨宿主→独立
嵌入位置：行内(产出落当前)/侧栏(多轮)/命令(幂等动作)，深度随关键性升
触发三式：主动建议(高置信低打扰)/被动唤起(安全)/快捷键(快但隐形)
上下文三源：宿主状态|选中内容|页面语义；只取必需、声明用途、可划掉
隐私底线：不整页监听、明示读取、答数据去处、绝不静默外传
可控三态：采纳/改/弃；就地编辑、可溯源、进宿主撤销栈
心流：输入中不打扰、过期即消失、有"别烦我"开关
数据契约：输入schema|回写字段(幂等/确认)|失败分流(拒答/解析/超时)
写入防护：暂存-确认-提交三态；字段越少越好；AI出参数不出计算结果
度量：holdout 对照主业指标；采纳率要结合"采纳后被回退"率看
纪律：可控性不足能力再强也被弃；降级中性值绝不污染宿主数据。常见坑
- 把本该嵌入的能力做成独立应用，用户反复搬运上下文，摩擦吞掉大半价值。
- 嵌入前提只是"我们有个壳"，宿主并非高频主场景，能力被硬塞成阉割版。
- 主动建议发得太频太泛，被当成通知静音，高价值场景也一并淹没。
- 上下文整页上传、常驻监听，用户感觉被偷看，信任断崖后难挽回。
- 建议直接替用户改好不确认，越过控制粒度，高风险动作也无预览。
- 丢弃建议后留下半个格式或幽灵标记，用户不得不手动清理残留。
- AI 动作绕开宿主撤销栈，用户无法一键撤回，安全感丧失。
- 回写宿主不做二次业务校验，结构合法但业务非法的数据写进真实字段。
- 降级值被当成真实数据落库，错误伪装成正常并一路污染下游。
- 只报曝光量点击量当成绩，无 holdout 对照，功能热闹主业没变好。
结语
嵌入式 AI 的底座不是模型能力，而是"在正确的位置、用正确的时机、把控制权留在用户手里"------缝进工作流的前提，是绝不替用户做主。
本文为「AI 产品经理入门与进阶」系列第三季·小系列〔产品形态进阶〕第 1 篇（总第 34 篇）。数据来源：本篇取舍矩阵、触发方式表、上下文获取表、数据契约表与检查清单均为可操作框架，示例数值已标注"示例数据，非真实业务"。具体数值（采纳率基线、节省时长、holdout 样本量等）随技术迭代与业务差异变化，请以最新数据为准。