十年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 V17PLC型号S7-1214C DC/DC/DC。请帮我写一个FB功能块实现以下功能 输入信号启动按钮I0.0停止按钮I0.1传感器AI0.2传感器BI0.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写一个电机启停块它居然给我生成了带故障自诊断、累计运行时间统计、维护提醒的一整套功能代码量翻了四倍。对这种过度设计我的处理方式是在提示词里狠狠限制“不要多余的功能保持代码尽可能简洁”。下面是几个我遇到过的典型问题和对应排查思路问题现象可能原因排查方法生成的代码编译报错指令不存在AI记错了该平台的指令集上传手册或指定指令版本用仿真器编译验证程序逻辑在仿真时与需求不符AI没有正确理解时序需求重新整理需求描述把时序要求拆分写成条件表数据块地址重叠AI不了解PLC存储区划分人工检查地址分配限制AI使用绝对地址强制用符号变量通讯功能块不工作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工程师越来越值钱的方向。