机器人架构评审

Purpose

让产品经理能围绕任务闭环、交付指标和系统风险参与架构评审。重点是验证架构能否达成产品目标并可部署运维，而不是评价代码风格或替研发负责人画最终架构。

Input

可提供架构图、模块清单、接口文档、数据流、时序、技术方案或一段口头描述。资料不足时先画概念架构，并把缺失的接口、预算和失效信息列为评审问题。

示例：使用 robotics-architecture-review，评审一套ROS 2轮式机器人从调度到电机控制的方案。

Key Concepts

• 任务链：任务系统 -> 行为决策 -> 路径/运动规划 -> 控制 -> 驱动器/执行器。
• 反馈链：传感器 -> 驱动/时间戳 -> 状态估计/感知 -> 世界表示 -> 规划与安全。
• 横切平面：安全、诊断、数据、配置、身份权限和运维贯穿所有模块。
• 预算：端到端延迟、控制周期、带宽、算力、内存、功耗、热和电池均需分配。
• 故障边界：每个模块必须说明失效如何发现、隔离、降级、恢复和记录。

Application

1. 对齐评审问题

先写本次架构必须回答的产品问题，例如“是否支持目标人流下安全导航”“断网能否完成当前任务”“单传感器失效是否进入安全状态”。避免无边界的通用评审。

2. 重画端到端链路

从用户/业务系统触发开始，画到物理动作和完成确认。标出本体、边缘、云端、人工和第三方系统边界；列出关键数据、控制命令和反馈。

3. 检查接口契约

对关键接口记录：生产者、消费者、数据结构、单位、坐标系、时间戳、频率、延迟、超时、QoS、版本、权限、重试、幂等和错误码。控制命令必须说明生效条件与撤销方式。

4. 检查六类预算

1. 实时与端到端延迟
2. 计算、内存和存储
3. 网络带宽与断连
4. 功耗、峰值电流与续航
5. 热、噪声和环境降额
6. 数据量、上传成本与保留周期

总预算应由关键路径逐层分配，不能只列单模块峰值。

5. 走查故障场景

至少演练：传感器遮挡/漂移、定位丢失、规划失败、执行器过温或通信中断、低电、上位系统失联、地图/模型版本不兼容、升级失败、人工急停和任务恢复。

6. 检查产品化能力

使用 架构评审清单，覆盖可观测性、配置、校准、部署、灰度、回滚、远程诊断、数据闭环、权限、隐私和现场维护。

7. 输出评审结论

按严重级别记录：

• Blocker：无法安全运行或无法完成核心任务。
• High：试点或规模部署前必须关闭。
• Medium：有绕行方案，但影响成本、性能或运维。
• Low：可计划优化。

每项问题必须包含证据、影响、建议动作、负责人和关闭标准。区分“确认通过”“有条件通过”“需重新评审”。

Examples

轮式调度链路

调度器下发任务并不等于机器人可执行。需要确认任务幂等、地图和站点版本、抢占规则、断线续跑、到站精度、底盘安全控制优先级，以及完成事件能否可靠回传。

人形操作链路

上层VLA输出动作意图时，应审查其如何经过约束检查、运动规划、全身控制和力/扭矩限制；学习策略失效不能绕过独立安全监控与急停链路。

Common Pitfalls

• 盒子图幻觉：有模块框图，没有数据契约和时序。修正：沿关键任务逐条走消息与控制链路。
• 云端依赖未声明：现场断网后任务失控。修正：定义离线边界、缓存、超时和安全状态。
• 安全与业务共用单点：同一故障同时破坏控制和保护。修正：识别独立性与故障隔离要求。
• 只评性能不评运维：实验室能跑，现场无法诊断升级。修正：把日志、配置、回滚和校准纳入架构门槛。

References

• 架构评审清单
• 可衔接 robotics-capability-technical-map、robotics-safety-reliability