7.0 KiB
MetaCore 产品计划
生成时间：2026-03-27
状态：草案
读者：创始人、产品、设计、工程、交付
一句话定位
MetaCore 是一套面向国产化部署项目的自主可控三维引擎底座，第一阶段聚焦工业数字孪生项目交付。
为什么要做这件事
上一代方案已经证明底层路线能够通过自主可控评测，但基于 Python 的架构在持续功能演进、第三方软件适配和长期稳定交付上成本太高。
C++ 重构不是表面上的技术升级，而是产品动作。
它要让引擎：
- 更容易适配国产平台
- 更容易在交付中审计和裁剪
- 更容易接入复杂企业环境
- 更适合长生命周期行业项目
产品假设
第一商业切口不是“做一个通用引擎”，而是：
在国产化环境下更可靠地运行，并更快交付工业数字孪生项目。
这才是采购故事。
客户不是因为它像 Unity 才买，而是因为：
- 它能跑在目标国产环境
- 它能降低交付成本和排期风险
- 它足够可控，适合长期掌握
核心客户
直接客户
- 在国产化约束下做工业数字孪生项目交付的团队
- 面向国企、重工、军工相关客户的系统集成商
- 需要掌握三维底座而不愿长期依赖国外商业引擎的企业技术团队
最终运行环境
- 国产 CPU、国产 OS、国产 GPU、中间件及网络受限环境
- 带有自主可控、可信、可追溯、供应链审查要求的项目环境
第一商业切口
Stage 1
通过 C/S 架构完成工业数字孪生项目交付。
Stage 2
在同一引擎底座上产品化 B/S 嵌入能力和 VR 虚拟维修训练能力。
Stage 3
扩展到仿真编排、AI 辅助工作流和更高层行业解决方案。
核心价值主张
MetaCore 必须同时赢在两件事上：
- 国产化平台适配能力
- 快速项目交付能力
如果只有其中一项成立，产品就是弱的：
- 只适配、不快交付：技术上有意思，商业上偏弱
- 只快交付、不适配国产化：容易被替代，护城河不足
产品分层
MetaCore 应被定义为一个分层产品，而不是一个单体引擎。
1. MetaCore Core
引擎底座。
职责：
- 平台抽象
- 运行时主循环
- 渲染桥
- 场景模型
- 资源流水线
- package 与序列化
- 面向交付的模块化能力
2. MetaCore Studio
内部团队与交付团队使用的编辑器。
职责：
- 场景搭建
- 资源导入与整理
- 项目配置
- package 和部署准备
- 面向交付的编辑工作流
非目标：
- 在广度上复制 Unity 编辑器
3. MetaCore Industry Twin Kit
面向数字孪生项目交付的解决方案层。
职责：
- 行业项目模板
- 标准场景骨架
- 常用运行时组件
- 数据绑定 adapter
- 部署预设
4. MetaCore XR Training Kit
第二阶段的解决方案层。
职责：
- VR 运行时支持
- 维修训练流程编辑
- 交互脚本支持
- 训练评分与回放挂点
产品原则
原则 1：可控优先于便利
凡是会让审计、裁剪、替换、国产适配变难的依赖，默认都应被视为高风险依赖。
原则 2：交付优先于平台演示
每一个重大功能都应该帮助真实客户项目更快、更稳或更低适配成本地交付。
原则 3：模块替换点本身就是产品能力
渲染桥、导入流水线、数据连接器、打包方式、XR 层，都应被视为可替换模块，而不是写死的实现。
原则 4：编辑器围绕交付工作流服务
编辑器不是拿来做“像不像 Unity”的面子工程，而是项目团队的生产工具。
原则 5：可审计性属于架构的一部分
资源流、package 流、场景持久化和部署配置，都应该是显式且可检查的。
Stage 1 必须交付什么
只有当下面这条最小 C/S 交付链真实成立时，Stage 1 才算完成：
- 在目标国产化环境中运行
- 导入并组织项目资源
- 搭建和编辑一个可用的工业场景
- 配置基础交互与展示行为
- 打包并运行一个可交付应用
- 接入基础状态或数据驱动可视化
- 把一个可部署项目包移交给交付团队，而不需要额外手工拼接
如果这条链没闭环，就不该过早加 AI 或高级仿真能力。
Stage 1 范围
范围内
- 以 Windows 为先的 C++ 引擎重构，同时把国产适配作为架构要求
- 第一阶段只承诺 C/S 交付
- 场景、对象、组件、资源、package 和编辑器基础
- 工业数字孪生场景搭建工作流
- 面向交付的项目结构
- 部署打包与项目移交准备
- 基础数据驱动可视化挂点
- 为后续平台与模块适配保留稳定扩展点
- 为未来 B/S 嵌入保留架构边界
明确不在范围内
- 与 Unity 全工作流完全对齐
- 在游戏引擎功能广度上竞争
- 第一阶段完整 B/S 产品化
- 第一阶段浏览器优先运行时
- 高级可视化脚本系统
- 复杂多人协作
- AI-first 工作流
- 完整仿真平台
- 第一阶段完整 VR 训练产品化
Stage 1 成功标准
产品结果
- 一个交付团队能在 MetaCore 上完成一个小型工业数字孪生项目
- 该项目能在目标国产化环境中稳定运行到可接受程度
- 核心项目工作流不再被 Python 时代的架构限制卡住
商业结果
- MetaCore 可以被讲成“国产化交付底座”，而不只是内部原型
- 至少有一个项目机会可以用新的 C++ 架构作为主技术故事去推进
- 产品叙事优先支持项目交付收入，再延伸到买断或融资故事
工程结果
- 引擎核心足够模块化，便于平台适配和长期演进
- 资源与场景流水线是确定且可审计的
- 运行时与编辑器的依赖边界清晰可控
为什么是纯 C++
这次重构应该从产品角度来解释：
- 降低国产环境适配复杂度
- 增强长生命周期企业部署的稳定性
- 让性能和打包结果更可预测
- 更容易接入现有原生软件体系
- 对依赖和执行边界有更强控制
不应该把话术讲成“Python 不好”，正确的说法应该是：
Python 版本足以支撑上一代评测，但不足以支撑下一代交付。
交付架构策略
MetaCore 最终应该同时支持 C/S 和 B/S。
但第一阶段不应同时完整交付两者。
第一阶段承诺
- C/S 是唯一承诺的生产交付架构
- 第一条付费项目闭环必须通过桌面式国产化部署完成
第一阶段对 B/S 的预留
- 场景与资源格式不能写死桌面假设
- 运行时边界不能把业务逻辑锁死在单一桌面壳里
- package 与服务边界要保留未来嵌入第三方系统的路径
第二阶段承诺
- 产品化 B/S 输出和嵌入模式，用于第三方业务系统集成
规则很简单：
为两者设计，只在第一阶段承诺 C/S。
技术方向约束
架构约束
- 保持严格模块边界
- 优先显式服务契约，避免隐式耦合
- 反射与序列化体系必须掌握在自己手里
- package 格式必须稳定且可版本化
- 平台适配必须作为一等架构问题