EngineOS 全局执行路线图

2026-08-05 ｜当前 v0.3（WP0–WP7 已完成）｜权威源：EngineOS/docs/02_EXECUTION_ROADMAP.md

门装好了，屋子是空的 —— 接下来四步是往里装东西，不是再加门

现在在哪

✅ 引擎登记与校验 ✅ 原文追溯 + 篡改检测 ✅ 需求路由（九条闸） ✅ Foundry 约束简报 ❌ 领域内容（5 个引擎全空壳） ❌ 引擎运行器 ❌ 跨引擎链路 ❌ 组合管理 / 审计升级

测试 40 条全绿｜代码约 1,100 行｜已推 origin/main ｜已耗约 12 个任务单元

完整体系的六个位置 —— 你有几个

①

组合总控器

❌ 缺

管优先级/依赖/制造顺序。多引擎时不知道先造哪个

②

路由器

✅ 已建（WP6）

判该不该造/造哪层/有没有现成的

③

核心引擎制造器

✅ 已有

你的总指令 v3，已登记 + 已适配

④

引擎运行器

❌ 缺（最被低估）

没它，引擎造完仍停在设计文档、跑不起来

⑤

引擎集成器

❌ 缺

引擎之间接口对不上，谁也不知道

⑥

审计与升级器

❌ 缺

改了不知道有没有改坏

四个阶段：做什么 → 你能得到什么

阶段一装内容 6–10 单元｜最高优先

做什么

把 narrative-core 从空壳 E0 做到 E2：人物 / 目标 / 动机 / 冲突 / 代价 / 关系 / 信息拥有状态 / 事件 / 因果 / 场景 / 时间 / 伏笔 / 节奏 / 分支 / 结局 → 落成本体 + 状态模型 + 规则 + 接口；再定影视 / 游戏 / 3D 三个适配器的边界（只定边界，不实现）

前置

🔴 需你确认：叙事资料在 A129 哪些文件里

验收

给一个剧情 brief 能出结构化输出；人为植入的因果断裂能被检查抓到

💰 你的收获：从「能证明没重复造」变成「有东西可以用」。而且它一个顶三个——游戏、影视、3D 共用同一套人物/冲突/因果，这三边以后不用各造一遍。

阶段二跑起来 5–8 单元

做什么

Engine Runner：engineos run <engine> --input <file>。接输入 → 识别对象状态 → 调子引擎 → 出结果 → 写运行记录（调用了谁 / 触发哪些规则 / 中间状态 / 失败位置 / 返工次数）

前置

阶段一（得有非空引擎才跑得起来）

验收

同一输入跑两次结果一致；人为破坏中间状态，记录能定位到哪个子引擎哪条规则

💰 你的收获：第一次真正批量生产结果。以前是「陪你聊一遍出一个结果」，以后是「喂输入、出结果、留痕迹」。运行记录同时是阶段四审计的原料——没有它，「自我升级」就是空话。

阶段三接起来 5–8 单元

做什么

两条链路：
A 剧情 → 游戏剧情适配器 → 3D 世界引擎 → 可执行场景规格
B 剧情 → 影视剧本适配器 → 场景与分镜输入规格
外加 Integrator 查接口 / 映字段 / 报字段丢失

验收

人物关系与信息拥有状态穿过适配器不丢；改 3D 侧字段名能报出下游受影响清单

💰 你的收获：架构成立的证明。一份剧情输入，同时出得了游戏任务规格和影视分镜规格——这是整个 EngineOS 赌注的兑现点。

阶段四管起来 8–12 单元

做什么

组合总控（优先级/依赖）+ 审计升级器（基准/回归/失败归因/回滚）+ core/ 公共能力层，从真实调用关系固化

前置

≥3 个非空引擎 + 有运行记录可分析

验收

改一个 Schema 主版本，能自动报出所有受影响的下游引擎并给迁移清单

💰 你的收获：从「几个引擎」变成「引擎生态」。新领域（建筑 / 软件 / 动画 / VR）进来是加领域包和适配器，不是重写超级提示词。

资源怎么分配

80/20：70% 投在阶段一和二

阶段一不做完，后面三段全部卡住
阶段二不做完，引擎永远停在设计文档
阶段三、四是验证与治理，依赖前两段

木桶：当前最短板是「内容为空」

不是「控制面不够」
现在最该抵制的诱惑 = 再加一层控制面
每加一个控制面组件先问：它管的对象是不是空的？

刻意推迟清单（以及解冻条件）

推迟的东西	为什么	什么时候解冻
`core/` 公共能力层	只有 1 份真实领域资料，现在抽象必然把领域规律错当公共模块	≥3 个领域有真实内容
数学基础库	公共基础应从真实调用固化，不是先重写一遍人类数学	同上
组合总控器	现在造 = 管理 5 个空壳，零价值	≥3 个非空引擎且开始抢资源
金融引擎迁移	概率型验证最重（回测/校准），先拿创意型练手风险小	阶段一、二跑通后

需要你拍板的四件事

#	决策	影响	我的建议
D1	四个领域的现有资料在 A129 哪些文件？	阻塞阶段一	让我先扫全仓列候选表，你只需点头
D2	narrative-core 做到 E1 还是 E2？	决定阶段一工作量	E2 —— E1 只是文件，E2 才能真用
D3	先 Runner 还是先跨引擎链路？	先证明「能跑」还是「能接」	先 Runner —— 链路验证本身也需要能跑
D4	五个领域全迁，还是先只做叙事？	战线宽度	先只做叙事 —— 一个顶三个，验证成本最低

如果只做一件事

做阶段一。它是唯一一段「不做完则后面全卡」的工作，
而且收获立即可感：你第一次能拿到真实剧情的结构化输出，
而不是一份「剧情引擎应该怎么造」的说明书。

风险与「我错了」的判据

风险	表现	可证伪锚
控制面自娱自乐	建了一堆闸，从没拦住真问题	到阶段三结束，若九条闸一次都没拦下过，砍到只剩 R4+R5
过早抽象	`core/` 里塞进只属于叙事的东西	每个公共模块必须指出≥2 个领域的真实调用点，否则退回领域包
迁移变重写	借「迁移」之名把原文改得面目全非	`engineos legacy verify` 必须始终绿
战线过宽	五个领域同时迁，全都半吊子	任一时刻 `partially-migrated` 的引擎不得超过 2 个

工作量单位 = 任务单元（一次能完整审查、修改、测试的范围）。数值为 estimated，基于 WP0–7 实际耗用反推，非承诺。
不给日历时间是刻意的：我不控制你的投入节奏，给「三周完成」是伪精确。