AI会写PLC了，工程师靠什么？

AI开始写PLC程序了，自动化工程师的饭碗还稳吗？

10月7日，工业技术媒体 Design News 报道，CODESYS 正在与 Intel 探索 AI 辅助 PLC 编程。通过 AI 接口，工程师可以让 AI 参与控制程序开发。CODESYS 还计划演示如何利用 AI 开发一个冰箱控制功能模块。

更值得注意的是，这不是简单地把代码生成器接进聊天框，而是让 AI 通过 MCP 接口，与 CODESYS 开发环境直接交互。
这意味着，AI 开始从"帮你写几行代码"，走向**"帮你完成一部分工程开发工作"。**

那问题来了：PLC 工程师是不是要被替代了？

真正的变化可能恰恰相反。

01最容易被压缩的，是重复性高、规则明确的编程工作

首先，最容易被 AI 压缩的，是那些重复性高、规则明确的编程工作。
比如生成常规功能块、补充变量声明、解释已有程序、编写注释、创建测试用例，甚至根据明确的控制要求生成一部分程序。
这些工作过去需要工程师花时间完成，现在有机会交给 AI 辅助处理。

但别忘了，工业现场最难的，往往不是把程序写出来。
一台设备启动后，传感器信号异常怎么办？几个动作同时发生时，怎样避免冲突？设备急停后，怎样确保系统进入安全状态？工艺条件变化了，原来的控制逻辑还成立吗？

这些问题，不是代码能编译通过就算解决了。

02AI可以写程序，但证明不了设备能安全运行

AI可以帮你写程序，但不能因为程序写出来了，就证明这台设备可以安全运行。
这才是工业控制和普通软件开发很不一样的地方。

所以，更值得关注的不是 AI 会不会写梯形图、结构化文本，而是它能不能真正进入控制工程的完整流程：

理解需求、生成程序、编译检查、仿真测试、现场验证，最后由有权限的工程师审核和部署。

当然，这条路还有很长的距离。编译通过不等于逻辑正确，仿真通过也不代表所有现场风险都已排除。
但趋势已经值得重视了。

03以后最危险的工程师，是只会写程序、却不懂设备为什么这样运行的人

过去，一个自动化工程师的效率，很大程度上取决于他写代码的速度、熟悉多少指令、积累了多少程序模板。
未来，这些能力依然重要，但可能不再构成最主要的差异。
真正拉开差距的，是：

你能不能把工艺要求转化成正确的控制逻辑，能不能识别异常工况，能不能验证 AI 生成的程序，还能不能在设备出问题时迅速找到真正的原因。

说得直接一点：

以后最危险的，不是不会用 AI 的工程师，而是只会写程序、却不懂设备为什么这样运行的工程师。

04对工业软件企业来说，这个变化也很重要

如果 AI 能够降低一部分编程和测试成本，未来自动化项目的竞争，可能不再只是比谁写代码更快，而是比谁更懂工艺、更懂现场，谁能把经验沉淀成可以复用的控制模块和工程方法。

所以，AI进入PLC编程，真正值得关注的，不是机器会不会抢走工程师的工作。
而是当写代码越来越容易，我们究竟要把工程师的时间，重新投入到什么地方？

这个问题，可能比 AI 能写多少行代码更重要。