工业自动化中的 AI

文章指南

如何为 Yaga 编写基于控制哲学的 PLC 编程 AI 提示词

结构化的 PLC 提示词远胜于开放式请求。通过定义标签、安全状态、允许条件、互锁、顺序逻辑和故障处理,Yaga 能够生成可在 OLLA Lab 中进行测试的梯形图脚手架。

直接回答

有效的 PLC 编程 AI 提示词需要结构化的控制哲学,而非开放式的请求。当工程师提供明确的 I/O 映射、允许条件(Permissives)、互锁(Interlocks)、顺序状态和故障条件时,Yaga 能够生成在 OLLA Lab 仿真环境中更易于验证的梯形图逻辑脚手架。

本文回答的问题

文章摘要

有效的 PLC 编程 AI 提示词需要结构化的控制哲学,而非开放式的请求。当工程师提供明确的 I/O 映射、允许条件(Permissives)、互锁(Interlocks)、顺序状态和故障条件时,Yaga 能够生成在 OLLA Lab 仿真环境中更易于验证的梯形图逻辑脚手架。

AI 在 PLC 工作中的失败并非因为其“代码编写能力差”,而是因为梯形图逻辑不仅仅是代码生成,它是在约束条件、扫描顺序和异常状态下的确定性控制行为。这一点往往被忽视。

在 OLLA Lab 的 Yaga Assistant 最近的一次内部测试中,包含标签字典、定义安全状态以及至少一个明确互锁的提示词,在 24 项任务中有 22 项(91.7%)生成了可用于仿真的初步脚手架;而诸如“编写一个泵的顺序逻辑”之类的通用提示词,在 24 项任务中有 17 项(70.8%)在仿真前需要进行重大修正。方法论:n=48 次提示词任务运行,涵盖泵、搅拌机、传送带和罐液位练习;基准比较器 = 通用自然语言提示词 vs. 结构化控制哲学提示词;时间窗口 = 2026 年 2 月至 3 月的内部测试期。这支持了一个狭义的结论:提示词结构对仿真中的初步可用性有显著影响。这并不能证明其具备现场部署能力、安全性或生产就绪性。

在自动化领域,提示工程应被狭义定义:将机械约束、I/O 映射和安全互锁系统性地转化为机器可读参数,以便 AI 代理能够生成语法正确、可测试的脚手架。这是一个有用的工具,而非工程判断的替代品。OLLA Lab 在此作为验证循环发挥作用,而非作为许可凭证。

为什么通用大语言模型在梯形图逻辑生成上会失败?

通用大语言模型在梯形图逻辑上失败,是因为它们预测的是合理的标记序列,而 PLC 针对有状态的输入和输出执行确定性的扫描逻辑。语言模型看到的是文本的连续性;控制器看到的是评估顺序、内存位、边沿条件和设备状态。

梯形图逻辑也是空间性的。并行分支、自锁路径、允许条件链和互斥状态通过结构承载意义,而不仅仅是通过文字。通用大语言模型倾向于将这种结构线性化为文本,并在此过程中丢失执行意图。这就是为什么 AI 生成的梯形图看起来很专业,但行为却很糟糕的原因之一。

第二个失败模式是对扫描周期的感知较弱。PLC 逻辑被重复评估,输出可能会根据程序结构在同一扫描周期内被写入、重置或覆盖。如果没有明确的约束,大语言模型可能会生成:

  • 对同一输出线圈的重复写入,
  • 缺失的单脉冲(One-shot)行为,
  • 自动和手动模式之间的竞争条件,
  • 计时器重置条件不明确,
  • 缺乏死区或故障处理的模拟量阈值,
  • 出现在注释中但未出现在可执行逻辑中的互锁。

常见的结果是从业者所熟悉的:逻辑读起来很通顺,但一旦输入发生变化就会表现异常。语法是廉价的,确定性则更难实现。

这一局限性与关于大语言模型推理和代码可靠性的文献广泛一致。跨软件和具身系统的已发表研究表明,当任务需要持久状态跟踪、空间推理或精确的约束满足,而不是流畅的模式补全时,输出质量会下降(Bubeck 等人,2023;Huang & Chang,2023)。PLC 编程在上述三点上尤其严苛。

什么是工业级自动化 AI 提示词?

