上线与采纳

给已经把东西造出来、准备让真人用起来的人。这一页回答：结果送到哪里去、上线那天做什么、没人用的时候怎么诊断、指标怎么埋怎么看、以及系统怎么才能活过它的第一个推动者。

上一段的工作见 build-and-mvd.md，采纳之后的算账与扩大见 value-accounting.md。

一、采纳为什么值得单独占一整段

行业里被反复引用的一条经验分配是 BCG 的 10-20-70 原则：AI 转型的努力应该有约 10% 花在算法、20% 花在技术与数据、70% 花在人与流程上（BCG, The Leader's Guide to Transforming with AI；该页对自动抓取返回 403，建议人工打开核对；Forbes 的转述）。

OpenAI 在《The State of Enterprise AI 2025》里给出的判断是同一个方向的另一种说法：

"The primary constraints for organizations are no longer model performance or tooling, but rather organizational readiness." （组织现在的主要约束已经不再是模型性能或工具，而是组织准备度。）

这两条合起来解释了一个在企业 AI 项目里高频出现的现象：系统上线、账号开了几千个、周活跃只有两位数。这类结果通常不是模型不够好，而是采纳没有被当成设计对象。

二、上线要做的三件事

「上线」这个动作本身很短，但有三件事省不掉。

第一，灰度名单点到人名。 不是「先开放给客服部」，而是五到八个具体的人。这份名单里应当包含三种人：一个在同事中有威望的意见领袖、一个已知的怀疑者、一个新人。意见领袖决定后面的人跟不跟；怀疑者会把所有问题说出来，而且他的认可最值钱；新人是交互设计的试金石，老手能忍受的别扭新人忍不了。

第二，退路要显式存在，并且要说出来。 上线当天当众说明「原来的干法完全没动，随时可以退回去；觉得不好用就别用，然后告诉我为什么」。这句话看上去在削弱推广力度，实际是在换真实反馈——一个被强制使用的系统，无法判断它是不是真的有用。这一点对应 Everett Rogers《创新的扩散》里影响采纳速度的五个属性之一 Trialability（可试性）。

第三，埋点在上线第一天就要有。 至少三样：谁打开了、谁真的用了、谁用到一半退出了。没有埋点的上线，等于在这一段里蒙着眼睛工作。

三、入口：系统可以新，入口必须旧

原则：用户在哪里干活，结果就送回哪里。

在中文企业 AI 项目里，最常见的采纳杀手是为了显得先进而要求一线学一个新门户。一个每天已经要开六个系统的人，不会为了新系统再开第七个。

用户实际在哪干活	结果送到哪	常见的错误做法
Excel	生成 Excel，或直接写回他那张表	做个网页要他导出再导入
企业微信 / 钉钉 / 飞书	机器人推消息，群里就能操作	发一个链接让他跳转登录
ERP / 现有业务系统	结果写回单据字段或备注区	单独一个「AI 助手」菜单
车间、现场、手上有活	语音输入、大字、单手可操作	让他脱手套打字
纸	打印出来的那张纸上多一行	「请扫码使用」

这条原则在厂商侧也有对应的公开例子。OpenAI 在西班牙对外银行（BBVA）的部署，是从员工已经在用的 ChatGPT 界面切入，而不是另起一个门户；范冰在《前线部署工程师》2.6 节把这条概括为「新系统真正难对付的，是用户的旧习惯」。

入口这件事只有一个自查问题：用户为了用这个东西，需要新增几个动作？0 最好，1 可以接受，2 以上通常撑不住。

四、语言：先给判断，还是先给依据

同一套模型、同一批语料，输出的组织方式不同，采纳结果可以差一个数量级。

Google PAIR 的《People + AI Guidebook》在 Explainability + Trust 一章里强调向用户解释系统、展示置信度、给出依据（pair.withgoogle.com/guidebook）。这套建议的隐含假设是消费级产品的使用场景——用户有耐心、环境安全、有时间读。

