3.7 KiB
3.7 KiB
00-Ops领域总览
本文档是 AIOT 平台 Ops（人工作业）领域的核心入口。 Ops 领域是平台当前的第一阶段核心基本盘，主要处理由人执行的各项业务流转。
一、业务边界定义
Ops 领域负责：
- 工单的完整生命周期管理（创建、派单、抢单、执行、挂起、验收）。
- 具体业务场景的人工作业标准（如保洁打卡、安保巡检）。
- 现场人员的排班与绩效数据基础收集。
Ops 领域绝不负责：
- 设备底层协议解析：Ops 不关心设备是 MQTT 还是 HTTP 报文，它只接收 IoT 领域转化后的标准"事件"。
- 硬件实时控制：Ops 不直接发指令给设备，若工单需要反控设备，必须调用 IoT 领域的内部 API。
- 财务计费结算：Ops 只记录耗时和耗材，真正的结算和财务账单属于更上层的计费域。
二、当前落地状态
| 模块 | 状态 | 说明 |
|---|---|---|
| 基础工单状态机 | 🟢 已实现 | PENDING -> ACCEPT -> PROGRESS -> COMPLETED 闭环已通 |
| 工单队列系统 | 🟢 已实现 | 基于 OrderQueueStatusEnum 的公共队列，支持 P0 打断机制 |
| 抢单/派单基础逻辑 | 🟢 已实现 | 基础区域派单与并发抢单控制（基于 Redis）已上 |
| 安保巡检路线 | 🟡 建设中 | 基础空间树复用完成，防作弊打卡待深化 |
| 保洁耗材管理 | 🟡 建设中 | 耗材库存扣减与工单的事务一致性仍在打磨 |
| 智能派单算法 | 🔴 规划中 | 下阶段迭代，基于位置与手头任务数的智能派发 |
| 复杂异常流转 | 🔴 规划中 | 超时自动退回、不可抗力挂起的补偿机制待完善 |
三、核心基础设施
3.1 工单状态机 (WorkOrderStatusEnum)
所有 Ops 工单（保洁、安保、维修、客服）共享统一的状态流转：
PENDING(待分配) →QUEUED(排队中) →DISPATCHED(已推送) →CONFIRMED(已确认) →ARRIVED(已到岗) →COMPLETED(已完成)- 详见：01-工单生命周期与状态机.md
3.2 工单队列系统 (OrderQueueStatusEnum)
公共基础设施，所有需要排队调度的工单类型（目前主要是保洁）都依赖此系统：
- 队列状态：
WAITING(等待中) →PROCESSING(处理中) →PAUSED(暂停中) →REMOVED(已移除) - 核心能力：P0 紧急任务可打断当前执行中的低优先级任务
- 排序算法：基于
queueScore = 优先级分数 + 时间戳的复合排序 - 详见：02-工单队列系统.md
四、下属核心文档阅读指引
在深入具体业务前，请按以下顺序阅读：
- 01-工单生命周期与状态机.md
- 必读。这是所有 Ops 业务的底层底座，搞懂了状态机，就搞懂了代码里的核心 Enum 和边界校验。
- 02-工单队列系统.md
- 必读。理解工单如何在队列中排队、如何被 P0 紧急任务打断、如何计算优先级分数。
- 03-保洁业务核心链路.md
- 偏向"抢单执行与过程留存"，重点看并发控制和防篡改。
- 04-安保业务核心链路.md
- 偏向"空间巡检与突发响应"，重点看基于空间的点位设计和告警强推。
- 05-保洁巡检与归属判定链路.md
- 保洁特有的巡检业务，重点看基于停留时长的归属判定算法。
五、协作约束
- 状态机不可私增：前端/移动端绝对禁止硬编码状态流转逻辑。所有合法状态流转必须由后端判断，任何新增状态必须先落文档。
- 领域数据隔离：Ops 模块查询设备信息时，允许在工单表里冗余存储当时的设备名称和位置信息，禁止每次都跨模块
JOIN设备表。