工业级自动化 AI 提示词是一份紧凑的功能规范。它应该告诉模型机器是什么、什么是“安全”状态、存在哪些设备、在允许动作前必须满足什么条件,以及应如何处理故障。如果提示词无法支持基本的功能设计规范(FDS)审查,那么它对于可靠的梯形图生成来说可能太模糊了。

在实践中,好的 PLC 提示词表现得不像搜索查询,更像是对初级控制工程师的指令。资深工程师不会说“给我做一个泵程序”,他们会指定工艺流程、标签、顺序、跳闸条件和预期的故障安全状态。

自动化提示词的 3 大支柱

#### 1. 上下文与目标

陈述机器或工艺单元、操作目标和安全状态。

包括:

  • 设备类型,
  • 操作模式,
  • 启/停目标,
  • 安全停机条件,
  • 异常状态预期。

示例:

  • “单台输送泵用于填充日用罐。”
  • “安全状态为泵关闭且出口阀关闭。”
  • “如果液位变送器无效,禁止自动启动。”

#### 2. I/O 和标签字典

明确定义标签。当命名明确且类型化时,AI 的表现更好。

包括:

  • 数字量输入,
  • 数字量输出,
  • 模拟量输入,
  • 相关的模拟量输出,
  • 内部内存位,
  • 计时器和计数器,
  • 报警或故障位。

示例:

  • `DI_PB_Start`
  • `DI_PB_Stop`
  • `DI_EStop_OK`
  • `AI_Tank_Level_Pct`
  • `DO_Pump_Run`
  • `M_Auto_Mode`
  • `T_FillTimeout`

命名规范并非装饰,它是可追溯逻辑与调试成本之间的区别。

#### 3. 允许条件与互锁

定义在动作发生前必须满足的条件,以及什么会导致动作停止。

包括:

  • 允许条件(Permissives),
  • 跳闸条件(Trips),
  • 模式限制,
  • 反馈要求,
  • 超时行为,
  • 报警条件。

示例:

  • 仅当 `DI_EStop_OK = TRUE` 时泵方可启动
  • 仅当 `AI_Tank_Level_Pct < 80` 时泵方可启动
  • 如果 `AI_Tank_Level_Pct >= 95`,泵必须停止
  • 如果运行命令为真且 3 秒内无运行反馈,则发出报警

这是许多提示词失效的地方。工程师通常只指定“理想路径”,而忽略了机器必须拒绝动作的原因。真实的工厂大部分时间都处于非正常状态。

如何为 AI 提示词定义“控制哲学”?

对于 AI 提示词,控制哲学应定义为生成可测试控制脚手架所需的最低功能规范。它不是营销术语,也不是模糊的设计叙述。在操作层面,它应包含控制工程师在 FDS 文档中所期望的核心行为:

  • 初始状态,
  • 操作模式,
  • 操作顺序,
  • 允许条件,
  • 互锁,
  • 报警和跳闸,
  • 故障响应,
  • 重置行为,
  • 操作员动作,
  • 成功标准。

该定义受工程可观测量的限制。如果提示词没有告诉模型当传感器故障、盖子打开、液位超过阈值或反馈从未到达时工艺应如何处理,那么该提示词就不是控制哲学。

这种框架与既定的工业文档实践相一致。IEC 61131-3 规范了 PLC 编程语言,但良好的梯形图逻辑仍然依赖于上游的功能清晰度。标准无法挽救模糊的意图。

一个需要摒弃的有用误区

自动化领域的提示工程不是为了让 AI 更有创造力,而是为了让规范更少歧义。

如何为 Yaga Assistant 构建控制哲学?

提示 Yaga 最有效的方法是提供一个受限的、可重用的模板。应告知模型角色、工艺目标、标签、顺序、允许条件、互锁和预期的输出格式。如果其中任何一项是隐含的,模型可能会进行即兴发挥。

推荐的 Yaga 提示词模板

扮演一名 IEC 61131-3 梯形图逻辑助手。

目标: 为以下控制任务创建梯形图逻辑脚手架。

系统描述:

  • 设备:[机器/工艺单元]
  • 操作目标:[系统应执行的操作]
  • 安全状态:[停止或故障时必须为真的输出/状态]

I/O 和标签字典: 数字量输入:

  • [标签]:[描述]
  • [标签]:[描述]

数字量输出:

  • [标签]:[描述]

模拟量输入:

  • [标签]:[描述及工程单位]

