MetaCore/docs/designs/metacore-phase1-roadmap.md

MetaCore 第一阶段 Roadmap

生成时间：2026-04-04
状态：草案
范围：第一阶段主干能力推进节奏
读者：产品、架构、引擎、编辑器、渲染、工具链、测试、交付

目的

这份文档把已经完成的能力清单、里程碑和 backlog，进一步收敛成一份真正可执行的 roadmap。

它回答的问题是：

• 第一阶段应该按什么节奏推进
• 每个阶段的主目标是什么
• 哪些工作可以并行，哪些不能乱序
• 每个阶段什么时候可以退出
• roadmap 完成后，团队是否可以进入正式开发

相关文档

• metacore-engine-feature-baseline.md
• metacore-phase1-m1-m4-tasklist-and-acceptance.md
• metacore-phase1-m1-m4-workstreams.md
• metacore-m1-backlog.md
• metacore-m2-backlog.md
• metacore-m3-backlog.md
• metacore-m4-backlog.md

核心判断

第一阶段 roadmap 的目标不是“把所有功能都铺满”，而是按正确顺序做通一条引擎主干：

1. 项目与资源进入引擎
2. 内容在引擎中可被制作
3. 内容与 UI 可被复用和组织
4. 项目可被独立发布和运行

如果这四条链依次成立，第一阶段就是健康推进的。

Roadmap 总览

Stage A：M1 项目与资源主干
  -> Stage B：M2 模型、材质、场景制作闭环
    -> Stage C：M3 Prefab 与 UI 基础
      -> Stage D：M4 Player、打包、发布闭环

推荐理解方式：

• Stage A：让项目和资源进入系统
• Stage B：让内容制作成立
• Stage C：让应用组织成立
• Stage D：让交付成立

建议节奏

如果以较稳健的第一阶段推进为目标，建议按 4 个执行阶段推进，而不是把所有 backlog 同时铺开。

建议节奏可以按下面理解：

• Stage A：先收地基
• Stage B：再做内容生产
• Stage C：再做复用与 UI
• Stage D：最后收发布闭环

如果团队规模较小，建议严格串行主里程碑，只允许少量前瞻设计并行。
如果团队规模较大，可以在主依赖不被破坏的前提下，让后一个阶段做设计预研，但不建议大规模越级实现。

---

Stage A：M1 项目与资源主干

目标

建立统一项目语义、统一资源入口和基础可见性。

本阶段要证明什么

MetaCore 不再只是“能打开一个编辑器”，而是正式围绕项目和资源工作。

主任务来源

• metacore-m1-backlog.md

核心任务

• 统一项目根目录解析
• 统一项目描述文件模型
• 项目创建与打开流程
• startup scene 规则统一
• Asset Database 初始化主干
• meta / GUID / package 记录统一
• 资源导入基础入口
• Project 面板第一版
• 资源刷新、重命名、移动基础规则
• 样板项目规范化
• M1 回归测试矩阵

可并行部分

• 项目描述文件模型
• Project 面板第一版
• 样板项目规范化

不应乱序的部分

• 没有统一项目解析，不应推进正式项目创建流程
• 没有 Asset Database 主干，不应推进正式导入入口
• 没有资源可见性，不应进入 M2 主实现

退出条件

• 用户可以创建并打开项目
• Editor / Player 对项目解析一致
• Project 面板可见项目资源
• 资源进入项目后进入 Asset Database
• meta / GUID / package 基础记录稳定

阶段产出

• 一个稳定的项目入口
• 一个稳定的资源入口
• 一个可用的资源浏览起点

---

Stage B：M2 模型、材质、场景制作闭环

目标

建立正式的内容制作闭环。

本阶段要证明什么

MetaCore 可以从“围绕资源工作”进一步变成“围绕内容制作工作”。

主任务来源

• metacore-m2-backlog.md

核心任务

• 首批模型导入策略定型
• 模型资产数据模型
• glTF/.glb 导入器第一版
• Mesh / Material / Texture 导入产物落地
• 导入归一化规则
• Project 面板模型资源增强
• 模型资源实例化到场景
• Scene 层级编辑增强
• Transform / Gizmo 工作流打磨
• 材质资源正式化
• 材质 Inspector 与材质指派工作流
• 基础光照工作流
• Scene 保存/重开中的资源引用稳定化
• 重导入与引用保持
• M2 回归测试矩阵

可并行部分

• 导入器第一版
• Project 面板模型资源增强
• Scene 层级编辑增强
• Transform / Gizmo 打磨

不应乱序的部分

• 没有模型资产数据模型，不应直接铺开多个格式导入器
• 没有 Scene 中资源引用规则，不应推进复杂重导入逻辑
• 没有正式材质资源，不应继续在 MeshRenderer 上堆临时字段

退出条件

• 第一种正式支持模型格式可导入
• 模型资产可进入场景
• 用户可以编辑 Transform、材质和灯光
• Scene 可保存并重开
• 重导入不打断核心引用

阶段产出

• 一条可用的 3D 场景制作链
• 一套正式进入场景的模型与材质资源语义

---

Stage C：M3 Prefab 与 UI 基础

目标

建立内容复用链和基础应用界面链。

本阶段要证明什么

MetaCore 不只是能做静态场景，而是开始具备“做应用”的基础能力。

主任务来源

• metacore-m3-backlog.md

核心任务

