想做一套设备管理系统，权限报表真的要自己写吗
-
给智能硬件客户搭一套设备管理后台，或者把自己团队的传感器、网关管起来，需求方开口往往只有三句话：要有设备台账、能看到在线状态、能导出报表。字段听起来都简单，真正动手之后你会发现，难的地方不在设备表里。
-
这篇文章写给三类读者： 需要为客户交付设备/资产管理后台的中小团队开发者，做智能硬件或 IoT 的服务商，以及 ISV 的技术负责人。你们的共同点是：业务模块自己写得动，但没有专职团队长期维护权限、审批、报表、开放接口这一层「底座」。
一、问题：字段好建，底座难搭
设备台账本身不难。编号、名称、型号、状态、购置日期，再加一个负责人，建张表就能跑起来。
真正吃掉时间的，是业务字段下面那层公共能力，而且每一层都要从零搭：
-
权限：谁看得到设备列表，谁改得了状态，统计接口要不要单独授权。角色管理要做到菜单、按钮、接口三重授权，设备状态这类枚举还要靠数据字典统一维护，菜单管理则是路由与权限码的骨架，否则前后端各写一套。
-
审批：设备报修、资产调拨、升级申请，都是「发起 → 逐级审批 → 结束」的流程。条件分支、抄送、逐层驳回、按节点分组，每一种都对应状态机里的一块。
-
报表：客户要的不是列表页，而是清单报表、交叉报表、明细带汇总，最后还得能导出 Excel。
-
开放接口：硬件网关要调你的接口，appKey/appSecret 鉴权、按接口限流、调用留痕，一个都不能少。
原因不在单点技术难度，而在于这四样东西都需要长期演进。权限模型调整一次，所有菜单和按钮跟着动；审批加一种节点，状态机要重新理一遍；报表形态从清单变交叉，底层定义跟着改。小团队没有专人盯这些，自研版本往往停在「够用」，维护成本却随业务一路涨。
二、方案：四个场景，底座先立起来
-
GewuMind Boot（格物智）的定位是 AI 开发工具：装上 gewumind-skill，你手上的 Claude Code / Cursor / opencode 就获得完整的后端开发能力，按「需求 → 设计 → 生成 → 发布」四阶段交付应用。它跑在一个低代码后端容器上——HTTP 接口用脚本编写、页面用组件文件维护、菜单/字典/配置全部在线管理，clone 下来三步就能跑起一整套可用后端。基线自带 45 张表，以及平台自带的菜单、角色、字典、配置与页面组件。
设备管理：核心场景
-
设备管理模块就在底座之上生成： 设备表含设备编号（不可重复）、名称、型号、状态（online / offline / maintenance）、购置日期，模块提供分页列表（关键字/状态筛选）、保存（新增/更新）、删除（逻辑删除）、统计（总数 + 各状态计数）四个接口。业务字段随项目增删，权限和数据字典直接复用平台现成的；需要收发设备消息时，可以走 MQTT/Kafka 消息通道，在脚本里直接收发。
审批：流程运行时在项目内
工作流引擎支持条件分支、抄送、逐层驳回、按节点分组审批。设备报修、资产调拨这类多级审批，「发起 → 逐级审批 → 结束」的运行时完全在本项目内，不需要外部引擎。系统预置了请假、合同、采购、跨部门申请四个流程示例，设备相关的流程照着搭即可。提醒一下：工作流引擎属于 10 项需商业 License 解锁的企业能力之一，未授权时处于 30 天试用。
报表：9 种预置形态 + Excel 导出
-
报表能力是报表定义加 9 个预置示例： 清单报表、交叉报表、中国式报表、明细带汇总、带条件格式、嵌套明细、多 Sheet、跨行合并、列头扩展，支持导出 Excel。设备台账周报、各状态数量统计、按型号分布，都能落在这 9 种形态里，不用自己写报表引擎。
开放接口：appKey/appSecret 换 token
应用管理里，每个应用持有独立的 appKey/appSecret，secret 仅创建时完整展示。接口授权以「接口路径 + 方法」为单位，单个接口可以单独限流。第三方先用 appKey/appSecret 换 token 再调接口，每次调用都留痕：应用、接口、耗时、结果码、IP、时间，排查对账和限流都有依据。硬件网关对接，就是典型场景。
三、示例：demo-device 真实演示
-
官方有一个 demo-device 模块的完整演示：EP02 视频《AI coding 实战：让 Agent 写设备管理模块》，在官网、B 站、YouTube 都能看。示例提示词只有一句话：
用 gewumind-boot 做一个设备管理模块：设备登记、心跳监控、固件版本管理，发布到 localhost:9089
-
Agent 按四阶段交付： 需求、设计文档、生成代码、一键发布，每阶段结束都等确认，不会一上来就往库里写东西。生成的模块包含 4 个接口：分页列表（关键字/状态筛选）、保存（新增/更新）、删除（逻辑删除）、统计（总数 + 各状态计数），统计接口挂了 device:stats 权限码——这是演示模块给统计接口挂的权限码，用来演示接口级授权。模块预置 5 条示例设备：边缘网关、温湿度传感器、工业相机、控制器、扫码枪，发布后刷新页面就能用。
-
产物是普通文件： SQL、接口脚本、页面组件。AI 生成的与手写的完全等价，可以随时打开继续改；发布失败可以回滚。
四、边界：它不是什么
-
选型前把话说清楚：
-
不是完整 IoT 平台。没有设备影子、协议解析、OTA 固件升级。MQTT/Kafka 在这里只是消息通道，用于设备消息收发、消息队列生产消费，协议解析不在范围内。
-
不是企业级 CMMS。工单体系、维保计划、资产全生命周期这类重型能力，不在它的目标里。
-
设备管理模块是底座之上生成的业务层。权限、审批、报表、开放接口由底座提供，设备台账是生成出来的业务模块：底座可以跨项目复用，业务模块跟着项目走。
-
许可是 Open Core。内核 Apache License 2.0 开源。10 项企业能力（SSO、工作流引擎、模块管理、Redis/共享会话、MQTT、Kafka、SSE、TCP、WebSocket、AI 客服）通过离线 License Key 解锁，不改变源码 Apache-2.0 授权；未授权时这些能力关闭或处于 30 天试用（默认 30 天），到期自动降级基础版。授权离线校验，不联网。
五、结论
搭设备管理后台，业务字段只是开头。真正决定项目周期和长期维护成本的，是权限、审批、报表、开放接口这层底座。如果团队没有专人维护这四样，把底座交给开源内核，把精力放在设备业务本身，是更省事的选法。
想进一步了解，可以看仓库：