内部位 / 计时器 / 计数器:

  • [标签]:[用途]

操作模式:

  • [自动 / 手动 / 维护]
  • [模式规则]

操作顺序:

  1. [步骤 1]
  2. [步骤 2]
  3. [步骤 3]

允许条件:

  • [启动前必须满足的条件]
  • [转换前必须满足的条件]

互锁 / 跳闸:

  • [必须停止或禁止操作的条件]
  • [故障条件及响应]

报警:

  • [报警条件]
  • [超时条件]

重置 / 恢复规则:

  • [手动重置要求]
  • [允许时的自动重置规则]

输出要求:

  • 使用清晰的梯形图结构(逐行)
  • 不要在多个冲突位置写入同一个输出线圈
  • 在需要时使用命名的内部位表示顺序状态
  • 为每一行梯形图添加注释
  • 明确标识假设

此模板不能保证逻辑正确,但它做了一件更有用的事:让错误更早显现。

初级提示词 vs. 资深提示词

| 提示词风格 | 示例 | 可能的结果 | |---|---|---| | 初级提示词 | “做一个梯形图,当我按下开始键时,让搅拌机运行 10 秒。” | 停止行为模糊,缺少盖子互锁,重置逻辑不清,标签结构薄弱 | | 资深提示词 | “扮演一名 IEC 61131-3 程序员。为搅拌机创建梯形图脚手架。输入:`PB_Start` (NO), `PB_Stop` (NC), `LS_LidClosed`, `EStop_OK`。输出:`MTR_Mixer`。互锁:除非盖子关闭且急停健康,否则搅拌机不能运行。使用 TON 实现 10 秒运行周期。盖子打开或收到停止命令时立即停止。安全状态 = 电机关闭。提供梯形图注释并标识假设。” | 具备明确允许条件的测试基准,更安全的停止行为,更清晰的仿真路径 |

区别不在于辞藻,而在于约束密度。

在 AI 编写第一行逻辑前,PLC 提示词应包含什么?

好的 PLC 提示词应将机器定义为一个有状态的系统,而不是一个口头任务。在 Yaga 编写任何一行逻辑之前,提示词应已回答六个工程问题。

1. 系统是什么?

定义设备、工艺边界和预期操作。

示例:

  • “带高液位报警和交替运行功能的双泵站。”

2. 什么是“正确”行为?

用可观察的术语定义操作成功条件。

示例:

  • “在自动模式下,主泵在集水井液位 70% 时启动,30% 时停止;备用泵在 90% 时启动;两者在急停或电机过载时停止。”

这一点很重要,因为“仿真就绪”应从操作层面定义:当工程师能够证明、观察、诊断并针对现实工艺行为强化控制逻辑,使其在进入实际工艺前达到要求时,即为仿真就绪。这比单纯了解梯形图语法标准更高。

3. 标签和信号类型是什么?

列出标签、信号方向和单位。

示例:

  • `AI_WetWell_Level_Pct` = 模拟量输入,百分比
  • `DI_P1_OL_Trip` = 数字量输入,过载跳闸
  • `DO_P1_RunCmd` = 数字量输出

4. 存在哪些异常条件?

定义故障、无效状态和故障响应。

示例:

  • 液位变送器质量差,
  • 命令发出后无运行反馈,
  • 两个过载均激活,
  • 急停不健康,
  • HOA 开关冲突。

5. 绝对不能发生什么?

明确陈述禁止的行为。

示例:

  • “在手动交替逻辑中,绝不能同时命令两台泵运行。”
  • “过载重置后,未经操作员动作不得自动重启。”
  • “盖子打开时不得启动搅拌机。”

6. 允许哪些假设?

要求 AI 声明假设,而不是掩盖它们。

示例:

  • “除非另有说明,假设停止按钮为健康的常闭(NC)触点。”
  • “假设模拟量缩放已在上游完成。”

隐藏的假设是 AI 生成的梯形图逻辑薄弱的常见来源。

OLLA Lab 如何验证 AI 生成的逻辑?

OLLA Lab 通过将 AI 生成的逻辑置于仿真环境中来验证它,在该环境中,输入、输出、变量和设备行为可以在考虑任何实际部署之前进行观察和操作。这使其成为一个风险受控的验证循环,而非预言机。

