企业官网建设流程全解析

1. 从梯形图到对话栏：一位老PLC工程师的“AI初体验”

干了十年PLC编程，我一直觉得这活儿靠的是经验和手感。画梯形图、排I/O表、调模拟量、盯时序……每一条逻辑都是拿现场设备的“脾气”换来的。所以当身边年轻人开始讨论让AI写PLC程序时，我第一反应是：这玩意儿能看懂我的程序才怪。

结果打脸来得很快。

一次赶项目，客户临时要求在现有产线上加一套自动分拣逻辑。那段时间正好手上压着三个程序的调试，实在抽不出空从零开始写。没办法，我抱着死马当活马医的心态，把需求描述扔进了AI对话窗口，附带一小段我自己写的ST结构化文本作样例。本意是让它“参考格式”，没想到它直接给我生成了一段完整的气缸顺序控制程序，且命名风格和我给的样例高度一致。

我盯着那段代码看了很久，心里冒出一个词：见鬼了。

后来我认真测了一周，把AI拉进了我熟悉的几个真实场景里：三菱FX3U的485BD从站通讯、汇川H5U的轴控代码、欧姆龙NJ的ST块……得出的结论比我想象的更“现实”：AI确实能写PLC程序，但它不是替代你的同事，而是一个“读了十年编程手册、但从来没进过车间”的助手。用得好，效率翻倍；用不好，坑里见。

这篇我就把这段时间实测的体验、踩过的坑、总结出的一套工作方式，原原本本分享给同行。尤其是那些跟我一样，从继电器回路一路画到结构化文本的老工程师——这篇文章就是写给你们的。

2. AI写PLC程序的实测表现：基础逻辑快得惊人，复杂项目仍需“翻译”

2.1 基础逻辑生成：从需求描述到可编译代码

先说最基本的场景：写一段简单的电机启停、报警复位、手自动切换逻辑。这类逻辑在PLC里属于“肌肉记忆级”的活，但恰恰是AI表现最稳定的领域。

我测试时给的提示词是这样的：

请生成一段西门子S7-1200的FB块，使用SCL语言。 功能：电机手动/自动模式切换。 手动模式下，由DI1启动、DI2停止，带互锁。 自动模式下，由上位机DB块中的MOTOR_AUTO_CMD触发启动， MOTOR_AUTO_STOP触发停止。 电机运行状态反馈DO1，故障信号DI3触发后输出报警并停止电机。 需要互锁：故障时无法手动或自动启动。

AI生成的结果让我挺意外。首先，变量命名是规范的（MOTOR_START_CMD、MOTOR_STOP_CMD、MOTOR_FAULT这种风格），其次它自动加了故障保持逻辑——手动模式下故障复位前不允许重新启动，这个细节很多刚入行的人都会漏掉。代码编译一次通过，下载到真实PLC上试运行，逻辑行为和预期一致。

需要说明的是，我用的是结构化文本（ST/SCL）来测试，而不是梯形图。原因后面细讲。如果你让AI生成梯形图，它通常只能给出一种“描述性”的XML或者LAD视图文本，没法直接导入GX Works或TIA Portal，实用性远不如ST。

这段测试让我意识到一件事：AI对于“需求边界清晰、逻辑链条明确”的编程任务，能力是被严重低估的。因为PLC程序的本质就是“输入条件→逻辑运算→输出动作”，而大语言模型恰恰擅长在大量代码语料中学习这类映射关系。越是规整的工程代码，它学得越好。

2.2 复杂逻辑实测：用汇川H5U写轴控程序

基础逻辑过了，我开始加大难度。第二个测试是汇川H5U的轴控程序。汇川的PLC这几年在包装、锂电、3C行业铺得很开，InoProShop用起来和Codesys系是一路的，支持ST、FBD、LD多种语言。

我给它一个真实需求：

• 双轴同步追剪控制（虚拟主轴+从轴联动）
• 从轴跟随主轴角度运行，切割位置触发凸轮动作
• 带原点回归、软限位、报警停止

