亿迅科技｜具身智能巡检需求设计
把巡检作业拆解为不同业务对象，定义状态、操作条件和异常处理，让管理门户、调度平台与机器人使用一致的业务含义。
参与需求分析、状态规则、事件处置、权限及系统协作梳理。流程图描述需求设计，实施效果以实际验收记录为准。
01 / 为什么要拆分父任务、子任务和机器人状态？
周期性计划可以继续存在，其中某一次执行却可能失败；机器人故障也不应自动等于整个计划终止。
需求材料分别定义父任务 5 类、子任务 7 类、机器人 7 类状态，并包含暂停、超时和人工接管等场景。
先确定是计划调整、执行中断还是设备异常，再判断它对另外两个对象的影响。
父任务表达巡检计划；子任务记录一次执行；机器人状态约束是否能调度与恢复。
界面字段较少，但难以说明一次失败是否影响后续计划，也容易把设备离线误当作任务结束。
异常触发 → 定位对象 → 记录状态 → 检查时间窗口、设备与电量 → 决定恢复或终止。
逐项核对前置条件、触发事件、下一状态和允许操作；统一状态图与需求表的评审版本。
依据：功能需求表第 27、41、46–48 行及任务状态图。版本统一与验收表达为复盘建议。
02 / 为什么任务完成不等于事件关闭？
机器人完成巡检后，发现的问题可能仍需值班人员确认和处理。若两个状态同步关闭，异常会失去后续责任人。
任务执行反馈由设备和平台提供，安全等事件需要人工确认，并保留处置动作与追溯记录。
任务记录执行结果；事件记录发现的问题、责任人、处理过程和关闭条件。
重复事件先聚合，按级别通知；由相应人员处置和确认关闭，再回到报告复盘。
列表会更整洁，但尚未处理的问题可能被提前标记为完成，无法体现人工处置责任。
事件接入 → 分类聚合 → 分级通知 → 人工处置 → 确认关闭 → 复盘。
验证重复通知、任务结束但事件未闭环、无权关闭及关键操作审计等场景。
依据：功能需求表第 84–139 行的事件与权限规则，原作品集业务流程中的任务结束与问题处理区分。验证场景为复盘建议。
产出与进一步阅读
- 设备接入、任务配置、调度执行、事件处置与报告复盘的业务链路。
- 父任务、子任务、机器人三类状态，以及暂停、恢复、超时和人工接管规则。
- 事件分类分级、角色与区域权限、门户与 RCS 双向数据流及协作边界。
流程图依据已提供材料重新组织，用于说明设计逻辑。“方案 B”为复盘时的比较项，不表示当时曾正式评审；后续验证与实际已完成的工作在对应节点中分别说明。