2. Roadmap版本与原型版本映射矩阵：版本号规则、映射表模板、同步更新机制

2.1 适用场景

• 多版本并行开发： 项目同时推进 2 个以上的 Roadmap 版本（如 v2.3、v2.4、v3.0），需要为每个版本交付不同的原型。
• 需求追溯链建立： 团队需要从原型设计稿，快速追溯到具体的 Roadmap 版本及功能特性，消除沟通黑盒。
• 跨角色协作对齐： 产品、设计、开发、测试等角色需要一份统一的版本参照基准，降低协同成本。

2.2 前置条件

1. 已完成项目 Roadmap 基线制定，至少包含未来 2 个主要版本的里程碑与功能清单。
2. 已确定原型设计工具（Figma / Sketch / Axure）及版本管理方式（文件命名 / 页面标记 / 分支管理）。
3. 已指定一名版本管理员（通常为高级产品经理或设计负责人），负责矩阵维护。

2.3 操作步骤

1. 定义版本号规则： 采用语义化变体 [Roadmap主版本].[Roadmap次版本].[原型迭代号]。例如：Roadmap 为 v2.3.0 的功能进行第 3 轮原型修改，则原型版本记为 v2.3.3。
   小贴士： 当 Roadmap 版本号（如 v2.4.0）发生变更时，原型版本的主、次版本号必须同步递增，避免出现“跨版本原型”导致追溯紊乱。
2. 创建映射表模板： 使用在线表格（飞书多维表格 / 腾讯文档 / Excel）建立映射矩阵，包含“Roadmap 版本”、“原型版本”、“对应功能”、“当前状态”、“负责人”等核心列。
3. 建立同步更新机制： 定义触发矩阵更新的条件与流程：
   • 主动触发： 新功能进入设计阶段、高保真原型评审通过、Roadmap 发生变更。
   • 被动检查： 每日站会后版本管理员核对变更，或在每次版本发布前进行 100% 矩阵一致性检查。

2.4 输入输出物

2.5 责任边界

• 产品经理： 负责定义 Roadmap 版本及其范围，当 Roadmap 发生变更时第一时间通知版本管理员。
• 设计负责人： 负责确保原型版本编号正确，维护矩阵表的及时性与准确性。
• 项目经理： 负责监督对齐流程，在版本发布前组织矩阵一致性评审。

2.6 记录材料

• 映射矩阵表： 推荐使用飞书多维表格 / 腾讯文档 / Confluence 表格，支持多人实时协作与历史版本回溯。
• 版本号配置文件示例： 在项目根目录下维护版本标识文件，用于开发与设计的自动化对接。

  {
    "project": "app-design",
    "roadmap_version": "v2.3.0",
    "prototype_version": "v2.3.1",
    "last_sync": "2024-05-20",
    "sprint": 5
  }

2.7 异常处理

2.8 验收标准

1. 映射矩阵表 100% 覆盖当前所有活跃的 Roadmap 版本（无遗漏）。
2. 每一个原型版本号都能在矩阵中唯一、准确地追溯至一个 Roadmap 版本。
3. 团队成员（产品、设计、开发各一人）接受随机抽查，能够在一分钟内通过矩阵找到目标版本信息。
4. 版本管理员每日更新矩阵，版本日志完整可回溯。