这是EAMX开发手记的第二篇，记录第2天的核心工作：故障上报和工单管理的功能设计。
在传统设备管理系统中，故障上报往往要求工人填写一堆表单：设备编号在哪里？故障类型是什么？发生位置是？——工人们很困惑：「我就是说一句'A区的注塑机坏了'，系统怎么就不知道是哪一台？」
EAMX的设计思路是：让系统去适应人的习惯，而不是强迫人去适应系统的要求。
故障上报的两大场景
在实际生产中，故障上报分为两种截然不同的场景：
场景一：有设备故障上报
工人知道是哪台设备坏了，直接关联设备填写故障描述。这种情况最简单，工人可以直接在设备档案中找到对应的设备，或者扫码快速定位。
场景二：无设备故障上报
工人说不清设备编号，只能描述位置和现象。比如：「二楼空调不制冷了」「三号产线的传送带发出怪响」「食堂的冰箱门关不上了」——这些描述五花八门，但没有一个直接对应系统里的设备编号。
第二种场景才是痛点所在。传统系统在这里就会卡住，要么要求工人必须找到设备编号才能报修，要么随便选一个相近的设备凑合报上去，结果导致数据混乱。
💡 EAMX的解决思路
当工人说不清设备编号时，由AI来理解。工人只需要描述「位置+现象」，AI自动匹配到具体的设备，生成规范化的故障单。
AI故障上报的核心能力
EAMX的AI故障上报系统，能够从工人的自然语言中识别出三层关键信息：
- 设备类型：「空调」「传送带」「冰箱」「注塑机」——这是最直接的设备分类
- 位置信息：「二楼」「三号产线」「食堂」「A区」——对应系统中的位置层级结构
- 设备编号/铭牌名称：有时候工人会说「1号空压机」「老张那台铣床」——这些需要AI结合历史记录来匹配
举个例子，当工人说「二楼空调」时，系统会自动解析：位置=二楼，设备类型=空调。然后在二楼的设备列表中，匹配到「二楼中央空调（设备编号：AC-2F-001）」。
⚠️ 技术挑战
位置描述的多样性是最大的挑战。工人会说「上面」「那边」「这个」「老车间」——这些模糊表达需要结合上下文和历史交互记录才能准确理解。
故障单与维修工单分离设计
这是EAMX的一个重要设计决策：故障单和维修工单是两条独立的记录。
| 维度 | 故障单 | 维修工单 |
|---|---|---|
| 核心问题 | 出了什么问题？ | 谁去修？什么时候修？花了多久？ |
| 关注点 | 设备状态、故障现象 | 人员安排、进度管控 |
| 触发时机 | 故障被发现时 | 维修任务确认时 |
| 关联关系 | 关联设备 | 关联故障单、人员 |
为什么要分离？
因为一个故障单可能对应多个工单（比如同一台设备连续出故障，每次维修都要记录），而一个工单也可能解决多个故障（一次上门维修处理了多个小问题）。分离设计让数据更清晰，设备履历更完整。
工单状态机
EAMX的维修工单有五个核心状态，每个状态都有明确的时间戳记录：
- 已创建：故障单确认，需要分配维修人员
- 已派单：维修人员已接受任务
- 维修中：维修人员正在处理
- 已完成：维修工作完成，等待验收
- 已验收：使用方确认维修质量，工单关闭
✅ 时间线追溯
每个状态变更都记录精确时间戳，形成完整的可追溯时间线。当设备再次出现类似故障时，维修人员可以快速查看历史维修记录，参考之前的处理方案。
状态回写机制
当工单状态发生变化时，系统会自动将最新状态回写到对应的故障单：
- 工单派单 → 故障单显示「维修中（已派单）」
- 维修开始 → 故障单显示「维修中」
- 维修完成 → 故障单显示「已完成」
- 验收通过 → 故障单显示「已验收」
这样一来，故障上报人可以实时查看维修进度，不需要反复追问维修人员「修好了没有」。
「以前报完修就石沉大海，不知道什么时候能修好。现在打开手机就能看到进度，安心多了。」
—— 某工厂班组长反馈
设计原则
回顾第2天的设计工作，核心原则可以总结为一句话：
让系统去适应人的习惯，而不是强迫人去适应系统的要求。
工人不需要记住设备编号，不需要学习复杂的表单填写，只需要说一句话——剩下的，交给AI。
下一步
Day 3的计划是实现故障知识库：当类似故障再次发生时，系统能够自动推荐历史处理方案，帮助维修人员快速响应。
完整的14天开发手记系列，我会在公众号「白杨谈设备资产管理」持续更新，欢迎关注。