梯形图编辑器提供逻辑界面。仿真模式提供执行。变量面板提供对标签、I/O 状态、模拟值和控制变量的可观测性。它们共同让工程师能够测试生成的逻辑在条件变化时是否按预期运行。

实际上,这意味着您可以:

  • 切换数字量输入,
  • 强制触发故障条件,
  • 检查输出响应,
  • 观察计时器和内部位的状态变化,
  • 对比梯形图状态与仿真设备行为,
  • 在测试失败后修改逻辑。

验证不是一张看起来正确的梯形图截图。验证是一系列被证伪的假设,随后是更严谨的逻辑。

生成-验证循环的样子

  1. 使用 Yaga 生成脚手架 使用结构化的控制哲学提示词。
  2. 检查生成的梯形图 检查标签名称、输出所有权、顺序结构和互锁位置。
  3. 在仿真中运行逻辑 从额定条件开始。
  4. 注入异常条件 强制传感器丢失、无效的允许条件、盖子打开状态、过载跳闸或超时情况。
  5. 观察逻辑是否安全失效 确认安全停止、报警锁存、禁止重启或按要求保持状态。
  6. 修改并重新测试 收紧提示词或直接编辑梯形图。

这就是 OLLA Lab 在操作上变得有用的地方。它为工程师提供了一个排练高风险任务的场所,而实际系统在这方面往往教学效果不佳。

如何测试 Yaga 的梯形图逻辑是否足够安全以继续?

通过在信任正常顺序之前定义故障案例来进行测试。一个仅在每个信号都表现正常时才有效的梯形图程序并未经过验证,它只是未受挑战。

至少在仿真中测试以下类别。

输入完整性故障

  • 传感器卡在高位,
  • 传感器卡在低位,
  • 变送器超出范围,
  • 模拟值错误,
  • 命令发出后无反馈。

互锁故障

  • 急停不健康,
  • 防护罩或盖子打开,
  • 运行期间允许条件丢失,
  • 过载跳闸激活,
  • 阀门位置反馈未到位。

顺序故障

  • 计时器从未重置,
  • 状态位保持锁存,
  • 手动和自动命令重叠,
  • 跳闸后未经重置即重启,
  • 停止路径后输出仍带电。

模拟量和 PID 相关故障

  • 过程变量超过跳闸阈值,
  • 缺少模拟量死区,
  • 阈值附近报警抖动,
  • 控制器输出饱和,
  • 模式切换导致冲击。

OLLA Lab 中模拟量工具和 PID 仪表盘的存在非常重要,因为许多 AI 示例仍被困在离散逻辑中。实际的工艺控制通常并非如此。泵站、空气处理机组(AHU)、热回路或加药撬块通常包含阈值、延迟、死区和依赖于模式的行为。

搅拌机控制提示词的示例是什么样的?

一个有效的示例应展示从工艺意图到机器可读约束的转化。以下是一个适用于 Yaga 的紧凑搅拌机示例。

示例结构化提示词

扮演一名 IEC 61131-3 梯形图逻辑助手。

系统描述:

  • 设备:批处理搅拌机
  • 操作目标:在操作员启动命令后运行搅拌机 10 秒
  • 安全状态:在停止、急停丢失或盖子打开时立即关闭搅拌机电机

I/O 和标签字典: 数字量输入:

  • DI_PB_Start:启动按钮,常开
  • DI_PB_Stop:停止按钮,常闭
  • DI_Lid_Closed:盖子关闭证明
  • DI_EStop_OK:急停健康

数字量输出:

  • DO_Mixer_Run:搅拌机电机运行命令

内部位 / 计时器:

  • M_Mix_Cycle_Active:混合周期激活锁存
  • T_Mix_Run:10 秒 TON 计时器

操作顺序:

  1. 收到启动命令后,仅在盖子关闭且急停健康时开始混合周期
  2. 运行搅拌机电机 10 秒
  3. 计时器完成后停止电机
  4. 如果收到停止命令、盖子打开或急停不健康,立即中止

允许条件:

  • DI_Lid_Closed = TRUE
  • DI_EStop_OK = TRUE
  • DI_PB_Stop 健康

互锁 / 跳闸:

  • 如果运行期间盖子打开,立即断开 DO_Mixer_Run
  • 如果急停不健康,立即断开 DO_Mixer_Run

