你的 AI 试点已经跑通了——真实的传感器、真实的推理、来自运营一线的真实反馈。它接下来要承担的责任更重：一次面向完整机器人单元、AGV 车队、整车项目或多站点电网部署的生产级铺开。其中每一项都会暴露出试点尚可容忍、而生产系统无法容忍的缺口——超出 PLC 扫描周期的延迟尖峰、传感器漂移下的模型精度退化、一个在实验室里非正式达成、却从未为认证工程师整理成文档的安全边界。这正是 Hyperion 生命周期中的 Ship（交付）阶段：一段为期 12 周的嵌入式协作，将一个跑通的边缘或嵌入式 AI 试点，依次推进就绪评估、评测与可观测性、安全与合规强化，以及在受限硬件上的扩展就绪。我主导设计了 Auralink——170 万行生产代码、约 20 个自主智能体在无人工干预下解决 78% 的事件、arXiv 2603.08736——并已将 10 个 AI 项目推向生产，其中包含自主物理系统方面的工作。物理 AI 试点的失败模式会反复出现；解法是已知的；而顺序至关重要。
在实验室里行得通的延迟表现，到了生产负载下却违反运营 SLA。你的试点在一台开发用 Jetson 上每秒跑一次推理调用，没有并发会话。生产则意味着八个机器人单元共享一个计算节点，或四十台 AGV 同时打向车队推理服务，或一个整车 ECU 要在 PLC 扫描周期预算内处理一次安全攸关的感知请求。第一次真正撞上并发负载时，你才会发现瓶颈到底出在模型服务、OT 网络延迟、CAN 总线时序预算，还是推理框架的线程模型——而且你是当着运营团队的面发现的，而铺开正取决于他们的批准。
安全边界是在实验室里非正式达成的，从未为认证评审整理成文档。你的安全工程师为演示目的非正式地接受了试点输出，但并没有为生产部署接受它。要进入生产，你需要一份书面的危害分析、一份失效模式覆盖文档、边界违规测试结果，以及一份风险管理记录——而这些都不存在。如果生产铺开已经排上了日程，你却要从零开始做文档工作，试点就会卡在一场动辄数月的认证评审里。
传感器漂移与标定差异，在生产环境中引发模型精度崩塌。试点是在受控条件下、用刚标定过的传感器跑的。生产则意味着已经运行了十八个月、存在热漂移的传感器，一个 ML 团队从未验证过的固件版本，以及维护团队早已学会容忍的偶发电气故障。生产铺开后几天之内模型精度就崩塌，而运营团队分不清到底是模型坏了、传感器坏了，还是集成坏了。
试点针对受限硬件没有任何 AI 专用的可观测性。你没有来自真实边缘计算节点、在真实负载下的延迟分布，没有针对生产环境传感器特性调校过的模型漂移检测，没有受限硬件上的单次推理成本追踪，也没有针对物理系统中真正要命的失效模式发出的告警——漏检、触发执行器指令的误报、回退到失效安全模式的推理超时。在从试点到生产的缺口里，每一起事件都会变成一场把铺开拖后数周的取证作业。
这段协作分四个、每个三周的阶段进行。我与你的团队嵌入式协作——你的工程师负责构建，我带来就绪度排序、物理 AI 评测方法论、安全文档的推进顺序，以及边缘专用的扩展测试。目标不是重建已经跑通的东西；目标是把它强化成一个用证据、而非用希望去通过生产铺开的系统。
围绕物理 AI 的各项生产就绪维度做深度评估：目标硬件上在真实并发负载下的推理延迟、生产环境相对试点环境的传感器数据质量、安全边界文档现状相对认证评审将要求的内容、针对边缘专用失效模式的可观测性覆盖，以及 OT/IT 集成的完整度。每一处缺口按四个层级排序：生产铺开阻断项、安全认证阻断项、运营稳定性风险，以及强化待办。每一项都附上工作量估算与责任人建议。
一条为物理 AI 而建的评测流水线：真实硬件上在真实并发负载下的推理基准、用于测量精度退化边界的传感器漂移仿真、失效模式注入测试（传感器故障、网络分区、执行器指令超时），以及在目标边缘硬件而非云端仿真器上运行的回归测试套件。面向受限硬件的 AI 专用可观测性：单次推理延迟分布、传感器漂移检测、失效安全切换日志、单次推理成本追踪，以及运营团队无需 ML 训练即可读懂的仪表盘。
认证评审需要、而试点没有产出的那套安全文档：书面危害分析、失效模式覆盖文档、边界违规测试结果、风险管理记录，以及在系统落入 EU AI Act 高风险分类（附件 III）时所需的附件 IV 技术文档。对受监管环境，证据链按对应的管辖标准来构建——汽车领域的 ISO 26262、工业领域的 IEC 61508、机载系统的 DO-178C、机器人领域的 ISO 10218。在需要之处，按 IEC 62443 编制 OT 网络安全文档。三周内做对；临到最后才做错，则要拖上数月。
在真实的生产规模上做负载测试——完整机器人单元、完整 AGV 车队、完整整车项目——在目标边缘硬件上、把真实 OT 网络纳入回路。瓶颈识别与修复：推理框架线程、模型量化档位、批大小策略、CAN 或 OT 网络延迟预算、计算节点热降频。对我们选择在本次铺开规模下接受的缺口，记录权衡取舍，并标明随着规模扩大运营团队应关注的信号。铺开排期：与安全工程师商定的逐单元、逐车或逐站点扩展计划。
拥有在实验室里跑通、却无法通过安全认证评审或 OT 集成验收测试、从而无法完成完整生产铺开的机器人单元或 AGV 试点的制造商。拥有达到台架精度目标、却从未在整车 ECU 上以真实并发请求速率做过负载测试的 ADAS 或 AD 试点的汽车 OEM 与 Tier-1 供应商。在某一座变电站拥有预测性 AI 试点、却从未为多站点网格边缘铺开做过验证的能源公用事业。任何运营方，只要其试点带有真实传感器、生产铺开已排上日程、且团队清楚当前系统并非为即将到来的局面而建。这不适合试点仍是一个 notebook 或一次云端演示的团队——那些组织需要先做 Physical AI Deployment 服务或 Strategy Sprint。它同样不适合没有工程能力来参与嵌入式协作的组织；这套交接模式假定有一支团队会在第十二周之后掌管该系统。
因为试点是为实验室条件而建的：全新的传感器、单会话负载、非正式的安全边界共识，以及宽容的评审者。生产铺开会成倍放大并发负载，引入传感器漂移与标定差异，要求一份能撑过正式评审的成文安全论证，并把系统摆到运营工程师面前，而铺开正取决于他们的接受。在我第一周评估的试点里，约有三分之一比团队以为的更接近生产就绪——在这类情形下，协作会聚焦于具体缺口，而非整套流程。我会在第三周如实告诉你。
对于 ISO 26262 ASIL-C 或 ASIL-D 下的高风险系统，或 DO-178C 下的机载系统，安全文档工作可能超过三周。在这类情形下，安全强化阶段会扩展，我会在第一周明确界定其范围。一个需要完整 ASIL-D 分解与公告机构评审的系统，与一个只需书面危害分析和 IEC 62443 区域文档的系统，是截然不同的范围——而我会在协作开始之前就把这点说清楚，而不是等它跑了六周之后。
可以。你的自动化合作伙伴掌管 PLC 环境、OT 网络以及系统集成层。我掌管 AI 专用的生产就绪——目标硬件上的推理性能、安全文档、物理 AI 可观测性，以及扩展测试。我们每周碰一次，让各自的工作成果相互对齐，尤其是在 OT 集成与安全文档这两块，自动化合作伙伴对生产环境的了解是不可或缺的输入。
对物理 AI 系统而言，EU AI Act 的适用范围相当可观。自主与工业 AI 系统通常落入附件 III 的高风险类别。安全与合规强化阶段会按风险分类所要求的层级，产出附件 IV 技术文档与上市后监测计划。对需要公告机构评审的系统，那是一条与本次协作并行的独立轨道；我会在第一周根据你的风险分类界定其范围。
30 分钟。我会诊断你的处境，坦诚告诉你这项服务是否合适——如果不合适，什么才合适。