AI代码生成这个词，这几年已经从一个“新潮玩具”变成了很多程序员的日常工具。但我接触下来发现，大家讨论的场景基本都被Web前端、Python脚本、算法题给占满了，很少有人聊工业自动化里的PLC编程。作为一个写代码十几年、常年跟产线设备打交道的工程师，我最近专门做了一轮压力测试，把AI代码生成直接扔进了真实项目里，重点深耕了AI PLC代码生成这个小众但极有应用价值的方向。折腾下来，我不仅把重复性的PLC逻辑砍掉了大半，还沉淀了一套适合复制到团队里的AI coding代码生成规范示例。这篇文章不吹不黑，就是把我的真实体验、踩过的坑、最后收口的方法全盘写出来，给那些想上AI编码又心里没底的同行做一个参考。
1. 上手体验：我先用AI代码生成解决了什么
1.1 为什么工业自动化场景最适合试点AI编码
很多人一听到“AI写代码”，第一反应是写网页、写Python脚本、写小工具。这些场景AI表现确实抢眼，生成快，格式也漂亮。但真正让我对AI编码“刮目相看”的，反而是在PLC项目里的应用，一个听起来特别传统、特别不性感的领域。
因为PLC项目里存在大量规律性极强的重复代码。比如模拟量处理、报警逻辑、设备启停、阀门连锁、数据上报，这些模块在不同项目里就是换个地址、改个注释就能整体复用。让工程师手动去写，不仅枯燥，而且特别容易在复制粘贴的时候漏改某个点。AI对这种“高重复、低创造”的代码，天然就是最强辅助。我甚至觉得，AI写PLC代码的稳定性比写普通业务代码还要高，原因是PLC的输入输出边界都很清晰，信号类型翻来覆去就那么几个，AI不容易自我发挥。
第二个原因是PLC程序的调试成本很高。普通后端程序员一天可以编译运行几十上百次，PLC程序想跑一次完整验证，要下装到控制器、连接仿真环境，一次全家桶下来可能就是十几分钟的等待。现场出了问题，轻则停产，重则设备动作失控。正因为试错代价大，PLC开发里特别强调“先想清楚再动手”。这种工作习惯正好能发挥AI的能力——AI生成得再快，也只是帮你想得更快，最终判断还得落到工程师身上。换句话说，PLC行业长期积累的严谨性，恰好和AI编码的短处形成了一种互补：AI负责快，人负责稳。
还有一点我特别想强调，就是工业代码的规范性比互联网代码严格得多。变量命名、注释格式、安全联锁、版本管理，每个PLC团队都有不成文但必须守的工程习惯。以前这些规范靠人肉执行，新工程师上手半年的核心任务就是“看懂规范”。到了AI编码这里，规范可以完整写进Prompt里，等于把团队经验直接固化成了生成条件。我发现这其实才是PLC方向引入AI最有价值的部分：不是让AI替你做决策，而是让它严格按照你设定的规范输出，把你原来要花在培训新人上的精力解放出来。
1.2 我从哪里开始：选场景、挑工具、定边界
坦白说，我一开始也是瞎试的。让AI“帮我写一个完整的灌装线控制程序”，结果得到的东西又长又空，变量名全是A、B、C，逻辑还互相打架，完全没法用。后来我换了个思路，不把AI当“全栈工程师”，而是把它当“一个干活麻利但特别需要明确指令的高级实习生”。这个心态一换，效果立刻不一样。
我给自己定了三层边界。场景边界：只让AI生成独立的逻辑块，比如一个电机控制功能块、一段报警处理函数、一个气缸时序段，而不是让它一口气吐整机程序。技术边界：统一采用IEC 61131-3标准里最适合文本生成的结构化文本ST语言，因为梯形图、功能块图这类图形化语言AI没法直接编辑，ST天生就是代码，能跟AI无缝衔接。质量边界：AI生成的代码必须能通过团队现有的代码评审标准，变量命名、注释、错误处理缺哪样都不行。把边界定清楚之后，我才开始选工具。
工具方面，我大部分时间用的是通用型大模型加代码辅助插件的组合。市场上主流的AI编程助手我也试过几款，实测下来一个有意思的结论是：对PLC这种小众领域，通用大模型有时候比专用编码工具更好用。原因是专用编码助手更擅长读你仓库里的历史代码做连续修改，但如果你项目本身代码里充满了坏味道，它读完反而容易照着坏风格继续生成。而通用大模型只要你把PLC背景知识、I/O表、工艺描述一次性喂进去，它的语义理解能力完全能写出像模像样的ST代码。
现在像CODESYS、TIA Portal这类PLC集成开发环境，也在逐步推出自己的AI增强功能。我的建议是别干等厂商把完整方案做好，当前阶段的通用工具已经能支撑一整条辅助编码的工作流。先把PM流程跑通，工具版本迭代自然会让体验越来越好。等厂商的AI插件成熟之后，再逐步迁移过去也不迟。
2. 实操记录：AI辅助PLC代码生成的全流程
2.1 把工艺描述翻译成Prompt：拆需求比写代码更重要
第二段我实际跑了一个案例：一套输送线分拣控制。工艺很简单，货物到达检测位后，传感器触发，分拣气缸推出，把货物推入侧向滑道，气缸缩回，整个过程按顺序循环。现场信号就那几个：来料检测、气缸伸出到位、气缸缩回到位、启动、停止、急停。
如果我把这段需求原封不动扔给AI，大概率拿到一份能编译但缺乏现场感的代码。所以我的做法是先把需求拆解成几个维度，再组织成Prompt。主要包含五个部分：
- 功能描述：把工艺动作写清楚，动词要特别明确。“货物到位后气缸顶出”和“当检测到货物且气缸在原点时，气缸顶出并保持2秒”，这两句话生成的逻辑会天差地别。AI理解语义靠的就是你给它的表达精度。
- I/O清单：把每个信号的名称、类型、语义都列出来。AI模型对符号名的理解其实很到位，但你得先把符号定义给它。我会把启动、停止、急停、传感器、输出线圈全部列好类型。
- 安全与约束：说明哪些条件优先级最高。比如急停必须无条件切断输出、气缸动作必须在允许范围内、故障灯必须保持直到人工复位。这些约束如果不写，AI自己不会加。
- 时序要求：互锁、延时、防抖、超时这些时间维度的需求，是AI最容易漏掉的地方。所以我会显式写“伸出到位后延时500ms再缩回”“信号必须持续50ms才算有效”。
- 代码规范：变量命名规则、注释语言、是否需要状态机结构、禁止双线圈赋值。规范越细，后文3.2节我会展开讲。
这里有个特别值钱的技巧：强制AI先“复述”一遍需求。我会在Prompt末尾加一句——“请先用中文列出你对该程序的理解、输入输出定义和状态跳转条件，然后再开始生成代码”。如果AI的复述已经理解跑偏，那后面生成的代码根本不值得看。这一步看似多花几十秒，实际上能帮你省掉后续一两个小时的修改时间。我在工业项目里把这个方法叫“需求回读”，推理和编程都适用。
2.2 一次真实的生成过程：结构化文本的产出与信任边界
那次给我的Prompt简化下来大概是这样：
请生成一个TIA Portal环境下的FC功能块，语言为结构化文本ST。功能：输送线分拣气缸控制。输入：Start（BOOL）、Stop（BOOL）、EStop（BOOL）、PartDetected（BOOL）、CylinderOutLimit（BOOL）、CylinderInLimit（BOOL）。输出：CylinderOut（BOOL）、Alarm（BOOL）。要求：采用单一状态机，状态包含IDLE、EXTEND、RETRACT、FAULT；急停必须无条件切断输出并进入FAULT；顺序需要等PartDetected为TRUE后才从IDLE转到EXTEND；气缸伸出到位后延时500ms再缩回；变量命名使用前缀风格，布尔量以b_开头；注释使用中文。
AI返回的结果，确实能看出“被约束过的痕迹”。状态机用CASE语句实现，急停分支被放在了所有分支的外侧，互锁条件也基本正确。贴一段核心代码差不多是这样的：
CASE State OF IDLE: IF b_Start AND b_PartDetected AND NOT b_EStop THEN q_CylinderOut := TRUE; State := EXTEND; END_IF; EXTEND: IF b_EStop THEN q_CylinderOut := FALSE; State := FAULT; ELSIF b_CylinderOutLimit THEN q_CylinderOut := FALSE; t_ExtendTimer(IN := TRUE, PT := T#500MS); IF t_ExtendTimer.Q THEN State := RETRACT; END_IF; END_IF; RETRACT: IF b_EStop THEN q_CylinderOut := FALSE; State := FAULT; ELSIF b_CylinderInLimit THEN State := IDLE; END_IF; FAULT: q_CylinderOut := FALSE; IF NOT b_EStop AND b_Reset THEN State := IDLE; END_IF; END_CASE;我必须澄清，这个版本是我经过两轮修正之后的成品，并非AI第一版的原样输出。第一版AI把急停处理埋在了每个状态分支的内部，同一个急停逻辑重复写了三遍，虽然结果勉强正确，但完全没做到“无条件切断”这个约束，一旦未来有人在某个新增状态里忘写，安全链条直接失效。更让我冒冷汗的是，AI在某个赋值语句里把CylinderOutLimit拼错了一个字母，变成CylinderOutLimt，编译会报错，可PLC编译器一般只提示第一处错误，后面的潜伏问题根本不会一下曝光。这么多细节，光靠扫读很难全部发现。
所以我给自己立了一条死规矩：AI生成的代码，我可以接受80%的框架，但每一行都必须经过人工过目。信任边界必须画清楚——AI负责搭骨架、画轮廓、填充常规逻辑，我负责人肉审稿、查细节、堵安全漏洞。任何看起来“应该没问题吧”的代码，都不能进PLC。这段时间体验下来，这条规矩帮我避免了好几次现场故障，我觉得比任何一条AI使用技巧都重要。
2.3 代码落地四步法：修订、编译、仿真和心态
拿到AI初稿之后，我有一套固定的落地流程，基本分四步走。
第一步是变量表核对。把AI用到的所有变量名和实际PLC变量表逐一比对，大小写、前缀、数据类型、BOOL还是INT，错一个都要改。这一步不能省，生成代码里变量名写错的发生频率远比你想象的高。我不止一次看到同事把英文下划线打错导致编译不通过，白白花了半小时排查。
第二步是注释和语义修订。AI生成的注释经常是“表面正确、内容空洞”。比如给IF条件配上“如果启动信号为真”，这种注释对现场维护毫无价值。我会改成带工艺语义的写法：“启动按钮按下且来料检测已置位，说明有货物等待分拣，进入顶出动作”。好的PLC注释应该告诉后来人“这段逻辑为什么存在”，而不是复述一遍代码本身。很多工程师嫌注释麻烦，但在PLC项目里，注释就是给半年后接手的人留的救命稻草。
第三步是编译和下装。这个没什么好说的，有错就改，改完再编。特别提醒，和高级语言不一样，PLC编译器的很多警告不影响编译却直接影响运行时安全。像“变量未初始化”“双线圈输出”“FB实例重复调用”这类问题，AI很难主动规避。编译信息里出现的每一条警告，都要人工判断它是否会影响现场工艺，不能因为能编译过就跳过。
第四步是仿真验证。我用带在线仿真功能的PLC开发环境，通过强制赋值模拟传感器信号。仿真过程中要特别关注边界场景：急停在气缸伸出中点被按下、来料检测在气缸缩回中途再次触发、两个传感器同时抖动。这些场景是AI生成代码最薄弱的环节，因为AI在训练数据里看到的基本都是理想流程，对现场那些奇奇怪怪的信号组合缺乏直觉。如果仿真里这些边界情况都能稳住，代码才算真正具备落地的底气。
3. AI Coding的规范与示例：生成代码的收口规则
3.1 没有规范的AI代码，就是一锅乱炖
每一个把AI编码用起来的人，最后都会撞上同一个问题：生成的东西能用，但风格千奇百怪。同一个电机启动逻辑，AI在A次生成里写成大平层嵌套if，在B次生成里又写成状态机；变量命名一会儿带前缀，一会儿裸奔。如果团队里每个人各用各的Prompt、各调各的AI，代码库很快会变成一锅乱炖。
我自己的项目就吃过这个亏。当时我让两个同事分别用AI生成同一个设备模块的代码，合代码的时候发现，一个用m_后缀表示电机，另一个用i_前缀表示输入，两个人在同一个程序单元里差点吵起来。这件事让我意识到，问题不在AI，而在于团队缺少统一的“收口规则”。
所以，引入AI编码的第一步，永远不是“挑选工具”，而是先定义清楚自己的“AI coding 代码生成规范示例”——我要什么风格的代码、什么命名习惯、什么注释标准、哪些写法绝对禁止。这份规范要细化到能直接写进Prompt的程度。规范越具体，AI输出越稳定，后续人工修改越少，这是线性相关的关系。反过来说，如果你连自己团队的代码规范都没想明白，那AI只会加速制造混乱。
3.2 我写进Prompt的“编码规范”清单
我在项目里沉淀了一套Prompt固定模板，每次生成代码都会附上这份规范清单。列在这里供大家参考，可以直接抄走，按自己团队的工程习惯修改：
- 命名规范：所有变量必须带类型前缀，b_表示布尔量、i_表示整型、r_表示实型、t_表示定时器、fb_表示功能块实例；禁止单个字母变量，禁止a1、temp_1这类无意义变量名。
- 结构规范：单个逻辑块超过10行必须拆状态机或用顺序控制段；禁止出现超过三层嵌套的IF；同一个输出线圈只允许在一个位置赋值，禁止双线圈。
- 注释规范：每个FC/FB开头必须有功能说明注释，包含输入输出定义、版本号、修改日期；关键赋值语句后必须跟一条工艺解释；严禁注释只复述代码。
- 安全规范：急停、安全门这类信号必须单独处理，不得嵌入常规逻辑流程；故障状态必须可复位、可追溯、有报警输出。
- 边界规范：所有传感器信号必须在逻辑入口做滤波或防抖处理；定时器必须考虑首次扫描初值；状态机必须有默认分支和异常分支；所有状态跳转必须有超时保护。
这套清单写成一段符合自然语言习惯的文字附在Prompt里，AI就能“读懂”。我实测下来，把规范写清楚之后，AI生成代码的一次性通过率提升非常明显。之前大概只有四成代码能直接进入修订流程，现在已经稳定到八成左右。剩下那两成，基本都是AI在边界条件和异常路径上的老毛病发作，还是得靠人脑兜底。
3.3 一次有规范和无规范的输出对比
用前面那个分拣气缸，给大家展示“有规范”和“没规范”的差距。没规范时，AI可能只输出这种简单版：
IF Start AND PartDetected THEN Cylinder := 1; END_IF; IF CylinderOutLimit THEN Cylinder := 0; END_IF;这段逻辑最核心的问题是完全没有状态概念。气缸伸出之后，如果传感器信号一直不消失，程序就永远卡在伸出状态；如果信号中途掉落，程序又会提前复位，动作时序完全失控。更严重的是，Cylinder这个变量在同一个扫描周期里被赋值两次，这是PLC里典型的双线圈风险，运行结果完全取决于扫描顺序。仿真环境里可能歪打正着，现场必定出问题。
有规范、有状态机的版本，就是我2.2节展示的那个样式。每一路输出都有明确的状态归属，有延时有超时，急停有独立分支，故障有复位路径。无规范版本可能在仿真里看着很正常，一上现场就掉链子；有规范版本虽然代码量大概是三倍，但每一行都能解释得通，现场出了问题也敢拍胸脯说不是程序逻辑的问题。
这个对比想说明一件事：AI代码生成本身并不难，难的是你愿不愿意花半小时，在生成之前把规范写清楚。这半小时的投入，后续通常会以二十小时省下来的调试时间作为回报。拿行业里一句老话讲，“磨刀不误砍柴工”，放在这里再贴切不过。
4. 实测中的翻车场景与排查心得
4.1 我遇到的三类典型问题
再完善的Prompt也不可能防住所有意外。这几个月的实测里，我至少踩过三类坑，复盘出来给大家避雷。
第一类叫上下文断裂。AI在生成一个上千行的FC功能块时，偶尔会在后半段忘记前面定义的变量和状态。表现出来就是变量名突然换了个风格，状态机分支在中间少了一条，前面定义的常量在后面根本没被引用。排查这种问题特别耗神，因为只能一行行跟着逻辑走。后来我强制要求AI分段生成，每200行暂停一次，先输出当前变量清单和状态清单再继续。这样上下文不会攒太多，AI的出错率明显下降。
第二类叫**“看起来合理但逻辑有害”**。这类最阴险，语法完全正确，快速浏览也发现不了问题，但细想就会发现是一个深藏的逻辑漏洞。我在某个安全联锁程序里遇到过，AI把急停信号写成了“取反后参与与逻辑”。从布尔表达式看，最后结果确实一致，可一旦输入信号本身异常，整条安全链路等于失效。编译和仿真都抓不出这种问题，只能靠人工对安全关键路径逐条核对。所以我后来的规定是：所有安全相关代码，AI只负责生成草稿，人工必须重写一遍，不允许直接采用。
第三类是项目专属逻辑缺失。AI根本不知道你们这个项目的特殊约定。比如我们有个老客户，所有报警必须带人工复位功能，报警触发之后即使故障消失，指示灯也要保持到操作员按下确认键。AI生成代码时默认报警随条件消失自动复位，跟客户习惯完全相悖。这类“团队隐性知识”AI无从了解，只能靠工程师把这些约定写进Prompt的固定模板里，相当于给AI做一层次项目级知识注入。
4.2 排查技巧与避坑指南
下面是这段时间积累的排查经验和避坑指南，不一定全是高深技巧，但基本每一招都实际救过我：
- 从编译信息反查变量表：AI代码编译报错时，先全局搜一遍变量名，大小写不一致或前缀写错占了报错的八成原因，而不是逻辑本身有问题。
- 用状态机视角读代码：如果程序是CASE结构的状态机，请先把状态跳转图画出来，然后人工把每个分支都走一遍。AI经常在“边界迁移”上偷懒，漏掉某个状态间的转换条件。
- 仿真不通过先查传感器抖动：AI对输入信号的防抖处理经常不写。仿真里行为异常时，十有八九是输入在临界状态反复跳变导致的。
- 别被注释带偏：AI写的注释只是它自己的理解，不是代码事实。怀疑某段逻辑有问题时，先忽略注释只看代码本身，确认实际行为之后再回头看注释要不要改。
- 大改不补丁：如果一段生成代码需要五处以上结构性修改，别打补丁了，直接重写或重新生成。在坏结构上修修补补，比重新生成多花一倍时间。
| 典型问题 | 表现 | 排查/预防方法 |
|---|---|---|
| 上下文断裂 | 变量名在前半段和后半段风格不一致 | 分段生成，每200行暂停并输出变量清单 |
| 布尔逻辑变形 | 急停取反、互锁错位 | 安全路径单独人工重写，禁止直接采用 |
| 双线圈赋值 | 同一输出多处赋值 | 编译警告必查，全局搜索输出变量 |
| 防抖缺失 | 仿真信号抖动时动作错乱 | 在Prompt中显式要求入口滤波 |
| 注释与代码不符 | 注释漂亮但代码行为不一致 | 读代码跳过注释，确认后再改注释 |
我特别想强调“大改不补丁”这条。工程上有个共识，修Bug的代价是随代码质量下降指数上涨的。AI生成代码的价值在于批量制造，为了保留AI的“原汁原味”去修一个千疮百孔的结构，完全没必要。重来生成的成本通常在几分钟以内，这是AI编码时代独有的“重来自由”。
5. 工具选型与团队落地判断
5.1 通用大模型与专用AI编码助手怎么选
我在整个体验过程中，把几类路径都跑了一遍，说说实际感受。
通用大模型，胜在语义理解全面。你给它一段工艺流程描述，它能推断出背后的控制需求；你在对话里补充传感器类型和动作顺序，它就能输出带互锁和状态机的代码。它对ST文本的生成能力出乎意料地扎实。缺点是它对你的项目代码库一无所知，涉及大量历史代码复用的时候，只能靠你手动把相关代码贴进上下文，效率会打折。
专用AI编码助手，像集成在编辑器里的那类，胜在能自动读取当前文件和仓库里已有代码，做跨文件补全、批量重构、单元测试生成都很顺手。但在PLC这个高度垂直的领域，它的训练语料本身偏少，生成的ST代码反而偶尔不如通用大模型灵活。你需要在Prompt里塞更多PLC背景知识，才能达到同等水准。
我给项目组的结论是两条腿走路：日常的零散代码生成、算法逻辑讨论、格式整理，用通用大模型；需要在既有工程仓库里做连续修改、跨文件重构、沿袭历史风格时，用专用编码助手。两个工具各有甜区，强行二选一都有点浪费。
不过有一点需要提醒：别让AI生成的代码绕过版本管理直接进控制器。不管用哪种工具，生成结果都必须走正常的代码评审和版本控制流程。AI只是把编写动作加速了，质量责任的链条一点都不能缩短。
5.2 哪类团队适合引入AI代码生成
最后聊一个管理层面的现实问题。不是所有团队现阶段都适合大范围切到AI编码上来。
第一个前提是现有的代码质量基础不能太差。如果代码库本来就是一团乱麻，变量命名随意、注释缺失、重复逻辑满天飞，那AI进来之后只会把这团乱麻复制得更多。因为AI默认会模仿你喂给它的上下文，你给它看的都是烂代码，它就给你生产更多烂代码。所以顺序不能反：先做代码规范化，再引入AI编码。
第二个前提是团队要有一套稳定的代码评审机制。AI生成代码的上限，取决于人类评审的上限。如果团队习惯“写完就跑”，AI高产只会加速制造技术债。反过来，有强评审机制兜底的团队，AI可以被放心地推上产能主力位置。
第三个前提，团队里至少要有一个人真正摸透AI编码在“这个项目”里的脾性。这个人不一定非是专家，但得明白哪些环节AI可靠、哪些环节AI不靠谱，能帮团队守住边界。说白了，这个角色承担的就是“踩坑先锋”的职能，把整套流程试错一遍之后，再给全团队铺路。
如果团队满足这三条，我的建议非常直接：挑一个中型模块，先完成一轮全流程试点，把规范、Prompt模板、评审机制都跑通，然后再逐步铺开。千万不要一开始就让所有人自由发挥。自由发挥的标准结局，是每个程序员都生成出一堆风格各异、同样难以维护的“AI异形代码”。
我个人在项目里的体会是，AI代码生成更像一把锋利的好刀，刀不会替你决定切什么，方向还是掌握在握刀人的手里。我能在PLC这种以保守和严谨著称的领域，借助它把重复劳动砍掉一半还多，说明这套打法的底层逻辑是通用的。如果你也正琢磨着把AI编码引到团队里，我的建议是，别把精力耗在纠结“用哪个工具”上，先挑一个小模块，把“规范—生成—人工评审—落地”这个闭环跑通。规范先行，人的判断兜底，AI的产能才能真正变成你的产能。
