Runwise 增长研究院

2026-08-28

Runwise 增长研究院

08/28/2026
企业AI创新

100多家企业已在用西门子工业Copilot，但AI写PLC代码真正的门槛不在生成，而在验证。

一句话看懂：西门子工业Copilot已在欧美100多家企业使用，但AI写PLC代码的真正难点不是生成，而是验证。西门子的做法是把AI接进TIA Portal，让生成结果变成可编译、可测试、可仿真的工程对象，而不是让聊天机器人绕过工程师直接控制机器。公开资料并未证明Copilot强制所有输出经过统一验证关口，真正的管理任务是企业根据错误后果，把代码审查、编译一致性检查、单元与异常工况测试、现场审批四道关口写进自己的工程制度。

为什么AI会写PLC代码以后，企业还要自己建立验证关口？

2024年10月，西门子与微软披露，欧洲和美国已有100多家企业在使用Siemens Industrial Copilot；同一份公告还写到，超过12万名工程师“可以”利用这套助手。两个数字很容易让人得到一个激进结论：生成式AI已经从办公桌进入工厂，开始大规模替工程师编写机器控制程序。

但更准确的读法是，100多家是企业层面的使用口径，公告没有拆分付费客户、试点客户与全面生产部署；12万则是已经使用西门子TIA Portal工程软件的用户规模，他们有机会用上Copilot，而不是12万名Copilot活跃用户。西门子没有公开个人日活、周活或持续使用率。

这组口径差异，恰好点出工业生成式AI真正难的地方。办公助手写错一封邮件，代价通常是重写；PLC程序写错一个条件，可能造成设备误动作、产线停机、产品报废，甚至危及人身与功能安全。工业AI的竞争，不只是让模型更会写代码，而是让生成内容进入一个可审查、可编译、可测试、可仿真、可回滚的工程环境。

西门子的产品动作不是让通用聊天机器人绕过工程师去控制机器，而是把AI接进工程师原来就在使用的TIA Portal。代码可以由AI起草，也可以作为工程对象被查看、修改和编译；Test Suite、PLCSIM Advanced、SIMIT等工具则提供了不同层级的测试与仿真能力。但公开资料没有证明Industrial Copilot会强制所有输出依次经过这些工具，更没有证明所有客户执行同一套下载审批。把可用能力变成必须通过的验证关口，仍取决于客户自己的工程流程、验证制度和责任体系。

一、它面对的处境：自动化工程师短缺，机器代码却容不得草率

工业自动化长期存在一个矛盾：企业需要更快推出新设备、改造旧产线，能够理解控制逻辑、现场工艺和安全约束的资深工程师却很稀缺。大量时间没有花在创造新控制方案上，而是消耗在重复编写代码、查询手册、配置传感器、搭建人机界面、迁移旧项目和补文档。

生成式AI看起来正适合处理这些工作。工程师用自然语言描述需求，模型可以在几秒内给出程序段、解释旧代码，还能生成界面与说明。问题是，工业代码不是一段孤立文本。它依赖具体PLC型号、输入输出点位、设备网络、变量定义、功能块、故障状态、节拍要求和企业自己的编码规范。同一句“电机异常时停机”，在不同机器上对应的信号、联锁和复位规则可能完全不同。

通用模型缺少这些项目语境。它可能生成语法正确却引用了不存在变量的代码，也可能漏掉某个异常工况，或者给出与现场安全回路冲突的处理。更棘手的是，自动化程序通常会在项目交付后运行多年，后来接手的工程师要能理解、修改和追溯。一次看似省时的生成，如果留下不符合公司规范的逻辑，可能把成本推迟到调试和维护阶段。

因此，西门子要解决的不是“让AI学会Structured Control Language”，而是把模型放回工业工程系统：让输出对接项目里的具体对象，让工程师在正式项目中看到和修改建议，并让原有的版本、编译、测试和仿真工具仍然可用。至于哪些检查必须完成、谁有权批准下载，产品接入本身不会替客户作出制度决定。

二、它做了什么：把生成式AI变成工程流程的一层，而不是机器的直接操作者

1、先接进TIA Portal，让AI输出从聊天文本变成工程对象

2024年4月，西门子宣布Industrial Copilot for Engineering连接TIA Portal，并计划当年夏季通过Siemens Xcelerator提供；产品于2024年7月上市。它可以根据自然语言生成Structured Control Language代码，TIA Portal能够直接接收建议，不需要工程师在公共聊天窗口与工程软件之间复制粘贴。

这个细节比“AI会写PLC代码”更重要。复制粘贴只能减少打字，接入TIA Portal则让建议落到具体项目中，和变量、功能块、HMI及其他工程对象一起被管理。工程师可以继续在熟悉的环境里查看、修改、编译和测试，而不是把核心工业代码带到一个脱离项目语境的工具中。

