ai接入博图tia

最近用了一个别人的项目:TIA_Portal_Openness_MCP

先说我的实际感受：

这个项目我已经用过一阵子了，整体思路挺有意思，尤其适合拿来做 AI 接入博途的探索。

目前我自己的结论是：

• 对 SCL 程序编写辅助比较有价值


• 做原型、生成基础代码、整理逻辑这类事情还不错


• 但如果直接拿去上实际项目，目前还不太合适


• 尤其是复杂工程、联调、规范一致性、工程可控性这块，离生产可用还有距离

不过作为一个 “AI + 博途 + MCP / CLI” 的尝试，我觉得还是挺值得看看。

这个项目怎么用

它主要有两种使用方式：

1. MCP 方式

这种方式适合接到支持 MCP 的 AI 客户端里用，比如一些支持 MCP 协议的桌面 AI 工具、IDE 插件或者 Agent 工具链。

大概理解就是：

• 先把它作为 MCP Server 配好


• 再让 AI 客户端通过 MCP 去调用它


• 然后在对话里让 AI 帮你做一些工程操作、代码生成、结构分析之类的事情

这种方式的优点是：

• 交互自然


• 适合边聊边改


• 比较适合做“AI 助手式”的使用体验

缺点也明显：

• 对客户端支持有要求


• 配置链路相对更长


• 一旦上下文大了，或者调用链复杂了，稳定性和可控性就比较吃环境

2. CLI 方式

另一种就是直接走命令行。

也就是不用 MCP 客户端那一套，直接通过它提供的 CLI 命令去操作，比如：

• 生成


• patch


• compile


• describe


• export / import


• prewarm

这种方式我感觉反而更适合真正想试功能的人。

优点是：

• 更直接


• 更容易排查问题


• 调试成本更低


• 批处理、脚本化更方便

缺点是：

• 交互感没那么强


• 需要自己组织命令和流程


• 更像工具，不像助手

我的实际看法

如果只是想体验一下 “AI 能不能帮忙写博途代码”，这个项目还是值得试的。

特别是 SCL 这块，拿来做辅助生成、改写、整理逻辑，确实比纯手敲轻松一些。

但如果说直接把它放进实际工作流里，让它稳定参与正式项目开发，我目前的感觉还是：

还不够成熟，更适合辅助，而不是替代。

所以我现在更倾向于把它当成：

• SCL 辅助编写工具


• AI 接入 TIA Portal 的实验平台


• 自动化工程生成的探索工具

而不是直接当生产工具来用。

也想问问大家：

• 有没有人也试过这个项目？


• 你们更常用 MCP 方式还是 CLI 方式？


• 在实际项目里，你们觉得它最有价值的点是什么？

#还有就是，在这想请教一下佬，怎么把别人的github项目链接放出来，又不违反社区规则啊，直接放出来，又要打 开源的模板。请教一下