1. 从“烟台方法”说起一套PLC标准化架构的由来“烟台方法”这个词在工控圈子里流传有些年头了最早是几位做非标自动化项目的工程师在烟台一带做项目时被同一个问题反复折磨后总结出来的一套编程架构思路。它的核心并不神秘说白了就是一句话把PLC程序里那些每次做项目都要重写一遍的东西抽出来做成标准件让工程师只关注真正变化的工艺逻辑。做过非标项目的人都懂那种痛。一个项目下来硬件选型、IO分配、报警处理、HMI交互、通讯配置这些活儿占了七成以上的时间真正跟工艺相关的核心逻辑可能只占三成。更麻烦的是每个工程师写出来的东西风格都不一样A写的程序B接手要重新读一遍项目一多维护成本直接爆炸。烟台方法要解决的就是这个问题——用一套统一的架构模板把重复劳动标准化把变化部分参数化。而“AI协同工作流”是这两年随着大模型能力提升被嫁接进这套架构里的新东西。它的定位不是让AI替你写完整程序而是让AI承担架构中那些有规律、有模板、有明确输入输出的环节比如根据IO表生成变量声明、根据工艺描述生成状态机骨架、根据报警清单生成报警处理逻辑。人负责判断和决策AI负责填充和转换这就是“协同”二字的真正含义。这篇文章适合谁看如果你正在做PLC非标项目被重复劳动拖得筋疲力尽如果你手上有多个项目并行想找一套能复用的架构如果你对AI辅助编程感兴趣但不知道在工控场景下怎么落地——那这篇内容应该能给你一些可以直接抄作业的思路。我不会讲太多虚的重点放在架构怎么搭、AI在哪些环节真正能帮上忙、以及我实际跑下来踩过的坑。2. 烟台方法架构的四层骨架与AI的切入点2.1 为什么是四层而不是三层或五层烟台方法把PLC程序分成四层硬件抽象层、设备控制层、工艺逻辑层、交互层。这个分层不是拍脑袋定的而是根据“变化频率”来划分的。硬件抽象层几乎不变设备控制层偶尔变工艺逻辑层每个项目都变交互层跟着工艺走。四层的好处在于AI的介入点非常清晰。硬件抽象层和设备控制层因为有大量重复模式最适合AI生成工艺逻辑层需要人的判断AI只能做辅助交互层介于两者之间AI可以生成框架人再调整细节。我试过三层分法把设备控制和工艺逻辑合并结果就是每次改工艺都要动底层代码风险太大。也试过五层把通讯单独拆出来但实际项目中通讯配置往往跟硬件绑定拆太细反而增加维护负担。四层是实测下来最顺手的粒度。2.2 硬件抽象层AI最该发力的地方硬件抽象层的任务是把物理IO映射成有意义的变量名让上层逻辑不用关心具体接的是哪个端子。传统做法是手动建变量表一个中型项目几百个点光命名就能耗掉大半天还容易出错。AI在这个环节的价值极大。你只需要把IO分配表Excel或CSV丢给AI附上一段命名规则说明它就能批量生成符合规范的变量声明。比如你告诉它“DI开头表示数字量输入后面跟设备编号和功能描述”它就能把“I0.0 1号电机运行反馈”转成“DI_Motor01_RunFb”。但这里有个坑AI生成的命名风格可能不统一。同一个设备它可能这次叫“Motor01”下次叫“Mtr01”。解决办法是在提示词里给几个示例让它照着示例的风格来。我一般会给5到10个典型命名作为参考这样生成结果的稳定性会高很多。2.3 设备控制层标准功能块库的建立设备控制层是烟台方法的核心资产。它把电机、阀门、气缸、变频器这些常见设备封装成标准功能块每个功能块有统一的接口使能、命令、反馈、报警、状态。上层调用时只需要实例化功能块传参就行。AI在这个环节能帮的是生成功能块的框架代码。比如你告诉AI“生成一个三相异步电机的控制功能块包含启动、停止、过载报警、运行反馈”它就能给出一个结构完整的FB。但要注意AI生成的代码在细节上往往有问题比如报警延时没加、手自动切换逻辑不完整、急停优先级没处理。这些必须人工补全。我的做法是让AI生成初版然后我对照自己积累的检查清单逐项过一遍。检查清单包括急停是否最高优先级、报警是否需要锁存、复位条件是否明确、手自动切换是否无扰。这套流程跑下来一个功能块的开发时间能从两小时压缩到二十分钟左右。2.4 工艺逻辑层与交互层AI辅助但不可替代工艺逻辑层是每个项目的灵魂这部分AI基本帮不上大忙。它需要理解工艺流程、设备联动关系、安全互锁条件这些信息往往在工程师脑子里或者散落在各种会议纪要里。AI可以帮你把自然语言描述的工艺转换成状态机骨架但状态之间的转换条件、异常处理、恢复逻辑必须人来定。交互层的情况类似。HMI画面布局、报警分级、操作权限这些涉及用户体验和操作习惯AI生成的方案往往“能用但不好用”。我一般让AI生成变量连接表和报警文本画面布局还是自己拖。3. AI协同工作流的具体落地环节3.1 从IO表到变量声明的自动化转换这是整个工作流里最成熟、最稳定的环节。具体操作流程如下第一步整理IO分配表。用Excel维护列包括地址、信号类型、设备编号、功能描述、信号方向、备注。这个表是后续所有自动化的基础必须保证准确。第二步写提示词。提示词的结构是角色设定 任务描述 命名规则 示例 输出格式要求。比如你是一名PLC编程工程师需要根据IO表生成变量声明。 命名规则 - 数字量输入DI_设备名_功能 - 数字量输出DO_设备名_功能 - 模拟量输入AI_设备名_功能 - 模拟量输出AO_设备名_功能 示例 I0.0 1号电机运行反馈 → DI_Motor01_RunFb Q0.0 1号电机启动 → DO_Motor01_Start 输出格式每行一个变量格式为“变量名 : 数据类型; // 地址 描述”第三步把IO表内容粘贴进去让AI批量生成。实测下来200个点的IO表AI生成时间大约30秒准确率在90%以上。错误主要集中在信号方向判断和功能描述理解上人工复核一遍即可。第四步导入编程软件。西门子TIA Portal支持从Excel导入变量表三菱和汇川也有类似功能。导入后检查地址映射是否正确特别是模拟量地址的偏移量。注意AI生成的变量名长度要控制在编程软件允许的范围内。TIA Portal的变量名最长128字符但实际使用中建议不超过32字符否则在HMI和SCADA里引用时会很麻烦。3.2 状态机骨架的AI生成与人工补全状态机是工艺逻辑层的核心。传统写法是用梯形图或SCL手写CASE语句一个复杂设备的状态机可能有十几个状态写起来很繁琐。AI生成状态机的流程先用自然语言描述设备的工作流程包括初始状态、启动条件、运行中的状态转换、停止条件、异常处理。然后让AI输出SCL格式的CASE语句骨架。比如描述“一个气缸的伸出缩回控制初始状态为缩回按下启动按钮后伸出伸出到位后延时2秒缩回缩回到位后完成一个循环”AI会生成类似这样的骨架CASE #State OF 0: // 初始状态 IF #StartBtn THEN #State : 10; END_IF; 10: // 伸出中 #SolenoidOut : TRUE; IF #CylOutFb THEN #State : 20; END_IF; 20: // 延时 #Timer(IN : TRUE, PT : T#2S); IF #Timer.Q THEN #State : 30; END_IF; 30: // 缩回中 #SolenoidOut : FALSE; IF #CylInFb THEN #State : 0; END_IF; END_CASE;这个骨架能用但缺了很多东西急停处理、超时报警、手动模式、状态复位。这些必须人工补。我的经验是AI生成的骨架能省掉60%的敲键盘时间但剩下的40%才是真正体现工程师水平的地方。3.3 报警处理逻辑的批量生成报警处理是另一个适合AI介入的环节。一个项目动辄几十上百条报警每条报警都需要触发条件、报警文本、报警等级、确认方式、复位条件。手动写这些逻辑非常枯燥。操作方式整理报警清单Excel列包括报警编号、触发变量、报警文本、等级、延时。然后让AI生成报警处理功能块的调用代码。烟台方法里通常有一个标准的报警处理FBAI只需要生成调用实例和参数赋值。这里有个细节要注意报警延时不能统一设一个值。有些报警需要立即响应如急停有些需要延时确认如液位波动。AI生成时如果不指定它可能全部用默认值。我的做法是在Excel里加一列“延时时间”让AI按列取值。3.4 HMI变量连接表的自动生成HMI变量连接表是PLC变量和HMI画面之间的桥梁。传统做法是手动在HMI软件里一个个建变量然后跟PLC变量做连接。一个中型项目几百个变量手动建表加连接一天时间就没了。AI可以生成HMI变量连接表的CSV文件格式符合HMI软件的导入要求。具体做法是让AI读取PLC变量表然后按照HMI软件的变量格式输出。西门子WinCC、威纶通、昆仑通态都支持CSV导入。但这里有个坑不同HMI软件对变量地址的格式要求不一样。WinCC用“DB块.偏移量”威纶通用“MW地址”昆仑通态用“寄存器地址”。让AI生成时必须在提示词里明确目标HMI软件的格式否则生成的结果没法直接用。4. 实测中踩过的坑与排查过程4.1 AI生成的变量名在SCADA里显示乱码这个问题困扰了我好几天。AI生成的变量名里包含中文描述导入SCADA后部分字符显示为乱码。排查过程如下先怀疑是编码问题检查了CSV文件的编码格式确认是UTF-8。然后怀疑是SCADA软件的字符集设置检查后确认支持中文。最后发现是AI生成时混用了全角和半角字符比如括号、冒号、逗号有些是全角有些是半角SCADA解析时出错。解决办法在提示词里明确要求“所有标点符号使用半角”并在生成后用脚本做一次全角转半角的清洗。这个坑让我意识到AI生成的内容不能直接信任必须有一道清洗工序。4.2 状态机骨架缺少状态复位导致设备卡死有一次用AI生成的状态机骨架做测试设备运行到某个状态后卡住不动了。排查发现AI生成的状态机在异常情况下没有复位路径。比如气缸伸出超时后状态机停在“伸出中”状态既没有报警也没有回到初始状态。这个问题暴露了AI生成代码的典型缺陷它只考虑了正常流程没有考虑异常流程。后来我在提示词里加了一条“每个状态都必须有超时处理和异常复位路径”生成质量明显提升。但即便如此人工复核仍然不可省略。4.3 报警文本长度超出HMI限制AI生成的报警文本往往比较详细比如“1号电机过载报警请检查电机负载和热继电器”。但有些HMI软件的报警文本有长度限制比如最多20个字符。超长的文本会被截断显示不完整。解决办法在报警清单Excel里加一列“短文本”专门用于HMI显示控制在15个字符以内。AI生成时同时输出长文本和短文本长文本用于SCADA和报表短文本用于HMI。4.4 功能块接口不统一导致调用混乱早期让AI生成功能块时没有严格规定接口格式结果AI生成的电机功能块和阀门功能块接口不一样。电机功能块用“Start/Stop”阀门功能块用“Open/Close”上层调用时很混乱。后来我制定了一套标准接口规范所有设备功能块统一使用“Cmd_Start”、“Cmd_Stop”、“Fb_Run”、“Fb_Alarm”、“Sts_Ready”这五个基本接口特殊设备再增加专用接口。把规范写进提示词后AI生成的接口就统一了。5. 让AI协同工作流真正跑起来的几个关键习惯5.1 提示词要像写需求文档一样认真很多人用AI辅助编程效果不好根本原因是提示词太随意。一句“帮我生成一个电机控制程序”AI只能给你最通用的东西没法贴合你的项目规范。我的做法是把提示词当成需求文档来写包含角色设定、任务背景、输入数据说明、输出格式要求、命名规范、示例、注意事项。一套好的提示词写下来可能有两三百字但生成结果的可用性能从30%提升到80%。而且提示词是可以复用的。同一个项目的不同阶段只需要改输入数据和少量参数提示词主体不变。我一般会把提示词存在文本文件里用的时候直接复制。5.2 建立自己的代码检查清单AI生成的代码必须经过检查才能用。我积累了一份检查清单每次AI生成后逐项过急停和故障复位逻辑是否完整手自动切换是否无扰报警是否锁存、是否需要确认状态机是否有超时和异常复位变量命名是否符合规范数据类型是否匹配地址映射是否正确这份清单是多年踩坑攒出来的每一条背后都有血泪教训。有了清单检查过程从“凭感觉”变成“按流程”效率和质量都稳定了。5.3 版本管理不能省AI协同工作流会生成大量代码和配置文件如果没有版本管理很容易乱。我的做法是用Git管理PLC程序源文件每次AI生成后提交一次提交信息写清楚“AI生成-变量表”或“AI生成-状态机骨架-人工补全急停逻辑”。这样做的另一个好处是当AI生成的结果有问题时可以快速回滚到上一个版本不会把项目搞乱。5.4 不要指望AI理解工艺这是最重要的一条。AI可以帮你写代码、生成表格、转换格式但它不理解你的工艺。它不知道这个气缸伸出之前必须确认安全门关闭不知道那个电机启动前必须等润滑油泵运行。这些工艺约束必须由人来定义AI只是执行工具。我见过有人试图让AI根据设备清单自动生成完整程序结果生成的逻辑完全不符合工艺要求改起来比自己写还费劲。正确的定位是AI负责“怎么写”人负责“写什么”。6. 这套工作流适合什么样的项目烟台方法加AI协同最适合的是中等规模的非标自动化项目IO点数在200到2000之间设备类型相对标准电机、气缸、阀门、变频器为主工艺逻辑有一定复杂度但不算极端。太小的项目比如几十个点的单机设备用这套架构有点杀鸡用牛刀直接手写更快。太大的项目比如整条产线的DCS系统涉及大量模拟量调节和复杂联锁AI能帮的比例反而下降因为工艺逻辑的占比太高了。另外这套工作流对工程师的基础能力有要求。你得懂PLC编程、懂工艺、懂HMI组态AI只是加速器不是替代品。如果基础不扎实AI生成的东西你看不出对错那反而危险。我在实际项目中的体会是这套工作流能把重复劳动压缩60%左右但前提是你愿意花时间搭建架构、写提示词、建检查清单。前期投入大概两三个项目的时间之后就能明显感觉到效率提升。如果你手上项目多、类型相似这套东西值得投入如果一年就做一两个项目可能直接手写更划算。