实战案例|接手无文档 PLC 旧工程:让 AI 画出程序结构地图,最小风险修改

开篇：交付群里的最后一条消息

每个自动化工程师都接过这样的班：产线马上投产，上一任工程师在交付群留下最后一句话——"逻辑都在程序里，有问题联系我"——之后头像再也没有亮过。

打开工程一看：OB1 一串 CALL，核心是 FB120_UnitLine 这个大块。没有配套文档，注释断断续续，变量名看着有规律，但你不敢赌自己的理解就是对的。

图 1｜演示工程：FB120_UnitLine，就是这台整线 Unit 块

改还是不改？改哪？怎么保证第一行改下去不会炸出五个别处的红字？

这篇讲我最近的接手流程：先让 AI 当导航员画地图，再做第一次修改。全程在演示工程上实测。

① 接手旧程序：不要直接扎进代码

拿到程序第一句抛给 AI 的话，不是"帮我改什么"，而是："先不改代码，分析 FB120_UnitLine 的程序结构。"

AI 只读不写，返回的东西比"这个块干什么的"值钱得多：

图 2｜结构分析：六态状态机（PackML/CPG 风格）

六态状态机。整个 Unit 的运行逻辑收敛在一个 CASE 里：0000 停止 / 7001 就绪 / 7002 复位中 / 7003 运行 / 7004 停止中 / 8401 故障。谁都能进停止，故障优先级最高——事故处理的秩序一眼可见。

图 3｜结构分析：七个段实例 + 接口设计特点

七个段实例。E002 上料、E003~E005 三段纯输送、E006/E007 双机器人码垛站（带垛号/箱号计数）、E008 层拼（阻挡缸 + 左右聚拢缸，整层转出）。每段一个 FB 实例，段与段之间靠状态联动，不靠交叉引用对方变量。

接口集中。所有 HMI 需要的命令/状态面集中在 FB120 的接口上——这意味着画面、调试、置数，都只需要盯一个接口。

到这里你还没读一行实现代码，但程序的三维结构已经有了。这就是地图的作用：不是替你理解程序，是让你知道该往哪看。

② 先读接口：它就是程序的地图

结构有了，第二句："读取 FB120_UnitLine。"

图 4｜接口地图：read_block 返回的 VAR_INPUT 段（含注释）

三个读法分享：

先读输入。EnableIn 总使能、Cmd_Auto/Cmd_Stop/Cmd_Reset 三个命令、七段各自的使能开关——输入面就是这台设备的"操作面板"，操作工能做什么全在这里。再读常量。VAR CONSTANT 段里躺着六态常量（_ST_STOPPED=0 到 _ST_ABORTED=5）——状态机的全部合法状态一目了然，后面看逻辑时 CASE 标签不用猜。最后读输出。状态字按六态编码、各段状态透出、故障字——输出面就是这台设备的"仪表盘"。

接口读完，这个块能被谁控制、会报告什么、异常时去哪看，三个问题全有答案。读懂接口，等于拿到程序的操作面板与仪表盘。

③ 隐形大坑：三套计数口径，极易置数翻车

结构清楚了，还有一层更隐蔽的：计数口径。

这条线上三个站都在数箱子，但数的不是同一种"箱子"。问一句 AI："分析 FB120 的计数口径：E006/E007 和 E008 分别数的什么"，返回的拆解值得整段抄进笔记：

图 5｜三本账：三个计数点分别数什么 + 换算公式

E006/E007 数"垛内序号"——不管箱子归不归本站机械手，到达就 +1，所以它的计数是"该垛从源头数起的第 N 箱"。E008 数"层内序号"——只统计进 E008 床面的箱：层计满且挡面压实 → 整层聚拢转出 → 层计数清零；另有一个永不清零的累计记总收箱数。

两套口径之间有确定的换算关系——AI 给出了双向公式：从垛内序号反推层号和槽位号（整除取商、取余定位），从层号和层内已进数正算回垛内序号。转换中的一个细节最见功力：E008 的置数拆成两个输入（层内计数 = 两段差值，层号由整除推算），校验规则要求差值 ≤ 层内数且为每层箱数的整数倍——口径换算不是数学游戏，是置数操作的正确性前提。

这三条不搞清楚，HMI 的置数按钮就是定时炸弹。旧程序最大的风险，不是代码写错，是你不知道它的计数口径。 AI 把它们从三个块的代码里翻出来摆在桌面上——至于换算规则写不写进操作规程，是你的决定。

④ 受控修改：只改一行，最小变更风险

看懂结构，就可以动第一行了。对 AI 说的不是"用什么工具、什么参数"，就是一句人话：

AI 走出的链路比预想的还多走了一步——而这步恰好是这套工具的价值所在：

图 6｜真实过程：首传被安全门拦下 → AI 自取最新导出改回 → 编译通过

然后验收。重新读取，和改之前逐行对比：

只差这一行。 你没提到的其余内容，一个字符都不会变。这不是 AI"很小心"，是机制保证：修改按锚点作用于最新快照，其余内容根本不经过 AI 的手。

为什么不让 AI 重写整个文件？让 AI 重写 400 行：一个字一个字往外生成，慢；上下文一长容易顾此失彼，丢行丢注释；按量计费的话，成本也不划算。锚点式编辑反过来：AI 只提交改动的几行，其余由工具从已验证的快照原样保底——生成时间从分钟级降到秒级，改动范围结构性锁死，"丢一行"这类事故从机制上不可能发生。

顺带说这次修改的真实过程：第一版上传被安全门拦了下来——因为博途侧的块比 AI 上次操作后有更新，工具拒绝基于过期内容上传。AI 自己重新读取了最新内容、在权威版本上改回、重新上传编译。拦我的和帮我的，是同一套机制。

⑤ 划重点：AI 只能画地图，工艺理解还得靠人

最后说清楚 AI 在这件事里的边界：

它画出的是结构地图——状态怎么分段、接口怎么分布、计数怎么联动。这些是"程序长什么样"。

它给不出的是工艺语义——为什么故障优先级最高、什么工况下允许跳段、置数时机为什么约定在空闲。这些是"程序为什么这样写"，答案在产线上，在工艺文件里，在前任工程师的脑子里。

AI 当导航员，开车的是你。每次修改后的人工校验、每个语义口径的现场确认，一步都不会少。

AI 帮你看懂程序长什么样，但永远没法替你读懂产线为什么这么设计。

你接手过最离谱的遗留程序是什么样？拿到旧程序，你第一步是读代码还是查接口？评论区交流。

👉关注 PLCMind 工控观察，持续分享工控一线实战案例。

官网：plcmind.com（文末「阅读原文」直达内测申请页，填表通过后邀请码发你邮箱）