1. 工业软件为什么会突然走到"该上AI"的十字路口
过去十年我一直在做工业软件相关的工作,最开始是给三维CAD软件写二次开发插件,后来带队做过工艺规划系统,也参与过几条产线的数字化交付。前几年圈子里的共识是:工业软件的价值在于严谨,在于把工程师脑子里的规则固化成流程和参数。这个认知没错,但到了2024年到2025年,整个风向明显变了。越来越多的客户在招标文件里直接写"具备AI辅助能力"作为加分项,甚至有甲方私下跟我说,他们想看的不是多一个自动出图按钮,而是软件能不能在没人盯着的时候自动判断设计合不合理、工艺能不能加工出来。
这种需求不是凭空冒出来的。工业软件过去几十年做的事情,本质上是在"精确记录"——把图纸精确到每一个圆角半径,把工艺路线精确到每一道工序的节拍,把BOM精确到每一个物料编码。但"精确记录"只能解决"已知的已知",也就是工程师完全清楚该怎么做、只是需要工具帮忙执行的情况。真正的死角在于"已知的未知"和"未知的未知":比如一个资深结构工程师扫一眼图纸就知道这里应力会集中,但说不清具体数值和修正方案;比如工艺师知道某个特征加工出来会有振刀风险,但对面的年轻工程师根本意识不到这个风险存在,等试加工出问题才回头改图纸。
AI在这块的价值不是替代精确计算,而是把工业软件从"人告诉它怎么做"升级成"它主动提醒人哪里可能有问题、哪里还有更好的做法"。用一句好理解的话说:传统工业软件像一支画图笔,你握着它描线、标注尺寸;AI加持之后的工业软件更像一个坐你旁边的老工程师,你画一步它看一眼,觉得不对会敲桌子提醒你,偶尔还直接帮你把重复性的工作顺手干完。
这篇文章就把我过去一段时间做工业软件AI落地的一些真实过程写出来。不吹概念,不画大饼,就讲几个已经跑通或者踩过坑的方向:怎么把AI接进CAD、怎么让AI读懂图纸语义、怎么做工艺智能推荐、为什么现在的Agent架构在工业场景里那么难落地。适合正在做工业软件产品、或者公司想给现有系统加AI能力但还没想好从哪里下手的同行看。
2. AI到底能在工业软件里干什么:先分清"辅助画图"和"辅助思考"两件事
很多团队一上来就想做"AI自动设计",这是最容易翻车的地方。自动设计在现阶段基本不是产品需求,而是研究课题。真正该先想清楚的问题,是你要做的是"辅助画图"还是"辅助思考"。这两个方向的技术栈完全不同,落地的难度和验收标准也完全不同。
2.1 AI辅助画图:把重复劳动变成一句话指令
辅助画图解决的是"图纸生成和执行层面的效率"问题。典型的场景有几个:标准件库的调用、参数化模型的变型设计、二维图纸的自动标注、相似特征的批量创建。这些工作的共同特点是——规则明确、操作重复、消耗工程师大量无技术含量的点击时间。
我做过一个比较成功的案例是给一款冲压模具设计软件加了一个自然语言驱动的标准件调用功能。过去工程师要画一颗M8内六角螺钉,需要打开标准件库、过滤型号、选择规格、确认长度、拖拽到装配树、调整连接关系,整套流程快的话两分钟,慢的话五分钟。我们做的方案是用一个基于大语言模型的任务解析器,把"在A面四个角加M8×30内六角螺钉,沉孔深度5mm"这句话解析成结构化指令,然后调用CAD内核的API去自动执行。
这里有个关键技术选型是:自然语言解析用大模型做,但底层几何操作绝对不能交给大模型直接生成代码跑,而是要走一套预定义的API指令集。大模型只负责把自然语言变成JSON格式的操作序列,CAD这边再写一个解释器去执行JSON。这么做的好处是安全可控:大模型永远接触不到几何内核,胡说八道也不会把模型搞坏。我见过有团队让大模型直接生成CAD的脚本代码,结果模型生成了一段在无限循环里求交集的脚本,直接把内核跑崩了,整个工程文件打不开。
辅助画图的核心检验标准是"可逆"和"可预期"。AI生成的每一步修改,都要能回退,都要能展示给工程师确认,而不是像魔改一样一下子把整个模型变了个样。我们在界面上做的交互是:AI解析完指令后,先把操作列表以清单形式展示出来,每条操作后面跟着一个勾选框,工程师可以人工删掉某一步不想执行的操作,再点击执行。这个交互设计一开始有人嫌多此一举,但实际用下来发现工程师反而更信任系统了,因为每一步改动都在他们的掌控范围内。
2.2 AI辅助思考:从"画得出来"到"画出来的东西对不对"
辅助思考解决的是"设计合理性"的问题,这是AI真正值钱的方向。具体包括:结构强度风险的预判、可制造性的评估、成本敏感度的提示、相似历史方案的检索推荐。
这个方向在技术上完全不是同一个量级的。辅助画图本质上是NLP加API控制的组合,而辅助思考本质上需要一个能理解图纸语义的模型。图纸在工业软件里不是一个页面,而是一棵完整的拓扑结构树:零件下面有特征,特征下面有约束,约束下面有尺寸和几何引用。要让AI理解"这里有个直径8mm的孔,贯穿两个板件,孔的轴线和板面法线夹角12度",得先把这种空间和拓扑关系变成AI能理解的数据形式。
我们做过一个最典型的辅助思考案例是孔特征的加工风险预警。在机加工艺里,细长孔、斜孔、深孔都有各自的加工风险:细长孔容易偏钻,斜孔容易让钻头受径向力打滑,深孔的排屑和冷却都麻烦。传统软件不会管这些,因为建模阶段的目标就是"把孔画出来",加工问题默认留给工艺阶段去发现。我们训练了一个小模型,输入的特征不是像素图像,而是孔的几何参数序列——直径、深度、轴线方向与工件坐标系各轴的夹角、所在壁厚的比值——输出的是风险等级和风险原因说明。
这个功能上线之后,有个结构工程师跟我说他第一次意识到自己经常设计的"通风减重孔"在加工时会那么麻烦。他说以前从来不关心孔怎么加工出来的,反正图纸发出去是工艺科的事。现在软件会在他画完孔的那一瞬间给出提示"该孔长径比超过8,建议改为阶梯孔或提前与工艺科沟通刀具方案",他觉得这个比软件帮他画一百遍倒角都有价值。
辅助思考的核心检验标准是"能不能在错误发生之前拦住它"。哪怕拦住一次,AI在工程师心目中的信任度就建立起来了。如果只是画图快,那叫好用的工具;如果能提前暴露风险,那才配叫"会思考的软件"。
3. 给CAD软件接AI大脑的真实技术框架:从数据管道到模型推理的设计取舍
这个章节我重点讲一个已经跑通全流程的技术架构:怎么把传统CAD软件改造成具备AI识别和推荐能力的系统。整体分四层:数据管道、几何语义化、模型推理引擎、交互反馈层。每一层都有不少坑,我逐个说。
3.1 数据管道:最难的不是模型算法,而是把模型变成模型能读的输入
很多团队做工业AI失败,直接就死在第一步。CAD模型本质上是B-Rep(边界表示)的数据结构,里面有面、边、顶点、曲面方程、拓扑连接关系。这些东西直接丢给神经网络是没法用的,必须转化成适合学习的中间表示。
我们对比过三种方案。第一种是把模型渲染成多视角图片,用CNN去识别,这是市面上很多"AI识别图纸"产品的做法。优点是可以复用成熟的图像模型架构,缺点是丢失了几何精度:图片上是128×128还是1024×1024,对识别结果影响非常大;而且模型旋转一个角度,同一个特征在图片里就完全不同了。第二种是把模型体素化,也就是把空间划分成小立方体网格,这种表示对特征级别的识别有帮助,但分辨率上不去的话,小孔小倒角这些关键特征根本体现不出来。第三种是直接抽取特征参数序列加拓扑图结构,也就是把每一个建模特征变成一个节点,特征之间的父子关系、参考关系变成边,形成一个图神经网络可以吃的输入。
我们最终选了第三种,而且建议做工业软件AI的团队重点考虑这条路。原因是工业模型的特征数量一般不会特别巨大,一个中等复杂度的零件几十个到上百个特征,构建出来的图也就几百个节点,计算压力完全可以接受。更重要的是,这种表示方式和CAD内核的建模历史树天然对应,AI给出的判断结果可以轻松回溯到具体的模型特征上——这一点对工程师的信任建立特别关键。如果AI说"这个孔有应力集中风险",你得能指出是哪个孔,而不是给个红框框说"大概这一片区域有问题"。
数据管道的实施细节上,一个比较容易被忽略的问题是特征参数的归一化。孔径8毫米和孔径80毫米,如果不做归一化直接喂给模型,模型大概率会把尺寸大小的绝对数值当成主导信号,而忽略了形状比例关系这类的相对特征。我们的做法是对所有尺寸类参数除以模型包围盒的对角线长度,得到无量纲的相对值;角度参数都除以180度归一化到0到1之间;布尔类型的参数保持不变。这套归一化规则看起来不起眼,但对模型收敛速度和最终精度的影响非常大。
3.2 几何语义化:让AI知道"这是一个孔"而不是"这里有一组曲面"
纯粹的原始B-Rep数据喂给AI还有一个问题——AI不知道"孔"是什么。在B-Rep里,一个孔表现为一个圆柱面的内表面加上两端的圆环边,从数据结构上看和一根圆柱凸台没有本质区别,就是一个圆弧形的面套一个圆形的边。要让AI真正理解"这是一个通孔、这是一个螺纹孔、这是一个沉头孔",需要先做一步几何特征识别,也就是把底层几何对象归类成高层语义特征。
这一步我们用了一个混合方案:规则引擎加大模型辅助判断。规则引擎负责做最基础的几何计算,比如:检测一个圆柱面的轴线方向和半径大小,计算圆柱面和相邻面的连接方式,判断这个圆柱特征是否贯穿整个实体;然后根据这些几何量打上初始标签。大模型负责处理规则引擎覆盖不了的情况,比如非标的异形特征、复合特征、带辅助基准的特征形态——这些场景规则写不完,让大模型基于特征参数做模式识别更合适。
这里我想重点说一个大模型的温度参数问题。做工业识别任务时,大模型输出端一定要把温度调到接近0,也就是尽量让它做确定性判断,不要引入随机性。这个和做聊天机器人完全是反过来的,聊天需要温度高一点让回复多样化,但工业判断如果同一组输入今天判成通孔、明天判成沉头孔,那工程师肯定会把系统卸载掉。我们调过一次温度从0.1改到0.3,线上测试的识别准确率从98.2%掉到了96.5%,看着好像差别不大,但工程场景里2个百分点的波动往往对应的是几十个模型报错,影响非常直观。
3.3 模型推理引擎:为什么小模型和大模型要分工干活
我们最终的架构是大小模型协同推理,不是啥都丢给大模型。小模型是一个轻量的图神经网络分类器,参数大概在几百万级别,用来做最频繁的特征分类和风险标记,单次推理时间控制在50毫秒以内,这样工程师在画图过程中可以实时看到提示,不用等待。大模型是承载领域知识的研判层,负责做更复杂的推理,比如给出风险解释和优化建议,这个不需要实时响应,可以接受三四秒的延迟。
整个流程是:CAD里每完成一个建模操作,数据管道立刻抽取这个特征相关的数据子图,转发给小模型做初步分类和风险判断。如果小模型判定一切正常,那么界面不会有任何变化——最后时刻系统不打扰,不该刷存在感的时候就不要刷存在感,这一点太重要了。如果小模型判定有潜在问题,再把上下文数据递交给大模型,由大模型生成一段人话解释和修改建议。这种异步的二次确认机制既保证了响应速度,又利用了大模型的理解能力和解释能力。
选模型骨架时我们也犹豫过要不要直接用开源的通用大模型微调就行。实测下来,通用大模型在做CAD特征识别上表现很差,因为它训练的语料里工业软件的数据占比太少。我们试过几个主流开源模型,让它们识别一个带过渡圆弧的方形凸台,输出结果五花八门:有的说是倒角,有的说是圆角,有的说是钣金折弯。最后还是靠自建标注集训练的小模型把精度拉上来的。大模型只保留语义推理部分,这在投入产出比上是最划算的。
3.4 交互反馈层:界面设计的核心是"让工程师觉得AI在听人话"
交互设计这个事不少人觉得是产品经理的活,技术团队不关心。但工业软件AI落地,交互决定生死。我见过的翻车案例中,有一半是模型效果其实还可以,但交互设计完全让人不想用。
我们的交互设计定了三条原则。第一,所有AI提示都要明确指出对应的特征对象,点击提示就能在模型树里高亮定位到那个特征,绝对不能只给一行字让工程师自己找。第二,所有AI建议都只算"建议",默认不自动执行,必须由工程师手动确认,哪怕这个建议已经非常明确、概率高达99%也不自动改模型。第三,AI要能回答工程师的追问——"为什么这么判断",点一下问题旁边的小问号,弹出来的是推理依据的自然语言描述,而不是无用的一堆置信度数字。
这三条原则里第二条争议最大。产品团队一开始坚持要做"一键全自动优化",把AI建议直接应用到模型上,理由是效率更高。我坚决反对:工业软件里任何一个隐形修改都可能引起连锁反应,比如调整孔的深度之后可能会穿透后面的某个加强筋,这件事AI不一定能发现,但工程师一眼就能看出来。AI的定位是让工程师多一双眼睛,而不是替工程师做决策。最后产品妥协成"批量应用"的模式:工程师可以勾选多条建议然后一键应用,但必须先看到完整的修改预览和碰撞检测结果。
4. 模型训练与数据标注的实战心得:工业数据的脏坑比模型结构更值得操心
做工业AI,真正投入最大的不是调模型,而是准备数据。数据标注的质量直接决定模型上限,这一点在工业领域比互联网领域更加成立。原因很简单:互联网数据靠爬虫能搞到海量样本,模型可以在千万级语料上预训练;工业数据要么在企业的服务器里,要么在工程师的硬盘里,数量天然少,而且每一条都需要领域专家级别的标注。
4.1 怎么在没多少数据的情况下把模型练出来
我们做孔特征风险预警项目时,手里只有800个标注过的CAD模型,算下来大概不到一万个有效特征样本。这个数据量对深度学习来说少得可怜。我们用了三招把效果拉到了可上线水平。
第一招是CAD层面的数据增强。这个方法比较有工业特色:不是对图像做旋转缩放,而是直接在CAD内核里去改特征参数来生成新模型。比如把孔径在原始值基础上随机偏移正负20%,把孔轴线角度偏移正负5度,把板厚改薄改厚20%,每改一次参数就生成一个新的变体模型,同时自动带上原始样本的标注标签。这样可以轻松把样本量扩大十倍以上,而且因为是在CAD参数层面的增强,生成的新样本和真实设计场景非常接近,不会有图像增强那种"变完形就不像真实世界"的问题。
第二招是迁移学习的两个阶段。我先让模型在纯合成数据上做预训练——用程序批量生成大量简单零件,这些零件的特征类型和组合方式完全可控,标注是程序自动生成的,成本几乎是零。然后用真实标注数据做微调。合成数据的好处是覆盖度可以做得很大,让模型先学到通用的几何特征表示;真实数据质量精度高但数量少,用来在最后阶段把模型的领域感觉"扳正"。两阶段合下来,在真实测试集上精度提升了大概11个百分点。
第三招是主动学习和人工复核的小闭环。模型先对未标注数据做预测,把置信度排名中间的那一批拿出来给专家标注——置信度太低的是模型完全不懂的,标了也学不到;置信度太高的标了也没新增量。只有"模棱两可"的样本能教会模型新的知识。这个策略在标注预算有限的时候特别管用。
4.2 数据标注规范的制定:跟工程师磨出来的经验
工业数据标注和通用的图像标注完全是两回事。图像标注是画框框,工业数据标注要写的是特征类型、特征参数、关联关系、风险等级、风险原因,一份标注的字段有十几项。刚开始我们让工程师直接标,结果一塌糊涂:同一个特征,两个工程师给的标签一个写"孔"一个写"圆孔-贯穿",风格完全不统一;风险等级的判断更离谱,同样的斜孔设计,一个工程师标"低风险",另一个标"中风险",因为他们的加工经验不一样。
后来我们成立了标准制定小组,把标注规范反复打磨了四轮。规范里每个特征类型都有明确的定义和图示,关键是要给出边界案例:比如直径多大以上算"大孔"、长径比超过多少算"深孔"、孔轴线偏转角小于多少度可以忽略。这些决策边界的确定光靠书面定义不够,必须用一批有代表性的模型实例作为"标注标准答案集"——标新样本之前先对照标准答案集校准一下自己对规则的理解。
风险等级标注的争议最大。最后我们放弃了一个综合风险分数的做法,改成"风险维度独立标注":几何风险、工艺风险、装配干涉风险分开打标签,每个维度独立的三档制(低/中/高),模型的输出也是分维度给出。这样工程师之间对同一特征的标注分歧大幅减少,因为不用在脑子里做综合权衡了。
4.3 模型评估时最容易做的假把式:别只看准确率
模型训练完,量产评估阶段大家最爱汇报的是准确率98%这种数字。这种单一指标在工业AI里是有很大欺骗性的。我后来习惯看两个额外的指标:一个是误报率,就是模型说有问题、实际却没问题的占比;另一个是漏报率,就是模型没发现问题、实际却有问题的占比。
孔风险预警这个场景里,漏报的代价远大于误报。漏报意味着风险真实存在但被系统放过了,工程师因为信任系统会更疏忽,一旦出问题就是实际的加工事故;误报只是多弹一个提示,工程师看完说"这个我有数"然后忽略就行了。所以我们在产品参数上做了取舍:模型阈值调到偏保守的方向,宁可多报20%的误报,也要把漏报率压到极低的水平。这个决策在评审会上不太好讲,因为"误报率升高"在汇报上不好看,但真正对用户负责的设计就该这么做。上线后我们发现误报多这个事在真实使用中也没那么烦,因为工程师们自己会过滤,他们反而更担心的是AI漏掉真问题。
5. 从单点功能到Agent化:为什么工业界的AI Agent这么难落地
最近国内的AI热词里到处是Agent、智能体、多智能体协作这类概念,很多同行也在问我们的CAD软件什么时候上Agent。我坦诚讲:工业软件的Agent化,我们踩了一堆坑,而且到现在也不敢说完全趟平了。
5.1 工业场景对Agent的核心约束:不能"自由发挥"
互联网场景的Agent可以自由试错——反正搜索、聊天、发个邮件下个单,错了重来成本很低。工业场景完全不允许这种自动驾驶式的自由探索。一个Agent如果要去调用三维建模内核的API,它必须严格执行参数格式和调用顺序:先选基准面,再建草图,再约束尺寸,然后拉伸成体——这个顺序错一步,模型直接建不出来,或者建出来是个废壳。Agent要是跟互联网风格一样"试一下"就会非常恐怖,可能反复试错把客户的模型文件搞出几十个垃圾版本。
所以我们的Agent架构在自由度上做了极端的限制。整个Agent被封装在意图解析、任务编排、动作执行三段式框架里:大模型只能负责意图理解和任务拆分,产出是结构化的任务清单;任务清单落到编排器后,必须经过一层"可执行性校验规则库",这里存放了几百条业务规则,比如"删除特征前必须检查是否有子特征引用""修改尺寸后必须重新求解约束""批量修改前必须做装配干涉预检",校验通过的任务才会下发到动作执行器。动作执行器只接受白名单API调用,每个API都是原子操作,不允许多步操作合并。
这套限制让Agent看起来"笨"了不少,不能像演示视频里那样一句话连续做数十个操作。但换来的是可靠性。我自己站在工程师立场上想,宁可AI笨一点但每一步都能预测,也不想要一个聪明但随时可能发癫的系统。
5.2 多Agent协作里的"会议协调"问题
多AI协作是另一块我们尝试过又收缩了的部分。一开始我们设计了三个Agent分工:一个做设计意图理解,一个做工艺可行性分析,一个做成本估算,三个Agent开会讨论然后给出综合方案。想法很美好,实际跑起来问题频出。
最大的问题是Agent之间的上下文同步。Agent A的分析结论用自然语言写给Agent B,Agent B理解偏了一个词,后续所有判断都跑偏了。比如设计意图Agent说"这个件客户要求轻量化",工艺Agent把"轻量化"理解成"减重孔优先"就开始推荐各种减重方案,但设计意图里轻量化可能只是指"换铝合金材料",根本不是要打孔。信息在传递过程中的失真比人还要严重——因为人会在说不清楚时反问,Agent不会,它只会顺着错误的理解继续往下推进。
现在的做法是减少Agent间的自由对话,改成共享一个结构化"事实黑板":所有Agent只往黑板上写结构化条目,比如"材料建议:6061-T6铝合金;理由:与现有焊接工艺匹配;置信度:高",其他Agent读黑板时拿到的是一致的数据格式,不依赖自然语言理解。需要Agent之间讨论时也不允许直接对话,而是把讨论请求放到一个仲裁器里去排队处理。这套改造之后多Agent协作才真正达到可用的状态。
5.3 Agent落地后的可观测性:活干得好不好得能复盘
我建议所有想上Agent的工业软件团队把可观测性作为一等公民来设计。Agent跟以前的功能块完全不一样:功能块的行为是写死的,出问题可以查源码;Agent的行为是大模型生成的,出问题你都不知道它在想什么。所以每一步Agent动作都要落日志,日志不能只记"做了什么",还要记"为什么这么做"——也就是把大模型给出的即时推理也说清楚。
我们专门做了一个Agent动作回放面板,界面上按照时间线展示Agent每一步的思考链、生成的任务清单、校验结果、执行状态。工程师如果发现Agent做的某个改动不合理,可以拖动时间轴回到出错那一步,看到"模型那一步是怎么判断的",方便反馈给开发团队做针对性修复。这个设计看着不起眼,但内部讨论时我们的看法是:没有回放面板的Agent就像一个蒙着眼干活的人,谁敢让它进生产流程呢?
6. 落地过程中的技术选型复盘:哪些选项我们试错后放弃了
整个项目做下来,有几条技术路线是我们尝试之后明确放弃的,写出来给同行参考,也许能帮大家少走一点弯路。
6.1 用纯大模型做图纸识别的方案:放弃
最早我们尝试过拿多模态大模型直接识别工程图纸截图,让它输出特征列表。效果跟大家预想的差不多——识别简单零件还能蒙蒙对,一到复杂装配图就崩溃:尺寸标注、中心线、剖面线混在一起,大模型根本分不清哪些线是几何轮廓哪些是辅助线。这东西做产品演示很惊艳,做工程不可靠。
而且多模态大模型的一个致命短板是精度不可控:同一个图有时识别出8个孔,有时识别出7个,没有确定性。工业软件需要的是同样的输入永远同样的输出,这个不确定性对工程师的信任是致命的。所以纯视觉识别在核心流程里被我们否掉了,只在辅助检索的试用功能里保留了入口。
6.2 用通用Agent框架做外部任务驱动的方案:放弃
当时社区里推荐用LangChain这类Agent框架来做语义解析和工具调用,我们搭建了一个demo,让Agent去调用CAD API完成"批量修改所有钣金件圆角半径"之类的任务。demo确实跑通了,但深入一看,框架自带的工具调用机制更偏向"能调就行",缺少工业场景需要的"事务一致性"——比如批量修改过程中改了五个零件、第六个零件因为约束冲突没改成功,框架默认继续执行下去,最后整个模型处于半更新状态。这在我们行业是不可接受的。
我们最后是自己写了一个带着"事务回滚"的任务执行器:一组操作要么全部成功,中途任何一个失败就把已执行的步骤全部回滚到初始状态。这个能力没有现成框架直接给,只能自己动手。所以我的建议是工业软件可以借鉴Agent框架的思路,但别把整个框架直接搬进来,核心的任务编排和动作管理一定得自研和深度控制。
6.3 模型参数直接放公有云推理的方案:部分放弃
那时候国内公有云上的大模型API能力已经不错了,我们一开始想把推理前置到公有云上,让CAD软件直接调云端接口。省事是真的省事,但工业客户对数据出企业的敏感度普遍很高,很多客户直接明说模型文件不能传出公司内网。后来我们搞了一套混合部署方案:小模型和特征识别任务全部放在本地边缘节点上跑,只有那些不涉及几何细节的语义解释类请求才走云端大模型接口。如果客户的内网安全合规要求非常严格,就全套本地部署,用一个轻量的本地模型做语义生成,效果比云端大模型差一点,但数据安全完全可控。
这个决策直接导致我们在模型压缩和量化上额外投入了不少精力。把一个小图模型从FP32量化到INT8精度,在测试集上精度只掉了0.3个百分点,推理速度提升接近四倍,这个账算下来非常值。大模型部分则用提示词裁剪和上下文压缩来减少token消耗,保证在有限算力下也能跑。
7. 做完这一轮AI化改造后,我对工业软件产品形态的一些新理解
项目做到后期,我越来越觉得"从画图纸到会思考的软件"这个转变,真正难的其实不是算法有多先进,而是要对工业场景的本质有足够的敬畏。AI再聪明,它只是工业知识的一个载体和放大器。它不能凭空变出工艺规则来,这些规则还是从老师傅和资深工程师那里学来的,AI做的事情是把这些分散的、藏在每个人脑子里的经验变成产品级的能力,让整个组织的平均水平往上抬一大截。
关于这个"平均水平的抬升"有一个很直观的体会。以前团队里带新人,结构工程师要花一年多才能熟悉各种可制造性问题,摔几次跟头才能记住哪些设计不能这么画。现在新人在画每一步的时候,AI会基于知识库给出提示,新人的犯错曲线明显变缓了。这不是说新人就不需要老法师带了,但很多基础的坑确实可以被挡在早期。从这个角度看,AI放进工业软件最大的价值不是替代谁,而是把整个行业的经验门槛往下压,让更多的工程师在更短的时间内做出更可靠的设计。
如果你也在做工业软件或者相关领域的AI落地,我的建议是:从数据管道开始做,不要一上来就卷模型。把模型数据"翻译"成AI能理解的结构化表示,这件事的ROI比调模型高得多;然后找一个足够小、足够痛的场景先跑通全链路;最后在设计产品形态的时候把"不打扰、可回退、能解释"当成硬约束。把这个流程走完,你就知道"会思考的软件"和"花哨的AI功能"到底差在哪里了。
最后分享一个小技巧。如果你要给现有工业软件加AI提示功能,最省力气的切入点其实是"历史报错数据的复盘"。把过去两三年里客户提交的模型错误日志、设计变更申请、加工异常报告收集起来,每条数据对应到当时的模型状态,这就是一个非常有价值的训练集。这个数据大多数企业都有,只是没人觉得它能用来培养AI。从这些真实出过错的数据里提炼规则,训练出来的模型往往比用标准案例训练的更贴合实际,因为错误往往比正确更能暴露知识的边界。