干了十年PLC编程最近开始让AI替我写程序。这话放两年前我自己都不信。干PLC这行的都知道工控圈对新技术向来慢半拍什么云平台、工业互联网喊了好几年落到车间里还是梯形图那一套。我一开始也觉得AI写代码就是个噱头IT圈玩的东西跟我们这种跟继电器、变频器、现场仪表打交道的没关系。直到去年接了个改造项目三台水泵加一套管网压力控制光捋老程序的地址就花了我一下午我抱着试试看的心态让AI帮我把一段设备手册里的PID逻辑翻译成结构化文本——三分钟出来的代码居然能直接粘进Codesys里编译通过连数据类型都给我匹配好了。那一下我才反应过来这玩意儿是真能帮上忙的。这篇文章我不想讲什么高深理论就从一个干了十年的PLC工程师角度聊聊我实际用AI写PLC程序的经历哪些场景真的省时间怎么把需求喂给AI让它交出能用的代码以及它最容易在哪里挖坑。给那些还在观望、或者已经试过但觉得AI“不靠谱”的同行的参考。1. 先看症结PLC编程最耗时间的从来不是“写代码”本身很多人一听“让AI写PLC程序”第一反应是“AI连梯形图都看不懂吧”。这话一半对一半错。PLC编程这事儿跟互联网写代码不一样的地方在于它的工作量大头根本不在敲代码那一步。PLC项目里真正吃时间的环节梳理下来无非这五块一是工艺逻辑的拆解甲方给你一张流程图上面写“液位高开泵、低停泵、中位允许投运”你得把它翻译成状态表、联锁条件、时序关系二是IO点表的整理和地址分配几百个点对到PLC模块上DI、DO、AI、AO哪个点接什么传感器什么量程有没有备用点三是安全联锁逻辑的编写急停、超限、互锁、断电保持这些逻辑占了程序的小一半但每一行都得慎之又慎四是标准化和注释公司没强制的话绝大多数老程序的注释都惨不忍睹五是调试阶段的修改现场试车有问题你得对着监控表一个一个查逻辑。这五块里真正需要“写指令”的时间可能只占百分之二三十。剩下的是需求理解、逻辑设计、验证排查。所以我用AI也不是冲着“让AI把代码全包了”去的而是让它把我最烦躁的那几件事接过去——把中文控制逻辑转成结构化程序骨架、给老代码补注释、根据故障现象生成排查思路。这些事AI干得又快又稳定而且不会跟我在交付节点上闹脾气。2. 我实际用AI干了这几件事每件都踩出了经验2.1 把“工艺描述”变成ST语言代码骨架PLC编程的主流语言除了梯形图之外IEC 61131-3标准里的结构化文本ST其实更适合AI生成因为它像简化版的Pascal逻辑表达直白。我最常用的做法是把控制要求像写需求说明书一样丢给AI让它生成功能块的ST代码。举个例子我常做的一类逻辑是“手自动切换”。手动模式下要求单台启停自动模式下要求按压力联锁。放在以前我得从老项目里复制一段改改或者从头敲框架。现在我会这么描述给AI我有一个恒压供水控制功能块使用Codesys ST语言编写。输入DI_HandAuto手动自动选择、DI_StartBtn、DI_StopBtn、DI_PumpOnline、模拟量AI_Pressure输出DO_PumpRun。逻辑要求手动模式下启动按钮置位泵运行输出停止按钮复位自动模式下压力低于1.5MPa开泵高于2.2MPa停泵手动自动切换时运行状态保持不能有瞬间停泵。变量命名使用前缀DI_DO_AI_AO。AI给出来的结果基本就是能直接拿去改改地址就用的骨架代码。结构干净、命名一致注释都按我的习惯写好了。这种“半成品”对我的价值最大因为功能块的框架、变量声明、注释规范这些基础工作AI干得比多数初级工程师还规矩。2.2 给老代码“补课”注释和逻辑梳理我手上有不少十年前的老程序三菱GX Works打开的工程梯形图连成一片变量名全是D0、M100、Y0这种。让AI理解这种程序意义不大但让AI把注释补上、把逻辑关系用文字复述出来效果出奇得好。具体做法是把程序段导出成文本格式GX Works支持导出CSV指令表博途可以导出ST或者SCL源码然后喂给AI“这是一段三菱PLC程序请分析每个网络的作用用中文注释说明输出Y0在什么条件下置位什么条件下复位。”AI返回就是逐段的分析说明我再把这些说明手工填回程序注释里。几百行的程序大概半小时搞定换成我自己啃一个上午可能就没了。2.3 故障排查AI当“外置大脑”给排查方向还有一类用法更适合现场就是排故。调试的时候遇到一个诡异问题——比如“西门子博途里CPU的M区在断电后某些位没有保持但已经勾选了保持功能”。把报错信息和现象发给AI它能快速列出排查清单检查保持性存储区有没有冲突、是否用了非保持的M区默认设置、断电瞬间电容放电是否完整等等。虽然AI不会像老师傅一样看一眼就知道“你设置错在哪个字节”但它能把你可能忽略的盲区给你兜一遍。尤其面对冷门型号或者不常用的功能这种穷举式提醒比翻手册快多了。2.4 标准化模板和设备选型辅助AI在“套路化内容生成”上确实很强。以前写设备说明、操作手册里的程序流程说明都要从旧文档里复制粘贴改一改。现在我可以把IO点表、控制逻辑概要丢给AI让它生成一份操作说明书初稿结构和上下文基本不用大改。再比如选型时把工艺参数流量、扬程、电机功率丢给AI让它按ABB或者西门子产品线给出变频器建议型号虽然不能盲信但用来圈定范围非常省事。这里必须说明一下AI给出来的代码和建议定位永远是“初稿”或“参考”不是“终稿”。别直接下现场也别直接交付。这不是信不过AI而是逻辑太紧了。3. 一套能落地的提示词模板以及我怎么校验AI的输出很多人试过让AI写PLC程序结果发现出来的代码要么语法不对、要么逻辑“想当然”。问题多半出在需求描述不够具体。PLC程序的特点是强约束、强时序、强安全给AI的信息越模糊它猜得越离谱。我来分享一个我自己调了好几版才定下来的提示词结构。3.1 一套可复用的AI编程提示词模板我的提示词固定分五段写角色设定你是一个有15年经验的PLC自动化工程师熟悉IEC 61131-3标准精通西门子博途SCL、Codesys ST、三菱GX Works的ST语言。硬件环境PLC品牌和软件平台举例Codesys V3.5 SP19目标CPU是倍福CX5120IO模块型号和地址起始位置通信方式Profinet、Modbus等。IO信号表全部输入输出以明确的表格或列表形式给出包括信号名、数据类型、地址、量程、点位说明。控制逻辑要求按条件逐条写清楚包括优先级、联锁、延时、保持、手自动切换规则、故障处理规则。要明确说“如果有冲突逻辑以安全条件优先”。输出要求使用ST语言命名规范按“前缀_描述”给关键段加注释给出容易遇到的上电初始化说明。下面是我最近做的一个“双泵恒压供水”功能块的提示词实例。你是一个有15年经验的PLC自动化工程师熟悉IEC 61131-3标准擅长Codesys ST语言编程。 项目环境Codesys V3.5 SP20PLC为倍福CX5120AI模块地址IW0DI模块地址IX1.0起DO模块地址QX2.0起。 IO说明 AI_Pressure AT %IW0 : WORD; // 压力变送器4-20mA对应0-1.6MPa DI_Fault1 AT %IX1.0 : BOOL; // 1#泵故障信号 DI_Fault2 AT %IX1.1 : BOOL; // 2#泵故障信号 DI_LevelLow AT %IX1.2 : BOOL; // 水池低液位 DO_Pump1 AT %QX2.0 : BOOL; // 1#泵接触器 DO_Pump2 AT %QX2.1 : BOOL; // 2#泵接触器 控制要求 1. 两泵一用一备默认1#泵启动每运行24小时自动轮换一次。 2. 自动模式压力低于1.2MPa启动当前泵压力高于1.5MPa停止当前泵。 3. 运行中如果当前泵故障立即停当前泵自动切换备用泵启动。 4. 水池低液位时禁止启动任何泵运行中低液位强制停止所有泵。 5. 泵启停间隔不小于5秒防止频繁启停。 6. 任何情况下DI_Fault状态同时只能启动一台泵。 输出要求使用ST语言实现变量前缀保持IO中定义的命名写出完整的变量声明和逻辑体注释用中文并提示上电初始状态处理。这个提示词的核心不在于“让AI生成程序”而在于把我脑子里的控制规则完整地倒给它。你会发现写这个提示词本身其实也是在帮我自己理清控制需求。很多时候我写完需求描述代码逻辑怎么组织已经清楚了大半AI只是替我敲键盘。3.2 拿到AI代码后必做的三轮修改AI生成代码后我从来不会直接粘进工程。第一轮先把地址替换成实际PLC硬件组态里的绝对地址或者符号路径。AI生成的代码里地址是它自己推的跟我的站点不一定对应这步是必须的。第二轮把安全联锁逻辑抽出来单独检查确保急停、超限、互锁的优先级在任何情况下都不会被绕过。第三轮补上时序和初始化逻辑比如首次上电时的状态复位、故障自保持、手自动切换时的瞬时脉冲处理。有朋友问过我这么改下来跟自己写还有多少区别说实话如果程序很小区别不大。但中大型程序AI给初稿的价值在于省去了变量声明、命名规范、结构框架这些重复劳动我只需要聚焦在逻辑验证上。单位时间里的产出质量明显不一样这才是它值得用的地方。4. 别高兴太早AI在PLC领域最常见的五类翻车现场用了大半年我确实被AI坑过几次而且坑得很有“AI特色”。不了解这些坑你很容易在项目紧要关头被摆一道。我总结成五类每个都是实际见过的。4.1 地址和符号表“幻觉”AI最喜欢干的事情之一是煞有介事地编造地址。你问它“把这段程序改成AT %MD10”它会很自然地用%MW10、%MD0这种它觉得“合理”的地址。问题是PLC地址跟内存区域强相关一旦地址错位轻则读写冲突重则覆盖别的功能块数据。尤其是西门子博途的符号寻址AI给出的全局变量名经常跟项目里已有的DB块变量冲突编译过不去还算好的编译过去了跑飞了才是大问题。规避办法很简单在提示词里明确要求“不使用自动分配的地址地址以我提供的IO表为准”并且在拿到代码后逐一核对地址声明。这一步没有捷径。4.2 数据类型的“想当然”PLC的数据类型比通用编程严格得多。AI从互联网语料里学了很多高级语言习惯最容易踩的坑就是拿INT当BOOL用、拿REAL当TIME用、延时直接写TON(IN:条件, PT:5)——在Codesys里PT是TIME类型5会被编译报错AI不知道T#5s这种PLC特有的时间字面量。反过来在博途SCL里时间要写T#5S或DINT转TIMEAI经常弄混。这类问题好在编译阶段就能暴露不算最危险的。最烦的是隐式转换能过编译但精度和溢出有问题。比如用WORD存模拟量转换结果然后直接跟REAL比较虽然能跑但偶尔出一个很奇怪的值。见到这类代码我一般都让AI改用类型转换函数或者在变量声明里严格使用INTERNAL类型。4.3 对扫描周期和时序的理解偏差PLC是循环扫描执行的同一个程序段的输出在下一个周期才生效。AI写循环和跳转逻辑时有时候会把通用编程里的“函数调用返回”思路带进来。比如它可能写出这样的代码// AI生成的“有问题版本” IF Start THEN PumpRun : TRUE; END_IF; IF PumpRun THEN Step : Step 1; END_IF;初看没问题但它没有考虑Step在同一个扫描周期里被重复执行或者某些情况下PumpRun刚置位就进入下一步导致错位。这种时序问题不跑仿真很难看出来。我现在会让AI在生成代码时“显式区分组合逻辑和时序逻辑”手动把状态机部分拆开一步一状态不给它自由发挥的余地。4.4 安全联锁被“以人为本”地简化这可能是最危险的一类。AI在生成逻辑时倾向于“按正常流程写”对安全需求的重视程度不够。举个例子我之前让AI生成一个“电机正转反转互锁”的功能块它给的逻辑是正转输出和反转输出互斥条件正转启动按钮或者反转启动按钮。看似没错但它漏掉了一个关键场景正转运行中按下反转按钮两条输出会瞬间同时导通吗按它的逻辑互锁是条件互斥不是输出互斥结果现场就可能炸接触器。我赶紧改了把互锁写成输出之间的硬互锁再加软互锁同时把急停复位状态放到最高优先级。经验是AI的代码安全联锁必须单独做“对赌式检查”——你假设它的逻辑可能藏着一个极端场景然后逐条验证“如果传感器断线会怎样”“如果急停拍下会怎样”“如果两个命令同时来会怎样”。这三点能过基本就稳了。4.5 品牌指令集张冠李戴不同品牌的PLC指令集差异非常大。三菱的SET/RST西门子的S/R赋值Codesys的TON实例是功能块实例博途的TON则更像IEC标准调用。AI如果没有被强约束很容易把三菱的写法带到西门子里。比如在三菱里写SET M0AI生成到西门子SCL就变成M0 : TRUE这个还好但反过来把西门子的#Temp局部变量类型语法用到Codesys里编译报错都找不到地方。解决的办法提示词里明确注明星鼎平台语言版本并且让AI对不确定的指令标注“待确认”。我甚至试过让它把三菱的ST逻辑先翻译成伪代码再手写翻译到博途比直接跨品牌翻译准确率高得多。5. 人机分工我现在的工作节奏和验收流程AI这东西对我最大的改变不是“写代码变快了”而是干活节奏变了。以前是“先想后写”有时候懒得想先写再改。现在是“先把需求讲清楚再让AI打草稿最后我审稿”。这个节奏逼着我养成了一种更好的习惯需求不明确的前提题词给AI再多描述也生成不出像样的东西。我现在的标准工作流是这样的第一步整理IO点表和工艺描述这一步永远是我的活不可能交给AI。因为AI不知道现场到底装了什么传感器不知道甲方习惯在HMI上叫什么名字。信息源头准确后面才有意义。第二步用第3节那个模板把控制逻辑按条目写清楚喂给AI让它在ST/SCL里生成初稿。这一步我通常会给两台不同的AI工具同时生成拿来对比互相当裁判。两个版本会暴露各自的盲区合起来看往往能发现单个版本里不容易注意到的边界问题。第三步人工审稿编译。地址核对、安全联锁检查、类型检查、时序推演都是我列成清单逐项过。这个清单我贴出来给你参考[ ] 所有变量地址和符号名与IO点表一一对应[ ] 所有安全联锁急停/超限/互锁/启动条件优先级最高不能被自动逻辑绕过[ ] 时间参数延时/定时器类型与平台匹配[ ] 手自动切换不会产生输出抖动或瞬断[ ] 上电初始化有明确的状态复位[ ] 故障自保持与复位逻辑闭环[ ] 每一个定时器/计数器实例名唯一第四步用PLC的仿真功能跑一遍逻辑或者接上小功率设备做点动验证。不到万不得已我不用仿真代替现场但仿真能抓出80%的时序问题。这套流程下来AI负责的是“量”把一大堆框架代码、注释、初稿批量生成我负责的是“质”把安全、时序、工艺这些真正值钱的东西抠死。人机之间没有谁替代谁反而互补得挺好。6. 再往后走我对AI和PLC工程师关系的看法很多同行担心AI会把PLC工程师搞失业。我自己用了大半年反而觉得不会。PLC这行的门槛根本不在“会不会写ST”而在“有没有在现场摸过设备、懂不懂工艺到底要什么”。AI能把代码写得像模像样但它不知道水泵汽蚀余量是什么不知道接触器触点粘连会有什么后果不知道甲方说的“压力波动不能太大”到底是多少算大。这些判断力AI暂时给不了。但我必须承认AI正在把行业门槛拉平。以前一个新工程师要攒两年经验才敢独立写复杂功能块现在借助AI半年可能就可以了。这种趋势下真正值钱的技能会越来越往“需求拆解、工艺理解、现场调试、安全兜底”这几个方向上集中。我甚至觉得未来招人我反而不在意他背了多少指令而是看重他能不能把一套复杂的工艺讲清楚、能不能拿着AI给的初稿挑出逻辑漏洞。这是好事也不是好事——好事是行业效率会整体提升不太好的是中间层混日子的空间会被压缩。最后说点实操层面的建议。如果你打算开始用AI辅助PLC编程先从三类需求开始一是让AI把你的中文工艺描述转成ST框架代码二是让AI给老程序补注释和说明文档三是让AI帮你想排查思路。这三件事见效最快也不太容易出大安全问题。等跑顺了再加到代码生成和仿真验证上。一开始别碰涉及安全等级极高的逻辑比如安全回路、硬互锁、紧急停车这些还是老老实实手写。等到你对AI的风格和坑足够熟悉了再逐步扩大应用范围。这是我踩了大半年坑之后最想说的一句话AI是来帮你加班的不是来替你担责的。代码最后敲下去的人是你现场出事站出去的那个人也是你。 AI辅助PLC编程实践：老工程师的经验与避坑指南
干了十年PLC编程最近开始让AI替我写程序。这话放两年前我自己都不信。干PLC这行的都知道工控圈对新技术向来慢半拍什么云平台、工业互联网喊了好几年落到车间里还是梯形图那一套。我一开始也觉得AI写代码就是个噱头IT圈玩的东西跟我们这种跟继电器、变频器、现场仪表打交道的没关系。直到去年接了个改造项目三台水泵加一套管网压力控制光捋老程序的地址就花了我一下午我抱着试试看的心态让AI帮我把一段设备手册里的PID逻辑翻译成结构化文本——三分钟出来的代码居然能直接粘进Codesys里编译通过连数据类型都给我匹配好了。那一下我才反应过来这玩意儿是真能帮上忙的。这篇文章我不想讲什么高深理论就从一个干了十年的PLC工程师角度聊聊我实际用AI写PLC程序的经历哪些场景真的省时间怎么把需求喂给AI让它交出能用的代码以及它最容易在哪里挖坑。给那些还在观望、或者已经试过但觉得AI“不靠谱”的同行的参考。1. 先看症结PLC编程最耗时间的从来不是“写代码”本身很多人一听“让AI写PLC程序”第一反应是“AI连梯形图都看不懂吧”。这话一半对一半错。PLC编程这事儿跟互联网写代码不一样的地方在于它的工作量大头根本不在敲代码那一步。PLC项目里真正吃时间的环节梳理下来无非这五块一是工艺逻辑的拆解甲方给你一张流程图上面写“液位高开泵、低停泵、中位允许投运”你得把它翻译成状态表、联锁条件、时序关系二是IO点表的整理和地址分配几百个点对到PLC模块上DI、DO、AI、AO哪个点接什么传感器什么量程有没有备用点三是安全联锁逻辑的编写急停、超限、互锁、断电保持这些逻辑占了程序的小一半但每一行都得慎之又慎四是标准化和注释公司没强制的话绝大多数老程序的注释都惨不忍睹五是调试阶段的修改现场试车有问题你得对着监控表一个一个查逻辑。这五块里真正需要“写指令”的时间可能只占百分之二三十。剩下的是需求理解、逻辑设计、验证排查。所以我用AI也不是冲着“让AI把代码全包了”去的而是让它把我最烦躁的那几件事接过去——把中文控制逻辑转成结构化程序骨架、给老代码补注释、根据故障现象生成排查思路。这些事AI干得又快又稳定而且不会跟我在交付节点上闹脾气。2. 我实际用AI干了这几件事每件都踩出了经验2.1 把“工艺描述”变成ST语言代码骨架PLC编程的主流语言除了梯形图之外IEC 61131-3标准里的结构化文本ST其实更适合AI生成因为它像简化版的Pascal逻辑表达直白。我最常用的做法是把控制要求像写需求说明书一样丢给AI让它生成功能块的ST代码。举个例子我常做的一类逻辑是“手自动切换”。手动模式下要求单台启停自动模式下要求按压力联锁。放在以前我得从老项目里复制一段改改或者从头敲框架。现在我会这么描述给AI我有一个恒压供水控制功能块使用Codesys ST语言编写。输入DI_HandAuto手动自动选择、DI_StartBtn、DI_StopBtn、DI_PumpOnline、模拟量AI_Pressure输出DO_PumpRun。逻辑要求手动模式下启动按钮置位泵运行输出停止按钮复位自动模式下压力低于1.5MPa开泵高于2.2MPa停泵手动自动切换时运行状态保持不能有瞬间停泵。变量命名使用前缀DI_DO_AI_AO。AI给出来的结果基本就是能直接拿去改改地址就用的骨架代码。结构干净、命名一致注释都按我的习惯写好了。这种“半成品”对我的价值最大因为功能块的框架、变量声明、注释规范这些基础工作AI干得比多数初级工程师还规矩。2.2 给老代码“补课”注释和逻辑梳理我手上有不少十年前的老程序三菱GX Works打开的工程梯形图连成一片变量名全是D0、M100、Y0这种。让AI理解这种程序意义不大但让AI把注释补上、把逻辑关系用文字复述出来效果出奇得好。具体做法是把程序段导出成文本格式GX Works支持导出CSV指令表博途可以导出ST或者SCL源码然后喂给AI“这是一段三菱PLC程序请分析每个网络的作用用中文注释说明输出Y0在什么条件下置位什么条件下复位。”AI返回就是逐段的分析说明我再把这些说明手工填回程序注释里。几百行的程序大概半小时搞定换成我自己啃一个上午可能就没了。2.3 故障排查AI当“外置大脑”给排查方向还有一类用法更适合现场就是排故。调试的时候遇到一个诡异问题——比如“西门子博途里CPU的M区在断电后某些位没有保持但已经勾选了保持功能”。把报错信息和现象发给AI它能快速列出排查清单检查保持性存储区有没有冲突、是否用了非保持的M区默认设置、断电瞬间电容放电是否完整等等。虽然AI不会像老师傅一样看一眼就知道“你设置错在哪个字节”但它能把你可能忽略的盲区给你兜一遍。尤其面对冷门型号或者不常用的功能这种穷举式提醒比翻手册快多了。2.4 标准化模板和设备选型辅助AI在“套路化内容生成”上确实很强。以前写设备说明、操作手册里的程序流程说明都要从旧文档里复制粘贴改一改。现在我可以把IO点表、控制逻辑概要丢给AI让它生成一份操作说明书初稿结构和上下文基本不用大改。再比如选型时把工艺参数流量、扬程、电机功率丢给AI让它按ABB或者西门子产品线给出变频器建议型号虽然不能盲信但用来圈定范围非常省事。这里必须说明一下AI给出来的代码和建议定位永远是“初稿”或“参考”不是“终稿”。别直接下现场也别直接交付。这不是信不过AI而是逻辑太紧了。3. 一套能落地的提示词模板以及我怎么校验AI的输出很多人试过让AI写PLC程序结果发现出来的代码要么语法不对、要么逻辑“想当然”。问题多半出在需求描述不够具体。PLC程序的特点是强约束、强时序、强安全给AI的信息越模糊它猜得越离谱。我来分享一个我自己调了好几版才定下来的提示词结构。3.1 一套可复用的AI编程提示词模板我的提示词固定分五段写角色设定你是一个有15年经验的PLC自动化工程师熟悉IEC 61131-3标准精通西门子博途SCL、Codesys ST、三菱GX Works的ST语言。硬件环境PLC品牌和软件平台举例Codesys V3.5 SP19目标CPU是倍福CX5120IO模块型号和地址起始位置通信方式Profinet、Modbus等。IO信号表全部输入输出以明确的表格或列表形式给出包括信号名、数据类型、地址、量程、点位说明。控制逻辑要求按条件逐条写清楚包括优先级、联锁、延时、保持、手自动切换规则、故障处理规则。要明确说“如果有冲突逻辑以安全条件优先”。输出要求使用ST语言命名规范按“前缀_描述”给关键段加注释给出容易遇到的上电初始化说明。下面是我最近做的一个“双泵恒压供水”功能块的提示词实例。你是一个有15年经验的PLC自动化工程师熟悉IEC 61131-3标准擅长Codesys ST语言编程。 项目环境Codesys V3.5 SP20PLC为倍福CX5120AI模块地址IW0DI模块地址IX1.0起DO模块地址QX2.0起。 IO说明 AI_Pressure AT %IW0 : WORD; // 压力变送器4-20mA对应0-1.6MPa DI_Fault1 AT %IX1.0 : BOOL; // 1#泵故障信号 DI_Fault2 AT %IX1.1 : BOOL; // 2#泵故障信号 DI_LevelLow AT %IX1.2 : BOOL; // 水池低液位 DO_Pump1 AT %QX2.0 : BOOL; // 1#泵接触器 DO_Pump2 AT %QX2.1 : BOOL; // 2#泵接触器 控制要求 1. 两泵一用一备默认1#泵启动每运行24小时自动轮换一次。 2. 自动模式压力低于1.2MPa启动当前泵压力高于1.5MPa停止当前泵。 3. 运行中如果当前泵故障立即停当前泵自动切换备用泵启动。 4. 水池低液位时禁止启动任何泵运行中低液位强制停止所有泵。 5. 泵启停间隔不小于5秒防止频繁启停。 6. 任何情况下DI_Fault状态同时只能启动一台泵。 输出要求使用ST语言实现变量前缀保持IO中定义的命名写出完整的变量声明和逻辑体注释用中文并提示上电初始状态处理。这个提示词的核心不在于“让AI生成程序”而在于把我脑子里的控制规则完整地倒给它。你会发现写这个提示词本身其实也是在帮我自己理清控制需求。很多时候我写完需求描述代码逻辑怎么组织已经清楚了大半AI只是替我敲键盘。3.2 拿到AI代码后必做的三轮修改AI生成代码后我从来不会直接粘进工程。第一轮先把地址替换成实际PLC硬件组态里的绝对地址或者符号路径。AI生成的代码里地址是它自己推的跟我的站点不一定对应这步是必须的。第二轮把安全联锁逻辑抽出来单独检查确保急停、超限、互锁的优先级在任何情况下都不会被绕过。第三轮补上时序和初始化逻辑比如首次上电时的状态复位、故障自保持、手自动切换时的瞬时脉冲处理。有朋友问过我这么改下来跟自己写还有多少区别说实话如果程序很小区别不大。但中大型程序AI给初稿的价值在于省去了变量声明、命名规范、结构框架这些重复劳动我只需要聚焦在逻辑验证上。单位时间里的产出质量明显不一样这才是它值得用的地方。4. 别高兴太早AI在PLC领域最常见的五类翻车现场用了大半年我确实被AI坑过几次而且坑得很有“AI特色”。不了解这些坑你很容易在项目紧要关头被摆一道。我总结成五类每个都是实际见过的。4.1 地址和符号表“幻觉”AI最喜欢干的事情之一是煞有介事地编造地址。你问它“把这段程序改成AT %MD10”它会很自然地用%MW10、%MD0这种它觉得“合理”的地址。问题是PLC地址跟内存区域强相关一旦地址错位轻则读写冲突重则覆盖别的功能块数据。尤其是西门子博途的符号寻址AI给出的全局变量名经常跟项目里已有的DB块变量冲突编译过不去还算好的编译过去了跑飞了才是大问题。规避办法很简单在提示词里明确要求“不使用自动分配的地址地址以我提供的IO表为准”并且在拿到代码后逐一核对地址声明。这一步没有捷径。4.2 数据类型的“想当然”PLC的数据类型比通用编程严格得多。AI从互联网语料里学了很多高级语言习惯最容易踩的坑就是拿INT当BOOL用、拿REAL当TIME用、延时直接写TON(IN:条件, PT:5)——在Codesys里PT是TIME类型5会被编译报错AI不知道T#5s这种PLC特有的时间字面量。反过来在博途SCL里时间要写T#5S或DINT转TIMEAI经常弄混。这类问题好在编译阶段就能暴露不算最危险的。最烦的是隐式转换能过编译但精度和溢出有问题。比如用WORD存模拟量转换结果然后直接跟REAL比较虽然能跑但偶尔出一个很奇怪的值。见到这类代码我一般都让AI改用类型转换函数或者在变量声明里严格使用INTERNAL类型。4.3 对扫描周期和时序的理解偏差PLC是循环扫描执行的同一个程序段的输出在下一个周期才生效。AI写循环和跳转逻辑时有时候会把通用编程里的“函数调用返回”思路带进来。比如它可能写出这样的代码// AI生成的“有问题版本” IF Start THEN PumpRun : TRUE; END_IF; IF PumpRun THEN Step : Step 1; END_IF;初看没问题但它没有考虑Step在同一个扫描周期里被重复执行或者某些情况下PumpRun刚置位就进入下一步导致错位。这种时序问题不跑仿真很难看出来。我现在会让AI在生成代码时“显式区分组合逻辑和时序逻辑”手动把状态机部分拆开一步一状态不给它自由发挥的余地。4.4 安全联锁被“以人为本”地简化这可能是最危险的一类。AI在生成逻辑时倾向于“按正常流程写”对安全需求的重视程度不够。举个例子我之前让AI生成一个“电机正转反转互锁”的功能块它给的逻辑是正转输出和反转输出互斥条件正转启动按钮或者反转启动按钮。看似没错但它漏掉了一个关键场景正转运行中按下反转按钮两条输出会瞬间同时导通吗按它的逻辑互锁是条件互斥不是输出互斥结果现场就可能炸接触器。我赶紧改了把互锁写成输出之间的硬互锁再加软互锁同时把急停复位状态放到最高优先级。经验是AI的代码安全联锁必须单独做“对赌式检查”——你假设它的逻辑可能藏着一个极端场景然后逐条验证“如果传感器断线会怎样”“如果急停拍下会怎样”“如果两个命令同时来会怎样”。这三点能过基本就稳了。4.5 品牌指令集张冠李戴不同品牌的PLC指令集差异非常大。三菱的SET/RST西门子的S/R赋值Codesys的TON实例是功能块实例博途的TON则更像IEC标准调用。AI如果没有被强约束很容易把三菱的写法带到西门子里。比如在三菱里写SET M0AI生成到西门子SCL就变成M0 : TRUE这个还好但反过来把西门子的#Temp局部变量类型语法用到Codesys里编译报错都找不到地方。解决的办法提示词里明确注明星鼎平台语言版本并且让AI对不确定的指令标注“待确认”。我甚至试过让它把三菱的ST逻辑先翻译成伪代码再手写翻译到博途比直接跨品牌翻译准确率高得多。5. 人机分工我现在的工作节奏和验收流程AI这东西对我最大的改变不是“写代码变快了”而是干活节奏变了。以前是“先想后写”有时候懒得想先写再改。现在是“先把需求讲清楚再让AI打草稿最后我审稿”。这个节奏逼着我养成了一种更好的习惯需求不明确的前提题词给AI再多描述也生成不出像样的东西。我现在的标准工作流是这样的第一步整理IO点表和工艺描述这一步永远是我的活不可能交给AI。因为AI不知道现场到底装了什么传感器不知道甲方习惯在HMI上叫什么名字。信息源头准确后面才有意义。第二步用第3节那个模板把控制逻辑按条目写清楚喂给AI让它在ST/SCL里生成初稿。这一步我通常会给两台不同的AI工具同时生成拿来对比互相当裁判。两个版本会暴露各自的盲区合起来看往往能发现单个版本里不容易注意到的边界问题。第三步人工审稿编译。地址核对、安全联锁检查、类型检查、时序推演都是我列成清单逐项过。这个清单我贴出来给你参考[ ] 所有变量地址和符号名与IO点表一一对应[ ] 所有安全联锁急停/超限/互锁/启动条件优先级最高不能被自动逻辑绕过[ ] 时间参数延时/定时器类型与平台匹配[ ] 手自动切换不会产生输出抖动或瞬断[ ] 上电初始化有明确的状态复位[ ] 故障自保持与复位逻辑闭环[ ] 每一个定时器/计数器实例名唯一第四步用PLC的仿真功能跑一遍逻辑或者接上小功率设备做点动验证。不到万不得已我不用仿真代替现场但仿真能抓出80%的时序问题。这套流程下来AI负责的是“量”把一大堆框架代码、注释、初稿批量生成我负责的是“质”把安全、时序、工艺这些真正值钱的东西抠死。人机之间没有谁替代谁反而互补得挺好。6. 再往后走我对AI和PLC工程师关系的看法很多同行担心AI会把PLC工程师搞失业。我自己用了大半年反而觉得不会。PLC这行的门槛根本不在“会不会写ST”而在“有没有在现场摸过设备、懂不懂工艺到底要什么”。AI能把代码写得像模像样但它不知道水泵汽蚀余量是什么不知道接触器触点粘连会有什么后果不知道甲方说的“压力波动不能太大”到底是多少算大。这些判断力AI暂时给不了。但我必须承认AI正在把行业门槛拉平。以前一个新工程师要攒两年经验才敢独立写复杂功能块现在借助AI半年可能就可以了。这种趋势下真正值钱的技能会越来越往“需求拆解、工艺理解、现场调试、安全兜底”这几个方向上集中。我甚至觉得未来招人我反而不在意他背了多少指令而是看重他能不能把一套复杂的工艺讲清楚、能不能拿着AI给的初稿挑出逻辑漏洞。这是好事也不是好事——好事是行业效率会整体提升不太好的是中间层混日子的空间会被压缩。最后说点实操层面的建议。如果你打算开始用AI辅助PLC编程先从三类需求开始一是让AI把你的中文工艺描述转成ST框架代码二是让AI给老程序补注释和说明文档三是让AI帮你想排查思路。这三件事见效最快也不太容易出大安全问题。等跑顺了再加到代码生成和仿真验证上。一开始别碰涉及安全等级极高的逻辑比如安全回路、硬互锁、紧急停车这些还是老老实实手写。等到你对AI的风格和坑足够熟悉了再逐步扩大应用范围。这是我踩了大半年坑之后最想说的一句话AI是来帮你加班的不是来替你担责的。代码最后敲下去的人是你现场出事站出去的那个人也是你。