# MetaCore 第一阶段 M1-M4 分工工作流 生成时间：2026-04-04 状态：草案 范围：第一阶段主干执行分工 读者：产品、架构、引擎、编辑器、渲染、工具链、测试 ## 目的 在 [metacore-phase1-m1-m4-tasklist-and-acceptance.md](D:/MetaCore/docs/designs/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 第一阶段才不会再次滑回“功能很多，但主干不闭环”的状态。