完整案例
Factory Digital Twin Command Center
把可交互 3D 工厂与一张电子制造订单的物料、排产、质量和交付闭环放进两个清晰分开的模拟工作区，由确定性状态与人工决策驱动。
核心问题只看生产线状态还不足以判断一张客户订单是否能兑现：库存缺口会改变采购与可承诺日期，产能扰动会改变生产完成时间，质量暂扣会阻止可用库存，仓库操作才会将良品变成已发运订单。该 Product 因而把空间化工厂观察与订单到交付决策组织为两个显式分开的模拟工作区，避免把局部 Build 拼成虚假的企业系统集成。
进入 3D Factory Twin ↓系统 / 集成边界包含两个分别初始化与重置的浏览器内模拟：5 线 Factory Twin 与单张电子制造订单履约；订单聚合复用 Twin 的纯函数时钟和 L5 产能定义，不与 3D Twin 会话状态同步，也未调用 LLM；ERP / MRP、APS、MES / MOM、QMS、WMS、TMS 仅为业务语境，未连接任何企业服务、PLC、SCADA 或 IoT.
正在加载 3D 工厂工作区…
加载完成后可拖动旋转、缩放并检查每个工位。深入材料架构判断、证据与限制主流程已经结束；需要审查设计判断时再展开。
概览
问题 → 工作流 → 系统。
案例从真实运营问题开始，而不是从技术栈开始。
这是一个浏览器原生的制造运营模拟 Product，提供两个有意分开的工作区：5 条产线的 3D Factory Twin，以及一张电子制造客户订单从交期承诺、物料齐套与采购恢复、L5 生产、质量放行到仓储发运的端到端闭环。工厂工作区的设备状态、WIP 与指标来自确定性 Twin State；订单工作区由单一确定性聚合状态管理订单、库存、采购单、工单、质量批次和发运单，并复用 Twin 的 L5 产能与仿真时钟。两个工作区分别初始化和重置，不声称接入彼此的线上系统或真实 ERP、APS、MES、QMS、WMS、TMS。
业务规则
系统必须遵守什么。
业务规则本身就是架构的一部分。
- 5 条产线均由 4 个工位组成，产线吞吐由最严重的工位状态约束；设备故障、阻塞和缺料会直接降低该线实际产出。
- 设备故障会导致上游 WIP 堆积、下游缓冲耗尽；物料短缺会沿下游传播；EOL 质量冻结会向上游形成回堵。
- Plant Throughput、吞吐目标达成率、WIP、Late Units、Service Risk 与 Energy Proxy 全部从当前 Twin State 计算，不由 AI 生成。目标达成率 = 当前模拟吞吐速率 ÷ 目标吞吐速率，限制在 0–100%；没有计划生产时间、运行时间、总产量和良品数量，因此不计算 OEE。
- 恢复方案必须包含时间、增量成本、预计产出、Service 和可检查约束；违反质量 Gate 的方案会被代码直接拒绝。
- 候选方案不会自动执行；只有用户明确批准后，Twin Engine 才应用允许的状态转换。
- 运营摘要由当前 Twin State 确定性生成，无需 AI Runtime；摘要只说明模拟状态，不输出控制动作。
- 订单工作区的 SO-1007 包含 30 台 INV-24，BOM 需求为 PCB ×1、电源模块 ×2、外壳 ×1、风扇 ×1；基线电源模块净短缺 20 件，只有 Buyer 批准后 4 小时在途 ETA 才进入覆盖计算。
- 销售承诺只记录由已知物料、L5 产能和 2 小时模拟运输计算出的最早可交付小时，并保留尚未发生的人工计划与放行假设；后续采购延误不会静默改写已承诺日期，而会改变当前预测并可显式显示为风险或逾期。
- 计划员接受订单后才可规划工单；Production 角色放行后才执行模拟产量。L5 故障期间无产出，维修确认后恢复；每批均须由质量角色记录检验，冻结批次不能拣配，完整订单只有质检放行后才能由仓库拣配、发运并在两小时后送达。
- 订单工作区拥有独立初始化与 Reset 生命周期；它复用 Twin 的确定性时钟和 L5 线速定义，但不读取或写入可视化 Twin 当前会话状态。
产品决策
哪些判断真正改变了设计。
关键权衡保持可见，而不是被实现细节淹没。
- 不使用 Blender 或任何本地资产制作链路；第一版设备几何体全部由浏览器端 Three.js 程序化构建，保证 ChatGPT / GitHub / Vercel 工作流可以完整维护。
- 不把高面数模型当作成熟度指标；优先证明 3D 对象与业务状态使用同一 Twin State，而不是制作更精细的静态资产。
- 把 Three.js 限定为 View Layer；核心状态、异常传播和 What-if 逻辑放在独立 TypeScript 模型中，可以脱离 3D 重放和测试。
- 第一条 Guided Scenario 使用 Line 3 主轴轴承故障，因为它能同时展示设备信号、上游阻塞、下游缺料、全厂 KPI 与恢复权衡。
- 同时保留物料短缺和质量冻结两个额外场景，用来证明 Twin Engine 不是只为单一动画脚本写死。
- 恢复方案采用 deterministic candidate + human approval；运营说明从当前 Twin State 确定性生成，不增加 LLM 调用。
- 质量场景故意包含一个“直接解除冻结”的诱人方案，并由 Hard Constraint 拒绝，用负向证据证明系统知道什么时候不能执行。
- 不新增数据库：当前 Product 的目标是可重复的工厂运行仿真与决策证明，跨会话持久化不是必要条件。
- 订单履约流程使用独立的订单工作区和单一聚合状态；它复用 Twin 的纯规则时间与 L5 产能定义，但不把当前 3D Twin 操作状态伪装成 MES 实时订单状态。
- 不把现有订单承诺、MES 执行、QMS 闭环、WMS 出库等独立 Build 描述成已经互相集成的服务；它们是可单独检查的能力证据，新的工作区按自身有界规则重建一条合成订单。
证据
验证这些结论。
每一项证据都应该支持 Product 的一个具体结论。
- Demo交互式 3D Factory Twin
5 条产线 × 4 工位；可旋转 / 缩放 / 点击检查；设备、WIP、AGV、异常与 KPI 使用同一运行状态。
- Demo电子制造订单到交付工作区
同一订单穿过物料与采购、交期承诺、L5 生产、质量关口、仓储拣配和模拟运输；供应商延误、产线停机和质量暂扣会改变可见的下游状态。
- 架构订单履约规则与事件来源
CODE 计算物料净短缺、承诺投影、产能和状态转换；采购、销售、生产、质量与仓库负责人分别确认其高影响操作。
- 架构确定性 Twin Engine + 人工授权边界
状态传播、KPI、What-if 与运营说明由代码负责；高影响仿真动作保留人工批准。
- 评估13 个 Digital Twin Evaluation Fixtures
覆盖基线生产、设备故障传播、物料缺料、质量 Gate、恢复效果、不可变状态与 deterministic replay。
- 评估订单到交付确定性回归
针对承诺锁定、物料短缺与采购 ETA、产能停机、批次质量关口、仓库拣配、发运、重复命令和 Reset 的有界规则检查。
- 源码实现源码
Next.js + TypeScript + Three.js；不依赖 Blender、本地资产管线、新数据库或额外云服务。
限制
这个 Product 不声称什么。
成熟度只能建立在现有证据真正支持的范围内。
- 这是明确的模拟工厂 Digital Twin，不是对真实 PLC、SCADA、MES、APS、WMS 或 IoT 设备的在线镜像。
- 订单工作区中的客户、供应商、BOM、库存、PO、产线、质量结果、运输和角色都是合成数据；它不是第二个 Build 的 API 组合，也未连接 ERP、APS、MES / MOM、QMS、WMS / WES、TMS、供应商或承运商服务。
- 两个工作区各自保存会话内模拟状态；它们共用确定性 Twin 代码定义，但不是互相同步的工厂状态，也不表示企业范围的跨系统事件总线。
- 设备健康、温度、振动、WIP、产能、成本和 Service 数据都是受控模拟数据，不代表任何真实工厂绩效。
- 当前物理模型是离散状态与流程传播，不是高保真物理仿真、有限元分析或机器人动力学模型。
- 3D 资产为程序化低多边形几何体，没有 CAD / BIM / Blender 资产导入、碰撞检测或真实空间测量。
- AGV 路径用于表达厂内物流上下文，不代表已经实现调度优化、避障或交通控制。
- 当前没有 AI 生成的订单解释或运营结论；两个工作区均以明确规则展示已知事实、投影依据与尚未完成的人工假设。
- 恢复方案验证的是当前受控规则集；只有明确状态冲突会被 Hard Constraint 拒绝。库存、订单、质量结果、人员、维护、工艺与真实可用产能未被完整建模，因此相关候选保持需复核，不声称覆盖真实工厂全部约束。
- 上线到 Winston Builds 生产网站只证明 Web Product 可运行，不代表已经部署到工业生产环境。