AI写PLC程序实测：工控人该不该转行？片段级辅助距离完整项目有多远

最近一段时间陆续有好几位同行在微信上问我同一个问题“AI 都能写 PLC 程序了工控人是不是该考虑转行了”问的人里有刚入行两三年的年轻工程师也有干了十多年设备维护的老手。我一开始没太当回事直到自己动手试了一圈之后才意识到这个问题值得认真聊一聊。先说结论AI 写 PLC 这件事真实水平没有标题里听起来那么吓人但也不是完全没用。我花了两周时间拿手头一个闲置的控制柜做了几组实测让它写逻辑、写功能块、写报警文本再拿这些结果去编译、去查错、去对比我平时手写的工程文件。这篇文章就是这次实测的完整记录包括它写得好的地方、写得离谱的地方以及我认为工控人真正应该担心的和完全不需要担心的事情。如果你是一名电气工程师、PLC 程序员、设备维护人员或者正在考虑进入工控行业这篇文章应该能给你一个相对踏实的参考坐标。1. AI写PLC程序实测水平到底怎么样1.1 能跑通的片段从简单逻辑说起我先从最简单的需求开始试让它写一个电机起保停控制逻辑。这种逻辑是工控入门第一课按钮启动、按钮停止、接触器自锁、热继电器常闭触点串在回路里梯形图也好、结构化文本ST也罢翻来覆去就那么几行。AI 生成这段代码的速度确实快几乎是一眨眼的功夫而且第一次生成的版本逻辑就是通的。它知道要用置位和复位指令知道停止信号要放在前面知道需要一个中间变量来保存运行状态。我拿着这段代码在编程软件里做了语法检查一次通过。编译、模拟运行、强制变量都表现正常。说实话这一下让我有点意外。接着我又试了定时器应用、计数器应用、顺序启动、星三角切换这类经典逻辑。除了一些指令名称需要按照具体PLC型号做微调之外大部分都能给出可用的代码。尤其是那些纯粹的逻辑运算、数学公式转换、数组处理片段AI 的生成质量已经超过了不少入行一两年的新人。原因也简单这些内容在公开资料里太多了模型学习得足够充分。1.2 看似专业、实则离谱的“幻觉”正当我觉得 AI 有点东西的时候它就开始翻车了。翻车方式还不是简单的错误而是那种“看起来非常专业实际上完全不能用的幻觉”。我让它写一个模拟量输入滤波的功能块。它给我生成了一段代码里面有模数转换指令、平均值计算、偏差判断注释写得整整齐齐变量命名也很规范。但我仔细一看就发现了问题它调用了一个这个型号 PLC 根本不存在的“系统函数”。也就是说这段代码永远无法编译通过因为它依赖的是一个虚构的指令。你如果不熟悉这个品牌 PLC 的指令集光是看着代码结构根本看不出毛病。更离谱的是我让它写一套带安全联锁的液压站控制程序。它非常贴心地帮我加上了“油温过高报警”“油位过低保护”“滤芯堵塞提示”这些逻辑看起来想得很周全。但只要深入核对就会发现它把两个液压泵同时启动的条件搞反了——本来应该互为备用的两台泵在它的逻辑里变成了同时启动。这种错误在代码层面很难发现只有在工艺层面才知道违反了设备运行的常识。如果你直接拿这种代码去现场跑轻则设备报警重则机械损坏。1.3 结论AI目前的定位是“片段级辅助”两轮测试下来我对 AI 写 PLC 的定位有了一个比较清晰的判断它适合写“片段”不适合写“项目”。所谓片段就是一段功能明确、边界清晰、输入输出可描述的代码块所谓项目则是一个包含硬件配置、网络组态、IO映射、工艺联锁、报警分级、手动自动切换、安全保护、掉电保持、现场调试的完整控制系统。前者是知识提炼后者是系统工程。AI 在提炼知识方面确实有优势但在系统工程方面它目前既看不到你的原理图也读不到你的点表更不知道你的设备在现场实际跑起来是什么脾气。它给你的只是一坨看起来合理的代码不是一套能够安全稳定运行的程序。所以别急着恐慌。会写几个功能块的 AI距离能独立交付一个能上电运行的控制项目中间还隔着十万八千里。2. 为什么AI写不出一个能上电运行的完整程序2.1 硬件差异与地址映射AI看不见你的点表每一台 PLC 程序的诞生都不是从写代码开始的而是从看图纸、对点表开始的。你得知道这台设备上有几个输入信号几个输出信号哪些是常开触点哪些是常闭触点哪些信号是接到模拟量模块的哪些是走通讯的每个通道对应现场哪一个传感器或者执行机构。所有这些信息集中在一张IO分配表里那是整个控制程序的骨架。AI 生成代码的时候根本不知道你的点表长什么样。它写出来的地址要么是默认生成的 %I0.0、%Q0.0 这类寄存器地址要么是一长串随意编造的变量名。你拿回来之后还得一个一个对照点表去改。如果是一个几百点的中大型项目光是地址映射的工作量就足够让人改到崩溃。换句话说AI 能帮你省掉的是“写代码”的那部分时间而工控人真正花时间的“对点表”“看图纸”“查线路”这些工作它一点忙都帮不上甚至还会因为乱编地址给你添乱。此外不同品牌、不同系列的 PLC编程方式差异极大。有的用梯形图有的偏好结构化文本还有的功能块图。各家的指令集、寻址方式、中断机制、通讯协议、数据结构定义都不一样。AI 会倾向于生成“通用风格”的代码但现场的设备往往是某一个具体品牌的具体型号你需要把它生成的通用代码逐条“翻译”成当前工程里能用的指令。这个翻译过程本身就是一种消耗。2.2 工艺逻辑与联锁代码之外的需求我见过太多外行人以为做电气控制就是“写程序”但真正在现场干过的都明白写程序之前得先“吃透工艺”。拿一套最简单的自动包装线来说什么时候启动传送带什么时候停止供料气缸伸出的条件是什么退回的条件是什么两台电机之间要不要联锁报警之后先停哪台设备复位按钮在什么状态下才有效。这些逻辑图纸上不会直接画出来说明书里也不会写完整全靠工程师和设备负责人一遍遍搭着聊甚至要蹲在现场看设备运行很久才能摸清楚。AI 无法理解工艺。它不懂“这个气缸绝对不能和那个气缸同时伸出是出于安全考虑”也不懂“供应商的这台设备启动时一定要先确认前一道工序的物料到位”。你给它一个需求描述它只能按照字面意思拼凑出一段逻辑至于这段逻辑是否符合设备实际运行的需要它完全没概念。打个比方让 AI 写控制程序就像让一个从没下过厨房的人照着菜谱做一道东坡肉。菜谱上每一步都写得清清楚楚但火候的微妙变化、锅底的实际情况、食材的细微差异这些只有亲自动手做过的人才清楚。AI 是一个极其勤奋的菜谱阅读者但它不是厨师。2.3 异常处理与安全检查出错的代价不一样写普通软件出错了的代价可能是程序崩溃重新部署一下就好。但写 PLC 程序出错的代价可能是设备损坏甚至人身伤害。这是工控和 IT 软件开发之间最本质的区别也是 AI 写代码这件事最大的隐患所在。AI 的生成逻辑是基于概率的。它倾向于输出“最常见的写法”而“最常见的写法”往往没有任何安全冗余。让它写一个气缸控制逻辑它会给你标准的电磁阀输出控制但不会主动考虑“如果气缸卡住了怎么办”“如果到位传感器坏了怎么办”“如果阀芯卡滞导致误动作怎么办”。这些异常情况处理是工控程序里极其重要的组成部分但它们在公开代码库里出现的频率远低于正常逻辑所以 AI 很难主动生成。我在实测中发现AI 生成的代码里急停处理逻辑普遍缺失安全门联锁做得非常潦草手动和自动模式的切换要么没有互锁要么切换条件过于简单。这些恰恰是工控程序里真正值钱的内容。一个合格的程序里安全相关逻辑至少要占三成以上而在 AI 生成的代码里这部分往往被压缩到接近于零。2.4 调试与验证仿真跑通不等于现场稳定退一步讲就算 AI 生成的代码能够编译通过逻辑也基本正确你仍然逃不掉现场调试这一步。而现场调试才是工控项目里最不可控、最能体现经验价值的环节。模拟量信号的波动、传感器接线松动导致的信号闪烁、变频器启动带来的干扰、机械卡顿引起的定位偏差这些问题没有任何一个仿真软件能模拟出来。AI 也无法提前预判你的现场会遇到什么奇怪的问题。它会很认真地告诉你“这段代码理论上没问题”但现场的实际表现可能会让它的理论显得非常苍白。我曾经在调试一台设备时程序逻辑看起来完美无缺上电测试却发现偶尔误动作。查了两天最终发现是靠近变频器的一段模拟量信号线屏蔽层接地不规范导致干扰信号窜入了输入模块。这种问题你让 AI 怎么发现它连你的变频器装在哪、布线怎么走的都不知道。所以AI 可以帮你把代码写得更好看、更快但“验证代码在真实环境里能安全稳定运行”这件事永远只能靠人去完成。3. 工控人的底气本来就不在“写代码”上3.1 现场经验是数据训练不出来的很多人一听说 AI 会写代码就慌了是因为默认了“工控人的核心技能就是写代码”。但这是一个天大的误解。在工控行业代码只是你表达控制逻辑的工具之一而且远不是最核心的那个。真正值钱的是经验。是那种听到设备异响就能判断出是轴承磨损还是齿轮松动的经验是看到程序里的某个定时器参数就能猜到这台设备实际节拍的经验是设备一出故障不用看图纸就能锁定大概率是哪个传感器出问题的经验。这些经验建立在成千上万个小时的现场摸爬滚打之上每一分每一秒都带着油污和汗味。AI 的训练数据里可以包含无数技术文档和代码片段但它永远无法包含“某个设备在某个环境下会有哪种奇怪的脾性”这种碎片化信息。我认识一位同行几十年的设备维修经验听声音就能判断出电机轴承是否缺油。有一次设备故障所有人都在查程序他到现场转了一圈说换掉电机尾部那个轴承试试。结果换上之后设备立即恢复正常。这种判断力AI 给不了代码也给不了只能靠时间积累。3.2 工艺理解与需求翻译能力工控工程师的核心能力是把机械工程师、工艺工程师、操作工嘴里那种含糊不清的需求翻译成严谨的控制逻辑。比如说操作工说的是“这料不能多给不然老堵”你听完要在脑子里把它翻译成“给料电机连续运行超过N秒且没有检测到物料到位信号时必须停止并报警同时暂停后续工位”。这种翻译过程需要你同时理解机械动作、传感器特性、控制程序和人机交互缺一样都不行。AI 能理解文字但理解不了这些文字背后的物理世界。你跟 AI 说“料不能多给”它会给你写一个简单的定时控制但不会考虑到物料湿度变化、料斗残留、传感器检测盲区这些实际操作里的变量。这些变量不是一个标准化的逻辑能覆盖的它需要的是针对特定设备、特定环境的定制化判断。而这种判断力恰恰是从一次次调试、一次次试错、一次次和现场操作工聊出来的。3.3 沟通协调与项目推进再深入一层一个工控项目里真正让人心力交瘁的往往不是技术问题而是沟通问题。设备方有自己的想法甲方有另一套想法机械工程师提了需求电气工程师发现做不到操作工说原来的方式更好用然后这些需求要在一台设备上同时落地。作为工控工程师你得在这些矛盾中间找平衡既要让设备按照设计意图运行也要让操作员用起来顺手还要让甲方验收时挑不出大毛病。这种沟通协调能力是任何 AI 都不具备的。AI 可以帮你生成一份完美的程序注释文档但它没办法替你去甲方的会议室里面对着一群人的质疑做技术澄清。它也没办法在设备调试现场手把手地教操作工正确使用触摸屏上的每一个按钮。而这些事情每天都在工控工程师的工作中真实发生。3.4 安全与责任出了事要担责的还有一个很多人没想过的层面责任。写进 PLC 的程序是要对设备安全负责的。现场设备如果因为程序逻辑缺陷导致人员受伤电气工程师是要承担责任的。这个责任AI 承担不了也不可能承担。当你把一段 AI 生成的代码部署到现场之前你必须要用自己的专业能力为它的正确性背书。这个“背书”的过程就是你不可被替代的价值所在。说白了AI 是一个能力很强但完全没有责任意识的助手。它可以帮你干很多活但最终拍板的人必须是你。而“拍板”这个动作需要的不仅仅是技术知识更是一种对后果的担当。这种担当让工控人这个角色在可见的未来里保持着一个 AI 难以跨越的护城河。4. 把AI变成你的超级助手实操方法与提示词思路4.1 哪些场景适合让AI干活虽然上面说了这么多 AI 的局限性但这不代表它没用。恰恰相反在正确的场景里使用 AI能把我从一堆重复性工作中解放出来。根据这一段时间的实测我认为以下场景最适合让 AI 帮忙生成标准功能块代码比如模拟量滤波、单位的量程转换、PID回路的参数估算。把一段梯形图逻辑“翻译”成结构化文本或者反过来帮助理解别人写的复杂程序。批量生成报警文本、注释内容、设备操作说明书的初稿。查询某个指令的格式和参数说明省得翻半天手册。根据你给的变量表生成结构体定义、数据块模板。帮你把一个老旧项目的代码整理成带注释的可读版本便于交接和维护。这些场景有一个共同特点输入输出边界清晰需求描述明确而且生成结果需要人工复核。只要抓住这个特点AI 就能成为一台效率放大器而不是一个需要你提心吊胆的定时炸弹。4.2 怎么提问才能得到可用结果工具好不好用很大程度看你会不会提需求。我见过有人让 AI 写程序只说一句“帮我写一个水泵控制程序”结果生成的一大段代码基本没法用然后就得出结论说 AI 不行。实际上不是 AI 不行是你给的信息太少了。想让 AI 输出一个能用的结果你得把它当成一个刚来项目组、对现场一无所知但技术基础扎实的新同事把你平时交代给新人时说的那些背景信息都清晰地在提示词里表达出来。我常用的提示词模板大概长这样你是一名有十年经验的PLC控制工程师。我正在做一个【设备类型】的控制系统。硬件使用【PLC品牌系列】DI点【数量】个DO点【数量】个AI点【数量】个。 该系统需要实现以下功能 1. 【功能A具体要求】 2. 【功能B具体要求】 3. 【功能C具体要求】 特别注意 - 这台设备启动时必须确保【前序条件】否则不允许启动。 - 急停触发时需要立即【动作要求】。 - 手动模式下【限制条件】自动模式下【限制条件】。 请使用结构化文本ST语言编写以上功能逻辑包含详细注释输出格式为代码块。按照这个模板去提问AI 给出的代码可用性会显著提高。因为它有了足够的背景信息来约束自己的输出而不是天马行空地自由发挥。注意不要指望一次就能生成完整可用的代码AI 的输出更像是一个“初稿”你需要在此基础上不断追问、修正、细化。4.3 一定要复核的四件事不管 AI 生成代码的时候有多流畅你在把它放进工程之前都必须逐条核对下面的内容指令的合法性。确认它使用的每一个指令都在你当前使用的 PLC 指令集里真实存在。最直接的验证方式是复制到编程软件里做一次语法检查任何提示错误的地方都不要放过。地址和变量的准确性。核对它定义的变量名、数据类型、初始值是否与你的工程设置一致。尤其要注意它的地址是否会和现有的其它程序冲突。不要想当然地认为 AI 会自动避开你程序里已经用掉的地址范围。安全逻辑的完整性。急停、安全门、限位保护、联锁条件这些内容 AI 经常漏写或者写得过于简单。你需要对照工艺要求逐条确认程序里有没有覆盖这些关键场景。如果发现缺失必须自己补上。边界条件的处理。数据输入超量程怎么办设备运行时参数突然丢失怎么办多个条件同时满足时优先级怎么处理AI 生成的代码往往只考虑到正常情况你要主动思考异常情况下的程序行为。把这四件事做成一张检查清单每次使用 AI 生成的代码都过一遍。习惯之后整个复核过程大概只需要十几分钟但这些时间花得非常值。4.4 一个跑通的辅助案例用AI写一个带注释的功能块为了帮你更直观地理解 AI 辅助开发的过程我分享一下自己完整跑通的一个小案例。我当时需要写一个用于空压机联控的轮询启动功能块要求是四台空压机按照累计运行时间从小到大排序优先启动累计时间最短的一台以实现均衡磨损。我把需求按照上面提到的模板输入给 AI补充说明了四台设备的启动信号、停止信号、运行反馈信号、手动旁路开关等条件。AI 在几秒钟内生成了一段结构清晰的结构化文本代码包含设备数组、排序算法、启动优先级判断逻辑甚至还贴心地加上了“手动模式下跳过自动排序”的处理分支。我用编程软件打开这段代码按照当前工程使用的变量规范做了逐条匹配和调整大约花了二十分钟。然后编译、模拟测试通过。之后我把这段代码下载到现场控制器里配合实际的空压机群做联调运行效果符合预期。整个过程中AI 承担了算法设计和基础代码生成的工作而我负责把这段通用代码“焊接”到我的具体工程里。两个人的活一个人更快地干完了这就是我现在真实的工作状态。4.5 快速上手的工具选型与流程建议工具选型方面目前市面上能写代码的语言大模型对话工具不少各有各的特点。我的建议是从你最容易上手的开始用不必盲目追逐参数最大的模型。关键考察指标有三个一是能不能处理较长上下文因为你可能要贴进去一长段现有代码二是代码能力的天花板可以拿你手头某个典型功能块分别测试几家看哪家最接近能用的水平三是使用场景是否便利比如能否在编程的同时快速切换窗口查询移动端能不能随时查一下指令格式。对于工作环境比较敏感、不允许把项目代码传到外部平台的场景可以考虑使用本地部署的开源代码模型。在工控这个对保密性要求较高的行当里本地部署会让人安心许多。配置一台中等性能的电脑跑一个参数规模适中的代码模型平时查查指令、生成点标准片段也完全够用。如果你的工作对保密没有特殊要求使用在线工具往往更方便模型迭代也更快。工作流程上我建议把 AI 放在“方案设计之后、代码测试之前”的位置。先自己把控制逻辑的框架搭出来明确每一段要实现什么功能然后让 AI 去填充具体实现最后再亲自做测试验证。千万不要让它直接接管“需求到代码”的完整链路那样风险太大而且返工成本更高。5. 未来三五年工控人怎么抓住下一波机会5.1 代码生成越来越便宜你的人力价值要往哪放不用怀疑以后编写常规代码的人力成本会持续下降。是不是意味着工控人就贬值了我觉得恰恰相反。当代码生成变得便宜的时候控制方案本身的价值会进一步凸显。同样一套设备别人只能按照常规思路写一套能跑的逻辑你能设计出一套优化过生产节拍、降低能耗、延长设备寿命的控制方案这才是真正的竞争力。而方案能力的来源仍然是你对工艺的深刻理解和经验的长期积累。就像计算器普及之后会计没有消失反而从繁重的计算中解放出来去做更有价值的财务分析。AI 普及之后工控工程师也会从繁琐的代码编写中解放出来把精力更多地投入到控制方案优化、系统架构设计、设备数据分析这些更上层的环节。5.2 从“写程序的”变成“定义边界的”未来三五年我认为工控行业会逐渐分化出两类角色一类是能够驾驭 AI 工具、系统化思考的“系统架构者”另一类是只会机械地写代码、点按钮的“代码操作员”。前一类人负责定义问题边界、设计控制策略、评估风险、对最终结果负责后一类人则可能真的面临被 AI 替代的风险。这不是危言耸听。如果你每天的工作就是照着别人写好的逻辑把梯形图敲进软件里那么这种工作确实很容易被 AI 生成流程取代。但如果你能够理解设备为什么这样设计、程序为什么这样写、异常情况为什么这样处理那你就在“定义边界”的这一侧AI 只是你的工具不是你的对手。说到底AI 需要有人告诉它“做什么”和“做成什么样才算好”。这个“告诉它”的过程就是定义边界的过程。有现场经验、有工艺理解、有系统思维的工控工程师天然就是定义边界的那个人。5.3 三条值得提前铺的路如果你现在还处在焦虑中不知道从哪里下手我结合自己的观察给你三条具体的建议。第一条尽快熟悉 AI 辅助开发的流程。不用等工具成熟了再用现在就可以拿一些非关键项目练手。学会写清晰的提示词学会快速审核 AI 生成的代码建立起适合自己工作习惯的人机协作流程。这个能力越早积累你的经验优势就越大。第二条深入一到两个细分行业的工艺。与其什么设备都做一点不如选择一个行业扎进去。水处理、包装线、机床、物流输送、光伏制造随便哪个方向都可以。把某个行业的工艺细节摸透你在这个领域里的价值会远远大于你“什么都会一点”的广度价值。AI 可以随时学会写代码但它很难实时掌握某个行业里最新最深的工艺诀窍。第三条主动往数据和系统层面靠。现在的控制系统早已不只是 PLC 本身的编程问题它牵扯到数据采集、远程监控、设备联网、故障预测。如果你能在控制逻辑之外补上通讯协议、数据库、上位机、数据分析这些技能你就是那个能把控制层和信息层连接起来的人。这种复合型角色短期之内没有谁能替代得了。5.4 给新入行同学的建议最后单独对准备进入工控行业的年轻同学说几句。AI 时代入行有一个好处学习的效率可以提升一大截。你可以让 AI 帮你解释一个陌生的指令、生成一个示例程序、模拟一个控制逻辑的运行结果这可比当年我们翻手册、查资料快多了。但我还是要强调一点要亲自去现场。AI 可以帮助你写代码但不能代替你感受现场设备运行时的震动和噪音不能代替你闻电气柜里焦糊味的异常不能代替你体验故障排除成功那一刻的快感。现场经验的积累与你是否会使用 AI 无关它只能靠时间、靠实践、靠一次次踩坑慢慢沉淀。所以趁着年轻多往车间跑多动手接线多跟着老师傅调试设备这些经历会成为你职业生涯里最坚实的底子。我个人现在的习惯是先用 AI 快速生成一个方案初稿然后拉上现场的设备负责人一起过一遍逻辑再结合实际的运行习惯反复调整。AI 帮我省掉了很多重复性工作但真正决定程序好不好的仍然是那一次次现场反馈的迭代。这一点至少在可以预见的未来不会改变。