# MetaCore 第一阶段实施计划

生成时间：2026-03-27  
状态：草案  
范围：第一阶段执行

## 目的

这份文档把第一阶段范围翻译成实施路线图。

它要回答：

- 先做什么
- 谁依赖谁
- 每个里程碑在证明什么
- 当前真正应该推进哪一段

## 里程碑总览

第一阶段应拆成 6 个里程碑，并把引擎生产力工作流排在 RuntimeData 前面。

```text
M1 引擎壳与项目循环
  -> M2 资源与模型导入循环
    -> M3 场景编辑、材质与光照工作流
      -> M4 UI、持久化与打包循环
        -> M5 面向数字孪生的 RuntimeData 集成
          -> M6 引擎硬化与未来预留
```

## M1 引擎壳与项目循环

### 目标

让 MetaCore 成为一个具备稳定项目行为的引擎壳。

### 交付物

- 稳定的 Windows 应用主循环
- 稳定的平台层
- 项目打开/创建行为
- 启动场景行为
- 独立 Player 执行能力

### 关键工作流

- 应用生命周期
- 模块与服务启动
- 项目描述文件处理
- 视口渲染稳定性
- 编辑器基线工作流与项目引导

### 完成标准

- 项目能稳定打开
- 启动场景能被解析
- 运行时能加载并渲染启动场景

## M2 资源与模型导入循环

### 目标

让 MetaCore 从“只有场景原型”变成“能围绕资源工作的工具”。

### 交付物

- 资源元数据生成
- 资源数据库稳定
- 导入流程稳定
- 一等支持的模型导入工作流
- package 流程稳定
- 重新导入与资源浏览基础

### 关键工作流

- 资源元数据与 package 格式
- 导入流水线
- 模型格式支持
- Project 面板工作流
- prefab 基础

### 完成标准

- 导入的资源稳定出现
- 导入的模型能在场景中使用
- 场景和资源在重载后仍然有效

## M3 场景编辑、材质与光照工作流

### 目标

让 MetaCore 真正可用于内容搭建。

### 交付物

- 稳定的层级编辑
- Transform Gizmo
- 材质工作流
- 光照工作流
- 可用的视口编辑体验

### 关键工作流

- 层级行为
- 多选和操作
- Transform 工具
- 材质资源与材质指派
- 灯光编辑

### 完成标准

- 可以基于导入资源搭一个场景
- 材质和光照可以稳定编辑
- 编辑器内容生产不再依赖硬编码 demo 对象

## M4 UI、持久化与打包循环

### 目标

让 MetaCore 作为项目工具具备交付能力。

### 交付物

- UI 基础编辑
- 场景保存/打开成熟化
- Windows 打包验证
- 项目级 pilot 打包流程

### 关键工作流

- UI 资源与 UI 运行时
- 编辑期 JSON 场景持久化与发布期二进制 Cook
- 启动场景打包
- clean machine 验证

### 完成标准

- 开发者能构建并打包一个小型工业三维可视化客户端
- 打包后的运行时在编辑器外表现稳定

## M5 面向数字孪生的 RuntimeData 集成

### 目标

在引擎基础工作流之上叠加数字孪生所需的 RuntimeData 能力。

### 交付物

- 独立的 RuntimeData 模块
- source / point / binding 模型
- runtime config 持久化
- live adapter 支持
- binding 配置工作流
- runtime diagnostics

### 关键工作流

- RuntimeData 架构
- adapter 与 binding 模型
- 运行时分发与故障处理
- 编辑器侧配置
- 数字孪生样板工程

### 完成标准

- 打包后的运行时能把外部数据应用到场景目标
- 运行时故障可见且不会导致崩溃
- 引擎能支撑一个小型数字孪生项目

## M6 引擎硬化与未来预留

### 目标

把 MetaCore 强化成一个可长期演进的引擎底座。

### 交付物

- 更清晰的 Runtime / Editor 分离
- 更强的诊断能力
- 更干净的子系统边界
- XR 与 B/S 的未来预留在代码结构中落地

### 关键工作流

- 模块边界清理
- 诊断与健康可见性
- 未来扩展接口
- 样板与测试扩充

### 完成标准

- 第二阶段工作不需要推翻第一阶段架构

## 任务树

### A. 引擎基础

- A1 应用生命周期
- A2 平台服务
- A3 日志
- A4 模块启动

### B. 场景与对象系统

- B1 场景结构
- B2 GameObject 层级
- B3 组件状态
- B4 持久化
- B5 prefab 基础

### C. 渲染与运行时

- C1 渲染桥
- C2 场景视口
- C3 运行时视口
- C4 相机控制
- C5 光照基础

### D. 项目与资源循环

- D1 项目描述文件
- D2 资源元数据
- D3 资源数据库
- D4 导入流程
- D5 package 流程
- D6 cook 流程

### E. 编辑器

- E1 Hierarchy 面板
- E2 Scene 视图
- E3 Inspector
- E4 Project 面板
- E5 Console
- E6 Undo / Redo

### F. UI 与交付

- F1 UI 资源与 UI 运行时
- F2 场景持久化
- F3 打包
- F4 clean-machine 验证

### G. RuntimeData

- G1 RuntimeData 模块
- G2 RuntimeData 类型系统
- G3 source 与 binding 文档
- G4 adapter 接口
- G5 dispatcher
- G6 live adapter
- G7 binding 编辑
- G8 诊断与 stale 处理

### H. 未来预留

- H1 XR 扩展边界
- H2 B/S 扩展边界
- H3 子系统清理

## 修正后的实施重点

旧建议过早把 RuntimeData 放在主线中央。

修正后的顺序应该是：

1. 先做 M1 和 M2
2. 再做 M3
3. 再做 M4
4. 最后再让 M5 成为主导

RuntimeData 仍然重要，但它现在应该被视为 Phase 1B 子系统，而不是第一阶段最先主导实现节奏的模块。

## 当前关键路径

当前关键路径应该是：

```text
项目循环
  -> 资源与模型导入
    -> 层级与 Transform 工作流
      -> 材质与光照工作流
        -> 场景保存/打开
          -> UI 基础
            -> 打包
              -> RuntimeData 集成
```

如果这条路径被过早的行业子系统实现打断，MetaCore 会继续表现得像一个专用 demo，而不是一个可用于开发项目的引擎工具。

## 当前执行焦点的完成标准

当前执行焦点完成时，应满足：

- 项目可以稳定打开并引导
- 导入的模型资源可以进入场景
- 层级编辑和 Transform 操作稳定
- 材质和光照可以重复性编辑
- 场景可以保存、重开并打包

只有在这些点成立之后，RuntimeData 才应该重新成为第一阶段主导任务。

## 立即下一步

从 M1 和 M2 开始推进。

在引擎内容工作流足够强之前，不要继续优先扩 adapter、工业协议或更多 RuntimeData 专属工具。