第1章：版本规划的核心目标与产出物

1.1 用户场景与业务问题

AI产品的版本规划常陷入两种极端：

• 过度承诺：在Roadmap上堆砌「智能」「自适应」「多模态」等热词，实际交付时才发现技术链条未打通。
• 无边界蔓延：用户反馈一个改一个，版本计划每周都在变，研发资源被低价值需求耗尽。

典型业务痛点可归纳为下表：

1.2 Roadmap 定义：从战略到版本的结构化映射

在AI产品语境下，Roadmap 是连接产品愿景与具体版本交付的战略路线图。它回答三个问题：

1. Why — 为什么做这个版本？对应哪个用户场景或业务目标？
2. What — 版本内包含哪些核心能力与交付物？
3. When — 关键里程碑和预期时间窗口是什么？

与传统的「甘特图」不同，AI产品的Roadmap必须内置技术验证节点（如模型效果达标率、推理延迟阈值），因为AI能力的不确定性远高于传统软件。

1.3 核心要素：Roadmap 的六块基石

一份可执行的AI产品Roadmap包含以下六个要素：

1.4 交付物形态：Roadmap 的三种呈现方式

根据沟通对象的不同，Roadmap应剪裁为三种交付物：

• 战略层（面向VP/CEO）：一页纸概览图，展示愿景→季度主题→关键节点，配色简洁，避免细节。
• 执行层（面向PM/研发）：带需求矩阵和依赖关系的版本规划表，包含优先级标签和风险标识。
• 协作层（面向业务/运营）：以用户价值为主线的版本说明文档，强调每个版本能解决什么具体问题。

1.5 需求拆解与版本规划方案

从用户场景到版本功能，需要经过三层拆解：

1. 场景萃取：从用户访谈/数据分析中提炼高频且高价值的任务。
2. 能力映射：将每个任务拆为「AI能力需求」与「工程能力需求」。
3. 版本封装：将可独立交付的能力组合成版本，确保每个版本有完整的用户闭环。

例如，一个AI客服产品的版本规划方案：

1.6 优先级决策：RICE 框架在AI产品中的应用

在AI产品中，传统的优先级模型需要增加「技术可行性」维度。推荐采用 RICE-T 模型：

• Reach — 影响用户数或业务覆盖范围
• Impact — 对核心指标（如转化率、留存）的预期提升
• Confidence — 对效果预估的信心指数（AI能力不确定性越高，信心越低）
• Effort — 研发/标注/训练的总人月
• Technical Feasibility — 模型方案是否已验证或存在已知技术风险

每个需求算出 RICE-T 总分后，按分数从高到低进入版本 backlog。低于阈值（如总分 < 30）的需求搁置到下个规划周期再评估。

1.7 指标验证与验收标准

每个版本发布前，必须通过以下三类验收门禁：

以下SVG将上述内容整合为一张完整的 Roadmap 核心结构图，展示从用户场景到版本交付的完整链路：

1.8 本章要点总结