PLC

接手别人的 PLC 程序：动第一行代码前的 4 步取证

一台还在跑、却没人能解释的机器，最贵的选择是打开博途直接改。动手前先做 4 步：取证、建基线、静态分析、验证根因再改——90% 的工作在读懂它。

一句话结论：接手一台还在运行、却没人能解释的 PLC 设备，最贵的一步就是打开博途开始改。这套被反复使用的接手流程只有 4 步：先取证、再建版本基线、用静态分析缩小搜索空间、根因验证之后才动代码。它背后有一条经验比例：接手继承程序时，约 90% 的时间属于"理解它现在是什么"，只有 10% 属于"把它改成我想要的样子"——把这个比例反过来，通常两周后就会回到原点，而且系统里多了一个你自己引入的未知。

本文完整编译自 Aiepco 的接手清单《Taking over someone else's PLC program: do these 4 things before you change a single line》（dev.to，2026-10-11；原文见 plc.aiepco.com），并合入其工程流程页中的交付纪律，做中文整理。

一、为什么"先改改看"是最贵的一步

在一台正在运行的设备里，一段"看起来明显冗余"的逻辑，很可能是某次事故之后打上去的补丁。你看到的是代码，看不到的是那次事故。

没有基线、没有证据的改动，不是消除了问题，而是把问题替换成了另一个问题；
新问题通常更难找，因为它是你自己引入的；
两周之后，你回到起点，而系统里从此多了一个未知——而且这次没有人能告诉你它原来是什么样子。

所以顺序很重要：证据在前，结论在后，不猜。

二、行业背景：为什么这类任务只会越来越多

这不是个别项目的问题。我们在《AI 正在改变 PLC 编程：哪些真能用，哪些还是噱头》里编译过一组行业观察：

在不少 OEM 场景里，一台机器的应用代码有高达 80% 是跨项目重复的；
但工程师大部分时间花在"读懂已有代码"上，而不是实现真正变化的那 20%；
与此同时，资深工程师在退休、新人上手慢，而系统还在继续运行——接手就成了一种常态，而不是例外。

换句话说，"读懂存量程序"是整个行业里最贵、也最常被低估的一环。下面的 4 步，就是把这一环变成可重复的工程动作。

三、4 步，按顺序执行

① 动手之前先取证：把"当前状态"完整存档

在碰任何一行代码之前，尽可能收集并归档这些材料：

从 PLC 上传的程序，就是它此刻运行的这个版本；
诊断缓冲区（Diagnostic buffer）；
报警历史；
主要 I/O 点的实际状态；
操作员的口述——"什么情况下会出问题""上次是什么时候"。

口语描述也是数据。这些材料是你后续每一个判断的原材料；一旦开始编辑，设备交接时的状态就永远消失了，它是唯一一件无法再生的东西。

具体做起来，每条材料都有值得注意的地方：

材料	归档时注意什么
上传的程序	记录上传时间、上传工具与版本；建议同时记下文件校验和，保证"这份就是那一份"
诊断缓冲区	重点看第一条故障——后续条目往往是它的连锁反应，时间戳要与操作员描述的时段对齐
报警历史	看的是模式：某类报警是否反复出现、间隔多长、和哪些操作相关
I/O 实际状态	在稳定工况下记录一遍，它定义了"正常"长什么样，后面每项改动都要回到这里对照
操作员口述	结构化记录：何时、什么现象、当时做了什么操作、能否复现——把这四问写全

最后提醒两件最容易被漏掉的材料：操作员的口述和稳定的 I/O 状态记录。前者常常包含图纸上永远不会写的"什么时候会出问题"，后者定义了"正常"长什么样——没有这个参照，后面每一次改动都无法判断到底是变好还是变坏。如果时间只够做一件事，先把上传程序归档；如果够做两件，就补上这两样。

② 建立版本基线：一句话说明它从哪来

把上传的程序存成一条带日期的归档记录，附一句话：

此版本于 <日期> 从机器上传，未做任何修改。

看起来是小事，但它是你以后能说清楚"改了什么、为什么改"的唯一依据，也是下一个接手人能站上去的起点。没有基线，所有的对比都无从谈起。

一个容易混淆的点：基线不等于"最新版本"。线上最新版本可能已经被（前一次混乱的）在线修改污染过；基线是"从我接手这一刻起、可复现的那个版本"。两者要分开存放、分开说明。之后每一次修改都以这条基线为参照做 diff，任何"口头说改过什么"都不能替代 diff。

③ 用静态分析和推理缩小搜索空间

不要从症状直接猜原因。先把整个程序过一遍工具：

