为什么大语言模型在梯形图逻辑上表现不佳？OLLA Lab 的图形化优势

大语言模型（LLM）在处理梯形图逻辑时之所以困难，是因为它们预测的是一维文本，而梯形图（Ladder Diagram）和顺序功能图（SFC）依赖于二维空间关系、并行执行和扫描周期顺序。OLLA Lab 提供了一个可视化仿真环境，工程师可以在逻辑进入实际生产流程之前，在此验证功率流、I/O 行为和定时错误。

AI 在梯形图逻辑上的失败，主要原因并非梯形图语法晦涩难懂，而是因为 PLC 控制不仅仅是语法问题，它是在确定性扫描定时下的空间执行过程。这种区别比大多数提示工程（prompt-engineering）建议所承认的更为重要。

在最近的一次内部基准测试中，我们将 50 个由 AI 生成并导入 OLLA Lab 仿真引擎的电机控制电路进行了测试。结果显示，68% 的 AI 建议序列在第一个虚拟扫描周期就失败了，这主要是由于梯级顺序（rung-order）和状态依赖错误，而非语法错误。方法论：样本量 = 50 个生成的电机控制任务；任务定义 = 导入并仿真 AI 生成的启动/停止、自锁、允许条件（permissive）和故障复位模式；基准比较器 = 经 Ampergon Vallis 工程评审认可的人工参考实现；时间窗口 = 2026 年第一季度。该指标支持一个狭义的观点：AI 生成的梯形图逻辑即使在结构上看起来合理，也往往会在执行时失效。但这并不支持“所有 AI 生成的 PLC 逻辑都不可用”这一普遍结论。

这才是真正的问题所在：文本的合理性与可部署的控制行为之间的差距。PLC 并不是在批改论文。

梯形图逻辑对 LLM 来说很困难，因为模型预测的是序列化文本，而梯形图通过二维拓扑结构来表达控制意图。这种不匹配是架构上的，而非表面上的。

IEC 61131-3 将梯形图（LD）和顺序功能图（SFC）定义为图形化语言，用于表达比单纯的平面文本更易于视觉推理的控制关系。在 LD 中，分支结构、功率流、梯级顺序和并行条件都是含义的一部分。在 SFC 中，发散、汇合、活动步和转换归属权同样是含义的一部分。当这种结构被扁平化为 XML、JSON 或提示文本时，部分执行上下文就容易丢失或产生错误绑定。

一维与二维执行的鸿沟

• Python 或 C 等文本语言：主要以线性顺序序列化意图。即使它们表达分支或并发，其表示形式仍然是 Token 序列化且明确的。
• 梯形图（LD）：将逻辑编码为一种电气风格的网络，具有从左到右的功率流和从上到下的评估顺序。并行分支并非装饰，它们定义了执行关系。
• 顺序功能图（SFC）：在空间上编码状态演变。发散和汇合指示了并行或替代路径，当简化为纯文本结构时，这些路径很难被保留。
• LLM：根据训练模式预测下一个可能的 Token。它们可以模仿梯形图符号，但模仿并不等同于在控制图中维护拓扑不变性。

关于 LLM 推理的研究反复表明，Token 预测不能可靠地保留空间或拓扑结构，特别是在任务需要在非线性表示之间进行一致映射时。序列模型在进行合理的续写方面表现更好，而在确定性的空间簿记方面则较弱。

AI 生成的梯形图逻辑经常失败，因为 PLC 在确定性的扫描周期内执行，而许多生成的序列忽略了这种执行顺序。一个孤立看合理的梯级，在控制器按顺序读取输入、求解逻辑并更新输出时，可能会失败。

标准的扫描模型非常直接：

1. 读取输入
2. 执行逻辑
3. 更新输出
4. 重复

该周期可能在毫秒内运行，但如果逻辑排序不当，其定时足以产生竞争条件、陈旧状态读取和错误的允许条件。

“看起来正确”的谬误

最常见的 AI 错误不是无效语法，而是看起来有效但执行行为无效的逻辑。示例包括：梯级顺序颠倒、过早的输出依赖、自锁逻辑损坏、不当的复位排序以及非法或不可编译的分支结构。

这就是可视化验证在操作上变得有用的地方。你需要看到活动路径、切换输入、检查标签，并观察序列按顺序失败。仅凭文本导出是无法揭示这一点的。

