一种具身机械主义解释框架下的范式

具身机械主义的解释框架 —— 一种关于具身智能的规范性说明

1. 需求范式的基本主张

1.1 需求对象不是“功能”，而是“稳定现象”

• 功能（Feature）只是手段；你真正交付的是：
  在扰动与约束下，系统仍能维持的吞吐、时效、安全、可用、可恢复的边界。

• 因此需求必须能回答：
  “系统在什么条件下，表现出什么稳定现象；超界时如何退化；如何被证据证明。”

1.2 需求表达必须“三件套”

每条关键需求都必须同时给出：

1. 现象契约（Phenomenon Contract）：可测、可回归的结果签名

2. 约束与超界动作（Constraints & Fallback）：边界与退化模式

3. 证据链（Evidence Chain）：能复现、能归因、能门禁的证据要求

---

2. 《AMR 需求规格书》标准目录（可直接套用）

A. 场景与边界

A1. 工厂语境（必须写清）

• 车间类型：[离散/流程/混合]

• 物流对象：[料箱/托盘/半成品/工装/危化品?]

• 关键站点：[入库/线边/工位/检测/缓存/出库/充电]

• 路网特征：[窄通道/单行/交叉口密度/电梯/门禁/坡道]

• 混行对象：[行人/叉车/牵引车/AGV/无人叉车]

• 运营制度：[班次、节拍、优先级、禁行时段、EHS 规则]

A2. 系统边界（反常识但关键）

• AMR 不是“车+调度软件”，而是“车队+路网+规则+站点交互+人因流程”的联合系统

• 明确不在范围：例如「WMS/ERP 不改」「工位工装不改」「只做 X 条线」「不做视觉拣选」等

---

B. 角色与协作机制

B1. 角色清单

• 现场操作员 / 线边物料员 / 叉车司机 / 班长

• 运维工程师（网络/IT/OT）

• EHS/安全员

• 计划/物流调度员

B2. 人机协作契约

• 谁能下发任务？谁能取消？谁能暂停/恢复？

• 人工介入的触发条件是什么？介入后系统如何接管回来？

• 关键原则：把“人工兜底”当作机制的一部分显式写进需求（否则上线必崩）

---

C. 现象契约（SLO/SLA 级）

把目标写成“稳定性签名”，而不是“支持XX功能”。

C1. 交付现象域（建议固定 6 类）

1. 安全：零碰撞 + 近失上限 + 危险动作禁止

2. 时效：任务完成时延 P95/P99

3. 吞吐：单位时间完成量与峰值退化曲线

4. 可用：任务服务可用性、关键链路可用性

5. 能量：趴窝率、充电成功率、SOC 预测误差

6. 韧性：异常恢复 MTTR、降级覆盖率

C2. 写法模板

• 在条件集合 K 下（地图版本一致、网络延迟<…、人流密度<…、任务到达率<…）

• 系统应维持现象 P（OTDR≥…、P95时延≤…、近失≤…、吞吐≥…）

• 若任一约束超界，则执行退化策略 F（冻结派单/降速/局部封路/请求人工接管…）

• 并产出证据 E（trace_id、map_version、policy_version、robot_id、task_id、事件序列）

---

D. 约束声明（需求里必须“像合同一样写”）

把约束按四类写清，并定义超界动作：

1. 安全硬约束（不可违反）

• 最小安全距离、限速、禁行区、路口让行、人机混行规则

• 超界动作：急停/软停/原地等待/安全员确认/切换保守策略

1. 实时约束

• 调度周期、交通控制响应、车端控制响应、站点交互超时

• 超界动作：本地避障优先 + 派单冻结 + 短视重规划

1. 可观测性约束

• 定位置信度阈值、地图一致性、时钟同步、传感器健康

• 超界动作：降级交通模型（区域占用/灯控）+ 禁止进入关键路段

1. 运营制度约束

• 优先级规则、节拍窗口、工艺禁区、班次策略

• 超界动作：生成例外工单 + 切换策略配置 + 留痕审计

---

E. 闭环机制需求（把“系统如何保持稳定”写出来）

用“闭环”替代“功能模块”描述（更可验收、更可治理）：

E1. 任务闭环（Demand → Plan → Execute → Confirm）

• 任务输入：来源、幂等、去重、优先级冲突规则

• 任务状态机：创建/派发/执行/到站/交接/异常/回滚

• 任务确认：站点确认机制（扫码/按钮/PLC 信号/视觉）

• 例外处理：取消/改派/回退/人工完成

E2. 交通闭环（Observe → Reserve/Arbitrate → Move → Release）

• 冲突检测、路口仲裁、区域占用/预定、死锁解除策略

• 重规划触发条件（不要“频繁震荡”）

• 局部封路与临时规则发布流程

E3. 安全闭环（Detect → Intervene → Recover → Report）

• 近失定义（可量化）与触发阈值

• 干预动作优先级（车端>调度端>人工）

• 事故/近失的证据链要求与复盘模板

E4. 能量闭环（Predict → Schedule → Charge → Validate）

• SOC 预测误差上限

• 充电排队策略、充电失败处理、趴窝预防策略

E5. 运营治理闭环（Monitor → Diagnose → Change → Gate）

• 监控指标、断点分类、变更管理、回归门禁、灰度与回滚

---

F. 断点图谱（需求阶段就要写，不要等事故）

至少给出一级断点分类（可直接沿用）：

• 任务输入/世界模型/定位与时间/派单分配/路径交通/执行协同/能量充电/治理与版本
  并规定：每个断点必须有触发阈值、即时干预、必备证据字段、回归用例归属。

---

G. 证据链规格（“没有证据=没有完成”）

G1. 统一关联键（强制）

• event_time（统一时钟）、trace_id、robot_id、task_id、map_version、policy_version

G2. 三层证据

• 车端：pose、速度、局部避障输出、E-stop、传感器健康

• 系统：派单决策、候选集、约束命中、路口仲裁、重规划原因

• 治理：版本对齐矩阵、配置快照、变更审计、覆盖率

---

H. 回归门禁（需求里写清“什么情况不能上线”）

分 4 道门（可直接写进发布流程）：

• G0 静态校验（地图拓扑/规则一致性/配置合法性）

• G1 仿真回归（关键场景 P95 时延/冲突/震荡）

• G2 历史回放（线上事故可复现或差异可解释）

• G3 灰度发布（SLO 不劣化 + 新断点族不出现 + 可回滚）

---

3. 需求写作的“句式规范”（给团队统一口径）

把“支持XX功能”改写成下面三种句式之一：

1. 现象句式

在[条件K]下，系统应维持[指标P]，且在[扰动D]下退化到[策略F]仍满足[安全边界S]。

1. 约束句式

当[约束C]超界时，必须触发[动作A]并进入[降级模式M]，直至[恢复条件R]满足。

1. 证据句式

对于[事件E/断点B]，必须记录[字段集]并可在[工具/回放]中复现到[可判定结论]。

---

4. 最小可交付版本（MVP）如何用本范式定义

MVP 不是“功能少”，而是：

• 现象域只保留 3 个：安全 + 时效 + 可用

• 断点卡片只做 15 张：每类 2 张（覆盖最高风险）

• 证据链先保证 6 键 + 车端轨迹 + 派单决策 + 路口仲裁

• 门禁至少做到 G0+G1（否则越迭代越不可控）

---