1. 从梯形图到对话栏一位老PLC工程师的“AI初体验”干了十年PLC编程我一直觉得这活儿靠的是经验和手感。画梯形图、排I/O表、调模拟量、盯时序……每一条逻辑都是拿现场设备的“脾气”换来的。所以当身边年轻人开始讨论让AI写PLC程序时我第一反应是这玩意儿能看懂我的程序才怪。结果打脸来得很快。一次赶项目客户临时要求在现有产线上加一套自动分拣逻辑。那段时间正好手上压着三个程序的调试实在抽不出空从零开始写。没办法我抱着死马当活马医的心态把需求描述扔进了AI对话窗口附带一小段我自己写的ST结构化文本作样例。本意是让它“参考格式”没想到它直接给我生成了一段完整的气缸顺序控制程序且命名风格和我给的样例高度一致。我盯着那段代码看了很久心里冒出一个词见鬼了。后来我认真测了一周把AI拉进了我熟悉的几个真实场景里三菱FX3U的485BD从站通讯、汇川H5U的轴控代码、欧姆龙NJ的ST块……得出的结论比我想象的更“现实”AI确实能写PLC程序但它不是替代你的同事而是一个“读了十年编程手册、但从来没进过车间”的助手。用得好效率翻倍用不好坑里见。这篇我就把这段时间实测的体验、踩过的坑、总结出的一套工作方式原原本本分享给同行。尤其是那些跟我一样从继电器回路一路画到结构化文本的老工程师——这篇文章就是写给你们的。2. AI写PLC程序的实测表现基础逻辑快得惊人复杂项目仍需“翻译”2.1 基础逻辑生成从需求描述到可编译代码先说最基本的场景写一段简单的电机启停、报警复位、手自动切换逻辑。这类逻辑在PLC里属于“肌肉记忆级”的活但恰恰是AI表现最稳定的领域。我测试时给的提示词是这样的请生成一段西门子S7-1200的FB块使用SCL语言。 功能电机手动/自动模式切换。 手动模式下由DI1启动、DI2停止带互锁。 自动模式下由上位机DB块中的MOTOR_AUTO_CMD触发启动 MOTOR_AUTO_STOP触发停止。 电机运行状态反馈DO1故障信号DI3触发后输出报警并停止电机。 需要互锁故障时无法手动或自动启动。AI生成的结果让我挺意外。首先变量命名是规范的MOTOR_START_CMD、MOTOR_STOP_CMD、MOTOR_FAULT这种风格其次它自动加了故障保持逻辑——手动模式下故障复位前不允许重新启动这个细节很多刚入行的人都会漏掉。代码编译一次通过下载到真实PLC上试运行逻辑行为和预期一致。需要说明的是我用的是结构化文本ST/SCL来测试而不是梯形图。原因后面细讲。如果你让AI生成梯形图它通常只能给出一种“描述性”的XML或者LAD视图文本没法直接导入GX Works或TIA Portal实用性远不如ST。这段测试让我意识到一件事AI对于“需求边界清晰、逻辑链条明确”的编程任务能力是被严重低估的。因为PLC程序的本质就是“输入条件→逻辑运算→输出动作”而大语言模型恰恰擅长在大量代码语料中学习这类映射关系。越是规整的工程代码它学得越好。2.2 复杂逻辑实测用汇川H5U写轴控程序基础逻辑过了我开始加大难度。第二个测试是汇川H5U的轴控程序。汇川的PLC这几年在包装、锂电、3C行业铺得很开InoProShop用起来和Codesys系是一路的支持ST、FBD、LD多种语言。我给它一个真实需求双轴同步追剪控制虚拟主轴从轴联动从轴跟随主轴角度运行切割位置触发凸轮动作带原点回归、软限位、报警停止AI生成的代码框架是完整且有效的电子齿轮比的MC_GearIn能对上原点回归MC_Home也写了。但有个细节问题——它把凸轮的相位偏移参数写死成了一个固定值而我现场需要的是根据产品长度由HMI实时写入。这不是什么高深的问题但我意识到一个关键点AI能读懂功能块手册上的说明却不知道“现场工况里这个参数必须由人来设定”。所以它默认选择了“最标准”的写法而标准写法在真实产线上往往是不够的。这也是为什么我说AI写的程序一定要经过一个懂工艺的人“翻译”成现场语言才能真正落地的原因。于是我继续给它补充提示凸轮相位偏移不是常量需要从HMI的寄存器D500读取 每次启动前由操作员设定。请修改代码。AI很利索地把代码改成了从D500读取赋值的方式逻辑没有破绽。这一步给我的感觉是它写代码的能力本质上是“海量编程知识库模式匹配”。只要需求表述得足够具体、足够符合工程逻辑它给出的东西就是能用的。2.3 为什么是ST语言而不是梯形图这里我要专门说一下语言选型的问题。很多PLC老工程师习惯用梯形图觉得直观、可追溯。但如果你想让AI帮你写程序ST语言是唯一现实的选择。原因有三第一ST是文本语言AI的训练数据里这类代码极多生成质量最稳定。梯形图本质上是一个图形化数据模型LD格式是XMLAI输出这类格式的能力远弱于文本而且没法直接复制粘贴到软件里编译。第二ST在主流PLC平台中的兼容性已经非常好了。西门子博途的SCL、三菱GX Works3的结构化文本、汇川/信捷等Codesys系PLC的ST、欧姆龙NJ的ST块……底层都是IEC 61131-3标准的变体语法差异主要在函数块命名和库的调用方式上逻辑写法几乎通用。第三也是最重要的一点ST更利于做代码审查。AI生成的一整段ST你逐行看过去判断它逻辑正不正确比盯着一屏梯形图找问题要快。我的习惯是让AI写ST我自己在脑内把ST“翻译”成梯形图的逻辑去审查。反向操作也行——你画梯形图有疑虑的时候丢给AI让它帮你转成ST对照着查。所以如果你还不会ST语言我认真建议你花一个月时间把它拿下。它不是用来替代梯形图的而是让你在AI时代多一条效率极高的路。3. 让AI写出真正能用的程序提示词里的“工程思维”3.1 你给的信息越“像图纸”AI给的代码越“像程序”这句话是我测试了无数次后总结出来的核心方法论。AI不像人它不会自动理解你脑子里的“现场情况”。它写出的程序好不好用取决于你给出的上下文有多具体。拿最简单的模拟量处理举例。直接说“写一个模拟量转换程序”AI给你的就是那个经典的公式工程量 int(65535) ×量程上限 - 量程下限 量程下限。这没错但没考虑采样滤波、断线检测、量程迁移更不可能知道你用的是三菱FX5U的SD630特殊寄存器还是西门子的IW64输入字。换个说法把信息补全三菱FX5U模拟量模块FX5-4AD通道1接4-20mA压力变送器 量程0-1.6MPa希望转换成0.0-1.6的REAL值用于PID控制。 采样值需要做16点滑动平均滤波断线时电流小于3.6mA 输出-1.0作为报警标志。请用ST语言写这段程序。我把这段喂给AI生成的代码非常干净数据寄存器读取、滤波循环、断线判断、工程量换算逻辑完整每个环节的注释都有。我只改了两个地方——滤波的数组索引边界检查以及把断线判断的死区从3.6mA改成了3.5mA现场变送器有温漂3.6会偶尔误触发。整体来说这个代码拿下来直接能用在项目里。这个例子的核心差异在于我把“工程语义”喂给了AI而不是“功能描述”。功能描述是“写个转换程序”工程语义是“什么PLC、什么模块、什么传感器、什么量程、什么异常工况、用在什么控制环里”。后者才是工程师脑子里的信息量也是AI快速逼近“可用代码”的关键。我列了一个我自己常用的提示词模板给各位做个参考硬件型号品牌、系列、具体模块型号编程语言ST/SCL/结构化文本功能描述这段程序要做什么输入是什么输出是什么边界条件故障怎么处理、超范围怎么处理、手动/自动模式如何切换调用方式是全局程序还是FB块有没有需要复用的变量特殊要求扫描周期、中断、通讯方式、与HMI/上位机的接口3.2 让AI学会你的命名规范和程序风格第二个让我觉得“哇这工具懂我”的测试是让AI学习我的代码风格。十年PLC编程下来每个人都有自己的习惯我喜欢用UINT做状态位、状态机用十位数的数字编号10待机20运行中30故障、报警输出统一用一个BYTE整包上传给HMI。这些风格在技术文档里找不到但它们是我调试效率的来源。我跟AI明确说了这些偏好后它生成的代码里自动带上了我的命名习惯。比如VAR stWord : BOOL; (* 待机状态 *) stRun : BOOL; (* 运行状态 *) stFlt : BOOL; (* 故障状态 *) nAlmByte : BYTE; (* 报警聚合字节 *) END_VAR原来得自己逐行写的状态机切换逻辑AI一次就给我搭好了框架。我省下来的时间花在了更值钱的地方——准确判断设备的工艺动作顺序是否符合机械设计意图。所以我的建议是花十分钟把你的程序风格和命名规则整理成文字存成一个固定的“风格提示词”每次都贴给它。AI会越来越“像你”你审代码的速度也会越来越快。3.3 一个我经常用的“AI辅助审查”流程除了让AI写代码我更喜欢用它做“代码审查”。这个用法可能更适合同行老手你写好了程序但怕某个逻辑有疏漏把代码粘给AI问它“这样的逻辑在什么情况下会出问题”实测效果非常好。有一次我写了一个三菱FX3U通过485BD做Modbus RTU从站的通讯程序数据交换格式是自己定义的。AI很快就点出两个问题一是保持寄存器和输入寄存器的起始地址跨越了Modbus协议的功能码边界二是在通讯异常时我没有对接收缓冲区做超时清理可能导致下一次通讯粘包。这两个问题确实存在。第一个是协议理解问题第二个是工程经验问题。它们在现场不会立刻爆发但运行一个月后就会变成“偶发通讯故障”这种最难查的疑难杂症。AI在代码审查上的能力某种程度上强于写代码的能力因为它能读取海量故障案例数据见过的坑比我多。我还做过一个实验把一份包含“隐藏bug”的程序贴上注释“这段程序有问题请找出潜在逻辑漏洞”AI成功揪出了80%的问题——包括一个在特定条件下会让输出线圈双重赋值的神级隐藏坑。这个能力说实话比大多数第一年新人的代码审查水平要高。4. AI的局限与翻车现场那些不能交给AI的事4.1 硬件地址与设备固有逻辑AI最容易“张冠李戴”AI不是万能的我遇到的第一个大坑出在硬件地址上。有一次我让AI写欧姆龙NJ的模拟量处理程序PLC的输入是NJ的模拟量模块但我偷懒没有明确告诉AI模块的具体型号和通道分配方式。AI直接给我编了一个它“认为合理”的地址——%IW0.2照搬照抄时误以为是通道2实际上是模块槽位2。这类问题几乎每次测都会遇到。AI不会知道你现场模块装在哪个槽、远程I/O站的地图范围、通讯模块占用的地址区段。这些信息它不可能“推理”出来只能靠你提供。我的处理习惯是凡是涉及硬件地址、通道映射、通讯协议配置的部分一律在提示词里写死在最开始输入模块NJ系列的CJ1W-AD041-V1槽位3 输入地址%IW3.0第1通道%IW3.1第2通道 模拟量输入规格0-10V量程对应0-400016位这样AI生成的代码基本不需要改地址部分。如果你自己都不确定地址那正确做法是先去查I/O分配表而不是问AI——这就属于“工具之外的基本功”。4.2 现场工艺与机械逻辑AI能给你代码给不了你“手感”第二个局限性是工艺理解。我让AI写过一个追剪凸轮的程序它写出来的MC_CamIn语法完全正确联动逻辑也没有问题。但它默认把“从轴跟随主轴同步段”设成了360度整圈同步而实际追剪设备需要的是“异步进给→同步追剪→快速回退”三段式凸轮曲线。这不是AI逻辑不行而是它不知道这台设备是怎么工作的。凸轮曲线要在哪个角度范围锁定同步、哪个角度范围快速回退、加减速的平滑曲线怎么设计——这些信息藏在机械图纸和老师傅的调试经验里AI读不到。但这不代表没用。我的做法是让AI生成一段“标准的凸轮程序模板”我自己在模板基础上按实际设备曲线修改关键角度值。相当于AI给了我一个空房子我按自己的尺寸来装修。它的价值是把编程时间压缩了而不是替你完成工艺设计。所以如果你是完全没有民建自动化调试经验的新人我不建议你直接信AI写的工艺程序就去现场跑。看懂程序和懂现场设备永远是两个维度的事。4.3 通讯配置与数据格式AI帮你写代码你帮AI理解报文Modbus、MC协议、EtherCAT、CC-Link……通讯程序是PLC编程里最磨人的部分。我实测了AI在三菱FX3U485BD做Modbus RTU从站、西门子S7-1200做Modbus TCP客户端等场景下的表现结论是AI对标准协议非常精通对“协议细节的非标准用法”理解很差。比如用FX3U的485BD板做RTU从站寄存器映射范围需要设置特殊寄存器D8400系列AI第一次给的代码把从站站号写进了D8121方向切换的时间参数用默认值这对于大多数应用虽然是标准做法但现场调试时往往需要动态修改从站地址而AI不会自动想到这一点。更麻烦的是如果你用的设备支持的是“半标准”协议比如国产仪表定制的Modbus地址映射AI给出的报文解析代码基本不能直接用。我测试过让AI写一个读取温控表当前温度的Modbus报文它能正确写出03功能码和CRC校验但寄存器地址若从十进制转十六进制时算错——表格上的地址是40001其实对应的是PLC里的0x0000它却写了0x0001。这就是典型的“AI不理解设备手册与实际寄存器偏移的关系”。所以通讯类程序的正确合作方式是你负责查设备手册确认寄存器地址映射表AI负责写CRC校验、报文组帧、超时重试逻辑这些底层琐碎你再把两边拼起来做整体联调4.4 一个完整的“翻车到补救”案例气缸顺序控制最后分享一个印象最深的翻车案例。我让AI写一个双气缸顺序控制程序A缸伸出→B缸伸出→B缸退回→A缸退回带光电传感器到位确认它一次就写出了可靠的状态机代码。但我下载到现场后发现A缸伸出的同时B缸电磁阀线圈竟然“闪”了一下。查了半天最后定位到问题AI把B缸的输出地址写成了和A缸定时器中间变量的地址“同名”——它生成的代码里定义了一个共享字变量作为计时器的适应区但同时又把该变量的低字节直接映射到了B缸的物理输出Q点。原因是我在提示词里给了输出点分配表但没强调这是“独立的物理输出区”AI就在变量区域优化时把它们重叠了。这个问题的本质不是AI笨而是“物理输出点值”和“程序中间变量”的隔离靠程序员脑子里根深蒂固的“I/O表纪律”来保证。AI没有这个“肌肉记忆”它只会在你给的信息边界内选择最省事的写法。我给的提示词是“输出Y0控制A缸电磁阀输出Y1控制B缸电磁阀”它是照做了——但另一头它定义了一个结构体变量其内部偏移恰好撞上了Y1的地址。解决方案倒是很简单生成代码后我自己全局搜索一遍“OUT”类指令逐个确认物理输出地址没有重复。这个习惯以前就有现在和AI协作后变得更加必不可少。5. 老工程师与新工具的协同方式我的“半天写完一周程序”工作流5.1 我的AI协作工作流测试了一段时间之后我总结出了一套在真实项目里固定下来的工作流现在基本每个项目都按这个节奏走第一步手工整理I/O表和工艺时序图。这是AI时代唯一完全不能省略的环节。我用Excel列好所有I/O分配模块号、通道号、PLC地址、传感器类型、对应气缸/电机/阀岛编号。工艺时序用一个简单的流程图加文字描述写清楚。第二步把I/O表和工艺描述粘贴给AI附上明确的编程要求让它把程序框架搭起来。这一步核心是让AI生成FB/FC的块结构、变量声明、以及各块之间的调用关系。第三步逐块审查和修改AI生成的代码。我速度快的时候一个普通项目200-300个点位30来个FB块两个多小时能审完全部代码。审查重点物理输出地址是否重复、定时器是否越界、通讯功能块的执行条件是否安全。第四步把确认过的程序下载到PLC用仿真或在线模拟验证一遍关键逻辑。我习惯先让AI检查逻辑漏洞再自己运行在线监控配合强制功能走一遍关键节点的时序。这套流程用下来最直观的变化是一个常规的改造项目之前我写程序自查就要两到三天现在基本一天搞定。省下来的时间我用来做以前顾不上做的事——HMI画面的操作权限分配、报警文本的重新组织、电缆标签核对。这些平时“不重要但影响体验”的活儿反而让我在项目验收时收到不少好评。5.2 AI不适用的场景这些程序求你别省事有几类程序我是坚决不让AI代笔的安全回路类急停、安全门、光幕联锁。这类逻辑涉及人身安全逻辑再简单也要自己手写且必须在多人审查后通过。AI生成的安全程序你没法从“责任”角度对它问责。极高速逻辑伺服中断处理、电子凸轮高速区段修正、扫描周期严格限定的任务。AI生成的代码往往会在循环里不经意加入延时较大的操作或者变量类型选择不优化访问效率这些在普通低速逻辑里毫无影响在高速场合就可能导致扫描周期波动。你自己都搞不清楚的工艺段这一步的逻辑如果是靠现场师傅“试出来”的先把工艺摸明白再提AI的事。AI不会比师傅更懂你的设备这种场景输给AI就是两边都瞎。老旧PLC的特殊指令集AI对十年前的FX2N、C200H这类老平台里的专用指令和特殊寄存器理解的精度会下降。它训练语料里这类内容相对少而且不同批次固件的特殊寄存器定义有差异AI区分不了。这类老平台程序我会自己写让AI做逻辑审查就够了。5.3 AI是“读手册的助手”不是“懂现场的师傅”如果你问我让AI写PLC程序的最大意义是什么我的答案是它把“写代码”的时间成本大大压缩了让我有更多精力放到“读设备、读工艺、读现场”上去。干PLC这行的人都知道编程从来不是最难的。最难的是搞清楚机械手爪到位信号的抖动是传感器问题还是气缸缓冲不足是上位机发来的启动指令时序不对还是PLC扫描周期恰好错过了信号。这些判断AI给不了任何工具都给不了。它靠的是你在车间里蹲出来的经验——这台设备运行时的声音、震动、温度都在替你说谎和作证。所以我把AI定位成“一个读了十年编程手册的助手”协议格式、语法细节、常见逻辑模式它比我记得全但哪台设备的行程开关该加滤波延时、哪个阀的线圈要加续流二极管它永远不如我清楚。这种分工我觉得是健康的。编程时间少了调试时间没变但我的精力分配变了。以前写程序写到手抖现在写程序像“审核图纸”反而感觉对程序的理解更清晰了。6. 给同为老PLC工程师的几点实在建议6.1 半个月适应期怎么过如果你是传统梯形图派的工程师刚开始用AI写ST肯定有“不如自己画得快”的阶段。这很正常。我的建议是别一上来就拿真正赶的项目的核心功能试水。先拿旧项目的非关键部件练手比如报警聚合、数据记录、配方管理这类模块在仿真里反复下载测试强迫自己适应“描述需求→生成代码→审查修改”这个新节奏。大概过两周你就能体会到好处了。因为ST语言在表达复杂逻辑时本来就比梯形图清晰AI生成ST的高效率和你的审查经验结合会让“写程序”这个环节在项目里所占的时间比例明显降低。6.2 提示词里务必写死的五件事以下是我多次翻车后总结出的“必须写死清单”每次生成代码前逐项确认PLC品牌和具体型号三菱FX5U、西门子S7-1500、汇川H5U等编程软件版本会影响函数块格式编程语言ST/SCL/结构化文本不要让它自由选择所有硬件地址分配表物理I/O地址、模块槽位、通讯站号特殊要求扫描时间限制、是否需要可复用的FB块、手动/自动切换规则这五件事写清楚AI生成的代码基本在“可用”和“比较好改”之间。偷懒少写一个后面就是多返工一小时。6.3 争议话题AI会让PLC程序员失业吗这个问题最近总被问到。我的看法是AI会淘汰的是“只会照着教科书翻译逻辑的初级程序员”——那种遇到问题先翻手册、手册里没有就停住不动的人。但PLC程序员的真正价值从来不只是“能把梯形图画对”而是“能判断现场为什么和图纸不一样”。产线调试的真相是图纸和接线从来没完全一致过传感器反馈也不会永远准时。AI能在你输入“设备不动”这个问题时帮你定位到程序里某个中间变量的状态不合理。但它不会替你爬到十九米的桁架上查那个接近开关的感应面是不是被铁屑糊住了。所以与其问AI会不会让我们失业不如问自己一个问题我是那个只会写程序的人还是那个懂整台设备的人答案是后者的工程师AI只会让你更值钱——因为你省出来的时间都花在了别人替代不了的地方。6.4 最后一个小习惯分享每次用AI生成完代码我都会额外做一件事让它为这段代码写一份“现场调试注意事项”清单——它通常会列出需要检查的接线端子号、可能出现的干扰源、以及每个参数变化的时间曲线特征。这个清单我会打印出来夹在项目资料里带进车间调试时对照着检查发现挺管用。我以前写程序从不自己写测试用例现在AI给了这份便利也不该浪费。程序要是有问题能快速定位要是没有问题这份清单也算给后续维护的人留了一份“前人经验”。这算是这段时间和AI协作下来我收获最大的副产品了。