> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI PLC 编程：99% 成功率在这个行业算灾难
- URL: https://www.hubwiz.com/blog/ai-plc-programming-tia-portal-what-works/
- Published: 2026-10-30T15:10:58.000Z
- Updated: 2026-10-30T15:59:51.000Z
- Description: 51 页图纸 11 分钟出 I/O 表；但 99% 成功率在这行等于灾难。卡住的从来不是模型，是流程。
- Author: admin
- Tags: 工业 AI, PLC, 博途, TIA Portal, 自动化

一张 51 页的接线图 PDF 交给 AI，11 分钟后回来一张 I/O 清单，再往下变成博途里的变量表。

这是 Prybisch Automation 在自己项目里量到的一个步骤。他们把它写进文章时补了一句：结果仍然要人工对着图纸核一遍。

同一篇文章里还借了 r/PLC 论坛一位工程师的话："在我们这行，99% 的成功率就是灾难性失败。"

两句话放在一起，就是这篇源文的态度：AI 在博途里确实能干活了，但能不能用不取决于模型多强，取决于外面那圈流程有多硬。作者 David Prybisch 在卢森堡做西门子自动化，写 PLC 十二年、在工业现场二十年，他用自己交付的项目来说明这件事。

## 两种"AI 碰过 PLC 代码"的方式

大多数人说的"AI 和 PLC"，是一个聊天窗：描述任务，拿到一段 SCL，粘进工程。小函数够用，整厂程序不够——模型不知道这个工程长什么样，不编译，也不测试。代码能不能套进现有的数据类型、块接口和命名习惯，还是得靠程序员自己看。

另一种是直接待在工程工具里的 agent：它知道工程结构，拿得到编译器的反馈，还能照着反馈动手。区别不在于它更聪明，而在于它在工程里干活，不是在工程旁边递代码。

**我们的整理**：源文把"AI 进工程"卡在这半句话上——agent 要知道工程结构、要吃得进编译器的报错。这两件事都不靠模型变聪明，靠一层桥。我们做的 TiaLink 就是这层桥：装在博途同一台机器上（V19 / V20），把读块树、建块写 SCL、编译、下载到仿真、读回核对变成一组标准接口，任何支持该协议的 AI 客户端都能接，工程数据不出内网。对照后面第四节那五条规矩，我们只做到块这一级：写入前先预览、按块绑定而不是整工程覆盖、不做 PLC 启停，安全回路仍归工程师。差别不在能力表——他们用 AI 交付项目，我们只交付这层通道，验收的责任还是人的。

## 一个项目里的五个动作，顺序固定

他们的每个项目走同一套顺序：

1. **功能规格书先行**。写任何代码之前，先有一份和你确认过的功能设计规格（FDS）。后面所有事情都拿它当尺子。
2. **生成并编译块**。算数和数据处理写 SCL，联锁逻辑写 FBD，然后编译整个工程。编译器报错，块打回重做。
3. **按规格评审**。逐块对着 FDS 问两件事：说到的功能都实现了吗？有没有做 FDS 没要求的事？
4. **仿真里做功能测试**。程序跑在仿真控制器上，每次改动都能重跑一遍。
5. **操作员级测试**。对着仿真 PLC 操作 HMI：按按钮、确认报警、改设定值，看反应对不对——按操作员以后真实用法来测。

HMI 不是另起一遍活。WinCC Unified 的画面、报警、变量从块和数据类型派生出来，把老的 Comfort Panel 项目迁到 Unified 也走同一条路。

值得单独说的是前期功夫。图纸 PDF 里的接线信息，agent 拆成 I/O 清单，再生成变量表——51 页的图纸集，大约十一分钟。这一步以前按天算。但作者没有把它包装成"自动化"：结果照样要对着图纸核。

## 老厂：没有符号的代码，也能重新变成文档

收益最大的地方常常不是新厂。很多 S7-300 跑了二三十年，程序只以在线上传的形式活着：STL，没有符号，没有注释，M 位和 DB 全是裸地址。要改造，第一步是先搞清它到底在干什么。

agent 逐块读，跨块追信号，反推出一份功能规格。这里有一条最硬的规矩：每句结论都要有证据，指向代码里的位置或文档里的位置；指不出来的，写进文档当成待确认问题，去现场或问操作员。不许拿"看起来合理"填坑。

