最近工业自动化圈子里聊得最热闹的话题不是哪家新出了旗舰PLC也不是谁的伺服又把响应带宽拉高了几毫秒而是AI到底能不能进车间、能不能写PLC程序。我自己也拿市面上的几款AI工具试过让它写个电机正反转、写个星三角启动看起来确实有模有样注释齐全格式规范甚至比不少入门工程师写得还整洁。但如果真让我拿它生成的程序去带一套产线我肯定不敢原因后面详细说。正好RealPLC那边提了个说法AI写PLC程序目前只能算L1配套还有一个PLC Coding五级能力模型。这套模型一出来我觉得终于有人把“AI写PLC到底行不行”这个模糊问题给结构化了。下面我就拿这套模型当尺子把AI在PLC领域的现状、以及一线工程师该怎么用它一次说清楚。这个内容适合三类人看一是正在纠结要不要用AI提效的PLC工程师二是带团队做项目、想给新人定标准的技术负责人三是对工业自动化和AI结合感兴趣但还没摸到门路的人。放心我不会只念概念我会把五级模型拆开每一级对应什么场景、现在的AI能做到什么程度、我们在现场踩过哪些坑都拿出来讲透。1. 先把这事放回一线现场AI写PLC到底意味着什么1.1 “能写代码”和“能交付程序”之间的差距我去年带过一个项目客户要求把一台老设备的继电器逻辑改成PLC控制。团队里有个年轻同事觉得这活儿太简单了直接把控制要求丢给AI几分钟就生成了一段ST程序逻辑上看着完全对。但真到现场调试的时候问题全冒出来了输入信号抖动没做滤波急停回路没有按常闭点来设计气缸到位信号比预设时间早退出了报警记录也没有。从“代码正确”到“现场能跑”中间隔着的不是几行逻辑而是十几年才能攒下来的现场经验。这就是为什么L1这个词一出来很多老工程师直点头。AI写出来的程序可能语法没有错误指令也都合法但它更像一个“答案正确但没有过程分”的作业。PLC程序的本质是“事件的时序控制”它要考虑扫描周期、信号的上升沿下降沿、通讯超时、故障停车顺序、手自动切换状态——这些知识在现场老师傅脑子里根本不出现在任何一本编程手册里。AI靠大模型能学到手册和代码仓库里的“标准答案”却学不到设备交付后第127天才出现的偶发报警也学不到某个传感器老化后信号变慢的微妙手感。所以别一看到AI能生成梯形图就觉得天塌了也别觉得它就是个玩具。正确的态度是把它当成一个“能力很强但缺乏现场常识的实习生”它写的代码看着合理但你必须校核、必须试、必须替它兜底。1.2 为什么说到“只能算L1”时大家反而觉得客观我这个圈子里的朋友对AI写PLC的看法一直两极分化。一方觉得AI早晚要取代一部分编程岗另一方觉得AI生成的程序就是垃圾完全不能用。但RealPLC这个五级模型一出来我发现两边居然都能接受“L1”这个定位。认为AI行的那拨人点头是因为L1确实承认AI能生成代码了而且生成质量在提升觉得AI不行的那拨人也点头是因为模型明确告诉你能写代码只是最底层的能力距离交付一个可靠的控制系统还差得远。这种“分级”的处理方式把讨论从“AI行不行”拉到了“AI到底行在哪一层、不行在哪一层”从情绪变成了标准。我做项目这些年最怕的不是技术问题是预期管理问题。老板以为AI能做到的事和AI实际能做到的事中间落差一大项目就难推进了。有个老板拿着AI生成的程序去投标他以为那就是完整方案我一看缺了十几处联锁差点出事。所以一个清晰的能力分级对非技术出身的决策者同样重要它能把“AI很厉害”这种空泛概念转化为“它现在只能承担这部分工作而且产出必须人工审核”的明确边界。1.3 这套模型解决了我最头疼的一个问题该怎么评价AI以前有人问我“AI写PLC到底行不行”我真的很难回答因为“行不行”这个概念太宽了。你是问它能不能写出一段语法正确的代码还是问它能不能完成一套设备从设计到交付还是问它能不能在设备运行三个月后根据数据优化节拍这些问题的答案完全不同。五级模型的价值就在于它给了我们一个坐标轴L1代码生成、L2代码理解与维护、L3工艺方案设计、L4系统集成与优化、L5自主工程与生命周期优化。沿着这个坐标轴你可以精确回答“AI目前在哪个位置”“我们团队该在哪一层用它”“用完之后要做什么样的审核”。说白了它把AI从“玄学”变成了“可以被管理和验收的工具”。我认为这才是它最值得工程师关注的地方。2. PLC Coding五级能力模型一份写给工程师的分级标准2.1 五级模型总览我按自己的理解把这套模型展开了一下如果你去查RealPLC的原始发布材料表述可能有细微出入但递进逻辑基本是沿这个方向走的。先看总表等级能力定位典型产出物核心输入交付可靠性L1代码生成指令片段、功能块、ST/梯形图逻辑文字需求、IO点表语法可过逻辑需人工校核L2代码理解与维护程序注释、逻辑说明、故障诊断、跨语言翻译已有代码/工程文件可辅助排查结论需验证L3工艺方案设计基于工艺时序的控制方案、报警/联锁清单、状态机工艺流程、设备清单、安全要求可作为设计底稿需联合评审L4系统集成与优化多PLC协同、通讯配置、上位机映射、参数优化建议完整系统和网络描述可辅助实施关键配置需现场验证L5自主工程与生命周期优化从方案到交付的完整工程实施含仿真验证、预测性维护需求文档、历史运行数据需闭环验证手段当前远未达到这套模型最巧妙的地方是把“能不能写代码”放在了最低层级。你可能觉得奇怪编程编程写代码不是核心吗但在真实的PLC项目里写代码只是很小一部分。需求确认、IO分配、电气原理图核对、通讯调试、现场试车、写成操作手册——这些环节的工作量都不低。AI如果只会生成代码它解决的其实是“工作量占比较小、但又最容易被看见”的那部分。2.2 L1和L2的区别到底是什么我拿写文章来打个比方L1是一个能写出通顺句子的人你给它一个题目它能写出一段话L2是一个能读懂整篇文章并做批注的人你给它一篇乱七八糟的老文章它能告诉你每段在讲什么、哪里有逻辑硬伤、哪里可以改。放在PLC领域L1就是“按下启动按钮电机运转按下停止按钮电机停止”AI能给你生成对应的梯形图或者ST代码。但实际维护场景里工程师遇到更多的往往不是写新程序而是接手一套没有图纸、没有注释、逻辑乱成一锅粥的老设备。图纸丢了原设计人员走了只有PLC里躺着一段看不出头绪的代码。这时候L2能力就非常值钱把老程序导出来让AI逐段解释逻辑、生成注释、标注联锁关系甚至帮你把三菱的步进梯形图“翻译”成更容易理解的流程图说明。我刚入行的时候接过一台老设备的维护任务光看懂那段阶梯程序就花了一周。如果当时有具备L2能力的AI这一周至少能压缩到半天。所以我在带团队的时候一直强调L1解决的是“从无到有”L2解决的是“从有到懂”而对绝大多数企业来说存量设备的维护才是日常大头L2的价值很可能比L1更高。2.3 为什么L3才是“懂工艺”的分水岭L3的核心是工艺方案设计。到了这一层AI就不再是“你说一句它写一行代码”的助手而是要求它能根据一套完整的工艺流程自主规划控制策略。举个例子一条灌装线L1的AI能生成灌装阀、气缸、电机各自的独立控制代码但L3的AI必须明白整体逻辑——启动后先快灌接近目标重量时切换成慢灌称重信号稳定后才能让压盖气缸动作前一段堵料时后一段必须联动停止报警出现时设备要停在哪一步而不是直接掉电。这就是所谓“懂工艺”。它需要的不只是编程语法知识而是大量行业know-how灌装头的机械特性、传感器的稳定时间、输送线缓存区的作用、不同物料的起泡特性对灌装速度的影响。这些东西不会写在PLC编程手册里也不会完整出现在任何代码仓库中它藏在工艺工程师的脑子里藏在一遍遍试错形成的习惯里。在我看来L3是这套模型中最难跨越的一道坎也是AI短期内最不可能真正的突破点。2.4 从L4到L5AI要补的课不只是“写程序”L4开始进入系统层面。它要面对的不再是一台PLC而是由多台PLC、HMI触摸屏、视觉相机、伺服驱动器、变频器、上位监控系统组成的完整系统。就拿我自己做过的项目来说台达PLC作为485从站串口参数怎么配置、从站地址怎么映射、站号冲突怎么避免信捷PLC作为Modbus TCP服务器和海康相机通讯寄存器区和相机数据格式怎么对齐康耐视Insight相机和西门子PLC做Profinet通讯GSD文件和IO设备组态怎么加西门子PLC里的VD200在Intouch上位机里对应什么地址怎么保证两边数据类型一致。这些都不是单纯的代码问题而是工程系统问题。到了L5AI几乎等于一个“虚拟自动化系统集成商”它要能理解需求文档、自动完成方案设计、生成代码、跑虚拟仿真、生成调试报告、再根据运行数据做预测性维护和工艺自优化。要走到这一步前提是得有大量项目数据灌回模型里。而工业数据恰恰是最难获取的——设备型号杂、协议私有多、现场不允许随便采集。所以我判断L5在很长一段时间内都只能是标杆不是现实目标。3. 拿模型当尺子现在主流AI在PLC领域到底到了哪一级3.1 先说L1的真实体验实验室里能用车间里要谨慎我拿几款主流大模型工具做过测试让它生成一些典型逻辑星三角降压启动、电机正反转互锁、气缸往返动作、定时器累积量统计。结论是简单的逻辑它完成得确实不错代码结构干净命名也规范有些时候比刚入行的新人写得还好。尤其是结构化文本STAI生成的代码可以直接复制到Codesys或博图里编译通过这一点是真的强。但问题也出在这里。编译通过不代表逻辑正确。我遇到过AI生成的正反转互锁程序里只做了软件互锁没有考虑接触器卡死导致的相间短路风险——这在现场是需要额外加硬件互锁的。它还经常忽略扫描周期对代码的影响在一个扫描周期里同时读取和修改一个寄存器导致现场怎么按按钮都没反应。这些问题在模拟器里测不出来因为模拟器的信号不像现场那么乱也不会有接触器线圈断电后的残压干扰。所以我的结论是L1的AI可以当作“快速生成初稿”的工具但它产出的每一段代码都得按现场的规矩过一遍省不掉。3.2 一上通讯和工艺AI就露怯L2到L3的现实瓶颈AI在纯逻辑层面的表现还算亮眼但只要涉及到通讯配置和设备兼容性水平就急剧下降。我试过让它给出“西门子S7-200 SMART作为Modbus RTU从站”的配置步骤它给出的寄存器地址映射倒是对的但忽略了主站轮询周期长短对数据实时性的影响也忽略了波特率不匹配时可能出现时通时断而非完全不通的现象。这类问题它不是不会“写”而是它没见过“现场”。之前有个朋友遇到PLC报警link-100以为是程序逻辑问题拿着报警码去问AIAI给了一堆“检查通讯参数、检查线路”的通用答案。实际上这个报警在特定品牌设备里代表的是Link区数据长度配置错误和程序逻辑没有半点关系。没有现场经验的人看AI的回答觉得挺专业但真正干过的人一眼就知道它在“正确地说废话”。这就是AI在没有足够领域数据时的典型表现语法层没问题语义层凑合场景层基本靠猜。L3及以上要求AI理解工艺、理解设备物理特性指望大模型通过看文字描述就懂灌装头的水流惯性和称重传感器的稳定时间我觉得还早。3.3 为什么大家都在等“仿真验证”这道闭环我一直觉得限制AI走向L5的最大瓶颈不是模型能力而是“数据闭环”缺失。想想自动驾驶是怎么进步的它靠的是海量真实路测数据喂给模型然后模型不断迭代。AI写PLC也一样如果它写完程序之后能自动连接一个虚拟调试环境跑一遍仿真发现逻辑漏洞再自动修正、再验证形成一个完整的“生成-验证-修正”闭环那进步速度会非常可怕。但现在的问题是市面上的PLCSIM、Factory I/O、各种HIL硬件在环仿真与ChatGPT这类大模型工具之间根本没有打通。工程师写完程序后得手工导入仿真软件、手工配置信号、手工判断结果AI看不到这些反馈也就不知道自己写的代码在仿真器里跑成什么样。没有这个闭环AI永远只能靠“猜”来提高进步速度当然慢。谁先把这个闭环打通谁就有机会把AI从L1拉到L3、L4甚至更远。3.4 现状速查表AI在各等级的真实位置能力等级当前AI表现主要阻碍L1能生成语法正确的代码片段和简单逻辑缺乏扫描周期、信号沿、安全回路意识L2能解释常见程序逻辑生成基础注释对特定品牌指令集细节理解不深容易想当然L3能给出工艺逻辑框架但深度不够缺少真实工艺的“试错经验”缺乏物理世界反馈L4能给出通讯配置思路兼容性和诊断能力弱缺乏海量设备组合验证数据L5基本属于概念标杆没有仿真验证闭环没有高质量领域数据回流这张表里L1到L2之间其实是有一条比较清晰的线的——单点逻辑生成已经比较可靠代码理解和注释生成也开始有实用价值。但从L2往L3走难度陡然加大。因为L3要求的不再是“懂代码”而是“懂设备和工艺”这在本质上是两套知识体系。4. 工程师实战把AI用起来顺便往L2以上进化4.1 提问之前先把“工艺背景”喂给AI很多工程师用AI写PLC程序上来就丢一句“帮我写个灌装程序”然后拿到结果觉得不靠谱。这不能全怪AI问题出在需求本身就不完整。AI不是读心机你给它多完整的上下文它就有多大几率给出靠谱的答案。我习惯的提问结构分成三层第一层是设备信息PLC型号、IO点数量、执行机构类型第二层是工艺要求动作顺序、联锁条件、报警需求、手自动切换逻辑第三层是输出格式到底要ST代码、梯形图、SFC流程图还是IO分配表加注释说明。我把一个实际项目的提示词模板书在下面你可以直接抄背景一套单站灌装设备PLC型号为汇川H5U。输入点包括启动按钮、急停按钮、气缸原位/到位检测各一个、称重稳定信号、灌装头上升/下降到位检测输出点包括灌装阀、气缸电磁阀、输送电机。 工艺要求 1. 按下启动后输送电机先运行检测到空瓶到位后停止。 2. 灌装头下降到位后打开灌装阀先快灌接近目标重量时切慢灌。 3. 称重稳定信号有效后关闭灌装阀灌装头上升。 4. 任意急停触发时所有输出复位。 5. 支持手动/自动切换手动模式下每个输出可单独测试。 请输出SFC状态图的分步说明、IO分配表、各步骤的联锁条件以及ST代码框架。报警文本统一标注不要省略安全回路。加了这些背景之后AI输出的质量会明显上一个台阶。而且你会发现当AI开始问你“急停按钮用的是常开还是常闭”“称重信号是直接接入PLC还是通过仪表通讯上传”这类问题时说明它已经在往L2的理解层级走了这种AI的产出才值得你认真对待。如果AI上来就直接噼里啪啦给代码反而要提高警惕——它很可能在用通用模板填答案。4.2 拿到AI结果后的“三查三改”无论AI生成得多漂亮最后要到现场跑必须做一遍“三查三改”。这是我自己的土办法但很管用。三查第一查地址AI经常把不同品牌的地址规则搞混三菱是M、D、Y西门子是I、Q、M、DB台达和信捷又有自己的映射方式。你把IO地址表明确写在提示词里并要求“只准使用表内地址”能减少很多离谱问题。第二查安全急停、安全门、光栅、过载保护这些回路绝对不允许被AI的“简化”逻辑优化掉。我见过AI把急停程序里的常闭触点逻辑“优化”成了常开差点造成安全事故这一点不能有任何商量余地。第三查时序特别是那些涉及多个扫描周期的动作AI很容易把一个需要持续几个周期的状态判断压缩成一步完成导致现场动作错乱。三改第一改封装把AI生成的散乱代码整理成标准FB块加入合理的输入输出接口方便复用和后期维护。第二改报警AI生成的报警文本往往是“错误”“故障”这种笼统词你要改成“灌装头上升超时”“称重无稳定信号”“输送电机过载”这种一看就知道在哪、怎么处理的描述。第三改注释AI的注释有时过于通用你要把现场设备的实际工艺名称、对应图纸编号这些信息补进去。我常说AI生成的程序只是毛坯房三查三改之后才是可以入住的精装房。4.3 把AI当成“读旧程序的助手”比让它“写新程序”更香我在前面提过L2的价值这里展开讲讲实操。我有一次接手一套老设备程序是用某国产品牌的老款软件写的原工程师已经找不到了图纸只剩一半。我的做法是把PLC程序导出成指令表文本然后分段丢给AI让它“用中文把这段逻辑讲清楚”再问几个具体问题“这段是做什么的”“这个计数器什么时候清零”“这个跳转是为了避免什么冲突”。结果让我有点惊讶AI虽然没有把整个工艺逻辑全部还原但它帮我在半个小时内生成了一份带注释的逻辑流程图把那些跳来跳去、不知所云的指令段梳理成了“启动条件-动作输出-结束条件”的结构。我拿着这份图去现场对照设备用了小半天就摸清了整台设备的套路。换作以前纯人工看一周起步还不一定看得明白。这套方法我现在已经写进团队的新人带教流程里了新员工接手旧设备不许直接闷头看程序先让AI做一遍“翻译”再拿翻译结果去现场验证。4.4 从工具到工序把AI嵌进现有开发流程单个人用AI效率提升是好事但团队层面要真正受益不能只靠个人自觉得把AI纳入现有开发流程。我建议团队做三件事一是建提示词模板库把常用控制场景的提示词沉淀下来比如电机控制、气缸控制、模拟量处理、通讯协议配置新人和老人共用一套高质量提示词避免每个人从零开始试验。二是AI输出独立审核任何由AI生成的代码必须经过一次人工评审评审要点就是前面说的“三查三改”审核人要在程序里留记录。三是不要把AI的命名规范直接用于现场每家客户对变量命名的要求不一样AI生成的变量名统一要改成符合项目规范的名字这一步不能省。我见过一些团队为了赶进度AI生成什么就用什么最后交付的程序五花八门后期维护苦不堪言。工具的进步不应该降低工程标准反而应该把人力从低效劳动中解放出来去做更有价值的设计和审核工作。5. 翻车现场与排查实录AI写PLC那些坑5.1 我踩过的几个真实坑第一个坑是地址混乱。让AI写一个台达PLC作为485从站的通讯程序它把站号寄存器和数据寄存器用混了还用了三菱风格的地址命名。如果我没检查就下载到PLC通讯要么起不来要么数据错位。第二个坑是安全逻辑被“优化”掉。有一版AI生成的程序里急停信号被简化成了普通输入取反中断跳转和输出复位全被写成了常规逻辑。表面上看行为一样但真到急停拍下那一刻扫描周期晚几个毫秒都可能出事。这种“正确但危险”的代码最害人。第三个坑是扫描周期误解。AI生成的一段逻辑里把多个需要按扫描周期顺序执行的动作放在同一个条件判断内完成现场现象就是按了启动按钮电机转了0.1秒就自动停了因为后续条件在一个周期内被当成已满足了。排查这种问题最耗时间因为它不会报错只是行为诡异。第四个坑是报警代码的处理。前面提到的link-100报警AI把它当普通变量名来解读给出了完全跑偏的建议。这种特定设备、特定版本下的报警代码没有厂商资料打底AI就是在编。5.2 发现不对之后我是怎么定位的面对AI生成的程序出了诡异故障我建议用“逆向提问法”比人工对着代码干猜快得多。具体操作是这样的把AI生成的代码和现场故障现象一起贴回去然后让AI自己“推演一遍”程序运行过程问它“按照你的代码按下启动后第三个扫描周期各寄存器的值应该是什么”“如果某个传感器信号一直不变化程序会卡在哪一步”。为什么要这么做因为AI生成代码的时候是“正向构造”它沿着需求往下推导但当它推演自己的代码时它会模拟运行反而容易发现自己埋的逻辑漏洞。我试过几次AI主动承认“按这个逻辑这个分支到不了”的比例相当高。然后你再让它给出修正方案再拿修正方案去现场验证这样一轮下来效率极高。这个方法和调试老程序时“大声朗读代码”的习惯是一回事——把代码念出来的时候自己经常能发现哪里不对劲AI也是一样。5.3 常见问题速查表问题现象常见原因处理方向生成的代码地址溢出或冲突AI不了解品牌地址映射规则提示词里附上地址表限定只能用表内地址急停/安全门逻辑被省略或改变AI按“最简化实现”优化明确声明安全回路必须完整保留且不允许简化梯形图结构混乱不符合企业规范AI按通用模式生成用公司的程序模板做统一整理变量名重新规范通讯代码没有超时重连或诊断逻辑AI缺少现场总线故障场景要求AI补充总线诊断、超时重试、状态监控代码报警文本过于笼统无法定位问题AI没有设备级信息把报警码和对应设备名称、处理方式做成表喂给AI运行顺序与工艺要求不一致AI对多步骤时序理解不足改用SFC图描述工艺再让AI按状态机生成代码这张表我建议打印出来贴在工位上。它不是标准答案但至少能帮你把AI产出物的审核流程化减少低级错误。好用顺手补一句任何AI生成的代码在下载到真实PLC之前都建议先在仿真环境里跑一遍。这一步不能省我吃过亏。5.4 什么时候我坚决不用AI最后说一个边界问题。AI虽然好用但有些场合我坚决不用。第一类是纯安全相关逻辑急停硬回路、安全继电器逻辑、光栅连锁、抱闸控制这些我不允许AI直接生成或修改最多让它做解释说明和文档整理。七分靠硬接线三分靠程序安全回路里哪怕逻辑上一个点出错赔上的可能是设备甚至是人。第二类是客户有明确认证要求的程序比如某些行业的第三方认证要求特定代码实现必须由具备资质的人签字负责AI生成的代码没有责任人根本过不了审。第三类是涉及高端工艺Know-how的核心控制算法比如某些独特配方工艺的经验参数曲线我不希望它进入公共模型形成训练语料也不认为AI能真正理解里面的门道。在这些场景里AI的角色止步于“解释”和“记录”不参与最终决策。工程师可以借它提高效率但不能把责任交给它。我个人的态度其实很明确五级模型最值钱的一点不是给AI发等级证而是帮我们把“AI写PLC”这个笼统的话题拆成了一个个可以讨论、可以验收的环节。我自己现在的用法也变了——很少再让AI直接出一整套站内程序而是让它帮我做两件事一是把接到手的老程序快速“翻译”成工艺说明二是把模糊的设备需求整理成结构化提示词。这两件事做完我再基于它的输出做设计、写联锁、补报警效率反而提升了很多。最后再分享一个小技巧让AI解释旧程序时别只问“这段是什么意思”要连着问“这一段如果某个输入掉了会怎样”“上电顺序如果反过来会怎样”。多问几个“会怎样”AI的答复质量会有质的提升你也会更早发现那些藏在老程序里的坑。这大概就是L2能力在一线最值钱的样子。再过几年等仿真闭环真正成熟L3、L4的AI可能会进入项目但至少现在把它放在L1并认真用好L1是我们最务实的选择。