1. 我为什么盯上“需求到三维模型”这段链路先交代一下背景。我以前一直觉得产品研发设计里最磨人的不是建模本身而是需求到三维模型之间的那段“翻译”过程。设计师拿到一页需求文档上面写着“做一个安装支架要能承受振动环境接口按对手件来”然后就要开始猜孔位是定死的还是可以调整的材料用铝还是钢避让空间留多少这些问题在需求阶段没人说得清等模型建完拿去评审才被一句“这里不对”打回来重做。传统流程里一个中等复杂度的结构件从需求接收到三维模型交付通常要两到五个工作日。建模操作本身可能只要半天剩下的时间全耗在澄清需求、查标准、选型、改图、等评审意见上。我们统计过自己企业的历史工单研发设计环节里真正用在“创建几何”的时间不到总工时的三成七成消耗在信息同步和返工上。这就是炽橙AIDT工业智能体切入研发设计场景的原因。AIDT这个名字拆开是AI与数字化技术我理解是AI-Driven Digital Technology的缩写在工业场景里它的任务不是帮你写代码或者生成一张好看的图片而是把工业软件里那些重复、繁琐、依赖经验的操作流程用智能体串起来。我做的这个3D CAD生成设计智能体目标很明确让设计师给一段需求描述智能体自动完成需求澄清、方案生成、三维建模和基础校审把“需求到模型”的周期从数天压到三小时以内。这篇文章是系列第二篇讲的就是这个智能体的设计思路、实现细节和实测数据。如果你正在做类似的研发提效项目或者纠结于“AI能不能在CAD里真正干活”那这篇应该对你有参考价值。需要说明的是智能体解决的不是创意设计问题而是“有章可循”的那部分设计工作——标准件、结构件、壳体、支架这类参数化程度高的对象效果最好。2. 3D CAD生成设计智能体的整体架构与关键技术选型2.1 四层架构分得清“谁在思考、谁在干活”智能体从零设计时最容易犯的错是把所有能力塞进一个模型里指望LLM既会理解需求又会操作CAD。实际上每一步的失败率都会累积必须拆层。我采用的架构分四层会话层负责与设计师进行多轮对话把模糊的自然语言需求整理成结构化的输入。比如设计师说“做一个防护罩注意别干涉到旁边的油管”会话层要把“防护罩”识别为对象把“别干涉油管”识别为空间约束。认知层核心是LLM加上企业知识库的检索增强RAG。它负责意图识别、约束抽取和方案规划把自然语言转化成CAD能理解的参数和指令序列。执行层对接CAD内核的API执行参数化建模、装配、出工程图等具体操作。这一层不需要“聪明”但必须稳定。知识层沉淀企业的历史图纸模板、标准件库、材料库、设计规范。这是智能体能真正落地的底座也是和通用AI工具拉开差距的地方。数据链路大致是需求文档 → 会话层澄清 → 认知层输出结构化约束 → 执行层按规划调用CAD API建模 → 模型交回认知层做自检 → 输出给设计师。每层之间都有明确的接口协议某一层换供应商或换模型不影响其他层。2.2 为什么坚持参数化驱动而不是让AI“画”一个模型这是整个项目里我回答最多的问题。现在市面上“卫星图生成三维模型”这类热词很多技术上多用NeRF、高斯泼溅或多视图重建输入一组照片或卫星影像输出一个三维网格。表面看起来AI确实能“生成”模型了那工业设计是不是也能这么干不能。原因有三个第一精度不对。消费级的AI三维重建精度在分米级到米级做城市规划、可视化还行工业设计要的是毫米级公差甚至特定表面的粗糙度都要控制网格模型完全不满足。第二模型不可编辑。重建出来的是“一张皮”没有特征树没有草图没有参数关系。设计师想改一个孔的直径还得回到原来的CAD文件里重新建一遍等于白做。第三数据格式进不了下游链路。制造环节需要的是带PMI产品制造信息、材料属性、BOM信息的模型网格模型在CAM、CAE、PLM系统里根本走不通。所以我们选的是参数化驱动路线。思路很简单企业历史图纸里同一类零件支架、法兰、壳体的结构拓扑是稳定的变的只是尺寸和位置。把这些图纸整理成参数化模板LLM负责从需求里抽取参数值、判断选哪个模板然后在CAD里实例化做出一个带完整特征树的可编辑模型。我把这比喻成写代码有了脚手架——不是每次从零搭项目而是从模板开始改参数、加特征效率自然高。2.3 四个关键组件的作用边界需求解析器把自然语言转成JSON结构里面包含对象类型、关键尺寸、公差等级、材料、表面处理、装配接口等字段。解析器会针对工业领域做术语映射比如说“Q235B”不该被解析成未知字符串。建模规划器把“建一个法兰”拆解成有序的CAD命令序列创建草图→拉伸底座→开中心孔→打螺栓孔阵列→倒角→加标注。规划器需要考虑CAD操作之间的依赖关系不能并行执行的绝不强行并行。约束校验器这是我认为最重要的组件。LLM生成的参数值经常会“一本正经胡说八道”比如把材料强度等级写成不存在的牌号校验器就是一道闸门它对照知识库里的枚举范围和数学关系做检查不合法就打回重答。知识检索器基于向量数据库存的是企业私有图纸、规范、标准件库。LLM生成参数时不是凭空猜而是先检索类似历史设计参考已有方案再输出大幅降低幻觉概率。3. 三小时里的关键节点从需求到模型的完整过程拆解3.1 需求澄清智能体先当半小时“产品经理”很多AI落地项目失败不是因为模型不行而是需求输入太模糊。设计师往对话框里丢一句“做个支架”就等着收图这根本不现实。所以智能体在动手建模前有一个强制需求澄清环节通常持续二十到三十分钟像产品经理问问题一样把关键信息问清楚。第一轮问交付物要零件还是装配体几号件有没有出图要求第二轮问关键尺寸和公差安装孔距、板厚、配合精度用户给的是确定值还是要推荐值第三轮问材料和工艺是钣金折弯还是机加工表面要不要处理第四轮问装配关系跟谁配合、安装方向、避空位置。每一轮结束后智能体会生成一份《需求规格确认单》列清楚已明确项、默认项、待确认项等设计师点确认后才进入下一步。这一步看着繁琐却是把返工概率降下来的关键。实测下来大部分工单在这个环节就能把需求从“大概齐”变成“可执行”后面建模阶段几乎不会再回头改大尺寸。3.2 概念方案生成与快速验证不只有一个答案需求澄清完成后智能体会基于知识库里的历史设计生成二到四个概念方案。每个方案本质是一组不同的参数组合和结构取向。比如防护罩设计可能同时给出钣金弯折方案、铸铝方案、焊接拼装方案它们的重量、材料成本、可制造性预判都不同。这个环节的技术实现并不复杂模板库里有多个结构拓扑加上参数组就能形成不同方案。关键是展示方式。智能体不是直接丢出一堆三维模型让用户选而是先输出轻量化预览图加一个对比表格列清楚每个方案的预估重量、材料利用率、制造工艺兼容性、成本区间。设计师在界面上勾选一个方案或者直接说“第二个方案的结构把板厚改成2毫米”智能体会在原有方案上迭代。我通常建议设计师在这个环节花二十分钟认真看因为后面CAD执行是自动的但方向选错的话自动得越快浪费越严重。这个“人机确认点”是整个流程里少数必须卡住的地方。3.3 参数化建模执行CAD内核里发生了什么方案确认后智能体进入真正的建模执行阶段这也是三小时里最耗算力的部分。我以一个典型支架类零件为例说下执行层的处理过程创建新零部件文档设置材料属性和单位制。根据规划器的命令序列创建基准面、绘制草图标注关键尺寸。这里用的尺寸是需求确认单里确认过的标注的同时会带上公差信息。执行特征操作拉伸基座、切除减重槽、打安装孔、添加倒角、阵列螺栓孔。每一步操作完成后执行层会记录这条操作日志和当前模型状态。调用标准件库需要螺栓、轴承、垫片时智能体直接从库里调标准模型装配上去不需要自己画。模型自检执行层完成建模后认知层会对模型做一轮回顾检查特征树是否完整、关键尺寸是否与需求单一致、有没有多余的废特征。在CAD API调用层面所有的建模命令都是同步推送到CAD内核里执行的每完成一个特征界面上会出现一次进度更新。整个过程看着像有个工程师在远程操作CAD只不过这个工程师的动作快很多。这里有一点值得强调建模规划质量直接决定模型质量。如果规划器给出的命令顺序不合理比如先倒角后打孔导致孔位参考失效整个模型就可能建不出来。我们的做法是在规划器里内置了一套“特征依赖规则库”凡是空间上有依赖关系的操作必须排序同级的特征再按资源情况决定是否并行。3.4 交付前的校审与数据回填让模型从“能看”变成“能用”建模完成不代表工作结束。工业模型的设计交付不是画完几何就行还得有工程属性、有规范、有往下游传的数据。智能体在交付前会自动完成四个动作干涉检查把新模型放进整机装配环境里做一个基础干涉检查看有没有明显的碰撞区域。检查报告会列出干涉位置和干涉量。工程图初稿从三维模型导出三视图、剖视图自动标注主要尺寸。这张图不用达到最终交付质量但至少让设计师不用从白纸开始出图。属性回填按照企业模板自动写入图号、名称、材料、表面处理、重量、设计者、日期等属性字段保持与PLM系统的字段一致。变更记录生成智能体会自动生成一份《设计变更说明》列清楚这版模型里哪些参数直接来自需求文本、哪些是从知识库参考来的默认值、哪些需要设计师最终确认。到这一步交付物已经是一个带完整属性、可追溯、可编辑的正式三维模型而不是一个空壳子。设计师要做的只剩下专业判断和微调。4. 实测效果复盘三类典型工单的真实数据4.1 时间对比不只是快是“可预期地快”我们在企业内部选了三个典型任务做测试分别代表不同的设计对象难度测试条件和结果是这样的任务类型传统手动建模平均耗时智能体端到端耗时缩短比例安装支架类钣金件约2个工作日约2.5小时约84%设备防护罩壳体约3个工作日约3小时约88%传动结构件含标准件装配约5个工作日约3.5小时约91%需要说明一点这里说的传统耗时是指“纯设计建模工作”——不含需求评审会议等空转的时间已经是比较理想的口径。实际项目里的感受比表格数字更直观以前一个设计师手里同时挂着三四个建模任务哪个项目催得紧就先做哪个现在把需求丢给智能体设计师可以先去处理更复杂的系统性设计问题模型好了自动通知回头看结果就行。4.2 质量指标快之外的价值在于返工变少了时间缩短只是表面我更看重的是质量变化。我们对这几十个测试工单做了统计三个指标有明显的改善一次评审通过率从之前的65%提升到89%。原因在于需求澄清环节把模糊地带提前消除了而不是等评审时再暴露。设计变更导致的返工工时下降了约60%因为智能体改模型本质上是“改参数重新生成”而不是在已有模型上进行破坏性的几何编辑。三维模型与BOM数据的字段一致率达到100%手工建模时常见的漏填属性、单位写错这类低级失误基本消失了。4.3 补充一句工业级CAD和AI生成模型的本质差异前面提到“卫星图生成三维模型”那类技术我特意观察过一段时间。它们做城市建筑、地表场景的还原确实有优势但在工业研发里价值点完全不同。一个是几何外观的重建一个是工程定义的设计。你要做一个能下生产线的零件必须要有公差、材料、工艺、装配关系这些工程信息光有形状是没用的。这个认知对我们的技术选型影响很大。曾有同事开玩笑说要不要试试直接让AI“画”个轮毂出来我说可以——画出来当效果图没问题当设计交付物就差的远了。反而是那些AI重建的点云模型可以拿来做逆向建模的参考输入先在测绘场景里用起来这个方向更实际。5. 落地过程中的坑与解法真实踩过才有的教训5.1 大模型的“自信幻觉”怎么兜底这是整个项目里最容易翻车的环节。初版系统跑通后我们做了个小规模测试结果LLM在生成参数时犯了不少低级错误把Q355B写成Q345B公差级别选了市场上不存在的组合某个孔径超出企业标准件库的覆盖范围。模型仍会一本正经地生成出来若不核对就带着错误参数进了CAD。后来我用三层防线解决知识库检索增强让LLM生成参数前必须先检索企业标准库输出时要引用来源约束校验器做硬校验所有参数过一遍规则引擎不符合的强制打回同时给出修改建议关键参数人工确认需求确认单里把材料、公差这类安全相关字段标黄要求设计师逐个确认才能放行。这套兜底方案上线后参数类错误率降到了2%以下。底层逻辑很简单不要指望大模型不出错要把所有“可校验的错”在系统层面拦住。5.2 CAD API的性能瓶颈与队列化改造智能体刚开始在服务器端跑CAD时我们遇到一个尴尬问题CAD内核是重负载应用建模操作对CPU、内存消耗都很大。多个工单同时提交时服务器直接卡死过有次救援花了半小时。我们把执行层改成基于任务队列的架构每个建模请求进入队列按优先级和资源池调度执行并行度限制在合理范围内。实测下来服务器端的8线程并发已经能稳定支撑日常使用再往上加并发收益不大反而会增加崩溃风险。另一个痛点是进度反馈。CAD长任务执行时如果界面上一片死寂用户会以为系统挂了。我们通过WebSocket推送方式把实时进度流推到前端如果任务超时或失败也会自动重试并把重试过程记录下来。5.3 知识库冷启动从标准件开始滚雪球知识库的质量直接决定智能体的上限模型再聪明也补不上库的空白。刚开始跑的时候知识库里只有几十张图纸智能体一出“非标”需求就抓瞎生成结果根本没法用。我的做法是先不谈“全要素覆盖”把企业每月高频使用的零件类型排个序比如支架、法兰、轴承座、防护罩、钣金门板先把这些做成参数化模板。和设计师约定如果有新的历史模型被验证没问题你们顺手把它转成模板存进库里每转一个我这边把该类型任务的自动化成功率提升一块你们有甜头库也会自己长胖。半年后库里积累了上百个模板覆盖了九成以上常见工单类型智能体的综合成功率就非常可观了。6. 这套模式给研发设计岗位带来的变化项目跑到现在让我感受最深的倒不是技术指标而是角色分工的变化。设计师的岗位重心正在从“画图员”转向“决策者”——他们不再花大量时间在建模操作上而是把精力花在需求定义、方案评审和规则输理上。智能体干活人定方向新设计师上手很快老设计师的经验也通过模板沉淀在系统里不再只存在于个人电脑里。总结时可说的不多但有一点我必须强调不要一上来就追求“全自动完全无人干预”。我把这个项目的推进分为三步第一步跑通一个简单工单让设计师觉得“这工具能用”第二步收集实际使用中暴露的问题把知识库和校验规则补全第三步再逐步扩大覆盖零件类型。每一步走稳了再进下一步这个路径比一开始就做重大变革的稳妥得多实际效果也更好。