AI 在 SFC 上表现不佳，因为 SFC 是一种视觉状态机，其含义取决于分支归属、同步步激活和转换准则。如果草率地扁平化图表，机器逻辑就会变得模棱两可。SFC 对 LLM 来说通常比基础梯形图更难，因为模型必须保留哪些步同时处于活动状态、哪个转换属于哪个分支、发散从何处开始以及汇合在何处合法解决。

图形化表示之所以重要，是因为控制的正确性不仅是逻辑上的正确性，也是在真实工厂行为下的可观察序列正确性。在工业自动化中，问题很少仅仅是“梯级能编译吗？”真正的问题更接近于：泵是否仅在允许条件为真时启动？验证反馈是否在预期时间内到达？报警是否正确锁存？

这就是为什么标准和安全实践强调验证、确认和生命周期纪律，而不是盲目信任生成的代码。仿真和基于数字孪生的验证在这里变得越来越重要，因为它们允许工程师在现场接触前测试行为。

OLLA Lab 通过为工程师提供一个有界的视觉环境来构建、仿真、检查和修改控制逻辑，从而弥合了 AI 差距。它不是 AI 的替代品，也不是现场能力的保证，而是一个验证和演练层。

OLLA Lab 在此工作流中的作用

在产品范围内，OLLA Lab 提供：

• 用于构建和修改梯级的基于 Web 的梯形图逻辑编辑器，
• 用于安全运行和停止逻辑的仿真模式，
• 用于监控输入、输出、标签、模拟量值和 PID 相关状态的变量面板，
• 可用的 3D/WebXR/VR 设备视图，
• 将梯形图逻辑与真实机器或过程行为连接起来的基于场景的实验室。

使用得当，这支持了一种严谨的工作流：将 AI 生成的建议作为草稿，重建或导入到可视化环境中，定义预期序列，在仿真中切换输入并观察输出，最后修改逻辑并重新测试。

工程师应将 AI 生成的梯形图逻辑视为来自初级贡献者的不可信草稿：可用于加速，不可作为最终权威，且仅在确定性评审后才可接受。

1. 在审查代码前定义控制意图：明确启动、停止、允许、跳闸、复位规则及报警行为。
2. 检查执行顺序，而不仅仅是语法：审查梯级顺序、分支合法性、状态依赖及锁存行为。
3. 仿真标称和异常情况：测试正常运行及各种故障场景。
4. 比较控制器状态与设备状态：确保模拟设备行为符合预期。
5. 修改并重新测试，直到序列稳定。

可信的工程证据不是截图画廊。它是一份紧凑的记录，表明工程师定义了正确性、测试了故障、修改了逻辑并学到了具体的东西。应包含：系统描述、正确操作定义、梯形图逻辑与模拟设备状态、注入的故障案例、所做的修改以及经验教训。

AI 对 PLC 编程仍然有用，但主要是作为草稿和辅助层，而不是执行权威。它擅长模式回忆、样板生成、解释和翻译支持。它在跨图形控制语义维护确定性行为方面较弱。

实际的区别很简单：草稿生成与确定性否决。AI 可以帮助编写草稿，而仿真和工程评审拥有否决权。

现有证据支持一个狭窄但重要的结论：LLM 在梯形图逻辑和 SFC 上表现不佳，不是因为工业控制太小众而无法描述，而是因为这些语言通过空间结构、并行关系和扫描周期执行来编码含义，而这些含义无法通过一维 Token 预测自然保留。

这一结论并不意味着 AI 与自动化无关。它意味着验证负担仍然牢牢地落在工程师身上。语法是廉价的，确定性才是昂贵的部分。

- IEC 61131-3: 可编程控制器 — 第 3 部分：编程语言 - IEC 61508 功能安全标准系列 - NIST AI 风险管理框架 (AI RMF 1.0) - 欧盟工业 5.0 政策背景 - 数字孪生概述 (NIST)

本文由 Ampergon Vallis Lab 的自动化工程团队撰写，专注于工业控制系统的逻辑验证与仿真技术。

本文内容经过 Ampergon Vallis 工程评审委员会核实，基于 2026 年第一季度针对 AI 生成梯形图逻辑的仿真基准测试数据。