第一段：盘点与排序
用统一模板收集场景，标注业务价值、数据依赖、合规要求与所需岗位，再由业务与 IT 共同排序。里程碑是场景池冻结：本季度只做名单内的场景，新增需求进入下一轮评审，避免一到季度中就不断插队，谁都做不完。
第二段：单点验证
选一个场景做完整闭环，从数据准备到上线运行，重点验证可行性与真实使用率。里程碑不是演示通过，而是业务方连续使用并愿意承担复核责任；不达标的场景应明确暂停，不硬撑到年底，也不追加预算。
第三段：复用复制
把首个场景的提示词结构、评测集、权限模型与运维流程整理成可复用组件，复制到相近场景。里程碑是第二个场景的上线周期明显短于第一个，说明复用真的发生，而不只是说法，投入才算摊薄，团队也才有信心。
第四段：规模化与运营
建立场景台账、模型与提示词版本管理、季度评审与预算联动。里程碑是季度评审能基于台账做增减决策，而不是每次从头讨论。此段最容易被忽略，也决定路线图能否持续，还是两年后重画一遍，人员换一茬又归零。
适用与不适用
适合谁
- 已有首个试点、准备扩大范围的企业
- 年度预算需要分阶段申报的集团企业
- 信息中心与业务部门能共同评审的组织
不适合谁
- 连一个场景都没跑通就想直接规模化的团队
- 不愿设阶段门、只按立项推动的项目
典型场景
某零售集团在第一段冻结了十二个场景，只放三个进试点。第二段中两个场景跑通，一个因数据权限迟迟未开被暂停。第三段把跑通场景的评测集复用到相近品类，第二个场景的上线周期比第一个短了近一半，团队才愿意继续投入。
可执行步骤
- 用统一模板收集场景，组织业务与 IT 共同排序并记录理由与依据，统一口径
- 在季度初冻结场景池，新增需求统一排入下一轮评审，不得插队，也不临时加塞
- 跑通一个完整闭环，并跟踪真实使用率、人工接管比例与变化，按月回看，并记录异常单
- 整理可复用组件，复制到相近场景并记录差异、调整动作与结果，形成模板
- 建立场景台账与季度评审机制，并与预算释放节奏联动，每季复盘，滚动更新
常见坑
- 场景池不冻结，季度内不断插队，最后每个场景都做不完，评审时无法解释进度，也无法交代投入，责任也难界定
- 演示通过就宣布成功，真实使用率无人跟踪，三个月后系统闲置，投入变成沉没成本，还占着运维资源
- 每个场景从零开发，复用率始终为零，投入越来越大而速度不变，团队也会疲，最后只剩一个样板，没人愿意接手
- 只排计划不排评审，年底才发现方向偏了，已无调整空间，只能明年再说，一年又过去了，复盘时才发现
自检与验收清单
- 场景池是否已在季度初冻结，并向业务线公示确认
- 首个场景是否有真实使用记录与接管比例数据
- 复用组件是否形成可查文档、模板与示例集说明
- 季度评审是否已排期，并与预算释放节点对齐联动
- 暂停与加码是否有书面决策，并由责任人签字确认
常见问题
四段各要多久？
单场景验证通常按季度安排，复用阶段取决于场景相似度，规模化则以季度为节奏持续推进。给出固定月数意义不大，更可靠的是用阶段门判断能否进入下一段，避免为了赶时间把验证做浅。
阶段门由谁评审？
由业务负责人、信息中心与财务共同评审，一把手对争议做裁决。只由项目组自评，阶段门会变成走过场；加入财务视角，资源分配才有人真正负责，也便于预算部门提前排期。
路线图能和年度预算对齐吗？
可以，把四段映射到预算科目：验证段走试点经费，复用段走平台投入，规模化段进入常规预算。提前对齐能减少中途追加预算的来回，也便于财务跟踪投入产出与后续审计。