AI 报警器：一线维修看得懂、用得上的报警诊断闭环
先说人话：这个东西是干什么的
在很多工厂里，设备一报警，现场通常要经历这几步：
- 看上位机上的故障码。
- 翻厚厚的 PDF 手册。
- 找不到就打电话问老师傅。
- 处理慢了，产线就一直等。
AI 报警器 做的事很直接：
- 设备报码后，系统自动给出“这是什么问题、可能原因、建议怎么处理”。
- 同时给出“查看手册”入口，能直接跳到对应页。
- 处理结果还能做人工反馈（有用/无用），后续持续优化。
它不是“替代工程师”，而是把“查资料 + 初步判断”的时间压缩掉，让人更快做决策。
行业痛点（不是概念问题，都是现场真问题）
1. 报警码能看到，但信息不完整
很多系统只显示 E034 这种代码，不告诉你上下文。新人基本无从下手。
2. 手册太厚、检索太慢
一本手册几百页到上千页很常见。故障发生时，没人愿意慢慢翻目录。
3. 知识在“人”手里，不在“系统”里
老师傅知道怎么处理，但经验没有结构化沉淀。人不在，效率立刻下降。
4. 处理闭环缺失
大多数系统没有记录“这次建议有没有用”，导致后续优化没有抓手。
5. 集成成本高
现场系统异构，想接一个新能力，常见顾虑是“要不要大改原系统”。
解决方案（尽量少改现有系统）
AI 报警器 采用“外挂式接入”思路：
- 设备或上位机把故障码发到 API。
- 后端按租户/厂商/系列/型号去知识库检索。
- 返回结构化结果：标题、含义、原因、建议、手册引用。
- Web 端或桌面端（Avalonia）弹窗展示。
- 操作员点“有用/无用/关闭”，反馈进入统计。
核心原则：
- 不改 PLC 逻辑。
- 不推翻现有 MES/SCADA。
- 在原有链路上增加“诊断与闭环”能力。
项目架构（通俗版）
一、数据层
- 手册 PDF 入库。
- 解析抽取报警码、原因、建议、页码等结构化信息。
- 形成可检索知识库（按品牌/系列/型号分层）。
二、服务层
Diagnose API：接收故障码并返回诊断结果。- 事件接口：接收设备报警事件，支持实时推送与补偿拉取。
- 反馈接口：记录“有用/无用/关闭”。
三、展示层
- Web 控制台：用于验证和运营侧查看。
- Avalonia 客户端：常驻进程，跨平台弹窗（Windows/macOS/Linux）。
四、闭环层
- 反馈日志与统计。
- 低质量答案回流到知识库修正。
- 形成“越用越准”的持续优化机制。
效果（当前可验证的价值）
1. 故障响应更快
从“报码后开始翻手册”变成“报码即看到建议 + 手册跳转入口”。
2. 新人可上手
不再完全依赖个人经验，降低人员经验差导致的处理波动。
3. 知识沉淀更可控
原来散落在聊天记录和个人记忆里的经验，逐步沉淀到系统。
4. 可量化优化
通过有用/无用反馈，能看到采纳率、问题分布、知识库薄弱点。
5. 对现有系统更友好
以 API 和弹窗方式接入，改造范围可控，不需要一次性重构整套系统。
边界说明（避免误解）
这套系统目前定位是“报警诊断辅助”，不是“自动控制替代”。
它能做的：
- 快速给出可参考建议。
- 提供手册定位和知识检索。
- 支持反馈闭环与持续优化。
它不能替代的：
- 现场安全确认。
- 电气/机械的最终维修决策。
- 企业内部的 SOP 与 EHS 责任体系。
适合谁用
- 做设备集成的团队。
- 设备运维或售后团队。
- 需要把“报警处理经验”标准化沉淀的制造企业。
一句话总结
AI 报警器 的核心价值，不是“看起来很智能”，而是把一线最耗时间的报警处理流程，做成可复用、可追踪、可优化的闭环能力。
