AI生成PLC程序能力分级：从L1到L5，工程师的提效指南

1. 为什么AI写PLC这件事，终于有人给出了“判定标尺”

最近翻技术群，十条里少说有四五条在聊AI写PLC。有的说“以后PLC工程师要失业了”，有的晒出截图，让AI写了个好几行的梯形图，评论区一片惊叹。我自己也试过不少，说实话，AI确实能写，但写出来的是什么水平，能不能直接下现场，这里面水太深了。

RealPLC提出“PLC Coding五级能力模型”这件事，我认为最有价值的不是又抛出一个新概念，而是它第一次把问题从“AI能不能写PLC程序”拉到了“AI写出来的PLC程序到底算什么水平”的维度。这个转向非常关键，因为你一旦开始用“等级”的视角去看，很多宣传就不再迷人了——那些“AI十分钟生成整套程序”的演示，大概率只停留在第一级。

这篇文章我准备把五级模型掰开揉碎讲清楚，结合西门子、三菱、汇川这些主流PLC的实际场景，讲讲每一级到底长什么样、AI目前真实水平在哪一级、我们工程师该怎么用它来提效，以及从模型到现场稳定运行之间还有哪些坑。无论你是刚入门的PLC学习者，还是每天和博途、GX Works打交道的现场工程师，这套分级都能帮你校准预期，少交点智商税。

2. PLC工程师的真实工作流：分级逻辑从哪来

在拆五级模型之前，得先聊一个更基础的问题：一个PLC工程师的日常工作，到底由哪些环节组成？

很多人以为PLC工程师就是“画梯形图”的，这是最大的误解。我做过的大大小小项目，从单机设备到一条几十米的生产线，真正花在“写代码”上的时间，可能只占整个项目周期的两三成。更多的时间消耗在理解和翻译工艺需求、做I/O点表、配置硬件组态、设计程序架构、反复仿真验证、现场调试排错、甚至陪产到深夜。AI写PLC这件事最大的认知偏差，就是大家都盯着“写代码”这一小块，而实际上代码只是整个控制系统的最后一公里。

RealPLC五级能力模型的底层逻辑，其实就是顺着工程师的真实能力成长路径走的。

我拿一个老工程师的职业发展来类比就更清楚了：刚入职的时候，你能照着手册写出一条MOVE指令，这是最初级的技能；干了一两年，你能独立写一个带故障诊断的水泵控制块，知道怎么封装接口、怎么处理异常；再往后，你开始负责整个项目的程序架构，能做模块划分、数据组织、安全联锁；到了资深阶段，你能基于现场的运行数据持续优化程序策略，甚至参与工艺改进。你发现没有，这可不仅仅是“会写的指令越来越多”，而是看问题的层级在逐层拔高。

五级模型的分级逻辑正是如此。它不是按“代码行数”或者“指令复杂度”来划分，而是按“AI对工程目标的理解深度”和“自主完成任务的闭环程度”来划分。这就让这套模型有了区分度，也让它能真正指导实践。

2.1 分级考察的三个核心维度

第一，是需求理解深度。AI是只看到一句“写一个电机启保停程序”，还是能理解整个设备的运行逻辑、安全要求和联锁条件？这直接决定了它输出的是“一段代码”还是“一个解决方案”。

第二，是工程闭环程度。写完代码之后，AI会不会做仿真验证？能不能发现I/O地址冲突？能不能在逻辑里处理掉电保持、故障复位这些现场问题？闭环程度越高，AI越接近一个可以独立交付的工程师。

第三，是抽象与架构能力。面对一个完整的项目，AI能不能拆出手动/自动模式、报警模块、配方管理、通信处理这些清晰的功能边界？还是说只能把所有的逻辑堆在一个OB1里？这个差距，在五级模型里体现得非常明显。

五级模型我理解下来是这样的：L1是代码片段生成，L2是功能单元生成，L3是项目方案生成，L4是闭环工程能力，L5是自演进与工艺优化。下面一个一个拆开说。

