做PLC这行十几年了最近三个月工作室群里聊得最多的就是AI写程序。一开始我是拒绝的毕竟现场出问题是要跳闸停机的谁敢拿一个“聊天机器人”生成的代码往设备上怼但架不住项目催得紧某天夜里实在改不动了抱着试一试的心态把一段ST语言的需求扔给了AI工具结果它给出的框架逻辑居然像模像样。从那天起我陆陆续续把几个项目的功能块、启停逻辑、报警程序都交给AI生成再结合自己的经验去改、去验证。这三个月踩了不少坑也总结出一套能用、敢用的方法。这篇就聊聊我的真实感受AI写PLC代码到底靠不靠谱靠谱在哪儿不靠谱又在哪儿。如果你是搞自动化、搞工控的或者正准备把AI引进你们团队的工作流这篇文章应该能给你一些有价值的参考。1. AI写PLC代码到底能干什么先别急把边界画清楚1.1 它擅长的结构化文本、常见逻辑框架先从结论说起在ST语言结构化文本这个领域AI的生成能力已经达到了“能用”的水平。所谓能用是指你给它一段清晰的需求描述它能给你出一段语法基本正确、逻辑结构合理的代码帮你省掉从空白页开始敲第一行的时间。我做的最多的一类尝试是设备单体逻辑。比如水泵的星三角启动放在过去我需要从建变量、画梯形图、写互锁、加延时挨个来一套流程走下来半小时起步。而AI的生成只需要一两分钟而且逻辑上几乎没有破绽启动指令置位、主接触器和星接触器先动作、延时三秒切换三角接触器、停机复位、保护跳闸联锁——这些它都能给你写出来。它擅长的另一个点是生成标准的算法模块。滤波、平均值计算、单位换算、批量数据处理、报警阈值判断这一类的纯计算逻辑AI写起来非常干净利落。因为这类代码在互联网上的样本量大代码风格高度统一AI学得也最好。你甚至可以要求它生成符合IEC 61131-3标准的代码风格它连注释都能给你按规范补齐。1.2 它不擅长的现场硬件、时序安全、老旧设备但你要是以为AI已经能替代工程师了那就大错特错了。在几个月的使用中我碰到的最大问题就是AI对“地址空间”完全没有概念。它根本不知道你的输入模块在哪个槽位输出继电器使用了哪个字节地址更不知道你的中间变量有多少个已经占用了。你要是不提供点位表它就会自己编一个看起来特别合理的地址出来——然后你下载到PLC里轻则变量冲突重则设备误动作。再一个是时序问题。PLC的程序不是从头到尾跑一遍就完事儿它是循环扫描的。同一个变量在扫描周期的不同位置读到的是不一样的值这在AI看来是完全无法理解的。它写出来的程序在逻辑层面看不出毛病但放到实际扫描周期里会出现数据没更新就被人读走了、输出该复位没来得及复位之类的问题。这些不是靠逻辑推理能解决的而是要靠工程师对扫描周期的理解去调整。还有一个致命区老旧设备、特殊指令。你如果用的是十年前的某日系品牌老PLCAI的训练数据里根本没有那么老的指令集它给你生成出来的就不是“代码不够优化”的事儿了而是指令根本不存在。我试过用AI给一台老设备写通讯解析程序生成的代码里连指令助记符都是编造的设备压根不识别编译都过不去。所以AI写PLC代码这件事的第一课不是“它能不能写”而是“你要让它写什么”。写标准算法、写常见框架、写注释规范的ST代码它能帮你省大量时间。写地址、写时序敏感的联锁逻辑、写老平台的专属指令趁早打消这个念头。2. 我实际用AI写了什么三个项目实例复盘2.1 案例A水泵星三角启动——AI最舒服的舒适区这个程序几乎每个做自动化的人都写过。我做这个案例的初衷是测试AI在“完全不给硬件信息”的前提下能生成什么水平的东西。我给的提示大概是这样的“生成一个水泵星三角降压启动的ST程序包含手动自动模式、启动停止按钮、过载保护输入延时5秒需要互锁逻辑。输出变量是主接触器、星接触器、三角接触器。”AI返回的程序让我眼前一亮。结构非常清晰变量声明、主程序、辅助逻辑分得明明白白。电机启动保护逻辑、星三角互锁逻辑都在。但问题出在细节上它把星接触器输出和三角接触器输出写成了一个变量名的两种状态——这在逻辑上看没错但实际上星和三角是两个物理接触器必须分别控制、分别读状态。我最后花了二十分钟修改输出映射和补充手自动切换时的复位逻辑最终才下载到PLC里。这个案例的结论是AI能给你搭好框架,但框架和现场之间的“最后一公里”得你自己走过去。2.2 案例B传送带分拣计数——提示词决定一半成败这个项目是一个有三条支线的传送带分拣系统。核心需求包括主传送带启停、三个传感器检测产品通过、气缸推料分拣、计数统计、满箱停机。经过第一个案例的经验这一次我在提示词上花了更多的功夫。我没有让它“写一个分拣程序”而是给它列了一份伪需求文档包括输入输出点位清单、传感器的安装位置、气缸动作顺序、计数逻辑的边界条件。结果大不一样它生成的分拣逻辑几乎可以直接使用。传感器信号边沿触发计数、气缸动作超时报警、计数达到设定值时停止主传送带这些全部到位。这次经历让我意识到一个重要规律AI写PLC代码的水平不取决于模型本身,而取决于你给它输入了什么。你给的是“需求一句话”它给你的是“逻辑框架”你给它的是“技术规格书”它才能给你“可上线的程序”。2.3 案例CPID回路调试——AI能帮上忙但别全信PID控制是很多人觉得AI肯定搞不定的领域但实测下来它其实能提供不少帮助。我让AI帮忙生成一个温控回路的PID功能块调用框架它给出了正确的PID指令参数格式、手动自动切换逻辑、输出限幅处理、积分作用防饱和提示——这些确实是很多新手容易写错的地方。但真正让我没料到的是AI对PID参数的整定方法给出了一个非常好用的参考流程先设一个保守的P值再看曲线振荡情况调整ID值优先不给。这个方法本身并不是什么秘密但AI把判断依据讲得很清楚“曲线等幅振荡则说明增益过大”“升温过慢则增大比例带”这类对照建议对现场调试人员来说相当于有个人在旁边提醒你。当然PID的最终参数还是要靠现场试。AI能给的是方法论给不了你设备的热惯性、环境温度波动、物料湿度影响。它生成的功能块框架我用了参数整定建议我参考了但最终的参数表还是我一组一组试出来的。能帮你规划路径但走路的每一步还得自己来。3. AI写PLC代码的原理为什么能写又为什么出错3.1 它学的不是语法是海量代码里的“套路”用过AI的人都会有这种困惑它连实体的PLC都没见过它凭啥能写出逻辑正确的程序这就涉及大语言模型的基本工作原理。AI的训练数据里有大量PLC程序示例、技术手册、工控论坛问答、开源项目代码它通过对这些数据的统计分析学会了代码的“套路”。什么叫套路就是“启动按钮ON→接触器输出ON”这种强因果关联、“延时5秒→定时器指令TON”这种问题与方案的标准映射。见得多了它就能根据你描述的问题匹配出最可能的代码模式。这就是为什么常见的逻辑AI写得又快又好因为训练数据里全是这类东西。而为什么小众指令、老设备程序它容易出错因为训练数据里太少了它只能靠“猜”。理解这一点很重要。它能写不等于它理解它是在做一种高级匹配。遇到没有见过的设备型号、指令格式它的表现和没有经验的新手差不多——硬套相似逻辑结果四不像。3.2 扫描周期思维AI永远学不会的最重要一课PLC和普通计算机的程序最本质的区别就是扫描周期。计算机程序可以自己决定执行顺序而PLC是自上而下、从左到右循环扫描的程序执行完一遍后立即从头开始下一轮一轮通常是几毫秒到几十毫秒。这个特性对整个程序逻辑有深远的影响。举个例子你在程序前半段修改了一个变量的值但这个变量已经在程序后半段被之前的扫描周期读走使用了那么实际效果会比你预期的慢一个周期。再比如说一个物理按钮按下和松开的时间可能恰好卡在扫描周期的边界上软件如果没有做沿检测就会漏掉信号。AI是完全没有“扫描周期”这个概念的因为它不是靠实时运行代码来学习的。它看代码只是在看“文字之间的关联”它理解不了“这个输出在下个周期才会被这个输入影响”这种时序关系。所以AI生成的程序经常出现同一扫描周期内变量先写后读、边沿检测逻辑缺失、定时器复位位置不对这类问题这些都是不懂扫描周期的典型表现。这也是为什么我一直强调AI写的程序一定要经过有经验的工程师审查。它写的是“逻辑上的正确”你要确认的是“实时运行上的正确”。3.3 可靠性怎么评估四个层面逐层拆解用了三个月我总结出一套评估AI生成代码可靠性的方法。把它拆成四个层面逐层验证就能比较准确地判断哪些代码能直接用、哪些要修改、哪些必须推翻重写。第一层语法正确性。把生成代码直接扔进编程软件里编译能通过编译是最低标准。不过要注意有些AI生成的代码在你用的软件版本里语法能过但如果换一个软件版本就不一定了。所以我一般直接在当前项目的编程环境里编译而不是在通用编辑器里看。第二层逻辑正确性。用模拟器跑一遍把输入信号依次强制置位和复位观察输出是否符合预期。这一步能发现大部分逻辑漏洞比如互锁没锁住、状态没复位、延时没控制住。第三层工程实用性。这一步是AI最难通过的。要点包括变量命名是否符合你的规范、有没有和其他功能块共享变量冲突、有没有把不该暴露的中间变量公开出来、数据类型转换是否安全。这些是代码能不能长期维护的关键。第四层现场适配性。说白了就是下载到真实PLC里跑。这一步主要验证的是时序问题、扫描周期影响、通讯延迟、IO响应速度。AI在这个层面得分最低但它帮你搭建的代码框架恰恰又是这层验证的基础。按我的经验AI生成的代码第一层大概有80%能通过第二层降到60%第三层只有30%第四层几乎没有。但反过来看如果它第二层都能过说明这个框架是健康的基于这个框架去做适配修改比从零开始写还是要省一半以上的时间。4. 三个月踩坑实录常见问题和排查技巧4.1 经典错误速查表看了能少走弯路这三个月我收集了一堆AI生成PLC代码的典型错误。有些属于“AI界的通病”有些则非常有这个领域特色。这里做一张表方便你对照排查| 错误类型 | 具体表现 | 原因分析 | 解决办法 | | 变量凭空创造 | 代码里出现未在变量表中定义的中间变量 | AI不了解项目变量分配情况 | 提前将点位表和变量名告知AI | | 指令张冠李戴 | 某品牌的定时器指令被错写成另一品牌的格式 | 训练数据来源混杂 | 在提示词里明确标注品牌型号和软件版本 | | 地址冲突 | 生成的DB块地址与已有程序重叠 | AI完全不知道已有程序占用 | 不依赖AI管理地址分配 | | 忽略扫描周期 | 同一变量在无延时的状态下被同一周期写读 | AI不理解PLC循环扫描机制 | 人工审查所有变量读写顺序 | | 定时器复位位置错 | 复位写在生成条件里而不是独立复位逻辑 | 对定时器工作原理理解不到位 | 按标准结构重写定时器段 | | 边沿脉冲当电平用 | 把只在ON一瞬间生效的脉冲信号当长信号使用 | 不清楚BOOL信号的电平/脉冲区别 | 用模拟器检查信号形态 | | 数据类型混乱 | 把INT当BOOL用或把REAL直接传给INT指令 | 缺乏类型强制转换意识 | 在提示词中注明变量的数据类型 | | 输出重复赋值 | 同一输出变量在多处被置位和复位 | 未考虑程序执行到后面的覆盖效果 | 严格检查每路输出的赋值位置 |这张表是我三个月来最核心的收获之一。你不需要记住全部内容但如果你用AI生成代码建议把这张表贴在屏幕旁边逐项对照检查。4.2 我的验证流程模拟器、代码审查、交叉验证AI生成的代码要经过验证周期的检验我梳理了一套固定流程分享给大家参考。第一步编译验证。这个没什么可说的先把代码复制到编程软件中编译看有没有语法错误。多提一句有些AI生成的代码在ST语言里能过编译但如果你的项目混用了梯形图和ST编译时可能出现跨语言不兼容问题这种要在提示词里提前说明语言类型。第二步模拟器测试。把编译通过的程序下载到PLC仿真软件里模拟器里跑一遍全流程。我习惯的做法是把AI代码写到单独的功能块里和原有主程序做逻辑隔离然后用模拟器的强制功能依次触发输入信号观察每一步的输出变化。第三步逻辑交叉审查。这一步非常重要特别是对于没有硬件基础的AI生成的代码。我把AI生成的代码发给自己团队里另一位工程师让他以另一个角度去读。两个人都觉得没问题我才进入下一步。这个环节屡次发现AI代码里的逻辑漏洞尤其是互锁和报警复位这两类AI写错概率特别高。第四步小范围实测。选择一个不影响整个产线安全的单台设备把代码下载进去实测。通常我会先跑低电压模式或者手动模式逐步确认IO映射和动作时序确认无误之后才进入自动模式运行。这一步是检验前面所有工作的试金石也是最没法偷懒的环节。4.3 一个细节提示词质量对结果的巨大影响前面我提到相同AI工具提示词的质量直接决定了结果的可用程度。这三个月我从最简单的“帮我写个水泵程序”一路摸索到现在已经形成了一套固定的提示词模板。它大概是这样的身份设定告诉AI它是什么角色。“你是一位有15年经验的PLC工程师熟悉某品牌某型号控制器的ST语言编程规范。”环境信息交代硬件背景。“当前项目使用的是某日系品牌的某系列CPU编程软件为对应版本支持ST、梯形图和功能块图语言。”点位清单把所有输入输出的变量名、地址、数据类型、功能说明列清楚。这里一定要具体到类似“DI0.0启动按钮BOOL类型常开触点”这种颗粒度。逻辑要求把你要实现的工艺逻辑准确描述。“当启动按钮按下时如果满足所有安全条件则启动电机输出当停止按钮按下或发生故障时立即停止输出并保持停止状态直到复位。”输出格式指定AI生成的代码格式。“请使用ST语言生成变量名使用前缀命名规则输出完整的变量声明段和程序段针对关键逻辑添加中文注释注明定时器工作时长和联锁条件。”这套模板下来AI生成代码的可用率至少提升了一倍。说到底AI在工控领域的发挥上限取决于你对项目的理解程度。你越清楚要什么它就越能给你的思路补上代码。你如果自己都没想清楚逻辑AI写完你也分辨不出问题在哪里。5. 什么情况下我建议你用AI什么时候千万别用5.1 适合AI的场景和用法建议结合三个多月的实践我梳理一下哪些场景我建议大家大胆用AI。首先是程序框架搭建。任何你熟悉但不能立刻默写的标准逻辑都可以交给AI先出第一版。比如电机启停、阀门控制、报警处理、手自动切换这些逻辑成熟且统一AI生成后你只需要检查修改比自己敲快得多。其次是算法类模块。数据处理、单位转换、滤波算法、PID功能块框架、通讯报文解析这类代码结构清晰、计算规则明确AI生成质量非常高。我最近常让AI生成一些特殊算法比如移动平均值滤波、温度传感器的线性化查表处理效果相当好。第三是注释补齐和代码规范整理。AI能读懂你的代码逻辑给它一段你写好的PLC程序让它补充注释、统一命名规范、整理格式它做得又快又好。这方面的价值被很多人忽略了。维护老项目时用AI整理代码能让后接手的人少走很多弯路。第四是学习性的用途。让AI解释一段他人写的复杂代码帮你理清每个功能块的作用比翻手册快得多。我有个同事就是靠AI讲解把一段结构复杂的通讯程序吃透的。这个用法是纯收益没有什么风险。用法上我建议你把它当“高级代码助手”而不是“自动编程机器”。你负责逻辑推理、硬件匹配、安全验证它负责快速生成符合通用代码风格的底稿。双方配合效率提升最明显。5.2 绝对禁区安全逻辑和关键工艺保护讲了这么多AI能做的事接下来必须把话说死有些场景绝对不要让AI生成代码。第一类是安全回路。包括急停回路、安全门联锁、光栅保护、安全PLC相关逻辑以及任何和人身安全相关的功能性安全程序。这类代码有明确的安全标准比如ISO 13849、IEC 61508等AI连相关标准都说不清楚更不可能满足认证要求。任何涉及安全的逻辑必须以人工编写为准,AI生成的代码哪怕看着逻辑正确也必须彻底排除。第二类是核心工艺保护逻辑。比如某些不能过热的设备、动作顺序存在严格依赖关系的产线、一旦误动作会造成重大损失的程序。这些程序里的每条联锁、每个条件都是工程师用事故换来的经验AI生成的代码永远不可能理解“因为曾经撞机烧了电机所以这个位置必须加三重保护”的含义。第三类是跨设备协调逻辑。两条产线之间联动的握手协议、多个PLC之间的数据交换时序这些程序的可靠性建立在大量现场调试和工程经验之上变量之间的时序关系非常微妙远超出了AI当前的能力范围。最后再说一个很多人忽略的工艺参数和配方管理。这类代码表面上看起来不复杂但里面的数据校验、权限管理、冗余机制都是现场长期积累的成果AI生成的简化版本可能会丢失这些安全措施。这类程序宁可不改也不要去试。写在最后一个工程师和AI协作的常态三个多月用下来我对AI写PLC代码的最后看法是它不是来抢工程师饭碗的它是一个可以把我们从重复劳动里解放出来的工具。过去我写一个星三角启动程序从变量表、梯形图、互锁、仿真、改错到最后文件需要两个小时现在AI生成之后我改改适配硬件、调调时序二十分钟能搞定。省下来的时间我能用来琢磨那些真正影响产线效率的工艺细节。但这一切的前提是你必须对自己的设备了如指掌对控制逻辑有清晰理解并且愿意认认真真地做验证。AI是放大器你有经验它就帮你省时间你没经验它只会帮你快速生成一个充满隐患的程序。最后分享一个小的经验我每次让AI生成完代码都会让它再对代码做一次“风险自查”让AI以对立面视角找问题。这招虽然不能替代人工审查但经常能提前暴露一些盲区算是用AI对抗AI的一个小花招吧。