前几天有位做电气控制的朋友发来一段 AI 生成的三菱 PLC 梯形图问我能不能直接用。我打开看了十分钟整体逻辑是有模有样的自锁、定时、输出都画出来了。但仔细一查定时器编号重叠中间继电器重复使用注释写得像从手册里抄的。真正放到 GX Works 里一跑第一轮编译就报错。这是个很典型的场景AI 确实能写 PLC 程序但“能写”和“能上机跑通”之间隔着调试、地址分配、型号匹配和现场验证。这篇文章想把最近看到的对比和实际使用体感整理一下包括不同 AI 的支持性差异、常见问题以及我觉得比较务实的使用方式。1. 先搞清楚AI 写 PLC 程序到底行不行先说结论行但只能在“辅助起草”这个层面行离“直接生成可部署程序”还有明显距离。这不是某个 AI 品牌的问题而是所有大模型产品目前的共性。PLC 程序跟普通软件开发有几个本质差异这些差异决定了 AI 的上限。1.1 AI 生成的 PLC 程序像实习生写的第一版如果你把 AI 当做一个刚入行的实习生它的表现就很好理解了。它看过很多资料知道“自锁电路大概长什么样”“定时器一般怎么用”“气缸顺序控制需要哪些步骤”。你给它一个需求它能快速给你画出一个结构完整的初稿。但这个初稿有两个典型问题一是指令不一定对应你用的型号。三菱 FX 系列的指令、西门子 S7-1200 的指令、汇川的指令虽然思路相似但写法不同。AI 很容易把不同品牌的代码混在一起尤其是当你没有明确说“请使用三菱 FX3U 的指令集”时。二是地址和软元件编号经常是“编”的。AI 并没有真正理解你的硬件配置它只知道“这里大概需要一个定时器”“那里大概需要一个中间继电器”。于是它会自动生成 T0、T1、M100、M101 这些编号至于这些编号是不是跟你现场已经用的冲突它完全不知道。所以AI 生成的程序看起来像模像样但拿到软件里编译往往会发现一堆问题。这不是幻觉而是它本身就不具备“硬件映射”能力。1.2 “能生成代码”和“能部署上机”是两件事我一直觉得很多工程师对 AI 编程的期待被“代码生成”这个词带偏了。对普通软件来说代码生成之后只要编译通过、测试通过基本就可以上线。但 PLC 程序完全不是这个逻辑。PLC 程序必须跟真实的输入输出点对应。你的 X0 接的是启动按钮X1 接的是停止按钮Y0 接的是接触器。AI 不知道你的接线图它只能根据你描述里的“启动”“停止”猜测一个结构无法保证地址映射正确。PLC 程序还要考虑扫描周期和时序。普通程序里的“延时”“边沿”是相对抽象的但 PLC 里一个上升沿指令在不同品牌、不同型号下可能行为完全不同。也就是说AI 生成的是“文字层面的程序”不是“已经通过编译和仿真验证的程序”。从生成到运行之间工程师要补的东西——地址映射、型号匹配、异常处理、时序验证——往往比从零写还多。但这不代表 AI 没用。它真正提升的是“从需求到初稿”的速度而不是“从需求到成品”的速度。2. 不同 AI 品牌的支持性差异在哪里“哪个 AI 写 PLC 程序更好”这个问题没有统一的答案因为不同工具背后的训练数据、代码库覆盖范围和使用方式都不一样。但可以从几个维度做个判断框架。我建议用三个维度去判断指令集覆盖度能不能正确输出三菱、西门子、欧姆龙、汇川等常见品牌的指令。代码稳定度同一个需求跑多次结果差异大不大会不会出现明显编译错误。上下文理解能力能不能根据你补充的“用了什么型号”“IO 怎么分配”“有没有特殊工艺”自动调整代码。2.1 通用对话式大模型最省事但细节看型号现在主流的通用对话式 AI比如常见的中英文大模型产品都能直接聊 PLC 编程。你只要描述需求它就能生成一段梯形图或结构化文本。这类工具的优点是门槛低、方便适合快速理解一个没接触过的指令、生成一段功能的初稿、把别人的程序解释成注释。问题在细节。通用模型的知识库覆盖范围广但 PLC 相关的工业指令集更新速度不一定跟得上。有些新出的旗舰机型、新版本的编程软件它未必知道。而且不同品牌之间的指令混淆情况比较常见。体感上这类工具写结构化文本ST 语言比写梯形图更稳因为梯形图更像图形化编程生成出来的 ASCII 表示形式不一定能直接导入编程软件。所以我会建议用通用对话式 AI 时尽量让它生成结构化文本或指令表而不是梯形图。2.2 代码助手类工具更擅长普通软件工业库支持不均衡代码助手类工具更擅长的是普通编程语言比如 C、Python、Java因为它们训练数据里这类代码量极大。PLC 相关的代码虽然也有但相比之下占比较小所以生成的稳定性也会差一些。有些代码助手能根据上下文做智能补全但前提是它要能理解你当前项目里的变量定义、模块结构。而 PLC 工程文件本身不是纯文本很多编程软件有自己封闭的数据结构代码助手很难真正拿到完整的上下文。如果只是把它当成“生成一段独立功能代码”的工具效果还可以如果指望它在整个 PLC 项目里帮你自动补全、跨模块管理目前还不够现实。2.3 垂直工业辅助工具更对口但覆盖品牌和指令集有边界现在市面上也出现了一些面向工业自动化场景的 AI 辅助编程工具或插件。它们的思路更垂直有的内置了特定品牌的指令集有的专门针对某个编程软件做代码生成。这类工具的优点是对指令集的准确度更高生成的代码更容易通过编译。缺点是覆盖范围有限。你用的品牌和型号如果不在它的知识库里效果可能还不如通用大模型。而且这些工具很多还处在迭代期功能变化较快使用前要看清楚它当前支持哪些品牌、哪些型号、是否能导出工程文件能识别的格式。判断一个 AI 值不值得用不是看它能不能写出一段看起来不错的代码而是看你把这段代码放进编程软件里要改多少次才能跑通。修改次数越少辅助价值越高。3. 我建议你按这个方式做一次 AI 写 PLC 程序的对比测试很多人问“哪个 AI 写 PLC 最好”但如果自己不去测一遍很难有真实体感。下面是我建议的对比测试思路你可以直接复用到自己的场景里。3.1 选择测试样例从“简单自锁”到“带步序的控制”分三级难度选三组有代表性的需求难度递增基础自锁电路启动保持、停止断开。这是最简单的逻辑用来测 AI 对基本指令的掌握。带计时器的电机控制按下启动按钮后延时启动按下停止按钮后延时停止。用来测定时器的使用是否正确。带步序的气缸顺序控制比如两个气缸依次动作前一个到位后才触发下一个。用来测“状态流转”和“互锁条件”这类复杂逻辑。为什么要分三级因为前两级一般 AI 都能通过但第三级往往会暴露问题。下面是一个可以拿来测试的需求描述模板请用三菱 FX3U 的指令集写一个程序 - 启动按钮 X0停止按钮 X1 - 按下 X0 后延时 5 秒Y0 输出电机启动 - 按下 X1 后延时 3 秒Y0 断开电机停止 - 需要自锁需要有手动复位方式注意这里有一个隐藏信息“需要有手动复位方式”。如果 AI 没有体现复位逻辑说明它的工业安全意识不足。3.2 定义评分维度别只看“能不能编译”判断一个程序写得好不好不能只看“好像能跑”。建议按下面五个维度评分评价维度看什么怎么判断指令规范性使用的指令是否属于指定型号对照编程软件的指令集查逻辑完整性是否包含自锁、互锁、停止、复位看有没有缺分支地址合理性是否有重复、冲突、超出范围在软件里编译看报警可读性注释是否完整、命名是否有含义看别人能不能看懂调试成本从生成到仿真通过要改几处记录修改数量和耗时这五个维度里最重要的是“调试成本”。这一步最能反映一个 AI 的实际价值。3.3 记录和复测同一需求给不同工具跑注意控制变量做对比测试时有两点很容易被忽略第一同一个需求给不同工具时描述要完全一致。否则你测出来的就不是工具差异而是不同描述导致的差异。第二同一工具也要跑两三次。大模型生成结果有随机性有时候第一次生成的不行第二次重试一下可能就对了。这本身就是一种稳定性的体现。我自己测试时会有个判断习惯如果一个 AI 需要在同一需求上重试三次以上才能得到可用结果那它在工程里的价值就要打折扣因为你把时间花在“引导 AI”上了。4. AI 生成的 PLC 程序最容易掉进哪几类坑在实际使用中AI 生成的 PLC 程序问题主要集中在下面几类。4.1 指令集与型号不匹配这是最基础也最频繁的问题。AI 可能知道三菱有 ANI、ORI、SET、RST 这些指令但如果你用的是西门子 S7-1200它却可能给你写出一堆三菱风格的指令或者反过来你在用三菱它给了你一堆类似TON这种西门子风格的结构。有些指令在不同品牌里只是写法不同有些则完全不存在。这种错误在编译阶段就会暴露算比较好解决。但麻烦的是它可能隐藏“看起来差不多”的代码里导致编译通过但行为不对。排查思路先确认你明确告诉 AI 型号了没有。如果说了型号还跑偏那就换个工具重新试。如果没说那不是 AI 的问题是输入信息不足。4.2 地址冲突和软元件编号超出范围PLC 程序里输入点、输出点、中间继电器、定时器、计数器都有数量限制和编号范围。AI 在生成代码时并不会真的去检查这些编号是否在你的硬件范围内也不会检查是否和你已有的分配表冲突。比如你的项目里 M100 已经被用来做某个工位状态AI 不知道它可能又给另一段逻辑分配了 M100结果就是两个功能互相干扰。这类问题在简单测试里很难发现一旦放到真实项目里往往表现为“偶尔动一下”“莫名其妙切换状态”“某个输出突然自己停了”。排查起来非常耗时间。建议拿到 AI 生成的代码后第一步不是看逻辑而是先整理所有用到的软元件清单跟项目的地址分配表一一对比。4.3 时序、边沿和扫描周期的隐性错误这类问题最坑因为代码在仿真里跑起来可能没问题但到现场就不对。PLC 程序是循环扫描执行的扫描周期决定了程序在“某一瞬间看到的状态”可能和你直觉上的状态不同。AI 很难真正理解“上升沿”和“电平”在程序里的区别也很难自动处理“保持一个周期”“延时后复位”这类时序问题。比如当 AI 需要实现“启动脉冲后保持状态”它可能直接用OUT输出没有使用 SET/RST 或自锁逻辑导致输出只维持一个扫描周期现场一看就是“按下按钮没反应”。排查思路凡是涉及延时、计数、顺序动作、脉冲输出的逻辑都要在仿真软件里跑一遍观察每个周期的状态变化。4.4 缺少安全分支和异常处理这是我觉得目前 AI 代码和真正工程代码最大的差距。真实 PLC 程序不只是“正常流程”的堆叠还必须有急停处理、互锁、报警、越限保护、手动自动切换、上电初始化等分支。AI 生成代码时通常只关注你描述的正常流程不会主动补全这些安全逻辑。你让它写“两个气缸顺序动作”它会给你一个标准的两步动作。但它不会主动想到如果第一个气缸前进到位传感器坏了怎么办如果中途有人按了急停再复位后应该从哪一步开始如果两个气缸同时卡住未复位能不能允许下一次启动这些内容不是靠“给 AI 更多提示”就能解决的因为每个项目的安全逻辑都不一样必须由熟悉现场的人来做判断。这也是目前 AI 无法替代工程师的核心原因。4.5 看似完整但缺少现场对应关系AI 生成的程序往往会给你一个看起来很“标准”的变量命名比如StartButton、MotorOutput这种。但你现场的实际地址是 X0、Y0这中间需要你自己做映射。更麻烦的是有些 AI 生成的程序会假设一些现场不存在的设备比如它默认有一个“急停输入”就写进了逻辑但你的控制柜根本没有把急停接入 PLC又或者它默认你的气缸到位传感器是常开型但你现场用的是常闭型。这类问题无法通过编译或仿真发现必须到现场确认。给所有把 AI 用于 PLC 编程的工程师一个建议AI 生成代码后先写一份“输入输出对应表”把程序里用到的每个变量、每个地址跟现场实际设备一一对应。对不上的一律不能上机。5. 真要在项目里用可以按这条链路收敛如果想把 AI 用在实际项目里而不是停留在“测试玩一玩”我建议按下面这条链路收敛。5.1 先跑通最小样例再扩展到复杂逻辑不要一上来就让 AI 写完整的设备程序。先拿一个小功能试一遍比如“用三菱 FX3U 写一个电机的启动停止控制”把整个流程跑通。看它能不能编译、能不能仿真、现场逻辑对不对。这一步的核心是建立“人机协作”的信任边界。你会知道哪些内容 AI 值得信任哪些内容必须自己动手改。每个人的边界不同但只有跑过一次才能真正确定。5.2 把 AI 生成代码当成“待评审代码”而不是“成品代码”在团队协作里AI 写的代码必须有评审环节。这个环节不能省因为 AI 不具备硬件感知能力也不了解你的项目历史。评审时可以按这个顺序来查指令是否匹配型号。查软元件清单是否有冲突。查变量命名是否符合团队规范。查是否缺少互锁、急停、复位、初始化逻辑。在仿真软件里跑一遍正常流程和异常流程。5.3 用 AI 做三类事查资料、写注释、生成初稿实际落地中AI 适合做的三类事查资料比如某个指令的具体用法、某个型号支持哪些计数器、某个报错代码是什么意思。写注释给它一段没有注释的程序让它补上中文注释和说明能节省很多整理时间。生成初稿给自己提供一个“第一版”然后在此基础上修改比从一张白纸开始写效率高很多。不建议把 AI 用在两种场景一是直接生成涉及安全保护的逻辑二是生成整个工程级别的完整程序。这两类都需要深厚的现场经验和项目上下文。5.4 排查链路AI 生成的程序跑不起来先查什么如果你拿到一段 AI 生成的程序编译报错或仿真不对按下面的顺序排查看现象是编译报错还是仿真卡住还是动作不对看输入你给 AI 的需求模型、品牌、IO 分配、特殊要求是否描述完整看型号和指令集程序里用的指令是否属于你指定的品牌和型号看软元件地址有没有重复使用、超出范围、预留冲突看数据类型变量类型是否匹配有没有把位变量当字节用或者反之。看时序逻辑涉及边沿、延时、计数、自锁的逻辑在扫描周期下行为对不对。做仿真验证把程序放进编程软件逐步运行观察每一步的输出状态。对现场接线最后到现场确认每个 IO 点和程序的映射是否一致。这个链路跟排查普通软件问题有很大区别因为多了一层“硬件对应关系”。如果你跳过第 4、第 6、第 8 步问题往往会在现场爆发。6. 以后 AI 写 PLC 程序会变成什么样经常有人问我“再过几年 AI 是不是就能直接写 PLC 程序了”。我的看法是它会越来越强但方向不是“直接替代工程师”而是“把工程师从重复劳动里解放出来去做更有价值的判断”。未来更可能出现的工作流是工程师用自然语言描述控制需求AI 直接生成带有地址映射、功能块封装和异常处理的基础框架工程师把精力放在安全逻辑、现场适配和整体架构上。在这个过程中判断力会变成最重要的能力。你要能看出来 AI 生成的代码哪里不对、哪里缺了现场分支、哪里可能在极端情况下出问题。这种能力无法靠工具替代只能靠项目积累。所以与其纠结“哪个 AI 最好”不如先把一个最小样例完整跑一遍。让 AI 生成、你评审、仿真验证、现场调试一次走完你自然就知道哪些环节能提效哪些环节必须自己上。这个循环跑通了比收藏再多的技巧文章都有用。