1. 车间全量推了两周，用的人只剩三个
一家装备制造企业做了一个设备点检与报修助手。设备点检员每天要走一圈，把设备的温度、振动、油位记下来，异常了走报修流程。助手能帮他们对着标准判断是否异常，也能直接把报修单填好。
第一版做完，直接在总装车间全量推给三十个人。厂里开了个一小时的培训会，讲完就上线了。
两个星期之后，还在用的只剩三个人。设备科回头一条条问，原因集中在三处。
培训没记住。一小时的会讲了十几个功能，散会之后没人记得住第一步点哪里。年轻人还能自己试出来，四十岁以上的点检员当场就放弃了。
多了一道手抄。点检表填在设备管理系统里，助手在对话窗口里给的结论，得自己看一眼再抄进表里。原来直接填表，现在多一步，抄错还得返工。
班组长不认。「点检这活靠的是手上的经验，机器哪知道这台设备有点闷。」班组长是这个班组里最有话语权的人，他不用，下面的人更不会用。
毛病出在三个地方：怎么推、推给谁先试、以及推出去之后怎么知道有没有人真在用。
2. 从试用到上线要过几道
2.1 四个阶段
一个应用从做完到全量用起来，中间有四个阶段，每个阶段的目的不一样。
内部验证是产品经理和研发自己用，确认基本功能跑得通、明显的问题没有。这一步不看使用率，只看功能是否按预期工作。
种子用户试用是找几个愿意提意见的人，用一到两周，重点是听他们的真实反应和真实问法。
单部门试点是找一个部门完整用起来，用三到四周，重点看它在这个部门的真实流程里能不能跑通、能不能省时间。
全量推广是把范围扩到所有该用的人，重点从「它好不好用」转向「怎么让所有人用起来」。
四个阶段不能跳。跳掉种子用户那一步，会在试点时才发现问题；跳掉试点那一步，会在全量推广时才发现流程根本接不上。车间那件事跳掉的是前两步。
2.2 每个阶段的验收点
| 阶段 | 谁来用 | 多久 | 看什么算过 |
|---|---|---|---|
| 内部验证 | 产品经理、研发 | 3-5 天 | 功能按预期工作；异常分支走通；日志能看到每一步 |
| 种子用户试用 | 3-5 个愿意提意见的人 | 1-2 周 | 他们提的问题里，一半以上是业务问题而不是功能 bug |
| 单部门试点 | 一个部门的全部目标用户 | 3-4 周 | 这个部门的某项业务指标有可测量的改善 |
| 全量推广 | 全部目标用户 | 持续 | 周活跃和一周留存达到设定值 |
第二阶段的验收点值得多看一眼：种子用户如果提的全是「按钮点不着」「页面打不开」，说明还没到能试用的程度，该退回去。
3. 试点先找哪个部门
3.1 三条选试点的标准
选试点不看哪个部门人多，看三条。
业务痛点明确。这个部门手上有一件天天要做、又确实费时间的事。点检和报修符合这一条：一圈走下来要一小时，填表和报修还得再花半小时。
关键角色愿意。部门的负责人或者班组里说话管用的人，至少有一个愿意试。这一点比前一点还重要：车间那件事里，班组长不认，下面的人就不会用。
出问题的影响可控。试点的动作不能直接影响对外交付或客户。点检记录属于内部数据，试错了不影响发货。
三条里有一条不满足，换一个部门，不要硬推。
三条标准在不同行业里的表现不一样。制造业选试点最容易，车间和班组边界清楚，一个班组就能划成独立的试点范围；政务大厅难一些，窗口的业务是串起来的，只试一个窗口会牵连到上下游；金融机构最麻烦，业务动作的合规要求高，试点范围往往要法务和风控一起点头。行业越重合规，试点的范围就要选得越小、试的时间越短，先把「能不能用」验出来，再谈「好不好用」。
3.2 试多久
三到四周。短了看不出一件事的真实使用频率，长了投入太大、结论也未必更准。
拿点检这件事说：点检每天一次，三周下来能看到二十个工作日的数据，足够判断留存和使用习惯。如果某件事一个月才做一次，试点就要相应地放到两个月，不然数据量根本不够。
3.3 看什么指标
试点阶段只看三件事：这个部门有没有真的用起来、那件事的时间有没有省下来、有没有人明确反对。
第一条看周活跃和完成次数。第二条看处理时长的变化，比如点检一圈从九十分钟降到七十分钟。第三条关键是反对的人是谁：如果是具体用的人，是产品问题；如果是班组里的关键角色，是推广问题，得先把他拉进来。
前面讲过的五层指标在这里不用全跑，跑结果层和效率层就够；风险层和可靠性层在内部验证阶段已经过过了。
4. 种子用户找谁
4.1 找三种人
种子用户是种子用户试用阶段的参与者，找三种人。
愿意提意见的人。他在用的时候会主动说「这里不对」，这种人最有价值。
熟练的老手。他对这件事的门道最清楚，也最容易看出助手给的东西是不是外行。
刚上手的新人。他不知道老一套的做法，反而更容易接受新的方式，能测出这个东西对新人有多好懂。
三种人各找一到两个，凑够三到五个就够。找太多，意见会很散。
4.2 问题怎么收
收集问题要有固定的去处。常见做法是三处并行：对话里给一个「这次结果不对」的按钮，点一下自动带上上下文；每周一次半小时的线上碰头，让种子用户当面说；再配一个群，随手发截图。
三个去处收集到的东西，每周汇总一次，按「业务问题」「功能 bug」「用法不懂」分三类。分类的意义在于处理的归属不同：业务问题找业务方确认，功能 bug 排进研发，用法不懂多数是设计没做清楚，需要改界面或补引导。
5. 发布渠道和回滚
5.1 从哪几个入口放出去
一个应用可以有几个入口，放出去的时候要选。
独立网页是最简单的入口，发一个链接，用户收藏就能用。
嵌在业务系统里，用户本来就在用的界面里多一块。车间那件事的关键改动就是把助手嵌进点检表页面，结论能直接落进表里，不用手抄。
挂在企业微信或内部工作台上，用户不用记地址，从工作台点一下就进来。
选入口的原则是「用户原来在哪做这件事，就在哪给他」。多开一个入口，就多一次让用户切换的成本。
5.2 版本怎么管
版本要能对应到人。做法是每次发布记三样：版本号、发布范围、发布时间。有了这三样，出问题的时候能查出来哪些人受影响。
灰度发布是把新版本先放给一小部分人：先给一个班组，观察两三天没问题再往前推。出问题的时候影响面小，回滚也快。
5.3 出问题退到哪儿
回滚要提前想清三件事：退回哪一版、退回去的时候数据怎么办、是谁决定退。
退回哪一版要写具体版本号，不能写「退回上一版」。连着发两次的时候，「上一版」是哪个说不清。
数据这件事最容易被漏。新版本可能已经产生了数据，直接退回去可能出现「界面是旧版、数据是新版」的情况。稳妥的做法是退版本不退数据，或者两者一起回。
谁决定退要落到人。常见做法是产品经理或值班的人可以在十分钟内决定停机；不停机但要回滚的，需要跟业务方一起定。
一次回滚要走的三步
- 正在发的版本
v1.4.2，新增了图片上传 - 要退到的版本
v1.4.1，上一个稳定版 - 不能写的那种说法退回上一版；连着发两次的时候，上一版是哪个说不清
版本号写具体，值班的人照着执行就行。
- 新版已经产生的数据点检记录 312 条
- 稳妥的做法退版本不退数据，新记录留着
- 要一起退的时候先导出一份留档，再动
- 最容易漏掉的情况界面退成旧版、数据留在新版，两边对不上
退版本和退数据是两件事，分开写清楚。
- 十分钟内要决定的产品经理或值班的人可以直接停机
- 不停机但要回滚的跟业务方一起定，写清谁发起、谁点头
- 上线头两周每天巡检一次，异常当场处置
决定权落到人头上，出事的时候不用现场再找。
回滚方案在发布之前写好，别等出事再商量。
6. 怎么看它有没有被真的用起来
6.1 使用率不等于开通率
开通了账号不等于在用。工厂那边开通一百二十个账号，第一版周活跃只有三十四个人。
看使用率要分三层。第一层是开通数，第二层是周活跃数，第三层是「真的用它完成了一次完整的业务动作」的人数。工厂那边的对应数字是一百二十、三十四、二十六。
第三层才是最该看的。打开页面看一眼又关掉，不算用起来。
6.2 留存的三个口径
留存看三个时间点：次日、七日和三十日。
次日留存看的是第一印象；七日留存看的是它有没有进入日常习惯；三十日留存看的是这件事是不是真的留下来了。
工厂那套数字对比很直观：第一版是四成一、两成二、一成二；改版之后是七成八、五成四、四成一。三十日留存从一成二涨到四成一，是整个改造里最说明问题的一个数。
留存怎么算要写清口径：当天用过的算活跃，第二天还用过算次日留存。中间断了两天又回来的算不算，口径里也要写。
同一批用户，几个口径算出来的数不一样
左边 · 改版之前
- 开通 120 人周活跃 34 人 · 完成一次完整动作 26 人 · 一周留存 12%
- 完成一次点检的 26 人里用助手填表成功的是 19 人，其余 7 人是打开助手看过结论之后自己填的表
- 这 7 个人算不算用起来要跟业务方定口径
- 这一集的底数全厂 120 人、试点 9 人 3 周，点检一圈从 90 分钟降到 70 分钟
开通说明不了什么，周活跃里有一部分只是打开过。
右边 · 改版之后
- 开通 120 人周活跃 78 人 · 完成一次完整动作 61 人 · 一周留存 41%
- 留存三个口径跟着变次日 41% 到 78%，七日 22% 到 54%，三十日 12% 到 41%
- 第 7 天还有 54 人在用改版前是 22 人
- 把定义放宽第三张卡从 61 涨到 74，数字好看了，活没多干
- 留存口径要写清三件事当天用过的算活跃，第二天还用过算次日留存，中间断了两天又回来的算不算也要写
三十日留存从一成二涨到四成一，是这套改造最说明问题的一个数。
三十日留存从一成二涨到四成一，是这套改造最说明问题的一个数。
6.3 只打开不用是怎么看出来的
只看打开次数会误判。判断方法是对齐两个数：打开次数和完成动作的次数。
两个数差得远，说明大部分人点进去看两眼就走了。常见原因有两个：第一眼没看懂它是干什么的；或者它答的东西用户拿不到手里用。
车间那件事两个原因都占了：培训没讲清，它给的结论又要手抄一遍。
7. 培训没人听、用两天就回去怎么办
这三种情况各有各的解法。
培训没人听。问题通常不在培训本身，在形式。一小时的会讲十几个功能，散会就忘。可行的做法是把培训拆成「现场十分钟、一个人、教一个动作」：就在他的工位上，教他完成今天最想省的那一步，教完让他自己走一遍。一百二十个人听着多，分到几个班组长身上，每人带十几个，一周能带完。
用两天就回去了。常见原因是新方式比老方式多了一步。车间那件事的手抄就是典型：多一步，人就会退回去。解法落在把那一步去掉上，靠提要求压不住，得让它直接落到原来的表里。
只看不用。有的人会打开看一眼，但真干活还是走老路。这一类要看他的顾虑是什么：是不信它的判断，还是怕担责任。不信，就把依据摆出来；怕担责，就把责任划清楚，比如「助手的结论是参考，签字还是你签」。
还有一条通用的做法：每个班组配一个内部帮手。这个人是班组里的人，不是信息科的。别人不会用的时候问他一句就行，比找 IT 快得多。
这三件事有先后：先把「多一步」去掉，再解决培训，最后处理不看不用。顺序反了，培训讲得再好，人一上手发现比原来麻烦，还是不会用。
8. 车间这次推广怎么推开
设备科把推广重做了一遍。
试点不再全车间推，先选两个班组共九个人，试三周。这两个班组是设备科自己挑的：一个班组长本来就嫌填表麻烦，另一个班的老师傅愿意说真话。
助手从独立网页改成嵌进点检表页面。点检员打开表，助手就在旁边，结论点一下直接落到对应的格子里，不用手抄。这一处改动是整件事里最关键的一步。
培训改成了现场十分钟、一个人、教一个动作。一百二十个人由四名班组长分担，每人带十几个。每个班组还配了一名内部帮手。
发布走灰度：先给两个试点班组，两天没问题再给整个车间，一周之后放到全厂。发布记录里写明版本号、范围和时间的对应关系。
回滚方案也定了：退回哪一版写具体版本号，退版本不退数据，值班人可以在十分钟内决定停机或回滚。
改版之后的数字：周活跃从三十四人涨到七十八人，真正用它完成一次点检的有六十一人；一周留存从百分之十二涨到百分之四十一；三十日留存从百分之十二涨到百分之四十一。点检一圈的时间从九十分钟降到七十分钟。
那位一开始不认的班组长后来成了内部帮手之一。设备科的说法是「他自己算了一下，一圈省二十分钟，一天省下来的时间够他下午早点收工」。
9. 推广方案怎么定下来
| 问题 | 答「否」的时候怎么办 |
|---|---|
| 这次推广走到哪个阶段，上一个阶段的验收点过了吗？ | 没过的退回去补，别往下跳 |
| 试点选的是哪个部门，三条标准都对上了吗？ | 有一条对不上的换部门，别硬推 |
| 试点看哪三个指标，目标值定了吗？ | 没定的先定：周活跃、处理时长、反对的人是谁 |
| 种子用户找了哪三种人？ | 缺哪一种补哪一种，凑够三到五个 |
| 发布走不走灰度，回滚退到哪个具体版本？ | 补上版本号、数据处置、决策人三样 |
| 使用率看哪一层，留存口径写清了吗？ | 至少看到「完成一次完整动作」这一层 |
| 培训是不是按「一个人、十分钟、一个动作」拆的？ | 还是大课的话改成现场逐人带 |
10. 推广里最容易跳过的几步
一上来就全员推。 三十个人里最后剩下三个，返工的成本比先试点的成本高得多。先在两个班组试三周，试出来的问题在这一步改，代价最小。
只统计开通人数，不看实际使用。 开通数是后台点的按钮，跟有没有人用没关系。要看周活跃，更要看「完成一次完整动作」的人数。
用户反馈收上来没人处理。 收问题的群建了，问题攒着没人看，第二周就没人再提了。反馈要有固定的汇总节奏和归属：业务问题找业务方，功能 bug 进研发，用法不懂改界面。
11. 正课到这里结束，最后一集转面试
推广这一段要能答上四个问题：先在哪个部门试、试多久看什么指标、种子用户找哪几种人、发布之后怎么退回去。使用率要看到「完成一次完整动作」那一层，培训拆成现场十分钟一个人一个动作。
到这里，一路跟下来攒的东西齐了：智能体组成图、训练与微调对照表、模型类型速查表、选型表、运行与成本方案、外壳工程组成图、上下文预算表与提示词模板、技能包规范、工具接入清单、入库与检索规范、分工设计图、编排方案表、人工确认点清单、数据集规范、隔离与配额清单、权限与安全清单、平台能力清单、体验设计清单、PRD 模板与验收清单、评测标准与评测集、推广方案。
这些东西不只是作业。面试的时候，被问到「你怎么评估一个场景该不该上智能体」「你怎么定验收标准」「你怎么证明它好用」，答出来的就是这一路做的判断。最后一集讲人工智能产品经理的面试：招聘要求里反复出现哪几条、技术理解题和场景题怎么拆、选型和成本怎么答、以及怎么用这些材料讲清楚自己做过的事。