指标一：任务成功率
按任务类型分别统计，而不是算一个总数。为什么分开：不同任务的难度与错误代价差别很大，混在一起会被简单任务拉高。做法是先定义什么算成功，比如输出被完整采纳，或仅做格式修改，口径要在上线前书面约定。
指标二：接管率与原因
接管率本身不是越低越好，要看接管原因。低接管但错误流出，比高接管更危险。怎么做：把接管原因分类统计，若集中在某类问题，说明该场景还不适合自动处理，应缩范围而不是继续调提示词，把风险留在可控区间。
指标三：异常处理时长
从异常发生到人工处理完成的时间，反映值守是否有效。为什么重要：客户感知的是等待，而不是模型准确率。做法是按小时段统计，找出高峰与无人值守的时段，据此排班，并在月报里注明最长等待与超时次数。
指标四：回滚次数与影响面
记录每次回滚的原因、影响用户数与恢复时间。回滚多不一定是坏事，说明团队敢在出错时止损；但回滚原因重复出现，说明上线前检查不到位。边界是回滚预案必须提前演练，不能等出事时第一次使用。
指标五：真实使用率
看目标用户中有多少人真正在用、每周使用频次与放弃率。为什么单看调用量会误判：调用可能来自测试脚本或批量任务。做法是区分真实用户与系统调用，并按岗位看使用差异，找出推广不到位的环节。
适用与不适用
适合谁
- 已上线、需要向管理层或客户说明运行情况的项目
- 准备扩大使用范围、需要判断依据的团队
- 正在设计上线观察期指标的产品负责人
不适合谁
- 只用演示数据评估、尚未进入真实业务的项目
- 要求用单一指标证明上线成功的决策者
典型场景
一家连锁药房的用药提醒助手灰度上线后，运营每周统计五项指标，发现任务成功率不低，但夜间接管平均等待超过四十分钟。排班调整后等待时间下降，团队才扩大门店范围；同时把回滚原因整理成检查项，第二个月没有出现同类问题。
可执行步骤
- 上线前书面约定成功、接管与异常的口径，双方签字确认，口径写入验收单
- 按任务类型分别统计成功率，不用一个总数对外说明，拆分到具体场景
- 把接管原因分类，找出暂不适合自动处理的场景并缩范围，而不是反复调提示
- 按小时段统计异常处理时长，据此排班并记录超时次数，每月复核一次
常见坑
- 用演示数据当上线效果，向客户承诺后无法兑现，解释成本高于项目本身，后续合作也受影响
- 只报总成功率，掩盖某类任务持续出错，问题在扩量后集中爆发，届时已难区分原因，投入难以回收
- 接管原因不分类，看到数字下降就以为改好了，实际是用户放弃使用，指标再好看也没用，真实问题被掩盖
- 回滚不记录影响面，无法判断是否该继续放量，决策只能凭感觉，复盘也缺依据，同类问题再次发生
自检与验收清单
- 成功率是否按任务类型拆分统计，口径是否书面
- 接管原因是否分类并可追溯到场景，是否按月对比
- 异常处理时长是否按时段统计，超时是否记录
- 回滚是否记录原因、影响面与恢复时间，是否有复盘
常见问题
上线多久才能看出效果
至少观察四周，覆盖一个完整业务周期。太短会把偶发波动当趋势，太长则失去调整时机；四周后仍不稳定的场景，应先缩范围，而不是继续增加指标解释，否则数字越多越看不清。
接管率高说明系统不好吗
不一定。接管高可能说明范围设得保守、风险控制得当；关键看接管是否及时、是否集中在少数场景。若接管长期高且无下降趋势，才需要重新评估场景选择。
这些指标能写进对外材料吗
可以写口径与方法，不写具体提升比例。客户环境不同，同一套指标的结果差异很大；把统计方式与观察周期写清，比给一个漂亮数字更经得起追问。被追问时也更容易自圆其说。