420 lines
7.6 KiB
Markdown
420 lines
7.6 KiB
Markdown
# MetaCore M4 Backlog
|
||
|
||
生成时间：2026-04-04
|
||
状态：草案
|
||
范围：M4 Player、打包、发布闭环
|
||
读者：架构、引擎、编辑器、工具链、测试、交付
|
||
|
||
## 目的
|
||
|
||
这份文档把 M4 从“里程碑目标”进一步下钻为“可以直接开卡的 backlog”。
|
||
|
||
M4 的核心不是“多一个 build 命令”，而是让 MetaCore 走完这条最终闭环：
|
||
|
||
**编辑器里的项目内容 -> 正式构建输入 -> 独立 Player 输出 -> 脱离开发环境运行。**
|
||
|
||
## M4 成功定义
|
||
|
||
M4 完成时，MetaCore 至少应满足：
|
||
|
||
- 用户可以从正式项目生成独立输出目录
|
||
- 输出目录包含运行项目所需的最小内容
|
||
- Player 脱离 Editor 与源工程目录可运行
|
||
- startup scene、模型、材质、UI 和运行时配置可正确加载
|
||
- 打包失败与运行时缺失关键内容时，有明确日志和诊断
|
||
|
||
---
|
||
|
||
## M4-01 Player 项目加载链统一
|
||
|
||
### 背景
|
||
|
||
Player 已存在，但项目加载逻辑还需要与 Editor 主干完全统一。
|
||
|
||
### 目标
|
||
|
||
统一 Player 对项目根、startup scene、资源和 UI 的解析逻辑。
|
||
|
||
### 交付结果
|
||
|
||
- Player 项目根解析规则
|
||
- startup scene 加载规则
|
||
- 资源与 UI 路径解析规则
|
||
- 与 Editor 行为的一致性约束
|
||
|
||
### 依赖
|
||
|
||
- M1、M2、M3 完成
|
||
|
||
### 建议 owner
|
||
|
||
- 引擎核心
|
||
|
||
### 验收标准
|
||
|
||
- 同一项目在 Editor 和 Player 中加载语义一致
|
||
- Player 脱离 Editor 仍能稳定解析项目内容
|
||
|
||
---
|
||
|
||
## M4-02 构建输出目录规范
|
||
|
||
### 背景
|
||
|
||
如果输出目录不固定，后续交付、诊断和 clean machine 验证都会混乱。
|
||
|
||
### 目标
|
||
|
||
定义正式的输出目录结构和最小运行内容。
|
||
|
||
### 交付结果
|
||
|
||
- 输出目录结构规范
|
||
- Player 产物放置规则
|
||
- 资源产物放置规则
|
||
- 配置产物放置规则
|
||
|
||
### 依赖
|
||
|
||
- `M4-01`
|
||
|
||
### 建议 owner
|
||
|
||
- 工具链与构建发布
|
||
|
||
### 验收标准
|
||
|
||
- 同类项目打包输出目录结构一致
|
||
- 运行所需内容边界清晰
|
||
|
||
---
|
||
|
||
## M4-03 cook 规则固定化
|
||
|
||
### 背景
|
||
|
||
没有稳定的 cook 规则，打包输出就不能成为可信构建结果。
|
||
|
||
### 目标
|
||
|
||
收敛第一阶段需要的 cook 规则和命名约定。
|
||
|
||
### 交付结果
|
||
|
||
- cook 输入输出规则
|
||
- 资源产物命名约定
|
||
- 场景、材质、UI、Prefab 的构建处理规则
|
||
|
||
### 依赖
|
||
|
||
- `M4-02`
|
||
|
||
### 建议 owner
|
||
|
||
- 工具链与构建发布
|
||
- 引擎核心配合
|
||
|
||
### 验收标准
|
||
|
||
- 同一输入在相同条件下产生稳定输出
|
||
- 关键资源类型都能进入正式构建链
|
||
|
||
---
|
||
|
||
## M4-04 编辑器打包入口
|
||
|
||
### 背景
|
||
|
||
如果打包只能通过内部脚本或手工命令完成，交付工作流不完整。
|
||
|
||
### 目标
|
||
|
||
提供第一版面向用户的打包入口。
|
||
|
||
### 交付结果
|
||
|
||
- 编辑器内打包入口
|
||
- 打包参数入口
|
||
- 打包结果反馈
|
||
- 打包失败信息反馈
|
||
|
||
### 依赖
|
||
|
||
- `M4-02`
|
||
- `M4-03`
|
||
|
||
### 建议 owner
|
||
|
||
- 编辑器与工作流
|
||
- 工具链与构建发布配合
|
||
|
||
### 验收标准
|
||
|
||
- 用户可以从编辑器发起正式打包
|
||
- 成功和失败结果都有明确可见反馈
|
||
|
||
---
|
||
|
||
## M4-05 独立输出目录生成
|
||
|
||
### 背景
|
||
|
||
M4 的关键不是“构建成功”，而是“得到一个脱离工程目录可运行的独立输出”。
|
||
|
||
### 目标
|
||
|
||
让项目生成独立的 Windows 输出目录。
|
||
|
||
### 交付结果
|
||
|
||
- 输出目录生成逻辑
|
||
- Player、资源、配置、UI 的正式摆放
|
||
- 最小依赖内容收敛
|
||
|
||
### 依赖
|
||
|
||
- `M4-02`
|
||
- `M4-03`
|
||
- `M4-04`
|
||
|
||
### 建议 owner
|
||
|
||
- 工具链与构建发布
|
||
|
||
### 验收标准
|
||
|
||
- 输出目录中包含项目运行的最小必需内容
|
||
- 脱离源工程目录仍可启动
|
||
|
||
---
|
||
|
||
## M4-06 发布态资源加载一致性
|
||
|
||
### 背景
|
||
|
||
编辑器里能跑不代表发布态能跑，尤其是路径和资源解析常常不同。
|
||
|
||
### 目标
|
||
|
||
验证并修正 Player 在发布态下对场景、材质、UI 等内容的加载一致性。
|
||
|
||
### 交付结果
|
||
|
||
- startup scene 发布态加载验证
|
||
- 模型、材质、UI 发布态加载验证
|
||
- 关键路径差异修正
|
||
|
||
### 依赖
|
||
|
||
- `M4-05`
|
||
|
||
### 建议 owner
|
||
|
||
- 引擎核心
|
||
- 渲染与资源表现配合
|
||
|
||
### 验收标准
|
||
|
||
- 发布态运行结果与编辑态期望一致
|
||
- 关键内容不会因路径或构建差异丢失
|
||
|
||
---
|
||
|
||
## M4-07 运行时日志与错误诊断
|
||
|
||
### 背景
|
||
|
||
没有日志与错误面，交付和现场排障成本会很高。
|
||
|
||
### 目标
|
||
|
||
建立 Player 发布态的最小可用日志与诊断体系。
|
||
|
||
### 交付结果
|
||
|
||
- 启动日志
|
||
- startup scene 加载错误日志
|
||
- 资源缺失日志
|
||
- UI / 配置加载错误日志
|
||
- 可定位的失败路径
|
||
|
||
### 依赖
|
||
|
||
- `M4-01`
|
||
- `M4-05`
|
||
|
||
### 建议 owner
|
||
|
||
- 引擎核心
|
||
- 工具链与构建发布配合
|
||
|
||
### 验收标准
|
||
|
||
- 缺失关键内容时不会静默失败
|
||
- 交付团队能通过日志快速判断问题位置
|
||
|
||
---
|
||
|
||
## M4-08 发布目录与移交规范
|
||
|
||
### 背景
|
||
|
||
打包完成后还需要明确“什么是交付物”。
|
||
|
||
### 目标
|
||
|
||
定义交付目录结构、最小移交内容和交付说明边界。
|
||
|
||
### 交付结果
|
||
|
||
- 发布目录说明
|
||
- 最小移交清单
|
||
- 缺失关键文件时的错误说明
|
||
- 面向交付团队的目录语义
|
||
|
||
### 依赖
|
||
|
||
- `M4-05`
|
||
- `M4-07`
|
||
|
||
### 建议 owner
|
||
|
||
- 工具链与构建发布
|
||
- 交付配合
|
||
|
||
### 验收标准
|
||
|
||
- 交付团队可以理解并使用输出目录
|
||
- 缺失文件时能快速定位责任边界
|
||
|
||
---
|
||
|
||
## M4-09 clean machine 验证流程
|
||
|
||
### 背景
|
||
|
||
如果产物只能在开发机跑，M4 就没有真正完成。
|
||
|
||
### 目标
|
||
|
||
建立 clean machine 或近似隔离环境验证流程。
|
||
|
||
### 交付结果
|
||
|
||
- clean machine 验证步骤
|
||
- 隔离环境下运行检查项
|
||
- 常见失败类型清单
|
||
|
||
### 依赖
|
||
|
||
- `M4-05`
|
||
- `M4-06`
|
||
- `M4-07`
|
||
|
||
### 建议 owner
|
||
|
||
- 测试与验收
|
||
- 工具链与构建发布配合
|
||
|
||
### 验收标准
|
||
|
||
- 样板项目可在隔离环境中成功运行
|
||
- 不依赖 Editor、源码目录或开发机临时状态
|
||
|
||
---
|
||
|
||
## M4-10 M4 回归测试矩阵
|
||
|
||
### 背景
|
||
|
||
发布链如果没有回归矩阵，很容易在后续迭代中失效。
|
||
|
||
### 目标
|
||
|
||
建立 M4 的最小稳定验收矩阵。
|
||
|
||
### 交付结果
|
||
|
||
- 打包输出检查测试
|
||
- Player 独立运行测试
|
||
- 发布态资源加载测试
|
||
- clean machine 验证回归
|
||
- 样板项目发布回归
|
||
|
||
### 依赖
|
||
|
||
- `M4-01` 到 `M4-09`
|
||
|
||
### 建议 owner
|
||
|
||
- 测试与验收
|
||
- 各模块 owner 联合
|
||
|
||
### 验收标准
|
||
|
||
- M4 主链均有回归覆盖
|
||
- 样板项目可作为固定发布态验收输入
|
||
|
||
---
|
||
|
||
## 建议优先级
|
||
|
||
### P0
|
||
|
||
- `M4-01` Player 项目加载链统一
|
||
- `M4-02` 构建输出目录规范
|
||
- `M4-03` cook 规则固定化
|
||
- `M4-05` 独立输出目录生成
|
||
- `M4-06` 发布态资源加载一致性
|
||
- `M4-07` 运行时日志与错误诊断
|
||
- `M4-09` clean machine 验证流程
|
||
|
||
### P1
|
||
|
||
- `M4-04` 编辑器打包入口
|
||
- `M4-08` 发布目录与移交规范
|
||
|
||
### P2
|
||
|
||
- `M4-10` M4 回归测试矩阵
|
||
|
||
说明：
|
||
|
||
- `M4-10` 依赖前面链路稳定，不代表不重要
|
||
- 一旦发布主链基本成立，应尽快补齐回归矩阵
|
||
|
||
## 推荐执行顺序
|
||
|
||
```text
|
||
M4-01
|
||
-> M4-02
|
||
-> M4-03
|
||
-> M4-04
|
||
-> M4-05
|
||
-> M4-06
|
||
-> M4-07
|
||
-> M4-08
|
||
-> M4-09
|
||
-> M4-10
|
||
```
|
||
|
||
## 建议任务卡字段
|
||
|
||
后续如果转到看板，建议每个任务卡都带上：
|
||
|
||
- `Milestone`: `M4`
|
||
- `Workstream`: 引擎核心 / 编辑器与工作流 / 工具链与构建发布 / 渲染与资源表现 / 测试与验收
|
||
- `Priority`: `P0/P1/P2`
|
||
- `Owner`
|
||
- `Depends On`
|
||
- `Definition of Done`
|
||
- `Validation`
|
||
|
||
## 结论
|
||
|
||
M4 的本质不是“把构建功能做出来”，而是让 MetaCore 的第一阶段真正拥有交付意义：
|
||
|
||
**项目内容能够脱离开发环境，以独立 Player 的形式被稳定运行和移交。**
|
||
|
||
只要这条链没有成立，前面 M1-M3 的成果就还没有真正进入“可交付引擎”的阶段。
|