• Prefab 资源模型正式化
• 从对象树创建 Prefab
• Prefab 实例化工作流
• Prefab Apply / Revert 第一版
• Prefab 编辑器表达
• UiDocument 正式资源化
• UI 节点模型与基础控件
• UI 编辑器第一版
• UI 运行时渲染第一版
• UI 与项目/Scene 引用关系
• Prefab / UI 资源进入构建链
• M3 回归测试矩阵

可并行部分

• Prefab 主线
• UI 主线

不应乱序的部分

• 没有 Prefab 资源模型，不应直接做复杂 Apply / Revert
• 没有 UiDocument 正式资源化，不应推进复杂 UI 编辑器
• 没有 Player UI 显示，不应把 UI 只停留在编辑器侧

退出条件

• Prefab 复用链成立
• UI 文档与基础 UI 编辑链成立
• Player 可以显示基础 UI
• Prefab 和 UI 都进入正式构建链

阶段产出

• 一条内容复用链
• 一条基础界面制作链

---

Stage D：M4 Player、打包、发布闭环

目标

让项目内容脱离开发环境，进入正式交付形态。

本阶段要证明什么

MetaCore 第一阶段不是“只能在开发机里演示的编辑器”，而是能产出独立运行结果的引擎工具。

主任务来源

• metacore-m4-backlog.md

核心任务

• Player 项目加载链统一
• 构建输出目录规范
• cook 规则固定化
• 编辑器打包入口
• 独立输出目录生成
• 发布态资源加载一致性
• 运行时日志与错误诊断
• 发布目录与移交规范
• clean machine 验证流程
• M4 回归测试矩阵

可并行部分

• 编辑器打包入口
• 发布目录与移交规范
• 日志与诊断补强

不应乱序的部分

• 没有统一 Player 加载链，不应定义正式交付目录
• 没有稳定输出目录，不应宣称具备交付闭环
• 没有 clean machine 验证，不应把发布链视为完成

退出条件

• 用户可以从项目生成独立 Windows 输出目录
• 输出目录包含运行所需最小内容
• Player 脱离 Editor 与源工程目录可运行
• 场景、模型、材质、UI、配置可正确加载

阶段产出

• 一条完整的发布链
• 一套可以移交的交付目录

---

关键依赖关系

硬依赖

• M2 依赖 M1
• M3 依赖 M2
• M4 依赖 M3

可前置设计、不可前置实现的项

• 可以在 M1 后半段开始预研 glTF/.glb 导入器设计
• 可以在 M2 后半段开始预研 Prefab / UI 数据模型
• 可以在 M3 后半段开始预研打包目录和 Player 加载链

当前不应抢占主线的事项

• 更广泛的模型格式矩阵
• 更复杂的 RuntimeData 增强
• VR/XR 工作流
• B/S 产品化
• AI 辅助编辑
• 高级渲染 feature

风险与节奏控制

风险 1：过早横向铺太多资源类型

控制方式：

• 先把 glTF/.glb 做成正式闭环
• 不要在第一条链没稳时分散到多个复杂格式

风险 2：编辑器体验先行、底层语义未收敛

控制方式：

• 资源、Prefab、UI 都必须先有正式模型，再补编辑器体验

风险 3：发布链最后才发现路径和资源假设不成立

控制方式：

• 从 M1 开始就统一 Editor / Player / Tool 的项目语义
• 从 M2 / M3 开始就让正式资源进入构建视角

风险 4：团队同时做太多里程碑，导致每条链都不闭环

控制方式：

• 一次只让一个主里程碑处于实现主导状态
• 后续里程碑只允许预研和设计前置

建议管理节奏

每个阶段建议包含 4 类评审点

1. 设计评审
2. 实现评审
3. 样板项目回归
4. 退出评审

每个阶段建议维护的状态

• Design Ready
• Implementation In Progress
• Feature Complete
• QA In Progress
• Accepted

每个阶段都应回答的三个问题

1. 这条主链现在是否真的跑通了
2. 目前是否还依赖临时 fallback 或 demo 假设
3. 如果现在暂停开发，这一阶段成果是否可被下阶段稳定继承

Roadmap 完成后，是否可以开始开发

结论：

可以开始开发，而且应该开始。

但要注意，不是“roadmap 一写完就全团队同时铺开所有 backlog”，而是：

• roadmap 完成，说明方向、依赖和退出条件已经足够清晰
• 下一步应进入正式执行
• 执行顺序应从 M1 P0 开始，而不是并行开满 M1-M4

更准确地说，roadmap 完成后，团队应进入：

按里程碑收敛的正式开发阶段。

这意味着：

• 先把 M1 P0 任务卡开出来
• 给每张卡指定 owner、依赖和验收方式
• 以 M1 退出条件为第一阶段短期目标
• M2/M3/M4 只做必要的前置设计，不抢主线资源

建议的立即下一步

Roadmap 之后，建议马上做这 5 件事：

1. 把 M1 backlog 转成实际任务卡
2. 给 M1 P0 任务指定 owner
3. 建立第一版看板
4. 明确样板项目作为固定回归输入
5. 开始执行 M1-01 到 M1-07

结论

roadmap 的意义，不是再增加一层文档，而是把前面的设计文档收口成“可开始执行”的节奏。

所以答案很明确：

是的，roadmap 完成后就应该开始开发。

但正确的开始方式是：

• 从 M1 开始
• 从 P0 开始
• 从主链开始
• 从可验收的任务卡开始

只要按这个节奏推进，MetaCore 第一阶段就会从“概念正确”进入“执行正确”。