企业官网建设流程全解析

做PLC这行十几年了，最近三个月工作室群里聊得最多的就是AI写程序。一开始我是拒绝的，毕竟现场出问题是要跳闸停机的，谁敢拿一个“聊天机器人”生成的代码往设备上怼？但架不住项目催得紧，某天夜里实在改不动了，抱着试一试的心态把一段ST语言的需求扔给了AI工具，结果它给出的框架逻辑居然像模像样。从那天起，我陆陆续续把几个项目的功能块、启停逻辑、报警程序都交给AI生成，再结合自己的经验去改、去验证。这三个月踩了不少坑，也总结出一套能用、敢用的方法。这篇就聊聊我的真实感受：AI写PLC代码到底靠不靠谱，靠谱在哪儿，不靠谱又在哪儿。如果你是搞自动化、搞工控的，或者正准备把AI引进你们团队的工作流，这篇文章应该能给你一些有价值的参考。

1. AI写PLC代码到底能干什么？先别急，把边界画清楚

1.1 它擅长的：结构化文本、常见逻辑框架

先从结论说起：在ST语言（结构化文本）这个领域，AI的生成能力已经达到了“能用”的水平。所谓能用，是指你给它一段清晰的需求描述，它能给你出一段语法基本正确、逻辑结构合理的代码，帮你省掉从空白页开始敲第一行的时间。

我做的最多的一类尝试是设备单体逻辑。比如水泵的星三角启动，放在过去，我需要从建变量、画梯形图、写互锁、加延时挨个来，一套流程走下来半小时起步。而AI的生成只需要一两分钟，而且逻辑上几乎没有破绽：启动指令置位、主接触器和星接触器先动作、延时三秒切换三角接触器、停机复位、保护跳闸联锁——这些它都能给你写出来。

它擅长的另一个点是生成标准的算法模块。滤波、平均值计算、单位换算、批量数据处理、报警阈值判断这一类的纯计算逻辑，AI写起来非常干净利落。因为这类代码在互联网上的样本量大，代码风格高度统一，AI学得也最好。你甚至可以要求它生成符合IEC 61131-3标准的代码风格，它连注释都能给你按规范补齐。

1.2 它不擅长的：现场硬件、时序安全、老旧设备

但你要是以为AI已经能替代工程师了，那就大错特错了。在几个月的使用中，我碰到的最大问题就是AI对“地址空间”完全没有概念。它根本不知道你的输入模块在哪个槽位，输出继电器使用了哪个字节地址，更不知道你的中间变量有多少个已经占用了。你要是不提供点位表，它就会自己编一个看起来特别合理的地址出来——然后你下载到PLC里，轻则变量冲突，重则设备误动作。

再一个是时序问题。PLC的程序不是从头到尾跑一遍就完事儿，它是循环扫描的。同一个变量在扫描周期的不同位置读到的是不一样的值，这在AI看来是完全无法理解的。它写出来的程序，在逻辑层面看不出毛病，但放到实际扫描周期里，会出现数据没更新就被人读走了、输出该复位没来得及复位之类的问题。这些不是靠逻辑推理能解决的，而是要靠工程师对扫描周期的理解去调整。

还有一个致命区：老旧设备、特殊指令。你如果用的是十年前的某日系品牌老PLC，AI的训练数据里根本没有那么老的指令集，它给你生成出来的就不是“代码不够优化”的事儿了，而是指令根本不存在。我试过用AI给一台老设备写通讯解析程序，生成的代码里连指令助记符都是编造的，设备压根不识别，编译都过不去。

所以，AI写PLC代码这件事的第一课，不是“它能不能写”，而是“你要让它写什么”。写标准算法、写常见框架、写注释规范的ST代码，它能帮你省大量时间。写地址、写时序敏感的联锁逻辑、写老平台的专属指令，趁早打消这个念头。

2. 我实际用AI写了什么？三个项目实例复盘

2.1 案例A：水泵星三角启动——AI最舒服的舒适区