除零风险；
数组访问没有边界检查；
块调用深度（层层嵌套的调用链）；
未使用的变量；
命名不一致、符号混乱。

这一步的目标不是马上找到 bug，而是把"一个大未知程序"变成"四个可疑块"。然后列出可能的原因，按可能性排序——而不是按"你想起来的顺序"逐个去试。

排序时可以顺手做三个维度的粗估：概率（有多像主因）、影响（一旦命中，后果多大）、验证成本（仿真几下能测、还是要停机上台）。高概率、低验证成本的原因先处理；高影响的原因即使概率中等，也要留出验证资源。

④ 根因验证之后，才允许修改

用仿真或现场单步确认根因，确认之后才改。改完之后必须做一轮回归：修好 A、碰坏 B 是常态而不是例外。每一次修改，都按第 ② 步的方式归档留痕。

验证手段按强度分四级，能用低风险的就不用高风险的：

静态核对：交叉引用、调用关系、数据类型——不运行程序就能排除一批假设；
仿真：在 PLCSIM 之类的环境里跑原有测试用例，对比关键变量的时序与终态；
现场单步：在停机窗口用单步、监控表确认根因，注意对生产状态的影响；
现场 trace + 回归：真实机器轨迹最接近事实，但成本最高，留给仿真无法复现的问题。

回归范围怎么定？至少覆盖：正常流程、异常分支、复位、首次上电、断电恢复。最后两类问题往往只在断电重启后才暴露。

四、附：这套流程背后的三条交付纪律

Aiepco 在自己的流程页里把纪律写得很直白，三条都值得抄下来贴在工位上：

证据缺失 = 失败。没有编译日志就没有证据，这一阶段就是失败——不是"没检查"，更不是"默认通过"。
条件通过 ≠ 通过。现场条件未确认时可以继续推进，但这个结论不能作为最终验收；关闭一项待办必须更新受影响的交付物，只改状态不算数。
三句话必须分开：静态分析通过 ≠ 编译通过 ≠ 逻辑正确。一句含糊的"质量有保证"，对客户毫无价值。

五、向对方要什么资料：即使答案是"没有"也要问

清单如下，有就拿着，没有也要问——"没有"本身就是信息，它告诉你这套系统过去是怎么被维护的：

程序备份：任何版本都行，越老越好——老版本的用途很具体：它可以和基线做 diff，帮你看清"上一次改动引入了什么"，这是理解事故补丁来源最快的路径；
PLC 型号与固件版本（订货号最准确）；
I/O 清单或电气图纸，草稿也有用；
历史上发生过哪些故障、当时怎么处理的（口述也要记下来）；
谁知道某段逻辑当初为什么这么写——那个人比任何文档都值钱。

六、远程能做什么，必须现场做什么

这条边界最好一开始就讲清楚，而不是第三周才发现：

工作	能否远程
程序上传、静态分析、逻辑审阅、根因推理	✅ 可以远程，多数项目就是这么开始的
接线与硬件更换	❌ 必须现场
捕捉真实机器轨迹（trace）	❌ 必须现场
安全功能的独立验证	❌ 必须现场，且需要独立签署

把这张表在开工前发给甲方，双方的时间预期和成本都会清晰很多。

七、三个不能碰的红线

这套流程里也有"什么时候不该动"：

安全相关程序（F 程序）：安全逻辑应保留在 F-LAD/F-FBD 体系内，由独立流程验证并签署。不要为了"风格统一"把它改写成普通 SCL。
临近交付、且没有测试覆盖的系统：改动风险大于收益。先补测试与文档，再谈优化。
来源不明的遗留程序：连"它现在是什么"都不清楚时，先补文档和基线，不要谈重构。

八、五个常见反模式

先改再想：用"改一下试试"代替诊断，把一次未知变成两次未知；
拿线上最新版当基线：混淆了"可复现的起点"和"已经漂移的现状"；
只信文档：纸面设计与在跑的程序不一致，是遗留系统的常态；
单点验证：仿真通过就上线，跳过回归范围和首次上电；
纯口头交接：没写进记录的结论，两周后就等于不存在。

九、这一步里，AI 能帮上什么忙

"读懂"是整件事里最耗时的 90%。传统做法是打开博途，靠交叉引用一个个点过去查：谁调用了这个块、这个变量在哪些网络被写、改一个 UDT 会波及谁。程序规模一大，这件事就变成体力活。

值得关注的是把工程本身变成一份可查询的地图：比如 TIA-CONTEXT 会解析博途的程序块、PLC 数据类型与变量表，建立调用、读写、类型、包含与控制流关系，再通过 MCP 协议交给 AI 智能体查询。

下面这几类问题，最适合在接手的第一周先问一遍：

