它解决排序问题
企业手上的 AI 想法通常远多于资源，路线图的作用是把候选场景按价值、可行性、依赖关系排序，并说明为什么这个季度做这三个而不是那十个。没有排序，资源会被最会喊的部门拿走，年底也说不清为什么。
它包含四样东西
场景清单与优先级、每个场景的负责部门与依赖、资源与预算的分层安排、阶段门与停止条件。四样缺一，路线图就会退化成愿望清单，评审时无法判断进展，也无法做取舍，最后只能按谁声音大来定，执行时也没人服气。
它不是什么
不是技术架构图，不是供应商采购清单，也不是一次性的汇报材料。架构与采购是路线图的下游产物；如果一份文件半年不更新，它大概已经不是路线图，而是一份纪念册，翻一次就放回柜子，下次开会也没人提。
什么时候该做
已有零散试点、需要决定下一步投哪里时最合适；或者多业务线同时提需求、预算要统一申报时。若还没有一个能跑通的场景，先做单点验证比画路线图更实际，也更容易拿到真实数据与使用记录。
适用与不适用
适合谁
- 有多条业务线、AI 需求分散的集团企业
- 进入年度预算申报期的信息中心或战略部
- 已有试点、需要决定复制顺序的团队
不适合谁
- 还没有任何可运行场景、只想先要一份材料的企业
- 一把手不参与、由单个部门代写的项目
- 期望路线图直接替代实施落地的团队
典型场景
某集团信息中心收集到二十多个 AI 需求，年度预算只够支持少数几个。团队用两周把需求按价值与依赖排序，选出三个进入试点，其余标注观察条件。季度评审时按实际进展调整顺序，两个未达预期的场景被暂停，资源转给新入选的场景。
可执行步骤
- 收集需求并标注提出部门、依赖系统与预期产出，形成统一清单与版本，并留档备查
- 按价值、可行性、依赖关系逐项排序，并记录排序理由与依据备查，附评分表
- 为前三个场景写明负责人、所需资源与阶段门条件，逐一确认到人并签字
- 约定季度评审节奏、参与人与停止条件，并写进部门日程与预算日历，提前对齐
常见坑
- 把路线图写成技术选型清单，业务部门看不懂，评审时也无法讨论取舍，最后变成信息中心的独角戏
- 只排优先级不写停止条件，项目拖着不下线，最终变成沉没成本，还没人敢拍板停，预算越拖越紧，最后不了之
- 一次排满两年，第二季度就与现实脱节，后面没人再引用，等于白做，还耽误了真正该做的事，还占着预算
- 由单个部门闭门编写，评审时无人认账，执行阶段互相观望，进度全部压在项目组身上，后面很难推动，也没人愿意接
自检与验收清单
- 是否有明确、公开且可复核的排序依据、权重与记录
- 每个场景是否写明负责人、依赖关系与阶段门条件
- 是否设置可执行、可观测的停止条件与止损线，并提前约定
- 是否约定季度更新、评审与调整机制，并留档备查
常见问题
路线图要做多细？
一页纸能说清即可，单个场景另附一页说明。过细的路线图在第一次评审后就会失效，因为业务条件变化比计划快；保留排序逻辑与停止条件，比排满时间表更重要，也更容易维护。
没有战略部门谁来写？
通常由信息中心牵头、业务部门共建，一把手只做评审与裁决。单人闭门编写最容易失败，因为排序本质上是资源分配，需要有人对取舍负责，也需要业务部门在场上认账，否则执行时没人配合。
多久更新一次？
按季度更新比较合适，与预算和考核节奏对齐。遇到重大变化，比如业务线调整或平台更换，可以临时加一次评审，但不必为此重写整份文件，否则永远在改版本，没人真正执行。