这个程序几乎每个做自动化的人都写过。我做这个案例的初衷是测试AI在“完全不给硬件信息”的前提下能生成什么水平的东西。

我给的提示大概是这样的：“生成一个水泵星三角降压启动的ST程序，包含手动自动模式、启动停止按钮、过载保护输入，延时5秒，需要互锁逻辑。输出变量是主接触器、星接触器、三角接触器。”

AI返回的程序让我眼前一亮。结构非常清晰：变量声明、主程序、辅助逻辑分得明明白白。电机启动保护逻辑、星三角互锁逻辑都在。但问题出在细节上：它把星接触器输出和三角接触器输出写成了一个变量名的两种状态——这在逻辑上看没错，但实际上星和三角是两个物理接触器，必须分别控制、分别读状态。我最后花了二十分钟修改输出映射和补充手自动切换时的复位逻辑，最终才下载到PLC里。

这个案例的结论是：AI能给你搭好框架,但框架和现场之间的“最后一公里”，得你自己走过去。

2.2 案例B：传送带分拣计数——提示词决定一半成败

这个项目是一个有三条支线的传送带分拣系统。核心需求包括：主传送带启停、三个传感器检测产品通过、气缸推料分拣、计数统计、满箱停机。

经过第一个案例的经验，这一次我在提示词上花了更多的功夫。我没有让它“写一个分拣程序”，而是给它列了一份伪需求文档，包括输入输出点位清单、传感器的安装位置、气缸动作顺序、计数逻辑的边界条件。结果大不一样：它生成的分拣逻辑几乎可以直接使用。传感器信号边沿触发计数、气缸动作超时报警、计数达到设定值时停止主传送带，这些全部到位。

这次经历让我意识到一个重要规律：AI写PLC代码的水平不取决于模型本身,而取决于你给它输入了什么。你给的是“需求一句话”，它给你的是“逻辑框架”；你给它的是“技术规格书”，它才能给你“可上线的程序”。

2.3 案例C：PID回路调试——AI能帮上忙但别全信

PID控制是很多人觉得AI肯定搞不定的领域，但实测下来它其实能提供不少帮助。我让AI帮忙生成一个温控回路的PID功能块调用框架，它给出了正确的PID指令参数格式、手动自动切换逻辑、输出限幅处理、积分作用防饱和提示——这些确实是很多新手容易写错的地方。

但真正让我没料到的是，AI对PID参数的整定方法给出了一个非常好用的参考流程：先设一个保守的P值，再看曲线振荡情况调整I，D值优先不给。这个方法本身并不是什么秘密，但AI把判断依据讲得很清楚，“曲线等幅振荡则说明增益过大”“升温过慢则增大比例带”这类对照建议，对现场调试人员来说相当于有个人在旁边提醒你。

当然，PID的最终参数还是要靠现场试。AI能给的是方法论，给不了你设备的热惯性、环境温度波动、物料湿度影响。它生成的功能块框架我用了，参数整定建议我参考了，但最终的参数表还是我一组一组试出来的。能帮你规划路径，但走路的每一步还得自己来。

3. AI写PLC代码的原理：为什么能写，又为什么出错

3.1 它学的不是语法，是海量代码里的“套路”

用过AI的人都会有这种困惑：它连实体的PLC都没见过，它凭啥能写出逻辑正确的程序？这就涉及大语言模型的基本工作原理。AI的训练数据里有大量PLC程序示例、技术手册、工控论坛问答、开源项目代码，它通过对这些数据的统计分析，学会了代码的“套路”。

什么叫套路？就是“启动按钮ON→接触器输出ON”这种强因果关联、“延时5秒→定时器指令TON”这种问题与方案的标准映射。见得多了，它就能根据你描述的问题，匹配出最可能的代码模式。这就是为什么常见的逻辑AI写得又快又好，因为训练数据里全是这类东西。而为什么小众指令、老设备程序它容易出错？因为训练数据里太少了，它只能靠“猜”。