西门子还把代码解释、自然语言检索手册和WinCC Unified基础可视化放进同一入口。工程师不仅能让AI生成一段SCL程序，也能让它解释遗留代码、定位相关手册章节，或先搭出机器面板的页头、导航和基础画面。动作的共同点不是功能多，而是减少工程师在文档、聊天工具和项目文件之间来回切换。

2、用领域知识和项目语境限制生成，而不是只靠提示词

2024版Copilot结合了西门子的工业领域知识与Microsoft Azure OpenAI Service。自助版产品把本地TIA Portal工程系统连接到客户自己的Azure OpenAI服务；西门子还允许客户使用私有Azure OpenAI实例，并说明客户数据不会用于重训模型。

这解决了两类问题。第一类是知识范围：模型回答TIA Portal任务时，可以围绕西门子手册、自动化语言和工程环境，而不是从互联网通用知识里猜。第二类是数据控制：客户不必把项目公开给消费级聊天工具，可以在自己的企业云资源、身份和权限框架中使用模型。

不过，“私有实例”不等于“全部在本地”。提示词、代码和生成结果仍要经过企业选择的云服务与区域配置，日志、访问权限、内容监测和数据保留也要逐项治理。2024年11月，西门子提出为Operations Copilot提供本地硬件软件包以实现完整数据主权，但当时使用的是“计划”表述，不能反过来说成Engineering Copilot已经普遍离线部署。

到2026年4月，西门子又推出已正式可用的Eigen Engineering Agent。它不只读取提示词，还读取TIA项目里的数据结构、功能块、参数和组件关系，并通过多步推理和自我修正，按客户标准完成代码、HMI和设备配置等任务。这个演进说明，工业AI的重点正在从“模型知道工业常识”转向“模型知道这一个客户、这一个项目正在造什么”。

但项目语境只能减少配错，不能消除错误。西门子另有一份面向其Generative AI Chat／Search Service的通用条款，要求用户独立核验输出，并测试、审查代码中的错误、缺陷和漏洞。这只能说明西门子对通用生成式AI服务给出了风险提示；现有公开资料不能证明该条款直接构成Industrial Copilot for Engineering的许可条件，也不能据此判断thyssenkrupp项目或其他现场的合同责任。Industrial Copilot客户仍需以实际产品许可、采购合同、行业规范和内部制度为准。

3、把代码、可视化和配置一起生成，减少的是重复工程劳动

Industrial Copilot最早落地的动作包括生成SCL代码、解释代码块、创建基础WinCC Unified可视化和检索工程手册。2024年联合公告称，工程师可以在30秒内创建面板可视化，生成的PLC代码有时只需要20%的适配。

这两个数字有传播力，但不能扩大解释。“30秒”没有公开样本复杂度，“20%适配”也没有说明是按代码行、工时还是修改项计算，更不等于代码准确率达到80%。它们是西门子与客户公告中的效率口径，不是独立审计结果。真正可以确认的是，产品把原本由工程师手工完成的初稿、骨架和检索工作，提前交给了AI来做。

thyssenkrupp Automation Engineering的电池质量检测设备提供了更具体的场景。这台设备用传感器、摄像头和测量系统，在多个阶段检查电池单元质量，并识别超出阈值的放电。Copilot参与TIA Portal项目创建、SCL代码、WinCC Unified可视化，还协助数据管理、传感器配置和满足检验要求的过程报告。

这些任务看似琐碎，却是复杂设备工程里最容易堆积工时的部分。让AI先生成重复对象，资深工程师就能把时间放在控制策略、异常工况和整机调试上。这里的经营价值不是“少雇多少工程师”，而是同一支团队能否缩短项目交付周期，缓解资深人员成为瓶颈。

4、在代码与真实PLC之间保留可用的编译、测试和仿真能力

AI把建议送入TIA Portal项目，并不等于代码已经下载到真实机器。西门子的产品资料证明Copilot与工程项目相连；另一套TIA Portal Test Suite手册则说明，当用户主动执行Application Test时，工具会先编译PLC程序并检查一致性。编译失败，测试流程停止；编译成功，程序可被下载到PLCSIM Advanced创建的模拟PLC实例中运行，并输出每一步的Pass／Fail结果和日志。

这里必须区分“工具能做什么”和“Copilot强制做什么”。Test Suite与PLCSIM Advanced提供的是可被客户采用的验证能力，不是公开证据所证明的Industrial Copilot统一内置关口。Test Suite手册所说的“只让测试过的代码在真实机器上使用”，是该测试方案的设计目标与建议流程；公开资料没有证明每个Copilot客户都购买、配置并强制执行这套顺序。

