5
运营期
Operations模型会漂移、用户会越界、底层模型会版本更迭，怎么让产品在长尾运营期保鲜？
与传统项目的关键差异
运营期是传统 PM 经验最容易失效的地方。传统软件交付后进入 BAU 维护模式；AI 产品交付后进入的是持续演进模式——评测集要随用户行为补充、提示词要随业务规则调整、底层模型一旦升级就要重做回归测试。
这一阶段还要正视一件事：每个 AI 系统都有退役的一天。可能因为更好的模型出现、可能因为业务下线、可能因为合规要求变更。退役不是收尾流程，是一个需要预先设计的阶段，特别是数据销毁与用户告知。
核心交付物
- 模型与提示词漂移监控方案
- 用户反馈回流到评测集的闭环机制
- 模型升级与迁移决策框架
- 退役与数据销毁流程
常见坑
- 把 AI 产品当传统软件维护，不做持续评测
- 底层模型静默升级，未触发回归测试
- 没有用户反馈回路，无法发现真实边缘场景
- 退役无预案，数据销毁流程不合规
阶段通过条件
运营期健康标准
满足以下条件表明产品处于健康运营状态：
- 漂移监控运行正常：模型输出质量监控看板可访问，漂移率 ≤ 设定阈值，超出时自动告警
- 反馈回流闭环建立：用户反馈每周至少更新一次评测集，新增边缘案例纳入回归测试
- 模型升级决策框架就绪：底层模型版本变更时自动触发全量回归评测，升级决策有明确的准入线
- 退役预案已备案：包含数据销毁流程、用户告知模板、服务迁移方案，且经过合规审核
- 漂移监控运行正常，超出阈值自动告警
- 反馈回流闭环建立，评测集每周更新
- 模型升级决策框架就绪，升级自动触发回归
- 退役预案已备案（含数据销毁 + 用户告知）
技术指标 → 业务指标对照
将技术监控指标映射到业务可感知的成果，让运营决策有业务视角。
| 技术指标 | 对应业务指标 | 关联工序包 | 映射逻辑 |
|---|---|---|---|
| 准确率 / 答对率 | NPS、用户满意度 | 漂移监控 | 准确率每降 5%，NPS 下降约 ___ 个点 |
| 响应延迟（P95） | 任务完成率、用户留存 | 漂移监控 | 延迟 > 3s，任务完成率下降 ___% |
| Token 消耗 / 成本 | 运营成本、毛利率 | 模型升级决策 | Token 成本占运营预算的 ___% |
| 漂移率 / 新型错误率 | 工单数量、客服成本 | 反馈回流 | 漂移率上升 → 工单量增加 ___% |
使用建议：定期（建议月度）填写具体数值，建立技术→业务的因果基线。
当技术指标告警时，同步评估业务影响，避免只看技术数据做决策。
基线建立方法：连续 3 个月同时追踪技术指标（准确率/延迟/成本/漂移率）和业务指标（NPS/完成率/工单量），将每月数据填入映射逻辑列，观察相关性。
基线建立方法：连续 3 个月同时追踪技术指标（准确率/延迟/成本/漂移率）和业务指标（NPS/完成率/工单量），将每月数据填入映射逻辑列，观察相关性。