在工业现场、急诊、车间这类场景里，这个假设不成立。中文材料里反复出现的一个对照是：老师傅被问「温度报警怎么办」，第一句通常是「八成是探头脏了，先擦探头」，先给经验判断，再给排查步骤；而系统的第一句常常是「请按照以下规程逐项检查」。前者是决断性优先，后者是解释性优先。

可操作的做法有三条：

1. 回答结构翻过来：先给最可能的判断和下一步动作，再把标准依据附在后面给愿意看的人看。
2. 知识库的单位是「这一行的人会怎么说」，不是「文档里怎么写」。
3. 自查方法：把系统的 10 条真实回答打印出来，念给一位资深从业者听。他皱眉说「谁这么干」，这条语料就该重写。

（上述对照来自中文实践材料的脱敏叙述，公司名与具体数字为示例，不宜作为行业统计引用。）

五、变更管理：两套经典模型与它们的边界

5.1 Kotter 八步

John Kotter 的变革八步是企业变革领域最广为引用的框架，官方页面的表述如下（Kotter Inc. 方法页）：

1. Create A Sense of Urgency（营造紧迫感）
2. Build A Guiding Coalition（组建引领联盟）
3. Form A Strategic Vision（形成战略愿景）
4. Enlist A Volunteer Army（招募志愿者队伍）
5. Enable Action By Removing Barriers（清除障碍以释放行动）
6. Generate Short-Term Wins（创造短期胜利）
7. Sustain Acceleration（保持加速）
8. Institute Change（把变革制度化）

适用边界：Kotter 的模型是组织层面的、自上而下的、以年为单位的变革路线图。它对一次为期数周的单场景部署往往过重。在 FDE 的语境里最常被实际用到的是第 2、6、8 三步——引领联盟（谁站台）、短期胜利（第一批可见的结果）、制度化（进流程、进考核）。

5.2 ADKAR 五要素与「障碍点」

Prosci 的 ADKAR 模型说的是个人完成一次改变要依次达成五个结果：Awareness（知道为什么要变）、Desire（愿意变）、Knowledge（知道怎么变）、Ability（真的做得到）、Reinforcement（变了之后被固化）。出处是 Jeff Hiatt 的《ADKAR: A Model for Change in Business, Government and our Community》（Prosci，2006），官方方法页见 prosci.com/methodology/adkar（该页对自动抓取返回 403，建议人工打开核对）。

这个模型对 FDE 最有用的不是五个字母，是 barrier point（障碍点） 这个概念：进度被第一个不足的环节卡死。如果一群人缺的是 Desire（愿不愿意），再多的 Knowledge 培训也不会改变结果。

适用边界：ADKAR 的原版假设组织内部的利益是对齐的——所有人都想要这次变革成功，只是能力或认知不到位。在真实企业里这个假设经常不成立，需要额外处理「变革让某些人受损」这一类情况，见下一节。

5.3 其他常被引用的框架

• McKinsey 变革四支柱 / 影响力模型：理解与信念、强化机制、技能培养、榜样示范。第二条「用正式机制强化」在 AI 系统上线场景里最常被跳过——系统上线了但考核没改，等于没上线（McKinsey, The four building blocks of change）。
• OpenAI 的组织侧观察：领先企业「把中心化的治理与培训，和通过嵌入式 AI champion 实现的分布式赋能结合起来」（《The State of Enterprise AI 2025》）。这是「引领联盟 + 内部冠军」在 2025–2026 年的公司实践版本。

六、抵抗诊断：能力、意愿、利益

上线之后每天都会遇到同一个问题：有人不用，为什么。诊断错了，后面的动作全部白做。

一个可操作的三分法是把 ADKAR 的障碍点压缩成三类：

6.1 前两类

① 能力问题（产品不好用）。 症状是用了但用得难受，抱怨很具体。解法是当天改、当晚通报。这一类最忌讳用培训来解决——培训解决不了慢。