AI生成的代码框架是完整且有效的：电子齿轮比的MC_GearIn能对上，原点回归MC_Home也写了。但有个细节问题——它把凸轮的相位偏移参数写死成了一个固定值，而我现场需要的是根据产品长度由HMI实时写入。

这不是什么高深的问题，但我意识到一个关键点：AI能读懂功能块手册上的说明，却不知道“现场工况里这个参数必须由人来设定”。所以它默认选择了“最标准”的写法，而标准写法在真实产线上往往是不够的。这也是为什么我说AI写的程序，一定要经过一个懂工艺的人“翻译”成现场语言才能真正落地的原因。

于是我继续给它补充提示：

凸轮相位偏移不是常量，需要从HMI的寄存器D500读取， 每次启动前由操作员设定。请修改代码。

AI很利索地把代码改成了从D500读取赋值的方式，逻辑没有破绽。这一步给我的感觉是：它写代码的能力，本质上是“海量编程知识库+模式匹配”。只要需求表述得足够具体、足够符合工程逻辑，它给出的东西就是能用的。

2.3 为什么是ST语言而不是梯形图？

这里我要专门说一下语言选型的问题。很多PLC老工程师习惯用梯形图，觉得直观、可追溯。但如果你想让AI帮你写程序，ST语言是唯一现实的选择。

原因有三：

第一，ST是文本语言，AI的训练数据里这类代码极多，生成质量最稳定。梯形图本质上是一个图形化数据模型（LD格式是XML），AI输出这类格式的能力远弱于文本，而且没法直接复制粘贴到软件里编译。

第二，ST在主流PLC平台中的兼容性已经非常好了。西门子博途的SCL、三菱GX Works3的结构化文本、汇川/信捷等Codesys系PLC的ST、欧姆龙NJ的ST块……底层都是IEC 61131-3标准的变体，语法差异主要在函数块命名和库的调用方式上，逻辑写法几乎通用。

第三，也是最重要的一点：ST更利于做代码审查。AI生成的一整段ST，你逐行看过去，判断它逻辑正不正确，比盯着一屏梯形图找问题要快。我的习惯是让AI写ST，我自己在脑内把ST“翻译”成梯形图的逻辑去审查。反向操作也行——你画梯形图有疑虑的时候，丢给AI让它帮你转成ST，对照着查。

所以，如果你还不会ST语言，我认真建议你花一个月时间把它拿下。它不是用来替代梯形图的，而是让你在AI时代多一条效率极高的路。

3. 让AI写出真正能用的程序：提示词里的“工程思维”

3.1 你给的信息越“像图纸”，AI给的代码越“像程序”

这句话是我测试了无数次后总结出来的核心方法论。AI不像人，它不会自动理解你脑子里的“现场情况”。它写出的程序好不好用，取决于你给出的上下文有多具体。

拿最简单的模拟量处理举例。直接说“写一个模拟量转换程序”，AI给你的就是那个经典的公式：工程量 = int(65535) ×（量程上限 - 量程下限）+ 量程下限。这没错，但没考虑采样滤波、断线检测、量程迁移，更不可能知道你用的是三菱FX5U的SD630特殊寄存器还是西门子的IW64输入字。

换个说法，把信息补全：

三菱FX5U，模拟量模块FX5-4AD，通道1接4-20mA压力变送器， 量程0-1.6MPa，希望转换成0.0-1.6的REAL值用于PID控制。 采样值需要做16点滑动平均滤波，断线时（电流小于3.6mA） 输出-1.0作为报警标志。请用ST语言写这段程序。

我把这段喂给AI，生成的代码非常干净：数据寄存器读取、滤波循环、断线判断、工程量换算，逻辑完整，每个环节的注释都有。我只改了两个地方——滤波的数组索引边界检查，以及把断线判断的死区从3.6mA改成了3.5mA（现场变送器有温漂，3.6会偶尔误触发）。整体来说，这个代码拿下来直接能用在项目里。

