夜雨聆风上一篇《中外工业软件到底差距在哪里？》发出后，收到一个朋友的私信，让我聊聊AI对工业软件的影响力。恰巧上个月参加了一次由工业软件一线研发人员开展的AI for coding的培训，她用2个月时间完成了一个过去需要用8个月左右才能完成的一个业务逻辑超复杂的功能开发和测试，bug的数量不到过去1/20，功能在用户端上线后基本上是一次性通过，证明了AI for coding在工业软件研发领域的巨大价值。但是在实战过程中，也发现了不少隐患和问题，今天我就结合那次培训，借花献佛，谈谈AI对工业软件的影响。这篇文章可能很长，我会分几期去写。
AI for coding的基本流程是：业务逻辑梳理—>代码分析—>人工审核—>代码生—>代码审阅—>问题排查—>迭代优化。我就结合工业软件的场景，一个一个来谈对工业软件可能产生的影响。事先声明，AI for coding或者AI for Industrial software是一个重度人机交互的过程，这篇文章只探讨AI本身对软件的影响，不考虑人因。一家之言，仅供参考。
做软件的第一步就是业务逻辑梳理，简单来说就是写需求。很多人觉得很常规，青铜用word/wps，黄金用禅道等协同工具，钻石可以用Doors，到了王者就可以用UML或者MBSE了。但是这里面有个巨大的问题：AI能够准确理解这些用自然语言或者UML、SysML语言构建的需求么？答案是：不能！原因主要在两方面：一方面当然是描述客户的业务需求是否准确，这里面有很多方法，但是主要考验的还是人对业务需求的理解，这方面不展开讨论；还有一个重要的原因是当前AI抗拒复杂但优雅的排版和繁琐的描述，Cloudflare的实测数据：同一篇博客，HTML 16180个token，转成md只要3150个。一篇博文压80%的token，意味着同样的LLM预算可以处理7-17倍的请求。换句话说，AI更喜欢那种平铺直叙、没有复杂排版的需求描述，而不是现在的Word、html或者sysml。
我们再来看AI for Industrial software，目前几乎所有管理软件的用户交互都是基于Html呈现的，也就是说无论输入还是输出，对于AI来说，都不算特别友好。CAD、CAE之类的工具软件就更为糟糕，他们的输入端和输出的结果几乎都无法接入AI，目前我只看到达索做了一些尝试，大体的逻辑还是通过API接口去实现和AI的互通，难以做到目前类似飞书、腾讯ima那样，All in AI。
有人可能会问：通过API接入AI和整个软件All in AI有什么差别呢？当前可能确实差异不大，但是时间长了，差距就会越来越大，核心就是今年被Openclaw点燃的Skill。为了方便大家理解什么是Skill，我借用知乎上的一个图解释一下。
真正把AI从一个聊天工具或者查询工具变成能干活的机器的，是Skill。比如我今天的工作是要设计一个齿轮。一般的流程是：启动CAD软件—>新建一个零件模型—>启动草图功能—>调用绘图工具绘制齿轮草图—>选择拉伸—>输入齿轮的厚度—>建模完毕保存。
API的方式是：需要事先将上述的建模过程通过API传递给AI进行训练，训练好AI模型以后，AI才能准确理解你的建模意图，也就是说如果建模的过程或者建模的内容每次都不一样，就需要对AI进行反复的调试、校准，这就需要大量精准的数据进行投喂，否则就很容易出现幻觉或者无法给你一个预期的成果。而如果是CAD All in AI以后，AI会在你建模的时候实时记录你的建模习惯和建模内容，形成记忆，并将其转换为Skill，这样你在未来的某一天，需要再次设计齿轮的时候，只需要给定一个明确的输入，AI就会用你习惯的思考和操作提供一个可靠的齿轮模型。
总结一下：API方式接入的是你的输入内容和思考之后的结果，并试图推导你的思考过程，但不一定正确——Deekseek能火，最主要的也是将这个推导的过程给呈现出来了。而All in则是记录你的思考和操作的过程，从而形成记忆，并将记忆变成Skill提供给AI模型，从而让AI模型输出的结果更接近你的设计意图。因为它的推导过程完全是你的思考和操作过程，所以一定更符合你的预期，推导的结论也就更加可靠。
所以我认为，未来决定AI for Industrial software的，是工业软件的自主学习能力，而非现在很多专家院士说的，用工业大数据训练出一个普适性的、精准的工业领域的大模型的能力。因为AI的基础就是线性代数+统计学，提供的回答只是一个统计意义上最高得分的答案，除非让它不断的记录人类的思考和行动过程，否则永远不可能训练出一个像人一个思考和行动的模型。
现如今，很多互联网公司都开发了类似Openclaw的skill工具，但是主要还是服务于程序员及文字工作者，总体来看应用场景并不丰富，做工具类工业软件企业不妨考虑一下，将skill工具接入自己的工业软件，形成一些标准化的作业模块，也就是KBE模板或者仿真模板，而非过去那样纯靠二次开发。目前github上已经有了一个Text to CAE的开源项目（https://github.com/Cai-aa/text-to-cae），已经开始做类似的尝试，有兴趣的可以自己研究。
管理类工业软件的公司，可以考虑逐步把交互功能“对话”化、直至完全后台化，仅靠对话就能完成数据管理和流程管理。比如可以通过对话告诉PLM系统：请帮我发起一个发动机叶盘的变更申请。AI就会自动将PLM库里面所有已发布的发动机叶盘推给你，请你选择那个需要变更的对象。你确定了以后，AI会自动帮你做影响分析，包括这个叶盘被哪些其他的发动机型号引用。并且会去同样AI化的ERP、MES系统中查询当前是否已经投料、在制品在哪个工位上，如何处理等等，而不是像现在这样完全靠人和接口去查询、选择、填写和判断。