企业官网建设流程全解析

干PLC这行的这些年，我写过的梯形图估计能堆满一个文件柜，但真正遇到配方管理、运动控制、数据处理这些复杂需求时，还是会老老实实切到ST（结构化文本）。今年开始，我试着用AI把需求直接变成完整ST程序，又顺手搭了一套基于agent的生成、编译、反馈闭环，跑了两个项目，确实省了不少时间，也踩了不少坑。这篇文章就把我摸索出来的这套玩法整理出来，适合想用AI提高PLC编程效率的电气工程师、自动化运维，也适合刚接触ST语言的新人。

1. 为什么PLC编程需要AI这条新路子

1.1 梯形图到结构化文本，痛点究竟在哪

梯形图确实是PLC编程的“母语”，电气工程师看着继电器电路就能上手，排查故障时一眼看到通断状态，这个优势到现在都无法替代。但设备越来越复杂，你总会在某个时间点遇到梯形图很难写清的逻辑：上百条配方要按表切换、温度PID参数需要在线自整定、Modbus报文要拆字节还要做CRC校验，或者一个状态机有十几个互锁条件。用梯形图写这些，网络会铺得特别长，改一个条件可能牵扯七八个网络。

ST语言本质上是PLC世界里的高级语言，语法和Pascal、C有点像，能用IF、CASE、FOR这些结构把复杂逻辑写得像一份清晰说明书。缺点也明显：没有梯形图那种可视化通断，新人需要一段时间适应变量、作用域、函数块这些抽象概念。我接触过不少老师傅，梯图画得很溜，一看ST就头疼，原因不是学不会，而是没有足够的实践场景去练。AI恰好补上了这个缺口——它能在你描述需求之后，立刻给出一份结构完整的ST代码，相当于凭空多了一个随时待命的“编程搭子”。

1.2 agent和普通AI问答的关键差别

早期用AI写程序，最多的操作就是复制粘贴：在对话框里说“帮我写一个PID功能块”，拿到代码往PLC软件里一贴，编译报错再复制回来，让它改，再贴回去。来回三五次，人都麻了。后来我意识到这里缺的不是AI写代码的能力，而是把“写完—编译—报错—修改”这个循环自动化的能力，这正是agent的思路。

agent和普通AI问答的最大区别，是它不是一个只会回答的单点工具，而是一个能拆解目标、调用工具、观察结果并修正行为的执行系统。打个比方，普通AI像打字很快的文员，你让它写一段话，它写完交差；agent像一个会看反馈改稿的编辑，它写完之后会拿着编译器的报错信息回来，判断错在哪，自己改掉再提交。你要做的，只是把最终结果再审一遍。

我建议的思路是：用大模型做推理核心，用脚本或工具把“提示词生成、ST代码落盘、调用编译器或语法检查、收集报错内容、回传给模型”串起来。这个闭环跑通之后，整个流程就变成你下需求，agent自动完成多轮迭代，最后交给你一份已经通过语法检查的ST文件。项目忙的时候，这种方法能把“写代码—改bug”的时间压缩到原来的三分之一左右。如果不想搭完整工具链，手动按照这个闭环来操作，也同样有效，只是人肉多跑几趟而已。

1.3 哪些场景用AI写ST收益最大

我最推荐AI写ST的场景有这么几类：第一，算法密集型逻辑，比如PID变体、模糊控制、数据滤波、坐标变换，AI对标准算法的掌握比大多数人牢靠；第二，批量重复代码，比如十几个结构相同的模拟量处理块，让AI照着模板批量生成，再用查找替换微调；第三，跨平台移植，把一个老项目的梯形图逻辑描述成文字，让AI改写成CODESYS或博途SCL，工作量能省一大截；第四，配方和数组数据处理，这种代码全是循环和索引，手写容易漏边界条件。

但有个反向场景我劝你别用AI——简单的启保停电路、点动控制、按钮互锁这类逻辑，梯形图二十秒就能画完，用AI反而要把需求反复描述清楚，最后还要检查，纯属浪费时间。AI适合的是“写起来费劲、查起来费时”的中大型代码，不是所有PLC程序。

确定场景之后，第二步不是直接打开聊天窗口，而是把ST语言基本功和AI的能力边界先摸清楚，否则AI给的东西你连怎么审查都不知道。

2. ST语言基本功与AI助手的边界

2.1 想用好AI，先把ST这些语法扎牢

