1. 从画图到选型AI 在研发链条里到底动了谁的奶酪先说一个我亲眼见过的场景。去年帮一家做非标自动化设备的朋友梳理研发流程他们结构组六个人电气组四个人加上两个负责出 BOM 和跟物料的工艺工程师。一个中等复杂度的机架项目从需求确认到图纸冻结平均要 22 个工作日。其中真正动脑子的设计时间大概只占四成剩下六成耗在三件事上反复改图、手动整理物料清单、跟采购确认某个型号到底还能不能买到。今年再去他们结构组还是六个人但项目周期压到了 14 天左右。变化不是靠加班而是他们把画图和选型这两段最耗人力的环节交给了 AI 辅助工具链。结构工程师现在的工作方式变成了先跟 AI 描述清楚工况和约束让工具生成几版初步方案和三维模型人再去做判断和微调电气这边原理图导出后由脚本自动抽取物料信息AI 负责做型号匹配和替代料推荐。这就是标题里说的研发部先变天。变的不是人少了而是人的时间被重新分配了——从执行性劳动往判断性劳动迁移。我写这篇东西不是要吹某个具体产品而是想把这条链路拆开讲清楚AI 到底在 CAD 和 BOM 这两个环节里做了什么、怎么做的、哪些地方现在还不能信、以及一个普通研发团队想上手应该从哪一步切进去。不管你是画图的、做电气的、管物料的还是带研发团队的都能从里面找到自己能直接抄的部分。需要先明确一个边界下面讲的所有内容都是围绕工业设计与研发流程中的 AI 辅助展开涉及的是 CAD 建模、BOM 处理、多模态理解、智能体编排这些正经工程话题。任何跟这个主线无关的东西都不在讨论范围内。2. AI 介入 CAD 的真实姿势不是替你画是替你试很多人对AI CAD的想象是说一句话图纸自己就出来了。这个想象有一半对一半会让人踩坑。对的部分是AI 确实能根据自然语言或参数约束生成几何体错的部分是它生成的往往是候选方案而不是能直接下厂的终稿。理解这个区别是能不能用好这类工具的分水岭。2.1 参数化建模与生成式设计的结合点在哪传统 CAD 建模是人定义每一步特征拉伸、切除、倒角、阵列一步一步来。生成式设计换了个思路你给它目标函数和约束条件它在解空间里搜索满足条件的几何形态。这两者的结合点恰恰在参数化上。举个具体例子。你要设计一个承重支架约束是安装孔位固定、最大外形不超过某个包络、材料用某牌号铝合金、安全系数不低于 2.5。传统做法是你凭经验画一版然后跑有限元不够就加厚超重就挖孔来回迭代。生成式工具的做法是把这些约束喂进去它批量生成几十上百个拓扑结构每个都附带质量、应力分布、重心位置的估算值你从里面挑几个顺眼的再细化。这里的关键认知是AI 负责广度搜索人负责深度判断。它能在几分钟内给你 200 个方案但它不知道你们厂的加工能力只能做三轴、不知道某个圆角会导致刀具干涉、不知道装配工装夹不夹得住。这些制造约束和装配约束目前还得靠人补进去。我实测下来比较稳的用法是把生成式设计当成方案发散器用在项目早期概念阶段。等方案收敛到两三个之后再回到传统参数化建模去做精确设计。别指望它一步到位出终稿那样返工率会很高。2.2 工业多模态理解模型解决了什么老问题多模态这个词听着玄落到研发场景其实很实在。以前的 AI 只能处理单一类型的数据要么读文本要么看图像要么算数值。工业场景里一个零件的完整信息是混在一起的——有三维几何、有二维图纸标注、有材料工艺说明、有历史版本的变更记录。工业多模态理解模型的价值就是把这些异构信息打通。比如你丢给它一张二维工程图它不光能识别出这是个法兰盘还能读出上面的尺寸公差、表面粗糙度符号、热处理要求然后把这些信息结构化输出。再比如你给它一个三维模型加上一段文字描述这个件要承受交变载荷它能推断出你关心的可能是疲劳寿命进而提示你关注应力集中区域。我见过一个很实用的落地把历史项目里几万张图纸喂给多模态模型做训练或微调让它学会看图找相似件。新项目来了一个零件它能从历史库里翻出结构最接近的几个连带把当时的工艺路线、供应商、成本都调出来。这对做非标设备的团队简直是救命——非标件重复利用率低是老大难有了这个能力复用率能明显往上提。2.3 从描述需求到拿到初版模型的完整链路把上面两块拼起来一条可用的链路大概是这样需求结构化把口头或文档形式的需求整理成功能 约束 边界条件三段式。这一步现在很多工具支持用自然语言输入但我的经验是你输入得越结构化输出质量越高。别偷懒只写一句设计一个支架。约束录入把安装接口、包络尺寸、材料、载荷、安全系数这些硬约束明确列出来。软约束比如尽量轻也要标出来让工具知道优化方向。生成候选让生成式模块跑一批方案。数量别贪多50 到 100 个足够太多你根本看不过来。筛选与细化按质量、应力、可制造性排序挑 3 到 5 个进入详细设计。这一步必须人工介入别让 AI 替你拍板。回填制造约束把加工方式、公差、装配关系补进去做可制造性检查。这一步目前 AI 帮不上太多是人的主场。提示整条链路里第 1 步和第 5 步是最容易被低估的。很多人把精力全花在怎么让 AI 生成得更好看结果需求没理清、制造约束没补生成的模型再漂亮也下不了厂。2.4 现阶段别指望 AI 碰的三类活说点泼冷水的话免得有人上头。以下三类工作现阶段交给 AI 风险大于收益涉及安全关键的最终校核承力结构、压力容器、涉及人身安全的机构最终强度校核必须由有资质的人签字负责AI 的输出只能作为参考。强依赖现场工艺经验的判断比如某个焊缝能不能焊到、某个深腔能不能加工出来这些依赖具体设备和工人水平AI 没有这些上下文。跨专业的接口协调结构、电气、液压、气动之间的空间干涉和时序配合牵扯太多隐性知识目前还是靠人拉通。把这三类活守住剩下的让 AI 去干才是理性的分工。3. BOM 这条线AI 真正能省下大把时间的战场如果说 CAD 环节 AI 还处在辅助发散的阶段那 BOM 环节它已经能实打实地接管重复劳动了。原因很简单BOM 处理的本质是结构化数据的抽取、匹配和校验这恰好是大模型和脚本最擅长的活。而且 BOM 出错带来的连锁反应特别大——一个型号写错采购下错单物料到货装不上整条线停摆。所以这个环节的自动化收益比画图环节更直接。3.1 原理图导出 BOM 的自动化抽取逻辑做电气的都熟这个流程在原理图工具里画完图导出 BOM然后手动整理。不同工具导出的格式五花八门有的给 CSV有的给 Excel有的字段名还带一堆前缀。整理的时候要干的事包括合并相同物料、补全缺失的封装信息、核对位号、剔除不贴的器件。AI 介入的方式是在导出和整理之间插一层解析。具体逻辑是字段映射把工具导出的原始字段映射到你们公司标准 BOM 模板的字段上。这一步以前靠人写映射表现在可以让模型根据字段名和样例数据自动推断映射关系人再确认。物料归并同一个物料在不同位置可能写法不同比如电阻 10K 0603 1%和RES 10K 0603 1% 厚膜模型能识别出这是同一个东西归并成一行数量累加。缺失补全有些字段导出时是空的比如封装、耐压值模型可以根据型号规则和历史数据推断补全并标记出这是推断值需人工确认。异常标记位号重复、数量对不上、型号格式异常这些自动标红让人重点看。我帮朋友那边搭过一版类似的流程用脚本做字段映射和归并用模型做缺失补全和异常识别。原来一个中等项目整理 BOM 要半天现在压缩到一两个小时而且错误率明显下降——因为机器不会像人那样看花眼。3.2 物料单位转换这个坑比想象中深热词里有个sap bom 物料单位转换这绝对是踩过坑的人才会搜的词。BOM 里的单位问题是数据治理里最烦人的一类。问题出在哪同一个物料采购按卷买仓库按米存生产按个领BOM 里可能写的是千克。单位不统一MRP 运算就出错要么多买要么缺料。更麻烦的是有些单位换算不是简单的十进制比如某些化工原料按密度换算某些线材按每卷长度换算还有的物料不同供应商的包装规格都不一样。AI 在这里能做的是建立和维护单位换算关系库并在 BOM 导入时自动做归一化。具体做法场景传统做法AI 辅助做法单位识别人工看字段名猜模型根据物料描述和数值范围推断换算关系手工维护换算表从历史采购/库存数据中学习换算系数异常检测靠经验发现自动比对历史用量偏离过大时告警多供应商差异逐个确认按供应商维度分别维护换算规则注意单位换算涉及钱和库存AI 推断出来的换算系数第一次用必须人工复核。我见过因为换算系数搞错导致某物料多买了三个月的量压了一堆库存。3.3 替代料推荐与供应链波动的应对这两年元器件供应波动大替代料管理成了刚需。传统做法是工程师凭经验列几个替代型号写在 BOM 备注里。问题是替代料也有生命周期主料和替代料可能同时缺货人工维护根本跟不上。AI 做替代料推荐逻辑是综合几个维度打分电气参数匹配度、封装兼容性、历史使用记录、当前库存和交期、成本差异。给每个候选替代料算一个可替换置信度高的直接推荐中的提示需验证低的直接排除。这套东西的价值在供应链紧张的时候特别明显。主料交期突然拉长到 20 周系统能立刻给出几个可替换的选项附带验证建议工程师不用从零开始查手册。当然最终能不能换还得工程师根据具体电路和工况拍板AI 只是把候选范围缩小了。3.4 把 BOM 校验做成一道自动闸门我特别想强调的一点BOM 自动化的最高价值不是生成得快而是校验得严。生成快只是省时间校验严是防事故。建议把 BOM 校验做成流程里的一道自动闸门任何 BOM 在进入采购流程前必须过这几关完整性校验必填字段是否齐全位号是否连续无缺。一致性校验BOM 与原理图/三维模型是否对得上数量是否匹配。合规性校验是否用了禁用物质是否符合公司物料优选库要求。可采购性校验型号是否有效是否有在途或库存交期是否可接受。成本校验总成本是否超出预算阈值关键物料价格是否异常波动。这几关用脚本加模型组合实现跑一遍几分钟能拦下大部分低级错误。我朋友那边上线这道闸门后采购退单率降了一大截因为大部分问题在研发内部就被拦住了。4. 智能体在研发流程里怎么编排从单点工具到工作流前面讲的 CAD 和 BOM都是单点能力。真正让研发部变天的是这些单点能力被智能体串成了一条自动流转的工作流。智能体这个词现在被用得很泛我按研发场景给它一个具体定义能感知当前任务状态、调用合适工具、做出下一步决策、并把结果传递给下游的执行单元。4.1 一个研发智能体该具备哪些能力别被各种框架名词绕晕落到研发场景一个有用的智能体需要这几样东西任务理解能听懂帮我把这个项目的电气 BOM 整理出来并检查替代料这种复合指令拆成子任务。工具调用能调用 CAD 接口、BOM 解析脚本、物料数据库查询、单位换算服务等。上下文记忆记得住这个项目的历史变更、之前确认过的替代料、工程师的偏好。异常处理遇到数据缺失或冲突时知道是停下来问人还是按规则先处理再标记。结果交付把结果整理成人能看懂的格式而不是甩一堆原始数据。这五样里异常处理是最考验设计功力的。很多 demo 跑得漂亮一到真实数据就崩就是因为真实数据永远有缺失、有冲突、有格式错误。一个成熟的智能体必须能优雅地处理不完美输入。4.2 多智能体协作在跨专业场景的落地单个智能体能干的事有限跨专业场景往往需要多个智能体协作。比如一个机电一体化项目结构智能体负责三维模型相关任务生成方案、检查干涉、抽取结构 BOM。电气智能体负责原理图和电气 BOM做器件选型和替代料推荐。物料智能体负责跨专业的物料归并、单位换算、库存和交期查询。协调智能体负责调度上面几个处理跨专业冲突比如结构改了导致电气安装孔位变化。这套东西听起来复杂但落地时可以从小处着手。我建议先做两个智能体协作的最小闭环比如结构 BOM 和电气 BOM 的合并去重。跑通了再往上加。多智能体协作最大的坑是状态同步。结构改了一版电气那边如果不知道就会基于旧版本干活最后对不上。所以协调层必须有一个可靠的版本广播机制任何一方的变更都要及时通知其他方。4.3 工作流搭建从人找工具到工具找人传统研发流程是人找工具工程师要出 BOM自己去打开工具、导出、整理、上传。智能体工作流要变成工具找人任务流转到某个节点对应的智能体自动启动处理完把结果推给下一个人或下一个环节。举个具体的流转例子结构工程师完成三维模型标记为设计冻结。结构智能体自动触发抽取结构 BOM做完整性校验。校验通过后通知电气智能体提示结构已冻结请确认接口。电气智能体检查电气接口与结构是否匹配不匹配则告警。两边都确认后物料智能体合并 BOM做单位归一和库存查询。合并结果推给工艺工程师做最终审核。这条链路里人只在关键决策点介入中间的搬运和校验全自动。我朋友那边跑通这条链路后跨专业协调的沟通成本降了很多因为大部分接口问题在自动流转中就被发现了不用等到开协调会。4.4 智能体技能的敏感变量管理热词里有个智能体技能敏感变量这是个很实际的问题。智能体在执行任务时会用到一些敏感信息比如供应商报价、成本数据、未公开的设计参数。这些变量如果管理不当可能泄露或被误用。我的建议是分级授权不同智能体只能访问它职责范围内的敏感变量跨范围访问需要显式授权。脱敏传递智能体之间传递数据时非必要的敏感字段做脱敏处理。操作留痕谁在什么时候访问了什么敏感变量全程记录可审计。最小权限默认不给权限用到什么申请什么用完回收。这些不是技术难题是管理规范问题。但恰恰是这些规范决定了智能体能不能在真实企业环境里跑起来。5. 落地时最容易翻车的几个地方讲了这么多能力得说说坑。我见过太多团队兴致勃勃上了 AI 工具结果用不起来最后吃灰。翻车的原因往往不是技术不行而是下面这几个地方没处理好。5.1 数据质量垃圾进垃圾出AI 也救不了这是最根本的问题。你的历史图纸如果标注不规范、BOM 如果字段混乱、物料库如果一物多码那 AI 处理出来的结果只会更乱。AI 能帮你处理有规律的脏数据但处理不了没有规律的脏数据。我的建议是上 AI 之前先做一轮数据治理。哪怕只治理一个产品线的数据把它做干净作为试点。别一上来就全公司铺开那样只会放大混乱。5.2 人的抵触不是怕失业是怕背锅工程师对 AI 的抵触表面看是怕被替代深层其实是怕背锅。AI 生成的方案如果出了问题责任算谁的如果算工程师的那他凭什么用如果算 AI 的那 AI 又负不了责。解决这个问题的关键是明确责任边界。我的做法是AI 的输出一律标记为建议工程师采纳后责任在工程师工程师如果发现 AI 的建议有问题并修正这是加分项。同时把 AI 的每次输出和工程师的每次修改都记录下来形成可追溯的决策链。这样既保护了工程师也让 AI 的改进有据可依。5.3 工具链割裂每个工具都很好就是连不起来市面上的 AI CAD 工具、BOM 工具、智能体平台单看都不错但彼此之间数据不通。你在 A 工具生成的模型导不进 B 工具B 工具整理的 BOMC 工具读不了。结果工程师还是得手动搬运。选型的时候接口开放性比功能丰富度更重要。宁可选一个功能少但 API 齐全的工具也别选一个功能强但封闭的工具。因为研发流程的本质是数据流转工具连不起来AI 的价值就发挥不出来。5.4 过度自动化把该人管的也交出去了最后一个坑是自动化过头。有些团队恨不得把整个研发流程全自动结果在关键决策点也交给 AI出了大问题。我的原则是涉及安全、成本、合规的最终决策必须有人签字。AI 可以把决策所需的信息整理好、把候选方案排好序、把风险点标出来但拍板这个动作得人来做。这不是保守是负责任。6. 一个普通团队想上手我建议的切入顺序说了这么多最后给个可操作的路径。如果你是一个研发团队的负责人或者是一个想推动这件事的工程师我建议按这个顺序来第一步选一个痛点最明确的单点场景。别贪大就选一个。比如电气 BOM 整理或者结构方案初步生成。选那种重复劳动多、规则相对清晰、出错代价高的场景。第二步把数据准备好。把这个场景涉及的历史数据整理出来做一轮清洗。数据量不用大几百条高质量的样本就够起步。第三步用现成工具搭最小闭环。别自己从零开发用现成的 AI 工具和脚本组合先跑通输入到输出的完整链路。这个阶段的目标是验证可行性不是追求完美。第四步让人用起来收集反馈。找一两个愿意尝试的工程师让他们在实际项目里用。收集他们的吐槽这些吐槽就是改进方向。第五步跑顺了再扩展。单点跑顺了再考虑往上下游延伸或者引入智能体做编排。一步一步来别跳步。我个人在实际推动这类事情时的体会是技术从来不是最大的障碍习惯和信任才是。一个工具再好如果工程师不愿意用就是零。所以前期花在沟通、培训、建立信任上的时间比花在技术选型上的时间更值钱。先让一两个人尝到甜头让他们去影响其他人比自上而下强推有效得多。另外分享一个小技巧在推广初期别急着统计效率提升了多少。这种数字容易引发抵触因为大家会觉得你在用数字压人。先关注工程师是不是觉得轻松了是不是少加班了这种体感指标。体感好了效率数字自然会来。