十年PLC工程师的AI编程实战：从ST语言生成到程序审查避坑

干了十年PLC编程，最近开始让AI替我写程序。这话搁两年前我自己都不信，毕竟干我们这行的，谁不是从梯形图一个触点一个线圈磕出来的。但现实就是，这半年我实打实把AI嵌进了日常PLC编程工作流里，从ST语言功能块生成到报警文本整理，从说明书解读到程序注释补齐，AI确实替我扛掉了一大坨重复劳动。这篇东西不聊虚的，就说我这半年怎么用、踩了哪些坑、哪些活敢交给AI、哪些死活不敢。

1. 为什么干了十年的老工程师，也开始用AI写PLC程序

1.1 最初的抵触到第一次试探

在工控圈里有个很普遍的心态：PLC程序是玩命的活，设备动起来要么出产品要么出事故，谁敢把命交给一个会一本正经胡说八道的语言模型？我一开始也是这么想的。尤其看到网上那些写Python、写Java的人在那喊AI编程多爽，我内心毫无波澜，因为PLC这玩意和互联网开发完全是两个物种。

但真正让我动摇的是一次整理老设备程序文档的任务。一台用了八年的老机器，程序里两万多步，变量名是拼音缩写，注释几乎没有，客户要求做全套技术归档。我对着博途和GX Works翻了一整天，纯粹在干体力活：把网络里的逻辑块抄进Excel，把定时器的时间常数列成表，把人机界面上的报警文本和程序里的置位复位对上号。干到下午眼睛都快花了，我当时就想，这种活要是能让AI干多好。

那天晚上我试着把一段没有注释的ST语言丢给AI，让它帮我加注释。它不但加得明明白白，还把几个可疑的逻辑隐患标了出来，其中一条确实是个联锁缺陷。那一刻我是真服了：AI在理解结构化文本这件事上，比自己想象的靠谱。

1.2 AI在PLC领域到底能干什么

适应了几天之后，我逐渐摸清了AI在PLC领域的能力边界。要用一句概括的话：凡是能写成文字的逻辑，AI都能帮你写；凡是必须靠现场经验和硬件直觉的事，AI一件都干不了。

具体来说，目前我用AI主要干这五类事：

• 生成和翻译ST语言（结构化文本）代码块，包括功能块、函数、循环、数组处理
• 给梯形图项目整理IO表、交叉引用、报警清单这些文档活
• 解读设备手册，比如把一份200页的伺服驱动器说明书压成10条关键参数说明
• 生成HMI脚本逻辑和报警文本初稿
• 做程序审查，把写好的代码丢给它找潜在漏洞

但要强调一个底线认知：AI目前吃透不了你的现场。它不知道你那个接近开关是常开还是常闭，不知道急停回路里那个中继为啥多串了一对触点，也不懂为什么这台设备启动前必须先把气缸回到原点。**这些信息的缺失，意味着AI写的程序绝对不能被直接下载到PLC里跑。**它只能当助手，不能当师傅。能用好这个助手，效率翻倍；把它当师傅，事故翻倍。

2. 把AI放进PLC工作流的正确姿势

2.1 我实际使用的几个场景

用顺了以后，我现在基本上把AI嵌在项目的几个固定环节里。

第一个环节是项目启动时的IO表和变量表设计。以前我都是对着甲方提供的IO清单，一个个在博途里建PLC变量，起名字、选数据类型、写注释，一个两百点的项目至少要耗掉大半天。现在我把IO清单粘贴给AI，让它按照“设备位号_用途_类型”的规范生成PLC变量表，顺带帮你把输入输出地址规划好，它一分钟就能给出一个结构漂亮的结果。我再复制回博途，微调一下地址分配就完事。这活儿AI干得又快又准，因为变量命名本质上就是文字工作。

第二个环节是功能块的编写。这是AI真正省时间的地方，也是我花最多精力调教它的地方。后面第三大章我会把完整的操作流程拆开讲，这里先不展开。

第三个环节是程序翻译和移植。前阵子做一个改造项目，老线是西门子S7-300，新线要用Codesys平台，程序逻辑得重写一遍。我把几百行老的ST程序扔给AI，让它翻译成Codesys语法，它还顺便帮我把不兼容的定时器指令改成了符合IEC 61131-3标准的写法。虽然不能直接用，但相当于白送我一个初稿，省了至少两天的抄写和改写时间。

