最近身边不少做设备维护和自动化集成的朋友都在问同一个问题AI 都已经能写 Java、写 Python、写 SQL 了那它能不能直接帮我写 PLC 程序不同品牌的 AI 到底哪个更靠谱如果真拿 AI 生成的控制逻辑去跑设备会不会翻车说实话我也用 AI 写过几次 PLC 程序包括三菱 FX 系列的简单启停控制、西门子 S7-1200 的交通灯逻辑还有 CODESYS 环境下的 ST 语言功能块。整个过程下来最大的感受是AI 在 PLC 领域比在 Web 开发领域“弱”很多这种弱并不体现在语言理解上而是体现在它对硬件、工艺、扫描周期和现场安全的理解几乎为零。这篇文章我不打算只讲结论而是把 AI 写 PLC 程序这件事从原理、实测、问题、排查到最佳实践完整拆一遍。无论你是刚接触 PLC 的电气工程师还是想评估“AI 编程替代人”的自动化项目负责人这篇文章都值得收藏。1. AI 写 PLC 程序这件事到底在讨论什么1.1 AI 写 PLC 和写普通代码有本质区别很多人第一次尝试让 AI 写 PLC 程序时会直接复制一个需求描述类似“用三菱 PLC 写一个电机正反转控制程序带互锁、带过载保护。”AI 确实会像模像样地给出一段代码。但问题是PLC 程序不是一个独立运行的算法它需要绑定具体的硬件 I/O 地址、编程软件版本、PLC 型号、扫描周期、还有现场操作逻辑。普通代码跑在服务器上错了最多报个 500 错误PLC 程序错了接触器可能直接炸、电机可能反转、机械手可能撞机。换句话说AI 写 PLC 程序本质上是在“写代码片段”而不是在“完成一个控制方案”。它缺的是对真实物理世界的感知。1.2 为什么 PLC 程序这么难被 AI 替代我们可以从几个角度理解这个问题编程范式不同。PLC 的主流语言不止一种梯形图LD、结构化文本ST、指令表IL、功能块图FBD、顺序功能图SFC都有人在用。AI 生成 ST 还算顺手但生成梯形图只能输出文字版指令没法直接生成图形化梯形图需要人工再去 IDE 里重画一遍。厂商生态严重割裂。三菱用 GX Works西门子用 TIA Portal汇川用 AutoShop倍福用 TwinCATCODESYS 又是一套体系。每家对指令命名、数据类型、定时器格式、地址编号都有自己的方言。程序需要绑定 I/O 点表。AI 不知道你现场接的是 X0 还是 X1不知道急停接常闭还是常开不知道按钮是接到输入模块还是通过触摸屏变量下发。它只能生成一堆占位符。安全与工艺逻辑不可生成。互锁、急停、复位、报警分级、手动/自动切换、上电初始化、断电保持这些属于工艺经验和安全规范AI 很难自动补全。1.3 真实使用场景有哪些虽然 AI 不能直接替代 PLC 工程师但在实际工作中它的确能在几个场景帮上忙生成 ST 语言模板、功能块骨架比如 PID 控制块、定时器封装、状态机框架。解释老旧 PLC 程序把一段看不懂的梯形图指令文字版贴给它让它用中文描述逻辑。做语法转换比如把三菱风格的代码改成西门子风格虽然不能直接用但能提供修改思路。辅助排错把编译报错信息和程序片段丢给它让它给排查方向。当“编程老师”随时问它某个指令是什么含义、某个数据类型怎么用。2. 各家 AI 在 PLC 编程方向的支持性现状2.1 国外大模型的总体表现从实际内容生成质量来看国外主流大模型对 PLC 的“常识性认识”明显更多。它们能比较准确地写出西门子 S7-1200 的 ST 语言功能块、CODESYS 的结构化文本也能写出三菱 FX 系列的基础指令。对主流 PLC 品牌的指令名、数据类型、常见库函数出错率相对较低。但这里有一个容易被忽略的问题模型知识库里的 PLC 资料很多来自英文手册、技术论坛和开源项目。一旦你要求它生成“符合国内电工习惯”的梯形图描述或者涉及国产 PLC 特殊指令它的表现就会明显下降。2.2 国内大模型的优劣势国内大模型在中文问答和国产 PLC 知识覆盖上有一定优势。你问它“台达 PLC 的 DVP 系列怎么读模拟量”它往往能给出比较接近实际的内容。但问题也很明显就是容易“一本正经地编造”。比如你问一个冷门指令它不会直接说不知道而是会生成一个看起来很像、但实际并不存在的指令名或功能号。这类情况在国产 PLC 的现场调试中非常危险因为工程师如果把 AI 编造的指令敲进 IDE编译报错还是小事最怕的是它编出一个能编译但逻辑错误的程序让人误以为代码没问题。2.3 代码助手类工具的表现除了通用对话式 AI现在也有不少 AI 编程助手因为它们嵌入在 IDE 中所以对代码库的理解能力比网页版强。但在 PLC IDE 里这些助手的支持普遍不算好。主要原因有两点三菱 GX Works、西门子 TIA Portal 这类软件的代码编辑区不是标准的文本编辑器AI 插件很难有效读取上下文。梯形图是图形化编辑AI 助手的“补全”机制根本派不上用场。所以在当前阶段代码助手类工具更适合用在以文本为主的 CODESYS、TwinCAT 或汇川 AutoShop 的 ST 语言编辑场景里。2.4 不同 AI 品牌支持性对比表先声明一点下面的表格是基于我实际体验和综合技术社区反馈整理出来的“总体取向”不是实验室跑分不同模型版本发布后结果可能会有变化。对比维度国外通用大模型国内通用大模型AI 编程助手IDE 插件ST 语言生成质量较好逻辑清晰中等偶有编造一般依赖上下文三菱指令覆盖中等较好较弱西门子指令覆盖较好中等较弱国产 PLC 覆盖较弱较好较弱梯形图支持只能输出文字描述只能输出文字描述几乎不支持图形化现场工艺逻辑不会自动补全不会自动补全不会自动补全解释老程序较好较好一般编译排错能提供思路能提供思路一般从这张表能看出一个核心结论目前没有任何 AI 品牌能做到“输入需求直接输出可上线的 PLC 程序”。AI 更适合做“编程辅助工具”而不是“程序生成器”。3. 环境准备开始测试 AI 写 PLC 程序前需要准备什么3.1 硬件与软件环境如果你想亲自测试 AI 写 PLC 程序的质量不一定要买一套真实的 PLC但至少要有对应的编程软件和仿真环境。我建议准备这样的环境操作系统Windows 10/11绝大多数 PLC 编程软件只支持 Windows。三菱系列GX Works2 或 GX Works3老工程师常用来学习 FX 系列。建议配合 GX Simulator 仿真器使用。西门子系列TIA Portal博途版本根据你的实际项目需求选择因为它安装体积大对电脑性能有一定要求。建议使用 PLCSIM 做仿真验证。CODESYS 系列CODESYS Development System可以免费试用非常适合测试 AI 生成的 ST 语言程序。汇川系列AutoShop 或 InoProShop如果你关注国产 PLC这是很好的测试环境。一个能稳定访问 AI 工具的浏览器或 API 接口注意账号权限和费用问题。版本需要根据你的项目实际情况调整以上示例以常见环境为例重点演示测试思路。3.2 人员准备测试 AI 写 PLC 程序最怕的不是 AI 写得烂而是你根本看不出它哪里写得烂。所以建议参与测试的人至少具备以下能力了解最基本的 PLC 工作原理知道扫描周期、输入刷新、输出刷新这些概念。看过一门语言的基础语法比如三菱的 LD、LDI、OUT、SET、RST或者西门子的 I0.0/Q0.0、TON、TOF。会使用至少一种 PLC 编程软件的仿真功能。具备最基本的电气安全意识知道互锁和急停意味着什么。如果你完全是零基础建议先不要直接拿 AI 生成的程序去套设备否则现场出了问题AI 不会替你承担责任。3.3 安全红线在开始测试之前我必须强调一条安全底线绝对不要把 AI 生成的程序直接下载到真实 PLC 里运行尤其是控制伺服、变频器、气缸、机械手的设备。正确流程应该是AI 生成代码 - 工程师审查 - 编译检查 - 仿真测试 - 空载测试 - 小范围带载测试 - 确认无误后投入生产。这条流程不是保守而是行业事故教训总结出来的红线。4. 实测让 AI 写一个三菱 PLC 电机正反转控制程序4.1 需求描述为了验证 AI 写 PLC 程序的质量我设计了一个非常经典的控制需求“使用三菱 FX 系列 PLC 编写三相异步电机正反转控制程序。要求正转按钮 X0 启动正转反转按钮 X1 启动反转停止按钮 X2 停止正转接触器 Y0反转接触器 Y1必须实现电气互锁和程序互锁热继电器常闭触点 X3 串入控制回路要求程序逻辑完整注释清晰。”这个需求已经写得相当具体如果 AI 连这样的题目都做不好那更复杂的系统就更不用提了。4.2 AI 生成的 ST 风格参考代码需要说明的是三菱 FX 系列常用的编程语言是梯形图或指令表但为了让 AI 生成的内容更接近文本可读我要求它用结构化文本的思维去描述然后手工转换成指令。AI 给出的核心逻辑思路如下这段代码是示意用于展示 AI 的架构能力不能直接复制到 GX Works 运行// 需求三菱 FX 系列电机正反转控制 // 输入点分配 // X0 正转按钮X1 反转按钮X2 停止按钮X3 热继电器常闭 // 输出点分配 // Y0 正转接触器Y1 反转接触器 // 程序逻辑 // 1. 正转启动条件X0 按下 且 未按停止 且 热继电器正常 且 反转未启动 // 2. 反转启动条件X1 按下 且 未按停止 且 热继电器正常 且 正转未启动 // 3. 正转自锁Y0 保持 // 4. 反转自锁Y1 保持 // 5. 程序互锁正转时禁止反转反转时禁止正转 // 6. 停止优先X2 按下时无论正转反转都停止如果把它翻译成接近三菱指令表的格式比较理想的结果是LD X000 OR Y000 ANI X002 ANI X003 ANI Y001 OUT Y000 LD X001 OR Y001 ANI X002 ANI X003 ANI Y000 OUT Y001看到这里你会发现这段代码的逻辑框架是正确的自锁、停止优先、热继电器保护、正反转互锁都考虑到了。这反映出 AI 对“电机正反转”这个经典案例的学习是很充分的。4.3 这段程序的问题在哪里虽然 AI 写出的核心逻辑没问题但它主要的问题在于“过度理想化”地址分配只是假设。AI 不知道你实际工程里 X0~X3 到底接的是什么设备如果现场接线是急停常闭点那么停止按钮逻辑可能要改成常闭处理。缺少上电初始化逻辑。对于真实设备通常需要确保 PLC 上电瞬间电机不会突然启动还要考虑停电再来电时的安全状态。缺少手动/自动切换、报警复位、运行状态指示等扩展逻辑。没有考虑硬件接线层面的互锁。程序互锁只能防止程序内部同时输出但接触器本身还应该有电气互锁触点AI 不会提醒你这一点。所以结论是AI 能完成核心逻辑但离“可投产”还有很长的距离。4.4 让 AI 写一个带定时器控制的交通灯程序再看一个稍微复杂一点的例子。需求是“用西门子 S7-1200 的 ST 语言编写一个十字路口交通灯程序要求南北绿灯 20 秒、黄灯 3 秒、红灯 23 秒东西方向与南北方向相反使用定时器实现。”AI 给出的思路通常是// 假设使用 TON 定时器 // 1. 初始化阶段南北绿灯东西红灯 // 2. 20 秒后南北绿灯灭南北黄灯亮 // 3. 3 秒后南北红灯亮东西绿灯亮 // 4. 如此循环如果是在 CODESYS 或 S7-1200 的 ST 语言中可以用 IF 语句加 TON 实例实现。AI 对这种“多个定时器形成固定时序”的逻辑理解得还算不错因为它本质上是一个简单的状态机。但如果你进一步问它“黄灯闪烁频率是多少”“夜间模式下红黄灯都闪光”“发生故障时全部红灯闪烁”它就需要你先给出明确的工艺要求否则它只会按最常见的默认逻辑来写。4.5 实验结果总结从这两个实验可以看出经典控制电路AI 正确率高基本逻辑可靠。带定时器的时序逻辑AI 能够完成但需要你清晰定义状态流转条件。涉及地址分配、硬件接线、安全联锁、工艺异常处理AI 基本不会主动考虑需要工程师补齐。5. AI 写 PLC 程序的六大主要问题5.1 指令与语法的“幻觉”问题AI 幻觉是当前所有内容生成工具的通病在 PLC 编程里表现得尤其明显。原因是 PLC 编程的语料库远没有 Java、Python 那么丰富很多冷门指令在网上只有零星几篇文章。典型表现把三菱的 MPS/MRD/MPP 堆栈指令写成不存在的“MPL”指令。把西门子的 TON 定时器格式写错比如忘记在定时器名后面加实例名。把 CODESYS 的 TRUE/FALSE 写成 1/0导致语法报错。编造一个看起来合理的功能块但实际上并不存在。应对方式很简单AI 生成的内容必须经过编译器和仿真器验证不能让 AI 当“最终裁判”。5.2 厂商生态差异性导致代码“水土不服”三菱、西门子、汇川、倍福虽然在基础逻辑上都遵循 IEC 61131-3 标准但实际使用差异很大。以定时器为例三菱的定时器是 T0~T255直接用 OUT T0 K20 表示 2 秒。西门子 S7-1200 是 TON、TOF、TP 功能块需要指定 IN、PT、Q、ET 引脚。CODESYS 里是 TON 实例PT 需要用 T#2S 或 TIME 类型变量。你把三菱风格的定时器代码塞进 TIA Portal根本编译不过。AI 很容易混淆这些差异尤其当你在对话中没有明确说明 PLC 品牌和编程软件时。所以最佳实践是每次提问时把“PLC 品牌 具体型号 编程软件 数据类型要求”写清楚。这比任何提示词技巧都重要。5.3 地址绑定与硬件组态缺失PLC 程序是面向硬件的程序。AI 生成代码时不知道你现场使用了哪些输入输出点不知道传感器是 NPN 还是 PNP不知道模拟量模块是 0~10V 还是 4~20mA。这时候 AI 只能生成占位符地址比如 X0、Y0 或者 I0.0、Q0.0。如果你直接把代码下载到真实设备地址对不上轻则设备不动作重则误动作引发事故。正确做法是在让 AI 生成程序之前先手工整理好 I/O 点表把每个输入输出点的地址、名称、功能、电气特性都列出来一起发给 AI。5.4 忽视扫描周期和实时性PLC 程序是循环扫描执行的执行周期一般只有几毫秒到几十毫秒。这决定了它不能像写普通软件那样写阻塞等待。AI 在生成代码时经常会出现这样的问题在 ST 语言里写 for 循环等待 1 秒这会导致程序卡住扫描周期异常。把多个定时器串联在一起导致时序意外拉长。使用了需要沿触发的边沿指令但没有考虑扫描周期的刷新时刻。这些问题在仿真器里不太容易暴露只有在真实设备运行时会表现出“动作不稳定”的现象。排查起来非常费劲。5.5 梯形图表达能力不足很多老师傅习惯看梯形图而 AI 在文本对话中只能输出指令表或 ST 语言很难直接生成一个真正可用的梯形图文件。虽然你可以让 AI 用文字描述“第一行左边是 X0 常开触点第二行……”然后自己在 GX Works 里画但这种人工翻译效率很低而且容易出错。5.6 缺少安全逻辑与工艺经验这是最致命的问题。AI 可能知道“互锁”这个概念但它不知道你的设备在什么情况下必须急停不知道两个气缸如果同时动作会不会撞在一起不知道停电恢复后设备应该保持什么状态。安全逻辑必须由熟悉工艺、熟悉设备的工程师来把关AI 只能作为一个“逻辑参考”而不是“安全审核人”。6. 如何判断和验证 AI 生成的 PLC 程序6.1 第一步语法编译检查无论 AI 生成的是 ST 语言还是指令表第一步就是把代码粘贴进对应的编程软件进行编译。编译器会帮你拦截语法错误、数据类型不匹配、指令不存在等问题。这一步可以过滤掉大部分“AI 幻觉”类错误但请注意能编译通过不代表逻辑正确。6.2 第二步仿真运行大多数主流 PLC 编程软件都支持仿真运行。三菱 GX Works2 配合 GX Simulator。西门子 TIA Portal 配合 PLCSIM。CODESYS 自带软 PLC 仿真环境。汇川 InoProShop 支持在线仿真。仿真环境里可以手动强制输入点观察输出点变化。对于交通灯、流水线节拍这类不涉及危险设备的程序仿真测试已经能覆盖绝大部分问题。6.3 第三步按 I/O 点表走查把 AI 生成的程序拿到真实项目里之前建议对照 I/O 点表逐行走查每个输入点是否与现场实际接线地址一致。每个输出点对应的接触器、阀岛、伺服使能是否匹配。是否考虑了常开/常闭逻辑。是否包含急停、复位、报警输出。是否有手动/自动切换切换时输出是否安全。6.4 第四步让 AI 解释自己写的代码很多人不知道让 AI 解释它自己生成的代码也是验证逻辑的一种好方法。你可以直接问“请逐行解释你生成的正转启动逻辑特别说明在什么情况下 Y0 会保持为 ON。”如果 AI 的解释逻辑清晰、前后一致说明它确实是在按需求生成如果解释含糊、自相矛盾那这段代码可能只是“看起来像样”。6.5 第五步空载测试与小范围带载测试如果条件允许在完成上述检查后可以先做空载测试不给电机通电只观察接触器动作是否正确。然后再在低风险设备上做小范围带载测试。这个过程必须有工程师全程在场并且保证急停有效、有人值守。7. 最佳实践如何把 AI 变成 PLC 编程的辅助工具7.1 把 AI 当“语法助手”而不是“方案设计者”AI 最擅长的是帮你写出语法正确、结构完整的代码片段而不是帮你设计整个控制方案。控制方案必须基于工艺工艺必须来自现场。所以推荐的使用方式是提出明确需求包括输入输出清单、控制流程、异常要求。让 AI 生成代码框架。你再根据现场情况调整地址、补充安全逻辑。7.2 用提示词模板提高生成质量如果你想让 AI 生成更接近可用的 PLC 程序建议使用统一的提示词模板。下面是一个参考请帮我编写一个 [三菱 FX3U / 西门子 S7-1200 / CODESYS] 的 PLC 程序。 项目背景[一句话描述设备或工艺] 输入点表 X0启动按钮常开 X1停止按钮常闭 X2急停按钮常闭 输出点表 Y0主接触器 Y1报警灯 控制要求 1. 按下启动按钮后Y0 输出并自锁 2. 停止按钮或急停按钮按下时Y0 立即断开 3. 程序应使用 [梯形图 / ST 语言 / 指令表] 形式输出 4. 请标注必要的注释并提醒我哪些地方需要根据实际接线调整。把这段模板复制给你的 AI 工具生成质量会明显高于直接问“帮我写个 PLC 程序”。7.3 用 AI 解释老项目程序AI 在 PLC 领域最有实用价值的功能之一就是解释老程序。你可以把一段无注释的指令表或 ST 代码贴给它然后问“请用中文逐段解释这段程序实现什么功能指出哪些地方有隐患。”AI 通常会给出比较专业的解释也能发现一些明显的逻辑漏洞。这对接手老项目的工程师帮助很大。7.4 用 AI 做多人审查的“第二双眼睛”在程序写完、仿真通过之后可以把完整代码发给 AI让它以“独立审核员”的身份找问题。比如“请帮我审查这段电机控制在逻辑上有哪些安全隐患比如缺少互锁、缺少急停、扫描周期问题等。”AI 虽然不能替代人工审核但它往往能发现一些因为“思维惯性”而被忽略的问题相当于成本很低的代码复查环节。8. 常见问题排查清单问题现象常见原因排查思路AI 生成的代码编译报错语法不对或使用了不存在的指令确认 PLC 品牌和编程软件让 AI 重新生成对应语法AI 把不同品牌指令混用提问时没有说明 PLC 型号在提示词中写清厂商、系列、编程软件程序能编译但设备不动作地址与实际 I/O 不一致对照 I/O 点表逐项核对地址分配动作顺序不稳定扫描周期、定时器使用不合理在仿真器中逐周期观察输出变化缺少互锁导致设备碰撞AI 不了解工艺未自动补全安全逻辑人工补全安全联锁禁止直接投产AI 编造冷门指令训练数据不充分以官方编程手册为准不要盲目相信 AI 回答梯形图无法生成文件AI 当前只能输出文本让 AI 输出指令表再在 IDE 中生成梯形图9. 总结与建议关于 AI 写 PLC 程序我目前的结论是不要指望 AI 直接生成一套可投运的完整程序但也不要低估 AI 在代码模板、逻辑解释、语法参考和排错思路上带来的效率提升。如果你是一名自动化工程师可以把它当作“随时在线的老工程师助理”让它帮你快速生成初版逻辑、解释一段陌生代码、排查一个编译问题。如果你是一名刚学 PLC 的新手AI 的最大价值是帮你快速理解指令含义和控制思路但千万不要把 AI 答题式生成的程序当成标准答案一定要用仿真器验证。真正能在 PLC 岗位上把 AI 用得好的人不是依赖 AI 生成多少代码而是懂得如何把需求描述清楚、如何审核逻辑、如何把安全边界牢牢握在自己手里。你越懂工艺就越能用好 AI你越不懂工艺AI 给你的只是看似完美的“幻觉”。 AI写PLC程序能行吗？从三菱西门子实测到安全落地的完整指南
最近身边不少做设备维护和自动化集成的朋友都在问同一个问题AI 都已经能写 Java、写 Python、写 SQL 了那它能不能直接帮我写 PLC 程序不同品牌的 AI 到底哪个更靠谱如果真拿 AI 生成的控制逻辑去跑设备会不会翻车说实话我也用 AI 写过几次 PLC 程序包括三菱 FX 系列的简单启停控制、西门子 S7-1200 的交通灯逻辑还有 CODESYS 环境下的 ST 语言功能块。整个过程下来最大的感受是AI 在 PLC 领域比在 Web 开发领域“弱”很多这种弱并不体现在语言理解上而是体现在它对硬件、工艺、扫描周期和现场安全的理解几乎为零。这篇文章我不打算只讲结论而是把 AI 写 PLC 程序这件事从原理、实测、问题、排查到最佳实践完整拆一遍。无论你是刚接触 PLC 的电气工程师还是想评估“AI 编程替代人”的自动化项目负责人这篇文章都值得收藏。1. AI 写 PLC 程序这件事到底在讨论什么1.1 AI 写 PLC 和写普通代码有本质区别很多人第一次尝试让 AI 写 PLC 程序时会直接复制一个需求描述类似“用三菱 PLC 写一个电机正反转控制程序带互锁、带过载保护。”AI 确实会像模像样地给出一段代码。但问题是PLC 程序不是一个独立运行的算法它需要绑定具体的硬件 I/O 地址、编程软件版本、PLC 型号、扫描周期、还有现场操作逻辑。普通代码跑在服务器上错了最多报个 500 错误PLC 程序错了接触器可能直接炸、电机可能反转、机械手可能撞机。换句话说AI 写 PLC 程序本质上是在“写代码片段”而不是在“完成一个控制方案”。它缺的是对真实物理世界的感知。1.2 为什么 PLC 程序这么难被 AI 替代我们可以从几个角度理解这个问题编程范式不同。PLC 的主流语言不止一种梯形图LD、结构化文本ST、指令表IL、功能块图FBD、顺序功能图SFC都有人在用。AI 生成 ST 还算顺手但生成梯形图只能输出文字版指令没法直接生成图形化梯形图需要人工再去 IDE 里重画一遍。厂商生态严重割裂。三菱用 GX Works西门子用 TIA Portal汇川用 AutoShop倍福用 TwinCATCODESYS 又是一套体系。每家对指令命名、数据类型、定时器格式、地址编号都有自己的方言。程序需要绑定 I/O 点表。AI 不知道你现场接的是 X0 还是 X1不知道急停接常闭还是常开不知道按钮是接到输入模块还是通过触摸屏变量下发。它只能生成一堆占位符。安全与工艺逻辑不可生成。互锁、急停、复位、报警分级、手动/自动切换、上电初始化、断电保持这些属于工艺经验和安全规范AI 很难自动补全。1.3 真实使用场景有哪些虽然 AI 不能直接替代 PLC 工程师但在实际工作中它的确能在几个场景帮上忙生成 ST 语言模板、功能块骨架比如 PID 控制块、定时器封装、状态机框架。解释老旧 PLC 程序把一段看不懂的梯形图指令文字版贴给它让它用中文描述逻辑。做语法转换比如把三菱风格的代码改成西门子风格虽然不能直接用但能提供修改思路。辅助排错把编译报错信息和程序片段丢给它让它给排查方向。当“编程老师”随时问它某个指令是什么含义、某个数据类型怎么用。2. 各家 AI 在 PLC 编程方向的支持性现状2.1 国外大模型的总体表现从实际内容生成质量来看国外主流大模型对 PLC 的“常识性认识”明显更多。它们能比较准确地写出西门子 S7-1200 的 ST 语言功能块、CODESYS 的结构化文本也能写出三菱 FX 系列的基础指令。对主流 PLC 品牌的指令名、数据类型、常见库函数出错率相对较低。但这里有一个容易被忽略的问题模型知识库里的 PLC 资料很多来自英文手册、技术论坛和开源项目。一旦你要求它生成“符合国内电工习惯”的梯形图描述或者涉及国产 PLC 特殊指令它的表现就会明显下降。2.2 国内大模型的优劣势国内大模型在中文问答和国产 PLC 知识覆盖上有一定优势。你问它“台达 PLC 的 DVP 系列怎么读模拟量”它往往能给出比较接近实际的内容。但问题也很明显就是容易“一本正经地编造”。比如你问一个冷门指令它不会直接说不知道而是会生成一个看起来很像、但实际并不存在的指令名或功能号。这类情况在国产 PLC 的现场调试中非常危险因为工程师如果把 AI 编造的指令敲进 IDE编译报错还是小事最怕的是它编出一个能编译但逻辑错误的程序让人误以为代码没问题。2.3 代码助手类工具的表现除了通用对话式 AI现在也有不少 AI 编程助手因为它们嵌入在 IDE 中所以对代码库的理解能力比网页版强。但在 PLC IDE 里这些助手的支持普遍不算好。主要原因有两点三菱 GX Works、西门子 TIA Portal 这类软件的代码编辑区不是标准的文本编辑器AI 插件很难有效读取上下文。梯形图是图形化编辑AI 助手的“补全”机制根本派不上用场。所以在当前阶段代码助手类工具更适合用在以文本为主的 CODESYS、TwinCAT 或汇川 AutoShop 的 ST 语言编辑场景里。2.4 不同 AI 品牌支持性对比表先声明一点下面的表格是基于我实际体验和综合技术社区反馈整理出来的“总体取向”不是实验室跑分不同模型版本发布后结果可能会有变化。对比维度国外通用大模型国内通用大模型AI 编程助手IDE 插件ST 语言生成质量较好逻辑清晰中等偶有编造一般依赖上下文三菱指令覆盖中等较好较弱西门子指令覆盖较好中等较弱国产 PLC 覆盖较弱较好较弱梯形图支持只能输出文字描述只能输出文字描述几乎不支持图形化现场工艺逻辑不会自动补全不会自动补全不会自动补全解释老程序较好较好一般编译排错能提供思路能提供思路一般从这张表能看出一个核心结论目前没有任何 AI 品牌能做到“输入需求直接输出可上线的 PLC 程序”。AI 更适合做“编程辅助工具”而不是“程序生成器”。3. 环境准备开始测试 AI 写 PLC 程序前需要准备什么3.1 硬件与软件环境如果你想亲自测试 AI 写 PLC 程序的质量不一定要买一套真实的 PLC但至少要有对应的编程软件和仿真环境。我建议准备这样的环境操作系统Windows 10/11绝大多数 PLC 编程软件只支持 Windows。三菱系列GX Works2 或 GX Works3老工程师常用来学习 FX 系列。建议配合 GX Simulator 仿真器使用。西门子系列TIA Portal博途版本根据你的实际项目需求选择因为它安装体积大对电脑性能有一定要求。建议使用 PLCSIM 做仿真验证。CODESYS 系列CODESYS Development System可以免费试用非常适合测试 AI 生成的 ST 语言程序。汇川系列AutoShop 或 InoProShop如果你关注国产 PLC这是很好的测试环境。一个能稳定访问 AI 工具的浏览器或 API 接口注意账号权限和费用问题。版本需要根据你的项目实际情况调整以上示例以常见环境为例重点演示测试思路。3.2 人员准备测试 AI 写 PLC 程序最怕的不是 AI 写得烂而是你根本看不出它哪里写得烂。所以建议参与测试的人至少具备以下能力了解最基本的 PLC 工作原理知道扫描周期、输入刷新、输出刷新这些概念。看过一门语言的基础语法比如三菱的 LD、LDI、OUT、SET、RST或者西门子的 I0.0/Q0.0、TON、TOF。会使用至少一种 PLC 编程软件的仿真功能。具备最基本的电气安全意识知道互锁和急停意味着什么。如果你完全是零基础建议先不要直接拿 AI 生成的程序去套设备否则现场出了问题AI 不会替你承担责任。3.3 安全红线在开始测试之前我必须强调一条安全底线绝对不要把 AI 生成的程序直接下载到真实 PLC 里运行尤其是控制伺服、变频器、气缸、机械手的设备。正确流程应该是AI 生成代码 - 工程师审查 - 编译检查 - 仿真测试 - 空载测试 - 小范围带载测试 - 确认无误后投入生产。这条流程不是保守而是行业事故教训总结出来的红线。4. 实测让 AI 写一个三菱 PLC 电机正反转控制程序4.1 需求描述为了验证 AI 写 PLC 程序的质量我设计了一个非常经典的控制需求“使用三菱 FX 系列 PLC 编写三相异步电机正反转控制程序。要求正转按钮 X0 启动正转反转按钮 X1 启动反转停止按钮 X2 停止正转接触器 Y0反转接触器 Y1必须实现电气互锁和程序互锁热继电器常闭触点 X3 串入控制回路要求程序逻辑完整注释清晰。”这个需求已经写得相当具体如果 AI 连这样的题目都做不好那更复杂的系统就更不用提了。4.2 AI 生成的 ST 风格参考代码需要说明的是三菱 FX 系列常用的编程语言是梯形图或指令表但为了让 AI 生成的内容更接近文本可读我要求它用结构化文本的思维去描述然后手工转换成指令。AI 给出的核心逻辑思路如下这段代码是示意用于展示 AI 的架构能力不能直接复制到 GX Works 运行// 需求三菱 FX 系列电机正反转控制 // 输入点分配 // X0 正转按钮X1 反转按钮X2 停止按钮X3 热继电器常闭 // 输出点分配 // Y0 正转接触器Y1 反转接触器 // 程序逻辑 // 1. 正转启动条件X0 按下 且 未按停止 且 热继电器正常 且 反转未启动 // 2. 反转启动条件X1 按下 且 未按停止 且 热继电器正常 且 正转未启动 // 3. 正转自锁Y0 保持 // 4. 反转自锁Y1 保持 // 5. 程序互锁正转时禁止反转反转时禁止正转 // 6. 停止优先X2 按下时无论正转反转都停止如果把它翻译成接近三菱指令表的格式比较理想的结果是LD X000 OR Y000 ANI X002 ANI X003 ANI Y001 OUT Y000 LD X001 OR Y001 ANI X002 ANI X003 ANI Y000 OUT Y001看到这里你会发现这段代码的逻辑框架是正确的自锁、停止优先、热继电器保护、正反转互锁都考虑到了。这反映出 AI 对“电机正反转”这个经典案例的学习是很充分的。4.3 这段程序的问题在哪里虽然 AI 写出的核心逻辑没问题但它主要的问题在于“过度理想化”地址分配只是假设。AI 不知道你实际工程里 X0~X3 到底接的是什么设备如果现场接线是急停常闭点那么停止按钮逻辑可能要改成常闭处理。缺少上电初始化逻辑。对于真实设备通常需要确保 PLC 上电瞬间电机不会突然启动还要考虑停电再来电时的安全状态。缺少手动/自动切换、报警复位、运行状态指示等扩展逻辑。没有考虑硬件接线层面的互锁。程序互锁只能防止程序内部同时输出但接触器本身还应该有电气互锁触点AI 不会提醒你这一点。所以结论是AI 能完成核心逻辑但离“可投产”还有很长的距离。4.4 让 AI 写一个带定时器控制的交通灯程序再看一个稍微复杂一点的例子。需求是“用西门子 S7-1200 的 ST 语言编写一个十字路口交通灯程序要求南北绿灯 20 秒、黄灯 3 秒、红灯 23 秒东西方向与南北方向相反使用定时器实现。”AI 给出的思路通常是// 假设使用 TON 定时器 // 1. 初始化阶段南北绿灯东西红灯 // 2. 20 秒后南北绿灯灭南北黄灯亮 // 3. 3 秒后南北红灯亮东西绿灯亮 // 4. 如此循环如果是在 CODESYS 或 S7-1200 的 ST 语言中可以用 IF 语句加 TON 实例实现。AI 对这种“多个定时器形成固定时序”的逻辑理解得还算不错因为它本质上是一个简单的状态机。但如果你进一步问它“黄灯闪烁频率是多少”“夜间模式下红黄灯都闪光”“发生故障时全部红灯闪烁”它就需要你先给出明确的工艺要求否则它只会按最常见的默认逻辑来写。4.5 实验结果总结从这两个实验可以看出经典控制电路AI 正确率高基本逻辑可靠。带定时器的时序逻辑AI 能够完成但需要你清晰定义状态流转条件。涉及地址分配、硬件接线、安全联锁、工艺异常处理AI 基本不会主动考虑需要工程师补齐。5. AI 写 PLC 程序的六大主要问题5.1 指令与语法的“幻觉”问题AI 幻觉是当前所有内容生成工具的通病在 PLC 编程里表现得尤其明显。原因是 PLC 编程的语料库远没有 Java、Python 那么丰富很多冷门指令在网上只有零星几篇文章。典型表现把三菱的 MPS/MRD/MPP 堆栈指令写成不存在的“MPL”指令。把西门子的 TON 定时器格式写错比如忘记在定时器名后面加实例名。把 CODESYS 的 TRUE/FALSE 写成 1/0导致语法报错。编造一个看起来合理的功能块但实际上并不存在。应对方式很简单AI 生成的内容必须经过编译器和仿真器验证不能让 AI 当“最终裁判”。5.2 厂商生态差异性导致代码“水土不服”三菱、西门子、汇川、倍福虽然在基础逻辑上都遵循 IEC 61131-3 标准但实际使用差异很大。以定时器为例三菱的定时器是 T0~T255直接用 OUT T0 K20 表示 2 秒。西门子 S7-1200 是 TON、TOF、TP 功能块需要指定 IN、PT、Q、ET 引脚。CODESYS 里是 TON 实例PT 需要用 T#2S 或 TIME 类型变量。你把三菱风格的定时器代码塞进 TIA Portal根本编译不过。AI 很容易混淆这些差异尤其当你在对话中没有明确说明 PLC 品牌和编程软件时。所以最佳实践是每次提问时把“PLC 品牌 具体型号 编程软件 数据类型要求”写清楚。这比任何提示词技巧都重要。5.3 地址绑定与硬件组态缺失PLC 程序是面向硬件的程序。AI 生成代码时不知道你现场使用了哪些输入输出点不知道传感器是 NPN 还是 PNP不知道模拟量模块是 0~10V 还是 4~20mA。这时候 AI 只能生成占位符地址比如 X0、Y0 或者 I0.0、Q0.0。如果你直接把代码下载到真实设备地址对不上轻则设备不动作重则误动作引发事故。正确做法是在让 AI 生成程序之前先手工整理好 I/O 点表把每个输入输出点的地址、名称、功能、电气特性都列出来一起发给 AI。5.4 忽视扫描周期和实时性PLC 程序是循环扫描执行的执行周期一般只有几毫秒到几十毫秒。这决定了它不能像写普通软件那样写阻塞等待。AI 在生成代码时经常会出现这样的问题在 ST 语言里写 for 循环等待 1 秒这会导致程序卡住扫描周期异常。把多个定时器串联在一起导致时序意外拉长。使用了需要沿触发的边沿指令但没有考虑扫描周期的刷新时刻。这些问题在仿真器里不太容易暴露只有在真实设备运行时会表现出“动作不稳定”的现象。排查起来非常费劲。5.5 梯形图表达能力不足很多老师傅习惯看梯形图而 AI 在文本对话中只能输出指令表或 ST 语言很难直接生成一个真正可用的梯形图文件。虽然你可以让 AI 用文字描述“第一行左边是 X0 常开触点第二行……”然后自己在 GX Works 里画但这种人工翻译效率很低而且容易出错。5.6 缺少安全逻辑与工艺经验这是最致命的问题。AI 可能知道“互锁”这个概念但它不知道你的设备在什么情况下必须急停不知道两个气缸如果同时动作会不会撞在一起不知道停电恢复后设备应该保持什么状态。安全逻辑必须由熟悉工艺、熟悉设备的工程师来把关AI 只能作为一个“逻辑参考”而不是“安全审核人”。6. 如何判断和验证 AI 生成的 PLC 程序6.1 第一步语法编译检查无论 AI 生成的是 ST 语言还是指令表第一步就是把代码粘贴进对应的编程软件进行编译。编译器会帮你拦截语法错误、数据类型不匹配、指令不存在等问题。这一步可以过滤掉大部分“AI 幻觉”类错误但请注意能编译通过不代表逻辑正确。6.2 第二步仿真运行大多数主流 PLC 编程软件都支持仿真运行。三菱 GX Works2 配合 GX Simulator。西门子 TIA Portal 配合 PLCSIM。CODESYS 自带软 PLC 仿真环境。汇川 InoProShop 支持在线仿真。仿真环境里可以手动强制输入点观察输出点变化。对于交通灯、流水线节拍这类不涉及危险设备的程序仿真测试已经能覆盖绝大部分问题。6.3 第三步按 I/O 点表走查把 AI 生成的程序拿到真实项目里之前建议对照 I/O 点表逐行走查每个输入点是否与现场实际接线地址一致。每个输出点对应的接触器、阀岛、伺服使能是否匹配。是否考虑了常开/常闭逻辑。是否包含急停、复位、报警输出。是否有手动/自动切换切换时输出是否安全。6.4 第四步让 AI 解释自己写的代码很多人不知道让 AI 解释它自己生成的代码也是验证逻辑的一种好方法。你可以直接问“请逐行解释你生成的正转启动逻辑特别说明在什么情况下 Y0 会保持为 ON。”如果 AI 的解释逻辑清晰、前后一致说明它确实是在按需求生成如果解释含糊、自相矛盾那这段代码可能只是“看起来像样”。6.5 第五步空载测试与小范围带载测试如果条件允许在完成上述检查后可以先做空载测试不给电机通电只观察接触器动作是否正确。然后再在低风险设备上做小范围带载测试。这个过程必须有工程师全程在场并且保证急停有效、有人值守。7. 最佳实践如何把 AI 变成 PLC 编程的辅助工具7.1 把 AI 当“语法助手”而不是“方案设计者”AI 最擅长的是帮你写出语法正确、结构完整的代码片段而不是帮你设计整个控制方案。控制方案必须基于工艺工艺必须来自现场。所以推荐的使用方式是提出明确需求包括输入输出清单、控制流程、异常要求。让 AI 生成代码框架。你再根据现场情况调整地址、补充安全逻辑。7.2 用提示词模板提高生成质量如果你想让 AI 生成更接近可用的 PLC 程序建议使用统一的提示词模板。下面是一个参考请帮我编写一个 [三菱 FX3U / 西门子 S7-1200 / CODESYS] 的 PLC 程序。 项目背景[一句话描述设备或工艺] 输入点表 X0启动按钮常开 X1停止按钮常闭 X2急停按钮常闭 输出点表 Y0主接触器 Y1报警灯 控制要求 1. 按下启动按钮后Y0 输出并自锁 2. 停止按钮或急停按钮按下时Y0 立即断开 3. 程序应使用 [梯形图 / ST 语言 / 指令表] 形式输出 4. 请标注必要的注释并提醒我哪些地方需要根据实际接线调整。把这段模板复制给你的 AI 工具生成质量会明显高于直接问“帮我写个 PLC 程序”。7.3 用 AI 解释老项目程序AI 在 PLC 领域最有实用价值的功能之一就是解释老程序。你可以把一段无注释的指令表或 ST 代码贴给它然后问“请用中文逐段解释这段程序实现什么功能指出哪些地方有隐患。”AI 通常会给出比较专业的解释也能发现一些明显的逻辑漏洞。这对接手老项目的工程师帮助很大。7.4 用 AI 做多人审查的“第二双眼睛”在程序写完、仿真通过之后可以把完整代码发给 AI让它以“独立审核员”的身份找问题。比如“请帮我审查这段电机控制在逻辑上有哪些安全隐患比如缺少互锁、缺少急停、扫描周期问题等。”AI 虽然不能替代人工审核但它往往能发现一些因为“思维惯性”而被忽略的问题相当于成本很低的代码复查环节。8. 常见问题排查清单问题现象常见原因排查思路AI 生成的代码编译报错语法不对或使用了不存在的指令确认 PLC 品牌和编程软件让 AI 重新生成对应语法AI 把不同品牌指令混用提问时没有说明 PLC 型号在提示词中写清厂商、系列、编程软件程序能编译但设备不动作地址与实际 I/O 不一致对照 I/O 点表逐项核对地址分配动作顺序不稳定扫描周期、定时器使用不合理在仿真器中逐周期观察输出变化缺少互锁导致设备碰撞AI 不了解工艺未自动补全安全逻辑人工补全安全联锁禁止直接投产AI 编造冷门指令训练数据不充分以官方编程手册为准不要盲目相信 AI 回答梯形图无法生成文件AI 当前只能输出文本让 AI 输出指令表再在 IDE 中生成梯形图9. 总结与建议关于 AI 写 PLC 程序我目前的结论是不要指望 AI 直接生成一套可投运的完整程序但也不要低估 AI 在代码模板、逻辑解释、语法参考和排错思路上带来的效率提升。如果你是一名自动化工程师可以把它当作“随时在线的老工程师助理”让它帮你快速生成初版逻辑、解释一段陌生代码、排查一个编译问题。如果你是一名刚学 PLC 的新手AI 的最大价值是帮你快速理解指令含义和控制思路但千万不要把 AI 答题式生成的程序当成标准答案一定要用仿真器验证。真正能在 PLC 岗位上把 AI 用得好的人不是依赖 AI 生成多少代码而是懂得如何把需求描述清楚、如何审核逻辑、如何把安全边界牢牢握在自己手里。你越懂工艺就越能用好 AI你越不懂工艺AI 给你的只是看似完美的“幻觉”。