这个块的调用者是谁，分别从哪些网络调用？
这个变量（或 DB 成员）在读的地方有哪些？在写的地方有哪些？
这个 UDT 被哪些块实例化/引用？改它会波及多少块？
哪段逻辑只写不读、或只读不写（典型的死代码或断裂链）？
同一个变量是否在多个地方被写（互锁与竞态的常见来源）？
块之间的调用深度最深到几层？有没有层级过深、难以追踪的链？
某个 DB/变量的生产者与消费者分别是谁？
哪些块从不被调用（可能是历史残留）？
某个信号从物理输入到最终消费者，中间经过了哪些网络？
一个块的语言构成是什么——LAD、SCL 混排时，哪些部分是文字层？

要说得更清楚一点：它给的是可核对的地图，不是替你下结论的人。AI 查出来的每一条关系，都应该回到对应的块与网络核对；仿真通过也不等于逻辑正确。把 AI 用在"把一个大未知变成几个可验证的问题"上，而不是让它替你签字。

如果你需要让 AI 直接进入博途工程做批量操作（导出、对比、批量生成），那么每一步都应该有预演、编译检查和仿真验证兜底，出问题能回滚——这也是 TiaLink（博途 MCP 网关）的设计前提。了解整套博途工程工具，可以从 TIA Forge 总入口开始。

十、接手前 48 小时怎么排（可直接照抄）

时间	做什么	完成标准
第 0 小时	上传程序、导出诊断缓冲区与报警历史	五类材料齐备并归档
第 2 小时	建立版本基线，写下"未修改"声明	基线可复现、可 diff
第 4 小时	与操作员/保养员访谈并结构化记录	四问（何时/何现象/何操作/可否复现）有答案
第 1 天	索取资料清单，标记"没有"的项	每一项都有答复（含否定答复）
第 1–2 天	跑静态分析，形成可疑块清单并按概率排序	大未知变成若干可验证假设
第 2 天	确定验证手段（仿真/单步）与回归范围	第一项根因进入验证

十一、Q&A

Q：没有源程序，只有一台在跑的机器，能接手吗？ 可以。先上传并归档，把这份上传版本当作唯一的事实来源；所有分析围绕它进行，文档里写的任何东西都要与它对照。

Q：可以先只补注释和文档，不动逻辑吗？ 推荐这么开始。补注释、整理符号表、建立基线都属于低风险、高回报；但注释也要在可回滚的版本管理里做，并保持与基线可 diff。

Q：安全功能可以一起"顺手"整理吗？ 不可以。安全逻辑要按独立流程验证并签署，不能混在普通重构里。这条是红线，不是建议。

Q：AI 查出来的答案能直接当结论吗？ 不能。把它当"待验证的线索"：每一条都要回到具体块和网络核对，关键结论要有仿真或现场验证。

十二、一页交接清单（可直接抄）

[ ] 从 PLC 上传程序，原样归档（记录时间、工具、校验和）；
[ ] 导出诊断缓冲区与报警历史（标出第一条故障）；
[ ] 记录主要 I/O 的当前状态；
[ ] 记录操作员对故障时机与现象的描述（四问结构化）；
[ ] 建立带日期与来源的版本基线（"未修改"声明）；
[ ] 运行静态分析：除零、数组边界、调用深度、未用变量、命名；
[ ] 列出可疑原因并按概率/影响/验证成本排序；
[ ] 向对方索要：程序备份（越老越好）、订货号/固件、I/O 表或图纸、故障史、关键知情人；
[ ] 仿真或现场单步确认根因；
[ ] 改动后跑回归（正常/异常/复位/首次上电/断电恢复），并按 ② 归档每一条修改。

十三、小结

接手遗留程序的胜负，在动第一行代码之前就已经决定了大半：取证让你拿到不可再生的现场状态，基线让你后来能说清楚每一处改动，静态分析把未知压缩成可验证的问题，根因验证让修改可控。把 90% 的时间花在"读懂现在是什么"上，那 10% 的修改才算真的改对了。

参考来源

Aiepco《Taking over someone else's PLC program: do these 4 things before you change a single line》，dev.to，2026-10-11；原文与完整流程见 plc.aiepco.com（takeover-checklist / process 两页）。
本文完整编译该清单的 4 步流程、资料清单与远程/现场边界，并合入其流程页的三条交付纪律；文中比例与表述以来源为准。48 小时排程、红线与反模式为在来源基础上的整理，供参考。

延伸阅读（本站）

工具入口：TIA-CONTEXT ｜ TiaLink ｜ TIA Forge 总入口

这是「AI × 工业 / PLC」专题的一部分。完整地图见：AI × 工业 / PLC 完全指南