BLSFlow docs

Appearance

blsflow 简要版 PRD ​

1. 文档目的 ​

本文件用于给开发者快速说明：

  • 产品当前要做什么
  • 目前已经完成了什么
  • 还有哪些内容尚未完成

本文件是开发沟通用的简要版产品说明，不替代任务文档、架构文档或模块文档。

2. 产品定位 ​

blsflow 是一个面向 CPU 矿机场景 的内部生产平台。

第一阶段主要服务自有矿场，核心目标是：

  1. 统一管理 CPU 矿机
  2. 支持人工操作和智能调度并存
  3. 基于收益自动切换运行币种
  4. 保留最小可用的维修记录

3. 当前阶段产品范围 ​

3.1 当前要做的核心能力 ​

当前产品需要逐步形成以下 5 类能力：

  1. 账号与控制台入口
  2. 设备接入与设备管理
  3. 币种与挖矿配置管理
  4. 手动切币与智能调度
  5. 维修记录与基础运营留痕

3.2 当前明确的一期边界 ​

  • 只做 CPU 矿机
  • 单台机器任意时刻只运行一个币种
  • 支持 手动模式 和 智能调度模式
  • 智能调度是自动执行，不是建议提示
  • 冻结语义是：停止智能调度，不切币，不停机
  • 恢复必须由用户手动开启

3.3 当前已确认支持的币种范围 ​

  • xcb
  • qubic
  • 门罗

4. 目标用户 ​

第一阶段主要用户：

  1. 项目负责人
  2. 运维人员

当前默认只有一个后台角色，登录后拥有全部权限。

5. 产品整体结构 ​

当前产品按逻辑模块理解为：

  1. 平台接入与控制台模块
  2. 设备与 Agent 管理模块
  3. 币种与挖矿配置模块
  4. 收益数据与监控模块
  5. 调度与执行编排模块
  6. 维修记录模块

开发时需要注意：

  • 控制台只做入口、展示、聚合、转发
  • 设备控制服务负责设备执行与设备事实状态
  • 调度核心服务负责调度判断与冻结状态
  • 数据与配置服务负责配置、收益和聚合事实
  • Agent 只负责本机执行与上报

6. 已经完成的内容 ​

6.1 文档与架构层 ​

已经完成：

  • 一期业务边界收敛
  • 系统骨架和服务边界第一版收敛
  • 模块职责、服务职责、状态归属基本明确
  • 文档驱动协作体系已建立

6.2 设备与 Agent 侧 ​

已经完成：

  • Agent 第一阶段工程骨架
  • Agent 与设备控制服务的 WebSocket 通信闭环
  • 正式注册 token 识别主链路
  • machines、machine_hardwares、metric_powers、metric_systems 四张核心设备数据落库
  • Agent 自动重连
  • Agent 身份自动生成与稳定化
  • 设备离线状态回收
  • 命令执行最小状态流转
  • 命令重投、重复结果幂等回写
  • 命令超时后的自动重试与 timeout 收敛

6.3 控制台与账号侧 ​

已经完成：

  • 控制台前端最小工程初始化
  • PHP 账号服务最小工程初始化
  • email 注册闭环
  • 开发态邮箱验证闭环
  • email 登录闭环

当前控制台已经具备最小账号入口，但还不是完整业务控制台。

6.4 文档层已经明确但尚未进入实现闭环的边界 ​

文档上已经基本明确：

  • 币种与挖矿配置由数据与配置服务承载主事实
  • 控制台只负责配置入口、展示与操作转发
  • 手动切币应读取统一配置主事实
  • 智能调度应读取统一候选范围和统一配置来源

这些边界已经可指导后续 task 拆分和实现，但多数还没有落成完整代码闭环。

7. 当前还没有完成的内容 ​

7.1 控制台业务入口 ​

尚未完成：

  • 设备管理页面和正式操作入口
  • 设备注册 token 管理入口
  • 币种与挖矿配置管理入口
  • 手动切币入口
  • 智能调度入口
  • 维修记录入口

7.2 配置与业务主链路 ​

尚未完成：

  • 数据与配置服务的正式最小实现
  • 币种、钱包、矿池、启动参数的正式维护闭环
  • 机器与币种适配关系的正式维护闭环
  • 智能调度资格范围的正式维护闭环

7.3 手动切币与调度 ​

尚未完成：

  • 手动切币的完整产品闭环
  • 智能调度的完整产品闭环
  • 收益驱动切换逻辑落地
  • 冻结、恢复、异常通知的完整业务链路

7.4 收益与监控 ​

尚未完成：

  • 矿池产量采集闭环
  • 币价采集闭环
  • 电价配置与分时电价闭环
  • 利润计算服务化闭环
  • 异常监控与冻结输入闭环

7.5 账号与安全 ​

尚未完成：

  • 真实邮件供应商接入
  • 找回密码
  • 登出与更完整会话管理
  • 权限模型
  • 更细粒度鉴权

7.6 维修方向 ​

尚未完成：

  • 维修记录正式页面和录入流程
  • 维修记录与设备视图联动

8. 当前开发者最应关注的事情 ​

当前开发者需要优先理解：

  1. 现在不是从零开始，设备控制主链路和最小账号入口已经完成
  2. 接下来重点不是继续堆底层，而是把控制台业务入口和统一配置链路接起来
  3. 手动切币应优先于智能调度落地，因为它更适合作为第一个完整业务动作闭环
  4. 任何实现都不能破坏现有服务边界和状态归属

9. 推荐的下一阶段开发顺序 ​

建议按以下顺序推进：

  1. 控制台设备注册 token 管理入口
  2. 控制台设备管理最小入口
  3. 数据与配置服务最小实现
  4. 控制台配置管理最小入口
  5. 手动切币最小闭环
  6. 智能调度最小闭环
  7. 收益与监控闭环
  8. 维修记录闭环

10. 当前明确不做或暂不展开的内容 ​

当前阶段不展开：

  • 数据库表结构详细设计
  • 接口字段详细设计
  • 完整权限模型
  • 多角色体系
  • 短信登录、OAuth、多因子认证
  • 备件库存和维修生命周期管理
  • 过早拆更多微服务

11. 给开发者的直接结论 ​

如果你现在接手开发，可以这样理解：

  1. 底层设备通信和命令可靠性已经有第一阶段基础，不需要重做
  2. 控制台账号最小闭环已经可用，但业务页面基本还没开始
  3. 配置、手动切币、调度这些业务链路，边界已经在文档里收敛，但大多还没有实现
  4. 下一阶段最合理的重点是把“控制台入口 + 配置主事实 + 手动切币”连成第一条完整业务闭环