MetaCore/docs/designs/metacore-phase1-m1-m4-workstreams.md

MetaCore 第一阶段 M1-M4 分工工作流

生成时间：2026-04-04
状态：草案
范围：第一阶段主干执行分工
读者：产品、架构、引擎、编辑器、渲染、工具链、测试

目的

在 metacore-phase1-m1-m4-tasklist-and-acceptance.md 的基础上，这份文档进一步回答一个更实际的问题：

M1-M4 应该怎么拆成可并行推进的工作流和责任域。

这份文档不重新定义里程碑目标，而是把每个里程碑映射到 5 条主工作流：

1. 引擎核心
2. 编辑器与工作流
3. 渲染与资源表现
4. 工具链与构建发布
5. 测试与验收

建议后续排期、拆工、开 issue、分配 owner 时，优先按这 5 条工作流拆，而不是把所有任务堆成一条线。

使用原则

原则 1：按责任域拆，不按文件夹拆

分工时应优先看“谁对哪条能力链负责”，而不是“谁改哪个目录”。

原则 2：每条工作流都要对接验收

不能只有开发 owner，没有验收 owner。

原则 3：允许交叉协作，但必须明确主责

例如材质系统同时涉及：

• 资源系统
• 渲染系统
• 编辑器 Inspector
• 场景持久化

但必须有一个主责工作流来收口。

工作流定义

1. 引擎核心工作流

负责：

• 项目系统
• 资源数据库主干
• Scene / GameObject / Component
• Prefab 核心语义
• 序列化与反射
• 运行时项目加载

典型 owner：

• 架构
• 引擎核心

2. 编辑器与工作流工作流

负责：

• Project 面板
• Hierarchy
• Inspector
• Scene View 交互
• UI 编辑器
• Prefab 编辑体验

典型 owner：

• 编辑器
• 工具开发

3. 渲染与资源表现工作流

负责：

• 模型导入结果到渲染对象的落地
• Mesh / Material / Texture 资源表现
• 基础 PBR
• 灯光
• Editor / Player 视觉一致性

典型 owner：

• 渲染
• 资源表现

4. 工具链与构建发布工作流

负责：

• 导入器工具链
• cook 规则
• 打包与发布
• 输出目录规范
• clean machine 验证流程

典型 owner：

• 工具链
• 构建发布

5. 测试与验收工作流

负责：

• smoke / integration tests 设计
• 样板项目回归
• 里程碑验收脚本
• 回归矩阵维护

典型 owner：

• 测试
• 工具链
• 相关模块 owner 联合

---

M1 分工工作流

M1 目标

建立“项目 + 资源 + 编辑器可见性”的稳定主干。

引擎核心

主责任务：

• 项目目录结构定义
• MetaCore.project.json 字段收敛
• Editor / Player / Tool 项目定位规则统一
• Asset Database 初始化与查询主干
• GUID / meta / package 记录统一

交付物：

• 统一项目解析入口
• 统一项目描述读写层
• 统一资源记录模型

完成标志：

• 从不同入口启动都能得到一致项目解析结果

编辑器与工作流

主责任务：

• Project 面板第一版
• 资源列表与类型显示
• 资源选择与 Inspector 联动
• 错误信息在 Console 中可见

交付物：

• 可用的项目资源浏览界面

完成标志：

• 新资源进入项目后，用户能在编辑器中明确找到它

渲染与资源表现

主责任务：

• 本阶段只承担配合责任
• 确保资源进入系统后不会卡住后续渲染接入

交付物：

• 对后续模型/材质资源接入的最小渲染占位约束

工具链与构建发布

主责任务：

• meta / package 基础生成流程
• 刷新与扫描入口
• 样板项目 bootstrap 规则收敛

交付物：

• 稳定的资源进入项目时的工具链行为

测试与验收

主责任务：

• 项目创建/打开测试
• 项目描述文件读写测试
• 项目定位测试
• Asset Database 初始化/刷新测试
• 样板项目打开回归

验收口径：

• “项目入口 + 资源进入项目 + 编辑器可见”链路成立

---

M2 分工工作流

M2 目标

建立“模型导入 -> 材质 -> 场景制作 -> 保存重开”的闭环。

引擎核心

主责任务：

• 模型资源数据结构
• Scene 中模型资产引用语义
• Scene 保存/打开中的资源引用稳定性
• 重导入后 GUID 与引用保持规则

交付物：

• 模型、材质、纹理资源与 Scene 引用关系定义

完成标志：

• Scene 保存后不再依赖原始导入过程的偶然状态

编辑器与工作流

主责任务：

• 模型资源拖入场景
• Scene 层级增强
• 多选、复制、重命名、重挂接打磨
• Transform / Gizmo 打磨
• 材质 Inspector 编辑
• 灯光 Inspector 编辑

交付物：

• 可用的 3D 场景制作工作流

完成标志：

• 内容人员可以从导入资源开始搭一个基础场景

渲染与资源表现

主责任务：

• glTF/.glb 导入结果到渲染对象的落地
• Mesh / Material / Texture 资源表现
• 基础 PBR 参数支持
• Directional / Point / Spot Light 表现
• Editor / Player 视觉结果尽量一致

