4 从 AI 愿景到场景优先级

4.1 企业不缺想法，缺少可比较的选择

当管理层提出“全面拥抱 AI”，各部门很快会产生长长的需求清单：智能客服、经营分析、合同审查、销售助手、代码生成、设备预测、自动报表、知识问答。问题通常不是没有场景，而是每个场景都被描述得同样重要。业务部门强调价值，技术团队强调可行性，安全团队强调风险，最后要么谁声音大谁先做，要么先建设一个通用平台，希望未来自然承接所有需求。

场景优先级的目的，是把愿景转化为可以比较的投资组合。它不是选出“最酷的 AI”，而是找到能够在合理时间内证明价值、积累可复用能力且风险可控的切入口。一个好场景既要有业务牵引，也要能形成数据与反馈闭环。

选择错误的第一个场景会产生两种后果。过于简单的场景容易做出演示，却无法证明对核心业务的影响，组织因此把 AI 当作新奇工具；过于复杂的场景则需要同时解决数据、流程、系统和组织问题，团队长期无法上线，组织因此认为 AI 不成熟。第一阶段应寻找“足够重要但边界可控”的任务。

4.2 从部门愿望改写为用户任务

“建设智能知识库”不是场景，它是预设方案。“帮助售后工程师在客户现场快速确认适用于当前设备的故障处理步骤”才是场景。前者没有用户、时机和结果，后者能够继续追问任务频率、当前耗时、错误后果和所需数据。

一个可评估的场景描述至少包含：

【某类用户】在【具体触发时刻】需要完成【任务】，当前因为【问题】导致【可量化影响】；希望 AI 在【行动边界】内提供【结果】，并通过【指标】证明改善。

例如：

售后工程师在设备现场收到故障码后，需要在十分钟内形成初步诊断。当前手册、历史工单和设备配置分散，平均检索四十分钟，约三成问题需要二次转派。希望助手在引用有效来源的前提下给出诊断路径和备件建议，但首期不自动预留库存，以首次解决率、检索耗时和错误建议事故数评估。

改写过程会暴露很多伪需求。“给所有员工一个企业 ChatGPT”听起来范围很大，但没有明确任务和结果；“自动生成周报”容易实施，却可能只转移写作时间，不改善决策；“预测所有设备故障”价值巨大，却可能缺少故障标签和维护记录。产品经理的第一项能力，是把技术愿望还原为待完成任务。

4.3 六维优先级矩阵

本书建议从六个维度评估场景，每个维度可以使用一至五级，但分数不是为了制造精确答案，而是让假设可见。

4.3.1 业务价值

评估任务对收入、成本、客户体验、风险和资产效率的影响。要区分理论价值与可捕获价值。一个任务即使影响巨大，如果结果无法进入实际流程或没有部门愿意承担变更，短期可捕获价值仍然有限。

需要记录当前基线：任务量、平均耗时、错误率、等待时间、返工、损失或机会成本。没有基线，上线后很难证明改善。

4.3.2 数据就绪度

评估关键数据是否存在、能否访问、语义是否明确、质量和时效是否满足、是否有反馈标签。不要只问“有没有数据”，还要问数据是否覆盖目标用户和异常情况。文档很多不代表版本可靠，日志很多不代表能够关联业务结果。

这一维度可以使用上一章的四层模型分解，明确缺口属于基础设施、工程、上下文还是 Agent 控制。

4.3.3 任务可评估性

是否能够定义好答案、坏答案和任务完成？合同摘要可以由专家抽样评估，库存查询可以与系统事实比对，开放式战略建议则很难建立客观标准。第一阶段优先选择可建立评估集和线上反馈的任务，因为可评估才能迭代。

可评估性还包括失败分类。团队要能区分数据错误、检索遗漏、推理错误、工具失败和流程问题，否则优化只能依靠感觉。

4.3.4 流程可嵌入性

AI 输出是否出现在用户真正工作的位置？如果售后工程师必须离开工单系统，登录另一个门户，重新输入设备信息，采用率会很低。场景需要明确入口、触发方式、审批和人工接管。

流程可嵌入性也受组织意愿影响。某部门担心透明化影响绩效，或专家不愿提供反馈，再好的模型也难以形成闭环。

4.3.5 实施成本与复用

成本包括数据接入、开发、推理、许可证、评估、治理、运维和变更管理。应同时评估场景能否沉淀共性能力，例如文档版本、客户实体、权限过滤、检索评估或工具框架。复用潜力高的场景可以接受略高首期成本，但不能用“未来可能复用”为无限平台投资辩护。

4.3.6 风险与可逆性

错误会造成什么后果？是否涉及人身安全、财务损失、歧视、隐私、监管或不可逆动作？是否存在人工确认、额度限制、沙箱和回滚？风险不是简单扣分项，某些风险应设置一票否决门槛。

相同模型能力在不同自治程度下风险不同。给工程师建议和自动控制设备不是同一个场景，应该拆开评估。

4.4 先过门槛，再比较得分

常见错误是把所有维度相加，得到一个总分。这样可能让高业务价值抵消不可接受的安全风险。更可靠的方法分两步。