你要让AI帮你写ST，自己至少得能看懂ST。不需要达到手写大师水平，但核心语法必须过一遍。ST里最常见的就是赋值表达式、IF/CASE分支、FOR/WHILE循环，还有功能块FB和函数FUNCTION的区别。比如一个电机启保停逻辑，用ST一句话就能写清楚：

bRun := (bRun OR bStart) AND NOT bStop AND NOT bFault;

这句代码的意思是：只要没有停止信号、没有故障，只要启动信号为真或者当前已经在运行，输出就保持为真。梯形图要用三个网络表达的逻辑，ST一行搞定。稍微复杂一点，用一个FB（函数块）可以描述整个设备的状态，我常强调新人必须理解一件事：FB声明后要先实例化才能调用，就像图纸设计完，要在现场“安装一台”才能运转。

AI常见的工作方式，是生成一个带VAR_INPUT、VAR_OUTPUT、VAR内部变量的FUNCTION_BLOCK。如果你不理解这些声明的作用，就不清楚为什么程序里能直接用bStart，也不知道bSensorA这些变量的值从哪来。审查AI代码的第一步，就是对照接口声明看有没有漏变量、有没有类型不匹配。时间字面量也值得注意，T#5S在ST里表示5秒，AI偶尔会写成TIME#5S或直接写5，不同平台兼容性不一样。

2.2 AI能写什么，不能写什么

我把AI在ST编程上的能力边界划得很清楚。能写的部分包括：标准算法、数据处理与转换、状态机框架、批量模板生成、注释和文档、代码风格统一、现有代码的解释与重构。这些都是“信息完整、规则明确”的活，模型从训练数据中学过大量相似代码，生成质量通常不差。

不能做的部分更关键：AI不知道你现场传感器怎么接的，不知道设备有没有机械互锁，不知道某个品牌的PLC在处理浮点数时是不是需要特殊设置，更不知道你的安全急停回路有没有硬接线。它给出的Modbus寄存器地址可能是别的型号的，它写的数组边界可能跟你PLC的寻址方式不一致，甚至会把供应商库函数的名字写错。这些都只能由有工程经验的人兜底。

所以我对AI生成代码的态度就六个字：可用，但必须审。AI是快马，不是导航。你要驾驭它，就得自己先知道路往哪走。

2.3 搭建一个称手的PLC agent工作台

想真正把“PLC agent”落地，需要一个最小的工作环境。硬件方面，一个支持ST的PLC开发环境就行，最常见的是CODESYS、西门子博途的SCL、汇川InProShop、信捷XD系列等；没有实体PLC就装仿真器，CODESYS自带软PLC仿真，博途也有PLCSIM。模型方面，不要迷信最贵的模型，选一个能处理长文本、输出代码稳定的大模型即可，再准备一个能保存ST文件的工作目录。

搭agent闭环时，我实测下来最省事的流程是：先写一个需求模板，每次把控制描述填进去，生成提示词；然后让模型输出完整ST代码到文本文件；接着用PLC软件的库或者自己写的小脚本检查语法和变量声明；把检查结果反馈给模型修改。这个过程里最重要的是“可重复”——同一个需求换参数生成，逻辑骨架不变，这样审查压力会小很多。

这里还经常遇到一个入门问题：PLC软件连不上控制器。以CODESYS为例，默认网关端口一般是11740，如果现场改过端口，就得在Device设置里改成一致；多台PLC在同一个网段时，建议先通过MAC地址确认到底连的是哪一台，别对着A设备下载了B设备的程序。博途连接不上时，多数是PG/PC接口和网卡选错；模拟屏不显示数据，也先查驱动版本和PN/DP地址。这些环境和通信问题虽然和AI无关，但往往是卡住整个流程的绊脚石。

3. 实操：从需求到ST程序的完整流程

3.1 需求拆解：先写一份“控制说明书”

真正开始让AI写程序之前，我会花十几分钟把需求写成一张表。这一步看起来繁琐，但它决定了AI生成代码的上限。你给AI的接口越清楚，它写的代码就越接近能用。一张标准的控制需求表包括四个部分：控制对象和工艺流程、输入信号、输出信号、逻辑约束。

以我最近调的一个三工位气缸顺序控制为例：

这张表一出来，控制任务就被翻译成了计算机能理解的语言。写程序的人（或AI）不需要去现场看设备，也清楚知道有哪些变量、有什么约束。这也正是AI最喜欢的输入方式——信息完整、边界明确、规则简洁。