这个例子的核心差异在于：我把“工程语义”喂给了AI，而不是“功能描述”。功能描述是“写个转换程序”，工程语义是“什么PLC、什么模块、什么传感器、什么量程、什么异常工况、用在什么控制环里”。后者才是工程师脑子里的信息量，也是AI快速逼近“可用代码”的关键。

我列了一个我自己常用的提示词模板，给各位做个参考：

• 硬件型号：品牌、系列、具体模块型号
• 编程语言：ST/SCL/结构化文本
• 功能描述：这段程序要做什么，输入是什么，输出是什么
• 边界条件：故障怎么处理、超范围怎么处理、手动/自动模式如何切换
• 调用方式：是全局程序还是FB块，有没有需要复用的变量
• 特殊要求：扫描周期、中断、通讯方式、与HMI/上位机的接口

3.2 让AI学会你的命名规范和程序风格

第二个让我觉得“哇，这工具懂我”的测试，是让AI学习我的代码风格。十年PLC编程下来，每个人都有自己的习惯：我喜欢用UINT做状态位、状态机用十位数的数字编号（10=待机，20=运行中，30=故障）、报警输出统一用一个BYTE整包上传给HMI。

这些风格在技术文档里找不到，但它们是我调试效率的来源。我跟AI明确说了这些偏好后，它生成的代码里自动带上了我的命名习惯。比如：

VAR stWord : BOOL; (* 待机状态 *) stRun : BOOL; (* 运行状态 *) stFlt : BOOL; (* 故障状态 *) nAlmByte : BYTE; (* 报警聚合字节 *) END_VAR

原来得自己逐行写的状态机切换逻辑，AI一次就给我搭好了框架。我省下来的时间花在了更值钱的地方——准确判断设备的工艺动作顺序是否符合机械设计意图。

所以我的建议是：花十分钟把你的程序风格和命名规则整理成文字，存成一个固定的“风格提示词”，每次都贴给它。AI会越来越“像你”，你审代码的速度也会越来越快。

3.3 一个我经常用的“AI辅助审查”流程

除了让AI写代码，我更喜欢用它做“代码审查”。这个用法可能更适合同行老手：你写好了程序，但怕某个逻辑有疏漏，把代码粘给AI，问它“这样的逻辑在什么情况下会出问题？”

实测效果非常好。有一次我写了一个三菱FX3U通过485BD做Modbus RTU从站的通讯程序，数据交换格式是自己定义的。AI很快就点出两个问题：一是保持寄存器和输入寄存器的起始地址跨越了Modbus协议的功能码边界，二是在通讯异常时我没有对接收缓冲区做超时清理，可能导致下一次通讯粘包。

这两个问题确实存在。第一个是协议理解问题，第二个是工程经验问题。它们在现场不会立刻爆发，但运行一个月后就会变成“偶发通讯故障”这种最难查的疑难杂症。AI在代码审查上的能力，某种程度上强于写代码的能力，因为它能读取海量故障案例数据，见过的坑比我多。

我还做过一个实验：把一份包含“隐藏bug”的程序贴上注释“这段程序有问题，请找出潜在逻辑漏洞”，AI成功揪出了80%的问题——包括一个在特定条件下会让输出线圈双重赋值的神级隐藏坑。这个能力，说实话，比大多数第一年新人的代码审查水平要高。

4. AI的局限与翻车现场：那些不能交给AI的事

4.1 硬件地址与设备固有逻辑：AI最容易“张冠李戴”

AI不是万能的，我遇到的第一个大坑出在硬件地址上。有一次我让AI写欧姆龙NJ的模拟量处理程序，PLC的输入是NJ的模拟量模块，但我偷懒没有明确告诉AI模块的具体型号和通道分配方式。AI直接给我编了一个它“认为合理”的地址——%IW0.2，照搬照抄时误以为是通道2，实际上是模块槽位2。

