工业场景AMR产品（面向研发）的需求范本

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

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

1. 需求范式的基本主张

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

功能（Feature）只是手段；你真正交付的是：
在扰动与约束下，系统仍能维持的吞吐、时效、安全、可用、可恢复的边界。
因此需求必须能回答：
"系统在什么条件下，表现出什么稳定现象；超界时如何退化；如何被证据证明。"

1.2 需求表达必须"三件套"

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

现象契约（Phenomenon Contract）：可测、可回归的结果签名
约束与超界动作（Constraints & Fallback）：边界与退化模式
证据链（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 类）

安全：零碰撞 + 近失上限 + 危险动作禁止
时效：任务完成时延 P95/P99
吞吐：单位时间完成量与峰值退化曲线
可用：任务服务可用性、关键链路可用性
能量：趴窝率、充电成功率、SOC 预测误差
韧性：异常恢复 MTTR、降级覆盖率

C2. 写法模板

在条件集合 K 下（地图版本一致、网络延迟<...、人流密度<...、任务到达率<...）
系统应维持现象 P（OTDR≥...、P95时延≤...、近失≤...、吞吐≥...）
若任一约束超界，则执行退化策略 F（冻结派单/降速/局部封路/请求人工接管...）
并产出证据 E（trace_id、map_version、policy_version、robot_id、task_id、事件序列）

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

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

安全硬约束（不可违反）

最小安全距离、限速、禁行区、路口让行、人机混行规则
超界动作：急停/软停/原地等待/安全员确认/切换保守策略

实时约束

调度周期、交通控制响应、车端控制响应、站点交互超时
超界动作：本地避障优先 + 派单冻结 + 短视重规划

可观测性约束

定位置信度阈值、地图一致性、时钟同步、传感器健康
超界动作：降级交通模型（区域占用/灯控）+ 禁止进入关键路段

运营制度约束

优先级规则、节拍窗口、工艺禁区、班次策略
超界动作：生成例外工单 + 切换策略配置 + 留痕审计

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功能"改写成下面三种句式之一：

现象句式

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

约束句式

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

证据句式

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

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

MVP 不是"功能少"，而是：

现象域只保留 3 个：安全 + 时效 + 可用
断点卡片只做 15 张：每类 2 张（覆盖最高风险）
证据链先保证 6 键 + 车端轨迹 + 派单决策 + 路口仲裁
门禁至少做到 G0+G1（否则越迭代越不可控）