干了十年PLC编程最近开始让AI替我写程序。最初只是抱着试一试的想法想看看大语言模型能不能读懂梯形图、能不能把一段需求描述转成结构化文本ST结果发现这条路远比我想象中走得更远——关键在于AI生成的代码能不能用、怎么改、怎么验证而不再是我自己一行一行去写。这篇文章我会从“为什么PLC工程师该尝试AI”讲起把我在西门子博途、三菱GX Works、Codesys这些平台里实际用AI写程序的流程、提示词写法、代码生成后如何处理、以及排查过程中的坑全部摊开来说。既讲我的个人经验也会加入一些通用可复用的步骤保证你读完能直接回到工位上试一把。先把结论放在前面AI编程不是让PLC工程师失业而是把我们从重复劳动里捞出来腾出时间去做更有价值的事情——比如方案设计、现场调试、异常处理。但AI写的代码确实不能拿来就用“让AI写程序”和“让AI写完就能跑”是两回事。1. 为什么干了十年PLC编程我突然转向让AI写代码1.1 梯形图背后的重复劳动PLC编程入门的时候梯形图是绕不开的。继电器电路那一套逻辑接触器、中间继电器、时间继电器、计数器画成梯形图之后直观得像看图说话。我刚入行的头三年就是靠手画梯形图一点一点磨出来的。但干满十年你就会发现梯形图虽然直观工程化的效率其实不高。设备控制逻辑越复杂梯形图就越臃肿。一台设备的自动流程、手动流程、报警联锁、多点位互锁、步进流程堆叠在一起一个程序块可能就有上千个网络。修改一个中间变量你得在几十个网络里找它在哪些地方被引用改完还要担心有没有破坏其它联锁。在这种情况下重复性的结构代码占了很大的比例。最常见的比如电机的启停控制启动按钮、停止按钮、热继电器、接触器线圈再加一个自锁触点阀门的开关控制开到位、关到位、开按钮、关按钮、报警输出常规报警处理超时报警、偏差报警、模拟量超限报警每个参数都是一套相似的程序段。这类代码本质上结构非常固定只要你描述清楚IO点表、控制要求和联锁关系一个有经验的工程师闭着眼都能写。而AI做这种重复度极高的活恰恰是强项。程序员圈子把这种用法叫“用AI替代样板代码”放到PLC领域其实一样成立——它能快速根据你的描述生成结构完整、注释清晰的基础逻辑块比手写快得多。1.2 AI并不是抢饭碗而是把时间还给你很多PLC工程师听到“让AI写程序”的第一反应是我十年的经验就这么不值钱了我觉得刚好相反。十年经验值钱的不是你画梯形图的手速而是你对整个系统的理解。AI能帮你把“写代码”这一步缩短但它不理解管线里哪段有物料干涉、不理解负载起动时电网压降、不理解变频器急停时会不会触发过流报警。这些必须由人来判断。我个人的体会是AI更像一个随时在线的、知识面超广的初级工程师。你给它清晰的需求它给你一版基础代码你需要做的是像一个带过十年徒弟的老师傅一样去审它的代码、挑它的毛病、告诉它哪里有问题让它改。这比全部自己写要快也比全部丢给AI直接跑要稳。换句话说AI编程把工作重心从“写代码”转移到了“提需求和审代码”而这两件事恰好是经验越丰富越占优势的事。这才是十年经验真正的增值点。2. AI写PLC程序的工具选择与提示词设计2.1 工具选型哪些模型更适合PLC编程现在市面上主流的AI大模型我基本都试过。国内外的通用大模型包括GPT系、Claude系、国内主流大模型如通义千问、文心一言、豆包、Kimi等对代码生成都有不错的能力。综合下来我目前在用的主力是通用大模型加上一个本地化的代码提示词模板——原因后面会说。至于具体型号变化太快我只能说能支持长上下文、能输出代码块的模型都可以尝试。我当时对比了几个模型针对同一个PLC需求分别要求生成ST代码看它的注释习惯、变量命名规范性、以及对“保持线圈不自锁”这类基本逻辑约束的理解能力逐步筛选出了自己用着顺手的。这里有一个小建议PLC行业的知识在公开语料里占比不高所以通用模型对梯形图和ST语言的理解深度参差不齐。上手前先拿一段自己写的代码问它“解释一下这段逻辑的作用”如果它能把互相锁、互锁条件、顺序启动条件讲清楚那它写出来的代码大概率可用如果它把线圈和触点都理解反了就别浪费时间去调教了。2.2 写提示词的经验把你的需求当作业布置AI写代码的质量很大程度上取决于提示词写得好不好。就像你给一个新来的工程师布置任务你说“把电机控制程序写一下”他能给你写出一百种不同风格的程序但你如果给他IO表、控制逻辑、安全要求、品牌型号和通讯地址他写出来的东西就可能跟你想要的八九不离十。我每次让AI生成PLC代码提示词里必须包含这么几项PLC品牌与编程语言——比如“西门子S7-1200博途平台使用结构化文本ST”IO点表——每个输入输出点的名称、地址、作用尽量写清是高电平有效还是低电平有效控制逻辑描述——比如“按启动按钮后电机启动停止按钮或热继电器动作时电机停止同时输出故障报警”额外要求——比如“电机启动前必须满足门关闭信号”“故障复位按钮才能复位报警”“程序采用逐行注释”。我试过一个比较典型的案例让AI生成一段三台电机的顺序启动和逆序停止逻辑要求是每台电机间隔五秒启动停止时先停第三台再停第一台任何一台故障时后续电机不得启动。AI生成的ST代码结构非常清晰用CASE语句分步执行变量命名也规范我只改了注释和两个中间变量的命名方式就能放进仿真里跑。那种感觉确实有点像多了个得力助手。2.3 结构化文本ST比梯形图更适合AI生成既然提到ST语言我多说几句。AI生成的代码无论是Python、C还是ST本质上都是文本。梯形图对AI来说反而是劣势——因为梯形图是图形化语言AI无法直接输出图形格式除非你让它生成某种中间文本再转换。目前主流的做法是让AI直接生成 ST结构化文本 或者 SCL西门子环境的类Pascal语言然后再在博途或Codesys里导入。ST语言本来就是IEC 61131-3标准的一部分它的代码结构和常见的通用编程语言接近AI在这个语料上的理解要远比梯形图好得多。当然也有例外。如果你必须交梯形图有些项目甲方就指定用梯形图可以走两条路一是让AI生成ST代码你用软件的“转换”功能转出梯形图二是让AI生成变量网络结构的描述比如“在Network 5中常开触点I0.0串联常闭触点I0.1后输出Q0.0并联自锁触点Q0.0”然后人工在博途里画。实测下来第二条路只适合简单逻辑复杂逻辑还是ST更利落。所以我的建议是如果你还没掌握ST语言值得花时间学一下。它不会取代梯形图但它是让AI编程真正落地的钥匙。3. 实操过程从博途报警处理到Codesys通信调试3.1 案例一用AI生成一段可复用的报警处理逻辑我在实际项目里最喜欢让AI干的活就是生成成套的报警处理逻辑。这类逻辑换一个设备就要写一遍以前靠复制粘贴再改地址现在靠AI直接生成。有一次项目用的西门子S7-1500带大概二十个模拟量输入每个模拟量都有高报警、高高报警、低报警、低低报警四种限值还要做报警死区处理。我概括了一下提示词西门子S7-1500博途TIA PortalSCL语言。 20路模拟量报警处理输入为数组变量AI_Value[1..20]报警限值数组 AI_H_ALM[1..20]AI_HH_ALM[1..20]AI_L_ALM[1..20]AI_LL_ALM[1..20]。 死区数组Alm_DeadBand[1..20]。 每路输出AI_HH[1..20]高高报警、AI_H[1..20]高报警、 AI_L[1..20]低报警、AI_LL[1..20]低低报警。 要求所有报警均为BOOL量高报和高高报同时满足时只输出高高报警 带死区报警输出有0.5秒延时确认使用FC块实现。AI生成的SCL代码非常规整用FOR循环遍历数组内部先用死区回滞消除临界抖动再用TON延时确认消除瞬时抖动还加了限值的合理性判断——如果某个限值设置不对输出错误标志。这段逻辑原本我手写大概要一小时AI生成加我修改不到一刻钟。但实际上我并没有直接拿它就用。第一件事是查死区处理方向对不对——不同的仪表工艺死区是加在上限还是下限必须确认模拟量信号在报警边界震荡时不会反复跳。我改了两行逻辑把方向调整正确又在TON后面加了输出互锁确保报警只能在实际数值越限后出现。这里有个重要的点AI生成代码只能给你一个“逻辑骨架”工艺方向、现场安全这些你必须自己把关。3.2 案例二Codesys里用AI排查通信问题说到Codesys我近期接连遇到两个问题都和通信有关。一个是Codesys读取PLC网口MAC地址另一个是建立连接时需要目标PLC的AMSNetID六字节网络标识符和端口号。以前遇到这类问题我都是翻手册、翻论坛一圈下来半小时起步。这次我直接把报错信息贴给了AICodesys运行时建立连接需要目标PLC的AMS NetId6字节网络标识符和端口号 我该在哪里找它直接告诉我在Codesys的Device窗口里选中目标设备打开“以太网”接口属性就能看到NetId端口号默认一般是11740STO。然后我追问了一句“NetId改了之后连不上怎么办”AI又给出了排查顺序先Ping网络通不通然后看NetId是不是被改掉了再看网关设定。顺着这个思路我在现场五分钟左右就把问题定位了——不是NetId是网关列表里少填了一项。这个案例让我意识到AI不光是写代码的更是排查问题的好搭档。尤其对那类“你知道答案在手册里但就是找不到在哪页”的问题AI可以像一个有经验的同事一样告诉你“去哪儿查、查什么、怎么排查”而这恰恰是乙方工程师在现场最需要的。3.3 参数计算与选择过程AI算出来的参数也得复核AI写程序的时候经常会涉及参数计算。比如电机启动的软启动时间、变频器的加减速时间、模拟量的工程量转换系数等等。AI它能够根据你给的数据直接帮你算出来但你一定得复核。我有一次让AI帮忙计算一个模拟量4-20mA信号对应的工程量范围。现场的变送器量程是0到1000AI直接把公式列了出来[ 工程量 电流值-4 \times 1000-0 / 20-4 0 ]并且在代码里生成了一行STProcessValue : (Current_mA - 4.0) * 1000.0 / 16.0;逻辑是对的。但它不知道现场用一个隔离栅把信号在4-20mA基础上整体抬高了0.5mA这个消息它不知道也不会主动问。结果我在仿真里一看数值偏了才想起来现场这个细节。所以AI能算参数但算完你得确认前提和数据来源。参数安全永远是你自己的责任AI只是提供了一个算法参考。4. 常见问题与排查技巧实录4.1 隐患一AI生成的代码不能直接下载到PLC这是新手最容易踩的坑。AI生成的代码不管它看起来多完整都只是文本。你没法直接把这段文本烧录进PLC里。以博途为例AI生成的是SCL文本你要在博途里新建一个FC或者FB把SCL代码粘进去编译通过后才生成块如果要导入到已有的DB还要检查变量名称和地址是否与AI生成的一致。这就带来一个常见问题AI生成的变量名如果和你在DB里定义的变量名不一致导入编译时会报错。我的经验是在提示词里直接要求AI“变量名使用与我提供的DB一致的命名方式”并且在输入前把自己DB块的变量清单一并贴给AI。这样生成出来的代码几乎能无脑导入。4.2 隐患二安全回路的处理绝不能交给AIPLC控制的核心是安全。急停回路、安全门联锁、光栅保护、双手启动这些触及人身安全的回路我个人的建议是——永远不要靠AI生成也不要在AI生成代码上直接改着用。这不是说AI写不好恰恰是因为它“太擅长”按照通用模板来写了而没有意识到现场安全等级要求有多高。安全回路设计有一套完整规范涉及安全继电器、冗余回路、安全PLC、相关标准和风险评估这些不是一段程序能搞定的。哪怕在AI生成的普通功能代码里我也一定会单独把安全相关的互锁逻辑拿出来人工审一遍并经过仿真验证才敢考进去。我吃过一次亏。AI生成的电机控制逻辑里所有联锁条件都写在输出前面外部急停信号通过一个中间变量接入。在我给的IO表里急停是常闭接点但AI生成时默认理解成了常开逻辑导致急停回路逻辑反了。仿真时测出来了但现场如果没测出来后果不堪设想。所以我的铁律就是AI生成的控制程序唯一允许直接跑的场景就是纯演示和仿真验证绝不直接进产线。4.3 隐患三AI理解错“保持优先”和“置位优先”PLC编程里有一个细节AI很容易搞混就是电机启停逻辑中的“置位优先”和“复位优先”。简单说如果同时有启动信号和停止信号置位优先会让电机保持启动状态复位优先会让电机停止。这个在梯形图里很常见但在ST代码里如果写成了两条独立的IF语句顺序不同结果就完全不同。AI生成的ST代码里经常出现这类顺序问题。比如IF Stop THEN Motor : FALSE; END_IF; IF Start THEN Motor : TRUE; END_IF;这种情况下Start信号即使和Stop同时为真电机也会被启动。如果写成倒过来结果是先复位后置位逻辑完全变了。这不是语法错误是逻辑时序问题。我每次审AI代码都会特别留意这种控制顺序。我在提示词里会加一句话“所有互锁条件必须在任何输出指令之前优先判断输出置位和复位按安全优先原则。”虽然不能保证AI每次都完全理解但至少把要求提在前面会好很多。4.4 常见问题速查表问题原因排查方法导入AI生成的SCL代码编译报错变量名与DB块不一致先在DB块中手动建立变量再让AI按你的变量名生成或导入后逐行改代码逻辑是通了但仿真结果不对地址映射错位对照IO点表逐点核对AI生成的地址和实际PLC映象区地址提示词很详细但生成结果很乱模型对PLC术语不熟悉换用更大的模型或在提示词里自带示例代码给它“现学”ALM延时确认代码太长不够简洁数据块结构设计不合理让AI把报警限值、延时值集中到UDT结构里简化代码AI生成的通信配置少了网关参数通用网络上AI缺少现场拓扑信息不要只问“怎么设置”要把你的网络拓扑、PC IP传给它5. 排查思路与调试技巧分享5.1 先让AI复述再让它动手我个人的一个习惯拿到一个复杂逻辑需求不是直接甩给AI写代码而是先问它“请先用文字描述一下你计划实现这段逻辑的思路”。比如让它写顺序启停之前先让它输出每台电机的启动条件、停止条件、联锁条件、异常处理顺序。如果它的思路描述有问题我直接在这里纠正比生成完一大段代码再改高效太多。这也是我踩了多次“提示词理解偏差”的坑之后总结出来的经验。5.2 仿真环境测不出所有问题AI写出的代码即使仿真全通过也不代表现场没问题。仿真器无法模拟真实的信号抖动、通信延迟、模拟量噪声更没法模拟控制柜里接线松动的情况。我在调试现场的习惯是AI生成的程序仿真通过后还要手动强制几个关键输入点比如信号在0和1之间快速切换看程序是否有异常输出。这部分是纯靠经验积累的测试思路AI帮不了你但你一定要做。5.3 让AI帮你生成测试用例有一个AI比我想象中强的地方它能帮你生成测试用例。你把自己写的程序描述发给AI让它列出一个测试用例清单包括正常流程、异常流程、边界条件。它会扬出不少你想不到的边界场景。比如有一段控制三个气缸顺序动作的逻辑AI给出的测试用例里有一条在第二个气缸动作期间第三个气缸的启动信号意外触发程序应当忽略还是排队等待这个问题我平时可能不会主动去测但对设备实际运行来说却很重要。从这个角度来说AI编程多了个好处——它逼你更系统地思考边界条件而不是按照经验路径一路走到底。6. 目前工具链的局限与未来的可能性AI编程在PLC领域的现阶段局限还挺明显的。最大的问题是缺乏与工程平台的深度集成——你没法让AI直接操作博途的界面去改DB块也没法让它直接连到Codesys运行时去监视变量。目前的流程是AI生成文本人贴进工程编译验证。这个“人肉粘贴”环节占了时间但已经比从零手写要省力太多。往远处想随着AI Agent的发展未来完全可以做到AI读项目说明书自动生成PO点表、变量表、功能块的框架再自动生成各个FB的代码最后由工程师审核后一键导入。这种模式离我们并不遥远我甚至在现在的工具组合下已经能实现其中七八成了。另外现在也有人在做专用PLC大模型专注收录各品牌PLC的指令手册、系统手册、样例程序。这些专用模型上手速度会比通用模型更快。但短期内我认为通用模型加自建提示词模板依然是性价比最高的路线——因为PLC知识更新慢、结构稳定一个写好的提示词模板可以反复用很久。我个人在这方面的经验是把你自己常用设备的型号参数、IO分配规则、注释规范整理成一个“项目背景文档”每次让AI写代码前直接贴给它效果比临时描述要好得多。这份文档就是你个人的知识资产越沉淀越值钱。最后再分享一个小技巧千万别小看让AI“翻译”代码的能力。我在现场经常遇到甲方提供的程序是用老式三菱FX写的要移植到西门子平台。以前只能人工逐行对照翻译现在我会先让AI把三菱的梯形逻辑转换成白话文描述再让它按西门子SCL生成。两次转换下来虽然不一定完全准确但极大减少了人工比对的工作量。干到第十年的时候我一度觉得PLC编程这行已经没有新东西了。倒是AI带来的一点变量让我重新摸到了那种“刚入行时琢磨新指令”的感觉。如果你也处在一个写重复代码写到麻木的阶段不妨试试这个思路也许会有惊喜。