② 知识问题（不会用）。 症状是打开过一次就没再打开，问出来的问题是「这个在哪点」。解法是陪他做一次完整的、真实的活，而不是演示。这一类最忌讳发操作手册。

6.2 第三类：利益受损

识别信号是「极度配合、零抱怨、零使用」。 真正嫌产品不好用的人会抱怨，真正不会用的人会提问，只有第三类会对你笑。

常见形态有三种：

1. 考核会变难看。 系统第一次把某个隐性指标（返工次数、处理时长、差错率）统计出来了，而这个数字会进他领导的报表。
2. 隐性权力被削掉。 他原来的价值是「只有他知道这个怎么算」，系统把这件事公开之后，他从「不可或缺」变成「一个岗位」。
3. 他管的人会变少。

三条处理路径，按成本从低到高：

• 给他署名，让他成为规则的定义者。 把判定规则标注为由他定义，在汇报里点名。这不是权术——评估标准本来就应该由业务专家定，见 evaluation.md。
• 让他先受益一次。 先做一件让他自己轻松的事，哪怕与主线无关。
• 给他退路。 如果他负责的工作确实会被替代，这件事通常不该由交付方来谈，但必须由交付方向发起人提出来。ADKAR 的原版模型假设组织利益对齐，这个假设不成立时，「受损者的出路」必须被显式设计。

范冰在《前线部署工程师》4.6 节把这一点写成了一句可直接引用的判断：「抵抗的成本，远高于安抚的成本。」

这一类原因在埋点日志里看不到。 数据能告诉你他没登录，告诉不了你他昨天在茶水间说了什么。

七、冠军用户与带头人

Rogers 在《创新的扩散》里的核心发现之一是：采纳的起飞点来自意见领袖的同侪影响——peer-to-peer 的沟通、角色示范、人际网络，而不是自上而下的宣讲。

落成三个可执行的问题：

1. 找到那个有威望的一线用户了吗？（不是最配合的那个，是别人服的那个。）
2. 他的第一次使用，是有人陪着完成的吗？
3. 「有用」这两个字，是从他嘴里、用他自己的话说出来的吗？

第一问需要点破一件事：在很多组织里，「最配合的人」和「别人服的人」是两个人，而新手会天然选前者——好约、态度好、不让人难堪。但最配合的那个人说「挺好用的」，通常没有人会跟。找到别人服的那个人的方法是看别人遇到问题时去问谁。

企业侧的公开对照案例有两个量级：

• BBVA 推 ChatGPT Enterprise 到 12 万人，靠的不是厂商培训团队，而是两批内部角色：一张全行的「AI 先锋网络」在各业务部门做工作坊、挖场景；一批被同事称为「AI 极客」的高级用户手把手带身边人。OpenAI 公开的数据是五个月内员工创建了超过 2,900 个 custom GPT，其中法务团队用它每年回答约 40,000 个政策与合规问题（OpenAI, AI in the Enterprise）。
• Anthropic 与埃森哲的合作是三万名顾问接受系统培训，组成一支再去带客户的队伍。

两个案例的结构是同一个：厂商真正要培训的只有一类人——会去培训别人的人。

八、培训与话术

企业场景的上手引导与消费产品有根本不同：消费产品的引导是一次性自助流程，企业系统的引导是一个永不结束的滚动过程（新员工入职、组织调整、新部门纳入）。设计得差，使用率会随着最初那批被培训过的人流失而自然衰减。

三个可复用的结构（综合自《前线部署工程师》5.4 节）：

