1. 从一条产线改造的吐槽说起
上个月帮一个做非标自动化的老朋友看项目，他接了个小活儿：给一条老旧的包装线做电控升级。原来的方案是西门子S7-200 SMART加触摸屏，程序是前几年外包写的，梯形图里全是M点、T定时器堆出来的顺启逆停逻辑，注释写得跟天书一样。他本来想直接改改就用，结果甲方临时加了个需求——把原来手动调节的PID温控改成自动整定，还要把运行数据传到上位机做简单报表。
他跟我吐槽的原话是：“这活儿不难，但烦。改梯形图我得一行行捋，捋完还得在博途里重新组态，下载的时候又提示保护机密PLC组态数据的密码出错，折腾一下午。”
我问他：“你没试试让AI帮你把这段逻辑翻译成结构化文本，或者直接生成一版新的PID控制块？”
他愣了一下：“AI还能干这个？”
这个反应其实很典型。现在做PLC这行的工程师，大部分人对AI编程的认知还停留在“写Python脚本”“生成网页前端”这个层面，很少有人意识到，AI编程工具正在以一种非常熟悉的方式，渗透进工业控制领域。而更有意思的是，如果你把AI编程这几年的演进路径摊开来看，会发现它和PLC这几十年的发展轨迹，像得让人有点恍惚。
这篇东西不打算讲什么“AI将取代PLC工程师”这种标题党结论。我想聊的是：为什么说AI编程正在重走PLC的路？这条路具体是怎么走的？对于每天跟梯形图、SCL、ST语言打交道的从业者来说，这件事意味着什么？以及最实际的——你现在能用AI编程工具做哪些PLC相关的活儿，怎么用，坑在哪里。
2. 两条时间线的诡异重合
2.1 PLC当年解决的“编程门槛”问题
要理解AI编程和PLC的相似性，得先回到PLC诞生的那个年代。上世纪六十年代末，美国汽车工业面临一个很现实的问题：每次改车型，继电器控制柜就得重新接线，几千个继电器、几万根线，改一次停产好几周。后来通用汽车提出需求，想要一种“可编程”的控制器，用软件逻辑替代硬件接线。Modicon做出了第一台PLC，核心思路就是用梯形图这种电工看得懂的符号，把继电器逻辑“画”出来，而不是“接”出来。
这个思路的关键在于：它没有要求电工去学汇编语言或者C语言，而是用他们本来就熟悉的继电器符号体系，降低了编程门槛。你不需要知道CPU怎么执行指令，只需要知道“常开触点闭合、线圈得电”这套逻辑，就能写出控制程序。这就是PLC能普及的根本原因——它把编程这件事，封装成了目标用户能理解的形式。
2.2 AI编程正在复刻同一条路径
再看AI编程这几年的发展。最早的代码生成工具，比如早期的Copilot，本质上是个“高级自动补全”，你得懂函数签名、懂语法，它才能帮你补全。这就像早期的PLC，虽然叫“可编程”，但你还是得懂逻辑。
但到了Cursor、Windsurf、Trae这一代工具，情况变了。你可以直接用自然语言描述需求：“帮我写一个Modbus RTU轮询程序，读取三个从站的保持寄存器，地址分别是40001、40003、40005，超时重试三次。”它直接给你生成可运行的代码。你不需要记住Modbus功能码03的具体报文格式，也不需要手算CRC校验，只需要把需求说清楚。
这和PLC梯形图的逻辑一模一样：把底层实现封装起来，让用户用自己熟悉的语言（电工用梯形图，程序员用自然语言）去描述控制逻辑。AI编程工具现在做的，就是把“编程”这件事的门槛，从“会写代码”降到“会描述需求”。
2.3 一个关键差异：PLC是封闭的，AI编程是开放的
但两者有一个本质区别，这个区别决定了AI编程不会简单重复PLC的老路。PLC从诞生之初就是软硬件一体的封闭系统，西门子的程序只能在西门子的PLC上跑，三菱的梯形图换到汇川上得重写。这种封闭性保证了稳定性，但也限制了灵活性。
AI编程工具是开放的。它不绑定特定硬件，生成的是通用代码或者符合某种标准的文本。你可以让AI生成一段SCL代码，然后手动适配到西门子、倍福或者CODESYS平台上。这种开放性意味着AI编程的渗透速度会比PLC快得多，因为它不需要重建一套硬件生态，只需要对接现有的编程环境。
3. 当AI开始“看懂”梯形图
3.1 从代码生成到逻辑理解
现在市面上大部分AI编程工具，对PLC的支持还停留在“生成代码片段”的阶段。比如你问Cursor“写一个三菱FX系列的点动控制梯形图”，它可能会给你一段指令表或者结构化文本，但格式不一定对，M点地址也不一定符合你的项目规范。
但真正有意思的方向是“逻辑理解”。我试过把一段老项目的梯形图截图丢给支持视觉的AI工具，让它解释这段逻辑在干什么。它能把常开常闭、定时器、计数器的关系捋清楚，用自然语言描述出来：“当X0闭合且X1断开时，Y0得电并自锁；T0计时5秒后，Y1输出。”这个能力对于维护老设备、交接项目来说，价值非常大。
更进一步，你可以让它做逻辑转换。比如把一段梯形图逻辑转换成SCL结构化文本，或者反过来。我实测下来，对于中等复杂度的顺启逆停、星三角启动、PID控制这类逻辑，AI的转换准确率已经相当可观。当然，前提是你得把逻辑描述清楚，不能指望它看一眼模糊的截图就全对。
3.2 为什么这件事对PLC工程师很重要
PLC工程师的日常工作里，有相当一部分时间花在“读别人的程序”上。特别是做非标项目的，经常要接手前任工程师留下的代码，注释不全、变量命名随意、逻辑绕来绕去。以前你得一行行捋，现在可以让AI先帮你生成一份逻辑说明，你再对照着看，效率提升很明显。
还有一个场景是跨平台移植。比如客户原来用的是台达PLC，现在要换成汇川，逻辑不变但指令系统不一样。以前得手动重写，现在可以把原程序的关键逻辑提取出来，让AI生成目标平台的代码框架，你再做适配。虽然不能全自动，但能省掉大量重复劳动。
3.3 当前能力的边界在哪里
得说清楚，AI现在对PLC程序的理解还远没到“万能”的程度。我总结了几条边界：
- 对非标准逻辑的处理能力有限：如果程序里用了大量自定义功能块、间接寻址、复杂指针操作，AI很容易懵。它擅长的是标准逻辑结构，比如启停、互锁、定时、计数、PID这些。
- 对硬件相关细节不敏感：比如某个型号PLC的高速计数器怎么配置、模拟量模块的量程怎么标定，这些跟具体硬件强相关的细节，AI给的建议往往需要你对照手册核实。
- 对安全逻辑的可靠性存疑：安全PLC程序涉及安全等级认证，目前不建议让AI直接生成安全相关逻辑，还是得按标准流程来。
提示：用AI辅助PLC编程时，把它当成一个“很懂逻辑但不太懂你现场设备”的助手。逻辑框架可以让它搭，硬件细节必须自己把关。
4. 提示词工程在PLC场景下的特殊玩法
4.1 为什么通用提示词不好使
现在网上讲AI编程提示词的内容很多，但大部分是针对Web开发、Python脚本的。你直接套用到PLC场景，效果往往不理想。原因很简单：PLC编程有自己的一套术语体系和约束条件，通用提示词没有覆盖这些。
比如你说“写一个电机控制程序”，AI可能给你生成一段Arduino代码。但如果你说“写一个基于西门子S7-1200的电机星三角启动程序，使用SCL语言，包含过载保护和启动延时”，它就能给出更贴近需求的结果。关键词的精确度，直接决定输出质量。
4.2 我常用的PLC提示词结构
经过一段时间的摸索，我总结了一个比较稳定的提示词框架，分四层：
第一层：平台与语言。明确告诉AI你用的是什么平台、什么语言。比如“西门子TIA Portal V17，SCL语言”或者“三菱GX Works2，梯形图指令表”。这一层决定了输出的语法格式。
第二层：控制需求。用工程语言描述控制逻辑，包括输入输出条件、时序关系、互锁要求。比如“按下启动按钮I0.0，主电机Q0.0得电；3秒后风机Q0.1启动；按下停止按钮I0.1，风机先停，4秒后主电机停”。这种描述方式AI理解起来很顺。
第三层：约束条件。包括变量命名规范、地址分配范围、需要使用的特定指令等。比如“M点从M10.0开始分配，定时器使用TON，不要用TONR”。
第四层：输出格式。明确你要的是代码、逻辑说明还是变量表。比如“输出SCL代码，并在注释中说明每个变量的作用”。
这个框架不是死的，但核心思路是：把AI当成一个刚入职的助理工程师，你得把需求交代清楚，它才能干对活。
4.3 几个实测有效的提示词示例
下面这几个是我在实际项目中用过、效果比较稳的提示词，直接给出来供参考：
平台：CODESYS V3.5，ST语言 需求：实现一个PID温度控制功能块，输入为实际温度、设定温度，输出为加热器PWM占空比。采样周期100ms，PID参数可在线修改。 约束：使用CODESYS标准PID库，变量命名以fbTemp开头，输出限幅0-100。 输出：ST代码，附带参数说明。平台：西门子S7-200 SMART，梯形图 需求：将以下梯形图逻辑转换为SCL结构化文本，保持逻辑等价。 逻辑描述：I0.0启动，Q0.0自锁；T37计时10秒后Q0.1输出；I0.1停止时全部复位。 输出：SCL代码，变量地址与原梯形图一致。平台：通用PLC逻辑 需求：解释以下梯形图程序的逻辑功能，用自然语言描述每一步的作用。 程序内容：[粘贴指令表或逻辑描述] 输出：分步骤的逻辑说明，指出潜在问题。这几个提示词的共同点是：平台明确、需求具体、约束清晰、输出格式指定。你如果只是笼统地问“帮我写个PLC程序”，得到的结果大概率不能用。
5. 实测：用AI工具处理一个真实的PLC改造需求
5.1 需求背景与拆解
回到开头提到的那个包装线改造项目。具体需求是这样的：
- 原有系统：西门子S7-200 SMART + 触摸屏，控制一条输送带、两个气缸、一个加热封口机构。
- 改造需求一：加热封口温度从手动电位器调节改为PID自动控制，热电偶输入，固态继电器输出。
- 改造需求二：增加运行数据记录功能，每5分钟记录一次温度值，通过RS485上传到上位机。
- 改造需求三：保留原有手动模式，增加自动/手动切换。
这个需求不算复杂，但涉及模拟量处理、PID、通讯、模式切换几个模块，手动写下来也得大半天。我决定用AI辅助来做，看看能省多少事。
5.2 用AI生成PID控制逻辑
第一步是PID控制块。S7-200 SMART本身有PID指令，但参数整定和模式切换的逻辑需要自己写。我把需求整理成提示词：
平台：西门子S7-200 SMART，梯形图/SCL混合 需求：实现加热封口温度PID控制。 - 热电偶输入经EM AT04模块，通道0，4-20mA信号，量程0-400度。 - 输出经EM AQ04模块，通道0，4-20mA信号，控制固态继电器。 - 设定温度通过触摸屏写入VD100，实际温度存在VD104。 - PID参数：比例增益VD200，积分时间VD204，微分时间VD208。 - 需要自动/手动无扰切换，手动时输出值由触摸屏直接给定。 输出：SCL代码，包含模拟量标定和PID调用。AI给出的代码框架基本可用，模拟量标定部分它用了标准的线性转换公式，PID调用也正确引用了S7-200 SMART的PID指令。但有几个地方需要手动调整：一是它默认用了0-32000的原始值范围，实际EM AT04模块的原始值范围需要查手册确认；二是手动/自动切换的无扰处理，它给的逻辑不够严谨，我后来参考了西门子官方文档里的标准做法。
这个环节的体会是：AI能帮你搭出80%的框架，但剩下20%跟具体硬件相关的细节，必须自己补。不过就算这样，也比从零开始写快了很多。
5.3 数据记录与通讯部分的处理
数据记录和RS485通讯这部分，我让AI生成了一个简单的循环记录逻辑：用定时器每5分钟触发一次，把当前温度值存入一个数据块，数据块采用先进先出方式覆盖旧数据。通讯部分用的是Modbus RTU从站模式，上位机做主站轮询。
AI生成的Modbus从站配置代码基本正确，包括波特率、数据位、停止位、校验方式的设置。但有一个坑：S7-200 SMART的Modbus从站指令需要指定保持寄存器的起始地址和数量，AI给的地址范围跟我实际分配的不一致，需要手动改。
还有一个细节：数据记录的时间戳。AI建议用PLC内部时钟，但S7-200 SMART的时钟需要额外配置电池卡才能保持，否则断电后时间会丢失。这个细节AI没有主动提醒，是我后来自己想到的。所以用AI辅助的时候，你得有足够的工程经验去判断它给的建议是否完整。
5.4 自动/手动切换逻辑的坑
自动/手动切换这个需求看起来简单，实际上有个容易忽略的点：切换瞬间的输出扰动。如果手动时输出是50%，切到自动时PID输出从0开始积分，加热器会突然掉电再慢慢升上来，温度波动会很大。
我让AI处理这个问题，它给出的方案是用PID指令的“手动/自动”输入引脚，在手动模式下把手动值直接赋给输出。这个思路是对的，但具体实现时，S7-200 SMART的PID指令手册里有一个“无扰切换”的说明，需要在切换前把积分项预置为当前输出值。AI没有主动提到这一点，我是在调试时发现温度波动异常，回头查手册才找到原因。
这个坑让我意识到：AI对PLC指令的理解是基于通用知识的，但每个品牌、每个型号的指令都有自己特殊的参数和行为。这些细节，AI不一定知道，或者知道了也不一定主动告诉你。
6. 不同AI编程工具在PLC场景下的实际表现
6.1 Cursor：代码生成强，但需要喂上下文
Cursor是我用得最多的工具。它的优势在于代码生成质量高，特别是SCL和ST这类结构化文本，语法错误很少。而且它支持多文件上下文，你可以把整个项目的变量表、功能块结构都喂给它，让它生成风格一致的代码。
但在PLC场景下，Cursor有个明显短板：它对工业控制领域的专有概念理解不够深。比如你提到“安全扭矩关断”“冗余配置”“等时同步模式”这些概念，它给出的代码往往流于表面，需要你大量修正。另外Cursor默认的代码风格偏Web开发，变量命名习惯跟PLC工程师不太一样，需要花时间调教。
6.2 VS Code Copilot：补全顺手，但全局逻辑弱
Copilot的优势是跟VS Code深度集成，写代码时的行级补全非常顺手。如果你在写SCL或者ST代码，它能根据上下文自动补全函数名、变量名，减少打字量。
但Copilot对全局逻辑的把握比较弱。它更擅长“你写一行，它补下一行”，而不是“你描述需求，它生成整个功能块”。对于PLC编程这种强调整体逻辑结构的场景，Copilot更适合做辅助输入，而不是主力生成工具。
6.3 Trae和Windsurf：各有侧重
Trae在国内的访问体验比较好，对中文提示词的理解也更自然。我试过用中文描述PLC控制需求，Trae生成的代码注释也是中文的，对于国内项目来说比较友好。但它的代码生成质量跟Cursor比还有差距，复杂逻辑容易出错。
Windsurf的亮点是它的“流式编辑”模式，你可以一边跟它对话一边修改代码，交互体验很流畅。但在PLC场景下，它的领域知识储备似乎不如Cursor，生成的代码需要更多人工修正。
6.4 一个实用的组合策略
我现在的做法是：用Cursor做主力生成，用Copilot做行级补全，用Trae做中文需求理解和注释生成。具体流程是：
- 在Trae里用中文把需求描述清楚，让它生成一版逻辑框架和中文注释。
- 把框架复制到Cursor里，用英文提示词让它优化代码结构和变量命名。
- 在VS Code里用Copilot做最后的代码补全和细节调整。
这个组合不是固定的，但核心思路是：不同工具各有所长，别指望一个工具解决所有问题。
7. 从“写代码”到“描述逻辑”：PLC工程师的技能迁移
7.1 哪些技能在贬值，哪些在升值
AI编程工具普及之后，PLC工程师的技能价值正在发生迁移。先说贬值的部分：
- 纯语法记忆：以前你得记住西门子的TON指令有几个参数、三菱的MOV指令怎么写，现在AI都能帮你生成，死记硬背的价值在降低。
- 重复性代码编写：标准的启停、互锁、定时逻辑，AI生成得又快又准，手动写的优势不明显了。
- 单一平台经验：如果你只会一个品牌的PLC，AI可以帮你快速迁移到其他平台，平台壁垒在降低。
再说升值的部分：
- 需求分析与逻辑抽象：能把现场控制需求拆解成清晰的逻辑描述，这个能力越来越重要。AI再强，也得你告诉它要干什么。
- 硬件与工艺理解：知道热电偶怎么接线、阀门响应时间多少、气缸动作时序怎么配合，这些现场经验AI替代不了。
- 调试与排错能力：AI生成的代码不一定对，出了问题你得能快速定位。调试经验的价值在上升。
- 跨领域整合能力：PLC加AI加通讯加上位机，能把不同技术串起来解决实际问题的人，会越来越吃香。
7.2 一个现实建议：把AI当成“翻译器”
我自己的体会是，AI编程工具对PLC工程师最大的价值，不是“替你写代码”，而是“帮你翻译”。翻译什么？翻译不同平台之间的逻辑，翻译自然语言和代码之间的表达，翻译老程序和新需求之间的差距。
比如你接手了一个三菱PLC的老项目，想把它移植到汇川平台上。以前你得逐行读三菱的指令表，理解逻辑后再用汇川的指令重写。现在你可以让AI先帮你把三菱程序翻译成逻辑描述，再根据逻辑描述生成汇川代码框架。虽然中间还需要人工校验，但效率提升是实实在在的。
再比如你跟客户沟通需求，客户说的是“封口温度要稳，不能忽高忽低”，你得把它翻译成“PID控制，采样周期100ms，超调量小于5%”。这个翻译过程，AI也能帮上忙——你把客户的原话输进去，让它给出技术方案建议，虽然不一定全对，但能给你提供思路。
7.3 别把AI当对手，把它当实习生
我见过一些同行对AI编程工具的态度比较极端，要么觉得“这玩意儿不靠谱，PLC还得手写”，要么觉得“AI要取代PLC工程师了”。这两种态度都没必要。
比较健康的心态是：把AI当成一个刚入职的实习生。它懂编程语法，逻辑能力也不错，但对你的现场设备、工艺要求、项目规范一无所知。你得带它、教它、检查它的工作。它干得快，但容易出错；它能帮你省时间，但不能替你负责。
这个定位想清楚了，用AI辅助PLC编程就顺了。
8. 现阶段的局限与下一步可能的方向
8.1 别指望AI直接生成可下载的程序
目前AI生成的PLC代码，离“直接下载到PLC就能跑”还有距离。主要卡在几个地方：
- 硬件组态信息缺失：AI不知道你的PLC型号、模块配置、通讯参数，这些需要在编程软件里手动组态。
- 变量地址分配：AI生成的变量地址往往是示意性的，需要你根据实际IO表重新分配。
- 编译环境差异：不同版本的编程软件对语法要求不同，AI生成的代码可能需要调整才能通过编译。
所以现阶段比较现实的用法是：AI生成逻辑框架和代码片段，你在编程软件里手动组态、分配地址、编译调试。
8.2 一个值得关注的方向：AI辅助PLC程序审查
比起生成代码，我觉得AI在程序审查方面的价值可能更大。PLC程序里有很多“隐性规则”，比如互锁逻辑是否完备、急停回路是否独立、模拟量滤波是否合理。这些规则有经验的工程师一眼能看出来，但新手容易忽略。
如果能把AI训练成“程序审查助手”，让它按照安全规范、行业惯例、项目标准去检查PLC程序，指出潜在问题，这个价值可能比代码生成更大。我试过让AI审查一段梯形图逻辑，它能指出“急停按钮使用常闭触点更安全”“互锁逻辑缺少延时确认”这类问题，虽然不够全面，但方向是对的。
8.3 对从业者的长期影响
往长了看，AI编程对PLC行业的影响可能比对Web开发更深远。因为PLC工程师的准入门槛本来就不低——你得懂电气、懂工艺、懂编程，还得有现场经验。AI降低了编程这一环的门槛，意味着未来可能有更多“懂工艺但不太会编程”的人进入这个领域。
这对行业是好事还是坏事，现在不好说。但有一点是确定的：只会写梯形图、不懂工艺、不会调试的PLC工程师，日子会越来越难过。而能把工艺需求翻译成控制逻辑、能用AI工具快速实现、能现场调试排错的人，价值会更高。
9. 我个人的几条实操建议
最后分享几条我自己用AI辅助PLC编程的实操建议，都是踩过坑之后总结的：
第一条：永远不要直接使用AI生成的代码，哪怕它看起来很完美。我吃过亏，一段AI生成的PID逻辑，语法没问题，逻辑也通，但参数单位搞错了，实际运行时温度直接冲过头。后来我养成了习惯：AI生成的每一行代码，都要对照手册核实一遍。
第二条：把AI当成“第二意见”，而不是“第一方案”。遇到问题先自己想解决方案，想好了再问AI，看看它有没有更好的思路。这样既能保持自己的判断力，又能从AI那里获得补充。
第三条：积累自己的提示词库。我建了一个文档，把每次用得好用的提示词记下来，按场景分类：PID控制、通讯配置、逻辑转换、程序审查。下次遇到类似需求，直接改改就能用，效率很高。
第四条：重要项目的关键逻辑，手写一遍再让AI优化。手写的过程是理清思路的过程，写完了再让AI帮你优化结构、补充注释、检查边界条件。这样出来的代码，你心里有底。
第五条：保持对现场设备的敬畏。AI再聪明，它没闻过烧焦的线缆味，没听过气缸漏气的声音，没感受过急停按钮按下去那一刻的心跳。现场经验是PLC工程师的护城河，别因为有了AI就把它丢了。
这个领域变化很快，但底层逻辑没变：把控制需求变成可靠的程序，让设备稳定运行。AI是个好工具，但工具永远替代不了使用工具的人。