一、为什么我们要重写一套AI原生的设备管理系统？
在设备管理这个领域深耕十几年，我们有一个判断越来越清晰：设备管理系统的核心问题，不是功能不够，是系统太难用。
难用在哪里？不是界面不够好看，是设计逻辑反人性：
- 设备入台账，20个字段一个一个填。设备铭牌上明明印着型号、功率、电压、序列号，系统却要求从另一个空白表单重新敲一遍。一台设备入台账，熟练操作也要将近10分钟。
- 故障报修时，"设备编号"成了拦路虎。铭牌上印的是"MC-2000 螺杆式空压机"，系统里存的编号却是"EQ-FJ-0037"。工人说"那边那台空压机好像有异响"，搜"空压机"搜不到，必须搜编号才行。
- 新设备运行后，技术标准和点检计划哪里来？中小企业的设备管理基础薄弱，从零建立维保标准是巨大的工作量。
- 一线员工需要全手机操作，但要么要装独立App，要么用小程序——不管哪种，都要额外维护。
- 菜单深，找功能比干活还累。台账、工单、备件、保养、审批……新员工第一天用，光搞清楚"该点哪个菜单"就要半小时。
这些场景的共同点：系统是给坐在电脑前的人设计的，不是给在一线干活的人设计的。
设备管理软件市场不缺产品。缺的是一套让一线人员愿意用、用了能真正解决问题的系统。这就是 EAMX 的起点。
💡 产品定位
EAMX 不是又一套"功能齐全"的设备管理系统。EAMX 是一套从第一天就内置AI能力的设备管理系统，核心理念是：让系统去适应人，而不是让人来适应系统。
二、技术选型：为AI而生
我们不是传统软件开发团队——我们是一群懂设备资产管理的业务专家。选择技术栈的原则只有一个：让开发速度最大化，不牺牲长期可维护性。
| 层级 | 技术选型 | 选型理由 |
|---|---|---|
| 前端 | React + Vite + TypeScript | 组件化成熟，Vite启动快，TS保证长期可维护性 |
| 后端 | Express 5 + Drizzle ORM | Express生态丰富，Drizzle类型安全、迁移方便 |
| 数据库 | PostgreSQL | JSONB对AI场景友好，全文检索能力强 |
| 包管理 | pnpm monorepo | 前后端同仓管理，依赖复用 |
技术选型不是炫技，是为后续的开发速度服务的。React + Vite 让我们能在 Day 1 以极快速度搭建前端页面；Drizzle ORM 让我们不需要手写 SQL 就能完成数据库迁移；PostgreSQL 的 JSONB 字段是 AI 场景的天然搭档——对话上下文、意图解析结果、结构化提取字段，都能直接存 JSONB，不需要额外设计表结构。
三、Day 1：工作量最大的一天
从早上9点到晚上11点，14天开发周期中交付密度最高的一天。一共交付了四个核心模块：
模块一：基础数据管理
- 公司组织架构（树形，不限层级的组织架构体系）
- 位置管理（精准定位设备所在区域）
- 用户管理与权限控制
模块二：设备台账——EAM系统的灵魂
Day 1 搭建了完整的设备台账 CRUD：
- 基础信息：设备编码、设备名称、品牌、型号、购置日期、保修截止日期等
- 财务信息：转固日期、资产原值、残值率、累计折旧等
- 关联信息：关联技术标准、工单计划、所需备件
- 设备履历：变动历史和工单历史可追溯
- 附件管理：支持设备铭牌、合同等文件上传
拍照上传设备铭牌，AI识别后自动建设备台账，用户确认必要字段后一键提交。从10分钟压缩到30秒。
模块三：故障上报
搭建了故障上报全流程，支持设备故障上报和无设备故障上报。故障上报和工单管理分离设计——多人上报同一故障时方便合并处理。
特别加入了设备别名功能：设备台账新建时，LLM自动搜索设备的常用别名存入数据库中。例如："塑料注射成型机"的别名包括"注塑机"，这样工人说"A区的注塑机坏了"，系统能精准识别到对应的设备。
模块四：移动端支持
所有核心流程在手机端可完成，支持相机调用、拍照直传AI分析。卡片式导航，点击即可进入详情。
四、Day 1 的核心交付：三个AI能力
这是 EAMX 和其他设备管理系统最本质的区别。
AI能力#1：铭牌拍照 → 自动入台账
痛点：新设备入台账，用户要填20+个字段，熟练操作也要将近10分钟。
方案演进：最初尝试让AI一次性识别所有字段，但铭牌照片质量不稳定（光线差、被遮挡、铭牌老旧模糊），一次识别20+字段准确率不够。
最终采用两阶段提取策略：
- 第一阶段：只识别设备型号。型号准确率最高，用它锁定设备身份。
- 第二阶段：基于型号，深度提取功率、电压、频率、序列号等技术参数。逐字段识别，准确率远高于一次全量提取。
✅ 用户实际体验
新设备到了，打开手机拍一张铭牌照片 → AI自动识别填好表单 → 核实后一键确认入账。整个过程不超过30秒。
AI能力#2：自然语言故障上报
在AI对话窗口直接输入"A区的注塑机坏了"，系统自动识别故障设备并创建故障上报单草稿。支持设备别名匹配，解决了一线人员记不住设备编号的核心痛点。
AI能力#3：设备别名智能识别
系统在设备台账新建时，LLM自动搜索并存储设备别名。当用户用口语化表达报修时（如"注塑机"而非"塑料注射成型机"），别名匹配确保AI能准确找到对应设备。
五、移动端优先：让系统去适应人
设备资产管理的核心用户是车间工人和现场维修人员，他们用电脑的机会远小于用手机。
很多系统的问题是：买来后告诉工人"去电脑室录单"——结果没人愿意用，系统成了摆设。
EAMX 从第一天起就是移动优先：
- 所有核心流程在手机端可完成
- 相机调用权限申请，拍照后直传AI分析
- 列表→详情采用卡片式导航
- 零安装——浏览器打开即用
设备在哪里，系统就应该在哪里。
六、一个关于AI原生开发的反思
Day 1 经历告诉我们一件事：AI原生应用的开发顺序和传统应用根本不同。
| 维度 | 传统开发 | AI原生开发 |
|---|---|---|
| 开发顺序 | 先搭框架 → 写CRUD → 最后加AI（外挂式） | 第一天就让AI进入核心业务流程 |
| AI定位 | "锦上添花"的附加功能 | 产品的基因和核心能力 |
| 用户交互 | 菜单 → 表单 → 提交 | 对话 → 识别 → 确认 → 提交 |
| 代码量 | 大量表单逻辑和校验代码 | 核心AI逻辑不到500行 |
Day 1 的三个AI能力加起来，核心逻辑不超过500行代码。但它们改变了整个产品的基因——这是一个从第一天起就知道怎么理解用户语言的系统。
⚠️ 关键洞察
AI不是给设备管理系统"加一个聊天机器人"。AI原生的本质是：AI嵌入业务流程，离开AI系统无法正常运作。铭牌识别建台账、语音报故障、别名智能匹配——这些功能如果去掉AI，整个流程就会回到10分钟手填的时代。
七、Day 1 交付总结
| 模块 | 状态 | 对应痛点 |
|---|---|---|
| 组织架构 / 用户管理 | ✅ 可用 | 权限和通知的地基 |
| 设备台账 CRUD | ✅ 可用 | 所有后续工作的起点 |
| 设备类别树形管理 | ✅ 可用 | 多级设备分类 |
| 维修工单状态机 | ✅ 可用 | 维修过程透明可追溯 |
| 故障报修全流程 | ✅ 可用 | 快速响应，减少无效上门 |
| AI 铭牌拍照入台账 | ✅ 可用 | 入台账从10分钟压缩到30秒 |
| AI 故障语音上报 | ✅ 可用 | 一句话报障，消除信息失真 |
| AI 设备别名识别 | ✅ 可用 | 让一线人员真正愿意用系统 |
| 移动端相机集成 | ✅ 可用 | 贴合一线工作场景 |
| 树形位置管理 | ✅ 可用 | 精准定位设备所在 |
这不是 Demo，不是原型，是一个可以实际使用的系统。
—— EAMX 开发团队
下一个阶段：系统骨架搭好了，如何快速填满业务全链路？备件库存、审批流、工单成本……这些模块如何在最短时间内完成，同时不让AI能力变成孤岛？敬请关注后续开发手记。