• 分层培训。 一刀切的全员培训是最大的浪费。有效的分层是三层：管理员与内部支持者的深度培训（他们未来是内部专家）；普通用户的场景化培训（不讲功能，讲「你的日常三件事怎么用系统做」，30 分钟封顶）；高管的一句话培训（「打开这里，这个数字就是答案」）。
• 培训培训师。 交付方终将撤场，培训工作必须在撤场前移交。识别组织里的热情分子，把他们变成内部讲师与内部答疑人，给官方认证、专属支持通道、以及在高管面前的曝光机会。Anthropic 与 FIS 合作的核心设计就是把「转移知识，让客户能独立构建和扩展自己的 agent」写进合作条款。
• 文档要以任务组织并嵌进产品。 「如何处理一笔异常退款」而不是「退款模块功能说明」；在用户卡住的地方就地出现，而不是独立存在于某个知识库。

每天的三个动作

采纳阶段的节奏是每天的，不是每周的。

时段	动作	要点
早	看埋点日报	日报要能点到人名，不是一个总数
白天	去找一个没登录的人	开场不要问「你为什么不用」（答案永远是「最近有点忙」），问「昨天那个活你还是按老办法干的吧，我在旁边看两分钟行吗」
晚	发一条一句话通报	格式固定：「今天根据 X 的反馈改了 Y」，具体到人名和改动，不要写「优化了系统性能」

晚上那条通报同时做了三件事：让改进被看见（对应 Rogers 的 Observability）、让抱怨被当天兑现、给下一个人一个提意见的理由。

九、埋点与采纳指标

9.1 指标框架

Google 的 HEART 框架 + GSM 流程（Goal → Signal → Metric）是这一段最常被借用的底子：Happiness、Engagement、Adoption、Retention、Task Success 五个类别，先定目标、再定信号、最后定指标（Rodden、Hutchinson、Fu，CHI 2010，作者页）。

HEART 原本是给有数据团队的大型产品用的。在一次单场景部署里，通常只取它的流程，落成一份能点到人名的日报：

行	内容
昨天有几个人用了	名单
谁用到一半退出了	名单 + 卡在哪一步
谁一次都没登录	名单（这一行就是今天的工作清单）
系统昨天答不上来的	条目列表（直接进评估集迭代）

9.2 几个采纳指标与它们的口径陷阱

指标	定义与用法	口径陷阱
激活率	已经用过一次关键动作的人 / 目标用户	分母必须是目标用户群，不是开通的账号数。 账号数当分母会同时高估和低估
连续使用天数	目标用户连续使用的天数	打卡式使用会污染这个数，需要配合「关键动作完成数」一起看
主动使用率	非被要求、非被提醒情况下的使用比例	与考核绑定后这个指标立刻失真，因此加考核之前要先取基线
使用深度	关键功能的覆盖比例	只看总量会掩盖「所有人都只用最浅的那个功能」
解决率 / 分流率	系统独立完成的比例	必须同时问三件事：分母是什么、判定窗口多长、谁来判定。ServiceNow 的公开口径要求一次分流成立需同时满足 24 小时内未提交工单且出现正向参与信号

关于最后一行，范冰在附录 A 里给了一句值得直接引用的判读纪律：「口径不清的 86% 不如口径清楚的 51%。」

9.3 让系统在组织里持续可见

采纳指标除了给交付方看，还有一个用途是让系统在组织里持续可见。一个低成本做法是把「谁在用、用得怎么样」做成每月自动发出的一张表，收件人包括业务负责人和他的上级。

十、组织维系：让系统活过它的推动者

企业系统流失的第二大原因是支持者离场。剧本很固定：项目由某位负责人发起，关系靠他维系，成功叙事由他代言；然后他升职、调岗或离职；继任者不反对这个项目，他只是不认识它。续约评审会上翻到系统那一页，问「这是什么」，会用的人不敢替预算说话，能说话的人没用过它。合同到期那天没有争吵也没有投诉，只是没有人发起续约流程。

对内部推动的项目，这个风险的形态更尖锐：推动者本人就是那个冠军。一仗打完他可能回原岗位或者去做下一个项目，系统留在那里。

从上线第一天就要做的四件事：

