把“让 AI 写 PLC 程序”这件事放到真实工程环境里看结果和很多人想象的不太一样。你让 AI 写一段 Python 脚本处理 Excel它通常能一次跑通但让 AI 写一段 PLC 程序去控制一台电机它交出来的代码很可能“看起来像那么回事”放到 PLC 里却不敢直接跑。这不是 AI 变笨了而是 PLC 编程和普通软件开发在底层逻辑上就不是一回事。这篇内容主要回答你的三个问题AI 写 PLC 程序的质量到底行不行、各个 AI 品牌对 PLC 场景的支持性怎么样、实际用起来主要会踩哪些坑。同时我会结合工程场景说说目前哪些环节可以先用 AI 提效哪些环节建议你保持人工控制以及怎样把“AI 生成 人工审查 仿真验证”这套流程真正落到自己的项目里。1. 先给一个明确判断AI 写 PLC 程序处在“可用但不可直接信”的阶段先说结论当前主流 AI 模型对 IEC 61131-3 标准下的文本类编程语言如西门子 SCL、结构化文本 ST、三菱指令表已经具备“生成可读代码”的能力。你给它足够清晰的 I/O 表、控制逻辑和硬件型号它能写出结构完整、注释清晰的程序框架。但真正让它独立负责一段带安全联锁的工业控制程序风险还很高。问题不在于 AI 不懂语法而在于 PLC 程序从来不只是“逻辑正确”就够了。一个 PLC 程序要真正落地还要满足硬件地址匹配、扫描周期约束、安全回路设计、版本兼容、现场调试习惯等一系列软件之外的条件。AI 很难从你的提问里完整推断出这些约束。所以一个更稳妥的判断是AI 写 PLC 的定位目前是“高水平助手”而不是“替代工程师的自动编程器”。它擅长帮你搭建 70 分的骨架剩下的 30 分——尤其是安全和联锁相关部分需要你来补。2. 为什么 AI 写 PLC 程序比写 Web 代码难这么多很多人不理解AI 写 Python、Java 都已经很成熟了怎么到了 PLC 这里就水土不服核心原因可以拆成五点。2.1 PLC 程序是硬件强相关的普通软件开发面对的是操作系统和框架AI 大体上能通过“常见用法”生成代码但 PLC 程序面对的是具体型号、具体模块、具体接线方式。同样是“读一个传感器信号”在西门子 S7-1200 里可能要先配置模块地址在三菱 FX5U 里要处理软元件编号在汇川 AM 系列里又是另一套命名方式。AI 不可能从一句“帮我写个电机启停程序”里推断出你的 PLC 品牌、CPU 型号、I/O 通道和传感器类型而这些恰恰是 PLC 程序能不能下载运行的关键。2.2 工业安全要求极高Web 程序出 Bug通常表现为页面报错、数据不对影响的是用户体验PLC 程序出 Bug可能表现为设备误动作、电机堵转、气缸撞机轻则损坏设备重则威胁人身安全。PLC 工程师在写每一段逻辑时脑子里同时装着“如果这个传感器坏了怎么办”“如果两个输出同时动作会怎样”这类安全冗余问题。而 AI 在生成代码时默认遵循的是“按你的描述把逻辑写出来”不会主动补上安全联锁。这是 AI 写 PLC 程序最本质的短板。2.3 语言和生态碎片化PLC 编程不是一种语言而是一簇方言。IEC 61131-3 定义了五种编程语言梯形图LD、结构化文本ST、功能块图FBD、指令表IL、顺序功能图SFC。这五种语言在不同厂商平台上的实现又各不相同西门子的 SCL 和标准 ST 有差异三菱有独特的软元件体系汇川、信捷等国产 PLC 在兼容欧系或日系的同时又加入了自家扩展。AI 的训练数据里能学到的每种方言的深度完全取决于该方言在公开语料中的分布量。2.4 图形化语言是 AI 的盲区这一点特别容易被忽略。梯型图、功能块图是 PLC 工程师最常用的语言但它们是图形化语言。ChatGPT、Claude、DeepSeek 这类大模型本质上是文本模型它可以直接生成 SCL、ST 这样的文本代码但没法直接在回复里“画”出一张梯形图。哪怕某些平台能输出 XML 或描述性文件供导入产物的可读性和可维护性也远不如工程师在 TIA Portal、GX Works 里手工画的图。2.5 公开训练语料太少、太乱网上公开的 Python 代码有数百万个高质量仓库但公开的 PLC 工程代码要少几个数量级而且大量以论坛求助帖、残缺的梯形图截图、非规范命名代码的形式存在。AI 学到的 PLC 知识里“形似”的成分多“神似”的成分少。这直接导致它生成的 PLC 代码在语法层面可能挑不出大毛病但在工程层面上经常出现“这里不对、那里缺一个条件”的尴尬局面。3. 不同 AI 品牌对 PLC 场景的支持性分析先说明一点各家大模型的能力边界不是固定的版本更新很快下面是从工程使用习惯出发的横向判断不涉及具体测试分数。3.1 对 IEC 61131-3 文本语言的支持度差异从社区反馈和实际使用感受看头部通用大模型对 SCL、ST 这类文本化 PLC 语言的支持度明显优于小众国产模型。原因是 SCL/ST 的语法接近 Pascal、C 等通用编程语言AI 可以用“类比推理”的方式写出相对合理的代码。西门子 SCL 因为语法规范、公开示例相对多是当前 AI 生成质量最好的 PLC 语言之一。三菱的指令表如 LD、MOV、ADD、CMP 这类指令行也有一定生成能力但质量稳定性不如 SCL。三菱编程的核心是软元件编号X、Y、M、D、T、CAI 经常在软元件的使用习惯上出问题比如重复使用同一个中间继电器、定时器编号超出范围等。3.2 对梯形图的支持基本只能“口述”在梯形图面前所有 AI 都回到了同一起跑线它们无法直接画出梯形图只能给你一段文字描述或者生成某些平台支持的 XML 导入文件。如果你问“帮我写一个电机启停梯形图”AI 会输出类似“用 X0 作为启动按钮、X1 作为停止按钮、Y0 作为输出线圈Y0 的常开触点并联在 X0 上实现自锁”这样的文字方案。这种方案对老手来说有价值等于是一个思路参考对新手来说价值有限因为你仍然需要在编程软件里亲手把触点、线圈、连线画出来。如果未来某家 PLC 平台推出“AI 直接生成梯形图”的编辑器那才是真正改变游戏规则的产品目前还没有看到足够成熟的公开方案。3.3 对国产 PLC 的支持更依赖你的提问质量像汇川、信捷、台达这些国产 PLC公开技术资料的密度远低于西门子和三菱AI 训练数据不足的问题会更明显。但它不是完全不能用。实际经验是如果你在提问时提供了详细的型号、指令手册节选、I/O 分配表和控制流程AI 依然能基于对通用 PLC 逻辑的理解给出有价值的框架代码如果你只丢一句“帮我写个汇川 PLC 程序”它多半会给你生成一段缺少品牌特征的四不像代码。3.4 品牌选择建议如果你的日常工作以西门子为主AI 能帮上的忙最大如果以三菱为主可以把它当“指令查询助手”而不是“代码生成器”如果以国产 PLC 为主建议把它当“逻辑设计顾问”重点让它帮你梳理工艺思路和测试用例而不是直接生成可下载的程序。4. AI 生成的 PLC 程序质量问题通常出在哪这一节是重点。从大量实际尝试的反馈看AI 写 PLC 程序最容易在下面七个地方翻车。4.1 指令幻觉编造不存在的指令这是最常见也最隐蔽的问题。AI 在生成代码时会“自信地”写出一些看起来合理的指令或函数但实际上在目标平台里根本不存在。比如它在三菱程序里写了一个SET Y0三菱确实有这个指令没问题但它可能在西门子 SCL 里用了一个 TIA Portal 中不存在的库函数或者用了某个过时版本的指令。解决思路只有一个对 AI 生成代码里的每一条指令都去目标平台的指令手册里核对一遍。这是最费时间但最保险的环节。4.2 变量地址冲突和软元件滥用AI 生成代码时经常忽略变量的地址规划。它可能把同一个中间继电器地址分配给两个不同用途也可能在程序中随意使用定时器编号导致和现有程序冲突。真实项目里I/O 分配表、中间继电器使用范围和定时器编号通常由主程序或工艺规范提前定义。AI 看不到这些约束所以它生成代码里的地址基本只能当“临时变量”看待需要你人工按项目规范重新映射。4.3 缺少互锁和安全逻辑这是最危险的问题。AI 会严格按照你描述的逻辑生成代码但很少主动思考“如果两个条件同时成立会怎样”“如果其中一个传感器故障怎么办”。比如你让它写一个气缸进退控制程序它会给你写出前进和后退各自的输出但可能不会主动加上“前进时禁止后退”的互锁条件。在真实设备上这种缺失可能直接导致机械损坏。所以如果 AI 生成的代码要用于实际设备互锁逻辑这一步必须由工程师亲自补全和确认不能跳过。4.4 不理解扫描周期的工作方式PLC 程序是循环扫描执行的扫描周期从几毫秒到几十毫秒不等。很多被 Web 开发思维训练过的 AI 模型会不由自主地把“循环”“等待”“递归”这类高级语言思路带进 PLC 代码。它可能写出一段“等待定时器到 5 秒后继续执行”的阻塞逻辑这在 PLC 的循环扫描机制里可能导致整个控制流程卡死。正确的 PLC 编程思路是“状态机 条件触发”每个扫描周期都检查条件满足则改变输出而不是像普通程序那样顺序等待。4.5 硬件配置和通信参数答非所问“三菱 PLC 的 IP 地址怎么设置”“汇川 PLC 和变频器走 Modbus 通信的地址怎么配”这类问题AI 能给出步骤但经常不够准确。因为 IP 地址设置涉及具体型号的拨码开关、工程软件里的网络配置、以及不同固件版本的差异AI 给出的答案往往是把“常见做法”拼在一起不能精确匹配你的设备。如果你拿 AI 给的硬件配置参数直接去现场操作大概率会卡在某个细节上。更稳妥的方式是把 AI 给的步骤当作方向参考最终以官方手册为准。4.6 命名混乱可维护性差AI 生成的变量名和注释风格极不稳定。同一个程序里它可能一会儿用Motor_Start一会儿用motorStart再一会儿用M1。变量命名不统一、注释随意在工程交付时会被当作不合格代码打回。你拿到 AI 代码后第一件事往往不是调试而是先花时间重命名和补注释。4.7 版本和平台混淆AI 会把不同平台、不同版本的知识混在一起。比如你在问三菱程序它却给你生成一段带西门子风格的注释你问的是 GX Works3 语法它可能给你输出 GX Developer 才支持的旧指令。这种混淆不容易一眼看出来但在编译阶段会集中爆发。5. 实际应用案例AI 生成 ST 代码后我做了什么修改下面用一个典型的“电机启停 运行超时报警”程序作为例子还原 AI 生成代码后人工检查的过程。这个案例基本模拟了你让 AI 直接干活时的真实体感。5.1 先建立提示词模板你让 AI 写 PLC 程序时问题描述得越具体输出质量越高。下面这个提示词模板可以直接复制使用。你是一名有 15 年经验的西门子 PLC 工程师使用 TIA Portal 和 SCL 语言编写程序。 请帮我编写一个电机控制程序要求如下 1. PLC 型号S7-1200 1214C DC/DC/DC 2. 输入信号 - 启动按钮常开I0.0 - 停止按钮常闭I0.1 - 热继电器常闭I0.2 - 电机运行反馈I0.3 3. 输出信号 - 接触器线圈Q0.0 - 故障指示灯Q0.1 4. 控制逻辑 - 按下启动按钮电机启动并自锁 - 按下停止按钮电机停止 - 热继电器动作时电机立即停止并锁存故障指示 - 故障复位方式按下停止按钮 3 秒后复位故障灯 - 启动命令发出后 5 秒内未收到运行反馈判断为接触器故障停止电机并点亮故障灯 5. 其他要求 - 使用 SCL 语言变量名规范注释清晰 - 在程序头部说明输入输出对应关系5.2 AI 生成的“第一版代码”把上面的提示词丢给一个主流大模型典型的 SCL 输出大致会长这样这里做了精简但结构与 AI 输出一致// 文件OB1 或 FC 中调用 // 电机控制 // I0.0: 启动按钮 // I0.1: 停止按钮 // I0.2: 热继电器 // I0.3: 运行反馈 // Q0.0: 接触器 // Q0.1: 故障灯 IF 启动按钮 THEN 电机启动请求 : TRUE; END_IF; // 停止或热继电器动作断开启动请求 IF NOT 停止按钮 OR NOT 热继电器 THEN 电机启动请求 : FALSE; END_IF; // 自锁保持 接触器 : 电机启动请求; // 运行反馈超时判断 IF 电机启动请求 AND NOT 运行反馈 THEN IF 超时计时器.Q THEN 故障锁存 : TRUE; END_IF; END_IF; // 故障灯输出 故障灯 : 故障锁存; // 按下停止按钮 3 秒复位故障 IF NOT 停止按钮 THEN 复位计时器.TON(IN : TRUE, PT : T#3S); IF 复位计时器.Q THEN 故障锁存 : FALSE; END_IF; END_IF;5.3 这段代码里藏了哪些问题这个版本“能看”但远不到“能跑”的程度。我检查后至少发现这些工程问题第一启动条件的处理不完整。IF 启动按钮 THEN能表达“按下启动”但没有考虑“启动按钮松开后如何保持”后面虽然用电机启动请求做了自锁但启动请求和接触器输出之间的时序关系不够清晰。第二热继电器的信号逻辑错了。项目中热继电器是常闭触点正常状态为 ON动作状态为 OFF。代码里IF NOT 热继电器 THEN把启动请求断开这个方向是对的但没有区分“热继电器动作”和“急停”这类不同等级的故障后续维护时容易混淆。第三缺少互锁。如果这是一个可逆电机控制项目的一部分那么 AI 生成的程序里往往没有“正转时禁止反转”这类互锁逻辑。这个例子只有单方向启停风险不大但如果是复杂设备这一点必须补上。第四超时判断的计时器没有复位。超时计时器在什么条件下复位代码里没有明确处理。运行反馈到位后计时器没有被重置下一次启动时可能带着上一次的计时状态导致误判。第五故障复位逻辑有漏洞。如果设备处于故障状态但操作者一直按住停止按钮3 秒后故障会复位。这个行为是否符合工艺要求需要现场确认。很多项目里故障复位是“独立复位按钮 工程师权限”而不是“停止按钮长按”。AI 不会知道你的现场要求但它会替你做决定。5.4 人工修改后的版本针对以上问题修改后的版本应该长这样// 文件FC_ MotorControl // 电机启停控制 启动超时报警 故障复位 // 输入输出映射 // 启动按钮 : Bool : I0.0 // 停止按钮 : Bool : I0.1 (常闭ON 表示允许运行) // 热继电器 : Bool : I0.2 (常闭ON 表示正常) // 运行反馈 : Bool : I0.3 // 接触器 : Bool : Q0.0 // 故障灯 : Bool : Q0.1 VAR 启动请求 : Bool : FALSE; 故障锁存 : Bool : FALSE; 超时计时器 : TON; 复位计时器 : TON; 急停信号 : Bool : FALSE; END_VAR // 安全条件急停未触发且热继电器正常且停止按钮允许运行 急停信号 : NOT 停止按钮; // 启动条件按下启动按钮且当前无故障且安全条件满足 IF 启动按钮 AND NOT 故障锁存 AND NOT 急停信号 AND 热继电器 THEN 启动请求 : TRUE; END_IF; // 停止条件安全条件不满足或热继电器动作或急停触发断开启动请求 IF 急停信号 OR NOT 热继电器 THEN 启动请求 : FALSE; END_IF; // 输出接触器跟随启动请求受故障状态限制 接触器 : 启动请求 AND NOT 故障锁存; // 启动超时检测有启动命令但无运行反馈持续 5 秒则进入故障 超时计时器.TON( IN : 启动请求 AND NOT 运行反馈, PT : T#5S ); IF 超时计时器.Q THEN 故障锁存 : TRUE; END_IF; // 运行反馈恢复或启动请求取消时手动复位超时计时器 IF 运行反馈 OR NOT 启动请求 THEN 超时计时器.TON(IN : FALSE, PT : T#5S); END_IF; // 故障复位停止按钮持续按下 3 秒且热继电器未动作时复位故障 复位计时器.TON( IN : 急停信号 AND 热继电器, PT : T#3S ); IF 复位计时器.Q THEN 故障锁存 : FALSE; END_IF; // 故障灯输出 故障灯 : 故障锁存;这个版本仍然需要结合你的实际接线来确认但至少在互锁、复位条件、计时器复位这三件工程关键事务上比 AI 第一版更接近可交付状态。这个对比最大的价值在于AI 可以帮你把 70 分的框架搭出来但把 70 分推到 95 分的那些细节全部来自工程师对现场、安全规范和工艺要求的理解。6. 怎么搭建一套“AI 协作写 PLC”的工作流如果你决定把 AI 用起来建议不要“拿到代码就下载”而是按下面这套流程推进能在效率和风险之间取得较好的平衡。6.1 第一步把项目背景完整喂给 AI一个合格的 PLC 提问至少包含这些信息PLC 品牌和具体型号包含 CPU 型号编程软件名称TIA Portal、GX Works3、AutoShop 等编程语言SCL、ST、梯形图、指令表完整的 I/O 分配表包括地址和信号含义工艺控制流程描述已知的安全要求急停、互锁、故障复位等信息越完整AI 的输出越接近可用状态。6.2 第二步让 AI 生成“框架 注释”而不是“最终代码”在提示词里明确要求 AI“先输出程序框架和变量清单”而不是直奔完整代码。这样你可以在拿到代码前先检查 AI 对 I/O 和工艺流程的理解是否正确避免在错误的基础上修改大段代码。6.3 第三步人工审查清单AI 生成的代码必须逐行过一遍下面这张检查清单每条指令是否都能在目标平台找到对应功能所有 I/O 地址是否和分配的变量表一致中间继电器、定时器、计数器编号是否有冲突互锁条件是否覆盖了所有可能同时动作的输出急停、安全回路是否独立于 AI 生成的程序计时器是否有明确的复位条件输出线圈是否有重复赋值一个 Q 点在程序里只能有一处可写注释里的符号名和实际变量名是否一致是否考虑了故障后的恢复流程6.4 第四步用仿真器验证这是 AI 写 PLC 工作流里最重要的一环。TIA Portal 自带 PLCSIM三菱 GX Works3 带 GX Simulator汇川 AutoShop 也有仿真功能。把 AI 生成的代码导入仿真环境用模拟输入信号去驱动运行观察输出是否能按工艺要求变化。在仿真环境里你可以大胆构造故障场景热继电器瞬间断开、运行反馈一直不返回、停止按钮突然断开等看程序能否按预期进入安全状态。这一步能把绝大多数 AI 代码里的逻辑漏洞暴露出来。6.5 第五步小步集成不要一次更换整段代码如果 AI 生成的代码要接入现有项目建议先把它封装成一个独立的 FB 或 FC用仿真验证没问题后再挂到主程序里测试。避免一次替换大段代码后现场出问题无法定位到具体原因。7. 常见问题与排查思路实际操作中你大概率会遇到下面这些问题提前知道对应排查路径能省不少时间。问题现象可能原因排查方式解决方案编译报错提示指令不存在AI 生成了目标平台不支持的指令或函数从错误提示定位到具体行打开官方指令手册核对替换成平台支持的指令或改用等价的标准指令程序能编译但下载后设备不动作I/O 地址与硬件接线不一致或变量名映射错误检查 I/O 分配表对照 PLC 变量表和硬件组态以实际接线图为准修正地址映射电机能启动但无法停止自锁逻辑错误或停止按钮信号未参与停止分支在仿真中强制停止按钮为 OFF观察程序分支检查停止条件是否覆盖所有运行状态定时器误动作计时器没有复位条件或复位逻辑错误查看计时器输入条件和复位分支增加明确的复位条件比如运行反馈到位或启动命令取消时复位故障灯一直亮无法复位复位条件设置不合理或故障锁存没有被清除检查锁存变量的复位分支按工艺要求设计可靠的复位流程例如独立复位按钮加权限AI 生成代码风格混乱未在提示词中指定变量命名和注释规范提前在提示词中给出示例格式在提示词里附加一段你项目的样板代码作为风格参考8. 最佳实践与工程建议8.1 把 AI 当“第一版草稿生成器”而不是“最终交付者”这个心态特别重要。把 AI 定位成“帮你快速搭出代码骨架的同事”而不是“替你干活的机器”你就不会在它出错时浪费时间去抱怨也不会因为过度信任而犯下低级错误。PLC 项目的最终责任一定在工程师手里AI 不背这个责任也担不起这个责任。8.2 安全相关逻辑一律人工编写凡是涉及急停、安全门、光栅、双手启动、互锁这类安全链路的程序不建议直接使用 AI 生成的代码。如果非要用也必须由具备安全经验的双人进行交叉审查并通过仿真验证所有故障场景。这一点没有商量余地。8.3 建立自己的提示词模板库做了几个项目后你会发现PLC 编程的套路是有限的。可以把常见场景的提示词模板沉淀下来比如“电机启停”“气缸顺序控制”“模拟量处理”“变频器通信”等。下次新项目直接复制模板替换 I/O 表和工艺描述AI 输出的质量会明显提高。8.4 让 AI 输出指令清单和依据在提示词里加一句“请列出本程序用到的所有指令并说明每条指令的作用”。这样你在人工审查时可以拿清单和官方手册逐条核对比对着代码猜快得多。8.5 用仿真器建立回归测试集把常见故障场景做成固定的仿真测试用例每次 AI 生成的代码都先跑一遍这些用例。比如“启动后反馈不返回”“运行中热继电器断开”“停止按钮按下一半”等。这样你每次引入新代码时至少可以确认它不会让以前的故障重新出现。8.6 大项目分块生成不要一次性全丢给 AI一个大型设备可能有几十个功能块。如果让 AI 一次生成全部代码输出必然混乱。更好的做法是把一个工艺拆成“手动模式”“自动模式”“报警处理”“通信处理”等独立块每块单独和 AI 协作最后按原有项目架构集成。8.7 保持团队内部的代码风格统一AI 生成的代码容易“个性化漂移”。建议在项目启动前定义好变量命名规则、注释格式和 FB/FC 封装规范并把这些规范写进提示词。如果你团队里的项目跨度大甚至可以为每个合作过的 AI 模型建立一份“风格约束记录”避免在不同模型间切换时输出风格飘忽不定。9. 总结与后续方向回到你最开始的问题有没有人测试对比过 AI 写 PLC 程序的质量答案是大家都在试而且测试结论高度一致——AI 能写但还不能独立负责生产级 PLC 程序。它能帮你写好框架、注释、文本化 ST/SCL 代码能帮你快速梳理工艺思路能帮你解释陌生的指令和程序段但它写出来的代码需要人工逐行审查、仿真验证、补安全逻辑才能真正进入现场。从各 AI 品牌的支持性看西门子 SCL 方向体验最好三菱指令表次之国产 PLC 需要更充分的提问上下文梯形图则基本需要人工转译。没有哪个品牌能做到“万能”关键还是看你给它的信息质量。如果你下一步要继续深入建议从两个方向入手一是把你手头最常见的工艺术场景整理成标准提示词模板让 AI 在你熟悉的领域越用越顺手二是把仿真环境的故障测试用例建起来让 AI 生成的每一版代码都在可控环境里先过一遍。这两件事做扎实AI 在你的 PLC 开发流程里能发挥的增量价值会比你想象中更大。