复杂项目还有更多可选工具。西门子SIMIT官方页面说明，它可以用真实或虚拟控制器开展验收测试与虚拟调试，并支持结合PLCSIM Advanced的软件在环以及连接真实自动化硬件的硬件在环。Process Simulate官方页面则说明，它可以在三维制造环境中连接TIA Portal、PLCSIM Advanced或实际PLC逻辑，验证和优化机器人工作单元、生产线安装与调试。这些页面证明西门子工具组合具备更深的虚拟验证能力，但没有证明Industrial Copilot输出会自动进入SIMIT或Process Simulate。

用同样的框架诊断你的业务

如果你也在思考如何把AI接进核心工程或业务流程，又担心验证和责任边界，可以用我们的AI顾问先诊断一下自己的业务场景。

免费体验 Upskill AI 顾问 →

因此，从管理流程看，客户可以把现有能力组织成四个彼此独立的关口。第一道是代码审查，确认变量、命名、数据类型和控制意图符合项目标准；第二道是编译与静态一致性检查，先挡住语法和工程对象错误；第三道是单元、集成与异常工况测试，把程序放进模拟PLC或数字孪生里运行；第四道才是现场调试、验收和有权限人员批准下载。这个四层关口是本文基于工具能力提出的管理建议，不是西门子已经替所有客户执行的统一制度。

关口	工具/动作	主要目的
第一道	代码审查	确认变量、命名、数据类型和控制意图符合项目标准
第二道	编译与静态一致性检查	先挡住语法和工程对象错误
第三道	单元、集成与异常工况测试	把程序放进模拟PLC或数字孪生里运行
第四道	现场调试、验收和有权限人员批准下载	确保真实机器安全

要让建议真正落地，企业还需要把测试对象和风险等级绑定。只改一段界面文字，与改动安全互锁、急停复位或机器人运动路径，不能共用同一审批强度。低风险对象可以允许自动生成后由一人复核；涉及控制逻辑的变更应要求明确测试用例；影响安全与设备动作的变更，还要覆盖断线、传感器失效、超时、重启和人工接管等异常场景。风险分级、测试覆盖和批准权限都属于客户治理设计，不能从产品功能清单直接推导出来。

版本管理同样不能省略。工程团队可以保存生成前后的差异、提示输入、采用或拒绝的建议、测试结果与批准人，才能在设备异常时追溯哪一处变更进入了控制器。若模型升级后同一提示产生不同输出，没有这样的记录，企业很难复现问题。公开资料没有证明所有客户已经统一保存这些记录；它仍是组织将生成式AI纳入变更管理时需要补上的控制点。

生成变快以后，验证反而更重要。过去工程师花一天写代码，可能愿意花半天测试；现在AI十分钟生成多个版本，组织若仍按原节奏抽查，错误代码会更快堆积。企业需要预先定义代码规范、测试用例、异常场景和发布权限，让每次高风险生成都有明确去向。西门子提供了把建议留在工程项目中并继续编译、测试、仿真的条件；客户是否把条件变成不可跳过的流程，决定了AI是在缩短交付周期，还是把返工推向现场。

5、用真实机器共创，但把试点、推广和完成状态分开

西门子没有只在内部实验室演示Copilot。2023年，它与Schaeffler展示了生成式AI在生产机器上辅助PLC代码和故障处理；2024年，thyssenkrupp Automation Engineering把Engineering Copilot集成到电池质量检测设备，并计划自2025年在全球地点和产品范围推广。

2025年5月，西门子把口径更新为“正在全球推广”，并称thyssenkrupp工程师报告了代码质量和开发速度改善。这个进展能证明项目没有停留在签约与演示，但公司仍未披露覆盖了多少地点、多少机器、多少工程师，也没有给出统一的工时、缺陷率或停机数据。因此，正文不能把“正在推广”写成“已经完成全球部署”。

还需要补一个主体变化。2026年4月，thyssenkrupp完成向Agile Robots出售Automation Engineering业务，该业务随后以Krause Automation名义运营。这不改变2024年真实机器集成的历史事实，却意味着把它称为“thyssenkrupp当前业务”已经不准确。工业客户案例不是一块贴上去就不变的招牌，组织归属和推广责任也会变化。

西门子自己的Erlangen电子工厂则把Operations Copilot用于焊接设备。它把机器错误码翻译成自然语言，再结合机器细节、历史、手册和备件清单提出处理建议。这里的AI仍是诊断与建议层：维修工程师可以更快理解故障，但建议是否适用于现场、是否需要停机和更换部件，仍要由有权限的人确认。

三、结果与演进：采用规模开始出现，经营结果仍缺一张统一账表

