从哪来 · 为什么 · 怎么做
玖衍 FAQ Q1 问「为何选 CMO 而非 AFSIM」。本节把选型逻辑写成可验收的工程论述，而非仿真圈站队。
教学演示 + LVC + AI 闭环
OpenNexus 的首要场景不是六自由度飞行动力学论文，而是指着屏幕讲清楚：态势从哪来、目标 ID 怎么对齐、AI 建议如何落到 Command 按钮。Command 自带 GUI 想定编辑、ORBAT 树、Mission 面板与 DB3K505 本地派生库——这些在 AFSIM 里要么要额外搭前端，要么要工程团队长期维护。
同时 LVC 链路要求 train/live 双模式在同一壳里切换；AI 参谋输出必须映射为 Mission / Doctrine 可理解的简单动作语言。Command 的数据模型与 OpenNexus 已建的 fusedId → DBID 映射、WPF :5000 写口天然咬合。
总成本 vs 单点指标
选 Command：更低集成总成本——GUI 想定、10 类 atomic_tasks → Mission/Doctrine、可编辑 DB3K505（约 16900 平台）、NamedPipe / REST 写口已通。适合「能演示、能讲解、能验收」的 LVC 决策飞轮。
选 AFSIM 的场景：六自由度轨迹、复杂传感器模型、工程级硬件在环——OpenNexus 不否认 AFSIM 在这类指标上更强，但那是另一条产品线的成本结构。全面换栈会把已通的 Brain→WPF→Command 链路推倒重来。
Command 为壳，AFSIM 可侧挂
短期：Command 继续担任任务级仿真壳——Brain BFF 锁 fusedId，MultiLLM 写 atomic_tasks，WPF Swarm 分解后经 NamedPipe 驱动 Command Mission。
中期：通过 MDW 的 DIS 1278 / ACMI 2.2 把 AFSIM 作为侧向高保真引擎接入——Command 仍管 ORBAT 与任务逻辑，AFSIM 可接管特定平台的 6-DOF 轨迹回放。两引擎并行，而非二选一换血。
Command vs AFSIM · 能力泳道对比
联调时指着此图讲：左泳道是 OpenNexus 已投资且已跑通的路径；右泳道是可选增强，通过中间件协议并入，而非替换 Command 本体。
工程落地细节
为何 DB3K505 是选型硬约束
Command 内置 DB3K505 派生库（与 zbsj.opennexus.fun 装备库同源语义）意味着平台 ID、挂载、性能参数在 ZBSJ、Brain 映射层与仿真实例之间不需要二次翻译。AI 参谋若 hallucinate 出库里不存在的平台型号，PromptOps 预检与 db:* commit Gate 会在进入 Mission 之前拦截——这是 AFSIM 侧挂方案也必须遵守的 OpenNexus 不变量。
十类原子任务如何映射 Mission
OpenNexus 把 LLM 输出约束为十种封闭类型（侦察、巡逻、打击、护航、压制、撤离等），每种类型对应 Command 的 Mission 模板与 Doctrine 条令片段。MultiLLMCoordinator 合并战区参谋输出后，TacticCommandMapper 将其翻译为 WPF Swarm 可执行的战术单元，最终经 NamedPipe 写入 Command 的 Mission 队列——浏览器与 Gradio 前端不得直写仿真，这是 INV-01 写口纪律。
Demo 与联调入口
现场演示与验收请走已部署实例：cmo.opennexus.fun（Command Web 化壳）、zbsj.opennexus.fun（装备库查阅与映射预检）。选型结论最终要落到 verify 脚本变绿，而非 PPT 上的引擎 Logo 对比。