第 11 章　上线不是终点：采用、运营与价值证明

11.1 为什么已经上线却没人用

系统上线是技术团队最有成就感的时刻，却只是用户采用的起点。

用户不用，原因可能很现实：入口不在原工作流中，需要重复登录或复制数据；系统偶尔出错，却没有说明何时可信；新工具增加了步骤，节省的时间却与个人无关；管理者要求使用，但原有考核和流程没有改变。

采用问题不能简单归结为“用户不接受新技术”。很多时候，是系统没有给用户足够价值，或者组织没有为新工作方式创造条件。

独立聊天页面适合演示，却不一定适合生产。用户每天在 CRM、工单、邮件或专业软件中工作，如果必须离开当前任务去另一个页面提问，使用成本会不断积累。

更有效的方式，是让 AI 在合适节点出现：打开工单时呈现相关信息，会议结束后生成待确认纪要，提交合同前提示风险，处理告警时给出排查建议。

系统还应尽量读取已有上下文，减少重复输入，并在确认后把结果写回原流程。最好的 AI 有时不是醒目的新产品，而是原有工作少了几个麻烦步骤。

培训不能只教按钮在哪里。用户需要知道系统擅长什么、容易在哪些情况失败、怎样查看来源、何时必须人工确认，以及发生问题向谁反馈。

为了推广而隐藏限制，用户会在第一次严重错误后失去信任。明确边界反而有助于建立稳定预期。

培训还要按照角色进行。管理者关心指标与风险，实际用户关心怎样完成任务，IT 和运维关心权限、监控和故障处理。

反馈应尽量靠近使用现场。简单的采纳、修改、拒绝和问题分类，比要求用户另写长篇意见更容易持续。

系统可以记录用户是否采用建议、在哪一步修改、哪些问题进入人工队列。这些数据既帮助改善模型，也能发现流程设计问题。

人工接管不能成为无人负责的黑洞。要明确由谁接收、多快响应、处理结果是否回到系统，以及同类失败是否进入评测集。

技术指标回答系统表现如何，业务指标回答项目是否值得存在。

准确率提高，可能没有减少处理时间；生成速度更快，可能因为用户不信任而全部重新检查；活跃人数增加，也可能只是管理要求下的短期行为。

价值证明要连接四个层次：系统是否可靠，用户是否采用，工作方式是否改变，业务结果是否改善。

业务结果可以是时间缩短、返工减少、质量提升、转化提高、成本下降或风险降低。指标要说明样本、周期和其他影响因素，避免把所有好处换算成夸张金额。

扩大之前，应确认核心任务表现稳定，用户持续使用，运维责任明确，新增规模不会突破权限、成本和容量边界。

扩张最好一次只改变一个维度：先增加同类用户，或者先增加相邻任务，不要同时改变用户、流程、数据和架构。这样出现问题时才能知道原因。

如果使用率持续下降、核心错误无法控制、业务指标没有变化，或者运行成本明显超过收益，就应该暂停。继续增加功能很少能修复一个没有价值基础的项目。

FDE 不应成为系统永久依赖的唯一专家。试点阶段就要确定未来由谁维护业务规则、知识内容、权限、模型配置、评测集和基础设施。

交接不只是发送文档，还包括权限移交、故障演练、版本发布、联系人和服务边界。长期团队需要能够独立完成常见操作，并知道什么问题需要升级。

如果每次知识更新或模型异常都必须找最初的 FDE，说明系统还没有真正进入组织。

可信的项目故事不从“我们使用了先进模型”开始，而要说明原流程有什么问题，为什么选择这个场景，做了哪些关键取舍，系统如何进入工作，用户怎样采用，指标发生了什么变化，以及哪些问题仍未解决。

失败和调整也是故事的一部分。它们能说明团队如何根据事实决策，比一条从未受阻的成功叙事更有价值。

上线不等于落地。系统必须进入原工作流，让用户理解能力边界，建立低成本反馈和有效人工接管，再把技术表现连接到业务结果。

当项目被证明有效，下一步不是无限增加定制，而是判断哪些现场经验值得沉淀，避免成功项目在扩张中变成成本黑洞。