干了十年PLC编程最近开始让AI替我写程序这话放一年前我自己都不信。做自动化的老油条嘛对新技术一向是“先看能不能落地再决定吹不吹”尤其PLC这种讲究状态、时序、因果的工业环境谁会放心把代码交给一个大语言模型但最近几个月我把DeepSeek这类对话式AI真正用进了博途、Codesys和国内几个主流PLC平台的日常开发里接的项目有正反转、星三角降压启动、抢答器控制、流水线分拣还有改了不少老设备的维护程序。实测下来的感受是AI确实能替我干活但前提是得用对方法得知道它的边界在哪。这篇东西就是我自己这一阶段的总结。想聊聊AI在PLC开发里到底能干什么、不能干什么我踩了哪些坑以及现在稳定跑通的一套“AI辅助PLC开发”工作流。打算尝试AI编程的自动化工程师、想用AI减轻重复劳动的设备维护老手还有刚入行还在跟梯形图死磕的新人都可以参考一下。我不讲什么大道理就讲实操以及我花了十年积累、最终被AI逼着重新梳理了一遍的那些工艺经验和程序架构认知。1. 从梯形图到对话生成我为什么开始让AI写PLC程序1.1 十年PLC老兵的AI初体验我是从继电器电路图时代走过来的人先做电柜装配后来才转PLC编程。从西门子S7-200的STEP 7到S7-300/400的LAD和STL再到TIA博途的SCL中间还做过三菱FX/Q系列、台达DVP、信捷XD以及汇川的InoProShop。说实话大学刚毕业那会儿我坚信PLC工程师的核心竞争力就是“写代码的手速”和“背指令的脑容量”。梯形图画得飞起语句表倒背如流谁要是说以后代码可能由AI来写我一定觉得这行要完。转变发生在今年初。当时接了一个项目现场急着要一套星三角降压启动的控制逻辑同时还得把正反转、手动/自动切换一起做了。那个程序本身不难但重复性极强改了第3版需求之后我已经不想再动十指了。第一次试AI抱着“反正也写不出什么花来”的心态我把控制需求用大白话打进去结果它给我生成了一段结构完整的SCL变量命名、注释、互锁逻辑、延时切换都齐了。当然仔细看问题不少但那种“从零开始”的空白恐惧感瞬间就没了。那一次之后我开始认真琢磨怎么用它。这半年试下来我的结论比较明确AI对PLC工程师来说不是替代者是个干活特别快、但需要人盯着的“初级技术员”。它的价值在于把“脑子里想的控制流程”快速翻译成“结构化的第一版代码”。对于干了十年的程序员来说最难的不是敲指令而是把需求表达清楚并拆成逻辑块。这部分恰好是AI能帮上忙的地方只要需求喂得好第一版代码的完成度能到七八成。1.2 AI在PLC项目里解决了什么真实痛点做了这么多年的PLC项目我总结下来最耗时间的其实不是画梯形图本身而是三件事第一面对一张白纸决定程序架构第二把现场需求一条条翻译成变量、触点、线圈第三写注释和整理文档尤其是改动频繁的项目注释经常跟不上。AI把第一件事的启动成本几乎降到了零。比如让我写一个“用按钮控制电机正反转”的功能块我脑子里先浮现的还是主电路、互锁、停止优先。但如果只是描述完需求让AI写它几秒钟就能给出一个可讨论的版本我在此基础上做增删比自己从空程序开始要省大量时间。第二件事是AI的强项它有大量公开的PLC代码、手册、问答数据可供训练对“按钮常开接I0.0接触器线圈接Q0.1”这种标准映射非常熟悉只要你把IO表给它它能很准确地帮你生成变量映射代码。第三件事更有意思我经常把已经写完的程序贴给它让它补注释或者把梯形图逻辑改写成SCL的等效逻辑生成质量比我手写还整齐。当然AI也解决了我最头疼的“多品牌语法切换”问题。以前我从西门子切到三菱总得翻指令表TIM、OUT、SET、RST还有各种寄存器编号。现在我把品牌、型号、需求填进提示词AI生成的代码虽然未必能直接编译但大方向往往是对的。2. AI到底能替PLC程序员干什么不能干什么2.1 真正好用的地方从自然语言到结构化代码在PLC这个领域AI最擅长的就是把自然语言翻译成结构化文本语言比如SCL或者ST。因为SCL的语法接近Pascal语法规则封闭、关键词固定大语言模型学起来容易生成的代码也比较稳定。如果你让它生产梯形图它会用文字描述的方式给你列出每一行的触点线圈关系自己能看懂但没法直接导入博途。但如果你让它生产SCL把功能块代码往博途或Codesys里一贴稍微改改变量名就能编译。举一个我最近实测的经典场景抢答器PLC控制系统。这种控制要处理“谁先按下谁有效、其他人按钮无效、主持人复位后才能进入下一轮”用梯形图写需要好几行互锁但用SCL写就非常自然。我让AI按这个需求生成代码它给出的逻辑是用置位复位指令锁存第一个触发变量然后用一个“允许抢答”的中间变量来锁住其他输入最后用主持人复位信号清零。这个思路跟我在纸上画的流程一模一样只是它用了5分钟我用了半小时。星三角降压启动更典型我先后让AI生成了三版代码越改越接近现场的工艺要求。这类“状态多、时序明确、边界清晰”的控制逻辑就是AI的舒适区。AI在文档整理上也是一把好手。我经常把IO表、报警字、配方参数丢给它让它生成PLC变量声明段的注释或者生成一份操作说明书的初稿。这种活以前我都是找实习生干现在AI几分钟就干完了而且格式整齐连“变量用途”“数据类型”“地址范围”都给你整理成表格。2.2 千万别指望AI的地方厂牌差异、地址规划与安全回路AI不是PLC手册更不是现场调试工程师。第一不同PLC品牌的地址体系差异极大西门子用I/Q/M区加符号名三菱用X/Y/M和D寄存器台达DVP虽然有类似X/Y/M但指令细节不同汇川InoProShop虽然是Codesys生态但地址和功能块库又有自己的一套。AI对这些差异有一定了解但经常混淆。比如我要它写三菱FX5U的程序它可能会给出接近西门子的I/Q变量命名或者把三菱的SET指令和西门子的S指令混着写。这种错很隐蔽编译不过倒容易发现怕的是编译能过但动作不对。第二是地址规划和过程映像区分配。AI不理解你现场的具体接线如果你不给它IO表它会自己编地址编得还挺有道理但一接现场就是灾难。我试过一次让AI生成一个设备的完整程序它把输出点分配到了Q0.0到Q0.7实际上我的CPU那组输出全是坏的都用备用输出模块结果整个接线图都要重做。所以我的铁律是地址表必须由人工提前确定AI只负责在给定框架内填逻辑。最要命的是安全回路的处理。AI的“简化思维”会在你不注意时优化掉急停、安全门、热继电器、机械限位这些关键信号。它可能觉得这些信号“工作状态时一直为常闭没必要参与逻辑”但它不知道的是PLC程序里必须把这些常闭点串进主回路逻辑否则断了线设备还在转出的是人命。有一次AI生成的正反转程序里把“停止按钮常闭串在主接触器回路”给漏了它的逻辑是用停止按钮复位一个中间变量但没把停止按钮直接放在最终输出表达式的与项里。这件事让我出了一身冷汗。从那以后安全相关逻辑我坚持人工写AI生成的内容只作为参考绝不直接进功能块。这里可以梳理一下AI在PLC开发中的能力边界做个表格更好说清适用场景能力表现我的评价经典算法正反转、星三角、抢答器能给出完整SCL/ST代码、带互锁和时序可用度较高需人工审查梯形图逻辑转SCL等效描述逻辑转换准确注释到位省力适合老设备改造报警、配方、IO表整理表格、注释、文档生成速度快强烈推荐效率翻倍多品牌指令差异容易混淆厂商语法必须人工核对地址规划/接线映射会凭空编造地址绝对要人定安全回路、急停逻辑经常简化或遗漏禁止直接使用硬件组态、通信配置如AMS NetID给不了准确配置值只能查手册实测3. 一套已经跑顺心的AI辅助PLC开发工作流3.1 第一步把控制需求写成AI听得懂的提示词用AI写PLC代码最大的分水岭不在于模型选多强而在于你提示词写得是否像一份“需求说明书”。我以前习惯直接说“帮我写个星三角启动程序”结果生成的内容五花八门有的用TON定时器、有的用计数器、有的甚至用延时接通的时间继电器指令程序框架确实对但跟我手上那台CPU的库版本不一定兼容变量命名也千奇百怪。后来我改进提示词固定了一个模板效果立竿见影。我常用的提示词结构是这样的角色设定你是一名有10年经验的PLC工程师熟悉西门子TIA博途SCL语言。 硬件环境CPU为S7-1200系列数字量输入I0.0-I0.3数字量输出Q0.0-Q0.2。 IO表I0.0启动按钮常开I0.1停止按钮常闭I0.2热继电器常闭I0.3手动/自动切换。Q0.0主接触器KM1Q0.1星形接触器KM3Q0.2三角形接触器KM2。 控制要求启动后KM1和KM3得电6秒后KM3断开、KM2得电停止或热保护动作立即全部断开KM2和KM3必须互锁手动模式下由启动/停止按钮控制自动模式下由HMI的自动启动信号M0.0触发。 输出要求SCL功能块代码带中文注释变量名清晰易读。这个提示词的要点在于先限制语言和平台再给准地址再列工艺顺序最后提输出格式。AI非常依赖上下文你给的越像甲方给工艺包它生成的越像能用的程序。3.2 第二步用“反问法”逼AI把需求问清楚还有一个实操中摸索出来的技巧我把它叫“反问法”。就是不要急着让AI生成代码而是先让它列出“写这段程序之前你还需确认的3个问题”。这个技巧最初是我调AI生成复杂逻辑时候发现的。因为PLC控制里有很多隐含条件比如星三角切换是“断电切换”还是“不断电切换”停止是“自由停车”还是“立即断开”热继电器用的是常闭还是常开信号手动模式是否允许直接启动三角形接法。这些条件只要有一个没交代清楚AI生成的程序看着能跑实际上就是埋雷。让AI先反问的好处一是强迫自己把工艺条件想周全二是在AI给出的问题清单上做勾选比凭空回忆需求更系统。有一次我让它生成一台流水线分拣程序它反问了我六个问题其中有两个我确实没想到一个涉及“气缸复位是否需要有超时报警”另一个涉及“扫码枪故障时是否允许旁路放行”。这俩问题在现场调试时一定会暴雷AI提前帮我问出来了。这也是我后面发现AI在PLC领域最有价值的功能之一——“需求审查”比写代码本身有用。3.3 第三步移植进工程前的逐项检查AI生成代码之后直接复制到博途编译我劝你别。我自己设定的流程是每次移植AI代码到工程之前必须过五关第一关地址核对。所有I/O地址必须与真实IO表完全一致不允许出现AI自创的地址哪怕它注释写得很通顺。第二关变量声明核对。SCL是在FB/FC里运行的AI生成的代码里如果出现了没有声明过的局部变量、静态变量或者它的临时变量跟现有DB冲突编译能过但运行就会出幺蛾子。第三关互锁检查。我做一个真值表把每个输出条件列出来逐个检查是否满足现场的“不允许同时动作”要求。正反转要查KM1/KM2互锁星三角要查KM3/KM2切换时序。第四关时序与复位检查。定时器在重新启动时能否自动复位计数器到上限后是否跳转等。第五关安全通道检查。急停、安全门、热继电器、限位开关必须确保它们以“停机优先”的形式参与逻辑AI无论如何简化都不能把这些通道短路。这五关走下来AI生成代码的可用率大幅提升基本能直接进编译环境。有些老工程师可能觉得这流程多余但我个人体会是既然用了AI提速就得用流程化审查来保证不出错宁可多花十分钟检查也不要把隐患带到现场。3.4 完整案例AI生成星三角降压启动的SCL我把这段时间最典型的一个案例完整拆开讲一讲就是星三角降压启动。我按照提示词模板把需求发给AI它生成了一段SCL。代码的框架是对的但有几个关键点我做了修改。先说AI生成版本里被认为“能用”的基础框架// 星三角降压启动控制 // 输入: I0.0启动, I0.1停止, I0.2热继电器常闭 // 输出: Q0.0主接触器, Q0.1星形接触器, Q0.2三角形接触器 VAR RunFlag : BOOL; // 运行中间变量 Timer_StarToDelta : TON; // 星型转三角延时定时器 END_VAR // 停止优先按下停止或热继电器动作时清除运行标志 IF NOT I0.1 OR NOT I0.2 THEN RunFlag : FALSE; ELSE // 启动信号启动按钮或自动信号 IF I0.0 OR M0.0 THEN RunFlag : TRUE; END_IF; END_IF; // 主接触器运行标志有效时得电 KM1 : RunFlag; // 星三角切换定时器 Timer_StarToDelta(IN : RunFlag, PT : T#6S); // 星形接触器启动阶段得电延时到断开 KM3 : RunFlag AND NOT Timer_StarToDelta.Q; // 三角形接触器延时后得电 KM2 : RunFlag AND Timer_StarToDelta.Q;这段代码逻辑显眼处没问题主接触器和运行标志联动星形先启动、延时后切三角形。但仔细审查会发现三个隐患。第一个隐患是KM3和KM2的互锁不够严格。KM3和KM2虽然分别用T#6S定时器的Q点错开但万一扫描周期里定时器Q翻转的瞬间、或者RunFlag抖动两个接触器有可能同时得电。接触器同时吸合主电路会直接短路。现场我绝对不允许这种东西存在。我的修改方案是加上显式的互锁项把KM3的输出条件加一条“NOT KM2”KM2的输出条件加一条“NOT KM3”。这在电气控制里就是最基础的自锁互锁思想可AI生成的代码经常只有时间错开没有显式互锁。第二个隐患是热继电器动作之后RunFlag被清掉没问题但Timer_StarToDelta的IN也变FALSE了再启动时定时器会重新计时这部分逻辑正确。可问题出在KM2的表达式上如果热继电器动作瞬间恰好定时器定时已经到QTRUEKM1已经被RunFlag带成FALSEKM2由于表达式里有RunFlag也为FALSE这点倒是安全。第三个隐患是自动模式的启动条件没有做“边沿触发”处理。如果M0.0一直为TRUERunFlag会变为TRUE但星三角切换是一次性的逻辑也需要KEEP功能——实际上RunFlag一旦为TRUE整个系统就进入星三角状态直到停止按钮按下这没问题但如果用户希望在自动模式里每启动一次就运行一次就需要在HMI侧做脉冲或者在PLC侧做上升沿。我最后提交到博途的版本长这样// 实际生产版本加入显式互锁输出表达式做安全关联 IF NOT I0.1 OR NOT I0.2 THEN RunFlag : FALSE; ELSIF I0.0 OR (AutoMode AND AutoStartCmd) THEN RunFlag : TRUE; END_IF; Timer_StarToDelta(IN : RunFlag, PT : T#6S); KM1 : RunFlag AND SafetyChain; // SafetyChain 为急停等安全回路中间变量 KM3 : KM1 AND NOT Timer_StarToDelta.Q AND NOT KM2; KM2 : KM1 AND Timer_StarToDelta.Q AND NOT KM3;改动不大但每一条改动都有明确理由给输出并联了“NOT”互锁项防止接触器同时导通把安全回路的中间变量串进主接触器保证急停动作立即使所有接触器断开自动模式用AutoStartCmd的上升沿信号避免HMI给持续信号时程序“卡在启动状态”。AI生成代码本身花了几分钟我的审查和修改花了差不多半小时。但整体算下来比我自己从零写还是快了不少尤其架构和变量命名这部分几乎不用动脑。4. 我踩过的坑和排查思路实录4.1 地址、变量名与生产环境不匹配用AI生成了五六次完整程序之后我总结出一个规律AI给变量起名的水平参差不齐。同一个“电机启动按钮”它可能叫START_BTN也可能叫Motor_Start_Button也可能直接叫M0.0。如果你不统一符号表生成的代码贴进博途哪怕逻辑全对变量名要改一大圈。更麻烦的是品牌差异。我做了个测试同一个星三角需求分别让AI用“三菱GX Works3”和“汇川InoProShop”生成结果三菱版本它用了X0/Y0输出、M0中间继电器而汇川版本给了I/Q/MCodesys风格两者不能互换。但如果你只告诉它“用汇川PLC”它给出的东西可能还是西门子味道。说实话AI并没有真正理解InoProShop的语义体系它只是根据训练数据猜。所以我现在固定做法是先在项目里把符号名和地址建好写提示词时直接把符号表片段贴进去让AI用我给的变量名而不是自创。4.2 AI生成代码的语法和指令兼容性陷阱SCL这类文本语言对PLC来说算“高层语言”但底层指令差异仍然客观存在。AI生成的SCL里经常出现我在博途实际编译不通过的情况集中在这几类一是定时器写法。不同PLC品牌对定时器的功能块调用语法不同。西门子博途SCL里用TON_Instance(IN : , PT : )整体调用而三菱结构化文本则是编写OUT_T之类的定时器线圈语法结构几乎完全不同。AI最容易混淆这些。二是置位复位指令。SCL里可以用S和R指令也可以用布尔赋值。AI往往两种混合着用导致同一个中间变量在一个分支里用赋值覆盖、在另一个分支里又用置位保持运行起来逻辑莫名其妙。三是数组和结构体。让AI生成配方管理或批量控制的代码时它喜欢用动态数组或者复杂结构体但很多PLC的FB接口不支持运行时动态下标只能在编译时确定。这种代码写得很漂亮拷进PLC里根本编译不过。后面我干脆在提示词里加了一句“请使用基础指令集避免动态数组和复杂结构体”生成结果的可用度才上来。4.3 安全逻辑被“优化掉”最危险的坑前面说过AI容易把安全信号“优化”掉我再展开说一个具体案例。我在让AI生成正反转程序的时候它的回复里用了类似这样的逻辑KM1 : ForwardCmd; KM2 : ReverseCmd;看起来很简单但缺少两个东西一是正反转之间的互锁条件二是急停回路关联。如果ForwardCmd和ReverseCmd同时为TRUE它就会同时输出两个接触器主电路就直接短路了。更离谱的是有一个版本它在“考虑互锁”时没有把停止按钮常闭串进去只在分支后用“若按下停止则将其复位”的方式处理这意味着安全回路断线时程序可能认为“停止信号为TRUE”并继续运行。这类错误非常隐蔽如果不是逐项对着电气原理图核对根本发现不了。所以我现在有一个铁律凡是涉及到“停机优先”“安全互锁”“急停回路”相关的行一律人工手写AI生成的结果只用来当思路参考。你可以相信AI帮你梳理正常工况但绝不能在安全回路上省时间。4.4 AI代码“过度结构化”带来的维护负担还有一类坑不算安全风险但很影响效率AI生成的代码结构经常“过度设计”。比如我让它写一个简单的计数分拣控制它给我搞了五个功能块一个是状态机、一个是配方管理、一个是报警处理、一个是输出映射、一个是主调用。从软件工程角度看这架构很高级但从PLC维护角度看这就是灾难。PLC程序和IT系统不同一旦现场要快速排查问题工程师习惯的是“一条线从头看到尾”的梯形图或者结构化文本你把逻辑拆得七零八落下一个接手的人根本不敢改。我的处理方法是提示词里明确限制程序规模。如果要的是一个Device级的小功能块就要求“单功能块实现不超过XX行避免额外FB调用”。这样AI生成的东西更贴近传统PLC程序风格后期维护成本低。4.5 常见问题速查表把这段时间踩过的坑整理一下做成一个速查表方便后面再遇到类似问题直接对照现象根因排查/解决思路生成的SCL在博途编译报变量未定义AI用了自创变量名提示词里贴入符号表强制使用现有变量程序动作与接线不符AI自编了I/O地址地址必须人工规划AI只填逻辑接触器同时吸合互锁项缺失或只有时间互锁给每个输出表达式加显式NOT互锁项急停/热保护失灵安全信号被AI“简化”掉安全回路逻辑一律手写定时器逻辑异常品牌定时器语法混淆明确指定品牌与PLC型号程序拆成太多功能块AI过度结构化提示词限制单功能块实现自动信号触发后重复启动未做上升沿处理在HMI侧或PLC侧做脉冲触发官方手册查不到的内容AI乱编大模型对私有库了解不足例如AMS NetID、MAC地址等硬件配置只能查手册5. 十年经验没白费AI改变的是工作方式而不是岗位5.1 现在的分工AI写第一版草稿我负责让它可靠用AI写了半年程序之后回头看这十年PLC职业生涯我发现自己干的活其实一直分两类一类是“把想法翻译成代码”一类是“让代码在设备和工艺上可靠运行”。过去我把大部分时间花在第一类总觉得写程序才是核心能力。现在AI把第一类的效率拉高了好几倍它替我干了大量的第一版起草工作我反而腾出了更多精力去搞第二类更关键的事需求拆解、安全审查、现场调试和文档沉淀。举个例子以前做老设备改造我拿到一叠图纸和一沓手写的控制需求首先在纸上画流程图再慢慢写程序光这个环节就得两三天。现在我用AI先跑一遍控制流程把自己想到的、AI反问出来的、工艺要求里的所有条件整理成需求文档AI生成第一版我再逐行核对、调整时序和安全逻辑基本上一天就能出一版可编译的草稿。后面到现场真正花时间的反而变成接线核对和机械配合调试这些AI确实替代不了但也不该由AI替代。5.2 给刚入门“AIPLC”的三个可执行建议要是你现在还在犹豫不知道从哪里开始把AI用进PLC工作我给你三个最稳妥的切入点先做注释和文档生成。拿一段你以前写的成熟程序贴给AI让它补注释、整理变量表、生成测试说明。这个场景风险最低即使AI理解有偏差也不影响程序运行你还能顺便感受它的输出风格。第二步再做单功能块的多版本对比。选一个你闭着眼都能写的简单逻辑比如电机启保停、或者三台电机顺序启动用不同提示词让AI生成不同版本比较它和你写法的差异。熟练之后你会发现真正影响代码质量的是提示词里给出的约束和细节不是AI本身。最后再尝试让AI生成整段新逻辑。从经典控制对象开始比如星三角降压启动、抢答器控制、交通信号灯模拟这些都是PLC教学里的经典案例官方资料多、AI训练数据足生成质量最稳定。等整个工作流跑顺了再去碰复杂的产线级程序。5.3 最后一点个人体会这半年用下来我最大的感触是AI并没有让十年PLC经验变得不值钱恰恰相反它让我那些藏在脑子里的工艺规则、安全底线、设备脾气变得更加值钱了。AI替代的只是“把规则写成代码”这个动作而那些规则本身还需要人来定义、判断、维护。以前我带徒弟得花两三年让他熟悉设备、熟悉工艺才能自己写程序。以后这个周期可能会缩短到几个月因为AI能帮新人快速生成第一版新人只需要学会审查和修改。但审查和修改恰恰是最需要经验的地方你得多犯几次错才知道哪里会短路、哪里会溜车、哪里会卡料。最后分享一个我现在的操作习惯每次AI生成代码并经过我修改后我都会把当时的提示词、AI原始输出和最终修改版保存到同一个项目文件夹里。这样下次遇到类似需求我可以直接复用提示词甚至把修改版再喂给AI让它学习我的风格。这种滚雪球式的积累比我过去十年靠脑子记指令、靠本子记窍门要高效得多。PLC这行不会消失但干法真变了。