# MetaCore 第一阶段 Roadmap

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

## 目的

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

它回答的问题是：

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

## 相关文档

- [metacore-engine-feature-baseline.md](D:/MetaCore/docs/designs/metacore-engine-feature-baseline.md)
- [metacore-phase1-m1-m4-tasklist-and-acceptance.md](D:/MetaCore/docs/designs/metacore-phase1-m1-m4-tasklist-and-acceptance.md)
- [metacore-phase1-m1-m4-workstreams.md](D:/MetaCore/docs/designs/metacore-phase1-m1-m4-workstreams.md)
- [metacore-m1-backlog.md](D:/MetaCore/docs/designs/metacore-m1-backlog.md)
- [metacore-m2-backlog.md](D:/MetaCore/docs/designs/metacore-m2-backlog.md)
- [metacore-m3-backlog.md](D:/MetaCore/docs/designs/metacore-m3-backlog.md)
- [metacore-m4-backlog.md](D:/MetaCore/docs/designs/metacore-m4-backlog.md)

## 核心判断

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

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

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

## Roadmap 总览

```text
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](D:/MetaCore/docs/designs/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](D:/MetaCore/docs/designs/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](D:/MetaCore/docs/designs/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](D:/MetaCore/docs/designs/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 第一阶段就会从“概念正确”进入“执行正确”。