理解这一点很重要。它能写不等于它理解，它是在做一种高级匹配。遇到没有见过的设备型号、指令格式，它的表现和没有经验的新手差不多——硬套相似逻辑，结果四不像。

3.2 扫描周期思维：AI永远学不会的最重要一课

PLC和普通计算机的程序最本质的区别，就是扫描周期。计算机程序可以自己决定执行顺序，而PLC是自上而下、从左到右循环扫描的，程序执行完一遍后立即从头开始下一轮，一轮通常是几毫秒到几十毫秒。

这个特性对整个程序逻辑有深远的影响。举个例子：你在程序前半段修改了一个变量的值，但这个变量已经在程序后半段被之前的扫描周期读走使用了，那么实际效果会比你预期的慢一个周期。再比如说，一个物理按钮按下和松开的时间，可能恰好卡在扫描周期的边界上，软件如果没有做沿检测，就会漏掉信号。

AI是完全没有“扫描周期”这个概念的，因为它不是靠实时运行代码来学习的。它看代码，只是在看“文字之间的关联”，它理解不了“这个输出在下个周期才会被这个输入影响”这种时序关系。所以AI生成的程序经常出现同一扫描周期内变量先写后读、边沿检测逻辑缺失、定时器复位位置不对这类问题，这些都是不懂扫描周期的典型表现。

这也是为什么我一直强调，AI写的程序一定要经过有经验的工程师审查。它写的是“逻辑上的正确”，你要确认的是“实时运行上的正确”。

3.3 可靠性怎么评估：四个层面逐层拆解

用了三个月，我总结出一套评估AI生成代码可靠性的方法。把它拆成四个层面，逐层验证，就能比较准确地判断哪些代码能直接用、哪些要修改、哪些必须推翻重写。

第一层：语法正确性。把生成代码直接扔进编程软件里编译，能通过编译是最低标准。不过要注意，有些AI生成的代码在你用的软件版本里语法能过，但如果换一个软件版本就不一定了。所以我一般直接在当前项目的编程环境里编译，而不是在通用编辑器里看。

第二层：逻辑正确性。用模拟器跑一遍，把输入信号依次强制置位和复位，观察输出是否符合预期。这一步能发现大部分逻辑漏洞，比如互锁没锁住、状态没复位、延时没控制住。

第三层：工程实用性。这一步是AI最难通过的。要点包括：变量命名是否符合你的规范、有没有和其他功能块共享变量冲突、有没有把不该暴露的中间变量公开出来、数据类型转换是否安全。这些是代码能不能长期维护的关键。

第四层：现场适配性。说白了就是下载到真实PLC里跑。这一步主要验证的是时序问题、扫描周期影响、通讯延迟、IO响应速度。AI在这个层面得分最低，但它帮你搭建的代码框架恰恰又是这层验证的基础。

按我的经验，AI生成的代码，第一层大概有80%能通过，第二层降到60%，第三层只有30%，第四层几乎没有。但反过来看，如果它第二层都能过，说明这个框架是健康的，基于这个框架去做适配修改，比从零开始写还是要省一半以上的时间。

4. 三个月踩坑实录：常见问题和排查技巧

4.1 经典错误速查表（看了能少走弯路）

这三个月我收集了一堆AI生成PLC代码的典型错误。有些属于“AI界的通病”，有些则非常有这个领域特色。这里做一张表，方便你对照排查：