从产品采用看，Industrial Copilot已经越过“只发布不使用”的门槛。西门子在2024年10月披露欧美100多家企业正在使用；thyssenkrupp、Schaeffler和西门子自有工厂提供了工程与运维场景；Engineering Copilot已经进入TIA Portal和Xcelerator的正式产品体系。

但采用规模的证据仍有三层。第一层是12万TIA Portal用户，这是潜在可接入基础；第二层是100多家使用企业，这是组织采用；第三层才是个人活跃、持续使用和生产覆盖，西门子尚未公开。把前两层直接写成第三层，会高估实际渗透。

效果证据也以公司和客户自报为主。30秒可视化、只需20%适配的代码、代码质量和开发速度改善，都说明重复工程任务存在压缩空间，但没有公开样本、基线、缺陷率和独立审计。西门子没有把Copilot单独产生的收入、续费率、项目毛利或客户停机改善从其他软件与自动化业务中拆出来。

2025年，西门子宣布工业AI Agent架构，希望从回答问题走向自主执行完整流程，并提出客户生产率最高提高50%的愿景。这个数字是“目标”或“设想”，不是客户普遍实现的结果。2026年4月，Eigen Engineering Agent在19个国家、100多家客户试点后正式可用，说明Agent不再只是未来概念；但这批试点与2024年Industrial Copilot的100多家欧美使用企业不是同一个统计口径。

更重要的是，Agent会自我检查，不等于可以自主控制真实机器。Eigen官方产品页明确写到，它能在TIA Portal里生成测试逻辑，并修复编译或语法错误；这证明的是工程Agent的产品能力，不是现场验收已经完成。真实设备仍存在功能安全、现场工艺和变更授权。随着AI从“给建议”走向“改项目”，组织需要提升的不是笼统信任，而是权限分层、测试覆盖和变更审计。

四、为什么不能盲目照搬：工业AI省下的是生成时间，新增的是验证压力

第一，TIA Portal的价值建立在高度结构化的工程资产上。西门子能把AI接进代码、HMI、设备和项目对象，是因为这些对象已有统一平台、接口和版本关系。系统割裂、变量命名混乱、旧代码无人维护的企业，直接加一个Copilot，很可能只会更快制造不一致。

第二，工业语境不是提示词模板。模型需要设备清单、功能块、企业标准和历史项目，但输入越深，暴露的工业知识产权越敏感。私有Azure实例、不用于模型重训和本地化选项是必要条件，却不能替代身份权限、网络分区、日志策略、数据区域与供应商审查。

第三，测试能力决定生成能力的上限。若团队没有自动化测试、PLCSIM、虚拟调试和明确验收标准，AI生成越快，验证积压越大。语法通过只能证明代码可编译，不能证明安全互锁、异常工况和设备节拍正确。

第四，多层供应商依赖会进入核心工程。Copilot依赖TIA Portal、Xcelerator、Azure OpenAI、许可和后续Agent接口。模型版本、云区域、价格、服务条款或API变化，都可能改变输出和成本。本地部署能减少一部分数据外流，却会增加算力、更新、模型运维和安全补丁的复杂度。

第五，工程责任不能靠一份通用条款替代。西门子面向Generative AI Chat／Search Service的条款体现了核验输出和审查代码的一般风险提示，却不能直接证明Industrial Copilot客户合同如何分配责任。企业需要单独核对适用的产品许可、采购合同、行业监管和内部授权，并为现场结果保留明确责任人。

五、给管理者的启示：把可用工具变成企业自己的验证关口

西门子案例可迁移的第一条判断，是把AI放进原有工作系统，而不是另开一个聊天入口。只有当生成结果成为可追踪的工程对象，后续版本、权限、测试和审计才接得住。对软件、制造、建筑和能源企业同样如此：AI的入口应尽量贴近正式生产系统，但执行权不应因此自动放开。

第二条判断，是用风险决定自动化深度。文档检索、代码解释和界面初稿可以较早推广；控制逻辑、设备配置和真实下载则需要更严的测试、双人复核或审批。不要用一个统一的“AI采用率”管理所有任务，而要按错误后果划分权限。

第三条判断，是同时度量生成效率与验证成本。若只统计AI节省了多少编写时间，而不统计返工、缺陷、仿真、调试和事故险情，管理层看到的只是半本账。真正有意义的指标应包括从需求到测试通过的总周期、首次通过率、上线后缺陷、回滚次数和工程师复核工时。

西门子已经证明，生成式AI可以进入工业工程环境，成为代码、可视化、配置和检索的工作层；它没有证明所有AI代码都被产品强制送入统一验证关口。真正的管理任务，是企业根据错误后果选择Test Suite、PLCSIM、SIMIT或其他验证手段，把测试覆盖、审批权限和责任记录写进自己的工程制度。AI可以先写；哪些检查不能跳过、谁批准它进入真实机器，仍要由企业明确。