> ## 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 工程的四个台阶
- URL: https://www.hubwiz.com/blog/ai-operate-codesys-project-four-steps/
- Published: 2026-10-31T12:29:37.000Z
- Updated: 2026-10-31T14:09:11.000Z
- Description: AI 打不开 CODESYS 的二进制工程。真正要搭的是四级台阶：文本化、结构 CRUD、在线通道、工程内单测。
- Author: admin
- Tags: AI PLC 编程, CODESYS, 单元测试, 工业 AI

"让 AI 帮我改 PLC 程序"这句话之所以经常跑不通，原因往往不在模型，而在文件格式：CODESYS v3 里，代码住在工程文件内部——一个二进制文件。AI 没法打开它，更没法编辑它。

所以真正的工程任务不是"写一个好的提示词"，是搭楼梯。一位工程师（dev.to @zhouyongh）用五篇连载把这套楼梯拆成了四级：**先把工程变成文本，再让文本能改结构，然后给 AI 一条到控制器的在线通道，最后把验证放进 PLC 自己的扫描周期里**。环境固定为 CODESYS V3.5 SP17（部分篇目含 SP22）、SoftMotion Win 64、Windows + PowerShell 5.1。

下面按台阶顺序编译，并在最后给出我们的整理：这四级分别能证明什么、不能证明什么。

## 台阶一：把 POU 导出成文本，改完再导回去

第一步要闭合的环是 `工程 ⇄ 文本 ⇄ AI`：把选中的 POU（声明 + 实现）导出成纯文本，改文本，再导回工程。

作者给了三条约束，这三条决定了后面所有的设计：

- **CODESYS 必须始终是工程结构的唯一真相**——文本是工作副本，不是源头；
- **导入不能损坏已有工程**；
- **要小而可脚本化的工具，不要重的 IDE 插件**。

导入并不是"直接覆盖"。管线是四步：

1. **备份**——先快照；
2. **比对**——对函数体做 diff；
3. **写回**——设置 POU 代码；
4. **保存**——持久化工程。

这一版的能力边界写得很清楚：**只更新，不新建、不删除 POU**；声明与实现按 POU 配对；导入之后必须在 CODESYS 里重新编译验证。