3. 五级能力模型完整拆解：从L1到L5

先给一个总览表格，方便大家对号入座。

这个表格不是凭空画的，每一级背后都能找到对应的技术特征和工程场景。下面详聊。

3.1 L1：代码片段生成——当前大模型的真实水平

L1的核心特征是：AI能“写出代码”，但它不懂工程。你给它一句“五分钟后延时启动”，它能给你一个TON定时器配合MOVE指令的组合；你让它“写一个电机正反转互锁”，它也能像模像样地输出一个梯形图。看着像那么回事，但你要是真把它丢到博途里编译，大概率有问题。

为什么这么说？因为大模型在PLC领域的学习素材，很大一部分来自公开的编程手册、培训教材、论坛问答。这些素材天然是“语法正确”但“上下文缺失”的。AI真正缺少的是“现场因果反馈”。换句话说，它从来没被一个旋转设备打断过叶片，也没有在三更天被叫起来处理过急停回路不灵的问题，所以它很难真正理解安全联锁为什么必须放在硬件回路里，而不是仅仅写在程序里。

我实测过让AI生成西门子S7-1200的电机启保停程序，SCL版本大概长这样：

// 电机启保停 - S7-1200 SCL IF #StartBtn AND NOT #StopBtn AND NOT #ThermoTrip THEN #MotorRun := TRUE; ELSIF #StopBtn OR #ThermoTrip THEN #MotorRun := FALSE; END_IF;

这个片段语法没问题，逻辑也基本正确。但注意，变量名是抽象的StartBtn、StopBtn，没有实际I/O地址，没有硬件组态，没有急停回路，没有掉电保持的讨论。放到真实项目里，这只是整个程序的一个细胞，离“能用”还有十万八千里。所以标题说“AI写PLC程序，只能算L1”，我认为非常客观。目前市面上吹得最凶的AI编程演示，绝大多数都停留在这个层级。

3.2 L2：功能单元生成——会封装、懂接口、能复用

到了L2，AI的能力就从“写一行指令”进化到了“写一个部件”。什么叫一个功能单元？拿最典型的“水泵自动控制”来说，不仅要有启停逻辑，还要包含手/自动切换、故障报警、运行状态反馈、电机过载复位、累计运行时间统计这些内容。

L2和L1的关键分水岭在于“接口意识”。AI如果能主动把输入、输出、内部静态变量像下面这样整理成一张接口表，说明它开始理解“可复用工程部件”这个概念了：

再加上对“电机过载后必须手动复位才能重新启动”“液位低时不允许启动”这类工艺规则的处理，AI生成的逻辑块就基本具备现场可用性了。

从工程实践来看，L2级别的AI输出，已经能切实帮到一线工程师。我自己现在做项目，经常让AI先搭一个功能块的“骨架”，把接口定义、诊断逻辑、状态机的框架写出来，我再往里面填具体的工艺判断条件。这样做的效率，比从空白页开始写至少快一倍以上。而且还有意外收获，AI生成的诊断逻辑经常比我自己平时习惯写的更完整，因为它会从纯逻辑完备性角度把各种分支都覆盖一遍。

3.3 L3：项目方案生成——从“写代码”到“做架构”

到了L3这一级，AI的输出不再是“一个块”，而是一整套“项目方案”。给它一份设备的工艺描述，比如“一条包装线，包含进料传送带、封口机、计数器、三色灯、紧急停止”，AI能输出完整的程序架构，包括模块划分、程序组织单元（OB/FB/FC/DB）规划、数据结构设计、主要执行流程。

这个级别的价值在于，程序架构往往是年轻工程师最欠缺的能力。很多项目代码后期维护困难，就是因为前期架构没做好，所有逻辑堆在几个大块里，改一处崩三处。AI如果在架构层面能给出合理的模块边界和层级关系，对项目的长期健康运行帮助极其显著。