新程序从这份规格重建，迁移优先用 FBD / LAD——在线时维护人员一眼能看出少了哪个条件。

这也是他们处理 S5、S7-300 改造和 CODESYS 迁博途的通用路线。顺带一个判断：老厂的难点从来不是"写新代码"，是"证明你读懂了旧代码"。

## 五条不许破的规矩

控制程序里的错误不是外观问题。作者的原话是"五条规矩，无一例外"：

| 规矩           | 落到哪一步                                             |
| ------------ | ------------------------------------------------- |
| 没有功能规格书就不写代码 | 没有约定过的 FDS，结果是拿什么去比对的都没有                          |
| 每个块都要在仿真里测过  | 没经过仿真测试的块不交付                                      |
| 安全归工程师       | 安全相关代码由工程师本人写，按常规方法验证                             |
| 现场调试归工程师     | 下载到真实 CPU、测自动模式、测 HMI、测安全功能，直到设备按预期运行；agent 永不上现场 |
| 老厂里证据是强制的    | 没证据的一律算未知，不算结论                                    |

第四条是整篇里最不像营销的一句话：**An agent never works on the plant。** 它把 AI 的作用范围钉死在"上现场之前"。

前面那句 99% 的说法，正是这几条规矩的来由。制造业里讲合格率，99% 是个体面的数字；放到控制程序上，一百次动作错一次就是撞机、喷料、伤人。所以这套流程不是为了让 AI 更可信，是为了让"哪一次会错"这件事在进现场之前就暴露出来——编译、评审、仿真、操作级测试，四道关口每一道都在把不可见的错误变成可见的报错或失败的用例。

## 提的是质量，不只是速度

讨论 AI 时大家先算省了多少时间。作者说对客户更重要的往往是另一件事：被检查的东西变多了。

**测试变多。** 很多常规项目里，测试集中在调试期做，时间紧、在设备上做。仿真测试可以每次改动都重跑，于是"以前好好的"不会悄悄坏掉。

**前期功夫有人接。** I/O 清单、变量表、报警文本吃掉大量工程小时，这些小时本来该花在真正的控制逻辑上。agent 接手打字之后，时间回到需要经验的问题：断线了会怎样？断电之后设备怎么重启？

**文档和程序同源。** FDS、程序、HMI 来自同一个源，程序改了，文档在同一批里更新，而不是项目收尾时凭记忆往回补。

他们明确拒绝给整体节省比例。单步（I/O 表）能测，整项目取决于工厂、手里有什么文档、旧代码烂到什么程度——这句话比任何百分比都可信。

## 买家在担心什么，能答什么

德国数字产业协会 Bitkom 的《Künstliche Intelligenz 2025》调查了 604 家企业，把障碍排出来：法律不确定性 53%、数据保护 48%、担心数据落到错的人手里 39%、缺可追溯性 38%、结果质量 36%。机械制造业口径接近：VDMA 的 144 家受访企业里，39 家提到数据访问与责任这类法律问题。

这些顾虑是正当的，所以作者逐条给答案：

| 顾虑         | 他们的回答                             |
| ---------- | --------------------------------- |
| 法律不确定、责任在谁 | 责任在交付程序的工程师，不在工具；和编译器、块库、代码生成器一样  |
| 数据保护、数据落错手 | 不用你的数据训练模型，工程留在自己系统里，数据路径在项目开始前约定 |
| 不可追溯       | 有约定过的 FDS、按 FDS 的评审记录、仿真测试结果      |
| 结果质量       | 每次交付前四道：编译、评审、功能测试、操作员级测试         |

## 项目数据到底怎么处理

一份博途工程里有整套工艺 know-how，所以他们的做法是固定五条：

- **不拿你的数据训练模型。**
- **用自己的系统，不用公共聊天工具。** 工程存在自己的机器上，不复制进公共对话。
- **数据路径先约定。** 哪些文档进 AI 处理、哪些不进，开工前说清楚。
- **尽量脱敏。** 公司名、厂名这类可识别信息，在不影响工作的前提下替换或删掉。
- **需要就签 NDA。**