第四个环节是报警文本和操作说明的生成。这个东西极烦人，又极适合AI。比如你有五十个报警点，每个点要写中文报警内容、可能原因、处理建议。以前要憋很久，现在把报警清单丢给AI，给它几条你写好的范例，它能给你写出风格一致的五十条。HMI上的设备操作说明、点检提示同样适用。

第五个环节是查手册。PLC编程遇到不确定的事太常见了，比如某个指令的确切行为、某个数据块的寻址方式。以前我得翻纸质手册或者PDF，现在我把相关章节丢给AI，让它总结出关键信息和示例代码。等于随身带了一个读完了全部手册的助理。

2.2 提示词怎么写才出活

AI这东西，提问质量直接决定输出质量。我试过随手丢一句“给我写一段星三角启动的程序”，回来的东西完全没法用，因为太笼统了，但一旦约束到位，质量噌噌往上涨。我总结了一个PLC向提示词的套路，五个关键要素缺一不可：

• 身份设定：给它立一个人设，比如“你是一个有十年西门子PLC编程经验的电气工程师”。
• 品牌和软件版本：必须说清楚是西门子博途TIA Portal V17、三菱GX Works3还是Codesys，不同平台语法差异很大，不说版本它只能给你一个通用但落不了地的结果。
• 任务描述：把要实现的工艺逻辑用简洁的话写清楚，最好列出输入条件、输出动作、时序要求。
• 规范要求：比如变量命名的规则、程序段的划分方式、注释要写到什么程度、是否需要使用OB/FC/FB结构。
• 输出格式：要求它给出完整的代码块、变量表和建议的硬件组态说明。

举一个我实际用过的例子。以前写一个物料分拣的控制功能块，我的提示词是这样的：

你是一个有十年西门子PLC编程经验的电气工程师。我使用博途TIA Portal V17，PLC型号S7-1214C DC/DC/DC。请帮我写一个FB功能块，实现以下功能： 输入信号：启动按钮（I0.0），停止按钮（I0.1），传感器A（I0.2），传感器B（I0.3） 输出信号：气缸伸出（Q0.0），气缸缩回（Q0.1），传送带电机（Q0.2），红灯（Q0.3） 工艺要求： 1. 按下启动后，传送带电机启动 2. 当传感器A检测到工件，气缸伸出推料 3. 气缸伸出到位后延时2秒缩回 4. 当传感器B检测到工件通过，计数加1 5. 计数满10个，红灯亮并停止传送带 6. 按下停止按钮，任何状态下都要立即停止并让气缸缩回 规范要求： - 使用IEC 61131-3标准ST语言 - 使用TIA Portal变量表风格，输入输出参数用符号名 - 添加中文注释 - 在注释里说明每个逻辑段的作用 - 注意边界情况：气缸伸出超时报警、传感器B信号抖动处理 输出格式： - 先列出功能块的输入输出参数定义 - 再给出完整ST语言代码 - 最后给一段程序逻辑的文字说明

这样写出来的东西，基本达到了可以人工审查后使用的水平。**提示词的细节程度，决定了你拿到的是垃圾还是半成品。**千万别害羞，把你能想到的约束全扔给它。

2.3 AI工具选型与准备

工具选择上，市面上的大语言模型我基本都试过一遍，最终日常主力用的是通用型的头部模型，因为它的代码理解和生成能力确实最稳。我也试过某些专攻代码的模型，在通用编码上很强，但对PLC这种工业领域的专门知识储备反而一般。我自己的经验是：别迷信“代码专用”的标签，选一个逻辑推理强的通用模型更实在。

除了对话式AI，我还会搭配用一些语法高亮编辑器和仿真软件来做验证。比如在Codesys里建一个仿真工程，把AI生成的代码粘贴进去做离线仿真，这一步我强烈建议每个人都养成习惯，比任何人工审查都直观。

另外还准备一个“资料库”：把我常用品牌的指令手册PDF、库文件说明、典型应用例程都归档好，需要的时候直接作为附件喂给AI。有些AI支持上传文件，这功能非常好用，比如我上传一个三菱FX5U的手册片段，它给出的指令用法精确度立刻上了一个台阶。给AI喂参考资料，等于给徒弟发图纸，不给图纸就干活，指望不上的。

3. AI生成PLC程序的实操全流程

3.1 从需求描述到结构化功能块

拿一个最近很典型的案例来说：给一台加热炉做温度控制的程序框架。我们用AI从零搭一个FB。我把工艺需求写成了提示词，包含了温度检测通道、加热输出、报警阈值、升温速率限制、手动自动模式切换这些信息。AI先是给我了一个参数定义，然后是完整的ST代码，还有一些标准的PID指令调用。