3.2 提示词模板：把控制逻辑翻译给AI

有了需求表，接下来就是写提示词。很多初学者直接把“写个三工位气缸程序”丢给AI，得到的代码多半没法直接用，因为AI不知道用什么平台、什么变量名、什么逻辑约束。我的提示词模板一般长这样：

你是一名精通IEC 61131-3结构化文本的PLC工程师。 请用ST语言编写一个功能块，用于三工位气缸顺序控制。 平台：CODESYS 3.5，程序组织单元：FUNCTION_BLOCK。 接口定义： 输入：bManual、bAuto、bReset、bStart、bEmergencyStop， 以及三个到位传感器bSensorA、bSensorB、bSensorC。 输出：三个电磁阀bValveA、bValveB、bValveC，报警bAlarm。 逻辑要求： 1. 自动模式下按 A→B→C 顺序动作，前一步到位后才能执行下一步。 2. 手动模式下每个输出可独立控制（外部按钮点动）。 3. 任一步动作超过5秒未到位，置位bAlarm并停止后续动作。 4. 急停有效时所有输出为FALSE。 5. 使用CASE语句描述状态机，代码注释完整。 请直接输出完整ST代码，并在代码上方列出关键变量说明。

这模板里有几个关键词：角色设定（PLC工程师）、平台版本（CODESYS 3.5）、程序组织单元（FUNCTION_BLOCK）、接口定义、逻辑要求、输出格式。每一条都是在降低AI生成“废话”或“不确定代码”的概率。实测下来，包含平台版本这一点特别重要，因为ST在不同IDE里的语法有细微差异，明确告诉它之后，函数块调用、时间字面量这些地方出错的概率会小很多。

3.3 代码生成与人工审查要点

模型给出代码后，我第一遍不会看实现细节，而是先扫结构。拿上面气缸程序来说，AI通常会生成类似下面这种骨架：

FUNCTION_BLOCK FB_CylinderSeq VAR_INPUT bManual : BOOL; bAuto : BOOL; bReset : BOOL; bStart : BOOL; bEmergency : BOOL; bSensorA : BOOL; bSensorB : BOOL; bSensorC : BOOL; END_VAR VAR_OUTPUT bValveA : BOOL; bValveB : BOOL; bValveC : BOOL; bAlarm : BOOL; END_VAR VAR eState : USINT; // 0=待机 1=A动作 2=B动作 3=C动作 fbTimer : TON; // 超时定时器实例 END_VAR

这时候我重点检查三件事：一是所有IO信号是否都声明了，有没有多出来或漏掉的；二是内部变量是否够用，尤其是定时器这类FB有没有实例化；三是平台兼容性，比如USINT在CODESYS里没问题，但换到某些国产PLC环境可能要改成BYTE。

再看逻辑实现部分，AI生成的CASE状态机一般不会出大问题，但超时检测经常写错位置。正确做法是让定时器在非待机状态一直计时，每次状态切换时重置；如果AI把定时器只放在一个状态里，就会导致其他状态超时失效。这种问题不是AI语法错误，而是控制逻辑层面的错，必须有经验的人来把关。审查通过之后，才算进入导入阶段。

3.4 导入PLC与仿真调试步骤

导入这一步，不同软件的路径不一样，但思路一致。以CODESYS为例：在工程树里右键应用，选择添加对象，新建一个POU，类型选FUNCTION_BLOCK，把AI生成的代码粘进去。然后在主程序PLC_PRG里声明一个该FB的实例，比如：

VAR fbCylinder : FB_CylinderSeq; END_VAR

在循环中调用：

fbCylinder(bManual := ..., bAuto := ..., ...);

之后把FB的输入输出变量关联到真实IO，或者先不关联，用仿真模式测试。CODESYS的仿真器可以在不连PLC的情况下直接运行，手动给变量强制赋值，就能观察状态机的跳转。我调试三工位气缸时，就是逐个置位传感器，确认每个阀门按预期打开关闭，再测试超时报警。这一步做完，才敢说这段AI生成的ST“被我验证过”。

3.5 完整案例：三工位气缸顺序控制

上面整个流程串起来，就是一个完整案例。从需求表到提示词，再到AI生成FB_CylinderSeq、人工审查、仿真验证，前后大约一个小时。我统计过，同样逻辑用梯形图写，先画IO分配再铺网络，至少半天，而且后续复用性差。换成ST的FB之后，下一次做一个四工位版本，只要把状态枚举增加一个，提示词里改个数，AI几秒钟就能生成新版本。

