很多团队试过「让 AI 写 PLC 代码」，结论往往两极：要么觉得惊艳，要么觉得不好用。差异通常不来自模型本身，而来自工作流有没有打通。

一、传统工作流里的三处断点

在把 AI 接进来之前，先看看断点在哪里：

  1. 上下文要人工搬运：变量表、既有功能块、类型定义分散在工程各处，人得先复制粘贴给 AI，AI 才可能给出可用的建议。
  2. 建议无法被验证：AI 输出的是文本，编译器和调试器不在回路里。对不对，只能靠人肉判断。
  3. 改动与工程状态脱节：AI 给了一段更好的写法，但要落到工程里，还得人工转录一遍，错误在这一步产生。

AI 原生要解决的，正是这三处断点：上下文自动进、结果自动验、改动直接落到工程。

二、四个环节，AI 与系统各做什么

环节 工程师 AI 系统（平台侧）
① 需求描述 用自然语言说明控制意图与约束 澄清歧义，补全边界条件 提供工程上下文（变量、类型、库）
② 生成 指定范围与风格 生成程序、功能块、测试用例 通过协议层调用工具写入工程
③ 校验 判断逻辑是否满足工艺要求 依据错误与告警迭代修改 编译器与语言服务给出可复现的结果
④ 调试 观察运行行为、确认异常路径 辅助定位、提出修改建议 启动仿真或调试会话，读变量、看执行流

关键在于 ② 和 ③ 之间没有人工转录：AI 调用的不是「一段文本」，而是真实的工程工具（读写变量、创建功能块、触发编译、启动调试）。这也是 AI 原生与传统「AI 增强」的分界 —— 前者把 AI 放进回路，后者把 AI 放在旁边。

三、为什么「校验」这一环决定成败

  • 生成不等于正确：语法正确、编译通过，与逻辑满足工艺要求是三件事。
  • 编译通过不等于逻辑正确：编译器的职责是语言与结构正确性，不负责判断「这个联锁条件是否符合安全规范」。
  • 可复现的反馈才有迭代价值：AI 需要的是确定的报错信息与明确的行为观察，而不是模糊的「不太对」。

因此，工作流里必须保留两道人参与的关口：需求确认与关键逻辑评审。AI 负责把工程量降下来，不负责把责任接过去。

四、可直接落地的实践清单

  • 小步推进：一次让 AI 处理一个功能块或一个设备单元，而不是整个工程。
  • 约定命名与单位：变量命名、单位标注、注释语言先定规则，再让 AI 生成，产出质量会明显稳定。
  • 把 AI 产出当草稿评审：合入前逐段读一遍，尤其是条件分支与边界处理。
  • 让编译器当第一道过滤器：每次生成后立即编译，用确定性的报错驱动下一轮修改。
  • 关键逻辑补测试用例：联锁、报警、急停路径这类逻辑，配一个可重复执行的用例。
  • 保留可读性：AI 写的代码也要满足团队的注释与结构规范，否则三个月后没人敢改。
  • 记录变更原因：把「为什么这样改」写进提交信息，比代码本身更能帮到后来的人。

五、延伸阅读

本文为技术解读，不替代产品文档；涉及具体操作与版本行为的细节，以知识中心为准。