▎AI 时代，工控工程师的价值在哪里？（下）
当AI能看懂你的TIA Portal项目结构、能用GitHub开源工具生成完整的PLC工程、能通过MCP协议操控CODESYS——你引以为傲的"编程能力"还值多少钱？
上篇我们梳理了六个真实案例：ABB的学术研究、CODESYS的官方MCP Server、Intel的本地AI方案、法国公司的T-IA Connect、GitHub开源项目、以及跨平台代码转换工具。
这些案例证明了一件事：AI写PLC程序已经不是"能不能"的问题，而是"有多好用"的问题。
现在该回答那个真正让人不安的问题了。
---
一、技能重构：从"写代码的人"变成"定义需求的人"
翻开任何一本PLC编程教材，前几章都在教你指令——LD、AND、OR、TON、MOV、MOVE_BLK。工程师花了大量时间背诵指令、练习语法、调试编译错误。
AI正在让这件事变得不再重要。
未来五年工控工程师的价值公式
2020年的竞争力：精通TIA Portal操作 + 熟练手写SCL/LAD + 熟悉西门子指令集
2026年的竞争力：理解工艺需求本质 + 能把需求精准翻译给AI + 能验证AI产出是否安全可靠
2030年的竞争力：跨OT/IT的系统架构能力 + AI工具链编排能力 + 特定行业的深度工艺知识
关键变化："怎么写"被AI接管，"写什么"和"为什么这样写"成为核心竞争力。
一个现实的类比：20年前招聘程序员要求"精通C语言指针操作"，今天招聘程序员要求"能设计系统架构并善用AI工具"。技能栈的顶端从"操作层"上移到了"设计层"。
工控行业正在经历同样的位移。
---
二、信任危机：AI生成的代码，你敢直接上产线吗？
这是AI应用于工控编程最核心的障碍。
互联网行业的AI可以灰度发布——1%的用户先试，出问题马上回滚。工控行业不行。一个错误的控制指令可能导致设备损坏、产线停摆、甚至人身伤害。
CODESYS的官方文档对这个问题有清醒的认知。他们的AI帮助聊天机器人明确标注："无AI幻觉——仅使用CODESYS在线帮助的内容，找不到合适信息时不会返回结果。" 这个设计选择本身就是在说：在工控领域，"不确定性"比"不知道"更危险。
谁对AI生成的PLC代码负责？三个现实问题
问题1：AI错误导致停机，算谁的责任？
目前法律框架下，责任在工程师——因为最终是工程师决定"采用"这段代码。AI是工具，不是法律主体。
问题2：你的判断力还够用吗？
当AI在10秒内生成了你手动需要4小时才能写完的代码，你有没有能力在合理的时间内验证它的正确性？这可能是比"AI能不能写"更严重的问题。
问题3：过度依赖的危险
一个新人工程师如果从入职第一天就用AI写代码，他可能永远不知道REAL和LREAL的精度差异、不知道Modbus的字节序问题、不知道什么情况下需要用AT关键字而不是SWAP指令。基础能力的空心化，是AI时代最大的隐性成本。
---
三、数据主权：你的PLC代码将被谁看到？
T-IA Connect默认支持云端AI（Gemini、Claude、ChatGPT），这意味着你的项目结构、数据类型、标签表——需要发送到谷歌、Anthropic或OpenAI的服务器。
对于汽车主机厂、军工企业、核电行业、化工巨头来说，这可能是不可接受的安全风险。一个典型的顾虑是：你正在给某款未发布的新车型写控制程序，AI需要读取你的DB块结构和标签表——这些信息一旦上传到海外AI服务器，就产生了数据出境的问题。在中国，这意味着需要遵守《数据安全法》和《个人信息保护法》。
这就是为什么CODESYS和Intel合作的OpenVINO方案备受关注。它在Intel NUC上本地运行LLM，整个推理过程不需要互联网连接。代码和提示词不出工厂。
但这带来了另一个问题：本地模型的能力上限远低于GPT-5和Claude。 安全和能力之间的取舍，将是未来几年工控AI化绕不开的课题。最可能的折中方案是：本地模型处理常规任务，云端模型处理复杂分析——但哪种数据可以"出去"、哪种必须"留在厂内"，需要企业自己建立明确的分级标准。
---
四、职业路径变化：三个新角色正在出现
AI不会消灭工控工程师这个职业，但会把它拆分成几个新角色。
角色一：AI辅助系统设计师。 传统工程师写代码实现控制逻辑。新角色用自然语言描述需求，AI生成代码初稿，工程师负责验证、调优、集成。工作重心从"码代码"变成"定方案"。
角色二：OT/IT融合工程师。 T-IA Connect的创始人称之为"OT与IT的桥梁"。MCP服务器、REST API、CI/CD流水线、Git版本管理——这些原来是IT领域的工具，正在进入工控领域。能同时理解PLC和Web服务的人，将是抢手人才。
角色三：AI验证与安全工程师。 一旦AI生成的代码开始进入实际项目，就需要有人专门负责"验证"——不是验证语法（AI已经很擅长），而是验证安全逻辑：联锁条件是否完整？急停逻辑是否覆盖所有工况？危险区域的访问控制是否严格？
---
五、结语：不是替代，是重新定义
2023年，ABB研究员在论文里写："GPT-4可以在多数情况下生成语法正确的ST代码。"当时这句话被当作技术新闻。
2026年，CODESYS MCP Server拿下年度产品奖、T-IA Connect实现AI实时读取项目上下文、GitHub上MIT许可证的开源工具能一键生成完整工程。
从"有趣的实验"到"拿奖的产品"，24个月。
但回看PLC替代继电器的40年历史，结论完全一致：新工具消灭的不是职业，是旧的工作方式。 那些在1980年代学会了梯形图编程的电工，工资比只会接继电器的同行高得多。
今天站在同一个十字路口。AI在工控编程领域的渗透速度，比大多数人预想的更快。但它替代的不是工程师，而是"纯写代码"这种工作方式。
今天就可以做的三件事
第一：去GitHub看一下TIA Portal Openness MCP项目（搜`bulaofen0036/TIA_Portal_Openness_MCP`），了解MCP协议的基本概念。不需要学会编写，只需要理解它能做什么。
第二：下次写PLC程序时，试着用ChatGPT或Claude生成一个SCL功能块的初稿草案，然后人工验证、修改。感受一下"AI写初稿 + 人做审校"的工作流。
第三：把你所在行业的典型工序、安全联锁条件、控制策略用文字整理出来。这些"用自然语言描述的工艺知识"，将是AI时代你最值钱的资产。
---
AI 不会淘汰工控工程师。但会淘汰只会写代码的工控工程师。
你现在做的每一个选择，都是在回答同一个问题：五年后，你是那个用AI加速工作的人，还是被AI加速淘汰的人？
下一主题