作者补了一句边界：这不是法律意见，替代不了你自己那侧的法务审查。

## Eigen：它是工具，不是服务

2026 年 4 月 20 日，西门子把 Eigen Engineering Agent 正式发布，接替原来的 Industrial Copilot for Engineering，定位是 PLC 编码、HMI 可视化、设备组态三块。它需要博途 V19 / V20 / V21 和一个 Industry Organization Account，按年订阅，一个席位可以分给三名用户。

对有自己的博途程序员的部门，这是合理的工具：环境熟、出自 PLC 厂家、由厂家维护。但要看清它是什么——**给"自己写程序的人"用的工具**。功能规格、测试、验收和责任都还在用户这边。

有两件事必须放进评估：

- **它从 V19 起。** S5 和 STEP 7 Classic 的老厂比这更早，而这些老厂恰恰就是"只剩一份没符号的在线上传"的那些厂：得先把程序读懂、重建，才谈得上用工具。
- **工具不增加产能。** 没有自己的程序员，或者腾不出人，需要的是服务，不是一个新工具。

两者并不互斥：小改动自己用 agent，大项目外包，是常见组合。西门子这条路线的取舍，我们此前单独拆过一遍，见[《西门子 Eigen：官方 AI Agent 能替工程师做到哪一步》](https://www.hubwiz.com/blog/siemens-eigen-engineering-agent/)。

## 问承包商五个问题

判断一个供应商是不是负责任地用 AI，五个问题够了。答案要具体，不要让人安心：

1. 开工前有没有和我们确认过的功能规格书？
2. 程序上现场之前怎么测，我们会拿到哪些测试结果？
3. 安全功能谁写、谁验证？
4. 我们的工程数据存在哪，会进公共聊天工具吗，会被拿去训练吗？
5. 谁在现场调试，谁测自动模式、HMI 和安全功能，结果谁负责？

如果答案都很含糊，通常意味着那套让 AI 输出"可验证"的固定流程根本不存在。第 1、2、5 题还有个特点：不用 AI 的承包商也应该答得上来。

## 源文自问自答的七个问题

**AI 能在博途里写 PLC 程序吗？** 能，前提是嵌在固定流程里。直接在博途里干活的 agent 能生成 SCL 和 FBD 并编译工程；可靠的前提是有一份约定过的 FDS 当尺子、按 FDS 评审、在仿真里做功能测试。从聊天窗粘代码进工程的那条路做不到这些，因为它既不知道工程，也不编译、不测试。

**Eigen Engineering Agent 是什么？** Industrial Copilot for Engineering 的后继产品，2026 年 4 月 20 日起正式可用，定位是 PLC 编码、HMI 可视化、设备组态。需要博途 V19 / V20 / V21 和一个 Industry Organization Account，按年订阅、一席三人。它是给自有程序员的公司用的工具，不是服务。

**AI 该写安全相关的 PLC 代码吗？** 在他们的项目里不写。安全代码由工程师本人编程、按常规方法验证；agent 负责标准逻辑、前期功夫、测试和文档。最后跑在控制器里的，是一段普通的、确定性的程序，里面没有 AI。

**AI 生成的代码在上现场之前怎么测？** 两阶段。先在仿真控制器上跑功能测试，每次改动都能重跑；再对着仿真 PLC 操作 HMI，按操作员以后真实用法测。之后是工程师本人做现场调试：下载到真 CPU、测自动模式、测 HMI 和安全功能，一直到设备按预期运行。

**承包商用了 AI，我们的工程数据会怎样？** 这件事要在开工前说清。在他们的做法里：数据不用于训练模型，工程存在自己的系统上、不进公共聊天工具，哪些文档进 AI 处理提前和你约定，可识别信息尽量脱敏，需要就签 NDA。

**没有文档的老 S7-300 能用 AI 吗？** 这是它最有用武之地的地方。逐块读没有符号的 STL、跨块追信号、反推功能规格；关键仍然是强制证据——每句结论指向代码或文档位置，证不出来的一律留作待确认。新程序就建在这个基础上。

**AI 写的代码出错了谁负责？** 检查和交付程序的那个工程师，不是工具。编译器、块库、代码生成器也是这么算的。工程合同里应该写明使用了 AI，责任与担保按合同走。

## 结论：流程比模型重要

AI 写 PLC 程序在博途里已经能实用。它是帮忙还是添风险，取决于外面的流程：写码前有 FDS，上现场前有仿真，安全握在工程师手里，现场调试由工程师亲自做到底。

作者公司自己的形态也说明了这一点：一个经验丰富的工程师，配一套练熟的 agent，agent 承担前期功夫、测试和文档，决策与责任留给人。反过来说，如果一个团队既没有 FDS 的习惯，也没有仿真的习惯，那么引入任何 AI 工具都只是把不确定提前了一步——代码出得更快，问题出得更晚，现场调试的时候才炸。

**我们的整理：这份经验里能拿走的三样东西**

- **把"证据"写进流程，而不是写进口号。** "每句话指向代码或文档的位置，指不出来就是待确认问题"——这条规则可以直接搬到任何一次 AI 介入的改造项目里，代价只是多一列备注。
- **用"agent 永不上现场"划边界。** 它比"AI 辅助"这类说法清楚得多：范围一刀切在仿真之后，责任归属自然就清楚了。同样的边界我们在写保护那篇里拆过：只做块级写、先预览、不做 PLC 启停。
- **别急着报节省比例。** 单步可测，整项目不可测。谁给你一个漂亮的整体百分比，谁大概率没量过。

**边界，别把它当成行业结论**

- **这是厂商自述。** 作者是卖工程服务的，文章顺手在卖"我们有流程"，所有效率数字都出自他们自己的项目，没有第三方复核。
- **单人单团队经验。** "一个工程师 + 一套 agent"是他们的组织形态，不等于任何规模都能照搬。
- **时间数据只有一个点。** 51 页图纸 11 分钟是单步、单例，没有分布、没有失败样本。
- **Eigen 的版本与许可要求以西门子官方页面为准。** 本文按源文 2026-10-26 的表述转述，产品更新很快。
- **安全结论不适用于所有地区。** 安全功能"工程师本人写、按常规验证"是他们的项目纪律，不是法规解读；具体项目要按所在地区的机械安全与功能安全要求执行。

**站内几条接得上的线**

- [AI 改博途程序：TIA Openness MCP 的写保护与边界](https://www.hubwiz.com/blog/tia-portal-openness-mcp-write-guards/)——本文第四节"agent 永不上现场"在工具侧的对应：只读/读写分层、预览、审计留痕。
- [接手遗留 PLC 程序的 4 步取证](https://www.hubwiz.com/blog/taking-over-legacy-plc-program-4-steps/)——第三节那些"没有符号的 STL"具体怎么取证、怎么建基线、怎么验证根因。
- [AI PLC 编程：7 个免费实战课，每课都能验收](https://www.hubwiz.com/blog/ai-plc-programming-7-lessons-verification/)——把"仿真里测过才交付"拆成七节可以自己跑一遍的课。

想让 AI 在自己的博途工程里读块、写块、编译、跑仿真，可以先看 [TiaLink](https://tia.hubwiz.com/tia-link?utm%5Fsource=blog&utm%5Fmedium=article&utm%5Fcampaign=ai-plc-programming-tia-portal-what-works)：本机网关，工程不出内网。

**来源**：David Prybisch，《AI in PLC Programming: What Works in TIA Portal Today》，Prybisch Automation，2026-10-26。原文链接：[https://prybisch-automation.eu/en/blog/ai-plc-programming](https://prybisch-automation.eu/en/blog/ai-plc-programming?ref=hubwiz.com)。五步流程、51 页图纸 11 分钟、五条规矩、Bitkom（604 家企业）与 VDMA（144 家）数据、Eigen 的版本与许可要求、五个承包商问题均出自原文；两张对照表、"我们的整理"与"边界"为我们整理，非原文内容。原文头图为流程示意图（FDS → 仿真 → CPU），封面按站内规则改用图库实拍。

本文由汇智网编译整理，转载请注明出处。

> **这是「AI × 工业 / PLC」专题的一部分。**完整地图见：[AI × 工业 / PLC 完全指南](https://www.hubwiz.com/blog/ai-industrial-stack/)