1. 业务侧要有一个「值班对接人」，而且不是交付方。 一线遇到问题第一个找的应该是他。这个人要在上线第一周定下来并公开宣布。
2. 价值口径写成文档，业务方是作者之一。 「这个系统每周省了多少小时」——这个数怎么算、谁来算、多久算一次，写下来。推动者走了，这份文档还在。
3. 系统的指标进某个人的考核表。 这一件通常需要发起人去推，对应 McKinsey 四支柱里的「正式机制强化」。
4. 把使用情况做成每月自动发出的表。

范冰在 5.5 节把防御工事概括为三处：关系网格化（一个支持者之外至少再发展两条独立关系线，检验标准是任何单个人离开信息通道都不中断）、价值组织化（把系统的价值从「某人的政绩」改写为「组织的资产」，具体动作包括把系统写进标准作业流程）、离场做成仪式（支持者离开时主动做交接，并以「帮助继任者快速出成绩」为切入点）。

十一、续约与扩大

这一节主要面向外部交付方；内部推动的项目对应的是「下一期预算」，逻辑相同。

11.1 五类流失

《前线部署工程师》第 5 章把企业客户流失归纳为五类，按可预防性排序：

类型	形态	对应防线
价值蒸发	系统还在跑，但没人记得它解决了什么问题	定期重述价值叙事；季度回顾
支持者离场	内部盟友升职、调岗或离职	组织维系（第十节）
质量漂移	业务在变、数据在变、模型在更新，输出质量缓慢下滑	线上采样 + 评估集回归（见 evaluation.md）
成本反噬	用量越大账单越高，价值叙事跟不上账单增长	成本口径与容量规划同步
供应商戒断反应	客户对被绑定的警惕	知识转移写进交付范围

第五类的证据强度需要特别说明。常被引用的「到 2028 年 70% 的企业将放弃由 FDE 主导的 agent 方案」这一说法，出处是媒体报道中一位 Gartner 分析师的个人观点，不是 Gartner 的正式预测报告，范冰本人在书中也做了同样的标注。引用时应保留这个限定。

11.2 度量「留住」的三层

• 行为层：使用率与活跃深度
• 关系层：健康度评分（使用信号 / 价值信号 / 关系信号 / 商业信号四类合成）
• 财务层：NRR（Net Revenue Retention，净收入留存），衡量同一批老客户今年比去年多付还是少付。超过 100% 意味着不签新单存量生意也在增长

一个可参照的上限：Palantir 在 2025 年第四季度财报里给出的 NRR 为 139%，剩余履约义务同比增长 145%，单季签约总合同额 42.6 亿美元（数字经媒体与中文材料转述，口径以官方财报为准）。

健康分体系最大的用处不是那个分数，是它逼着团队每周把所有客户挨个过一遍。

11.3 季度回顾的三条纪律

季度业务回顾（QBR）常被办成供应商单方面放幻灯片的例会。三条可以改变结果的纪律：

1. 讲客户的语言，不讲产品语言。 说「本季度为你们节省了多少工时」，不说「本季度我们上线了什么功能」。
2. 让客户的业务方当主角。 由支持者来讲他团队的故事，交付方提供数据弹药。
3. 以「下一季度的价值计划」收尾。

11.4 扩大的路径

从一个部门扩到一张网，公开材料里出现频率最高的三条路径是：

• 横向：同一个场景复制到别的部门、别的分厂、别的区域。这是最便宜的一条，因为 Context 大部分可以继承。
• 纵向：同一批用户的相邻场景。原料通常来自算账阶段汇报里的「过程中的发现」。
• 纵深：把系统从辅助推到自动，从只读推到写回。

BBVA 的公开扩张链路（3,300 → 1.1 万 → 12 万账号）是横向扩张的一个样本；Walgreens 先在 10 家门店试点、店内运营效率提升后八个月推到 4,000 家门店，是「先十家、后四千」的另一个样本（后者数字来自财报会披露经媒体转述，二手）。