交付物：

• 模型导入后的可见渲染结果
• 第一版材质与光照链路

完成标志：

• 导入的模型和材质在 Editor / Player 都能正确显示

工具链与构建发布

主责任务：

• glTF/.glb 导入器第一版
• 导入归一化
• 材质/纹理导入产物落盘
• 重导入触发和错误诊断

交付物：

• 第一正式支持模型格式的生产级基础闭环

完成标志：

• 至少一种正式格式可稳定导入、重导入和落地

测试与验收

主责任务：

• 模型导入测试
• 模型实例化场景测试
• Scene 保存/重开测试
• 材质引用测试
• 重导入引用稳定性测试
• 样板场景回归

验收口径：

• “导入模型 -> 放入场景 -> 编辑 -> 保存重开”链路成立

---

M3 分工工作流

M3 目标

建立“Prefab 复用 + 基础 UI”的应用制作基础。

引擎核心

主责任务：

• Prefab 核心语义
• Prefab 与 Scene 实例关系
• Apply / Revert 的基础数据模型
• UiDocument 资源语义
• UI 资源与项目/Scene 引用关系

交付物：

• Prefab 和 UI 资源的核心模型定义

完成标志：

• Prefab 与 UI 都成为正式资源，而非编辑器临时结构

编辑器与工作流

主责任务：

• Prefab 创建、实例化、Apply、Revert 交互
• Prefab Inspector 表达
• UI 层级树
• UI Inspector
• UI 创建、删除、基础布局编辑

交付物：

• Prefab 和 UI 的第一版编辑器工作流

完成标志：

• 内容复用和 UI 编辑都能在编辑器中完成，不依赖手写文件

渲染与资源表现

主责任务：

• UI 运行时基础显示
• UI 元素视觉表现最小闭环
• Prefab 实例在渲染层上的一致表现

交付物：

• Player 中的基础 UI 可视结果

完成标志：

• UI 资源在 Player 中可以显示

工具链与构建发布

主责任务：

• Prefab 资源落盘与加载稳定化
• UI 资源落盘与加载稳定化
• 相关资源进入项目和打包流程

交付物：

• Prefab / UI 资源成为正式构建输入

测试与验收

主责任务：

• Prefab 创建/实例化测试
• Apply / Revert 测试
• UI 文档保存/重开测试
• Player UI 显示测试
• 样板项目回归

验收口径：

• “复用对象模板 + 基础 UI”双链路成立

---

M4 分工工作流

M4 目标

建立“从项目到独立 Player 发布”的交付闭环。

引擎核心

主责任务：

• Player 项目加载稳定化
• 启动场景、资源、UI、运行时配置加载一致性
• 运行时关键错误路径的主逻辑收口

交付物：

• 独立运行的项目加载主链

完成标志：

• Player 脱离 Editor 仍能稳定解析项目内容

编辑器与工作流

主责任务：

• 打包入口
• 发布参数入口
• 输出目录和错误信息在编辑器中可见

交付物：

• 面向用户的发布操作入口

完成标志：

• 用户可以从编辑器发起一次正式打包

渲染与资源表现

主责任务：

• Player 中场景、材质、灯光、UI 的一致性回归
• 发布态资源缺失时的可见降级表现

交付物：

• 发布态视觉一致性基线

工具链与构建发布

主责任务：

• cook 规则固定化
• 输出目录结构定义
• 打包流程固定化
• clean machine 验证脚本或流程

交付物：

• 正式发布目录规范
• 一条可重复执行的打包链路

完成标志：

• 样板项目可在独立目录成功运行

测试与验收

主责任务：

• 打包输出检查测试
• Player 独立运行测试
• clean machine 或近似隔离环境验证
• 样板项目发布回归

验收口径：

• “项目内容脱离开发环境独立运行”链路成立

---

推荐人员配置方式

如果团队规模较小，建议至少保证以下主责关系：

• 一人主责引擎核心
• 一人主责编辑器与工作流
• 一人主责渲染与资源表现
• 一人主责工具链与构建发布
• 一人主责测试与验收

如果团队规模不足，可以合并：

• 引擎核心 + 工具链与构建发布
• 编辑器与工作流 + 测试与验收

但不建议把以下三者长期合并给同一人：

• 引擎核心
• 编辑器工作流
• 渲染表现

因为这会导致主干推进过慢，且验收视角缺失。

推荐管理方式

每个里程碑建议都用同一套看板列：

• Not Started
• In Design
• In Progress
• Blocked
• Ready for QA
• Accepted

每个任务卡至少包含：

• 所属里程碑
• 所属工作流
• 主责 owner
• 依赖项
• 验收方式

结论

M1-M4 已经定义了“做什么”，这份文档补上了“谁来按什么责任域推进”。

后续真正执行时，最重要的不是把所有任务排成一条顺序线，而是：

• 用里程碑控制主依赖
• 用工作流拆出并行面
• 用测试与验收工作流保证每个里程碑都能真实退出

这样 MetaCore 第一阶段才不会再次滑回“功能很多，但主干不闭环”的状态。