1. 十年PLC老手为什么突然让AI替我写程序干PLC编程干了十年说实话以前我挺排斥AI写程序的。一觉得PLC是现场设备代码和气缸、电机、安全回路直接连着AI哪懂这些二来这么多年梯形图都成肌肉记忆了遇到问题第一反应是自己上手。但最近半年我改主意了让AI替我写程序不是偷懒而是把时间从重复劳动里抠出来留给真正需要工程师判断的东西。我在三菱、西门子、汇川、信捷这些平台上都试过现在主要用AI生成结构化文本ST/SCL再花时间做仿真测试和现场调试。这篇文章就把这些经验整理出来给还在观望的PLC工程师做个参考。1.1 先承认一个事实大部分PLC程序是“重复劳动少量算法”做了十年项目接触的设备类型也算不少包装线、机床上下料、水泵房、恒压供水、小型生产线、非标设备改造。拆开来看真正的程序逻辑无非几种电机启停、阀门开关、气缸动作、报警汇总、复位流程、手自动切换、配方读取、数据转换。这些逻辑写一次不难难的是每个项目都要重复写一遍而且写完之后还要反复核对IO点表、查接线图、调动作时序。我自己统计过一个中等规模的设备程序真正需要动脑子的算法部分可能只占两三成剩下七八成都是“按部就班”的框架代码和IO映射。以前这些活都是老老实实手动敲费时间不说改一个点还要牵连着检查好几段逻辑。后来我开始试着让AI生成这些东西才意识到以前很多时间都花在了可以自动化的事情上。AI不是把编程这件事变魔法而是把我的双手从键盘上解放出来让我把精力放在审代码、测动作、调现场这些更值钱的事情上。1.2 AI写PLC程序到底能写到什么程度我前后在三菱GX Works3、西门子博途TIA、CODESYS这几个环境里都试过AI编程。坦率地讲AI生成的ST语言和SCL语言在“能编译、能运行、逻辑结构清晰”这个层面已经超出了我的预期。比如让它写一个带定时器的电机启动控制块它能把输入输出、TON实例、启动保持、停止复位都写得像模像样。让它写一个简单的排队抢答逻辑它能给出完整的锁存和复位方案比很多新人在车间里蹲一天写出来的还规矩。但要说完全放心那也是假的。AI对现场的理解始终隔着一层它不知道你的急停按钮接的是常闭还是常开不知道你的输出模块是不是带继电器保护也不知道老设备改造时哪些线已经拆掉重接了。所以我自己定了一条规矩AI生成的代码只能当“初稿”必须经过人工检查、仿真验证、空载试机三道关才允许进PLC。这个心态摆正之后AI就成了一个特别好用的工具而不是一个让人提心吊胆的“黑箱写手”。2. AI写PLC程序前我先做的一套标准动作2.1 把设备动作翻译成“程序需求说明书”很多人用AI写程序上来就是一句“帮我写一个电机启停程序”然后拿结果去用发现根本不是自己想要的。问题出在需求没讲清楚。PLC程序和普通软件不一样它必须和硬件地址绑定必须知道输入点在哪、输出点在哪、中间继电器怎么定义。AI不知道你的IO表只能凭空给你一套变量名这当然没法直接用。我现在会先花二十分钟把控制需求整理成一套“AI看得懂”的需求说明书里面就三块内容。第一块是输入输出表把按钮、感应开关、限位、急停、接触器反馈等信号列清楚给出变量名和数据类型。第二块是动作时序把设备从启动到停止的每一步描述出来按顺序写清楚。第三块是异常处理把超时、故障、急停恢复这些特殊工况写明白。这三块信息给足之后AI生成的代码命中率会大幅提升基本一次生成的代码就能对上七八成。举个例子一个最简单的电机正反转需求如果你只写“正反转控制”AI可能只给你两路接触器输出完全没有互锁。但如果你写清楚按启动正转按钮后正转接触器吸合按反转按钮时先断开正转延时1秒后反转接触器吸合正转和反转输出绝对不能同时为真任何时刻只要急停被按下所有输出立即断开。这四句话一给AI生成的代码就靠谱多了。写需求说明书这件事永远不能省。2.2 给AI的提示词模板可以直接抄在大量试错之后我总结出一套适合PLC编程的提示词模板现在基本固定下来。第一句话说明平台和语言比如“请用三菱GX Works3的ST语言”或者“请用CODESYS风格的IEC 61131-3结构化文本”。第二句话给出程序名称和功能比如“创建一个电机正反转星三角启动控制功能块”。第三句话列出输入输出变量包括变量名、数据类型、注释。第四句话描述动作流程按时间顺序写。第五句话强调约束条件比如“输出必须互锁”“所有定时器使用TON”“变量命名必须符合我给出的命名规则”。最后还要加一句“不要生成梯形图只用结构化文本”因为AI生成梯形图没法直接导入纯文本代码我可以自己复制粘贴自己建功能块。使用这套模板之后我明显感觉到AI的生成质量稳定了一个档次。它不再天马行空乱编地址而是老老实实按照我给的变量表写代码这比让它自由发挥要重要得多。2.3 生成代码后第一道工序人肉静态审查哪怕AI的代码再规范我也从来不会直接复制到PLC程序里。第一道工序永远是人工静态审查开着代码一行一行看。看什么呢一是看变量名是不是全部来自我给的变量表有没有出现AI自己编的地址比如三菱程序里冒出“D9999”这种没有定义的数据寄存器。二是看输出点有没有被重复赋值同一个输出在一段程序里被赋值多次这在PLC扫描机制下会造成非常隐蔽的故障。三是看有没有把BOOL当INT用或者把INT直接赋给WORD这类类型错乱。静态审查看起来土但这是效率最高的环节。很多AI生成的小毛病比如TON的实例没有声明或者定时器变量在多个地方共用都会在这一步被拦下来。我见过一些同事拿着AI代码直接往博途里灌结果编译报错或者运行后输出不动作回头查半天其实都是这种小问题。AI可以帮你从无到有写出一份代码但它不会替你做工程判断这个判断只能靠自己。3. 三个我用AI写的PLC程序实战拆解3.1 抢答器控制系统AI写布尔逻辑比想象中靠谱先拿一个常见的小程序练手四人抢答器控制系统。需求很简单四路按钮谁先按下对应输出灯亮并且锁存主持人按下复位按钮后系统恢复继续下一轮。这种程序以前在学校课程设计里很常见现实中也会用在一些娱乐设备、教学演示设备上。我让AI生成对应的ST代码它给出的逻辑结构居然相当完整。核心代码如下VAR bBtn1 : BOOL; bBtn2 : BOOL; bBtn3 : BOOL; bBtn4 : BOOL; bReset : BOOL; bLamp1 : BOOL : FALSE; bLamp2 : BOOL : FALSE; bLamp3 : BOOL : FALSE; bLamp4 : BOOL : FALSE; bLock : BOOL : FALSE; nWinner : INT : 0; END_VAR IF bReset THEN bLamp1 : FALSE; bLamp2 : FALSE; bLamp3 : FALSE; bLamp4 : FALSE; bLock : FALSE; nWinner : 0; ELSIF NOT bLock THEN IF bBtn1 THEN bLamp1 : TRUE; bLock : TRUE; nWinner : 1; ELSIF bBtn2 THEN bLamp2 : TRUE; bLock : TRUE; nWinner : 2; ELSIF bBtn3 THEN bLamp3 : TRUE; bLock : TRUE; nWinner : 3; ELSIF bBtn4 THEN bLamp4 : TRUE; bLock : TRUE; nWinner : 4; END_IF; END_IF;这段代码基本逻辑是对的。但我审查之后还是发现了一个关键问题它没有做按钮的边沿检测。如果某一轮抢答结束后主持人按复位键复位而选手按钮还没松开那么下一轮一开始该路会被立即锁存造成误判。真实场景里必须给按钮输入加一个上升沿检测或者通过PLC输入端的硬件滤波配合确保只有“按下瞬间”才算有效。所以我的处理方式是给每个按钮单独加一个R_trig上升沿变量用触发器输出替代原始按钮信号。AI写框架我补细节配合起来效率很高。3.2 正反转星三角降压启动安全互锁必须自己把关这个案例是典型的电机控制现场场景也是我认为AI最需要人工把关的一类程序。需求是电机启动时先星形接法降压启动延时一段时间后切换为三角形接法同时支持正反转控制。这个程序如果只写主逻辑AI完全能写出来但安全细节很容易出错。AI的第一版代码大致长这样IF bStart THEN bKM1 : TRUE; bKM3 : TRUE; IF tonTimer.Q THEN bKM3 : FALSE; bKM4 : TRUE; END_IF; END_IF;从算法角度这没错但拿到现场就出问题了。第一缺少正反转互锁如果正转接触器和反转接触器同时吸合会造成相间短路。第二星形转三角形切换时没有所谓的“转换等待时间”直接断开星形同时吸合三角形接触器分断电弧还没灭另一个就吸上去了。第三急停信号没有接入急停一停控制电源PLC输出可能还在ON虽然接触器会失电但程序里最好也要把急停状态纳入逻辑。我让AI生成“改进版”之后自己又重新改了一遍最终的核心控制逻辑大概是IF bStop OR bEmergency THEN bKM1 : FALSE; bKM2 : FALSE; bKM3 : FALSE; bKM4 : FALSE; nState : 0; ELSIF bStartForward AND NOT bKM2 AND NOT bKM3 THEN bKM1 : TRUE; nState : 10; ELSIF nState 10 THEN IF tonStar.Q THEN bKM3 : FALSE; bKM4 : TRUE; nState : 20; END_IF; ELSE bKM1 : FALSE; bKM2 : FALSE; bKM3 : FALSE; bKM4 : FALSE; END_IF;注意这里我仍然保留了接触器之间的电气互锁也就是外部接线中KM1和KM2必须串接对方的常闭触点这比软件互锁更可靠。AI写的程序只有在外部硬件互锁都到位的前提下才有意义。程序里的延时、状态切换、急停复位都是我根据现场情况补进去的。这个案例充分说明AI可以帮你搭好一个控制逻辑的骨架但和安全相关的血肉必须由有现场经验的工程师自己填。3.3 包装设备的自动运行状态机AI负责框架我负责IO映射很多PLC项目最耗时的不是单独一个电机的启停而是整机自动运行流程。比如一台包装设备要经历待机、启动、运行、暂停、清理、故障处理等状态状态之间的切换条件非常多。这些程序在ST语言里最适合用CASE状态机来实现而AI生成CASE框架恰好是它的强项。我让AI生成一个五状态的设备主流程它给出的结构是CASE nState OF 0: (* 待机 *) bReady : TRUE; IF bStart THEN nState : 10; END_IF; 10: (* 启动 *) bConveyor : TRUE; IF bInPosition THEN nState : 20; END_IF; 20: (* 运行 *) bRun : TRUE; IF bStop THEN nState : 30; END_IF; 30: (* 暂停 *) bConveyor : FALSE; bRun : FALSE; IF bReset THEN nState : 0; END_IF; ELSE nState : 0; END_CASE;这个框架可以用但我后来加了两样东西。第一是“上电初始化”PLC刚上电时nState可能是一个随机值必须用一个初始化程序段把状态变量强制复位到0。第二是“报警优先级”故障发生时要记住当前状态故障排除后能回到之前的位置不能一报警就把所有输出全断了尤其对于带有气缸、夹具的设备直接断输出可能会让工件掉落甚至伤到人。AI最擅长的是把状态之间的跳转关系梳理清楚这是我写程序时最耗时间的一部分。剩下那些输出映射、报警记忆、手自动切换、单步调试功能都是我自己手动补的。两者结合起来一个中型设备的程序编写时间缩短了大概三分之一。4. 让AI写完代码后我是怎么“挑毛病”的4.1 最常见的四类AI代码坑用AI写了半年程序之后我总结出它最容易出的四类问题几乎每次都要检查一遍。第一类是编造标签和地址。AI在找不到你给的具体地址时会非常自然地编一个假地址出来在CODESYS里编一个“%MW888”在三菱里编一个“D8888”这些地址有时并不存在有时会被系统变量占用编译能过运行却可能把数据写到莫名奇妙的地方。第二类是数据类型错乱最常见的就是把BOOL当INT进行数值比较或者把WORD和INT混着用导致运算结果完全不对。第三类是时序错觉AI经常忽略PLC扫描周期的概念把两个本来应该在不同扫描周期完成的动作写在一个周期里导致输出打架。第四类是注释写得特别自信但代码不严谨它注释里写着“急停时立即断开所有输出”实际代码里却只有简单的一个IF完全没考虑输出模块的复位方式。这些坑看着小但每一个都有可能导致设备出问题。所以我在审查AI代码时不怎么信它的注释只看变量声明、输出赋值和定时器调用这三块。4.2 下载到PLC前的四步检查我给自己定了一套固定的检查流程每一步都不能跳。第一步是编译前的静态检查把所有变量列表导出来逐个对着IO表核对看地址范围对不对。第二步是仿真验证博途里用PLCSIMCODESYS里用内置仿真器三菱GX Works3可以开模拟模式先把AI代码放到虚拟环境里跑一遍用强制输入的方式模拟现场信号观察输出状态是否符合预期。第三步是强制测试在仿真器里把按钮、限位开关全部强制为OFF和ON反复切换确认程序不会出现输出乱抖、状态卡死的现象。第四步是现场空载实验这一步一定不能省而且必须断开动力电源只接控制回路让PLC带着接触器、继电器空跑连续跑够几十次确认所有切换时序都正常后再接电机负载测试。每一步我都在踩过坑之后才明白它有多重要。有一次AI生成的程序在仿真里一切正常结果到了现场发现接触器切换时火花太大原因是程序里星三角转换时间算得太极限实际接触器机械释放时间不够最后把延时从60毫秒调成150毫秒才稳定。仿真器不会告诉你接触器的机械特性这就是人工测试存在的意义。4.3 给AI代码“挑毛病”的速查表经常有朋友问我AI生成的PLC程序到底怎么快速排查问题。我把最常见的现象和对应处理办法整理成了一张表。现象可能原因排查位置处理办法编译报错变量未定义AI编造了变量名变量声明区对照IO表统一替换输出不动作逻辑块顺序不对程序段执行顺序把主逻辑放在最后执行输出抖动缺少互锁或扫描周期竞争同一输出被多段赋值全局搜索该输出变量定时不准TON实例被多个地方共用定时器实例声明每个定时器单独建实例急停后输出不复位急停信号未纳入程序主控逻辑最前面加急停总复位段状态卡死CASE缺少默认分支状态机ELSE分支重置到安全状态这张表是我自己排查AI代码时最常用的工具。现在每次生成完代码我就拿这张表逐项过一遍能拦下八成以上的低级问题。5. 我现在用AI写PLC程序的工作流和边界5.1 一条完整的AI辅助开发流程现在我做PLC编程已经形成一套稳定的工作流。第一步根据电气图纸和设备动作要求整理IO变量表和动作时序清单。第二步在AI工具里写下平台信息、变量表、动作流程、约束条件生成初始代码。第三步人工静态审查把AI编造的标签、类型错误、输出重复赋值都改掉再放进PLC编程软件里编译。第四步用仿真器做功能验证强制输入信号逐个测试状态切换。第五步现场空载调试确认接触器动作次序和电气互锁都符合要求再带载试运行。这套流程看着传统但实际效率提升非常明显。以前从零写一个几百行ST程序可能要花一整天现在AI生成初稿、我修改定稿加仿真测试半天就够了。省下来的时间都用在真正需要经验的环节看设备动作是否合理和安全相关的逻辑是否正确现场调试时有没有异常发热、异响、报警。5.2 什么类型的程序适合交给AI写什么不适合用了一段时间之后我心里其实已经有一条很清晰的分界线。适合交给AI写的程序包括状态机框架、数据处理和转换、报警分组和处理逻辑、定时控制、数据统计、通信报文的解析拼接、还有一类是把成熟的程序A移植到IO点基本不同的程序B。这些程序逻辑相对独立不涉及复杂安全联锁AI生成的初稿质量很高人工稍微调整就能用。不适合交给AI写的程序首先是安全控制相关的逻辑比如急停回路、光栅联锁、安全PLC程序这些一旦出问题就是设备损坏甚至人身伤害AI没有现场经验也没有办法判断你外部的安全回路是否可靠。其次是强电联调逻辑像变频器、软启动器、伺服驱动器的整体调试流程很多参数必须在现场根据实际情况调整AI根本不知道你的电机功率、负载惯量、启动电流。最后是老设备改造项目特别是那种图纸不全、现场线号乱掉的设备AI生成再漂亮的代码也没用因为前提条件本身就不可靠。5.3 给刚想用AI的PLC工程师几句实在话如果你也是一个PLC工程师最近想试试让AI写程序我劝你先别急着把AI生成的代码往PLC里灌。选一个小项目最好是那种不影响生产、逻辑也不复杂的设备从头到尾走一遍我刚才说的流程感受一下AI的生成习惯也体会一下“人工审查”这个环节到底有多重要。第一课不是教你怎么让AI干活而是教你怎么发现AI的错误。我自己踩过几次坑之后的体会是AI写PLC程序真正帮到我的地方不是“自动生成”而是“快速生成初稿”和“帮我把脑子里的逻辑理成文字”。很多想法在脑子里是一团浆糊写提示词的时候反而逼我把需求一条条说清楚这个过程本身就很值钱。最后再提一个建议AI生成的代码不管看起来多完美都留好原始文档、注释和修改记录因为你三个月后回头改程序时真正能救你的不是AI而是你自己当时留下的痕迹。