| 错误类型 | 具体表现 | 原因分析 | 解决办法 | | 变量凭空创造 | 代码里出现未在变量表中定义的中间变量 | AI不了解项目变量分配情况 | 提前将点位表和变量名告知AI | | 指令张冠李戴 | 某品牌的定时器指令被错写成另一品牌的格式 | 训练数据来源混杂 | 在提示词里明确标注品牌型号和软件版本 | | 地址冲突 | 生成的DB块地址与已有程序重叠 | AI完全不知道已有程序占用 | 不依赖AI管理地址分配 | | 忽略扫描周期 | 同一变量在无延时的状态下被同一周期写读 | AI不理解PLC循环扫描机制 | 人工审查所有变量读写顺序 | | 定时器复位位置错 | 复位写在生成条件里而不是独立复位逻辑 | 对定时器工作原理理解不到位 | 按标准结构重写定时器段 | | 边沿脉冲当电平用 | 把只在ON一瞬间生效的脉冲信号当长信号使用 | 不清楚BOOL信号的电平/脉冲区别 | 用模拟器检查信号形态 | | 数据类型混乱 | 把INT当BOOL用，或把REAL直接传给INT指令 | 缺乏类型强制转换意识 | 在提示词中注明变量的数据类型 | | 输出重复赋值 | 同一输出变量在多处被置位和复位 | 未考虑程序执行到后面的覆盖效果 | 严格检查每路输出的赋值位置 |

这张表是我三个月来最核心的收获之一。你不需要记住全部内容，但如果你用AI生成代码，建议把这张表贴在屏幕旁边，逐项对照检查。

4.2 我的验证流程：模拟器、代码审查、交叉验证

AI生成的代码要经过验证周期的检验，我梳理了一套固定流程，分享给大家参考。

第一步，编译验证。这个没什么可说的，先把代码复制到编程软件中编译，看有没有语法错误。多提一句：有些AI生成的代码在ST语言里能过编译，但如果你的项目混用了梯形图和ST，编译时可能出现跨语言不兼容问题，这种要在提示词里提前说明语言类型。

第二步，模拟器测试。把编译通过的程序下载到PLC仿真软件里，模拟器里跑一遍全流程。我习惯的做法是：把AI代码写到单独的功能块里，和原有主程序做逻辑隔离，然后用模拟器的强制功能依次触发输入信号，观察每一步的输出变化。

第三步，逻辑交叉审查。这一步非常重要，特别是对于没有硬件基础的AI生成的代码。我把AI生成的代码发给自己团队里另一位工程师，让他以另一个角度去读。两个人都觉得没问题，我才进入下一步。这个环节屡次发现AI代码里的逻辑漏洞，尤其是互锁和报警复位这两类，AI写错概率特别高。

第四步，小范围实测。选择一个不影响整个产线安全的单台设备，把代码下载进去实测。通常我会先跑低电压模式或者手动模式，逐步确认IO映射和动作时序，确认无误之后才进入自动模式运行。这一步是检验前面所有工作的试金石，也是最没法偷懒的环节。

4.3 一个细节：提示词质量对结果的巨大影响

前面我提到相同AI工具，提示词的质量直接决定了结果的可用程度。这三个月我从最简单的“帮我写个水泵程序”一路摸索，到现在已经形成了一套固定的提示词模板。它大概是这样的：

身份设定：告诉AI它是什么角色。“你是一位有15年经验的PLC工程师，熟悉某品牌某型号控制器的ST语言编程规范。”

环境信息：交代硬件背景。“当前项目使用的是某日系品牌的某系列CPU，编程软件为对应版本，支持ST、梯形图和功能块图语言。”

点位清单：把所有输入输出的变量名、地址、数据类型、功能说明列清楚。这里一定要具体到类似“DI0.0：启动按钮，BOOL类型，常开触点”这种颗粒度。

逻辑要求：把你要实现的工艺逻辑准确描述。“当启动按钮按下时，如果满足所有安全条件，则启动电机输出；当停止按钮按下或发生故障时，立即停止输出，并保持停止状态直到复位。”

输出格式：指定AI生成的代码格式。“请使用ST语言生成，变量名使用前缀命名规则，输出完整的变量声明段和程序段，针对关键逻辑添加中文注释，注明定时器工作时长和联锁条件。”

这套模板下来，AI生成代码的可用率至少提升了一倍。说到底，AI在工控领域的发挥上限，取决于你对项目的理解程度。你越清楚要什么，它就越能给你的思路补上代码。你如果自己都没想清楚逻辑，AI写完你也分辨不出问题在哪里。