这类问题几乎每次测都会遇到。AI不会知道你现场模块装在哪个槽、远程I/O站的地图范围、通讯模块占用的地址区段。这些信息它不可能“推理”出来，只能靠你提供。

我的处理习惯是：凡是涉及硬件地址、通道映射、通讯协议配置的部分，一律在提示词里写死在最开始：

输入模块：NJ系列的CJ1W-AD041-V1，槽位3 输入地址：%IW3.0（第1通道），%IW3.1（第2通道） 模拟量输入规格：0-10V，量程对应0-4000（16位）

这样AI生成的代码基本不需要改地址部分。如果你自己都不确定地址，那正确做法是先去查I/O分配表，而不是问AI——这就属于“工具之外的基本功”。

4.2 现场工艺与机械逻辑：AI能给你代码，给不了你“手感”

第二个局限性是工艺理解。我让AI写过一个追剪凸轮的程序，它写出来的MC_CamIn语法完全正确，联动逻辑也没有问题。但它默认把“从轴跟随主轴同步段”设成了360度整圈同步，而实际追剪设备需要的是“异步进给→同步追剪→快速回退”三段式凸轮曲线。

这不是AI逻辑不行，而是它不知道这台设备是怎么工作的。凸轮曲线要在哪个角度范围锁定同步、哪个角度范围快速回退、加减速的平滑曲线怎么设计——这些信息藏在机械图纸和老师傅的调试经验里，AI读不到。

但这不代表没用。我的做法是：让AI生成一段“标准的凸轮程序模板”，我自己在模板基础上按实际设备曲线修改关键角度值。相当于AI给了我一个空房子，我按自己的尺寸来装修。它的价值是把编程时间压缩了，而不是替你完成工艺设计。

所以如果你是完全没有民建自动化调试经验的新人，我不建议你直接信AI写的工艺程序就去现场跑。看懂程序和懂现场设备，永远是两个维度的事。

4.3 通讯配置与数据格式：AI帮你写代码，你帮AI理解报文

Modbus、MC协议、EtherCAT、CC-Link……通讯程序是PLC编程里最磨人的部分。我实测了AI在三菱FX3U+485BD做Modbus RTU从站、西门子S7-1200做Modbus TCP客户端等场景下的表现，结论是：AI对标准协议非常精通，对“协议细节的非标准用法”理解很差。

比如用FX3U的485BD板做RTU从站，寄存器映射范围需要设置特殊寄存器D8400系列，AI第一次给的代码把从站站号写进了D8121，方向切换的时间参数用默认值，这对于大多数应用虽然是标准做法，但现场调试时往往需要动态修改从站地址，而AI不会自动想到这一点。

更麻烦的是，如果你用的设备支持的是“半标准”协议（比如国产仪表定制的Modbus地址映射），AI给出的报文解析代码基本不能直接用。我测试过让AI写一个读取温控表当前温度的Modbus报文，它能正确写出03功能码和CRC校验，但寄存器地址若从十进制转十六进制时算错——表格上的地址是40001，其实对应的是PLC里的0x0000，它却写了0x0001。这就是典型的“AI不理解设备手册与实际寄存器偏移的关系”。

所以通讯类程序的正确合作方式是：

• 你负责查设备手册，确认寄存器地址映射表
• AI负责写CRC校验、报文组帧、超时重试逻辑这些底层琐碎
• 你再把两边拼起来，做整体联调

4.4 一个完整的“翻车到补救”案例：气缸顺序控制

最后分享一个印象最深的翻车案例。我让AI写一个双气缸顺序控制程序（A缸伸出→B缸伸出→B缸退回→A缸退回，带光电传感器到位确认），它一次就写出了可靠的状态机代码。但我下载到现场后发现，A缸伸出的同时，B缸电磁阀线圈竟然“闪”了一下。