最让我惊喜的是，它自动处理了一个我差点忽略的细节：当模式从自动切换到手动时，输出要做无扰切换处理，也就是保持当前输出值作为手动初始值，防止温度跳变。这个细节在传统开发中，是老师傅才会注意到的经验问题，AI居然主动做了。

但AI也有翻车的时候。有一次它给我生成一个轴控功能块，使用绝对位置控制和相对位置控制混合切换，它给的代码逻辑看着天衣无缝，但在仿真的时候发现，当轴在运动中切换模式时，目标位置的计算会出现一个偏差。因为相对运动模式下，它用的是当前实际位置加偏移，而绝对运动模式下，目标位置直接等于设定值，二者在进行数学换算时丢了一个当前速度前馈量。这就要靠人工去发现和修正，AI是看不出现场运动控制里的这些细节的。

3.2 ST语言代码生成与人工审查

AI生成ST语言的确比生成梯形图靠谱太多。因为结构化文本本质上是文本信息，天然是AI的舒适区。而梯形图是一种图形化语言，AI目前对图形的理解远不如对文字的理解。所以我的建议是：**优先让AI生成ST语言功能块，然后自己在梯形图里调用这些块。**这也是主流的PLC平台都支持的方式，既发挥了AI的长处，也保留了自己对程序的掌控力。

代码生成之后，人工审查这一步绝对不能省。我自己总结了一套审查清单：

• 检查变量类型：BOOL、INT、REAL、TIME是否匹配，尤其是不同品牌PLC的数据类型长度差异
• 检查边界条件：数组访问有没有越界，计数器有没有溢出，有没有除零的可能
• 检查指令兼容性：AI有时会生成当前平台不存在的指令，比如西门子里没有的写法，或者语法正确的但必须启用某库才可用的指令
• 检查时序逻辑：对于需要顺序控制的程序，AI生成的IF ELSE嵌套有时候会忽略状态互锁，需要用状态机思维去审核
• 检查安全回路：急停、安全门、光幕这些安全相关的逻辑，我从不交给AI生成或修改，一律自己手写

**这里有一条铁律：安全回路的代码必须人工手写，禁止让AI参与任何涉及人身安全和设备安全的关键逻辑。**这不是技术保守，而是责任边界的问题。AI可以生成报警文本，可以整理IO表，但涉及到急停、安全门联锁、抱闸控制这类代码，出问题的代价太大了，没有必要冒这个险。

3.3 验证与调试不能省

程序生成完，我的标准动作是先进仿真软件。比如西门子的S7-PLCSIM、Codesys的在线仿真、三菱的GX Simulator，先把AI给的逻辑跑一遍。我习惯把重点放在三个方面的验证：输出条件是否与需求一致、时序是否满足要求、异常输入下程序状态是否安全。

举一个实际例子：我之前让AI帮我写一个自动分拣线的计数程序，它给的程序在普通流程下完全正常。但当我在仿真里模拟了一个异常场景——传感器A连续触发两次而没有B响应时，它的计数逻辑就出现了重复计数。这是因为AI在写代码的时候，只是简单地在A触发时加1，没有考虑到两次A触发之间必须有B复位的逻辑。这个在现场就是工件计数不准、产量数据混乱的问题。经过排查后我在代码里增加了一个复位标志位，这个问题才解决。

**仿真不能发现所有问题，但能发现一大半问题，尤其逻辑漏洞和变量使用错误这一类。**剩下的现场问题，神仙难救，只能靠试车时逐个去查。不过话说回来，AI把工作量从写代码变成了改代码之后，留给试车的问题本来就会少很多。

3.4 让AI补全注释与文档

程序写完后，还有一件烦人的事就是写注释和整理文档。这件事在传统工作流里最容易被拖延，因为不直接影响设备动作，但又直接关系到后续维护成本。一台设备你写程序用了三天，后面维护的人可能要花三年去读它。

我现在的做法是：程序写好之后，把完整的代码复制给AI，让它逐段生成注释说明，包括功能描述、输入输出意义、关键中间变量的作用、使用了哪些定时器和计数器。AI在理解代码方面是强项，它给出的注释比很多工程师手写的还要详细和规范。因为人写注释往往默认自己记得当时的思路，而AI是逐行逐句理解后输出的，反而更适合后来阅读代码的人。

