[HMI 架构笔记] AI 悬浮助手链路:自然语言、预览确认、写闸门和 PLC 回执

写在最前面：HMI 里的 AI 助手最容易踩坑的不是“模型答得准不准”，而是“写动作到底从哪里发生、谁能确认、失败后能不能追”。把链路拆开，边界就清楚了。

1. 结论先说

悬浮助手是入口，不是执行器。它负责对话框、预览确认和结果回显；不负责直接写 PLC。

本地能离线解析的指令，先走本地 parser。只有本地规则处理不了，才交给模型编排工具调用。

所有写都必须进入 ModbusDataService。AI 的请求不能绕过服务层闸门。

2. 一次 AI 写操作的完整链路

操作工输入一句自然语言，比如「所有限时设为 15 秒」。这句话先进入 AI 悬浮助手，再由聊天服务判断：能不能离线解析，是否需要确认，最后能否通过工具调用落点。

// 推荐链路：入口、编排、执行、闸门分层 operator says: 所有限时设为 15 秒   -> AiFloatingAssistant: 接收输入，展示预览确认   -> AiChatService: 判断改写 / 查询 / 诊断 / 工具调用   -> AiOfflineCommandParser: 能离线解析就本地解析   -> set_tag_value: 确认后发起工具调用   -> ModbusDataService: 统一写闸门   -> PLC: FC06 / FC16 写保持寄存器

这条链路的关键不是顺序漂亮，而是每一层只做自己该做的事。UI 不拼写命令，服务不做展示，PLC 不承担业务判断。

图：AI 悬浮助手链路

3. 为什么离线解析要放在模型之前

AI 助手不是所有动作都必须上模型。像「把所有限时设为 15 秒」这类结构化参数改写，规则很清楚、影响范围可枚举，离线 parser 反而更稳。

模型适合处理模糊表达、多轮追问、诊断建议；但可确定性执行的写动作，最好优先走规则链路。

// 判断顺序：先便宜、先确定、先本地 if (AiOfflineCommandParser.TryParse(input, out command))     return PreviewAndConfirm(command);  return await AiChatService.AskWithTools(input);

这样做有三个好处：减少不必要的大模型调用、降低模糊改写风险、把可复现的写请求变成可测试规则。

4. 预览确认不是 UI 彩蛋，是写入闸门的一部分

AI 写动作必须先出预览确认。用户看到的是“将要写哪些标签、旧值是什么、新值是什么、预计影响是什么”。确认之后，才发工具调用。

如果只把预览确认当成一个前端弹窗，它很容易被绕过：某个批量脚本直接调工具、某个调试页面绕过 UI、某个旧版本入口没有确认卡。正确的位置是：写动作进入服务层前，必须已经完成业务层确认，最终再经过 ModbusDataService 的权限闸门。

// 反例：模型工具调用直接写 PLC if (modelSaysWrite)     plc.WriteRegister(addr, value);  // 正例：工具调用只是发起请求，最终由服务层裁决 var result = await modbus.WriteAsync(addr, value); if (!result.Ok)     return ShowFailure(result.Reason);

5. EnableWrite 和服务闸门的关系

本地面板不依赖 EnableWrite。现场手动操作不能被远程写开关影响。

AI / MCP 先看 EnableWrite，再看服务闸门。它决定 AI 能不能发起写请求，但最终能不能写入，仍由点表和服务层判定。

6. 回执只做展示，不做隐式补救

写入成功后，AI 对话窗只回显结果；写入失败后，AI 对话窗展示失败原因。它不应该偷偷重试、不应该自动改其他参数、也不应该在用户没确认的情况下补写。

这句话很重要：AI 是辅助操作界面，不是后台自动修复引擎。现场系统最怕“看起来自动处理了，实际没人知道发生了什么”。

7. 收尾

一句话总结：悬浮助手负责表达，离线解析负责确定性，聊天服务负责编排，写闸门负责裁决，PLC 只负责执行。

AI 进入 HMI 后，最该守住的不是酷炫，而是可控。确认在前，闸门在中，回执在后，链路才敢用到现场。

—— 科控物联 · HMI 架构笔记系列