RealPLC AI为啥目前只支持ST/SCL，不支持梯形图编程！

我们目前已经内测了两期，从单个对话编程多智能体的编排后，复杂度和每次迭代所花费的时间和精力也在成指数式上升。

期间，也有很多朋友会问，支不支持梯形图，什么时候能够支持？我们这期统一回复下，另外也分享下我们的思考，仅供参考。

01、AI的能力和性价比

不用说，AI之所以如此火爆，主要就是文本的理解能力，从AI的底层算法和推理的链路，文本式的方式是从chatgpt那一天开始就是AI的最舒服的方式。

梯形图的诞生的背景，是当时要推广PLC产品，必须要让人类工程师能更快的实现编程和上手，降低使用的难度。确实比直接用终端汇编语言要更容易使用，所以梯形图是PLC编程语言绝对的第一位，理所当然。

但是，AI时代，从能力上来说，语料和代码库更多的是其他语言，比如TypeScript、C、Java...毕竟这些开源的代码和Github上那么多优秀的开源资料，更加容易获取并持续得到优化和训练。

而PLC的资料和代码确实非常少的，当PLC支持ST这类文本语言后，其他从C/C++等算法可以改变一些即可直接转换成ST语言，更能够处理一些复杂运算等场合。

而且，目前从使用效果和实际测试来看，ST语言生成的效果比梯形图更好。另外，梯形图，大部分是通过文本类的语言结合工业软件的转换而得到。

所以，个人认为：ST是AI时代实现PLC编程的最佳方式，至少目前是这样的。

02、AI自己的观点

通过和Chatgpt进行会话总结，主要也是三个方面来佐证：

1.AI理解与生成能力的差异；

2.开发效率和扩展性考虑；

3.梯形图的复杂性和局限性。

03、RealPLC的选择

RealPLC为什么选择先把ST/SCL做好？

因为RealPLC当前最重要的目标，不是一次性支持所有PLC语言，而是先跑通一个真正可靠的工程闭环。

这个闭环至少需要做到：

• AI能够准确理解需求；
• 生成结构清晰的程序；
• 自动补充必要的故障和联锁；
• 发现明显的危险逻辑；
• 调用真实PLC软件进行编译；
• 根据诊断信息自动修复；
• 保留每一次程序版本；
• 最终由工程师确认后写入项目。

ST/SCL是目前最适合完成这套闭环的语言。

因此，RealPLC现阶段优先支持ST/SCL，并不是功能上的妥协，而是一种工程上的取舍：

先把一种语言做深、做稳、做成真正可以验证的工程工具，再逐步扩展到梯形图、功能块图和其他PLC语言。

04、小结

AI生成PLC程序的关键，从来不是“能不能输出几行代码”或者“能不能画出几个触点”。

真正重要的是：

生成的程序是否符合需求，是否能够编译，是否具备故障处理，是否满足工程规范，是否可以安全地进入真实项目。

RealPLC选择从ST/SCL开始，是因为文本化、结构化和可验证的程序，更适合建立AI与真实工业软件之间的闭环。

梯形图不会缺席，但它必须建立在可靠的逻辑模型和工程验证基础之上。

RealPLC最终要做的，也不是一款只会生成ST代码的工具，而是让AI真正理解控制需求，并能够在不同PLC平台、不同编程语言和真实工程环境中，生成可以验证、可以审核、可以交付的工业控制程序。