怎么读这套页
先看玖衍 FAQ 的一句话结论，再进对应专题页。每页固定三段：从哪来（问题与遗产）、为什么（选型理由与反面）、怎么做（契约、接口、Gate）。图不是装饰，而是联调时可指着讲的结构。
战场失败的真实根因
往往不是「模型不够大」，而是 ID 对不上、写口不唯一、协议各说各话、训练/实战风险边界模糊——这些遗留烟囱逼出了 OpenNexus 的技术选择。
成本、可讲解、可验收
选型优先「教学演示 + LVC 铰链 + AI 闭环」总成本，而不是单点指标碾压。每个技术点都能在 Demo 上指着屏幕验收。
契约 + 写口 + Gate
fusedId / DB3K、WPF :5000 唯一写口、LvFlightPlanV1、原子任务封闭语言、train/live 策略切换——写成不变量，再用 verify 守住。
七篇技术细节论述
每篇可独立阅读；合起来就是 OpenNexus LVC 决策飞轮的工程说明书。
CMO / Command 仿真选型
为何锚定 Command 而非全面换 AFSIM：本体已建、LVC 铰链已通、AI 要「简单动作语言」。
阅读论述 →PromptOps 与指挥员信任
信任来自封闭原子任务、条令溯源与 HITL，不是参数规模；提示词是多层约束栈。
阅读论述 →LVC 训练 / 实战双模式
同一指挥壳、两套风险策略：train 跑通流程，live 强制异构执行 + 人审 + JUDGE。
阅读论述 →本体论 · fusedId · DB3K505
统一库不是又一个 SQL 中台；是装备主键 + 运行时融合 ID + 映射策略的咬合。
阅读论述 →中间件协议栈
ACMI / DIS / DDS / NamedPipe / JSON 如何各司其职，把「看见战场」压到 E2E <200ms。
阅读论述 →多 LLM → 蜂群 → Command
战区参谋并行写 atomic_tasks，WPF 蜂群分解，NamedPipe 落地——浏览器不得直写仿真。
阅读论述 →杀伤链 · ATO · 飞行计划
单目标串行 OODA：锁 fusedId → 映射 → Command 生成 LvFlightPlanV1 → 审核下发 → BDA。
阅读论述 →技术点落在哪一层
上层解决「看见与研判」，下层守住「能实例化、能下令、能复盘」。相关技术深读页分别钉在这些层上，避免只讲名词不讲落点。