第一步设置门槛。数据是否有合法用途？是否能够建立最小评估？错误是否有可接受的人工兜底？业务负责人是否承诺进入流程？任何门槛不满足，场景进入准备池而不是实施池。

第二步在通过门槛的场景中比较价值、时间、成本和复用。可以形成四类组合：

快速验证型：价值中等、就绪度高、风险低，适合建立信心；
战略牵引型：价值高、缺口明显，但可分阶段，适合带动共性能力；
平台复用型：单场景价值一般，但能支持多个已确认需求；
暂缓研究型：价值想象大，但数据、评估或风险条件尚不成熟。

投资组合中不应全部是快速验证，也不应全部是战略大项目。一个合理季度可能同时推进一项快速验证、一项战略场景准备和一项有限的平台共性建设。

4.5 场景发现的四种来源

第一种来源是高频重复任务。大量时间花在查找、整理、比对和转录上，通常适合 AI 辅助，但需要确认节省的时间能否被真正释放。

第二种来源是跨系统等待。任务本身不复杂，却因信息分散和交接耗时。这里的核心可能不是模型，而是数据服务和流程编排。AI 可以改善入口，但不要用模型掩盖系统集成问题。

第三种来源是专家稀缺。少数专家掌握故障诊断、合同判断或运营经验，成为组织瓶颈。场景需要把专家知识与案例转化为可检索上下文，同时保留升级通道。目标不是复制专家的全部判断，而是让常见问题自助化，让专家集中处理例外。

第四种来源是反馈过慢。企业已经产生大量业务结果，却无法及时发现变化和调整。例如投诉主题一月后才汇总、质量异常跨周才定位。此类场景强调事件、语义、评估和闭环。

发现过程中要访谈真实执行者，而不只访谈管理者。管理者描述的是流程图，执行者会告诉你哪些步骤依赖截图、微信、个人 Excel 和口头确认。这些“非正式接口”往往决定数据产品范围。

4.6 识别“模型问题”背后的数据问题

很多需求最初被描述为“模型不够聪明”。进一步分析后，可能是文档版本混乱、实体无法关联、指标口径冲突、权限导致检索缺失或缺少结果反馈。场景评估要做一次失败预演：

如果模型回答错误，最可能缺少什么事实？
如果检索到了错误文档，如何知道它已过期？
如果两个来源冲突，谁拥有裁决权？
如果工具返回超时，Agent 应继续还是停止？
如果用户没有反馈，如何判断任务是否解决？

这些问题会把“模型准确率”拆成可建设的数据和系统能力，也能帮助团队估算真实成本。

4.7 山城精工的场景组合

山城精工初步收集了五个需求：售后诊断助手、销售方案生成、经营问数、设备预测性维护和合同风险审查。

设备预测价值很高，但历史故障标签稀缺，设备型号差异大，错误预警会造成维护成本，首期进入准备池。经营问数有明确数据，但指标口径冲突，适合先建设受控指标查询而非开放问答。销售方案生成风险低、数据较易获取，却难以直接证明收入提升，可作为快速验证。合同审查需要严格权限和法务评估，先限定为条款定位与差异提示。售后诊断任务高频、当前耗时可量化、专家愿意参与、数据缺口虽多但可控制，因此成为战略牵引场景。

团队没有选择“价值分最高”的单一场景，而是形成组合：售后诊断进入九十天实施，销售方案做四周验证，经营指标先治理两个核心主题，设备预测补采标签，合同审查建立权限和评估准备。这比宣布五个项目同时启动更接近真实投资管理。

4.8 从优先级到发现阶段

优先级评审不是立项终点。进入候选的场景要经过两至四周发现阶段，验证三个假设：

价值假设：问题是否真实高频，用户是否愿意改变流程？
数据假设：关键数据和上下文是否可获得，缺口成本是否可接受？
可控假设：能否建立评估、权限和人工兜底？

发现阶段可以使用少量样本和人工流程，不急于建设平台。产品经理记录用户任务和基线，架构师画出现状数据流，领域专家建立首批评估集，安全人员判断数据用途。阶段结束时做继续、调整或停止决策。

停止不是失败。尽早证明一个场景当前不值得做，为企业节省了更大成本。成熟的 AI 产品组合必须有退出机制，否则所有试点都会因为沉没成本被包装成成功。

4.9 本章产物：场景优先级卡

每个候选场景使用同一张卡：

项目	内容
用户与触发时刻	谁在什么时候遇到问题
待完成任务	需要形成什么判断或行动
当前基线	频率、耗时、错误、等待和成本
目标结果	任务、流程和业务指标
数据与上下文	来源、语义、质量、时效、权限、反馈
行动边界	辅助、建议、委托或自治
评估方式	离线集、线上反馈与失败分类
门槛	合法用途、风险、兜底和业务负责人
实施成本	接入、开发、模型、治理与运营
复用能力	对其他已确认场景的贡献
决策	实施、发现、准备或停止

真正的优先级不是给想法排序，而是给企业有限注意力排序。选择第一个 AI Ready 场景时，团队也在选择第一批需要被产品化的数据、第一组需要显式化的语义、第一条需要形成的反馈闭环。这个选择决定了企业会从演示走向能力，还是从一个演示走向下一个演示。