代码锁在二进制里：AI 改 PLC 工程的四个台阶
AI 打不开 CODESYS 的二进制工程。真正要搭的是四级台阶：文本化、结构 CRUD、在线通道、工程内单测。
"让 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 插件。
导入并不是"直接覆盖"。管线是四步：
- 备份——先快照；
- 比对——对函数体做 diff；
- 写回——设置 POU 代码；
- 保存——持久化工程。
这一版的能力边界写得很清楚：只更新，不新建、不删除 POU；声明与实现按 POU 配对；导入之后必须在 CODESYS 里重新编译验证。
图 1：环很简单，纪律都在导入侧——备份、比对、写回、保存。（图源：原文）
图 2：POU 的声明与实现按层级落到文本目录里。（图源：原文）
台阶二：让文本能改"结构"，不只是改"函数体"
第二篇把工具从"只能编辑代码"升级成"能操作工程对象"——也就是 POU、DUT、GVL 的增删改查。这一步是质变：
- 新建对象；
- 删除对象；
- 重命名对象；
- 同步声明与实现。
同时纪律不变：写回前备份、应用前 diff、导入成功后保存。作者的原话是"让文本侧成为二进制工程的完整对等物（full peer）——AI 可以改结构，而不只是改函数体"。
这一层最容易被低估。改函数体是局部的；改结构会牵动符号引用、任务绑定、HMI 变量连接、以及任何按名字找对象的地方。所以"能改结构"必须配一套"改结构之后怎么证明没坏"的流程，这也是后面台阶四存在的理由。
图 3：结构级改动走同一条管线，只是 diff 需要看得懂对象级变化。（图源：原文）
台阶三：给 AI 一条到控制器的在线通道
前三篇解决了"AI 能改工程"，但这时代码还只活在工程里。第三篇把链路接到运行时，路径是：
AI → Script Engine → soft PLC
AI 负责规划动作，脚本引擎（CODESYS 内部的 IronPython）负责对运行时执行动作，soft PLC 跑应用。
四个能力：
| 步骤 | 做什么 |
|---|---|
| 连接 | 打开在线会话 |
| 下载 | 装载已编译的应用 |
| 启动 / 停止 | 控制运行状态 |
| 读 / 写 | 访问实时变量 |
三条注意事项很关键：下载与运行是两个独立步骤（下载完不等于跑起来）；变量路径要按控制器的命名规则（GVL / 程序作用域）；仿真模式不需要真实硬件，这让整套流程可以在笔记本上闭环。
图 4：这条链路一旦打通，"AI 说改好了"才有可能被真实变量证伪。（图源：原文）
图 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 或环境变量。
图 6：白盒断言的代价是它真的跑在你的扫描周期里——这是优点，也是预算。（图源：原文）
附：主机 / 控制器的最小闭环
另有一篇把搭建过程写成"你真的能跑起来"的版本：主机 PC 与 soft PLC（CODESYS Control Win）通信，应用暴露轴和变量，主机负责启停与数据交换。
设备侧：新建标准工程，加 SoftMotion Win（或 Control Win），定义程序与轴对象，编译下载。示例里用的是 FB_SimAxis——它解析命令并对位置做斜坡，动作在程序里是真的，"轴"是仿真的。这句话很重要：在碰硬件之前，用它证明"主机 → 控制器 → 运动指令 → 状态回读"这条环是通的。
图 7：四层台阶最终要落在这条环上，否则"AI 改好了"无法被验证。（图源：原文）
编者补充：这四级台阶各证明什么
原文是工程师的操作笔记，短、直接、没有论证。我们把它放回工程语境，给出四条判据——每一层只能证明一件事，别把上一层当成下一层。
第一级（文本化）证明的是"改动可 diff"。 备份 + 比对 + 写回 + 保存这套四步，本质是把"不可见的二进制改动"变成"可审阅的文本差异"。没有 diff，AI 的改动就只能靠人眼在 IDE 里翻，那等于没有评审。
第二级（结构 CRUD）证明的是"工程能自洽"，不证明"程序还对"。 重命名一个 POU 之后，编译器仍然可能通过，但 HMI 上绑定的变量已经断了。这类断裂只有两种东西能抓：引用检查，或者端到端跑一遍。能改结构之后，验证预算必须同步变大。
第三级（在线通道）证明的是"能把结论送到真实变量上"。 这是 AI 参与 PLC 工作的分水岭：改完能下载、能启停、能读写，才谈得上"验证"。但注意脚本引擎本身是任意代码执行——IronPython 在 CODESYS 进程里跑，等于给 AI 一把能开工程和运行时的钥匙。这层必须配权限边界和操作日志，不能只靠提示词约束。
第四级（工程内单测）证明的是"逻辑对不对"，不证明"现场对不对"。 断言与被测逻辑同周期跑，好处是确定性高、时序真实；代价是测试代码会占用扫描时间，而且只能覆盖你写出来的用例。它替代不了编译检查、替代不了仿真、更替代不了现场调试。
拿我们站内已有的验证框架对照，这四级正好卡在中间两层：
| 层 | 能证明 | 不能证明 |
|---|---|---|
| TIA/CODESYS 编译 | 语法、类型、引用在工程内自洽 | 逻辑是否符合工艺 |
| 工程内单元测试（本篇） | 给定输入输出下逻辑正确 | 时序、硬件、现场工况 |
| 云仿真 / 虚拟 PLC | 扫描周期、状态机、联锁 | 真实 I/O 与干扰 |
| 现场调试 | 一切真实的东西 | 只在这一次工况下成立 |
对做西门子主线的读者，这套思路可以平移：博途侧对应的"文本化"入口是 SCL 源文件的导入导出，以及 Openness 的接口；差别只在脚本引擎换成了外部驱动。站内AI 改博途程序的写保护与边界讲的是同一件事的另一半——写之前先设护栏，这篇讲的是写之后怎么证明没写坏。
边界：原文是个人实操连载，不是评测。五篇都是短笔记，没有成功率、耗时、成本这类数据；"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 完全指南