这些数字共同的启示不是「要扩得快」，而是扩张的入场券是使用数据，不是演示效果。

十二、常见失败模式

1. 把采纳当成运营的事，不当成设计的事。 结果是做完了才开始想怎么推。
2. 用培训解决产品问题。 培训解决不了慢。
3. 用考核解决利益问题。 加考核会把一场诊断变成一场对抗。
4. 只找最配合的人当带头人。 他的认可不产生同侪影响。
5. 上线没有埋点。 之后所有关于「有没有人用」的讨论都变成立场之争。
6. 系统的组织生命只挂在一个人身上。 这个人一动，系统就进入无人认领状态。
7. 忘了给受损者设计出路。 ADKAR 的原版假设在这里失效。

延伸阅读

• build-and-mvd.md：为什么「入口必须旧」在造的阶段就要决定
• value-accounting.md：采纳数据怎么变成一笔能汇报的账
• evaluation.md：质量漂移的监测与回归
• frameworks-compared.md：各家方法论对采纳这一段的处理差异
• ../05-practice/stakeholders-and-data-access.md：干系人地图与四类人的激励结构（本页第六、七节的现场版）
• ../05-practice/anti-patterns.md：采纳类失败模式的早期信号
• ../05-practice/china-specifics.md：拍板文化、驻场与内部 FDE 的组织安排
• ../00-start/glossary.md：NRR、激活率、HEART、ADKAR 等术语
• Everett M. Rogers，《Diffusion of Innovations》，Free Press，初版 1962（通行第 5 版 2003）：意见领袖、可试性、可观察性的原始出处
• Google PAIR，《People + AI Guidebook》：AI 产品的用户体验设计模式，https://pair.withgoogle.com/guidebook/

来源

1. BCG，"The Leader's Guide to Transforming with AI"（10-20-70 原则）。https://www.bcg.com/featured-insights/the-leaders-guide-to-transforming-with-ai（该页对自动抓取返回 403）；转述见 Forbes，2026-01-26，https://www.forbes.com/sites/joemckendrick/2026/01/26/why-ais-10-20-70-principle-should-matter-to-ceos-and-everyone-else/
2. OpenAI，《The State of Enterprise AI 2025》。https://cdn.openai.com/pdf/7ef17d82-96bf-4dd1-9df2-228f7f377a29/the-state-of-enterprise-ai_2025-report.pdf
3. OpenAI，《AI in the Enterprise》（BBVA custom GPTs、法务每年 40,000 个问题）。https://cdn.openai.com/business-guides-and-resources/ai-in-the-enterprise.pdf
4. Kotter Inc.，"The 8 Steps for Leading Change"。https://www.kotterinc.com/methodology/8-steps/
5. Jeff Hiatt，《ADKAR: A Model for Change in Business, Government and our Community》，Prosci，2006；官方方法页 https://www.prosci.com/methodology/adkar（该页对自动抓取返回 403）
6. McKinsey，"The four building blocks of change"。https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-four-building-blocks--of-change
7. Everett M. Rogers，《Diffusion of Innovations》，Free Press，1962（第 5 版 2003）
8. Kerry Rodden, Hilary Hutchinson, Xin Fu，"Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications"，CHI 2010。https://kerryrodden.com/heart/
9. Google PAIR，《People + AI Guidebook》。https://pair.withgoogle.com/guidebook/
10. 范冰（XDash），《前线部署工程师》第 4 章（变革管理、降低使用门槛）与第 5 章（守住续约：五类流失、上手引导、组织维系、健康分），GitHub 开源全文，2026 年 8 月。https://github.com/xdash/FDE-the-Guidance-Book-of-Forward-Deployed-Engineer
11. 范冰，同书附录 A（指标口径纪律，含解决率/分流率与激活率分母）。同上仓库