1. 从一条产线改造的吐槽说起上个月帮一个做非标自动化的老朋友看项目他接了个六轴机械臂配视觉分拣的活控制核心用的是汇川的PLC上位机用CODESYS做逻辑触摸屏走Modbus。他跟我吐槽了一件事现在招进来的年轻工程师梯形图写得稀烂但用AI编程助手生成ST代码倒是飞快问题是生成出来的东西看着对跑起来全是坑——变量命名混乱、扫描周期没考虑、急停逻辑和普通逻辑混在一个POU里最后调试阶段返工的时间比手写还长。这个场景让我突然意识到一件事AI编程现在走的路和当年PLC替代继电器逻辑柜走的路几乎是同一条。上世纪七八十年代继电器逻辑柜是工业控制的主流一堆中间继电器、时间继电器、接触器硬接线堆出来的控制柜改一个逻辑要重新接线排查故障要拿着万用表一根根量。PLC出现之后逻辑变成了软件改逻辑不用动线排查靠监控变量。当时老一辈电工也骂过这玩意儿看不见摸不着断电就没了哪有继电器靠谱结果呢PLC成了工业控制的标准底座。今天的AI编程助手——Cursor、Windsurf、VS Code Copilot、Trae这些——扮演的角色恰恰就是当年PLC在继电器柜面前扮演的角色。它把写代码这件事从手工劳动变成了描述需求审核结果的工程活动。但问题也一模一样工具越抽象对使用者的底层理解要求反而越高。你让一个不懂扫描周期的人去写PLC程序他写出来的东西在仿真里跑得通上机就炸你让一个不懂内存模型和并发的人去用AI生成后端代码本地测试全绿上线就雪崩。这篇东西不打算吹AI编程有多神也不打算唱衰它。我想做的是把AI编程和PLC这两条看似不搭界的线拧在一起从工程实践的视角拆一拆它们共享的底层逻辑是什么、AI编程现在踩的坑为什么和PLC早期一模一样、以及一个真正能落地的AI辅助编程工作流应该长什么样。如果你是从PLC转过来的工程师或者是从纯软件想切入工业控制的开发者这篇应该能帮你少走不少弯路。2. PLC的进化史就是AI编程的预演2.1 从硬接线到软逻辑抽象层上移的代价继电器逻辑柜时代一个电机星三角降压启动的控制逻辑是用接触器、时间继电器、热继电器硬接线实现的。逻辑是物理存在的——你能看见哪根线接哪个端子能摸到继电器吸合的动作。这种具象化带来的好处是排查直观坏处是任何逻辑变更都等于物理改造。PLC把这个逻辑搬进了存储器。梯形图LAD本质上是用图形化的方式模拟继电器逻辑但底层已经是扫描周期驱动的软件执行。这里出现了一个关键转折逻辑不再物理存在而是时间存在——它依赖于CPU每个扫描周期对输入采样、程序执行、输出刷新的循环。这个转折带来的代价今天的AI编程正在原样复现维度继电器时代PLC时代AI编程时代逻辑载体物理接线存储器中的程序自然语言描述模型生成修改成本重新接线改程序下载改提示词重新生成排查方式万用表量通断在线监控变量读代码断点调试核心门槛电路原理扫描周期IO映射上下文理解架构判断典型翻车线接错双线圈/扫描顺序错幻觉API/并发错误你看这张表最右边一列和中间一列的核心门槛和典型翻车是不是惊人地相似PLC新手最常犯的错是双线圈输出——同一个输出线圈在程序里出现两次后扫描的覆盖先扫描的逻辑上看起来对实际行为完全不是你想的那样。AI编程新手最常犯的错是什么同一个功能让AI生成两段代码一段用了某个库的v1 API一段用了v2 API混在一起编译能过运行时行为不一致。本质都是抽象层上移之后你对底层执行模型的理解没跟上。2.2 扫描周期思维AI编程最缺的那根弦PLC工程师有一个刻在骨子里的概念扫描周期。一个扫描周期分三个阶段——输入采样、程序执行、输出刷新。这意味着你在程序里读到的输入值是整个扫描周期开始时锁存的不是实时的。你在程序里写的输出值要等扫描周期结束才真正作用到物理输出端子上。程序执行阶段输入的变化不会立即反映到你的逻辑里。这个模型逼着PLC工程师养成一个习惯任何逻辑都要考虑它在哪个时刻生效。一个急停按钮按下从物理信号到程序里读到中间有一个扫描周期的延迟从程序里写输出到物理接触器断开又有一个扫描周期。对于高速安全场景这个延迟是要算进安全距离里的。AI编程助手现在最大的问题恰恰是没有扫描周期思维。你让Cursor生成一段处理用户请求的代码它会给你一个看起来逻辑完整的函数但它不会主动告诉你这段代码在并发场景下两个请求同时读到同一个状态、同时修改、后写的覆盖先写的——这就是软件世界的双线圈。我实测过很多次用AI生成PLC的ST代码如果你不明确告诉它这是一个循环扫描执行的程序所有变量在每个周期都会被重新求值它生成的代码经常带着事件驱动的思维惯性。比如它会写一个IF button_pressed THEN toggle_output; END_IF在PLC里这会导致输出在每个扫描周期都翻转一次因为button_pressed在按钮按住期间一直是TRUE。正确的写法应该是边沿检测IF button_pressed AND NOT button_pressed_prev THEN toggle_output; END_IF。这个坑PLC老手一眼就能看出来但AI不知道。因为AI的训练数据里事件驱动的代码远远多于循环扫描的代码。2.3 为什么工业场景对AI编程格外苛刻工业控制场景有几个特点让它对AI编程的容错率远低于互联网应用第一状态是持续的。一个PLC程序可能连续运行几个月不重启所有状态都在内存里累积。互联网应用可以靠重启解决大部分问题PLC不行——你重启一次产线损失可能是几十万。第二错误代价不对称。互联网应用出bug最多是用户看到报错页面。PLC出bug可能是机械臂撞机、阀门误动作、甚至人身伤害。这种不对称性决定了AI生成的代码必须经过更严格的审核。第三调试窗口极窄。产线调试通常在深夜或停产窗口进行你没有时间慢慢试错。这就要求代码在第一次下载运行时就有很高的正确率。第四硬件耦合深。PLC程序不是跑在通用服务器上它和具体的IO模块、通信协议、驱动器参数强耦合。AI对具体硬件型号的理解往往停留在文档层面缺乏实际调试经验。这四点叠加起来意味着AI编程在工业场景的落地不能照搬互联网那套快速迭代、小步快跑的思路。它需要一套更保守、更强调验证的工作流。3. AI编程助手在PLC场景的真实能力边界3.1 我拿四个主流工具跑同一段PLC逻辑的结果为了搞清楚现在这些AI编程助手到底能干什么我设计了一个测试用同一段需求——三台电机顺序启动、逆序停止带过载保护和急停启动间隔3秒停止间隔4秒——分别让Cursor、Windsurf、VS Code Copilot和Trae生成西门子S7-1200的SCL代码。需求描述我写得比较完整包含了IO分配、定时器要求、互锁条件。结果如下工具生成质量主要问题可用度Cursor结构完整变量声明规范定时器用TON但没考虑首次扫描急停逻辑放在主程序末尾改3处可用Windsurf逻辑正确注释详细变量命名用了驼峰不符合西门子习惯缺少过载复位逻辑改2处可用VS Code Copilot补全式生成片段质量高需要人工拼接整体架构要自己搭适合有经验者Trae中文注释友好理解需求准确定时器时间格式写错S5T#和TIME混淆改2处可用这个测试让我得出一个结论AI生成的PLC代码在语法正确性上已经能打70分但在工程正确性上只有40分。语法正确性指的是代码能编译、变量类型对、指令用法没错工程正确性指的是扫描周期考虑、边沿检测、故障安全、可维护性这些只有实际调过机的人才会在意的东西。3.2 为什么AI写不好边沿和互锁边沿检测和互锁逻辑是PLC编程里最基础也最容易出错的两个点AI在这两块的表现尤其差。先说边沿。PLC里的边沿检测有两种实现方式一种是硬件层面的用带边沿检测的输入模块一种是软件层面的用R_TRIG/F_TRIG功能块或者自己用prev变量做。AI生成代码时如果你不明确要求它大概率会写成电平判断而不是边沿判断。原因很简单训练数据里电平判断的代码量远大于边沿判断。再说互锁。工业场景里的互锁分好几种电气互锁接触器常闭触点、程序互锁逻辑上禁止同时输出、机械互锁物理结构上不可能同时动作。AI能理解程序互锁但它经常忽略一个关键点互锁逻辑应该放在输出之前还是之后放在之前互锁条件不满足时输出根本不会置位放在之后输出可能先置位再被互锁复位中间有一个扫描周期的毛刺。对于某些敏感设备这个毛刺就是事故。我踩过的一个真实坑用AI生成一段控制液压站蓄能器充压的代码AI把压力上限判断放在了输出赋值之后。仿真时看不出来实际上机时发现压力到了上限输出还会多保持一个扫描周期导致溢流阀频繁动作。后来把判断挪到输出之前才解决。提示让AI生成PLC代码时务必在提示词里明确所有互锁和保护逻辑必须在输出赋值之前完成判断这一句话能省掉大量返工。3.3 变量命名和IO映射AI最容易埋雷的地方PLC编程有一个和通用软件开发很不一样的习惯变量命名直接对应物理点位。比如I0.0_StartBtn、Q0.1_Motor1Run、M10.0_SystemReady。这种命名方式让程序可读性极高维护的人一眼就知道这个变量对应哪个端子。AI生成代码时默认的命名风格是软件工程那套startButton、motor1Running、systemReady。这在纯软件项目里没问题但在PLC项目里是灾难——因为调试的时候你要对着电气图纸找点位命名不带点位信息你得来回翻IO表。更麻烦的是IO映射。PLC的输入输出点在程序里通常要映射到中间变量M区或DB块这样做的目的是隔离物理层和逻辑层。物理点位可能因为硬件改版而变化但逻辑层引用的中间变量不变。AI经常直接把I0.0写在逻辑里省掉了映射层。短期看没问题长期看是技术债。我现在的做法是在提示词里直接给AI一个命名规范模板比如输入变量格式I{byte}.{bit}_{功能名}输出变量格式Q{byte}.{bit}_{功能名}所有物理IO必须映射到DB_IO数据块后再使用。这样生成出来的代码可维护性会好很多。4. 把AI编程当成高级编译器而不是程序员4.1 提示词工程的本质是需求规格说明书很多人用AI编程助手习惯是想到哪问到哪一句帮我写个电机控制程序就指望AI给出能用的代码。这种用法在PLC场景基本等于自杀。我观察下来AI编程助手在PLC场景的有效用法是把提示词当成一份微型需求规格说明书来写。一份合格的PLC需求规格说明书应该包含IO清单所有输入输出的点位、功能、类型数字量/模拟量控制流程启动条件、停止条件、运行中的状态转换保护逻辑过载、超时、急停、互锁的触发条件和动作时序要求各动作之间的延时、顺序异常处理故障后的复位方式、报警输出命名规范变量命名规则、IO映射规则你把这六项写清楚AI生成的代码质量会有一个质的飞跃。我实测过同样一个三电机顺序启停的需求用一句话描述生成的代码需要改5处用完整规格说明书生成的代码只需要改1处。这其实和PLC编程的老规矩是一样的先画流程图再写程序。只不过现在流程图是用自然语言描述的AI帮你翻译成代码。4.2 上下文窗口AI的工作内存和PLC的DB块AI编程助手有一个核心限制上下文窗口。它一次能看到的代码量是有限的。这导致一个现象当项目规模超过一定阈值AI生成的代码质量会断崖式下降。原因不难理解。AI生成代码时需要参考项目里已有的变量定义、函数签名、数据结构。如果这些信息超出了上下文窗口AI就只能猜猜出来的东西和现有代码对不上就会出现变量名冲突、类型不匹配、重复定义这些问题。这个限制和PLC的DB块数据块有异曲同工之处。PLC的DB块是有限大小的你不能把所有数据都塞进一个DB块必须按功能拆分。AI的上下文窗口也是一样你不能指望它一次处理整个项目必须按模块拆分每个模块单独生成然后人工做集成。我现在的做法是把PLC项目按功能拆成若干POU程序组织单元每个POU单独让AI生成生成时把该POU依赖的变量定义和接口说明一起喂给AI。这样虽然麻烦一点但生成质量稳定得多。4.3 从生成到审核角色转换的关键用AI编程最危险的心态是它生成的应该没问题。最健康的心态是它生成的每一行我都要审。审核AI生成的PLC代码我有一套固定的检查清单扫描周期检查有没有依赖实时输入的逻辑有没有边沿检测缺失互锁检查所有互锁是否在输出之前互锁条件是否完整故障安全检查急停、断电、通信中断时输出是否进入安全状态定时器检查定时器类型TON/TOF/TP是否用对时间格式是否正确变量检查命名是否符合规范IO映射是否完整有没有重复定义边界检查模拟量输入超范围怎么处理计数器溢出怎么处理这套清单走一遍基本能拦住80%的AI生成代码的坑。剩下的20%靠仿真和实际调试。5. 一个可复现的AI辅助PLC开发工作流5.1 环境准备工具链怎么搭先说工具选型。PLC开发不像纯软件开发工具链受限于PLC品牌。西门子用TIA Portal汇川用InoProShop基于CODESYS三菱用GX Works欧姆龙用Sysmac Studio。AI编程助手是外挂在这些工具之外的。我的推荐组合是代码生成Cursor或Trae中文理解好对ST/SCL语法支持不错代码审核VS Code Copilot补全式审核边看边问仿真验证PLC品牌自带的仿真器如西门子PLCSIM、CODESYS Simulation版本管理GitPLC代码也要版本管理别笑这是刚需这里重点说一下Git。PLC项目用Git管理最大的障碍是TIA Portal的项目文件是二进制格式没法diff。解决办法是把ST/SCL代码导出为文本格式再提交。TIA Portal支持导出源文件CODESYS本身就支持文本格式。这样每次改动都能看到diffAI生成的代码和手写代码的差异一目了然。5.2 提示词模板我用了半年的那个版本下面是我实际在用的PLC代码生成提示词模板针对西门子SCL优化过其他品牌改一下语法就行你是一名有10年经验的PLC工程师请根据以下需求生成西门子S7-1200的SCL代码。 【项目背景】 [一句话描述项目] 【IO清单】 输入 - I0.0: 启动按钮常开 - I0.1: 停止按钮常闭 - ... 输出 - Q0.0: 电机1接触器 - ... 【控制流程】 1. [步骤1] 2. [步骤2] ... 【保护逻辑】 - 过载I0.2为TRUE时立即停止所有输出置位故障标志 - 急停I0.3为FALSE时立即停止所有输出 - ... 【时序要求】 - 启动间隔3秒 - 停止间隔4秒 - ... 【命名规范】 - 输入变量I{byte}.{bit}_{功能名} - 输出变量Q{byte}.{bit}_{功能名} - 中间变量M{byte}.{bit}_{功能名} - 所有物理IO必须映射到DB_IO数据块 【代码要求】 - 所有互锁和保护逻辑必须在输出赋值之前 - 所有按钮输入必须做边沿检测 - 定时器使用TON时间格式用T#3S - 每个POU不超过50行超过则拆分 - 添加中文注释 请生成完整的SCL代码包括变量声明和程序主体。这个模板的关键在于把工程约束显式写进提示词。你不写AI就按软件工程的默认习惯来你写了AI就会遵守。5.3 生成-审核-仿真-上机的四步闭环有了提示词模板接下来是工作流。我把它总结成四步闭环第一步生成。按模块拆分每个模块单独生成。生成时把该模块的IO清单、控制流程、保护逻辑写清楚。不要一次生成整个项目。第二步审核。用前面说的六项检查清单过一遍。重点看边沿检测、互锁位置、故障安全。审核时不要只看代码逻辑还要对照IO表逐个核对点位。第三步仿真。把生成的代码导入PLC仿真器构造测试用例。测试用例要覆盖正常启动停止、急停触发、过载触发、通信中断、边界条件如定时器时间设为0。仿真通过不代表上机通过但仿真不通过一定不能上机。第四步上机。上机调试时先用单步执行或低速运行模式验证逻辑确认无误后再全速运行。上机过程中记录所有异常回头修正提示词模板让下一次生成质量更高。这个闭环跑顺了之后AI生成代码的首次上机通过率能从40%提到70%左右。剩下的30%靠的是经验积累和提示词迭代。5.4 版本管理和回滚别让AI改乱你的代码AI编程助手有一个副作用它改代码的速度太快了快到你可能来不及反应就改乱了。尤其是当你在一个成熟项目上让AI做局部修改时它可能会顺手改掉一些你没让它改的地方。解决办法只有一个Git。每次让AI改代码之前先commit一次。改完之后diff一下看看AI到底改了什么。如果改乱了直接回滚。我踩过的一个坑让AI给一个已经调好的程序优化一下结构结果它把几个POU的调用顺序改了导致扫描周期变化原本正常的逻辑出现了时序问题。幸好有Git回滚只花了10秒。如果没有版本管理这个坑可能要花半天排查。注意PLC项目的Git提交一定要把导出的ST/SCL源文件一起提交不要只提交二进制项目文件。二进制文件没法diff等于白提交。6. 那些AI不会告诉你的PLC实战细节6.1 扫描周期和程序结构的隐性关系PLC的程序结构直接影响扫描周期。你把所有逻辑放在一个主程序里扫描周期就长你拆成多个子程序按需调用扫描周期就短。AI生成代码时默认会把所有逻辑堆在一起因为它不知道你的扫描周期预算。一个实际的例子我做过一个项目主程序扫描周期要求小于10ms。AI生成的代码把所有逻辑放在一个POU里实测扫描周期15ms超标。后来拆成三个POU用条件调用只在需要时调用扫描周期降到8ms。这个细节AI不会主动考虑因为提示词里没写。你得在提示词里明确主程序扫描周期要求小于Xms请合理拆分POU。6.2 模拟量处理的那些坑模拟量输入在PLC里是一个容易出问题的地方。AI生成模拟量处理代码时经常忽略几个点第一量程转换。4-20mA信号对应0-27648西门子或0-32767其他品牌需要线性转换到实际工程量。AI经常直接拿原始值用忘了转换。第二滤波。模拟量信号有噪声需要滤波。简单的做法是取多次采样的平均值复杂的用一阶滞后滤波。AI默认不滤波。第三断线检测。4-20mA信号如果电流低于3.6mA说明断线了。AI默认不检测。第四超限报警。模拟量超过量程上限或下限要报警。AI默认不处理。这四个点你在提示词里不写AI就不做。写了它才会加进去。6.3 通信中断的故障安全设计PLC和上位机、触摸屏、变频器之间的通信随时可能中断。通信中断时PLC应该进入什么状态这是一个故障安全设计问题。AI生成通信代码时通常只处理通信正常的情况不处理通信中断。比如它生成一段读取变频器频率的代码如果通信中断读回来的值是0或者上一次的值AI不管直接拿去用。正确的做法是通信中断时相关输出进入安全状态。比如变频器通信中断PLC应该输出一个通信故障标志同时把变频器的使能输出置FALSE让变频器自由停车。这个逻辑AI不会主动加因为提示词里没提。故障安全设计是PLC工程师的核心职责不能指望AI。6.4 调试阶段的最小可运行原则AI生成的代码往往一次性生成了完整功能。这在调试阶段是灾难——出了问题你不知道是哪部分导致的。我的做法是让AI分阶段生成每次只生成一个最小可运行的功能。比如先只生成电机启动停止调通了再加顺序启动再加过载保护再加急停。每加一个功能仿真验证一次上机验证一次。这样做虽然慢但出问题时排查范围小。而且每加一个功能你都可以让AI基于已有的、已验证的代码来生成上下文更清晰生成质量更高。7. 从PLC老手到AI编程高手的迁移路径7.1 你已经有的优势状态机和时序思维如果你是从PLC转过来的工程师你在AI编程这件事上其实有天然优势。PLC编程训练出来的两种思维恰恰是AI编程最需要的第一状态机思维。PLC程序本质上是一个状态机——系统在若干状态之间转换每个状态有明确的进入条件、退出条件、输出动作。这种思维迁移到通用软件开发就是状态机建模能力。AI生成代码时如果你能用状态机的语言描述需求生成质量会高很多。第二时序思维。PLC工程师对什么时候发生极其敏感。这种思维迁移到软件开发就是并发和时序问题的敏感度。AI生成的代码在并发场景下的问题PLC工程师往往能比纯软件工程师更早发现。7.2 你需要补的课内存模型和并发PLC工程师转AI编程需要补的主要是两块第一内存模型。PLC的内存是静态分配的变量在编译时就确定了地址。通用软件的内存是动态分配的有堆、栈、垃圾回收。AI生成的代码如果涉及动态内存PLC工程师可能看不出问题。第二并发。PLC是单线程循环扫描天然没有并发问题除了中断程序。通用软件是多线程的有锁、有竞态、有死锁。AI生成的代码在并发场景下的问题需要专门学习才能识别。这两块补起来不难但需要时间。我的建议是先从单线程的、状态机驱动的软件项目入手逐步过渡到并发场景。7.3 反向迁移软件工程师学PLC的捷径反过来如果你是软件工程师想切入PLC你的优势是代码能力和工具使用能力需要补的是硬件思维和工程约束。硬件思维指的是理解IO点位、理解电气图纸、理解传感器和执行器的工作方式。工程约束指的是理解扫描周期、理解故障安全、理解调试窗口的狭窄。我的建议是找一个真实的PLC项目哪怕是小项目比如控制一个传送带从IO接线开始到程序编写到上机调试完整走一遍。走完这一遍你对PLC的理解会比看十本书都深。8. 我个人的几点判断关于AI编程和PLC的关系我有几个可能不太主流但自己比较确信的判断。第一AI编程不会取代PLC工程师但会取代只会写梯形图的PLC工程师。就像PLC没有取代电工但取代了只会接继电器柜的电工。工具在进化使用工具的人也必须进化。第二AI编程在工业场景的落地速度会比互联网场景慢得多。因为工业场景的容错率太低验证成本太高。但这不代表它不会落地只是落地的方式会更保守——先辅助再半自动最后才可能全自动。第三未来PLC工程师的核心竞争力会从写代码转向定义问题。当AI能帮你写代码时你的价值不在于你能写多复杂的梯形图而在于你能把现场需求准确地翻译成AI能理解的规格说明。这个能力本质上就是系统分析和需求建模能力。第四PLC和AI编程的融合会催生新的工具形态。现在已经有一些PLC品牌在尝试把AI集成到编程环境里比如根据自然语言描述生成梯形图、根据IO表自动生成变量声明。这些工具成熟之后PLC编程的门槛会降低但天花板会提高——因为你能做的事情更多了。最后说一个我自己的体会。我用AI编程助手大概一年半了最大的收获不是写代码更快了而是我能做以前做不了的项目了。以前接一个项目我要评估自己的技术栈能不能覆盖现在接项目我会评估这个需求我能不能描述清楚。描述清楚了AI就能帮我补上技术栈的缺口。这个转变和当年从继电器转PLC的老工程师体会到的应该是一样的——工具变了但工程判断力永远是核心。