  
> 技术栈：Python、FastAPI、SQLAlchemy、MySQL、Redis、Vue 3  
> 说明：本文基于实际后端实现整理；截图中的柜机、区域、工单和指标均为脱敏模拟数据。

![1.png](https://developer.qcloudimg.com/http-save/yehe-12379527/0605b1a936a16e37366a5ac13e35f63f.png)

## 1. 要解决的问题

热门换电柜经常缺少满电电池，冷门柜却可能长期积压。系统需要在高峰前回答四个问题：

![image.png](https://developer.qcloudimg.com/http-save/yehe-12379527/c74864ea8d94b98ce8a3f906b910d832.png)

我的实现没有让大模型直接决策，而是采用一条可解释、可回放的确定性链路：

> 统计需求画像 + 冻结库存快照 + 硬约束匹配 + 工单状态机 + 事后对账

当前版本属于“统计基线 + 评估基础”，可以进行接口测试和影子调度，但仍需真实业务验收后才能正式自动落单。

## 2. 整体架构

![image.png](https://developer.qcloudimg.com/http-save/yehe-12379527/428b46f27ef532fb733bf52cd21c3cd3.png)

### 核心分层

| 层次 | 解决的问题 | 核心输出 |
| --- | --- | --- |
| 需求层 | 未来需要多少电池 | 1/3/6 小时需求 |
| 供给层 | 当前与窗口内有多少可用电池 | 满电、预计充满、低电、健康空仓 |
| 调度层 | 哪些电池可以安全调拨 | 柜级计划、柜间工单、未满足原因 |
| 评估层 | 预测和调度是否有效 | MAE、WAPE、Coverage、缺货窗口率 |

## 3. 核心数据流水线

![image.png](https://developer.qcloudimg.com/http-save/yehe-12379527/68d68573bf15c594059f0e245d487e9c.png)

### 数据设计亮点

- `event_id` 全局幂等，重复事件不会重复累计需求。
- 失败换电也计入需求，避免热门柜需求被低估。
- 大批量事实使用 MySQL `INSERT ... SELECT ... GROUP BY`，不把百万级日志加载为 ORM 对象。
- 画像使用暂存表和事务原子发布，失败时保留上一版正式结果。
- 预测冻结画像批次、库存批次、模型版本和库存事件版本。
- 每个缺口组合都生成计划项，即使最终匹配数量为 0，缺口也不会“消失”。

## 4. 库存批次：给预测冻结一个可信现场

![image.png](https://developer.qcloudimg.com/http-save/yehe-12379527/ee63e8a3bf198805a0944a65987c3a51.png)

关键原则：

- MySQL 是权威来源，Redis 只是加速器；缓存失败自动回源。
- 总仓数来自柜机主数据，满电阈值来自电池类型主数据。
- 最新库存和预测绑定库存分开保存，不能用新库存反向解释旧预测。
- 正式调度前还会比较库存事件版本，库存变化就要求重新预测。

## 5. 预测与缺口计算

![image.png](https://developer.qcloudimg.com/http-save/yehe-12379527/3335d256aebb197d6f7275b708bfc7db.png)

核心公式：

```text
健康仓位 = 总仓位 - 坏仓位
可用容量 = min(类型容量, 健康仓位 - 固定预留空仓)

窗口预计可用 = 当前满电 + 窗口内预计充满
行动窗口缺口 = max(行动窗口目标 - 窗口预计可用, 0)
1小时缺口 = max(1小时最低保有量 - 1小时预计可用, 0)

正式缺口 = max(1小时缺口, 行动窗口缺口)
满电富余 = max(当前满电 - 行动窗口目标, 0)
```

取两个窗口的最大缺口，是为了避免“三小时后能充好”掩盖“第一小时已经没电”。

![2.png](https://developer.qcloudimg.com/http-save/yehe-12379527/75cc5492b6ce58e1b8fe37a8c0c8d279.png)
> 图中柜机编号、区域、运行号和业务量均为模拟数据。

## 6. 调度算法

![image.png](https://developer.qcloudimg.com/http-save/yehe-12379527/40a3f186479f29e0ad679853e2bfa90c.png)
![image.png](https://developer.qcloudimg.com/http-save/yehe-12379527/8357bee6fe81b116bace7d859792684e.png)
### 算法亮点

- 最小预测单元是“柜机 + 电池类型”，物理空仓却按整柜共享。
- 目标柜空仓不足时，可以配套带回其他兼容类型的低电池。
- 行动窗口内即将充好的低电池禁止调出，避免重复计算供给。
- 来源柜和目标柜都必须保留固定安全空仓。
- 来源、目标严格限定在同一区域，禁止跨城市调度。
- 多轮匹配会继续利用前一轮调出后释放的仓位。
- 无法满足时明确记录富余不足、距离超限、仓位约束等原因。

## 7. 影子调度与正式调度

![image.png](https://developer.qcloudimg.com/http-save/yehe-12379527/38bbf31df5a022b3170ffd5498383e87.png)

| 能力 | `shadow` | `live` |
| --- | --- | --- |
| 历史回放 | 支持 | 不支持 |
| 外部工单 | 强制禁止 | 受配置控制 |
| 库存事件版本校验 | 否 | 是 |
| 在途正式工单预占 | 不读取 | 必须扣除 |
| 推荐用途 | 算法验证、人工对照 | 真实业务执行 |

正式模式会扣除未完成工单占用的来源满电、目标调入、目标空仓和目标低电。库存快照更新不会自动释放预占，只有工单进入终态才释放。

![3.png](https://developer.qcloudimg.com/http-save/yehe-12379527/670dd9ae238593ed80cbcce40e102f2d.png)

> 图中使用影子模式与模拟工单，不包含真实业务数据。

## 8. 工单状态机

![image.png](https://developer.qcloudimg.com/http-save/yehe-12379527/2f76b3daceac2bea3d88c9efe210e9c3.png)

`created/sent/external_failed/accepted/in_progress` 都会占用库存或仓位；`completed/cancelled/rejected/failed` 才会释放预占。

## 9. 工程落地亮点

| 方向 | 实践 |
| --- | --- |
| 幂等 | 事件、预测运行、调度运行、工单分配多层唯一键 |
| 并发 | 区域库存咨询锁、画像训练租约、正式调度行锁 |
| 性能 | SQL 集合聚合、固定批大小、循环内零查询、Redis MGET/Pipeline |
| 降级 | Redis 故障回源 MySQL，缓存异常不改变业务结果 |
| 可观测 | 最新可用结果与最新失败尝试分开，日志带请求 ID |
| 可解释 | 每条预测有原因，每个剩余缺口有约束原因 |
| 可评估 | 预测与真实需求按 1/3/6 小时窗口事后对账 |
| 安全上线 | 先影子调度，再人工对照，最后才考虑正式外发 |

### 本地性能记录

| 场景 | 数据规模 | 耗时 |
| --- | ---: | ---: |
| ORM 逐对象构建需求事实 | 50 万日志 | 617.289 秒 |
| MySQL 按日集合聚合 | 同一批 50 万日志 | 43.130 秒 |
| 主动拉取库存 | 2,000 柜 | 25.004 秒 |
| 需求与库存预测 | 10,000 个柜型组合 | 11.933 秒 |
| 约束调度 | 10,000 个预测组合 | 8.677 秒 |

相同数据下，需求事实构建从应用层 ORM 聚合改为数据库集合聚合后提升约 14.31 倍。以上仅为本地实验结果，不代表生产 SLA。

## 10. 当前边界

- 当前是小时统计画像，不是机器学习模型。
- 3/6 小时预测是逐小时分位数求和，不是累计窗口直接分位数。
- 尚未模拟换电后低电池再次充满形成的动态供给回流。
- 当前调度是风险优先、距离优先的确定性匹配，不保证区域全局成本最优。
- 外部工单未接通时只能生成内部草案。
- 自动化测试通过不等于真实业务已经完成全链路验收。

## 11. 下一步演进

![image.png](https://developer.qcloudimg.com/http-save/yehe-12379527/60dd343013482fe3ac154793c9d88c24.png)

机器学习可以替换需求预测，运筹优化可以替换匹配策略，但区域、兼容、仓位、库存版本、在途预占和人工审批仍然是不可绕过的硬约束。

## 结语

这套系统的核心不是“算法看起来多智能”，而是每一层都能回答：数据来自哪里、结果是否完整、为什么可以调、为什么不能调、执行后如何验证。

技术栈：Python、FastAPI、SQLAlchemy、MySQL、Redis、Vue 3   说明：本文基于实际后端实现整理；截图中的柜机、区域、工单和指标均为脱敏模拟数据。

从缺电预警到调度工单：换电柜智能调度系统设计与实践

两轮电动车换电柜智能调度服务。系统根据历史换电需求画像和当前柜机库存，生成柜间电池调入、调出建议及影子/正式调度计划。

后端

人工智能

云计算

技术栈采用Python/FastAPI与Vue3，通过确定性链路解决换电柜供需失衡。核心是统计需求画像、库存快照及硬约束匹配，经影子调度验证，实现可解释调度。预测与缺口计算、库存批次冻结确保数据可信，工单状态机管理全流程，多窗口策略避免高峰缺电，显著提升调度效率。

机器学习

代码解释

数据库

数据流

Python

MySQL

Redis

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从缺电预警到调度工单：换电柜智能调度系统设计与实践-腾讯云开发者社区-腾讯云

从缺电预警到调度工单：换电柜智能调度系统设计与实践

从缺电预警到调度工单：换电柜智能调度系统设计与实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