5. 什么情况下我建议你用AI，什么时候千万别用

5.1 适合AI的场景和用法建议

结合三个多月的实践，我梳理一下哪些场景我建议大家大胆用AI。

首先是程序框架搭建。任何你熟悉但不能立刻默写的标准逻辑，都可以交给AI先出第一版。比如电机启停、阀门控制、报警处理、手自动切换，这些逻辑成熟且统一，AI生成后你只需要检查修改，比自己敲快得多。

其次是算法类模块。数据处理、单位转换、滤波算法、PID功能块框架、通讯报文解析，这类代码结构清晰、计算规则明确，AI生成质量非常高。我最近常让AI生成一些特殊算法，比如移动平均值滤波、温度传感器的线性化查表处理，效果相当好。

第三是注释补齐和代码规范整理。AI能读懂你的代码逻辑，给它一段你写好的PLC程序，让它补充注释、统一命名规范、整理格式，它做得又快又好。这方面的价值被很多人忽略了。维护老项目时用AI整理代码，能让后接手的人少走很多弯路。

第四是学习性的用途。让AI解释一段他人写的复杂代码，帮你理清每个功能块的作用，比翻手册快得多。我有个同事就是靠AI讲解，把一段结构复杂的通讯程序吃透的。这个用法是纯收益，没有什么风险。

用法上我建议你把它当“高级代码助手”，而不是“自动编程机器”。你负责逻辑推理、硬件匹配、安全验证，它负责快速生成符合通用代码风格的底稿。双方配合，效率提升最明显。

5.2 绝对禁区：安全逻辑和关键工艺保护

讲了这么多AI能做的事，接下来必须把话说死：有些场景绝对不要让AI生成代码。

第一类是安全回路。包括急停回路、安全门联锁、光栅保护、安全PLC相关逻辑，以及任何和人身安全相关的功能性安全程序。这类代码有明确的安全标准（比如ISO 13849、IEC 61508等），AI连相关标准都说不清楚，更不可能满足认证要求。任何涉及安全的逻辑，必须以人工编写为准,AI生成的代码哪怕看着逻辑正确，也必须彻底排除。

第二类是核心工艺保护逻辑。比如某些不能过热的设备、动作顺序存在严格依赖关系的产线、一旦误动作会造成重大损失的程序。这些程序里的每条联锁、每个条件都是工程师用事故换来的经验，AI生成的代码永远不可能理解“因为曾经撞机烧了电机，所以这个位置必须加三重保护”的含义。

第三类是跨设备协调逻辑。两条产线之间联动的握手协议、多个PLC之间的数据交换时序，这些程序的可靠性建立在大量现场调试和工程经验之上，变量之间的时序关系非常微妙，远超出了AI当前的能力范围。

最后再说一个很多人忽略的：工艺参数和配方管理。这类代码表面上看起来不复杂，但里面的数据校验、权限管理、冗余机制都是现场长期积累的成果，AI生成的简化版本可能会丢失这些安全措施。这类程序宁可不改，也不要去试。

写在最后：一个工程师和AI协作的常态

三个多月用下来，我对AI写PLC代码的最后看法是：它不是来抢工程师饭碗的，它是一个可以把我们从重复劳动里解放出来的工具。过去我写一个星三角启动程序，从变量表、梯形图、互锁、仿真、改错到最后文件，需要两个小时；现在AI生成之后我改改适配硬件、调调时序，二十分钟能搞定。省下来的时间，我能用来琢磨那些真正影响产线效率的工艺细节。但这一切的前提是：你必须对自己的设备了如指掌，对控制逻辑有清晰理解，并且愿意认认真真地做验证。AI是放大器，你有经验，它就帮你省时间；你没经验，它只会帮你快速生成一个充满隐患的程序。最后分享一个小的经验：我每次让AI生成完代码，都会让它再对代码做一次“风险自查”，让AI以对立面视角找问题。这招虽然不能替代人工审查，但经常能提前暴露一些盲区，算是用AI对抗AI的一个小花招吧。