走出 Pilot Purgatory：让试点有下一步

选择一个足够窄的楔子场景

试点的目的不是证明 AI 什么都能做，而是验证一个小而真实的闭环。好的楔子场景通常有三个特征：使用者集中、流程重复、结果能在两周内观察。比如只服务一个区域的销售主管、只处理一个类型的审核任务，或只覆盖工单流转中的某一段。

范围越窄，越容易看清问题来自模型、数据、流程还是入口。相反，如果第一版就承诺覆盖所有团队和全部例外，团队会把大部分时间耗在边界条件上，却得不到任何采用证据。

把采用当作产品能力的一部分

采用并非培训结束后自然发生。FDE 应当在设计时就回答：建议在哪里出现？它能否直接进入用户原有系统？用户纠正一次要花几步？遇到例外时能否迅速回到人工流程？这些决定了工具是额外负担，还是工作流的一部分。

每周找几个真实用户回看实际记录，比一次大型汇报更有效。问他们哪一次建议真正省了时间，哪一次让他们不敢相信，以及在什么情况下他们干脆没打开它。反馈应当变成下一周的优先级，而不是一份被归档的访谈纪要。

在开始时约定扩展门槛

试点开始前，就应和业务 Owner 约定下一步的条件。达到怎样的采用率？减少多少等待或返工？风险事件处于什么范围？扩展后谁维护提示词、规则、权限和知识源？如果这些问题留到试点结束才问，往往已经失去了推动资源的窗口。

• 01可复用：流程是否能复制到相邻团队，而不需要从头重做？
• 02有 Owner：谁对业务结果、内容与权限持续负责？
• 03有证据：是否已经积累了采用和结果的量化记录？

FDE 的交付不止是一个上线的原型；更重要的是让组织拥有继续使用、维护和扩展它的能力。