AI 写 PLC，关键在项目关系上下文
文章以 TIA Portal 中变量读写追踪为例，指出 PLC 项目的跨块关系难以靠文件堆叠完整表达。直接粘贴、字符串搜索和让智能体自行浏览，分别面临窗口限制、关系方向缺失与上下文过期问题。
AI 深度解读
让 AI 回答一个 PLC 变量被谁读取、被谁写入，听起来只是代码搜索。可在真实项目里，有用的答案应该落到具体触点、线圈、网络和行号，才能支撑修改与评审。作者的主张是：当前模型已经能写 SCL，真正缺的是可核查的项目上下文。
他们用一个 TIA Portal 项目展示了这种差别：把散落文件组织成关系图，再让 AI 查询调用、读写和未解析引用。对程序员更有参考价值的，是其中三条约束：每条结论带证据，查询必须检查截断，项目缺失的对象也要进入报告。
为什么多塞文件，仍然回答不好依赖问题
PLC 项目里的关系天然跨文件。梯形图中，网络 N3 的线圈写入某个变量，网络 N7 的触点读取它，变量定义又在另一张标签表中。把文件切成文本块，恰好容易切断这些联系。
项目图的做法，是把对象作为节点，把调用、实例化、读取、写入等关系作为边。大白话解释：除了保存「项目里有什么」，还要保存「它们怎么连起来」。
作者尤其强调关系的出处。「Auto_mode 里的线圈写了 tag3」和「解析操作数后发现，Auto_mode 第 217 行的线圈写了 tag3」，可信程度不同。后一种说法提供了回到源文件验证的入口。
AI 给出的依赖结论，应该能被还原成一组可以逐条检查的记录。
原文节选存在信息缺口：提到了三种上下文方案、图中的四类内容和六个探针，却没有完整展示相关表格及提示词。因此，我们能讨论已经给出的结果，无法据此复现完整查询流程。
227 个节点之外，517 条关系提供了什么
这次运行针对 MIT 许可的开源项目 rassulz/multirobot_painting_control_system，项目名为 PLC_SCADA_HMI。环境是 TIA Portal V19，S7-1500 / ET200MP 站点，CPU 1513F-1 PN，订货号 6ES7 513-1FL02-0AB0，固件 V2.9，工具版本为 TiaLink 1.4.0.0。
作者引用的运行记录来自 2026-10-27，图构建耗时 1.2 秒，得到 227 个节点、517 条边，以及 8 条未解析引用。边的分项数字为 220/2/2/87/52/154，但节选没有给出完整的类别对应，不能自行补齐。
整个过程只读：没有导入、修改程序块或保存，项目脏标记也没有变化。作者同时披露，这些数据来自课程已经发布的运行记录，写这篇文章时没有独立重跑。
关系数量约为对象数量的两倍，说明对象清单并不足以支撑分析。但这个比例本身还不能证明图一定优于所有文本检索方案，真正有说服力的是它能交付什么。
例如，additional_variables.tag3 的查询结果可以落成四个位置：
| 访问方式 | 梯形图元素 | 所在位置 | 行号 |
|---|---|---|---|
| 读取 | 触点 | Auto_mode，network 1 | 152 |
| 读取 | 触点 | Auto_mode，network 1 | 222 |
| 写入 | 线圈 | Auto_mode，network 1 | 217 |
| 写入 | 线圈 | Auto_mode，network 1 | 262 |
这比「自动模式模块使用了这个变量」多了一层工程价值：评审者能打开 XML，核对第 217 行是否真有对应线圈，也能把四处位置分配给具体人员检查。
不过，这四处是图中识别出的直接读写位置。作者把它描述为完整的软件影响范围，判断偏满：变量变化经由控制逻辑继续传播的行为影响，不能仅凭四条直接引用就全部确认。
分析 FB::Auto_mode 时，作者还把两类问题分开。默认关系集 call / instantiate / read / write 回答「谁与它存在依赖」：主程序 network 1 调用它，实例 DB 是 Block_1_DB，修改接口时两者都应检查。
加入 containment 后，问的是「它位于哪层结构中」，沿文件、网络、程序块等层级追踪。依赖关系帮助制定检查范围，包含关系帮助定位位置，两次查询各有用途。
为什么健康的查询结果，也可能让人判断错
图的第一个风险是过期，而且外观看不出来。
作者要求先核对项目名称、构建时间，以及是否来自当前打开的项目。构建后只要又改了程序块，旧图就可能失效。空图被拒绝时，工具还会保留上一份图，因此查询成功并不能证明查询的是当前版本。
第二个风险是结果上限。Auto_mode 在一次查询中匹配到四项：FB、调用点 Main::N1::I1、对应文件和网络。但返回结果同时提示「还有更多」。忽略这个提示，就会把一页结果误认成全部引用。
作者因此建议六个探针分六轮执行，每轮单独核查。长回答的问题不只是可能说错，还可能漏掉内容，却保持完整流畅的语气。
第三个风险，是把「没有执行检查」看成「检查通过」。他们发现 8 条引用指向项目中没有定义的对象，交叉检查显示，这些都是写入定时器实例的线圈；涉及的两个 FB 接口为空，也没有同名全局 DB。原文提到了 IEC_Timer_0_DB，但没有展示全部八条记录。
随后，编译返回：
「No block was compiled. All blocks are up-to-date.」
这句话只说明本次没有程序块需要编译，不能拿来证明八条引用没有问题。报告必须记录检查究竟执行了什么。
未解析引用也不能直接判为坏代码。它可能确实缺少对象，可能依赖外部库，也可能尚未加入这份项目副本。AI 可以整理证据，分类仍需负责设备的工程师完成。同样，空 FB 接口、两个空 OB 网络是事实，是否属于设计意图，还要找项目负责人确认。
我的判断
我赞同作者把「证据出处」放在回答质量之前。对于接手旧项目、做依赖排查的人，可定位的记录比一段通顺解释更有用。
但「图无法放进序列，所以提示工程解决不了上下文」说得过于绝对。图可以序列化成文本，模型也可以通过工具按需读取关系。更准确的问题是：直接堆文件时，关系没有被显式维护，完整性和证据来源也难保证。
相较于关键词搜索，图适合回答跨对象的读写关系，以及某个名字是否解析到实际对象；搜索依然适合快速定位文本。原文没有提供它与更好文本检索方案、长上下文方案之间的对照数据，也没有给出多项目准确率。因此，这是一份有具体证据的案例，尚不足以证明普遍优势。
图本身同样会出错。解析遗漏、版本过期或外部依赖未纳入，都可能制造「对象缺失」。抽查两三处行号只能帮助校准信任，不能证明整张图正确。
作者保留的边界也很关键：图不了解接线、通道和硬件。%I29.4 在表里是一个地址字符串，现场端子是否对应，还要另外检查。关系图、编译、仿真、安全评审各自验证不同问题，不能互相替代。
TiaLink 是连接 TIA Portal 与 agent 的本地 MCP 网关，作者称项目数据留在工厂内。这解释了工具定位，但原文并未展开整条 agent 调用链的数据流，不能进一步推导出所有数据处理环节的结论。
能拿来做什么
- 接手一个不熟悉的项目时，可以照作者的约 30 分钟流程，先记录图对应的项目、构建时间和来源，再手工对照一次 TIA 项目树；清单不一致，就先排查图的可靠性。
- 挑一个输出使能、联锁或握手变量，让 AI 分别列出读取者和写入者，并抽查两三处 XML 或编辑器位置。把直接访问位置作为检查起点，继续评估行为影响。
- 在日常 AI 编程中，也可以要求依赖分析附上文件位置、证据来源和截断状态。一次查询只回答一个可验证的问题，避免把长回答当成完整清单。
- 将未解析引用逐条写入报告，分类为真正缺失、外部依赖或后续补入，并注明判断依据。编译结果另行记录，尤其要区分「实际编译通过」与「本次没有编译」。