西门子不给源码,AI 就自己写了一个渲染器

故事发生在一个真实的托盘输送线项目上——某成品库，一台 S7-1500，一个两百多个块的程序。用户把项目在博途里打开，让 AI 上："读一下这几个核心块，解读架构。"

第一发请求发出去了。回来的是——空。

不是报错，不是权限拒绝，就是干干净净的空：块找到了，名字、编号、类型都有，唯独源码那一栏，什么都没有。换成另一个块，还是空。四个块，全空。

如果是个人类工程师，这时候大概会怀疑人生：我权限没配好？项目加密了？还是这软件有 bug？

AI 的做法朴实一点：把能试的路全部试一遍，做成一张五级的梯子，一级一级往下爬。

五级梯子，五次落空

五级取源梯子：前四级全空，第五级是墙也是窗

第一级，读块的 Source 属性。空。

第二级，走属性接口再问一次。空。

第三级，找本地缓存的上传副本——这个项目不是我们上传的，没有副本。空。

第四级，用接口+程序体属性现场拼一份源码出来。接口层拿得到，程序体拿不到。空。

第五级，调博途的导出接口，把它吐出来的东西当源码。

第五级有意思。导出接口确实吐东西了——吐的是 XML。三兆多的 XML。而 XML 不是 SCL，当源码用就是把整份原料清单当菜端上桌，所以我们的校验把它拦下来了。

到这里，梯子五级全部落空，每级为什么空都有日志为证。结论收敛到一个让人意外的事实上：

西门子的工程师没打算刁难谁——对大多数自动化场景，"读源码"本来就不是需求，块能编译能下载就行。但对"让 AI 读懂并修改存量程序"这件事，这就是堵墙。

墙上只有一扇窗

复盘那份被拦下来的 XML，转机出现了。

三兆的 XML 里，躺着一个 StructuredText 节点。SCL 块的程序体，在导出 XML 里不是黑的——它是以 token 流的形式完整存在的：每个关键字、每个变量引用、每个注释、每个换行和缩进，都是一个一个的节点，白纸黑字。

导出 XML 里的 token 流（示意，合成内容）

也就是说：西门子不给你文本，但给了你全部的料，只是摆成了 XML 的形状。缺的只是一个把料摆回人样的东西。

于是 AI 给自己写了一个渲染器：读 token 流，按文档顺序拼回 SCL。变量加 #，DB 引用补引号，REGION 区间标题还原，多实例调用按参数边界重组——每一个规则都不是猜的，是先把四个块、三千多个 token 的导出文件全部普查了一遍，每种节点形态都见过之后才写的。

渲染器输出（与上表同一片段）

写完先不上机，拿真实导出离线渲染对拍：最大的调度块，3 兆 XML 渲出 19 万字符 SCL，83 个 REGION 一个不少；拿渲染结果和博途编辑器里的原文逐字对比——包括那个两千四百行的块里，多行调用的换行和缩进，一模一样。

最后一步，活体验证：连上用户开着项目的博途（中间还等了一下 Openness 的授权弹窗——工程现实总会出场），重新读那个块。

梯子日志这次是这样的：前四级照旧空，第五级——XML 34155 字符 → SCL 1931 字符。

源码回来了。AI 把自己的眼睛修好了。

顺带一提，同一晚还挖出第二个 bug：生成源码的工具链拿错了对象类型，拿到的是数据模型不是博途工程对象，所以导出永远失败。也修了。这种"修好自己的工具再用工具干活"的事，人类工程师干了一百年，现在 AI 也开始干了。

眼睛修好之后，看到了什么

托盘输送线五层控制架构（真实项目提炼）

源码能读了，AI 把这条输送线的架构完整读了一遍。值得单独讲讲——这是一套在真实产线上验证过的、非常适合中小物流线抄作业的架构，五层：

第一层，区域调度。一个 2400 行的调度块，内部 199 个实例把整个库区编排出来：129 个输送段、23 个巷道口、8 组扫码器、8 个叉车入口。最有味道的是命名——实例名就是拓扑：GS3055_G3060，从 GS3055 到 G3060 的一段输送机。看名字就知道货往哪走，调度代码里没有一个魔法数。

第二层，任务总线。每个工位一份任务数据（UDT），任务号、运行位、组报警位。任务不是被"计算"出来的，是沿着拓扑接力的——上游工位满了、下游空着、没有报警，任务就交过去。条件不满足就等着。简单，但整条线的状态因此处处可查。

第三层，接力与动作。任务交接块的守卫链有十条，全是通过布尔量拼起来的工艺条件；动作块管正反转的减速、到位，每种动作还带"工艺联动"变体。

第四层，驱动控制。手动/自动、限位、升降速、分岔选择——布尔联锁最密的一层。

第五层，保护。组报警总线：任何一台设备组报警置位，全线传递禁止，一个位管全线。加上转圈计数防堵：托盘在一个圈里转的圈数超限就判定堵料——正常/疑似/确认，三个阶段靠计数器和延时拼出来。

三个可以拿走的模式：拓扑即命名、任务接力总线、组报警保护总线。

下一步：给架构上状态机？

读的过程中自然会冒出一个问题：这套靠布尔条件织起来的逻辑，如果引入状态机的思想，会更好还是更差？

我们研究了这个问题，结论是一句话：流程编排层上状态机，安全联锁层不上。

状态机分域判据（建议长按保存）

任务生命周期（空→待交接→传递中→到位→堵塞→报警）值得上一台状态机：十条守卫链变成一张转移表，非法状态被枚举机制性排除，HMI 上一个状态字代替六个布尔位，故障回放变成看时间线。而且这套架构是盖章式的——状态机写进模板块一次，129 个实例自动复制，工程量被架构本身稀释。

但驱动层的限位、急停、超时屏蔽，不上。那一层的价值就是布尔表达式"一目了然可审查"，套上状态抽象反而降低可审查性——安全联锁的透明性本身就是安全性。

还有一个对做 AI 工具的人有意思的发现：状态机是 LLM 生成最可靠、验证最高效的结构——转移表可以全量枚举审查，缺一个转移静态检查就能报警。给存量架构上状态机，等于把程序改成 AI 最擅长维护的形状。这可能是"AI 可维护性"成为架构设计输入的第一个真实案例。

收尾

这一晚下来，AI 干了三件事：发现自己瞎了，自己治好了，然后看清了一条产线。

我们做 PLCMind 的路线一直是"生成→编译→诊断→修复"的闭环，但这一晚让闭环多了一环：AI 能维护自己的作业环境——读不到源码，就把取源的能力造出来。

对存量项目占绝对多数的中国自动化市场，这一环可能比代码生成本身更关键。生成是从零开始的世界，而真实的工程，从来都是从"读懂已有的东西"开始的。

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