Appearance
小团队内部 AI 工具的采纳度量：覆盖率优先于频次
第二部 · Agent 实践 · 第26章
撰写日期：2026-07-10
结论
给一个内部团队 AI 工具做数据看板时，我第一版盯的是调用总次数和 token 消耗——很快发现这组指标会骗人：几个重度用户能把总量拉得很好看，而团队里可能一半人从没打开过。对一个还在证明自己"值不值得学"的内部工具，这是致命的盲区。
内部 AI 工具的第一指标不是频次，是覆盖率：目标人群里有多少人真正用过。核心问题从"用了多少次"变成"N 个人里还有谁没用过"。
1. 覆盖率 vs 频次：先回答哪个问题
| 频次视角 | 覆盖率视角 | |
|---|---|---|
| 指标 | 总调用数、token 量、DAU 峰值 | N/M（M 人里 N 人用过）、谁没用过 |
| 回答的问题 | 重度用户爱不爱用 | 这个工具值不值得团队学 |
| 覆盖率 <50% 时的动作 | 优化重度用户体验 | 找出没用的人、降低上手摩擦 |
| 失败模式 | 少数人撑起漂亮总量，多数人静默流失 | —— |
我的判断：覆盖率低于一半时，产品还处在"值不值得学"阶段，此时该做的是降摩擦，不是优化 power user。 只有覆盖率上来了，频次和留存才是有意义的下一层指标。这本质上是把 PMF / Retention 的问题，搬到了一个十人量级的内部场景里问。
2. 关键指标是"谁没用过"，而不是"用了多少"
一个具体到能驱动行动的指标长这样：团队采纳 N/M（点名谁还没用过）。它的两个设计要点：
- 落到人，不落到数。"9 人中 6 人用过"只是现状，"还有 A、B、C 没用过"才能驱动下一步——去问这三个人卡在哪。
- 剔除 owner/自己。工具的建设者天然是重度用户，把自己算进覆盖率会系统性地高估采纳。度量分母应是"目标用户"，不含建设者。
3. 埋点：永久账 + 卡内实时计数
度量能不能做准，取决于事件有没有被可靠地留下来。两条经验：
| 机制 | 设计 | 为什么 |
|---|---|---|
| 永久事件账 | 每次交互追加写入一份 append-only 明细（如 jsonl），与聚合结果分离 | 聚合可以随时重算口径；易失的内存计数一旦口径改了就无法回溯 |
| 卡内实时计数 | 在推送卡片里内置按钮，点击即埋点、实时回写计数 | 把"有没有人真的看/用"变成可度量事件，而不是靠猜阅读量 |
原始明细和聚合视图要分层：先留全量原始事件，再在其上算指标。指标口径几乎一定会变（要不要算 owner、按人去重还是按次），只要原始事件在，换口径就是重算；如果只存了聚合数，改口径等于数据永久丢失。
4. 覆盖率报表怎么用
覆盖率不是给自己看的虚荣数字，它要变成每天的行动输入：
- 日报里直接给出 N/M 和未覆盖名单，让"谁还没上车"一眼可见；
- 对未覆盖的人，逐个了解摩擦点（不知道怎么用 / 不知道有这个 / 用了一次没用起来），这三类对应完全不同的产品动作；
- 把新成员加入时的"首次使用"设成一个显式事件——否则新人从加入那天起就静默地拉低覆盖率而无人察觉。