Claude Code打通PLC编写到仿真验证

AI 写出 PLC 代码，离「能用」还有多远？作者在 TIA Portal V19 上跑了一次完整实验：从空设备出发，用一条需求驱动 Claude Code，经 MCP 写入程序、编译、下载到仿真器，再验证电机顺序启动、停止和故障场景。结果是编译零错误、零警告，三个行为场景通过。

对程序员更有参考价值的，是它把 AI 编程的验收标准从「生成了什么」推进到「实际运行了什么」。不过，仿真通过、现场可用和安全可靠之间，仍有需要人工补上的环节。

一条提示词能跑通，靠的是需求可以验收

实验发生在 2026-10-27，环境是 Windows、TIA Portal V19、Openness 19.0、S7-PLCSIM Advanced 6.0，以及 gateway 1.3.2.0。作者称，这个版本提供五组共 34 个工具，另外还有一个用于 LAD 梯形图工作的工具，但正文没有展开五组能力的具体清单。

gateway 必须装在 TIA 所在的 Windows 机器上，agent 可以在另一台电脑运行。作者的调用全部通过跨机器 HTTP 完成。Claude Code 的接入命令是 claude mcp add --transport http tialink http://192.168.1.110:8080/mcp，再用 claude mcp list 检查连接和工具数量。

其他客户端的差别主要在配置入口：Cursor 使用 .cursor/mcp.json，Claude Desktop 使用 claude_desktop_config.json；WorkBuddy、CodeBuddy 通过界面添加连接器，还要点击 Enable。

真正支撑自动执行的，是需求足够具体：启动按钮让电机 1 运行，持续 3 s 后启动电机 2；常闭停止按钮断开，或者出现故障，两台电机都应立即停止。逻辑放进可复用的 FB 功能块，由 OB1 主程序调用，定时使用 IEC 定时器。

地址也被固定下来：M0.0 是启动，M0.1 是停止允许信号，1 表示允许，M0.2 是故障，M0.3、M0.4 分别输出两台电机的运行状态。提示词还要求写入 PLC_3、编译达到 0 错误、使用全新名称创建仿真实例、运行场景验证，并且不要保存工程。

作者没有提供 SCL 模板，也没有指定操作步骤。但任务的输入、输出、失败条件和交付物都已经划定。

「一条提示词」能成立，前提是它包含一份可执行的验收约定。

编译通过之后，还要证明停止逻辑真的有效

下面这段 SCL 负责保存运行状态、延时启动第二台电机，并统一处理停止与故障。SCL 可以理解为 PLC 使用的结构化文本编程语言。

FUNCTION_BLOCK "FB_MotorSeq"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT
      Start : Bool;             // start button (M0.0)
      StopPermit : Bool;        // stop, normally closed: 1 = allowed (M0.1)
      Fault : Bool;             // fault (M0.2)
      RunDelay : Time := T#3S;  // motor 2 delay
   END_VAR
   VAR_OUTPUT
      Motor1 : Bool;            // motor 1 running (M0.3)
      Motor2 : Bool;            // motor 2 running (M0.4)
   END_VAR
   VAR
      statRun : Bool;           // run latch
      statPermit : Bool;        // run permitted
      rtStart : R_TRIG;         // rising edge of the start button
      tonRun2 : TON_TIME;       // IEC on-delay timer
   END_VAR
BEGIN
    // Run is permitted when the normally-closed stop is closed and there is no fault
    #statPermit := #StopPermit AND NOT #Fault;

    // Latch on the start edge; stop or fault clears it immediately
    #rtStart(CLK := #Start);
    #statRun := (#rtStart.Q OR #statRun) AND #statPermit;

    // Motor 1 runs at once; motor 2 starts RunDelay after motor 1
    #Motor1 := #statRun;
    #tonRun2(IN := #Motor1,
             PT := #RunDelay);
    #Motor2 := #statRun AND #tonRun2.Q;
END_FUNCTION_BLOCK

重点看 #statRun := (#rtStart.Q OR #statRun) AND #statPermit;：启动采用 R_TRIG 上升沿触发，停止和故障则通过 #statPermit 清除运行状态，不必等待定时结束。持续按住按钮，也不会持续产生新的启动边沿。

OB1 负责把功能块实例接到约定的 M 区地址：

