第 5 章　场景筛选：找到最小业务结果

5.1 不是所有问题都需要 AI

业务发现会带回很多问题，但问题真实存在，不代表都适合用 AI 解决。

企业最容易犯的错误，是先决定使用大模型，再寻找能够容纳它的场景。这样做出的方案可能技术上成立，经济上却不合理；可能在演示中聪明，进入生产后反而增加风险。

FDE 的第一项技术判断，有时就是不用 AI。

如果规则明确、输入结构化、结果必须完全确定，普通程序通常更可靠；如果只需要按关键词找到准确文档，传统搜索可能更便宜；如果任务只是跨系统复制固定字段，RPA 或接口集成更合适；如果流程本身混乱，先重整流程往往比增加智能层有效。

AI 更适合处理语言、图像和非结构化信息，需要理解上下文、生成草稿、归纳判断或应对一定变化的任务。即便如此，高风险决定仍可能需要规则约束和人工确认。

成熟的方案通常不是“全部 AI”，而是规则、检索、工作流、传统软件和模型的组合。

5.2 用六个维度筛选场景

一个适合起步的场景，应同时具备价值和可行性。可以从六个维度判断。

价值

问题是否正在造成真实代价？这种代价可以是时间、成本、收入、质量或风险。如果只是“看起来不够先进”，项目通常缺少持续推动力。

频率

问题多久发生一次？高频、重复的工作更容易积累收益，也更容易获得足够样本进行评测。低频任务并非不能做，但单次价值必须足够高。

数据

完成任务需要哪些数据？数据是否存在、质量如何、能否合法取得、是否有人维护？“公司有很多数据”不等于项目拥有可用数据。

风险

错误结果会造成什么后果？内部草稿写得不好，可以由员工修改；自动批准贷款、给出诊疗建议或控制生产设备，容错空间完全不同。风险越高，验证、权限和人工介入成本越大。

可集成

系统能否在需要的时间读取信息，并把结果送回用户工作的地方？如果必须依靠大量手工复制，或者关键系统没有任何可用接口，项目价值可能被操作成本抵消。

可衡量

上线前是否知道当前基线？上线后能否观察时间、质量、采用或业务结果的变化？无法衡量并不等于没有价值，但会让验收和后续投资变得困难。

六个维度不是为了计算一个看似精确的总分，而是暴露薄弱环节。一个价值很高却拿不到数据的场景，仍然无法启动；一个容易实现却无人关心的场景，也不会产生影响。

5.3 从大愿景缩小到业务闭环

企业提出的 AI 目标经常很大：“建设智能销售平台”“实现全流程自动化”“打造企业级知识大脑”。这些可以作为长期方向，却不适合作为第一个项目的边界。

缩小范围不是把一个大系统随意切出几页功能，而是找到一段能够独立产生结果的业务闭环。

一个闭环至少包括：明确的触发事件、可获得的输入、具体使用者、系统产生的动作、必要的人工确认、结果回到业务流程，以及可以观察的指标。

例如，“提高销售效率”不是闭环；“销售拜访后，根据录音和 CRM 信息生成结构化纪要，由销售确认后写回系统，并把遗漏的下一步行动提醒给负责人”才接近闭环。

范围可以通过几个方向继续收缩：

• 从整个公司缩到一个部门；
• 从所有用户缩到一类角色；
• 从全流程缩到一个高频节点；
• 从自动执行缩到生成建议并由人确认；
• 从所有数据缩到一个质量较好的数据源；
• 从长期平台建设缩到几周内可以验证的结果。

小不是目的。最小范围仍然要完成一段真实工作，否则只是把大型演示变成小型演示。

5.4 先验证最危险的假设

很多团队喜欢先做界面，因为界面最容易展示进度。但项目真正的风险往往藏在别处：能否取得数据，模型是否能处理真实输入，权限能否正确隔离，用户是否愿意改变操作方式，关键系统是否允许写回。

第一个原型应该优先验证最可能让项目失败的假设。