当然，从生成到能用之间还有一道不可省略的工序，就是编译和仿真时的报错处理。这也是我把agent闭环加进来的原因——让AI自己看报错自己改，比人工来回复制粘贴高效太多。报错信息通常已经指明了行号和原因，模型基于这些反馈再生成修复后的代码，迭代三轮以内基本就能通过语法检查。

4. 常见问题与排查技巧实录

4.1 AI生成ST代码最常见的五种坑

我在这两个月里让AI生成了一百多段ST代码，踩过的坑基本可以归纳成五类。

第一，变量声明不一致。AI会在声明区写bSensorA，在逻辑代码里写成bSensorA_1，或者大小写对不上，编译直接报“变量未定义”。原因多是模型在长文本输出时记忆漂移。审查函数块时，先做一次变量名对比，或者用IDE的自动声明功能补全。

第二，定时器和函数块没有实例化。新手最容易遇到的就是直接写TON(IN := ..., PT := ...)，但TON必须先在VAR区声明实例才能用。正确写法是先VAR fbTimer : TON; END_VAR，再调用fbTimer(IN := ..., PT := ...)。

第三，数组边界和索引差异。AI习惯C语言风格的0起始下标，但不少PLC的数组定义和访问习惯有差异，有些环境还允许从任意下标开始。这类问题编译阶段不一定报错，运行起来才越界，危害更大。

第四，平台特有语法串味。CODESYS的ST和博途SCL大体相同，但细节不同，比如数组初始化、地址表示、时间字面量。AI如果没被告知平台，会默认用最通用的写法，结果在自己的IDE里编译不过。所以提示词里写清平台版本，比事后改代码更省事。

第五，安全逻辑位置错误。AI会把急停、复位放在程序最后，或者让普通逻辑覆盖它。审查时必须要求安全类信号在最前面、优先级最高，后续所有分支都不能绕过。这条没有任何商量余地。

4.2 现场通信、固件与版本兼容问题

搞PLC的老手都清楚，很多时候程序本身没问题，卡住的却是通信和版本。连接不上PLC时，先查三件事：IP地址和网段通不通、端口号对不对、目标设备是不是你想象中那一台。多台PLC通过网口组网时，我习惯先把每台设备的MAC地址记录下来，查询时用MAC和IP双重确认，避免下错程序。CODESYS默认端口是11740，有些现场会改成别的值，改完之后两端必须一致；InProShop和信捷软件也有各自的端口设置，在设备连接配置里核对即可。

固件升级也是现场高频故障点。我遇到过工具软件升级PLC固件时提示“拉取固件包列表网络请求失败”，折腾半天发现不是设备问题，而是本机网络访问不了软件服务器。解决办法很简单，去官网下载对应版本的固件包，用离线方式更新，绕开在线拉取。还有模拟屏不显示数据，多数不是AI生成程序的问题，而是驱动版本、通信参数和PLC侧不一致，逐一核对就能定位。

4.3 安全冗余：AI写的程序能不能直接上产线

这个问题我被问过很多次。我的回答很直接：AI生成的ST程序，永远不能直接承担安全功能。急停回路、安全门、光幕这类硬安全，必须用硬接线继电器回路实现，不能指望控制器里的程序逻辑，更不能指望AI生成的代码。AI程序跑在PLC里，只负责常规动作控制，而安全回路要在它“大脑断电”的情况下也能把设备停下来。

验收流程上，我给自己定的规矩有三条：第一，所有AI生成的代码必须经过人工逐段审查，签字确认；第二，先仿真，后空载，再带载，每一步都要有测试记录；第三，关键联锁和超时报警逻辑，单独用测试用例验证，不能只看一遍代码就觉得没问题。严格遵守这三条，AI生成的代码才能作为日常控制逻辑使用。

4.4 问题排查速查表

最后说点我自己的体会。用AI写ST程序这件事，真正值钱的不是生成代码那一刻，而是你逼着自己把设备逻辑讲清楚的过程。以前我遇到复杂工况，脑子里常常是模糊的“大概这么动”，现在为了写提示词，必须把IO表、时序、异常处理都列明白，AI反而成了我整理思路的镜子。对熟手来说，这套PLC agent玩法是实打实的效率加速器；对刚接触ST的新人来说，它又像一个不知疲倦的老师——但记住，老师可以帮你检查作业，能不能毕业，还得看你自己有没有把安全和逻辑的底线守住。