我试着让AI为上述包装线做过一个模块划分建议，它的输出大致是这样的：

• 主程序OB1：扫描周期管理，调用各模式处理块
• 手动模式块：单机点动，用于调试和维护
• 自动模式块：按工艺顺序执行进料、封口、计数循环
• 安全联锁块：急停、门开关、光栅信号统一处理，独立于自动流程
• 报警引擎块：统一管理故障捕捉、报警显示与复位
• 配方/参数数据块：计数目标、传送带速度等工艺参数集中存储

看到这个结果，我是有点惊讶的。它没有把安全联锁揉进自动流程里，而是单独拆出来，说明AI对“安全功能必须独立于常规逻辑”是有一定认知的。当然，架构归架构，真要落地，还需要人工做很多关键决策，比如安全回路是走硬接线还是走安全PLC，这绝不是AI能替你拍板的。但“从0到1的架构草稿”这一步，AI已经能完成得很好。

3.4 L4：闭环工程能力——会验证、会修正、能交付

L4和L3的本质区别，在于“闭环”。AI生成的程序不再是一锤子买卖，而是进入了一个“生成—仿真—发现问题—修正—再验证”的循环。

这可能也是PLC这个领域和Web开发、数据分析最大的不同。互联网代码写错了，改一行重新部署，成本很低；PLC程序出问题，轻则停机停产，重则设备损坏甚至伤人。所以PLC行业历来对“验证”的要求极高，而这恰恰是当前大模型最薄弱的一环。大模型本质上是一个“根据上文预测下文”的系统，它没有执行环境，不知道自己的输出在真实PLC里跑起来是什么结果。

但方向是对的。目前已经有团队尝试把AI生成的代码自动导入PLCSIM等仿真环境，配合Factory I/O这类虚拟产线做联合调试。AI生成的程序如果仿真通过了，再走人工审核，这个流程一旦跑通，AI就能摸到L4的门槛。

L4还要考验一个能力：从仿真结果反推问题根源并且修正代码。这比“生成代码”难得多，因为它需要模型具备一定的因果推理能力。举个例子，仿真运行时如果发现“输送带在收到停止信号后，因为正在执行封口动作而延迟了3秒才停”，AI能不能意识到这是流程协作上的问题，并主动调整状态机的切换条件？如果能，那它就不是一个代码生成器，而是一个真正的工程助手了。至少在当前这个时间点，还没有产品能稳定做到这一点。

3.5 L5：自演进与工艺优化——长期主义的最高级

L5听起来很科幻，但逻辑上它是L4的自然延伸。当AI不仅能完成单个项目的闭环，还能基于现场长期积累的运行数据、故障数据、能耗数据，主动对控制策略做出优化建议，甚至自动调整参数，它就进入了“自演进”阶段。

举几个具体的画面：生产线连续运行三个月后，AI发现某个气缸的往复时间从每周期1.2秒逐渐退化到1.5秒，它综合判断可能是密封磨损，提前给出了维护提醒；或者它发现夜间低负荷时段，PID回路震荡幅度偏大，自动调整了积分系数，让系统平稳下来。这些已经是资深工艺工程师做的事情了。

这个级别最大的挑战其实不只是AI，而是数据基础和行业规范。PLC是工业控制的现场层，往上还有MES、SCADA，再往上才是数据分析平台。数据能不能打通、敢不敢让AI触碰控制逻辑，都是远比模型能力更难回答的问题。所以L5更多是方向，是大家努力的目标，短期内不会有成熟产品。

4. AI生成PLC程序，落地现场前必须解决的技术细节

讲完分级，来聊点落地的东西。不管AI帮你写到了L2还是L3，最终程序都是要下到PLC里，驱动真实的电机、气缸、变频器运转的。围绕现场实施，有几个高频技术点我想特别拆开说，因为这些恰恰是AI很难“替你想到”的内容。

4.1 VMware里连PLC：桥接、NAT、仅主机到底怎么选