同时在最后我会让AI生成一份程序说明文档，包括系统概述、程序结构、功能块清单、调用关系、报警清单和变量说明。这份文档稍微修改就能直接归档，比我以前整理得快太多。

4. 常见问题与排查技巧实录

4.1 AI写PLC代码的“通病”

用多了以后，会发现AI写PLC代码存在一些固定的毛病。提前知道了这些，可以少浪费很多时间。

第一个通病是指令库幻觉。AI会一本正经地编造一些看起来合法但实际不存在的指令，尤其在涉及特定品牌特定型号时。比如我让它用汇川AM600写一个运动控制程序，它编了一个看起来挺合理但实际上并不存在于汇川指令库里的轴控指令。解决办法很简单：提示词里明确要求它“仅使用我在手册中提供的指令集”，或者把指令手册作为附件喂给它。如果都没有，那就只能靠审查和仿真去兜底。

第二个通病是忽略PLC扫描机制。AI默认的编程思维是顺序执行的，而PLC是循环扫描的。它生成的代码里有时会出现同一个输出在不同网络里被多次赋值的情况，这在梯形图里是以最后一句赋值为准，极易埋雷。还有一个典型问题是在FOR循环里做通讯读写，这在PLC里是会阻塞扫描周期的，AI完全没这个概念。

第三个通病是变量类型过于理想化。AI写代码时倾向于用STRING、ARRAY这种高级数据结构，但在老旧PLC上，字符串处理是极其消耗资源和代码量的。如果平台是S7-200 SMART这种小型机，AI给的解决方案经常根本装不下。所以提示词里最好说清楚PLC的具体型号和内存水平。

第四个通病是过度工程化。AI为了展示能力，往往把一个简单任务写得很复杂。我让AI写一个电机启停块，它居然给我生成了带故障自诊断、累计运行时间统计、维护提醒的一整套功能，代码量翻了四倍。对这种过度设计，我的处理方式是在提示词里狠狠限制：“不要多余的功能，保持代码尽可能简洁”。

下面是几个我遇到过的典型问题和对应排查思路：

4.2 我现在的工作流

最后分享一下我目前稳定下来的工作流，给想尝试的朋友一个参考框架。

接到一个新项目后，我先是把甲方需求、IO表、设备清单全部整理成文字材料，这是整个流程的地基，材料越详细，后面AI发挥的空间越大。然后让AI根据材料生成IO变量表和初步程序框架，我审核并确定变量命名规范和程序结构。接着进入核心功能块的逐个开发，每个功能块按“需求描述、AI生成、人工审查、仿真验证”四步走。程序主体框架搭完以后，我再让AI做一遍整体审查，专门找变量冲突和逻辑矛盾，这个步骤输出质量一般，但聊胜于无，偶尔能抓住真人容易漏掉的角落。最后是人工编写安全相关回路和关键联锁，这些我坚决不交给AI。文档和注释这些收尾工作全部打包给AI处理。整套跑下来，我粗略估算过，纯编程时间大约可以减少三成到四成，把大量精力腾出来了，真正花在理解工艺和调试现场上的时间反而变多了。

4.3 关于AI替代PLC工程师的一些大实话

现在到处有人说AI要替代程序员，我看在PLC这个领域，这话短时间内就是个笑话。AI现在能替代的是那些重复性的、语言模型能理解的工作，但PLC工程师很大一部分价值在现场：你蹲在配电柜前面看指示灯的状态变化、拿万用表量信号线、根据设备异响判断哪个气缸密封圈不行了，这些AI做不了。

但我也要诚实地提醒还在靠纯手工堆代码的同仁：AI虽然替代不了你，但一位熟练掌握AI工具的PLC工程师，完全可能替代你。就像当年电脑辅助设计出现的时候，用手工绘图的老工程师照样能找到工作，但新项目的负责人一定优先分配给电脑用得溜的人。工具往前走了，你没有理由留在原地。我们这行讲究的是经验，但经验只有和效率结合起来，才会有真正的竞争力。

我现在感觉这个趋势特别明显，两年前认为AI距离工控还很远，但现在已经实打实地进入到了设备程序开发的日常流程里。今天我把这半年的经验全盘托出，一方面是记录一下自己的实践过程，另一方面也是真心建议同行们早点上手，别等到周围的年轻人都开始用AI写功能块了，你还在为IO点表熬夜加班。早点让AI替你扛掉那些重复劳动，把精力留下来干真正值钱的事——琢磨工艺、排查故障、优化节拍，这才是PLC工程师越来越值钱的方向。