AI写PLC只能算L1？PLC Coding五级能力模型解读与工程师实战指南

最近工业自动化圈子里聊得最热闹的话题，不是哪家新出了旗舰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的原始发布材料，表述可能有细微出入，但递进逻辑基本是沿这个方向走的。先看总表：

这套模型最巧妙的地方，是把“能不能写代码”放在了最低层级。你可能觉得奇怪，编程编程，写代码不是核心吗？但在真实的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到L5，AI要补的课不只是“写程序”

L4开始进入系统层面。它要面对的不再是一台PLC，而是由多台PLC、HMI触摸屏、视觉相机、伺服驱动器、变频器、上位监控系统组成的完整系统。就拿我自己做过的项目来说，台达PLC作为485从站，串口参数怎么配置、从站地址怎么映射、站号冲突怎么避免；信捷PLC作为Modbus TCP服务器和海康相机通讯，寄存器区和相机数据格式怎么对齐；康耐视Insight相机和西门子PLC做Profinet通讯，GSD文件和IO设备组态怎么加；西门子PLC里的VD200在Intouch上位机里对应什么地址，怎么保证两边数据类型一致。这些都不是单纯的代码问题，而是工程系统问题。

到了L5，AI几乎等于一个“虚拟自动化系统集成商”，它要能理解需求文档、自动完成方案设计、生成代码、跑虚拟仿真、生成调试报告、再根据运行数据做预测性维护和工艺自优化。要走到这一步，前提是得有大量项目数据灌回模型里。而工业数据恰恰是最难获取的——设备型号杂、协议私有多、现场不允许随便采集。所以我判断L5在很长一段时间内都只能是标杆，不是现实目标。

3. 拿模型当尺子：现在主流AI在PLC领域到底到了哪一级

3.1 先说L1的真实体验：实验室里能用，车间里要谨慎

我拿几款主流大模型工具做过测试，让它生成一些典型逻辑：星三角降压启动、电机正反转互锁、气缸往返动作、定时器累积量统计。结论是，简单的逻辑它完成得确实不错，代码结构干净，命名也规范，有些时候比刚入行的新人写得还好。尤其是结构化文本ST，AI生成的代码可以直接复制到Codesys或博图里编译通过，这一点是真的强。

但问题也出在这里。编译通过不代表逻辑正确。我遇到过AI生成的正反转互锁程序里，只做了软件互锁，没有考虑接触器卡死导致的相间短路风险——这在现场是需要额外加硬件互锁的。它还经常忽略扫描周期对代码的影响：在一个扫描周期里同时读取和修改一个寄存器，导致现场怎么按按钮都没反应。这些问题在模拟器里测不出来，因为模拟器的信号不像现场那么乱，也不会有接触器线圈断电后的残压干扰。所以我的结论是：L1的AI可以当作“快速生成初稿”的工具，但它产出的每一段代码都得按现场的规矩过一遍，省不掉。

3.2 一上通讯和工艺，AI就露怯：L2到L3的现实瓶颈

AI在纯逻辑层面的表现还算亮眼，但只要涉及到通讯配置和设备兼容性，水平就急剧下降。我试过让它给出“西门子S7-200 SMART作为Modbus RTU从站”的配置步骤，它给出的寄存器地址映射倒是对的，但忽略了主站轮询周期长短对数据实时性的影响，也忽略了波特率不匹配时可能出现时通时断而非完全不通的现象。这类问题它不是不会“写”，而是它没见过“现场”。

之前有个朋友遇到PLC报警link-100，以为是程序逻辑问题，拿着报警码去问AI，AI给了一堆“检查通讯参数、检查线路”的通用答案。实际上这个报警在特定品牌设备里代表的是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在各等级的真实位置

这张表里，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生成的代码，在下载到真实PLC之前，都建议先在仿真环境里跑一遍。这一步不能省，我吃过亏。

5.4 什么时候我坚决不用AI

最后说一个边界问题。AI虽然好用，但有些场合我坚决不用。第一类是纯安全相关逻辑：急停硬回路、安全继电器逻辑、光栅连锁、抱闸控制，这些我不允许AI直接生成或修改，最多让它做解释说明和文档整理。七分靠硬接线，三分靠程序，安全回路里哪怕逻辑上一个点出错，赔上的可能是设备甚至是人。第二类是客户有明确认证要求的程序，比如某些行业的第三方认证，要求特定代码实现必须由具备资质的人签字负责，AI生成的代码没有责任人，根本过不了审。第三类是涉及高端工艺Know-how的核心控制算法，比如某些独特配方工艺的经验参数曲线，我不希望它进入公共模型形成训练语料，也不认为AI能真正理解里面的门道。

在这些场景里，AI的角色止步于“解释”和“记录”，不参与最终决策。工程师可以借它提高效率，但不能把责任交给它。

我个人的态度其实很明确：五级模型最值钱的一点，不是给AI发等级证，而是帮我们把“AI写PLC”这个笼统的话题拆成了一个个可以讨论、可以验收的环节。我自己现在的用法也变了——很少再让AI直接出一整套站内程序，而是让它帮我做两件事：一是把接到手的老程序快速“翻译”成工艺说明，二是把模糊的设备需求整理成结构化提示词。这两件事做完，我再基于它的输出做设计、写联锁、补报警，效率反而提升了很多。

最后再分享一个小技巧：让AI解释旧程序时，别只问“这段是什么意思”，要连着问“这一段如果某个输入掉了会怎样”“上电顺序如果反过来会怎样”。多问几个“会怎样”，AI的答复质量会有质的提升，你也会更早发现那些藏在老程序里的坑。这大概就是L2能力在一线最值钱的样子。再过几年，等仿真闭环真正成熟，L3、L4的AI可能会进入项目，但至少现在，把它放在L1并认真用好L1，是我们最务实的选择。