AI 进 PLC 工程的两条路：从机器需求，还是从工具链编排
一家让 AI 从机器需求写 ST，一家让 AI 编排整条工具链。同一周两条路，验证责任都还在工程师身上。
2026 年 10 月，两家自动化厂商把 AI 放进了 PLC 工程的两个不同位置。Unitronics 装在"起点"：工程师用自然语言描述机器要做什么，工具生成结构化文本。Rockwell 装在"上层"：自然语言发起一个工程任务，由多个 agent 跨工具去执行。
先把这个坐标补全。第一波 AI 进 PLC 工具的形式是副驾——2024 年 11 月 TIA Portal V20 发布时，Siemens Industrial Copilot 的定位就是"简化编程任务、加速排障"（这是 2024 年的发布，不是本周新闻，写在这里只是为了说明这条演进线的起点）。两条新路的区别在于：一个替换掉"从空白工程开始写"，一个替换掉"在多个工具之间搬运上下文"。
路一：Unitronics —— 从机器需求直接生成 ST
Unitronics 把 AI 辅助工作流嵌进了 UniLogic——它的 PLC 控制、运动与 HMI 编程环境。这个功能叫 UniLogic AI Wizard，官方口径是"帮助工程师从机器需求走到 UniLogic 兼容的 IEC 61131-3 结构化文本，用你自选的 AI 模型，不需要从零写复杂提示词"。
流程是这样的：不是打开一个空白编程界面，而是先用自然语言描述机器要做什么；UniLogic 整理需求、从当前工程里补上相关信息、应用 UniLogic 自己的编程规则，然后自动生成一份结构化的"工程请求"，交给工程师选定的 AI 平台。
向导会问三件事：机器的动作顺序、控制方式、以及相关的安全考虑。工程师可以从当前工程里挑 I/O、标签、数据结构一起打包进请求。
这一层的价值不在"生成代码"，而在把平台上下文塞进去。原文说得很直白：通用 AI 工具也能写结构化文本，但它们不知道某个自动化平台支持哪些数据类型、函数、结构体和编程约定；AI Wizard 是在请求抵达模型之前补上这些工程上下文。
产出物可以是：完整 ST 应用、单个 ST 函数、对现有逻辑的修改、代码审查与问题识别、注释与工程文档，以及把第三方代码转换成 UniLogic 兼容 ST。生成结果里可能包含变量、枚举、结构体、函数、状态机和注释。
边界写得比多数厂商清楚：
- 它是工程助手，不替代工程判断、测试、调试与机器安全流程；
- 生成的逻辑必须经过复核、测试、验证才能上线；
- 导入后会标出假设、占位符和需要注意的项；
- 官方直接定性："这不是自主机器编程。"
CEO Amit Harari 的说法是这套设计的出发点："AI 不该是坐在工程软件旁边的另一个黑盒。它需要目标平台的上下文——架构、规则、工程结构。"
图 1：向导把需求、工程上下文与平台规则打包成"工程请求"，再交给模型。（图源：Unitronics / IEN Europe）
路二：Rockwell —— 从"编排"入手，让 agent 跨工具干活
Rockwell Automation 在 2026 年 10 月 21 日发布 FactoryTalk Conductor，定位是"AI 原生的编排平台"：协调跨工业自动化生命周期的 AI 工作，从系统设计、开发到运行维护。它会在波士顿的 Automation Fair 2026 上首次公开展示，计划 2027 年第一季度商用。
能力口径：用户用自然语言发起工程任务，平台把完成任务所需的软件、AI 能力和工作流接起来。首发集成四个工具——Studio 5000 Logix Designer、Logix Echo、Emulate3D、FactoryTalk Optix，覆盖设计、开发、仿真与测试；后续计划接入 FactoryTalk Design Studio、FactoryTalk Historian、Plex、Fiix。
治理与模型选择上有两个具体安排：可以走 FactoryTalk Hub 托管的 AI 服务，也可以接客户偏好的大模型或小模型，包括本地部署的开源权重模型（官方给的理由是降低持续的 token 消耗成本）；同时提供"Rockwell 验证过的 agents 与 skills"，客户也可以自建。
Rockwell 软件与控制高级副总裁 Matheus Bulho 的说法是："把 AI 编排和可信的工业经验结合起来。" ARC Advisory Group 副总裁 Craig Resnick 的判断更直白："工业 AI 的下一阶段由编排定义，而不是单个 copilot。"
Rockwell 还引用了自家《2026 智能制造状况报告》的数字：三分之一的制造运营已经在使用 AI 增强。
值得注意的是它自问自答里的那条界线——"Conductor 与 AI copilot 有什么不同？"官方答案是：copilot 辅助单个任务，Conductor 让多个 agent、工作流与软件工具协同，从而把跨应用、跨数据源、跨团队的多步骤活动自动化。换句话说，它卖的不是"写得更快"，而是"把搬运上下文这件事交出去"。
两条路的对照
| 维度 | Unitronics（AI Wizard） | Rockwell（Conductor） |
|---|---|---|
| 入口 | 空白工程之前：机器的动作顺序、控制方式、安全考虑 | 工程任务的发起层：一句自然语言任务 |
| 输入 | 需求描述 + 当前工程的 I/O、标签、数据结构 + 平台规则 | 任务描述 + 跨工具现状（设计、仿真、HMI） |
| 产出 | IEC 61131-3 ST：变量、枚举、结构体、函数、状态机、注释 | 跨工具的编排结果：agent 调用、工作流推进 |
| 明确边界 | 不替代判断/测试/调试/安全流程；标出假设与占位符 | 商用时间 2027 Q1；agent 与 skills 需"验证过" |
| 可用状态 | 已嵌入 UniLogic | 2026 年 10 月首秀，2027 Q1 商用 |
| 主要风险 | 生成物看起来合规、语义不符工艺 | 编排层出错时，错误会跨多个工具传播 |
编者补充：三条判据
两家都是厂商口径，本文不做能力评价，只给三条能用来判断"这套东西在我这能不能用"的判据。
判据一：产出物能不能 diff、能不能回滚。 生成一段 ST 比较容易，难的是三个月后有人问"这段逻辑是谁、基于什么改的"。Unitronics 的做法是在导入后标注假设与占位符，这已经比"直接贴进工程"好一档；但更硬的要求是生成物进入版本管理——文本可 diff、可回滚，才能进变更流程。这一条恰好是工程侧最容易被跳过的地方。
判据二：假设是否显式。 需求描述里没写的（量程、单位、失效安全方向、异常恢复策略），模型只能猜。凡是猜出来的部分都必须以"待确认"的形式出现在工程师眼前，而不是埋在代码注释里。站内AI 改博途程序的写保护与边界里那条"预演—验证—回滚"就是这个道理的另一半。
判据三：模型调用是否留痕、是否可换。 Rockwell 允许接自选模型（含本地开源权重），这一点在受监管行业比"能力多强"更重要——模型可替换意味着你不被单点锁定，本地部署意味着数据不出厂。但随之而来的是新的问题：换模型之后，同一段提示还会给出同一个结果吗？这需要回归集，而不是"感觉差不多"。
把两条路放进我们的验证框架看：
| 层 | 能证明 | 不能证明 |
|---|---|---|
| 编译（工具自带） | 语法、类型、引用自洽 | 逻辑符合工艺 |
| 工程内单元测试 | 给定输入下逻辑正确 | 时序与真实 I/O |
| 仿真（Emulate3D / 软 PLC） | 状态机与联锁走通 | 现场工况 |
| 现场调试 | 真实的一切 | 只在这一工况成立 |
生成式工具把第一层变得很便宜——便宜到容易让人以为过了第一层就等于能上线。真正没变的是后面三层。
边界：本文编译两家的公开材料（一为厂商赞助内容，一为新闻稿），没有任何第三方实测数据；能力描述、集成清单、可用时间均为厂商陈述，其中 Rockwell 的商用时间是计划值。涉及安全相关程序、现场调试与停机窗口的改动，请按内部规程与变更流程执行。
来源： - Unitronics,《Unitronics Uses AI to Take PLC Logic from Machine Requirements to Code in Minutes》, IEN Europe，2026-10-19（Automation.com 于 2026-10-26 收录同题） - Rockwell Automation,《Rockwell Automation Introduces FactoryTalk Conductor, an AI-Native Orchestration Platform for Industrial Automation》, PR Newswire，2026-10-21 - 背景：Siemens,《A new version of our engineering platform》(TIA Portal V20 / Industrial Copilot)，2024-11-18
本文由汇智网编译整理，转载请注明出处。
这是「AI × 工业 / PLC」专题的一部分。完整地图见：AI × 工业 / PLC 完全指南