如果最大风险是手册版本混乱，就先验证能否识别有效版本；如果最大风险是模型会泄露跨部门信息，就先做权限测试；如果最大风险是用户不愿意改变流程，就先用人工模拟服务验证他们是否真的需要这个结果。

有时最好的原型甚至不需要完整开发。团队可以先由人按照未来系统的方式完成任务，观察用户是否采用、结果是否有价值。只有价值被验证后，再自动化背后的步骤。

这种顺序看起来不如漂亮界面有成就感，却能更早发现项目不成立，从而节省最多成本。

5.5 明确这次不做什么

项目范围失控，往往不是因为原目标不清楚，而是没有写清楚什么不在范围内。

一个试点可以支持某一类产品，却暂不覆盖全部产品线；可以生成回复草稿，却不自动发送；可以读取历史工单，却不修改主数据；可以验证业务效果，却暂不满足大规模并发。

“不做清单”有三个作用。

第一，它保护交付时间，让团队集中验证核心假设。第二，它管理客户预期，避免不同人员对“完成”有不同想象。第三，它让未来扩展有依据：被排除的事项可以在核心结果成立后重新评估，而不是在试点中不断插入。

FDE 说“不”不是拒绝客户，而是让客户更快知道什么值得先做。

5.6 定义最小业务结果

最小业务结果不是“完成一个机器人”“上线一个知识库”或“支持十个功能”。这些都是交付物，不是结果。

一个有效的结果描述，至少要说明：谁在什么流程中使用，哪项表现发生变化，在多大范围和时间内观察，以及必须遵守哪些护栏。

例如：

在六周试点中，让 20 名售后客服使用带来源引用的故障建议，将平均资料查找时间降低 30%，同时确保跨客户数据不可见，涉及安全操作的建议全部由工程师确认。

这句话同时包含用户、流程、时间、指标和边界。即使最终没有达到目标，团队也能知道差距在哪里，而不是用“系统已经上线”宣布成功。

最小业务结果还有一个重要作用：把客户与交付团队放到同一侧。系统建设方负责技术和交付，客户则需要提供真实用户、数据、反馈和流程支持。业务结果不是供应商单方面能够制造出来的。

5.7 从基线到业务结果

要证明变化，首先要知道改变之前是什么状态。

基线指标描述项目开始前的现实，例如平均处理时长、转派率、一次解决率、错误率或人工成本。没有基线，任何提升都缺少参照。

技术指标描述系统自身表现，例如检索命中率、回答正确率、延迟、调用成本和权限错误率。它们帮助团队改善系统，却不等同于业务价值。

领先指标比最终结果更早出现，例如试用人数、每周使用频率、建议采纳率和人工接管率。它们能提示项目方向是否正确。

业务结果指标描述流程最终变化，例如处理时间、返工、收入、成本、满意度或风险事件。

四类指标要连成逻辑：系统表现改善，用户愿意采用，工作方式发生变化，业务结果才可能出现。如果其中一环断开，就要重新检查问题定义。

5.8 什么时候应该停止

停止条件与成功标准同样重要。

以下情况出现时，团队应该暂停或重新定界：关键数据无法合法取得；真实用户无法参与；错误风险高于可接受范围；接入成本明显超过潜在收益；核心任务在真实样本中长期达不到最低要求；客户内部没有人对结果负责。

停止不等于失败。及早证明一个方案不值得继续，是 FDE 为客户创造的价值之一。真正昂贵的失败，是团队明知基本假设不成立，仍因为已经投入时间而继续扩大项目。

停止之后也不一定什么都不做。可以缩小用户范围，把自动执行改为人工确认，先治理数据，或者用传统软件解决其中确定的部分。

本章小结

场景筛选的目的，不是从问题清单中挑出最像 AI 的项目，而是找到价值真实、数据可得、风险可控、能够接入并且可以衡量的一段业务闭环。

先判断是否真的需要 AI，再从大愿景收缩到最小业务结果；先验证最危险的假设，再决定是否扩大投入；同时明确不做事项和停止条件。完成这些判断后，技术选型才真正有了依据。