AI写PLC程序实战指南：质量评测、踩坑清单与落地流程

这次我们直接聊一个很实际的问题AI 写 PLC 程序到底能不能用过去半年不少工程师在微信群里讨论过“让 AI 帮我写段三菱 PLC 程序”“让 AI 写个西门子博途里的 FB 块”讨论焦点也很一致生成结果看起来像那么回事但能不能直接下载到 PLC 里跑答案往往比较微妙。这个问题的本质是通用大模型学过大量代码但 PLC 编程的 IDE、指令集、硬件寻址、安全习惯和常规 IT 编程差异太大。这篇文章我不打算聊“哪个 AI 品牌天下第一”而是把重点放在四件事第一AI 写 PLC 程序的质量到底怎么测、怎么判断好坏第二主流 AI 品牌对三菱、西门子、汇川、CODESYS 等常见 PLC 环境的支持现状第三实际落地时主要会踩哪些坑比如指令集错误、数据类型不匹配、地址分配不合理第四给出一套可以直接照做的 AI 辅助 PLC 开发流程。如果你关心 AI 在工业自动化里的真实边界建议直接收藏。1. 核心能力速览先把结论性的信息放在前面。以下内容基于当前主流 AI 产品的公开能力和工业自动化社区的反馈整理具体到某个模型版本的表现建议按你实际使用的版本测试。能力项现状说明项目类型AI 辅助 PLC 程序生成、代码解释、故障排查主要支持 PLC 品牌西门子博途/S7、三菱GX Works、汇川、CODESYS 系、欧姆龙等生成代码形式主要是结构化文本ST、指令表IL梯形图LAD生成支持有限是否支持完整工程单段逻辑可生成完整工程OB/FC/FB/DB 联动需人工整合是否支持批量任务一次生成多段逻辑可以但需逐个验证是否支持 API 接入部分大模型支持 API可做私有化辅助工具硬件门槛无特殊要求网页端或 API 调用即可启动方式访问对应 AI 产品网页或通过 API 调用主要问题指令集混用、数据类型错误、地址分配硬编码、缺少安全逻辑适合场景程序框架生成、功能块封装、代码解释、报错排查、学习入门2. AI 写 PLC 程序的真实质量水平2.1 从测试结果看能写但离“下载即用”有距离从社区里多个横向测试看AI 写 PLC 程序的质量大概可以分三个层级。第一层是“框架级”。让 AI 生成一个电机启停控制的功能块包含启动按钮、停止按钮、接触器输出、热继电器反馈大部分主流 AI 产品都能生成结构清晰的结构化文本。变量声明完整逻辑顺序基本正确注释也像模像样。第二层是“调试级”。把 AI 生成的代码放进博途或者 GX Works 里编译开始出现报错。错误主要集中在数据类型不匹配比如把BOOL和INT直接做逻辑运算指令名称写错比如三菱的SET、RST和西门子的S、R混用定时器使用方式错误比如西门子的TON实例化方式与三菱的OUT T0 K10完全不同缺少全局变量和符号表映射AI 生成的地址经常需要手动重新分配。第三层是“危险级”。代码编译通过但逻辑存在安全隐患。比如缺少急停处理、缺少互锁、地址重复赋值、没有考虑扫描周期带来的竞争问题。这种代码如果直接下载到设备里跑轻则设备动作异常重则造成安全事故。2.2 不同 AI 品牌的支持差异从公开信息和工程师实测反馈来看不同 AI 产品在 PLC 编程上的表现有明显差异。国外的 GPT 系列和 Claude 系列在理解复杂指令方面较强。它们对西门子博途的 ST 语言、SCL 语言理解较好生成代码结构完整注释规范。但问题是对国内小众 PLC 品牌的支持较弱需要把指令集说明文档作为上下文提供给 AI。另外直接生成梯形图几乎不可能只能生成 ST 或 IL。国内的几个大模型产品对三菱 GX Works、汇川、信捷等品牌更熟悉一些。它们训练语料里中文技术论坛、工控博客、设备手册的占比高所以生成的三菱风格程序更贴近国内工程师的习惯。不过在复杂算法和大型工程结构方面代码组织能力略弱于国外头部模型。这里要说一句公道话AI 写 PLC 代码能力强不强很大程度取决于你给它的提示词带了多少上下文。同样是“写一个电机正反转控制”直接问和把“PLC 品牌、型号、输入输出表、安全要求、编程软件、指令集”一起给它生成质量完全不同。2.3 质量控制的关键人为校验不可省略从实际应用看AI 写 PLC 程序最大的风险不是生成不了而是生成结果“看起来对实际错”。常规 IT 代码写错了报错、崩溃、功能异常影响范围可控。PLC 代码如果逻辑错误设备可能直接动作涉及机械、电气、人身安全。所以我认为AI 写 PLC 程序短期内只能作为辅助工具不能作为替代工程师的工具。所有 AI 生成的代码都必须经过编译检查逻辑仿真空载测试带载试运行安全回路审查。3. 为什么 AI 在 PLC 编程上会翻车3.1 指令集和编程环境的碎片化这是 AI 写 PLC 程序最容易翻车的地方。PLC 不像 Python没有统一的标准库。三菱的指令和西门子的指令完全不同汇川和信捷的指令虽然接近三菱但细节又有差异。同一个功能在不同品牌上写出来的代码风格差异极大。更麻烦的是大模型训练数据里混入了各种来源的 PLC 代码包括不同品牌、不同版本、不同行业的代码。模型在生成时可能把三菱的写法混进西门子的代码里也可能把 CODESYS 的语法混进汇川的程序里。实际测试中AI 经常会把定时器、计数器、中断处理的用法搞混。比如// 错误示例把西门子 TON 和三菱 OUT T 混用 IF START THEN TON_IN(IN : true, PT : T#5S); // 西门子写法 OUT T0 K50; // 三菱写法混入后必报错 END_IF;这种错误在人工排查时需要花时间而且如果对指令集不熟的新手去看根本发现不了。3.2 缺少 IO 映射和符号表上下文PLC 程序不是孤立代码它要跟实际的输入输出点绑定。AI 生成代码时默认只会给你一套通用变量名比如M0、D100、Y0。但实际工程里这些地址需要和现场接线、模块通道、HMI 变量一一对应。AI 在没有任何工程上下文的情况下只能硬编码地址。这带来两个问题第一地址冲突。AI 不知道你哪些地址已经被用了可能把定时器用的T0和保持继电器用的M0混在一起编译时不一定报错但运行后逻辑混乱。第二可维护性差。工程上要求用符号名代替绝对地址比如用MOTOR_A_RUN代替Y0。AI 生成时往往直接用绝对地址导致程序可读性差后期维护困难。比较好的使用方式是把完整符号表、IO 地址分配表作为上下文窗口提供给 AI再让它生成程序。3.3 缺乏安全工程设计思维工业程序最核心的并不是“跑通”而是“出事时能停下来”。急停回路、安全门互锁、超限保护、故障反馈、复位条件这些是 PLC 程序里最关键的逻辑也是 AI 最容易忽略的部分。举例生成一个气缸控制程序AI 会写出电磁阀输出、到位检测、延时等待这些常规逻辑但很少有人工势能、气压不足报警、手动/自动模式切换、设备急停后的安全复位逻辑。不是 AI 不知道这些逻辑而是模型倾向于生成“高频代码”而安全逻辑在训练数据里往往只出现在特定行业程序里。所以在让 AI 生成代码时提示词里必须显式要求包含安全逻辑同时工程师在审查时必须检查安全回路。4. AI 辅助 PLC 开发的完整流程可直接照做这里给出一个我比较推荐的 AI 辅助 PLC 开发流程。这套流程不依赖特定 AI 品牌重点是把人工校验环节前置。4.1 第一步整理工程信息写结构化提示词AI 生成质量80% 取决于提示词质量。不要直接问“写一个 PLC 程序”要提供工程信息。请帮我生成为一个三菱 FX5U PLC 的电机正反转控制程序。 要求 1. 编程软件GX Works3 2. 编程语言结构化文本ST 3. 输入点 - X0正转启动按钮常开 - X1反转启动按钮常开 - X2停止按钮常闭 - X3热继电器反馈常开超限闭合 4. 输出点 - Y0正转接触器 - Y1反转接触器 5. 扩展要求 - 正转和反转必须有电气互锁和软件互锁 - 热继电器动作后程序锁定需要按停止按钮复位 - 每个输出带延时保护防止接触器频繁动作 - 变量使用符号名不要用绝对地址硬编码把这样的提示词发给 AI生成结果会好很多。而且你会发现即使不同 AI 品牌生成结果逻辑结构也基本可用差异主要在指令细节上。4.2 第二步编译检查 代码审查清单AI 生成代码后先不要急着仿真。打开 PLC 编程软件创建工程把代码粘贴进去编译。编译会有三种结果完全通过这时候需要人工审查逻辑规范性不能直接下载。少量报错这个最常见。根据报错信息修正指令格式或者把报错内容复制回 AI让 AI 自行修正。大量报错说明 AI 可能选错了指令集需要核对编程软件、PLC 型号、所用高级语言版本。人工审查时建议对照以下清单检查项检查内容地址分配是否与硬件配置一致是否有地址冲突数据类型BOOL/INT/REAL/TIME 是否使用正确定时器/计数器实例化方式是否正确定时范围是否合理互锁逻辑正反转、多设备联动是否具备互锁急停处理急停信号是否接入程序是否为常闭逻辑复位条件故障后是否能正常复位是否会出现自锁手动/自动切换两种模式是否互斥切换是否安全扫描周期问题是否存在需要在多个扫描周期内保持的状态4.3 第三步仿真和空载测试编译通过不代表逻辑正确。打开 PLC 编程软件的仿真功能逐个测试输入信号观察输出状态是否满足预期。重点测试异常场景同时按正转和反转输出应保持禁止热继电器动作后程序是否进入锁定状态急停按下后所有输出是否立即断开恢复供电后程序是否处于安全状态会不会自动启动设备。4.4 第四步带载试运行空载测试通过后断开执行机构只接输入信号和反馈信号在真实 PLC 上运行。观察变量变化确认逻辑无误后再接负载试运行。这一步建议做完整的动作记录每一步输入动作对应什么输出时间是多少是否有异常抖动。5. 常见问题与排查方法结合实际使用情况把 AI 写 PLC 程序时常见的问题整理如下问题现象可能原因排查方式解决方案生成代码编译报错AI 使用了错误的指令集查看报错行核对指令名称将报错信息发给 AI要求修正或换一种编程语言重写定时器写法不一致三菱/西门子/CODESYS 语法混用检查定时器实例化格式人工修正提示词里限定编程软件型号变量全部是绝对地址提示词未提供符号表查看变量声明部分要求 AI 使用符号名自己维护符号表映射程序逻辑正确但无法触发输出输入输出地址与硬件不一致对照 PLC 变量表检查修正地址映射缺少急停和保护逻辑AI 生成逻辑不完整检查程序框架提示词里显式要求安全逻辑人工补充生成代码在博途打不开语法混入了其他语言格式检查文件格式和代码风格转换成 SCL 语法或粘贴到正确编程界面多段代码无法整合每个功能块独立生成缺少调用关系检查主程序和功能块调用让 AI 先生成程序架构再生成各功能块AI 理解偏差导致逻辑不对提示词描述不清晰检查输入输出条件描述用表格形式写清控制要求和控制流程6. 适合 AI 辅助的 PLC 编程场景AI 写 PLC 程序目前还不是全场景适用。下面这些场景AI 能显著提升效率。6.1 功能块FB/FC封装这是 AI 目前最擅长的场景。让 AI 生成一个带输入输出参数的功能块比如电机控制、阀门控制、模拟量处理、PID 调节只要把接口定义和功能描述给足生成结果通常很规范。例如让 AI 生成一个模拟量平均值滤波功能块FUNCTION_BLOCK FB_AnalogAvgFilter VAR_INPUT bExecute : BOOL; // 执行信号 rRawValue : REAL; // 原始模拟量 uiChannel : UINT; // 通道号保留备用 END_VAR VAR_OUTPUT rFilteredValue : REAL; // 滤波后的值 bDone : BOOL; // 完成标志 END_VAR VAR arrBuffer : ARRAY[0..9] OF REAL; // 10点滑动窗口 uiIndex : UINT; uiCount : UINT; rSum : REAL; END_VAR // 当执行信号上升沿时将最新值写入环形缓冲并计算平均 IF bExecute THEN rSum : rSum - arrBuffer[uiIndex]; arrBuffer[uiIndex] : rRawValue; rSum : rSum rRawValue; uiIndex : (uiIndex 1) MOD 10; IF uiCount 10 THEN uiCount : uiCount 1; END_IF; rFilteredValue : rSum / UINT_TO_REAL(uiCount); bDone : TRUE; ELSE bDone : FALSE; END_IF;这类功能块有固定的输入输出接口逻辑相对标准化AI 生成的可靠性较高。6.2 代码解释与维护老工程师离职后留下一堆没有注释的 PLC 程序新工程师看不懂。这时候把代码片段复制给 AI让它解释每一段的作用能快速降低上手成本。实际测试中AI 对三菱的步进梯形图指令、西门子的 SCL 代码解释都相对准确。它甚至能告诉你某段代码可能存在的隐患比如定时器冲突、地址复用等。6.3 报错排查PLC 程序报错把报错信息和相关代码片段发给 AI往往能得到很具体的排查方向。比如常见的三菱“Device busy”错误、西门子的“Area length error”等AI 基本都能给出原因和常见解决方案。但这里要特别提醒AI 的诊断结果只能作为参考最终确认还是要结合编程软件的在线监控和实际设备状态。6.4 不适合 AI 的场景大型项目的整体架构设计、多轴运动控制、CNC 加工代码、安全 PLC 程序这些场景不建议让 AI 主导。原因很简单这些项目对逻辑正确性和安全性的要求远高于代码生成速度而且需要大量现场调试经验。如果你硬要让 AI 写一个多轴插补程序得到的代码要么只能作为参考要么根本跑不起来。7. 让 AI 输出更规范 PLC 代码的提示词模板这里给几个可以直接复制的提示词模板覆盖常见需求。7.1 标准程序生成模板你是具有 20 年经验的 PLC 高级工程师精通西门子 S7-1200/1500 博途开发。 请帮我编写一个 [功能名称] 程序使用 SCL 语言。 硬件信息 - PLC 型号[型号] - 编程软件[TIA Portal V17 / GX Works3] - 输入信号[列清楚每一个输入点] - 输出信号[列清楚每一个输出点] 控制要求 - [要求1控制逻辑] - [要求2安全保护] - [要求3手动/自动模式] - [要求4故障处理] 输出要求 - 使用有意义的符号变量名不要用绝对地址。 - 变量声明必须与逻辑代码分离。 - 每条逻辑必须包含中文注释。 - 必须包含急停、故障锁定和复位逻辑。 请先生成变量声明表再生成主体逻辑代码。7.2 代码修正提示词模板我有一段 [品牌] PLC 代码在编译时报错请你帮我修正。 PLC 型号[型号] 编程软件[软件名称及版本] 报错信息 [粘贴完整报错信息] 代码片段 [粘贴代码] 要求 1. 保留原有功能逻辑。 2. 修正指令集和数据类型问题。 3. 给出修改后的完整代码。 4. 标注哪些地方做了修改以及原因。7.3 代码解释提示词模板你是一名资深 PLC 工程师。以下是 [三菱/西门子/汇川] PLC 程序片段请逐行解释 [粘贴代码] 解释要求 1. 说明每段代码完成的功能。 2. 指出可能存在的逻辑缺陷或安全隐患。 3. 标注关键地址对应的作用。 4. 最后用一段话总结这个程序的整体逻辑。7.4 批量生成提示词模板如果需要生成多个功能块建议先用一个整体提示词生成程序架构再逐个生成功能块。请帮我设计一个 [设备类型] PLC 程序的整体架构。 架构要求 1. 列出主程序OB1/Main需要调用的所有功能块。 2. 每个功能块的功能范围、输入输出接口定义。 3. 功能块之间的调用顺序和数据流。 4. 所有全局变量的定义。 5. 程序执行扫描周期的分配建议。 确认架构无误后我会继续请你逐个生成功能块代码。这套模板的核心思路是把 AI 当实习生先向它交代背景再让它输出代码最后你来做 Code Review。8. 接口 API 与批量任务扩展如果你不是只想在网页里对话而是想把 AI 编程能力接进内部工具可以走 API 路线。目前主流大模型产品普遍提供 API 接口。可以让 AI 在本地或服务器上构建一个辅助编程服务传入控制要求文本返回生成代码。API 调用流程如下准备 API Key构造请求参数包含模型名称、提示词、温度、最大 token 等传入上面第 7 节写的提示词模板解析返回结果把生成的代码保存为文本文件再导入 PLC 编程软件中人工编译。Python 调用示例通用模板import requests import json # 需要替换为你的 API 地址和 Key api_url https://api.example.com/v1/chat/completions api_key your_api_key_here headers { Content-Type: application/json, Authorization: fBearer {api_key} } # 提示词内容按实际项目替换 prompt 请帮我编写一个三菱 FX5U PLC 电机正反转控制程序使用 GX Works3 ST 语言。 输入X0 正转启动X1 反转启动X2 停止X3 热继反馈。 输出Y0 正转接触器Y1 反转接触器。 要求包含互锁保护和故障复位逻辑变量使用符号名。 payload { model: your-model-name, messages: [ {role: user, content: prompt} ], temperature: 0.3, max_tokens: 2000 } response requests.post(api_url, headersheaders, jsonpayload, timeout120) result response.json() # 输出生成的代码 generated_code result[choices][0][message][content] print(generated_code)批量任务方面可以把多个控制需求写入 Excel 或 CSV每行包含设备名称、控制逻辑、IO 分配、安全要求再用 Python 循环构造提示词并调用 API生成结果逐行写入文件。批量调用时注意三点第一控制并发数避免触发限流第二每个请求保存到独立文件防止丢失第三生成完成后必须逐个人工编译验证。9. AI 写 PLC 程序的产品化建议如果你正在考虑把 AI 辅助编程做成团队内部的效率工具下面这几个建议可以参考。9.1 建立团队私有提示词库不同工程师写 PLC 程序的风格不同AI 生成的代码风格也会随提示词变化。建议团队整理一套标准提示词库包含设备类型清单电机、气缸、阀门、变频器标准功能块模板符号表格式安全逻辑清单常见错误修正指南。这样每次调用 AI生成结果都比较稳定人工审查成本也会降低。9.2 建立代码验证流程AI 生成代码必须与验证流程挂钩。比较稳妥的做法是生成代码 - 编译检查 - 功能仿真 - 代码审查 - 空载测试 - 带载试运行 - 归档。每一步都要有记录。特别是代码审查建议安排资深工程师执行不要只看编译通过就结束。9.3 限制 AI 的使用边界明确哪些环节允许 AI 参与哪些不允许。建议允许生成标准化功能块、代码解释、报错排查、生成测试用例限制涉及安全回路的保护逻辑AI 只能给参考必须人工重写禁止直接下载 AI 生成代码到实际生产设备不做任何测试。10. 未来方向与个人建议从这几个月的实际体验来看AI 写 PLC 程序的进步速度比想象中更快。随着大模型对工业指令集理解的加深生成质量的瓶颈大概率会从“能不能读懂指令”转移到“能不能理解设备运行的安全边界”。当前阶段如果你想用 AI 辅助 PLC 开发我会给这几个建议第一从功能块开始尝试不要一上来就让它写全套工程。功能块接口清晰、逻辑独立是 AI 最容易写对的场景。第二提示词里一定要写清楚 PLC 品牌、编程软件、输入输出定义和安全要求。信息越完整生成结果越好。第三不要跳过验证。AI 生成的代码必须编译、仿真、空载测试后再考虑下载到真实设备。第四把 AI 当同事不当老师。你给它清晰的工程背景它帮你产出一版可参考的初稿最后把关的是你。如果你正在做 PLC 项目想测试不同 AI 品牌的编程能力建议直接拿你手头一个已经做完的标准功能块隐藏答案让 AI 重新生成一版再和你的代码对比。你会发现这个测试过程本身比结果更有价值。