从我们开始RealPLC开发以来，就有很多朋友在问RealPLC支不支持梯形图。

当时，我们统一回复是暂不支持。原因，当然是从自然语言到XML再导入到TIA或者用其他的方式来做，成本和实际生成效果都不是很理想。所以，一直在等待最新的技术发展。

通过AI每周的Search和周报，我们也看到今天这篇文章所给出的路线，所以，我们也参考这种思路给出一种可能实现路线。

我们也知道很多工控行业的朋友在做RealPLC相同的事情，甚至还有互联网的一些技术大拿也想加入这个行业。

作为扎根工控行业的公号来说，我们也一直分享AI在工控行业的技术，也希望多多交流沟通，共同推进！只有不断的探索，我们才能共同前行！马上也中秋节了，恭祝关注我们，阅读此文章的朋友们节日快乐，家庭幸福！

那在设计 RealPLC 的梯形图生成能力时，我们遇到一个很关键的问题：

AI 应该直接生成 TIA Portal 的梯形图文件，还是先生成一种中间结构，再转换成真正的 PLC 工程文件？

从工程可靠性的角度看，后者更合理。

也就是：

自然语言
↓
DSL
↓
AST
↓
SimaticML / SVG / ST
↓
TIA Portal / Web / 仿真验证

这套思路，本质上是在 AI 和工业工程之间加了一层“确定性边界”。

DSL 是什么？

DSL 的全称是：

Domain-Specific Language

中文一般叫：

领域专用语言。

它和 Python、C++ 这种通用语言不同。DSL 只解决某个具体领域的问题。

比如 SQL，就是数据库领域的 DSL。

PLC 梯形图同样很适合这种思路。

例如一个电机启停逻辑，可以简化成：

XIC(Start) XIO(Stop) [XIC(Motor)] OTE(Motor)

这里可以约定：

AI 不需要直接写复杂 XML，只需要表达控制逻辑。

这就把问题从：

“请生成一大段严格符合 TIA 格式的 XML”

变成：

“请描述这几个触点、线圈和它们之间的逻辑关系。”

对大模型来说，后者明显更稳定。

AST 又是什么？

AST 的全称是：

Abstract Syntax Tree

中文叫：

抽象语法树。

简单理解，AST 就是把一段文本，转换成计算机真正能理解的“结构”。

例如：

XIC(Start) XIO(Stop) OTE(Motor)

解析后可以变成：

Network
└── Series
├── Contact
│   ├── variable: Start
│   └── type: NO
├── Contact
│   ├── variable: Stop
│   └── type: NC
└── Coil
└── variable: Motor

这时候，系统看到的就不再是一串字符，而是：

一个真正结构化的梯形图网络。

这非常重要。

因为一旦有了 AST，RealPLC 就能基于同一个结构做很多事情。

为什么不让 AI 直接生成 SimaticML？

TIA Portal 的梯形图并不是简单文本。

它涉及：

这些内容对 PLC 工程师来说，并不是“控制逻辑”，而只是 TIA Portal 的工程格式。

如果让 AI 直接生成 SimaticML，相当于同时要求它完成两件事：

第一，理解设备控制逻辑。

第二，精确维护复杂 XML 图结构。

问题就在这里。

AI 很擅长理解：

启动按钮按下，停止按钮没有动作，电机自保持运行。

但它不一定每次都能稳定维护几十甚至几百个 XML 节点、ID 和连接关系。

少一条 Wire，重复一个 UId，都可能导致导入失败。

所以更合理的方式是：

AI 负责逻辑
程序负责格式

DSL + AST，本质上是在做一个“小型编译器”

这套方案其实很像传统编译器。

我们写 C 语言时，不会自己生成机器码，而是：

C代码
↓
AST
↓
编译器
↓
机器码

同样，PLC 梯形图也可以：

LAD DSL
↓
LAD AST
↓
Renderer
↓
SimaticML

这里的 SimaticML，更像“目标代码”。

它应该由程序确定性生成，而不是交给 AI 自由发挥。

真正重要的其实是 AST

DSL 只是 AI 输出的一种形式。

真正值得长期设计的是 AST。

因为同一个 AST，可以同时生成：

LAD AST
/   |   \
/    |    \
SimaticML  SVG   ST
↓        ↓     ↓
TIA Portal Web  仿真

这意味着：

网页看到的梯形图，和真正导入 TIA 的程序，来自同一个源。

这会大大减少“页面显示是一套、实际运行又是另一套”的风险。

对 RealPLC 最大的价值，是自动修复

RealPLC 真正重要的能力，不只是第一次生成。

而是：

生成
↓
导入
↓
编译
↓
发现错误
↓
AI 修复
↓
再次编译

假设 TIA 返回：

Network 6
Timer parameter invalid

如果程序是 AST 结构，RealPLC 可以只修改：

Network 6

其它网络完全不动。

这非常适合 Agent 自动修复。

如果是一整个几千行 XML，改一个定时器时，很可能同时破坏其它节点和连接关系。

未来还能跨 PLC 品牌

这套架构还有一个更大的好处：

不容易被西门子绑死。

未来可以变成：

LAD AST
/      |      \
/       |       \
Siemens    CODESYS    Omron
SimaticML  PLCopen XML 其它格式

AI 生成控制逻辑这一层不用重做。

只需要增加不同厂商的 Renderer。

这才更像一个真正的平台。

结语

DSL：

Domain-Specific Language，领域专用语言。

AST：

Abstract Syntax Tree，抽象语法树。

它们并不是什么新概念。

但在 AI 工业编程时代，这套传统编译器思想反而非常重要。

因为工业软件真正需要的，不是让 AI 什么都做。

而是：

AI 负责理解和推理，确定性程序负责生成、校验和执行。

所以 RealPLC 的梯形图路线，不应该是：

自然语言
↓
AI
↓
直接生成复杂 XML

更合理的是：

自然语言
↓
AI
↓
DSL
↓
AST
↓
确定性生成
↓
TIA Portal

这层 DSL + AST，不是在增加复杂度。

恰恰相反。

它是在 AI 和 PLC 之间，建立一个真正适合工业工程的确定性边界。