上位机程序连接的是现实设备，出错时影响的不只是页面显示。因此，AI 上位机编程不能从“帮我做一个控制面板”开始，而要先把设备状态、通信字段、权限和异常处理写清楚。界面只是最后一层，真正重要的是数据是否可信、动作是否可回退。
先画出设备状态图
把设备拆成待机、运行、暂停、报警和维护等状态，并写明每个状态允许哪些动作。比如报警状态下可以读取数据，但不能直接下发启动命令；维护状态下需要二次确认。状态图能防止 AI 把所有按钮都接到同一条执行路径。
| 状态 | 可读数据 | 允许动作 | 离开条件 |
|---|---|---|---|
| 待机 | 温度、压力、计数 | 启动、参数查看 | 收到启动确认 |
| 运行 | 全部过程数据 | 暂停、停止 | 任务完成或人工停止 |
| 报警 | 报警码、时间、现场值 | 确认、复位（需权限） | 原因排除并复核 |
| 维护 | 诊断数据 | 点动、校准（需授权） | 维护结束确认 |
把通信协议变成字段字典
无论设备使用 Modbus、OPC UA 还是厂商自定义接口，都先建立字段字典：地址或节点、数据类型、单位、读写权限、刷新周期和异常值。让 AI 根据字段字典生成代码，比让它凭经验猜寄存器更安全。
字段：motor_speed
类型：float
单位：rpm
权限：read
刷新：500ms
异常：通信超时、值超出 0-3000让 AI 先写模拟器，再接真实设备
没有模拟器时，调试很容易被现场设备打断。可以先让 AI 生成一个固定数据源，模拟正常、超限、断线和恢复四种情况。界面和状态机通过测试后，再替换成真实通信客户端。这样你能在没有设备的时间里完成大部分交互工作。
控制动作必须有确认和回执
- 按钮提交前显示目标设备、动作和当前状态。
- 发送后等待明确回执，不把请求发出当作执行成功。
- 超时后显示“结果待确认”，不要自动重复下发。
- 记录操作人、时间、参数和设备返回值。
AI 生成的界面如果省略这些步骤，看起来很顺滑，实际上无法追溯。涉及真实设备时，宁可多一个确认框，也不要把不确定状态伪装成成功。
异常处理要单独测试
至少测试通信断开、数据类型错误、设备重启、权限不足和重复点击。每种异常都应该有用户能理解的提示、日志里的原始信息和恢复办法。可以让 AI 根据字段字典生成测试清单，但最终结果仍需由熟悉工艺的人确认。
从原型走向部署
小型工具可以先在单机上运行；正式部署时，再考虑服务进程、日志轮转、权限分级和离线恢复。AI 适合协助整理代码和文档，不应绕过现场安全制度。需要先做一个可运行小工具时，可参考站内的零代码 AI 开发入门。
