园区机器人来自不同厂商，门禁、电梯各归物业和维保，跨品牌任务靠管理员在多个后台重复录入、对讲机现场协调。做这类定制，我第一步从来不画界面，先做资源建模——把异构设备统一成可编排的资源。

资源建模：机器人、门禁、电梯、充电桩进同一张设备清单，每台登记四元组——品牌、接口协议（任务下发怎么调、状态怎么回传）、能力（可巡逻／可送物料／可控门／可控梯）、所属区域。这张表是编排的地基：任务下发时按能力和区域筛设备，不按品牌。加一个新品牌，只是往清单里添一类接口，任务模型不动。

状态边界：设备状态和任务状态是两层，别混。

• 设备状态：空闲、执行中、待联动（卡在电梯口等放行）、故障。回传缺失的品牌，做轮询兜底，但要在清单里标注「状态非实时」——这四个字决定值班策略。
• 任务状态：已下发、执行中、已完成、已取消。执行中任务取消，要结一段执行记录（跑到哪个点位、触发过哪些联动），不能直接删——这段记录是下次调度的依据。
• 联动状态单独记：门禁放行、电梯响应，谁的任务触发的、何时完成。跨系统联动一旦出问题，责任边界靠它划分，不然机器人厂商和物业系统互相甩锅。

字段边界：任务表单里的「时段」允许重叠（两台机器可以同时巡逻不同区域），但同一台设备的任务时段不允许——校验落在设备维度，不是任务维度，这是最容易做反的。「路线」存有序点位序列，点位复用设备清单里的区域编码，不另造一套坐标。

角色与权限：管理员编排并下发；现场人员只读状态看板，无派单权——派和看分开，避免现场越权改任务；值班人接收异常推送并可挂起任务。挂起不是取消，挂起要写原因，恢复要值班人确认，两个动作都留痕。

接口对接的验收线：状态回传缺一家的，这套不算交付完成。只接任务下发的系统，现场永远不知道机器是坏了还是在等门——异常响应慢半拍的根因都在这一层。

实施节奏这块，像素匠人的做法一直是：先资源清单和人工派单，跑通状态回传，再做表单编排，联动条件最后接。
来源：像素匠人