很多工程师有在虚拟机里装博途或者GX Works的习惯，结果发现虚拟机死活扫描不到现场PLC。这个问题几乎每周都有人问，答案其实就三个字：用桥接。

VMware的三种网络模式，我用一句话分别概括：NAT是“虚拟机通过宿主机上网”，对外不可见；仅主机是“虚拟机只和宿主机通信”，完全封闭；桥接是“虚拟机像一台独立的设备一样，直接插在你当前的局域网里”。PLC自动扫描依赖的是广播报文和网段内的设备发现机制，NAT模式相当于给虚拟机装了一堵墙，PLC的广播帧根本广播不到虚拟机里；仅主机模式下虚拟机和PLC之间则完全不在一个网络域。只有桥接模式，PLC才能把虚拟机当成网段内的一台普通设备来发现和访问。

实际操作时还有几个细节要留意。一是桥接要选对物理网卡，如果你的电脑既有有线网卡又有无线网卡，必须指定连接到PLC所在网络的那一张。二是在虚拟机里手动设置静态IP，和PLC保持在同一网段，比如PLC是192.168.0.1，你在虚拟机里就设置成192.168.0.88，掩码255.255.255.0。三是Windows防火墙经常拦PLC通信软件，我踩过不少次坑，后来干脆在“专用网络”模式下把TIA Portal、SIMATIC Manager这些程序全部放行，安静很多。如果你扫描还是找不到设备，先在虚拟机里PING一下PLC的IP，通则设备发现基本没问题，不通就回到网络适配器设置里检查选没选对网卡。

4.2 西门子PLC控制变频器三段速：接线和程序是一对搭档

AI写梯形图的时候，经常会写出“用程序直接改变频率设定”这种逻辑，这在通信控制的场景下是对的，但在很多老设备上，PLC控制变频器靠的是数字量输出点，这就是热词里提到的“开关量控变频器”问题。这里存在一个很大的认知盲区，很多人以为开关量只是“启动/停止”，但其实通过多个DO点组合，完全可以实现多段速控制。

三段速的经典做法是：用PLC的两个或三个DO点去控制变频器的多功能输入端子。以西门子变频器配合S7-1200为例，假设用Q0.0、Q0.1、Q0.2分别接变频器的DIN1、DIN2、DIN3，变频器内部把DIN1、DIN2、DIN3分别定义为固定频率1、固定频率2、固定频率3，PLC侧只需要按真值表输出这三个点：

程序写起来很简单，本质就是根据工艺条件给Q0.0/Q0.1/Q0.2赋值。但这里有一个特别容易出错的地方：切换段速的时候，变频器会因为频率突变造成机械冲击。成熟的工程师会在切换之前先判断设备当前是否在运行，或者通过延时配合减速曲线，让频率切换更平滑。这个细节，AI基本不可能自动考虑到。

4.3 三菱PID自整定和西门子多重背景：AI可以写，但参数和架构得人来定

再聊两个实战里高频出现、又特别能体现AI边界的技术点。

三菱FX系列PLC做PID控制，很多新手一上来就写PID指令，结果要么系统震荡要么响应迟钝。正确做法是先做自整定：三菱的PID指令支持自整定功能，需要把相关的自整定位元件置ON，然后让系统在有负载的状态下自动辨识过程特性，PLC会根据测量值的变化自动计算出PID参数。实操中经验是：自整定前先把回路切到手动，让被控量稳定在设定值附近再启动自整定，否则自整定出来的参数可能很离谱。而且整定出的参数一般偏保守，想要更好的动态响应，还得在工程经验基础上手动微调比例增益和积分时间。AI给你生成的PID指令片段，永远替代不了这一步现场的调试手感。

