十年PLC老手用AI写ST程序：提示词模板与实战避坑指南

干了十年PLC编程最近开始让AI替我写程序。这事说出来身边的老师傅第一反应都是“你疯了程序错了现场设备要动的AI懂个屁工艺”。但说实话真正让我下定决心尝试的不是AI有多聪明而是我把自己十年的重复劳动摊开看了一眼电机启停、报警处理、模拟量换算、手自动切换这些块我写了不下几百遍变量名换个前缀就又是一套新程序。既然这些工作本身就是高度模式化的为什么不让一个擅长模式识别的工具来打底稿我来做审查和收尾这篇文章想把这段转型经历里最实在的东西分享出来包括我踩过的坑、调通的流程、直接能用的提示词模板以及我认为AI在PLC编程里真正能干和绝对不能碰的边界。适合那种写了几年梯形图、开始觉得枯燥又对AI编程既好奇又警惕的同行。没有任何玄学全是实操经验。1. 十年PLC老手为什么开始把代码交给AI1.1 真正压垮我的是重复劳动很多人以为PLC程序员每天面对的是复杂的运动控制和精密的算法其实大部分时间干的都是“套模板”。新上一个项目先打开之前做过的类似程序把电机控制块复制过来改改IO点报警块复制过来改改文本模拟量处理块复制过来换个量程。听起来很熟练实际上就是高级搬运工。我用了大概七八年才意识到这类工作根本不是技术活纯粹是体力活加记忆力活。谁记得住哪个老项目的程序最稳定哪个功能块的写法没留坑谁就能干得快。但人的记忆力是有上限的而且随着年龄增长这种“翻旧账”式的开发方式越来越痛苦。AI出现的节点对我来说很微妙。我刚开始觉得这玩意儿就是个高级搜索引擎后来试着让它生成一段西门子风格的ST语言代码发现输出居然像模像样虽然不能直接下装但结构、变量声明、注释习惯都挺对路。那一刻我意识到困扰我十年的“模板复用”问题可能有了一个全新的解法。1.2 工具选型Cursor、Windsurf、Copilot还是Trae网上关于AI编程工具大比拼的内容很多我也把主流的几个都试过一遍。先说结论对于PLC编程这个场景工具的真面目没那么重要核心是你用的模型强不强以及你所在的编程环境能不能方便地粘贴文本代码。我用过的组合大致分三类。第一类是VS Code加Copilot插件严格说Copilot更适合写通用软件代码对PLC这种高度领域化的代码帮助有限它的训练数据里PLC相关内容占比太小很多时候给出的是“看起来像PLC但实际指令不对”的代码。第二类是Cursor和Windsurf这类AI原生编辑器它们的优势是支持整个项目上下文理解但PLC项目往往不是传统意义上的代码工程而是TIA Portal或CODESYS里的工程文件AI编辑器根本读不进去。第三类是直接用网页版对话把需求用自然语言描述清楚让AI生成ST语言代码然后我复制到PLC编程软件里编译。我最常用的其实是第三类尤其是DeepSeek的API和一些国产大模型的网页端。原因很简单不需要把PLC工程文件暴露给任何工具只需要来回粘贴代码文本安全可控。对程序员来说是“在IDE里写代码”对我们这行来说更像是“用一个懂ST语言的助手给自己打草稿”。1.3 为什么我选择ST语言而不是梯形图这是个关键抉择点。我身边很多同行至今坚持梯形图理由是现场电工看得懂、维护方便。这个理由我尊重但AI编程这件事彻底改变了我对ST语言的看法。目前AI对图形化编程语言的生成能力很弱你让AI生成了一个梯形图它本质上是生成一段XML描述放到TIA Portal里导入大多数时候编译报错报错信息还不一定看得懂。但ST语言就是纯文本AI在其训练资料里见过大量ST代码哪怕是西门子ST、CODESYS ST、IEC 61131-3标准ST混着学的至少能产出结构完整的文本代码。我实际测试下来AI生成的ST代码编译通过率在六成以上剩下的四成主要错在指令名称不统一、数据类型不匹配这类细节。这个成功率已经足够让我把“写程序”的重心从“敲代码”转移到“提需求、审代码、改错误”上。我并不建议所有人都立刻从梯形图切到ST但如果想让AI替你干活ST是绕不开的路径。2. 让AI写PLC程序提示词比代码本身更重要2.1 我总结的一个万能提示词模板聊AI编程绕不开提示词。我发现很多人让AI写PLC程序失败不是因为AI不行而是需求描述得太模糊。你说“帮我写一个电机控制程序”AI给出来的东西五花八门根本没法用。但如果你把设备类型、PLC品牌、编程环境、IO点表、工艺要求、安全功能全部写清楚AI生成的代码质量会直接上一个台阶。我这边经常用的提示词模板是这样组织的你现在是一名有二十年经验的西门子PLC工程师使用TIA Portal V17和S7-1200系列PLC编程语言为ST结构化文本。请帮我编写一个【功能块名称】功能描述如下【详细描述】。输入变量包括【变量名、数据类型、含义】。输出变量包括【变量名、数据类型、含义】。需要实现的逻辑包括【逻辑1】、【逻辑2】。特别要求【安全功能、互锁条件、手自动切换方式】。请输出完整的FC或FB代码包含变量声明和注释代码风格参照IEC 61131-3标准。这个模板里有几个关键要素值得说一下。第一给AI一个身份它就会自动对齐行业规范和术语习惯。第二指定具体的PLC型号和编程软件AI能调取对应体系的指令库写法。第三把变量的名称、类型、含义列清楚AI生成的代码几乎不用改变量名。第四安全功能必须单独强调AI默认不会考虑急停、互锁这些东西你不说它就不写写了可能是错的。2.2 一次完整实操电机星三角启动功能块说一个我印象最深的实操案例。当时一个项目里需要做六台水泵的星三角启动控制逻辑本身不复杂但每台泵的控制字、状态字、故障字都不一样写起来非常烦。我决定让AI打底稿。我给AI的提示词大概是这样请编写一个三相异步电机星三角启动控制功能块输入参数包括启动命令、停止命令、热继电器故障信号、接触器反馈信号。启动流程为先接通主接触器和星形接触器延时5秒后断开星形接触器再延时0.5秒接通三角形接触器。输出参数包括主接触器、星形接触器、三角形接触器控制字以及运行状态、故障状态。要求星三角切换不允许同时导通任何故障信号触发时立即全停。AI生成了一段一百多行的ST代码结构分了三段变量声明、逻辑处理、状态输出。让我意外的是它居然把互锁逻辑写进去了三角形接触器导通前先判断星形接触器已经断开。这个细节很多新手都会漏AI居然记住了。不过它也有两个问题一是把延时直接写成了固定数字没有做成可配置参数二是没有考虑故障复位的手动操作只能在故障消失后自动复位这不符合现场检修安全要求。我花了大约二十分钟修改了这两处然后把代码复制到TIA Portal里编译一次通过。之后六台水泵每台只需要改输入输出变量名程序骨架完全一致。这套流程下来原本一天的工作量压缩到两个小时左右。2.3 让AI反过来挑你程序的毛病写代码的人都知道自查是最难的。AI在这方面的价值被很多人忽略了。我现在写完一段ST代码或者从AI那边拿到了生成结果第一件事不是编译而是把它扔回聊天窗口让AI以“现场调试工程师”的身份审查一遍。我会用这样一个提示词请审查以下ST代码。重点检查1. 有没有可能同时输出两个正反方向的控制信号。2. 急停和故障信号被强制旁路的可能性。3. 延时定时器复位不彻底导致的逻辑残留。4. 数据类型隐式转换的隐患。请逐条列出问题并给出修改后的代码。这个做法帮我抓到了不少潜在毛病。印象最深的是一次AI审查出一段代码里的定时器重复调用问题同一个TON实例在两个分支里被重复使用这在PLC扫描周期的工作方式下会导致计时不连续实际运行中表现就是偶尔延时比设定值短。这个隐患靠人盯着代码看完真的不一定能发现但AI对这类模式非常敏感。3. 实例拆解AI生成一个模拟量PID控制功能块3.1 需求怎么写AI才明白你要什么模拟量PID控制在PLC编程里算有点门槛的内容了正好拿来说明AI能不能处理相对复杂的逻辑。我做的是把一个PID功能块交给AI生成要求是在S7-1200上模拟一个带手自动切换、抗积分饱和、输出限幅的ST控制块。提示词我做了额外的细化。我没有简单说“写一个PID功能块”因为AI很可能直接给你一个通用库的调用而我要的是“用于教学和深度定制的自定义实现”。我把PID公式里的比例项、积分项、微分项分别说明积分项要求带和值限幅手动状态下积分值清零切换回自动时无扰。输出要求带上下限并且支持输出变化率限制防止阀门动作过猛。AI生成的速度很快大概十几秒就给了一段代码。结构上用的是FUNCTION_BLOCK输入输出变量声明完整。我第一眼看到它的积分限幅处理时有点意外它没有用简单的“超限就截断”而是把限幅放在积分累加之前用的是“如果积分项超出上限就保持上限值同时停止累加”这个策略这个思路在经典抗积分饱和算法里是标准的说明它确实不是瞎编的。3.2 AI生成的代码和我动手改的部分为了让读者直观感受差异我简化一下它生成的PID核心代码逻辑。FUNCTION_BLOCK FB_PID_SIM VAR_INPUT rPV : REAL; // 过程值 rSP : REAL; // 设定值 rKP : REAL; // 比例增益 rKI : REAL; // 积分时间 rKD : REAL; // 微分时间 bAuto : BOOL; // 自动模式 rManOut : REAL; // 手动输出值 rOutMin : REAL; // 输出下限 rOutMax : REAL; // 输出上限 END_VAR VAR_OUTPUT rOut : REAL; // 控制输出 END_VAR VAR rErr : REAL; rIntSum : REAL; rLastErr : REAL; rDeriv : REAL; rOutRaw : REAL; END_VARIF bAuto THEN rErr : rSP - rPV; rIntSum : rIntSum rErr * rKI; IF rIntSum rOutMax THEN rIntSum : rOutMax; ELSIF rIntSum rOutMin THEN rIntSum : rOutMin; END_IF; rDeriv : rErr - rLastErr; rOutRaw : rKP * rErr rIntSum rKD * rDeriv; IF rOutRaw rOutMax THEN rOutRaw : rOutMax; ELSIF rOutRaw rOutMin THEN rOutRaw : rOutMin; END_IF; rOut : rOutRaw; ELSE rOut : rManOut; END_IF; rLastErr : rErr;这段代码从语法角度说能在TIA Portal里直接编译但从工程角度我加了三处处理。第一处是积分项的手动模式清零。AI代码里手动切自动时rIntSum保留着手动期间的旧值这会导致切换瞬间输出突变。我在ELSE分支里加上rIntSum清零逻辑才能做到无扰切换。第二处是微分项的噪声抑制。现场过程值的波动非常频繁直接用rErr - rLastErr算微分阀门会被高频抖动晃得寿命减半。我改成了一阶低通滤波的近似处理限制单周期微分变化量。第三处是输出变化率限制用一个额外变量记录上一次输出值每周期限制输出变化幅度不超过设定值。这三处属于典型的“AI不知道现场有多残酷”的例子它写的是教科书逻辑但现场设备需要的是工程逻辑。3.3 从ST代码到PLC功能块的工程化收尾AI生成的代码只是第一步真正让它变成PLC里能安稳运行的功能块还需要做几件琐碎但重要的事。第一件事是编译检查数据类型匹配。TIA Portal对REAL和LREAL的隐式转换很严格AI有时候会混用编译报错后需要手动统一。第二件事是分配背景数据块。S7-1200里调用FB必须指定背景DBAI不会替你考虑这个这是PLC工程层面的操作AI的代码里也不会有任何体现。第三件事是把输入输出变量对应到实际的模拟量通道、上位机画面变量上。这个环节本质上就是做点位映射表AI帮不了还得自己来。做完整套动作之后我用仿真功能跑了一遍PID响应曲线结果很理想。对一个没有经过现场参数整定的控制块来说能达到这种效果已经说明AI生成代码的可用性比我预想的高很多。但这里有个态度问题必须摆明白AI生成的代码能让我省事前提是我知道要往里面补什么。如果是一个刚入行的小白拿着AI代码直接下装大概率会把设备搞出问题来。4. AI写PLC程序踩过的坑以及我的排查套路4.1 五个翻过车的典型坑和AI协作这段时间我总结了五个出现频率最高的坑每一个都对应着一次或多或少的返工。第一个坑是AI凭空捏造指令和功能块。它有时候会写出一个西门子根本没有的指令名比如把TON写成TimerOnDelay或者自创一个没有输入输出的函数编译直接报错。遇到这种情况不要修改代码直接重新生成在提示词里注明“请使用IEC 61131-3或TIA Portal支持的标准指令”恢复概率很高。第二个坑是变量命名混乱。同一个功能块里第一次生成用rSetpoint第二次生成用rSP如果混在一起用虽然不影响编译但维护性极差。我的解决办法是在提示词里一次性把变量名固定下来。第三个坑是写出纯粹C语言风格的代码。AI的大模型训练数据里C语言占比太高它在生成ST代码时会不自觉地引入C语言习惯比如用return提前跳出、用数组下标访问超出边界的元素、甚至用malloc动态分配内存这些在PLC里全是雷。第四个坑是注释风格与公司标准不符。我司的程序注释习惯是中文加操作员级说明AI默认生成的注释经常是英文专业术语风格每次都要花时间清洗。第五个坑最隐蔽是AI在不同会话里给出的同一逻辑实现不一致。今天让它写的启停逻辑是“上升沿触发保持”明天同样需求它会写成“电平触发保持”两种写法在设备行为上差异很大。所以我的原则是同一个项目的代码坚持在同一个会话里生成和迭代不要频繁开新对话。4.2 拿到AI代码后我每次必做的四步审查现在我拿到AI生成的代码不会直接往PLC软件里粘贴而是走一套固定审查流程大约花十到十五分钟但能避开百分之九十的坑。第一步查指令与语法。把代码里所有的指令和系统函数列一遍对照当前PLC品牌的指令手册确认名称存在顺便看一眼变量声明有没有漏掉。第二步查互锁与安全逻辑。单独关注正反转互锁、星三角切换互锁、急停信号路径、故障复位机制这些是现场设备最容易出大事故的地方。第三步查数据类型与转换。确认每个比较运算两侧类型相同所有乘除运算都考虑了REAL和INT混杂的情况所有触点信号用的都是BOOL。第四步做干跑仿真。把代码放到PLC仿真软件里输入一组边界值比如零度、最大量程、最小量程看输出是否符合预期。做了这四步之后AI代码的可用性从“看着行”变成“确实行”。我经常拿这套流程跟同行说AI编程对人的要求不降反升以前你只需要会写现在你还需要会审、会判断、会决策。4.3 哪些PLC代码永远不应该交给AI最后说一个更偏价值观层面的问题也是我在这段经历中反复思考的。AI在PLC编程里能做骨架、能做重复劳动、能做审查辅助但有几类内容我不会让它碰。第一类是安全回路相关的逻辑包括急停回路、安全门联锁、抱闸顺序控制。这类逻辑涉及安全认证和现场人身安全即使AI写出了看似合理的代码也无法替代人工分析和安全评审。第二类是涉及核心工艺Know-how的程序段比如配方管理、生产批次追溯这类代码背后是公司多年的工艺积累喂给AI本身就有泄密风险更别谈让AI代写。第三类是已经被验证稳定运行的老程序不要因为好奇或“优化”心态拿去给AI重写稳定压倒一切这个原则在工业现场永远不过时。我自己的做法是把AI当成一个极其聪明但完全没有工程敬畏心的实习生。它可以在你盯着的时候快速起草但所有对现场负责的决策还是在人的手里。这种边界感清晰之后用AI写程序这件事才变得真正可持续。回头看看这几个月的变化最让我感慨的不是效率提升了多少倍而是工作重心真的在转移。以前每天大量时间耗在复制粘贴和改变量名上现在这些杂活被AI接走了我能把省下来的精力放到更值得的地方比如多想想工艺怎么优化、程序结构怎么搭更合理、怎么把项目的边界条件定义得更清楚。如果你也想尝试这条路我的建议很简单不要一下子铺太开先找一个你非常熟悉的功能块比如电机控制、报警处理这种把提示词写详细让AI生成然后用你已有的经验去改。这个过程既是在测试AI的能力也是在积累你个人的提示词经验库。等你跑通了一两个块再慢慢扩大范围让AI逐步介入更复杂的逻辑。最后分享一个我最近觉得特别值的小技巧。把你们公司沉淀多年的老程序挑几个代表性功能块把源码喂给AI让它按你的要求改写成标准化、模块化的ST代码同时生成配套注释和测试案例。这件事的本质是让AI帮你把过去十年的隐性经验变成一套清晰、可复制、可审查的模板库。等到哪天需要开发新项目直接从这套模板库里调效率和对现场的把控力都在一个更高的起点上。