AI生成的PLC代码到底靠不靠谱？研究人员故意往ST程序里埋了108个Bug！

现在越来越多的大模型开始生成 PLC Structured Text 代码。

但一直有个关键问题没有解决：

AI 生成的 PLC 程序，到底应该怎么证明它是可靠的？

只看代码能不能编译，显然远远不够。因为很多危险错误并不会产生语法报错。

例如：

MotorRun := AutoMode AND SafetyReady;
如果有人把 AND 改成 OR：
MotorRun := AutoMode OR SafetyReady;
程序依然可以正常编译，但设备的启动条件
已经完全变了。

01

论文研究

最近，一篇名为 STMutants 的论文给出了一种很有价值的思路：研究人员故意在 Structured Text 程序中植入 Bug，再检查 AI 生成的测试能不能发现这些错误。

研究团队选择了 11 个 ST 程序，包括 PID、流量计、交通灯、刀库、信号发生器和顺序控制等，总共制造了 110 个一阶变异体。

经过编译、可观察性和等价性筛选后，最终保留了 108 个有效错误版本。

这些错误包括：

• 修改数值和时间常量
• 把 > 改成 >=
• 把乘法改成加法
• 删除或者增加 NOT
• 把 AND 改成 OR
• 删除缩放运算
• 修改变量初始化状态

这些都是 PLC 项目中可能真实出现的错误。

随后，研究人员让 GPT-5.2、Gemini 2.5 和 Claude Sonnet 4.5 分别生成 ST 单元测试，再使用 MATIEC 实际运行原始程序和错误程序。

结果显示：

Gemini 2.5：发现 102 个，94.4%
GPT-5.2：发现 93 个，86.1%
Claude Sonnet 4.5：发现 93 个，86.1%

单看这个结果似乎非常不错，大模型生成的测试已经能发现大多数人为植入的错误。

但真正值得警惕的是另一个结果。

在一个包含深层状态转换的顺序控制程序 SEQUENCE_8 中：

GPT-5.2：发现率 50%
Gemini 2.5：发现率 10%
Claude Sonnet 4.5：发现率 10%

为什么成绩突然这么差？

因为这类程序不是给一个输入、马上产生一个输出。它需要经过多个 PLC 扫描周期，内部状态不断演化，错误才会逐渐传递到最终输出。

这正是当前大模型的明显短板：

它们擅长分析局部代码，却未必能够可靠推演跨扫描周期、带状态保持的 PLC 顺序逻辑。

而真实工业程序中，最危险的问题往往就在这里：

• 定时器到期后的状态转换
• 正反转互锁
• 故障锁存和复位
• 上升沿、下降沿触发
• 自动与手动模式切换
• 多设备顺序控制
• 通信超时与故障恢复

所以，这篇论文最重要的结论并不是“某个模型得了第一名”，而是告诉我们：

AI 生成 PLC 代码之后，必须经过编译、测试、仿真和安全属性验证，不能只依靠大模型自己审查大模型。

02

启发

这对 RealPLC 也非常有启发。RealPLC 当前正在建立：

AI 生成 SCL
→ TIA Agent 导入
→ TIA Portal 编译
→ 返回 diagnostics
→ AI 自动修复

这可以解决代码语法、接口、数据类型和工程对象问题。

但下一步还需要建立自己的 SCL 变异评测库：

正确程序
→ 自动注入已知缺陷
→ 生成测试用例
→ TIA 或仿真执行
→ 计算缺陷发现率
→ AI 定位并修复
→ AI 定位并修复


未来评价一个 PLC AI 系统，不能只看它
“生成了代码”，而要看：

编译成功率
缺陷发现率
安全缺陷发现率
误报率
修复成功率
平均修复次数

AI 生成 PLC 代码并不是终点。真正有价值的工业 AI，必须完成：

需求理解、代码生成、官方编译、自动测试、缺陷修复和工程师审批的完整闭环。

这才是 AI PLC 编程从“演示效果”走向“工程可用”的关键一步。如果对您有启发，还请点赞👍、推荐和转发哦！

参考链接：

【1】https://arxiv.org/pdf/2606.05499

【2】https://www.realplc.com