西门子S7-300/1500的多重背景（Multi-Instance），则是一个非常典型的“架构级”问题。初学者喜欢一个FB配一个背景DB，做多了项目就会发现背景DB碎片化非常严重。多重背景的做法是先建立一个调用多个FB的“管理者”FB，让这些子FB的实例数据统一收纳在管理者FB的背景DB里，工程上整洁得多，地址管理也更方便。AI能不能理解这种架构取舍？说实话，目前它最多能解释什么是多重背景，要它在你这个具体项目里做出“哪些逻辑适合做成多重背景、哪些适合全局DB”的判断，还差得远，因为这里面有很强的个人习惯和项目维护偏好。

4.4 AI代码落地前必做的五道校验

结合自己的经验，我给所有想用AI提效的工程师一个忠告：AI生成代码务必要走“五道校验”。

第一道，硬件组态校验。程序里引用的每一个I/O地址、每一个模块型号，都要和硬件组态严格对应。AI生成代码时往往会用一些笼统的符号名，特别容易漏掉模块的实际通道范围。

第二道，安全联锁校验。急停回路、安全门、光栅这些信号的优先级必须是最高的，而且最好独立于主控制流程。如果AI把安全联锁逻辑和普通工艺逻辑混在一起写，直接让它返工。

第三道，数据类型与边界条件。整数溢出、定时器最大定时值、模拟量工程量转换的上下限，这些都是AI生成代码的重灾区。尤其是定时器，TON定时器如果定时值超过上限，在S7-1200里会直接出错。

第四道，掉电保持与数据初始化。哪些数据掉电后必须保持，哪些必须重新初始化，这需要根据工艺来决定。AI没有现场知识，它不知道你的设备停机后重新上电，料位、速度、累计数的恢复策略是什么。

第五道，仿真验证。有条件就上PLCSIM，简单设备可以用模拟量信号做干跑测试。这一步过了，才算达到L3级别的可用标准。

5. 工程师怎么用好这套五级模型：我的实战建议

把模型和实操都讲完之后，聊聊“有了这把尺子之后，普通人到底该怎么用”。其实这套模型给我最大的启发，不是去衡量AI，而是反向衡量自己的工作方式。

5.1 把分级当尺子，不要当判决书

你要明白，用AI写到L2或L3，并不代表你个人水平是L2或L3。反过来，AI只能做L1，也不代表以后永远停在L1。模型的真正价值在于帮你判断“哪些工作现在可以交给AI，哪些还有很高的验证成本”。我的习惯是：L1级别的活，比如写个标准指令片段、生成一段ST语法示例，直接交给AI，省下来的时间去做L3、L4的思考和验证。L2级别的功能块，让AI搭框架和接口，我负责填工艺细节。到了L3以上，AI输出的内容只作为参考草案，没有经过完整的仿真和评审，我绝不让它直接进项目。

5.2 给团队和供应商准备一张评估清单

如果你是团队负责人，或者要在采购阶段评估某个“AI PLC编程工具”，可以拿下面这张表做初步判断：

这套表不一定能直接测出工具的“绝对分数”，但至少能帮你绕开那种“贴一个梯形图就说自己能替代工程师”的营销话术。

5.3 说说我个人的真实感受

试了这么长时间AI辅助PLC编程，我最大的一个感受是：AI写PLC这件事，瓶颈从来都不在“写代码”本身。一个指令怎么写，一段梯形图怎么画，这些都是有标准答案的，AI学得快很正常。真正的门槛在于你对工艺的理解、对设备安全底线的敬畏、对现场各种异常工况的预判能力。这些东西没有任何一本手册会写全，更不可能从一句话提示词里凭空长出来。

所以我的建议很朴素：大胆用AI去处理那些重复的、确定性的工作，让它帮你节省时间，但把省下来的时间和精力，投入到需求调研、仿真测试、现场调试这些真正决定项目成败的事情上去。希望这套五级模型也能帮你更清醒地看待“AI写PLC”这件事。下次再刷到“AI十分钟写完一个完整项目”之类的标题，你可以在心里默默打个分——如果它只是生成了一小段梯形图，再炫也只是L1；能和你讨论工艺流程和模块划分的，才是真正值得花时间研究的工具。