ORGANIZATION_BLOCK "Main"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
BEGIN
    "DB_MotorSeq"(Start := %M0.0,
                  StopPermit := %M0.1,
                  Fault := %M0.2,
                  RunDelay := T#3s,
                  Motor1 => %M0.3,
                  Motor2 => %M0.4);
END_ORGANIZATION_BLOCK

这里要核对 "DB_MotorSeq" 的调用及每个地址绑定。功能块自身正确，接线地址错了，运行结果仍会出问题。

编译返回 state=Success、errorCount=0、warningCount=0，Main（OB1）和 FB_MotorSeq（FB1）均完成清理。随后，作者验证了顺序启动、停止、故障三个行为场景。

电机 2 的观测启动延迟为 3.12 s，比设定值多 120 ms。作者将其归因于 150 ms 的轮询粒度和扫描抖动。这个解释合理，但轮询读到的是观测时间，单靠它不能证明内部动作的精确时刻。同样，图中所述的同一扫描周期停止，也不能直接当成经过独立测量的现场响应上限。

写入成功不够，还要读回，并弄清保存边界

这条链路存在明确的顺序约束：Import → compile → read back。导入之后，功能块还没有达到一致状态，直接导出会收到 Block is inconsistent (not compiled)。因此，不能把导入成功当作程序已经可用。

下载成功也需要核实。作者导出三个块的 SimaticML，检查 OB1 是否调用正确的实例 DB、M 地址是否匹配、FB 是否使用 IEC TON、是否存在多余实例，以及元数据是否标记为 consistent。

不过，原文列出的文件大小是 Main 7,766 B、FB_MotorCtrl 15,978 B、DB_MotorCtrl 6,903 B，其中后两项属于更早的单电机版本。它们不能作为当前 FB_MotorSeq 双电机程序的直接证据，复核方法与样本记录需要分开看。

耗时也会影响 agent 的判断。添加 CPU 在旧设备上花了 34 s，在较新设备上为 2.2 s，下载约需 10 s。作者建议提高客户端超时，避免将执行缓慢误判为失败；但原文没有给出完整耗时分布，也没有明确推荐新的超时值。

另一个容易混淆的边界是保存。按 gateway 的说明，导入、硬件写入、删除和编译都先作用于内存中的工程，保存后才持久化。关闭 TIA Portal 会丢失未保存修改。

但实验本身已经执行下载，因此「不要保存工程」不能被理解成所有外部状态都会自动恢复。作者提出的实践是先验证，最后保存一次；涉及下载和联机时，还需要单独考虑回退。

我的判断

我认同作者把「读回结果」和「行为验证」放进验收链路。它比只贴一段能编译的代码更有说服力，也揭示了 AI 工具调用中的常见缺口：接口返回成功，只能证明某一步被接受，不能包办最终正确性。

但这仍是一个范围很小的仿真实验。正文没有提供与人工实现的耗时对照，也没有说明多次运行的成功率，不能据此推导 AI 已经更快、更可靠。V19 是本次实测环境，V20 是作者宣称支持的版本，两者的证据强度也不同。

作者建议先只读检查工程树、程序块和交叉引用，再预览修改一周，并坚持每次写入后读回。这些是经验建议，「一周」没有对照数据支持。相较直接让 agent 改完整工程，小范围变更确实更方便检查，但仍需结合团队流程决定观察期。

还有一条约束值得保留：Openness 侧串行执行，同一工程应保持一个会话、一个写入者。这里增加并行 agent 可能制造半完成状态。

这次实验支持的是自动化闭环可行，生产安全仍需另行验证。

作者也明确要求人工审查 AI 生成的 SCL，尤其是急停、联锁和 F-programs，并反对无人值守地执行下载或联机。编译可以成为硬门槛，却不能替代这些审查。

能拿来做什么

• 给日常 AI 编程任务补齐验收条件：除了要求生成代码，还要写明目标对象、输入输出、失败场景，以及最终需要交付的运行证据。
• 在前端或 Node 的自动修改流程中借鉴「写入后读回」：检查实际文件和差异，再执行构建与行为验证，避免仅凭工具返回成功结束任务。
• 如果接入 TIA 工程，先从只读检查和一个带测试场景的功能块开始；修改前用 VCI 或 Git 归档可比较的文本，并记录操作者、时间、模式和对象。
• 把编译失败设为阻断条件，把下载、联机和安全逻辑保留给人工逐步确认；同时分别核对工程保存状态与目标运行状态。