![导出、编辑、导回的环](https://www.hubwiz.com/blog/content/images/2026/10/img_224021393abd0978fdd79e1ffb498789-800-1.jpg)

图 1：环很简单，纪律都在导入侧——备份、比对、写回、保存。（图源：原文）

![导出后的工程树](https://www.hubwiz.com/blog/content/images/2026/10/img_0494a2e6aed15a3fb52fbb1108bbbc7c-800-1.jpg)

图 2：POU 的声明与实现按层级落到文本目录里。（图源：原文）

## 台阶二：让文本能改"结构"，不只是改"函数体"

第二篇把工具从"只能编辑代码"升级成"能操作工程对象"——也就是 POU、DUT、GVL 的增删改查。这一步是质变：

- **新建对象**；
- **删除对象**；
- **重命名对象**；
- **同步声明与实现**。

同时纪律不变：写回前备份、应用前 diff、导入成功后保存。作者的原话是"让文本侧成为二进制工程的完整对等物（full peer）——AI 可以改结构，而不只是改函数体"。

这一层最容易被低估。改函数体是局部的；改结构会牵动**符号引用、任务绑定、HMI 变量连接、以及任何按名字找对象的地方**。所以"能改结构"必须配一套"改结构之后怎么证明没坏"的流程，这也是后面台阶四存在的理由。

![导入管线：备份、比对、写回、保存](https://www.hubwiz.com/blog/content/images/2026/10/img_8ddf2e578d57c2d7d32c77a21ccfe0e6-800-1.jpg)

图 3：结构级改动走同一条管线，只是 diff 需要看得懂对象级变化。（图源：原文）

## 台阶三：给 AI 一条到控制器的在线通道

前三篇解决了"AI 能改工程"，但这时代码还只活在工程里。第三篇把链路接到运行时，路径是：

**AI → Script Engine → soft PLC**

AI 负责规划动作，脚本引擎（CODESYS 内部的 IronPython）负责对运行时执行动作，soft PLC 跑应用。

四个能力：

| 步骤      | 做什么      |
| ------- | -------- |
| 连接      | 打开在线会话   |
| 下载      | 装载已编译的应用 |
| 启动 / 停止 | 控制运行状态   |
| 读 / 写   | 访问实时变量   |

三条注意事项很关键：**下载与运行是两个独立步骤**（下载完不等于跑起来）；**变量路径要按控制器的命名规则**（GVL / 程序作用域）；**仿真模式不需要真实硬件**，这让整套流程可以在笔记本上闭环。

![在线环：连接、下载、启停、读写](https://www.hubwiz.com/blog/content/images/2026/10/img_a60c8c8c2b1acbbaacc2b5fda17d1ddb-800-1.jpg)

图 4：这条链路一旦打通，"AI 说改好了"才有可能被真实变量证伪。（图源：原文）

![AI → 脚本引擎 → soft PLC](https://www.hubwiz.com/blog/content/images/2026/10/img_4b8be56420a8fd97189b9e8472aa6545-800-1.jpg)

图 5：AI 只出计划，真正碰控制器的是脚本引擎。（图源：原文）

## 台阶四：把单元测试放进 PLC 的扫描周期

这是整组文章里最值得抄的一篇。目标是一句话能说明的白话需求：**AI 自己写单元测试、导入工程、产出红绿报告**，并且能覆盖回归场景。

作者先把既有方案摊开比较，这张表比结论更有用：

| 方案                        | 测什么  | 仿真 / 真机 | 代价              |
| ------------------------- | ---- | ------- | --------------- |
| 主机侧 pytest 驱动读写           | 黑盒接口 | 两者皆可    | 断言离现场很远；时序不确定   |
| Matiec 离线编译检查             | 纯逻辑  | 不连运行时   | 覆盖不到轴控制与在线状态    |
| CoUnit / UniTest（库装进 PLC） | 白盒   | 两者皆可    | 要装库；社区库大多没人维护   |
| CODESYS Test Manager（3S）  | 白盒   | 两者皆可    | 商业授权；OEM 环境常受限  |
| 手写 ST 断言 + 主机收结果          | 白盒   | 两者皆可    | 协议自己维护；PLC 侧零依赖 |

他选了最后一条，理由四条：**断言和逻辑住在一起；PLC 侧零依赖；主机拿到统一的结果流；设计仿 xunit**。

机制本身不复杂，但每个细节都踩过坑：

- 测试代码就是普通 ST，**和应用一起编译、一起下载**；
- 断言与被测逻辑**在同一个扫描周期、同一批变量上跑**；
- 套件通过 `PRG_Tests` 挂到一个循环任务上；
- 每个用例按 **Setup → 断言 → TearDown** 执行；
- 断言把结果写进 `GVL_Test` 的用例表；
- 所有套件跑完，置一个 **done 标志**；
- 主机轮询 done，读计数与用例明细，生成报告。

xunit 概念的映射也很直接：**suite → `FB_<Unit>_Test` 功能块；test → 套件上的 `Test_*` 方法；assert → `ass.AssertEquals_*` / `AssertTrue` 这类调用；fixture → Setup / TearDown 加上套件的 VAR**。

两个具体的坑：`PRG_Tests` 必须挂在循环任务上；`g_uiSuitesTotal` 必须与套件数量一致，否则 done 永远不来。另外还有安全提醒：**不要把口令写进脚本**，用 `-UserFile` 或环境变量。

![测试代码与应用一起编译；断言与逻辑同周期](https://www.hubwiz.com/blog/content/images/2026/10/img_4e653dd76a4983bca806c29a58e7a732-800-1.jpg)

图 6：白盒断言的代价是它真的跑在你的扫描周期里——这是优点，也是预算。（图源：原文）

## 附：主机 / 控制器的最小闭环

另有一篇把搭建过程写成"你真的能跑起来"的版本：主机 PC 与 soft PLC（CODESYS Control Win）通信，应用暴露轴和变量，主机负责启停与数据交换。

设备侧：新建标准工程，加 SoftMotion Win（或 Control Win），定义程序与轴对象，编译下载。示例里用的是 `FB_SimAxis`——它解析命令并对位置做斜坡，**动作在程序里是真的，"轴"是仿真的**。这句话很重要：在碰硬件之前，用它证明"主机 → 控制器 → 运动指令 → 状态回读"这条环是通的。

![主机与控制器闭环](https://www.hubwiz.com/blog/content/images/2026/10/img_7d9d4e5e165f824ac92468b23b1549c8-800-2.jpg)

图 7：四层台阶最终要落在这条环上，否则"AI 改好了"无法被验证。（图源：原文）

## 编者补充：这四级台阶各证明什么

原文是工程师的操作笔记，短、直接、没有论证。我们把它放回工程语境，给出四条判据——**每一层只能证明一件事，别把上一层当成下一层。**

**第一级（文本化）证明的是"改动可 diff"。** 备份 + 比对 + 写回 + 保存这套四步，本质是把"不可见的二进制改动"变成"可审阅的文本差异"。没有 diff，AI 的改动就只能靠人眼在 IDE 里翻，那等于没有评审。

**第二级（结构 CRUD）证明的是"工程能自洽"，不证明"程序还对"。** 重命名一个 POU 之后，编译器仍然可能通过，但 HMI 上绑定的变量已经断了。这类断裂只有两种东西能抓：引用检查，或者端到端跑一遍。**能改结构之后，验证预算必须同步变大。**

**第三级（在线通道）证明的是"能把结论送到真实变量上"。** 这是 AI 参与 PLC 工作的分水岭：改完能下载、能启停、能读写，才谈得上"验证"。但注意脚本引擎本身是**任意代码执行**——IronPython 在 CODESYS 进程里跑，等于给 AI 一把能开工程和运行时的钥匙。这层必须配权限边界和操作日志，不能只靠提示词约束。

**第四级（工程内单测）证明的是"逻辑对不对"，不证明"现场对不对"。** 断言与被测逻辑同周期跑，好处是确定性高、时序真实；代价是测试代码会占用扫描时间，而且只能覆盖你写出来的用例。它替代不了编译检查、替代不了仿真、更替代不了现场调试。

拿我们站内已有的验证框架对照，这四级正好卡在中间两层：

| 层              | 能证明            | 不能证明       |
| -------------- | -------------- | ---------- |
| TIA/CODESYS 编译 | 语法、类型、引用在工程内自洽 | 逻辑是否符合工艺   |
| 工程内单元测试（本篇）    | 给定输入输出下逻辑正确    | 时序、硬件、现场工况 |
| 云仿真 / 虚拟 PLC   | 扫描周期、状态机、联锁    | 真实 I/O 与干扰 |
| 现场调试           | 一切真实的东西        | 只在这一次工况下成立 |

对做西门子主线的读者，这套思路可以平移：博途侧对应的"文本化"入口是 SCL 源文件的导入导出，以及 Openness 的接口；差别只在脚本引擎换成了外部驱动。站内[AI 改博途程序的写保护与边界](https://www.hubwiz.com/blog/tia-portal-openness-mcp-write-guards/)讲的是同一件事的另一半——**写之前先设护栏**，这篇讲的是**写之后怎么证明没写坏**。

**边界**：原文是个人实操连载，不是评测。五篇都是短笔记，没有成功率、耗时、成本这类数据；"AI 写单测"能否稳定产出可用用例，文中没有量化证据。作者的示例是仿真轴与 soft PLC，不能直接外推到真机与安全功能。涉及安全相关程序时，仍按内部规程与变更流程执行。

**来源**： - 《CODESYS AI Practice — Import/Export Files》 https://dev.to/zhouyongh/codesys-ai-practice-importexport-files-18j7 - 《CODESYS AI Practice — Project Sync》 https://dev.to/zhouyongh/codesys-ai-practice-project-sync-4jea - 《CODESYS AI Practice — Online Connection》 https://dev.to/zhouyongh/codesys-ai-practice-online-connection-25f9 - 《CODESYS AI Practice — Unit Testing》 https://dev.to/zhouyongh/codesys-ai-practice-unit-testing-h11 - 《CODESYS Applied Practice — Host/Controller Closed Loop》 https://dev.to/zhouyongh/codesys-applied-practice-hostcontroller-closed-loop-5edk （均为 2026-10-31 发布；正文图片来自原文，已转存至站内）

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

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