最近后台收到不少读者留言AI 现在能写 PLC 程序吗各个 AI 品牌到底哪个支持度更好实测下来质量怎么样真正拿到产线用会不会出事这类问题我在过去几个月里反复被问到。因为业务里其实一直在接触西门子、三菱、汇川、倍福这些主流 PLC身边也有工程师开始尝试用 AI 辅助写程序甚至有人把 AI 生成的代码复制进 TIA Portal 就往 PLC 里下载。这个操作让我越看越后背发凉。所以这篇文章我不打算只给结论而是把“AI 写 PLC 程序”这件事从原理到实测再到生产落地风险完整拆开讲讲。如果你也正打算用 AI 生成梯形图、ST 或 SCL 代码建议先看完这一篇再动手。1. AI 写 PLC 和写普通代码的底层差别先说一个很多人容易忽略的事实PLC 编程本质上不是“代码能力”问题而是“工程规范和硬件绑定”问题。AI 写 Python、Java 这类通用语言之所以看起来成熟是因为训练数据极其丰富生态统一运行环境也相对固定。你让 AI 生成一个“读取 CSV 文件并计算平均值”的 Python 脚本它基本能一次写对。因为这类任务在开源代码库、技术博客里被反复写过成千上万遍。但 PLC 程序不一样。PLC 程序天生和硬件厂商绑定西门子的博途TIA Portal用的是 SCL / LAD / FBD指令集以 STEP 7 为基准三菱 GX Works 系列使用梯形图、ST、结构化梯形图指令名和西门子差异巨大汇川、信捷这类国产品牌风格接近三菱但指令细节又有自己的变化倍福 TwinCAT 使用 IEC 61131-3 标准但也引入了大量厂商扩展库比如 Tc2_Standard、Tc2_System更别说还有 AB、施耐德、欧姆龙、基恩士这些同样强势的厂商生态。所以 AI 写 PLC 遇到的第一道坎不是“不会写逻辑”而是“不知道当前项目用的是哪套指令集”。你让 AI 生成一段三菱 FX3U 的变频器读写程序它大概率会给你一段“看起来像 PLC 程序但又不太对”的代码。如果拿这段代码去编译会得到一堆指令不存在的报错。另一个重要差别是PLC 程序运行在扫描周期模型下。// 普通编程思维事件驱动 if (buttonPressed) { motor.run(); }// PLC 编程思维周期扫描 IF StartButton THEN MotorRun : TRUE; END_IF;AI 很容易忽略扫描周期带来的边缘检测、互锁、初始化、复位等问题。这在通用编程里很难暴露但在 PLC 里是直接的安全隐患。所以第一部分的结论非常重要AI 写 PLC 程序不是不能用但它的能力边界比写普通代码要窄得多。你必须为 AI 补充足够的硬件背景和项目上下文它才能输出相对可用的东西。2. 测评方法我是怎么测 AI 写 PLC 的既然要讨论“各个 AI 品牌支持性怎么样”那得先有一个相对一致的测试口径。否则你让 AI 写“一个抢答器程序”它怎么都能给你凑一段但真正到工程验证差距就出来了。我目前使用过的主要 AI 工具包括几类ChatGPT 系列GPT-4 级别及更新版本Claude 系列国产大模型文心一言、通义千问、Kimi、DeepSeek 等IDE 内嵌的 AI 辅助工具比如 Cursor、GitHub Copilot我建议如果你也想做横向对比可以按下面这套标准来测结果会比较有参考价值。2.1 测试任务设计不要只测“写一个电机启停”这种入门程序那体现不出差距。我实际测试时会分三档难度任务示例考察重点入门单按钮启停电机、闪烁灯、定时器控制基础指令、常开常闭、定时器用法进阶三菱 FX3U 通过 RS485 读取变频器频率通信指令、寄存器地址、功能码工程级使用 ST 语言实现多工位机械手状态机控制状态机建模、安全互锁、边界条件2.2 评分维度给每个任务生成的结果我会从六个维度打分语法正确性能否直接在对应 IDE 里编译通过库和指令准确性是否使用了目标 PLC 真实存在的指令、函数块逻辑完整性是否覆盖了初始化、复位、边沿检测、故障处理安全设计是否考虑了急停、互锁、掉电保持等基本安全场景可读性变量命名、注释、程序结构是否清晰可维护性拆分成 FB/FC 还是全部挤在一个 OB 里。这套测评体系不是学术标准但对工程选型足够有参考意义。3. 实测案例三个典型 PLC 任务下面放三个我在测试中使用过的真实任务。为了尊重不同厂商的实际工程习惯我分别选择了厂商生态里最容易出问题的方向来测。3.1 任务一西门子 S7-1200 电机启停控制SCL这个任务是让 AI 写一个带启动、停止、过载保护的电机控制逻辑。输入条件是TIA Portal 环境、S7-1200 PLC、使用 SCL 语言。AI 生成的代码往往长这样// 电机控制功能块 - AI生成示例 FUNCTION_BLOCK FB_MotorControl { S7_Optimized_Access : TRUE } VERSION : 0.1 VAR_INPUT StartBtn : Bool; StopBtn : Bool; Overload : Bool; END_VAR VAR_OUTPUT MotorRun : Bool; END_VAR BEGIN #MotorRun : (#MotorRun OR #StartBtn) AND NOT #StopBtn AND NOT #Overload; END_FUNCTION_BLOCK这段代码初看没什么大问题逻辑也紧凑。但实际在 TIA Portal 里用你会发现几个问题#MotorRun OR #StartBtn这种结构在按钮卡死或扫描周期比较长时可能造成启动命令保持不符合“按钮松开即断开”的常规习惯缺少边沿检测没有独立状态位后续做远程监控时很难知道当前状态是“运行中”还是“已停止”没有故障记忆功能。过载信号一消失电机可能直接自动重启这在设备安全上非常危险。如果给这段代码打分语法正确性可以给 4 分逻辑完整性顶多 2 分安全设计只能给 1 分。所以AI 生成的代码不是不能看而是绝对不能直接下载到 PLC 里。更合理的用法是让它帮你生成逻辑骨架你再根据实际项目要求补上互锁、故障复位和状态保持逻辑。3.2 任务二三菱 FX3U 通过 RS485 读取变频器频率这个任务是很多做设备改造的工程师非常关心的三菱 PLC 通过 RS485 和变频器通信读取/写入运行频率。在没有给出明确寄存器地址和通信协议细节的情况下AI 生成的指令通常是这样的// 三菱 FX3U 变频器通信 - AI生成示例伪代码 LD M0 RS D10 D20 K2 M10或者采用 MODBUS 指令// // 错误示例AI 容易把指令名写错 MOV K21 D8120 SEND K2 K1 H2001 D100 D10 M0 M3这里问题就比较明显了SEND/RECV指令是三菱 FX 系列较早的通信指令实际 FX3U 项目中使用扩展通信指令更常见变频器通信需要明确知道协议是 Modbus RTU 还是专用通信协议比如三菱变频器专用 PU 口协议AI 经常混用D8120通信格式设置、从站号、波特率、校验位这些参数没有硬件手册的话 AI 根本不可能正确推算出来变频器的频率地址会因品牌和型号不同而变化例如三菱变频器 FR-E700 系列的频率写入地址和读取地址都不同AI 很容易写成通用地址。我拿到这段代码后专门做过一次编译测试结果基本是编译失败指令名称在 GX Works3 里根本不存在。这说明一个关键问题AI 对三菱 PLC 的指令记忆往往来自网络论坛和零散教程片段。它知道“大概有这么一条指令”但记不清指令在哪个系列、哪个版本、哪一代软件里可用。3.3 任务三用 ST 语言实现机械手多工位状态机这个任务难度最高也是目前 AI 生成效果最差的一类。做一个简单的搬运机械手控制包含原点检测、夹紧、上升、右移、下降、松开、回原点等步骤。AI 生成的代码通常会把所有逻辑塞进一个 FB 里面用 IF 判断做状态切换看起来非常“工程化”// 机械手控制 - AI生成示例伪代码存在逻辑缺失 CASE state OF 0: // 原点 IF originSensor THEN state : 10; END_IF; 10: // 夹紧 clamp : TRUE; IF clampSensor THEN state : 20; END_IF; 20: // 上升 liftUp : TRUE; // 缺少上升到位检测 state : 30; 30: // 右移 moveRight : TRUE; // 缺少右移到位检测 state : 40; ... END_CASE;这段代码的核心问题是把每个动作的时间和到位检测直接简化掉了用一个状态编号直接跳到下一个状态。实际机械手控制必须考虑每一个气缸的磁性开关反馈、超时报警、急停复位、断电恢复后的状态一致性。可以说AI 生成的这类代码只能当“帮助理解流程”的辅助材料完全不具备直接用于现场调试的水平。4. 各 AI 品牌在 PLC 场景的支持度对比这部分只说体感不指向任何具体公司的具体产品因为模型迭代速度快有些体验今天和上个月已经不一样。4.1 对标准 IEC 61131-3 的支持所有主流 AI 大模型对 IEC 61131-3 标准中的 ST结构化文本、FBD、SFC 都有一定理解。因为它们训练时都看过大量教材和标准化文档。实测下来纯语法层面AI 写 ST 的完成度明显高于梯形图对 LD梯形图的支持基本停留在“把梯形图逻辑转文字描述”或者“反过来把梯形图描述成指令表”的水平无法直接生成可视化梯形图LAD/FBD 是图形化编程AI 输出的形式要么是 XML 要么是助记符但不同 IDE 的格式互不兼容。所以如果你用的是西门子 S7-1200/1500、倍福 TwinCAT、CODESYS 这类以文本 ST/SCL 为主要语言的平台AI 的可用性会明显好于纯梯形图平台。4.2 对厂商私有指令的支持这是拉开差距的地方。品牌/平台AI 支持体感主要问题西门子 TIA Portal相对较好SCL 语法问题不大但指令块参数容易写错DB 访问方式常混淆三菱 GX Works3 / GX Works2中等偏下指令名称经常张冠李戴FX3U/Q 系列的指令容易混淆汇川 / 信捷一般基于三菱风格但具体功能指令参数差异明显AI 没法准确区分倍福 TwinCAT中等标准 ST 还行但库函数、轴控指令经常写出不存在的函数名AB Studio 5000较弱标签式数据模型和厂商专用指令集AI 生成的代码编译通过率较低欧姆龙 / 基恩士较弱生态封闭网上公开代码少AI 训练数据不足这个表格是我根据自己的测试和同行交流总结的不能代表所有情况。但可以反映一个大方向训练数据越多的平台AI 的支持度越好生态越封闭、资料越少的平台AI 越容易编造指令。4.3 语言输入的影响还有一个实际体验上的差异你用中文提问还是英文提问AI 生成的代码质量会有明显差别。很多国产 PLC 指令和中文手册的原始语义用中文提问反而更容易触发模型记忆。但西门子 SCL、倍福 TwinCAT 这些生态相对开放的平台用英文提问、附上官方手册片段效果会更稳定。个人经验是提示词里给出“目标 PLC 型号 编程软件 语言标准 关键 IO 定义 动作流程”这样输出的代码才有一点可用性。只丢一句“帮我写个电机控制程序”AI 给你的就是一个通用模板和你现场的硬件、点表、安全逻辑完全不匹配。5. AI 生成 PLC 代码的高频问题通过多次测试和实际项目复盘我总结出 AI 写 PLC 代码最常见的七个问题。这也是你拿到 AI 输出后需要重点检查的地方。5.1 虚拟指令和指令名幻觉这是最致命的问题。AI 会“创造”一些听起来合理但实际不存在的指令。比如// 看起来合理实际可能不存在的指令 DINT_TO_TIME_CONV或者把三菱的SET M0和OUT M0混用。在纯文本翻译场景下AI 很容易出现这种幻觉而且语法越复杂的指令幻觉率越高。排查方法把 AI 生成的代码放到官方 IDE 里编译。编译通过是底线不通过就得逐个对照指令手册。5.2 寻址错误三菱 PLC 里D是数据寄存器M是中间继电器X是输入Y是输出。西门子里I 区输入、Q 区输出、M 区位存储、DB 是数据块。AI 经常把不同厂商的寻址体系混在一起// 错误示例三菱程序里出现西门子风格寻址 LD I0.0 OUT Y0.0这种代码不仅编译失败更是彻头彻尾的逻辑混乱。5.3 忽略边沿检测在 PLC 编程中按钮信号通常需要上升沿或者下降沿触发特别是在“单按钮启停”“计数”“状态切换”这类场景中。AI 比较难理解“为什么不直接使用按钮状态而必须使用边沿”于是生成大量电平触发的逻辑。这会导致按键变成长按驱动操作一次执行多次或一直置位。5.4 定时器使用不当定时器在 PLC 里有多种类型通电延时定时器 TON断电延时定时器 TOF保持型通电延时定时器 TONR。AI 经常用错特别是掉电保持场景下需要保持计时结果时它还在用普通 TON。更严重的是有时 AI 会把定时器的预设值PT写成一个变量但没有定义该变量编译直接报错。5.5 系统安全逻辑缺失这是最值得警惕的问题。AI 生成的代码骨架通常默认“设备处在正常工作状态”完全没有考虑以下场景急停按下后输出是否能在下一个扫描周期立即断开气缸或电机因异常卡死超时报警如何触发程序进入未知 STATE 时如何处理手动/自动切换时输出是否会瞬间抖动设备断电恢复后中间变量是保持还是复位会不会导致设备突然动作。这些不是“AI 水平差”而是工程经验积累成的行业规范。AI 训练数据里能学到语法但很难学到“在什么工况下必须加什么保护”。5.6 缺少程序结构拆分AI 写复杂功能时倾向于把所有代码堆进一个函数块或一个 OB 中而不是按功能拆分为多个 FB 或 FC。这在语法上没问题但工程上极难维护和排障。特别是当程序超过几百行后这种“大泥球”结构会直接拖垮后续改造效率。5.7 上下文过长后一致性下降大型 PLC 程序往往有几百上千个变量和多个功能块。AI 的上下文窗口有限即使是最新模型也无法完整理解整个项目的所有逻辑关系。你让它修改某一个功能块它可能会改变该功能块内部的变量名导致和其他功能块的接口冲突。这也是 AI 目前最不适合直接重构大型 PLC 项目的原因。6. 实测后的结论AI 写 PLC 到底能用到什么程度这是我比较有把握的判断也符合当前大多数工程师的共识。6.1 可以用的场景生成特定功能块的逻辑骨架比如电机控制、气缸动作、报警汇总把梯形图描述转换成 ST 语言辅助跨平台移植为已有代码生成注释和文档解释一段陌生的 PLC 程序逻辑根据动作流程图生成初始版本再人工优化。6.2 还不能用的场景直接生成整套设备程序并下载到 PLC涉及安全回路的程序例如急停逻辑、安全门互锁、光栅保护涉及轴控制、运动控制、PID 调参等依赖工艺参数的程序需要与第三方设备精确通信的程序在没有手册和协议文档输入的情况下AI 基本无能为力。6.3 生产环境必须坚持的红线我强烈建议不管 AI 工具多强生产环境必须遵守以下原则AI 生成的代码必须经过“官方 IDE 编译 仿真验证 现场空载测试 现场带载测试”四个阶段涉及安全功能的程序不得由 AI 独立完成必须由有资质、有经验的工程师人工确认AI 只能作为效率辅助工具不能直接替代工程师的判断所有 AI 生成代码保留可追溯的版本记录便于问题回溯。7. 让 AI 写 PLC 更靠谱的提示词方法如果你发现 AI 生成的 PLC 代码质量差很多时候不是 AI 笨而是你的提示词给的信息太少。下面分享一套我实测下来比较有效的提示词模板。7.1 基础提示词模板你是 PLC 工程师请帮我写一段 [语言] 程序。 项目背景 - PLC 品牌型号[厂商/系列例如西门子 S7-1200三菱 FX5U] - 编程软件[例如 TIA Portal V17GX Works3] - 控制任务[用两三句话描述控制逻辑] - 输入输出列表 X0 / I0.0启动按钮 X1 / I0.1停止按钮 Y0 / Q0.0电机输出 - 工作流程 1. 按下启动按钮电机启动 2. 按下停止按钮电机停止 3. 过载信号触发时电机立即停止并保持故障状态 4. 故障复位按钮触发后故障状态解除。 要求 - 使用标准 [ST]/[SCL]/[LAD] 语言 - 程序必须包含边沿检测、故障保持、复位逻辑 - 变量命名使用 [匈牙利命名法/蛇形命名法] - 请在注释中说明每个功能块的作用。7.2 让 AI 生成完整工程文件之前先让它列提纲复杂项目不要一上来就让 AI 写全部代码。先让它列出请帮我把一个搬运机械手的控制程序拆分为功能块 列出每个功能块的名称、输入输出变量、职责说明。等结构确认没有大问题后再逐个功能块生成代码。这样极大减少 AI 上下文超长导致的一致性丢失问题。7.3 复述检查法AI 生成代码后可以追加一个问题请检查你上面生成的代码列出可能导致设备安全事故的边界场景 并在代码中补充对应的处理逻辑。这个做法不能保证 100% 安全但能让 AI 尽量反思自己生成的逻辑。实测中复述后生成的代码比第一版明显更完整尤其是故障处理和状态保持方面。7.4 提供完整的外部设备手册描述如果是通信类任务比如三菱 PLC 读取变频器频率你必须把寄存器地址和通信参数喂给 AI不能期待它自己知道。可以这样写变频器通信参数 - 协议Modbus RTU - 从站号1 - 波特率9600 - 数据格式8N1 - 频率读取寄存器地址40001对应功能码 03 - 频率写入寄存器地址40002对应功能码 06 - PLC 侧三菱 FX5U使用 RS485 通信扩展板编程软件 GX Works3 请生成对应程序。信息越具体AI 越不容易瞎编。如果连你都不知道寄存器地址那就先去看变频器手册这个环节不能省。8. 未来趋势和给工程师的建议说说我对这个方向的一个整体判断。AI 在 PLC 编程领域的价值一定是从“辅助片段生成”起步逐步走向“更懂硬件的助手”。现在你问 AI“怎么写三菱变频器通信”可能会得到一堆不可编译的垃圾。但未来厂商如果开放了官方知识库、指令数据库甚至把整个 IDE 编译环境接入 AI AgentAI 写 PLC 代码的质量会明显改善。典型的方向包括厂商把标准功能块库直接喂给模型让 AI 生成代码时自动引用经过认证的功能块AI 助手直接和 TIA Portal、GX Works3 对接生成的不是文本代码而是可以被 IDE 直接导入的标准库文件AI Agent 结合仿真环境自动编译验证后再交付代码而不是给一段“看起来对但实际不能编译”的文字用 AI 做程序审查检查互锁缺失、变量类型不匹配、定时器误用等工程师容易漏掉的问题。但从现在到完全可用还有一段距离。在厂商工具链真正打通之前PLC 工程师应该把 AI 定位成一个“聪明但经验不足的实习生”而不是“可靠的自动化编程专家”。我的建议很简单可以用来学新知识让 AI 解释一条不认识的指令或者把一段梯形图转成 ST学习效率高可以用来做项目预研快速生成一个功能块的初稿评估方案可行性不能用来直接替代现场调试程序里每一项安全逻辑、每一个时间常数都必须由你亲自确认持续跟踪模型迭代AI 能力和训练数据更新非常快半年前的结论可能下个月就过时了。所以不要固守“AI 不行”的旧观念过几个月重新试一次可能会有惊喜。如果自己有条件建议亲手做一个“PLC 测试台”比如用西门子 S7-1200 或三菱 FX5U搭一个小型 Demo。拿 AI 生成的程序做仿真运行对比它写的和现场工程师写的差距在哪里。这样得出的经验比任何网上测评都有价值。 AI写PLC程序靠谱吗？实测对比与生产落地风险解析
最近后台收到不少读者留言AI 现在能写 PLC 程序吗各个 AI 品牌到底哪个支持度更好实测下来质量怎么样真正拿到产线用会不会出事这类问题我在过去几个月里反复被问到。因为业务里其实一直在接触西门子、三菱、汇川、倍福这些主流 PLC身边也有工程师开始尝试用 AI 辅助写程序甚至有人把 AI 生成的代码复制进 TIA Portal 就往 PLC 里下载。这个操作让我越看越后背发凉。所以这篇文章我不打算只给结论而是把“AI 写 PLC 程序”这件事从原理到实测再到生产落地风险完整拆开讲讲。如果你也正打算用 AI 生成梯形图、ST 或 SCL 代码建议先看完这一篇再动手。1. AI 写 PLC 和写普通代码的底层差别先说一个很多人容易忽略的事实PLC 编程本质上不是“代码能力”问题而是“工程规范和硬件绑定”问题。AI 写 Python、Java 这类通用语言之所以看起来成熟是因为训练数据极其丰富生态统一运行环境也相对固定。你让 AI 生成一个“读取 CSV 文件并计算平均值”的 Python 脚本它基本能一次写对。因为这类任务在开源代码库、技术博客里被反复写过成千上万遍。但 PLC 程序不一样。PLC 程序天生和硬件厂商绑定西门子的博途TIA Portal用的是 SCL / LAD / FBD指令集以 STEP 7 为基准三菱 GX Works 系列使用梯形图、ST、结构化梯形图指令名和西门子差异巨大汇川、信捷这类国产品牌风格接近三菱但指令细节又有自己的变化倍福 TwinCAT 使用 IEC 61131-3 标准但也引入了大量厂商扩展库比如 Tc2_Standard、Tc2_System更别说还有 AB、施耐德、欧姆龙、基恩士这些同样强势的厂商生态。所以 AI 写 PLC 遇到的第一道坎不是“不会写逻辑”而是“不知道当前项目用的是哪套指令集”。你让 AI 生成一段三菱 FX3U 的变频器读写程序它大概率会给你一段“看起来像 PLC 程序但又不太对”的代码。如果拿这段代码去编译会得到一堆指令不存在的报错。另一个重要差别是PLC 程序运行在扫描周期模型下。// 普通编程思维事件驱动 if (buttonPressed) { motor.run(); }// PLC 编程思维周期扫描 IF StartButton THEN MotorRun : TRUE; END_IF;AI 很容易忽略扫描周期带来的边缘检测、互锁、初始化、复位等问题。这在通用编程里很难暴露但在 PLC 里是直接的安全隐患。所以第一部分的结论非常重要AI 写 PLC 程序不是不能用但它的能力边界比写普通代码要窄得多。你必须为 AI 补充足够的硬件背景和项目上下文它才能输出相对可用的东西。2. 测评方法我是怎么测 AI 写 PLC 的既然要讨论“各个 AI 品牌支持性怎么样”那得先有一个相对一致的测试口径。否则你让 AI 写“一个抢答器程序”它怎么都能给你凑一段但真正到工程验证差距就出来了。我目前使用过的主要 AI 工具包括几类ChatGPT 系列GPT-4 级别及更新版本Claude 系列国产大模型文心一言、通义千问、Kimi、DeepSeek 等IDE 内嵌的 AI 辅助工具比如 Cursor、GitHub Copilot我建议如果你也想做横向对比可以按下面这套标准来测结果会比较有参考价值。2.1 测试任务设计不要只测“写一个电机启停”这种入门程序那体现不出差距。我实际测试时会分三档难度任务示例考察重点入门单按钮启停电机、闪烁灯、定时器控制基础指令、常开常闭、定时器用法进阶三菱 FX3U 通过 RS485 读取变频器频率通信指令、寄存器地址、功能码工程级使用 ST 语言实现多工位机械手状态机控制状态机建模、安全互锁、边界条件2.2 评分维度给每个任务生成的结果我会从六个维度打分语法正确性能否直接在对应 IDE 里编译通过库和指令准确性是否使用了目标 PLC 真实存在的指令、函数块逻辑完整性是否覆盖了初始化、复位、边沿检测、故障处理安全设计是否考虑了急停、互锁、掉电保持等基本安全场景可读性变量命名、注释、程序结构是否清晰可维护性拆分成 FB/FC 还是全部挤在一个 OB 里。这套测评体系不是学术标准但对工程选型足够有参考意义。3. 实测案例三个典型 PLC 任务下面放三个我在测试中使用过的真实任务。为了尊重不同厂商的实际工程习惯我分别选择了厂商生态里最容易出问题的方向来测。3.1 任务一西门子 S7-1200 电机启停控制SCL这个任务是让 AI 写一个带启动、停止、过载保护的电机控制逻辑。输入条件是TIA Portal 环境、S7-1200 PLC、使用 SCL 语言。AI 生成的代码往往长这样// 电机控制功能块 - AI生成示例 FUNCTION_BLOCK FB_MotorControl { S7_Optimized_Access : TRUE } VERSION : 0.1 VAR_INPUT StartBtn : Bool; StopBtn : Bool; Overload : Bool; END_VAR VAR_OUTPUT MotorRun : Bool; END_VAR BEGIN #MotorRun : (#MotorRun OR #StartBtn) AND NOT #StopBtn AND NOT #Overload; END_FUNCTION_BLOCK这段代码初看没什么大问题逻辑也紧凑。但实际在 TIA Portal 里用你会发现几个问题#MotorRun OR #StartBtn这种结构在按钮卡死或扫描周期比较长时可能造成启动命令保持不符合“按钮松开即断开”的常规习惯缺少边沿检测没有独立状态位后续做远程监控时很难知道当前状态是“运行中”还是“已停止”没有故障记忆功能。过载信号一消失电机可能直接自动重启这在设备安全上非常危险。如果给这段代码打分语法正确性可以给 4 分逻辑完整性顶多 2 分安全设计只能给 1 分。所以AI 生成的代码不是不能看而是绝对不能直接下载到 PLC 里。更合理的用法是让它帮你生成逻辑骨架你再根据实际项目要求补上互锁、故障复位和状态保持逻辑。3.2 任务二三菱 FX3U 通过 RS485 读取变频器频率这个任务是很多做设备改造的工程师非常关心的三菱 PLC 通过 RS485 和变频器通信读取/写入运行频率。在没有给出明确寄存器地址和通信协议细节的情况下AI 生成的指令通常是这样的// 三菱 FX3U 变频器通信 - AI生成示例伪代码 LD M0 RS D10 D20 K2 M10或者采用 MODBUS 指令// // 错误示例AI 容易把指令名写错 MOV K21 D8120 SEND K2 K1 H2001 D100 D10 M0 M3这里问题就比较明显了SEND/RECV指令是三菱 FX 系列较早的通信指令实际 FX3U 项目中使用扩展通信指令更常见变频器通信需要明确知道协议是 Modbus RTU 还是专用通信协议比如三菱变频器专用 PU 口协议AI 经常混用D8120通信格式设置、从站号、波特率、校验位这些参数没有硬件手册的话 AI 根本不可能正确推算出来变频器的频率地址会因品牌和型号不同而变化例如三菱变频器 FR-E700 系列的频率写入地址和读取地址都不同AI 很容易写成通用地址。我拿到这段代码后专门做过一次编译测试结果基本是编译失败指令名称在 GX Works3 里根本不存在。这说明一个关键问题AI 对三菱 PLC 的指令记忆往往来自网络论坛和零散教程片段。它知道“大概有这么一条指令”但记不清指令在哪个系列、哪个版本、哪一代软件里可用。3.3 任务三用 ST 语言实现机械手多工位状态机这个任务难度最高也是目前 AI 生成效果最差的一类。做一个简单的搬运机械手控制包含原点检测、夹紧、上升、右移、下降、松开、回原点等步骤。AI 生成的代码通常会把所有逻辑塞进一个 FB 里面用 IF 判断做状态切换看起来非常“工程化”// 机械手控制 - AI生成示例伪代码存在逻辑缺失 CASE state OF 0: // 原点 IF originSensor THEN state : 10; END_IF; 10: // 夹紧 clamp : TRUE; IF clampSensor THEN state : 20; END_IF; 20: // 上升 liftUp : TRUE; // 缺少上升到位检测 state : 30; 30: // 右移 moveRight : TRUE; // 缺少右移到位检测 state : 40; ... END_CASE;这段代码的核心问题是把每个动作的时间和到位检测直接简化掉了用一个状态编号直接跳到下一个状态。实际机械手控制必须考虑每一个气缸的磁性开关反馈、超时报警、急停复位、断电恢复后的状态一致性。可以说AI 生成的这类代码只能当“帮助理解流程”的辅助材料完全不具备直接用于现场调试的水平。4. 各 AI 品牌在 PLC 场景的支持度对比这部分只说体感不指向任何具体公司的具体产品因为模型迭代速度快有些体验今天和上个月已经不一样。4.1 对标准 IEC 61131-3 的支持所有主流 AI 大模型对 IEC 61131-3 标准中的 ST结构化文本、FBD、SFC 都有一定理解。因为它们训练时都看过大量教材和标准化文档。实测下来纯语法层面AI 写 ST 的完成度明显高于梯形图对 LD梯形图的支持基本停留在“把梯形图逻辑转文字描述”或者“反过来把梯形图描述成指令表”的水平无法直接生成可视化梯形图LAD/FBD 是图形化编程AI 输出的形式要么是 XML 要么是助记符但不同 IDE 的格式互不兼容。所以如果你用的是西门子 S7-1200/1500、倍福 TwinCAT、CODESYS 这类以文本 ST/SCL 为主要语言的平台AI 的可用性会明显好于纯梯形图平台。4.2 对厂商私有指令的支持这是拉开差距的地方。品牌/平台AI 支持体感主要问题西门子 TIA Portal相对较好SCL 语法问题不大但指令块参数容易写错DB 访问方式常混淆三菱 GX Works3 / GX Works2中等偏下指令名称经常张冠李戴FX3U/Q 系列的指令容易混淆汇川 / 信捷一般基于三菱风格但具体功能指令参数差异明显AI 没法准确区分倍福 TwinCAT中等标准 ST 还行但库函数、轴控指令经常写出不存在的函数名AB Studio 5000较弱标签式数据模型和厂商专用指令集AI 生成的代码编译通过率较低欧姆龙 / 基恩士较弱生态封闭网上公开代码少AI 训练数据不足这个表格是我根据自己的测试和同行交流总结的不能代表所有情况。但可以反映一个大方向训练数据越多的平台AI 的支持度越好生态越封闭、资料越少的平台AI 越容易编造指令。4.3 语言输入的影响还有一个实际体验上的差异你用中文提问还是英文提问AI 生成的代码质量会有明显差别。很多国产 PLC 指令和中文手册的原始语义用中文提问反而更容易触发模型记忆。但西门子 SCL、倍福 TwinCAT 这些生态相对开放的平台用英文提问、附上官方手册片段效果会更稳定。个人经验是提示词里给出“目标 PLC 型号 编程软件 语言标准 关键 IO 定义 动作流程”这样输出的代码才有一点可用性。只丢一句“帮我写个电机控制程序”AI 给你的就是一个通用模板和你现场的硬件、点表、安全逻辑完全不匹配。5. AI 生成 PLC 代码的高频问题通过多次测试和实际项目复盘我总结出 AI 写 PLC 代码最常见的七个问题。这也是你拿到 AI 输出后需要重点检查的地方。5.1 虚拟指令和指令名幻觉这是最致命的问题。AI 会“创造”一些听起来合理但实际不存在的指令。比如// 看起来合理实际可能不存在的指令 DINT_TO_TIME_CONV或者把三菱的SET M0和OUT M0混用。在纯文本翻译场景下AI 很容易出现这种幻觉而且语法越复杂的指令幻觉率越高。排查方法把 AI 生成的代码放到官方 IDE 里编译。编译通过是底线不通过就得逐个对照指令手册。5.2 寻址错误三菱 PLC 里D是数据寄存器M是中间继电器X是输入Y是输出。西门子里I 区输入、Q 区输出、M 区位存储、DB 是数据块。AI 经常把不同厂商的寻址体系混在一起// 错误示例三菱程序里出现西门子风格寻址 LD I0.0 OUT Y0.0这种代码不仅编译失败更是彻头彻尾的逻辑混乱。5.3 忽略边沿检测在 PLC 编程中按钮信号通常需要上升沿或者下降沿触发特别是在“单按钮启停”“计数”“状态切换”这类场景中。AI 比较难理解“为什么不直接使用按钮状态而必须使用边沿”于是生成大量电平触发的逻辑。这会导致按键变成长按驱动操作一次执行多次或一直置位。5.4 定时器使用不当定时器在 PLC 里有多种类型通电延时定时器 TON断电延时定时器 TOF保持型通电延时定时器 TONR。AI 经常用错特别是掉电保持场景下需要保持计时结果时它还在用普通 TON。更严重的是有时 AI 会把定时器的预设值PT写成一个变量但没有定义该变量编译直接报错。5.5 系统安全逻辑缺失这是最值得警惕的问题。AI 生成的代码骨架通常默认“设备处在正常工作状态”完全没有考虑以下场景急停按下后输出是否能在下一个扫描周期立即断开气缸或电机因异常卡死超时报警如何触发程序进入未知 STATE 时如何处理手动/自动切换时输出是否会瞬间抖动设备断电恢复后中间变量是保持还是复位会不会导致设备突然动作。这些不是“AI 水平差”而是工程经验积累成的行业规范。AI 训练数据里能学到语法但很难学到“在什么工况下必须加什么保护”。5.6 缺少程序结构拆分AI 写复杂功能时倾向于把所有代码堆进一个函数块或一个 OB 中而不是按功能拆分为多个 FB 或 FC。这在语法上没问题但工程上极难维护和排障。特别是当程序超过几百行后这种“大泥球”结构会直接拖垮后续改造效率。5.7 上下文过长后一致性下降大型 PLC 程序往往有几百上千个变量和多个功能块。AI 的上下文窗口有限即使是最新模型也无法完整理解整个项目的所有逻辑关系。你让它修改某一个功能块它可能会改变该功能块内部的变量名导致和其他功能块的接口冲突。这也是 AI 目前最不适合直接重构大型 PLC 项目的原因。6. 实测后的结论AI 写 PLC 到底能用到什么程度这是我比较有把握的判断也符合当前大多数工程师的共识。6.1 可以用的场景生成特定功能块的逻辑骨架比如电机控制、气缸动作、报警汇总把梯形图描述转换成 ST 语言辅助跨平台移植为已有代码生成注释和文档解释一段陌生的 PLC 程序逻辑根据动作流程图生成初始版本再人工优化。6.2 还不能用的场景直接生成整套设备程序并下载到 PLC涉及安全回路的程序例如急停逻辑、安全门互锁、光栅保护涉及轴控制、运动控制、PID 调参等依赖工艺参数的程序需要与第三方设备精确通信的程序在没有手册和协议文档输入的情况下AI 基本无能为力。6.3 生产环境必须坚持的红线我强烈建议不管 AI 工具多强生产环境必须遵守以下原则AI 生成的代码必须经过“官方 IDE 编译 仿真验证 现场空载测试 现场带载测试”四个阶段涉及安全功能的程序不得由 AI 独立完成必须由有资质、有经验的工程师人工确认AI 只能作为效率辅助工具不能直接替代工程师的判断所有 AI 生成代码保留可追溯的版本记录便于问题回溯。7. 让 AI 写 PLC 更靠谱的提示词方法如果你发现 AI 生成的 PLC 代码质量差很多时候不是 AI 笨而是你的提示词给的信息太少。下面分享一套我实测下来比较有效的提示词模板。7.1 基础提示词模板你是 PLC 工程师请帮我写一段 [语言] 程序。 项目背景 - PLC 品牌型号[厂商/系列例如西门子 S7-1200三菱 FX5U] - 编程软件[例如 TIA Portal V17GX Works3] - 控制任务[用两三句话描述控制逻辑] - 输入输出列表 X0 / I0.0启动按钮 X1 / I0.1停止按钮 Y0 / Q0.0电机输出 - 工作流程 1. 按下启动按钮电机启动 2. 按下停止按钮电机停止 3. 过载信号触发时电机立即停止并保持故障状态 4. 故障复位按钮触发后故障状态解除。 要求 - 使用标准 [ST]/[SCL]/[LAD] 语言 - 程序必须包含边沿检测、故障保持、复位逻辑 - 变量命名使用 [匈牙利命名法/蛇形命名法] - 请在注释中说明每个功能块的作用。7.2 让 AI 生成完整工程文件之前先让它列提纲复杂项目不要一上来就让 AI 写全部代码。先让它列出请帮我把一个搬运机械手的控制程序拆分为功能块 列出每个功能块的名称、输入输出变量、职责说明。等结构确认没有大问题后再逐个功能块生成代码。这样极大减少 AI 上下文超长导致的一致性丢失问题。7.3 复述检查法AI 生成代码后可以追加一个问题请检查你上面生成的代码列出可能导致设备安全事故的边界场景 并在代码中补充对应的处理逻辑。这个做法不能保证 100% 安全但能让 AI 尽量反思自己生成的逻辑。实测中复述后生成的代码比第一版明显更完整尤其是故障处理和状态保持方面。7.4 提供完整的外部设备手册描述如果是通信类任务比如三菱 PLC 读取变频器频率你必须把寄存器地址和通信参数喂给 AI不能期待它自己知道。可以这样写变频器通信参数 - 协议Modbus RTU - 从站号1 - 波特率9600 - 数据格式8N1 - 频率读取寄存器地址40001对应功能码 03 - 频率写入寄存器地址40002对应功能码 06 - PLC 侧三菱 FX5U使用 RS485 通信扩展板编程软件 GX Works3 请生成对应程序。信息越具体AI 越不容易瞎编。如果连你都不知道寄存器地址那就先去看变频器手册这个环节不能省。8. 未来趋势和给工程师的建议说说我对这个方向的一个整体判断。AI 在 PLC 编程领域的价值一定是从“辅助片段生成”起步逐步走向“更懂硬件的助手”。现在你问 AI“怎么写三菱变频器通信”可能会得到一堆不可编译的垃圾。但未来厂商如果开放了官方知识库、指令数据库甚至把整个 IDE 编译环境接入 AI AgentAI 写 PLC 代码的质量会明显改善。典型的方向包括厂商把标准功能块库直接喂给模型让 AI 生成代码时自动引用经过认证的功能块AI 助手直接和 TIA Portal、GX Works3 对接生成的不是文本代码而是可以被 IDE 直接导入的标准库文件AI Agent 结合仿真环境自动编译验证后再交付代码而不是给一段“看起来对但实际不能编译”的文字用 AI 做程序审查检查互锁缺失、变量类型不匹配、定时器误用等工程师容易漏掉的问题。但从现在到完全可用还有一段距离。在厂商工具链真正打通之前PLC 工程师应该把 AI 定位成一个“聪明但经验不足的实习生”而不是“可靠的自动化编程专家”。我的建议很简单可以用来学新知识让 AI 解释一条不认识的指令或者把一段梯形图转成 ST学习效率高可以用来做项目预研快速生成一个功能块的初稿评估方案可行性不能用来直接替代现场调试程序里每一项安全逻辑、每一个时间常数都必须由你亲自确认持续跟踪模型迭代AI 能力和训练数据更新非常快半年前的结论可能下个月就过时了。所以不要固守“AI 不行”的旧观念过几个月重新试一次可能会有惊喜。如果自己有条件建议亲手做一个“PLC 测试台”比如用西门子 S7-1200 或三菱 FX5U搭一个小型 Demo。拿 AI 生成的程序做仿真运行对比它写的和现场工程师写的差距在哪里。这样得出的经验比任何网上测评都有价值。