查了半天，最后定位到问题：AI把B缸的输出地址写成了和A缸定时器中间变量的地址“同名”——它生成的代码里定义了一个共享字变量作为计时器的适应区，但同时又把该变量的低字节直接映射到了B缸的物理输出Q点。原因是我在提示词里给了输出点分配表，但没强调这是“独立的物理输出区”，AI就在变量区域优化时把它们重叠了。

这个问题的本质不是AI笨，而是“物理输出点值”和“程序中间变量”的隔离，靠程序员脑子里根深蒂固的“I/O表纪律”来保证。AI没有这个“肌肉记忆”，它只会在你给的信息边界内选择最省事的写法。我给的提示词是“输出Y0控制A缸电磁阀，输出Y1控制B缸电磁阀”，它是照做了——但另一头它定义了一个结构体变量，其内部偏移恰好撞上了Y1的地址。

解决方案倒是很简单：生成代码后，我自己全局搜索一遍“OUT”类指令，逐个确认物理输出地址没有重复。这个习惯以前就有，现在和AI协作后变得更加必不可少。

5. 老工程师与新工具的协同方式：我的“半天写完一周程序”工作流

5.1 我的AI协作工作流

测试了一段时间之后，我总结出了一套在真实项目里固定下来的工作流，现在基本每个项目都按这个节奏走：

• 第一步，手工整理I/O表和工艺时序图。这是AI时代唯一完全不能省略的环节。我用Excel列好所有I/O分配：模块号、通道号、PLC地址、传感器类型、对应气缸/电机/阀岛编号。工艺时序用一个简单的流程图加文字描述写清楚。

• 第二步，把I/O表和工艺描述粘贴给AI，附上明确的编程要求，让它把程序框架搭起来。这一步核心是让AI生成FB/FC的块结构、变量声明、以及各块之间的调用关系。

• 第三步，逐块审查和修改AI生成的代码。我速度快的时候，一个普通项目（200-300个点位，30来个FB块）两个多小时能审完全部代码。审查重点：物理输出地址是否重复、定时器是否越界、通讯功能块的执行条件是否安全。

• 第四步，把确认过的程序下载到PLC，用仿真或在线模拟验证一遍关键逻辑。我习惯先让AI检查逻辑漏洞，再自己运行在线监控，配合强制功能走一遍关键节点的时序。

这套流程用下来，最直观的变化是：一个常规的改造项目，之前我写程序+自查就要两到三天，现在基本一天搞定。省下来的时间，我用来做以前顾不上做的事——HMI画面的操作权限分配、报警文本的重新组织、电缆标签核对。这些平时“不重要但影响体验”的活儿，反而让我在项目验收时收到不少好评。

5.2 AI不适用的场景：这些程序求你别省事

有几类程序我是坚决不让AI代笔的：

• 安全回路类：急停、安全门、光幕联锁。这类逻辑涉及人身安全，逻辑再简单也要自己手写，且必须在多人审查后通过。AI生成的安全程序，你没法从“责任”角度对它问责。

• 极高速逻辑：伺服中断处理、电子凸轮高速区段修正、扫描周期严格限定的任务。AI生成的代码往往会在循环里不经意加入延时较大的操作，或者变量类型选择不优化访问效率，这些在普通低速逻辑里毫无影响，在高速场合就可能导致扫描周期波动。

• 你自己都搞不清楚的工艺段：这一步的逻辑如果是靠现场师傅“试出来”的，先把工艺摸明白再提AI的事。AI不会比师傅更懂你的设备，这种场景输给AI就是两边都瞎。

• 老旧PLC的特殊指令集：AI对十年前的FX2N、C200H这类老平台里的专用指令和特殊寄存器理解的精度会下降。它训练语料里这类内容相对少，而且不同批次固件的特殊寄存器定义有差异，AI区分不了。这类老平台程序，我会自己写，让AI做逻辑审查就够了。

5.3 AI是“读手册的助手”，不是“懂现场的师傅”

