物联网系统 B 端产品开发
在公司既有物联网产品(已有管理端与移动小程序客户端)的基础上,用 AI 辅助开发独立补齐面向用能单位(工厂、医院、民宿等)的 Web 端 B 端门户。 复用成熟的后端接口,落地设备管理、能源监控大屏与工单闭环等模块,服务于使用空气能热水系统的场所, 覆盖开发、测试、设计与文档输出。
原有系统我新增的部分
应用层
原有
管理端 · Admin
/Web/admin/ 平台运营与设备管理后台
原有
工厂物联小程序
既有移动客户端,功能与接口已成熟
我新增
B 端客户端 · /Web/c/
登录 · 监控大屏 · 设备 · 工单
服务层
原有
核心后端 · BLL / DAL / Model
设备接入、用户与业务核心服务
我新增
客户端后端接口
WebSite.Customer.dll · customer.ashx · c_workorder.ashx
数据层
原有
SQL Server
设备、能耗、工单等业务数据
设备层
原有
空气能设备 · 物联网网关
热泵机组 / 水箱 / 电表水表 数据上报
背景
红日子物联是面向用能单位的设备管理与能源监控平台。公司已有后端服务、管理端,以及一个功能完整的 移动小程序客户端,但缺一个在桌面浏览器里好用的 Web 端 B 端门户——工厂、医院、民宿等客户 希望在大屏上远程看设备运行状态、查能耗与碳排、配参数、报故障。我负责的正是 /Web/c/ 这块 Web 客户端, 在成熟的后端接口之上把它做出来。
既有代码是 ASP.NET WebForms 技术栈。好处是小程序端已经把接口与业务跑通,我可以直接复用; 难点在于要先读懂现有契约与数据结构,再在不破坏既有平台的前提下,补出 Web 端特有的前端, 以及配套的后端接口(WebSite.Customer.dll、customer.ashx、c_workorder.ashx)。
目标
- 在既有平台上,交付一个客户单位能直接用的 B 端门户:监控、设备、工单三大模块闭环。
- 能源数据可视化:用电/用水、碳排放与标准煤换算、区域与时间维度分析。
- 设备状态准实时呈现,多场所客户数据彼此隔离,体验上支持日/夜双主题。
实现
AI 协作方式
- 开发环境是 VSCode + Claude 插件,在编辑器里直接读既有代码、改代码、跑验证。
- 方法上主要用 superpowers 这套 skill:先 brainstorming 厘清需求、产出 spec,再用 writing-plans 写出实现计划,然后按计划拆成多个 subagent 分工执行。此外一些复用的参数名和API规范，我整理为了DEV文档。
- 「spec → plan → 分 subagent 执行」让我在不熟的老技术栈上,也能把改动拆成边界清晰、可逐个验证的小任务，在此基础上使用Git进行了版本管理。
我还使用了Claude design，进行基本原型图的绘制。以及GPT生成一些工厂、酒店、医院以及设备的占位图。
（部分Git记录截图）- 不足之处：1. 没有处理好git说明文件，导致Claude经常没有识别这个文件夹是Git仓库。
- 2. 没有把这个问题写入memory。
后续优化：
我的个人主页按规则Git。
客户端外壳:登录、菜单与日夜主题
- 沿用 C# / ASP.NET WebForms,前端用 jQuery + ECharts。入口 index.aspx / login.aspx(md5.js 做密码摘要),登录后进入由 menu.xml 配置、menu.js 动态加载的左侧菜单(监控 / 设备 / 工单三大块),主工作区用 iframe 承载、模块解耦。
- theme.js 统一管理日 / 夜主题:主框架切换后向各 iframe 子页广播,配合 theme-vars.css 的 CSS 变量整站换肤,白天看数、夜间值班都不刺眼。
能源监控大屏(project_monitor)
- 项目大屏(SCADA 组态):project_system_monitor.aspx 服务端按会话里的 CustomerId 查 [Device] 等表再渲染,为单水箱(04A / 01A / 01B)、双水箱、承压式等设备各做一套组态图,空气能主机用快 / 慢速旋转视频反映风机转速,画布等比缩放。
- 能耗与碳排卡片:系统总览、今日用量、区域能耗、7 日表计等页用 ECharts 呈现用能结构与趋势;碳排放按湖南电网因子 0.4976 kgCO₂/kWh、标准煤 0.1229 kgce/kWh 换算(换算逻辑已就位,当前用示意数据填充,接真值即可上线)。
设备管理(model/device)
- 我的设备、当日报警、历史数据、设置参数(下发 / 初始化 / 一键同步)、状态参数;状态参数面板用 setInterval 每 6 秒自动刷新,实时反映机组运行值。
工单(model/workorder)
- 两条流转线:报警工单由设备报警联动生成;主动工单走「待分派 → 处理中 → 已完结 / 关闭」状态机(对应 active_workorder 的 activate / detail / submit 各步)。
我做的后端接口
- 后端我新增了两个 ASHX 接口——customer.ashx(客户端数据)、c_workorder.ashx(工单),以及 WebSite.Customer.dll 承载客户端业务逻辑;它们复用既有 BLL / DAL 直连 SQL Server,并统一按 CustomerId 做多场所隔离,不改动原平台。
成果
- 独立交付面向用能单位的 Web 端 B 端门户(/Web/c/ 前端 + customer.ashx / c_workorder.ashx 等后端接口):登录、能源监控大屏、设备管理、工单四块闭环,覆盖开发、测试、设计与文档。
- 把分散设备纳入统一大屏,能耗、碳排、标煤一目了然,远程查状态、下发参数,降低现场运维成本。
- 沉淀出可作为迭代基线的 PRD,理清了模块结构、接口与业务规则。
仓库:github.com/999boom/Hongrizi-IOT · 客户端目录 /Web/c/ · 2026.04
算法
基于AI的热水调度系统算法架构
┌─────────────────────────────────────┐
│ 1. 数据采集层 │
│ 输入实时和历史数据 │
│ - 历史逐时用水量 │
│ - 室外温度 │
│ - 时间特征（小时/星期/节假日） │
│ - 储水箱温度 │
│ - 循环水箱温度 │
│ - 储水箱水位 │
│ - 分时电价信息 │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ 2. AI预测层（LSTM） │
│ 作用：预测未来24小时逐时用水量 │
│ 输入：过去24小时/过去N天的时序数据 │
│ 输出：未来24小时逐时用水需求曲线 │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ 3. 策略计算层 │
│ 作用：把“用水预测”转成“调度方案” │
│ 包括： │
│ - 电价政策识别 │
│ - 单谷电 / 双谷电模式判断 │
│ - 等效成本计算（电价 / COP） │
│ - 次日所需加热量计算 │
│ - 保温需求计算 │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ 4. 调度决策层 │
│ 作用：确定什么时候、加热多少、 │
│ 是否补热、是否保温 │
│ 例如： │
│ - 夜间谷电先加热一部分 │
│ - 午后低成本时段再补热 │
│ - 平电高COP时段做保温 │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ 5. 设备控制层 │
│ 控制器输出指令给硬件 │
│ - 热泵启停 / 功率调节 │
│ - 循环水泵 │
│ - 补水水泵 │
│ - 保温循环泵 │
│ - 各类阀门开闭 │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ 6. 反馈修正层 │
│ 作用：监控实际运行结果并修正 │
│ - 实际用水 vs 预测用水 │
│ - 实际水温 / 水位是否达标 │
│ - 预测偏差修正 │
│ - 每周用新数据更新模型 │
└─────────────────────────────────────┘