输出要求:

  • 提供逐行的梯形图脚手架
  • 为 DO_Mixer_Run 使用一个输出所有权路径
  • 添加梯形图注释
  • 陈述任何假设

生成后检查事项

在 Yaga 生成梯形图后,检查:

  • `DO_Mixer_Run` 是否只有一个清晰的所有权路径,
  • 计时器使能是否与激活的周期状态绑定,
  • 在盖子打开或急停丢失时是否立即断开,
  • 是否没有隐藏的自动重启,
  • 注释是否与实际梯形图行为匹配,
  • 是否有明确的假设。

然后在仿真中运行它,并在定时运行期间强制 `DI_Lid_Closed` 为假。如果电机命令仍然存在,则提示词或逻辑有误。

工程师应如何可靠地记录 AI 辅助的 PLC 工作?

工程师应将 AI 辅助的 PLC 工作记录为工程证据,而不是界面截图库。一份可靠的记录应展示系统应该做什么、它是如何被测试的、它是如何失败的,以及它是如何被修正的。

使用此结构:

  1. 系统描述 定义设备、工艺目标、操作模式和安全状态。
  2. “正确”的操作定义 陈述可观察的成功标准,包括停止条件和异常状态行为。
  3. 梯形图逻辑和仿真设备状态 展示生成的或编辑后的梯形图,以及相关的仿真机器状态或变量行为。
  4. 注入的故障案例 记录引入的确切故障:传感器丢失、过载、允许条件丢失、超时、无效模拟值等。
  5. 所做的修订 记录用于修正行为的逻辑变更或提示词优化。
  6. 经验教训 陈述故障揭示了关于原始控制哲学、假设或顺序设计的哪些信息。

这将产生一份紧凑的证据,对审查员、导师或招聘经理非常有用。

AI 辅助 PLC 提示工程的局限性是什么?

AI 辅助 PLC 提示工程对于脚手架搭建、起草和加速初步逻辑结构非常有用。它不足以用于安全验证、调试签字或特定现场的部署决策。

该界限对于伦理和工程都至关重要。OLLA Lab 在此被描述为一个基于 Web 的交互式梯形图逻辑和数字孪生仿真器,通过 Yaga、3D/WebXR/VR 仿真、基于场景的练习、模拟量和 PID 工具以及导师工作流提供指导支持。这些功能使其作为排练和验证环境非常有用。它们并不能通过关联将生成的逻辑转化为已批准的工厂逻辑。

一些局限性应保持明确:

  • AI 生成的梯形图在语法上可能是合理的,但在功能上是不安全的。
  • 仿真可以暴露许多逻辑缺陷,但它不等同于现场调试。
  • 数字孪生验证取决于模型保真度和场景范围。
  • 功能安全义务仍然需要正式的方法、胜任的审查和基于标准的生命周期纪律。

这与更广泛的安全文献一致。IEC 61508 及相关指南将系统性故障、规范错误和验证纪律视为核心关注点。一个能快速生成代码的模型并不能消除这些职责。

为什么这种方法比要求 AI “编写程序”更有用?

这种方法更有用,因为它将任务从无约束的生成转变为有界的工程。当你首先编写控制哲学时,你迫使重要的决策公开化:安全状态、允许条件、跳闸、顺序所有权和故障响应。

这有三个实际好处:

  • 更好的初步脚手架,
  • 仿真中更快的调试,
  • 人类更清晰的审查。

它还培养了正确的习惯。职业转变不仅是从不懂梯形图到懂梯形图,而是从编写梯形图到捍卫行为。

继续探索

Interlinking

References

编辑透明度

本博客文章由人类作者撰写,核心结构、内容和原创观点均由作者本人创建。但本文部分文本在 ChatGPT 和 Gemini 的协助下进行了润色。AI 仅用于语法与句法修正,以及将英文原文翻译为西班牙语、法语、爱沙尼亚语、中文、俄语、葡萄牙语、德语和意大利语。最终内容已由作者进行严格审阅、编辑与验证,作者对其准确性承担全部责任。

作者简介:PhD. Jose NERI, Lead Engineer at Ampergon Vallis

事实核验: 技术有效性已于 2026-03-24 由 Ampergon Vallis 实验室 QA 团队确认。

可直接实施

使用仿真支撑的工作流,将这些洞见转化为可衡量的工厂成果。

© 2026 Ampergon Vallis. All rights reserved.
|