如果你问我，让AI写PLC程序的最大意义是什么？我的答案是：它把“写代码”的时间成本大大压缩了，让我有更多精力放到“读设备、读工艺、读现场”上去。

干PLC这行的人都知道，编程从来不是最难的。最难的是搞清楚机械手爪到位信号的抖动是传感器问题还是气缸缓冲不足；是上位机发来的启动指令时序不对，还是PLC扫描周期恰好错过了信号。这些判断AI给不了，任何工具都给不了。它靠的是你在车间里蹲出来的经验——这台设备运行时的声音、震动、温度，都在替你说谎和作证。

所以我把AI定位成“一个读了十年编程手册的助手”：协议格式、语法细节、常见逻辑模式，它比我记得全；但哪台设备的行程开关该加滤波延时、哪个阀的线圈要加续流二极管，它永远不如我清楚。

这种分工我觉得是健康的。编程时间少了，调试时间没变，但我的精力分配变了。以前写程序写到手抖，现在写程序像“审核图纸”，反而感觉对程序的理解更清晰了。

6. 给同为老PLC工程师的几点实在建议

6.1 半个月适应期怎么过

如果你是传统梯形图派的工程师，刚开始用AI写ST，肯定有“不如自己画得快”的阶段。这很正常。我的建议是：别一上来就拿真正赶的项目的核心功能试水。先拿旧项目的非关键部件练手，比如报警聚合、数据记录、配方管理这类模块，在仿真里反复下载测试，强迫自己适应“描述需求→生成代码→审查修改”这个新节奏。

大概过两周，你就能体会到好处了。因为ST语言在表达复杂逻辑时本来就比梯形图清晰，AI生成ST的高效率和你的审查经验结合，会让“写程序”这个环节在项目里所占的时间比例明显降低。

6.2 提示词里务必写死的五件事

以下是我多次翻车后总结出的“必须写死清单”，每次生成代码前逐项确认：

• PLC品牌和具体型号（三菱FX5U、西门子S7-1500、汇川H5U等）
• 编程软件版本（会影响函数块格式）
• 编程语言（ST/SCL/结构化文本，不要让它自由选择）
• 所有硬件地址分配表（物理I/O地址、模块槽位、通讯站号）
• 特殊要求（扫描时间限制、是否需要可复用的FB块、手动/自动切换规则）

这五件事写清楚，AI生成的代码基本在“可用”和“比较好改”之间。偷懒少写一个，后面就是多返工一小时。

6.3 争议话题：AI会让PLC程序员失业吗？

这个问题最近总被问到。我的看法是：AI会淘汰的是“只会照着教科书翻译逻辑的初级程序员”——那种遇到问题先翻手册、手册里没有就停住不动的人。但PLC程序员的真正价值从来不只是“能把梯形图画对”，而是“能判断现场为什么和图纸不一样”。

产线调试的真相是：图纸和接线从来没完全一致过，传感器反馈也不会永远准时。AI能在你输入“设备不动”这个问题时，帮你定位到程序里某个中间变量的状态不合理。但它不会替你爬到十九米的桁架上查那个接近开关的感应面是不是被铁屑糊住了。

所以，与其问AI会不会让我们失业，不如问自己一个问题：我是那个只会写程序的人，还是那个懂整台设备的人？答案是后者的工程师，AI只会让你更值钱——因为你省出来的时间，都花在了别人替代不了的地方。

6.4 最后，一个小习惯分享

每次用AI生成完代码，我都会额外做一件事：让它为这段代码写一份“现场调试注意事项”清单——它通常会列出需要检查的接线端子号、可能出现的干扰源、以及每个参数变化的时间曲线特征。这个清单我会打印出来，夹在项目资料里带进车间，调试时对照着检查，发现挺管用。

我以前写程序从不自己写测试用例，现在AI给了这份便利，也不该浪费。程序要是有问题，能快速定位；要是没有问题，这份清单也算给后续维护的人留了一份“前人经验”。这算是这段时间和AI协作下来，我收获最大的副产品了。