1. 工业软件AI落地的整体思路拆解

1.1 为什么工业软件必须往“会思考”的方向走

干了十多年工业软件这行，我亲眼看着CAD从二维绘图板变成三维参数化建模，又看着CAE从专家级分析工具变成实时仿真平台。但说实话，直到大模型出现之前，工业软件再卷也就是“画得更快、算得更准”，本质上还是人脑想好了，工具负责执行。很多同行没意识到，真正卡住工业软件脖子的，恰恰是“设计意图”这个东西——你画一条线、约束一个尺寸、标注一个公差，背后全是工程师脑子里的经验判断，而这些判断没有沉淀在软件里。

AI带来的变化不是让软件多几个自动化按钮，而是让软件开始理解“为什么要这么画”。比如你在一根轴上布置轴承位，传统CAD只知道这是两个圆柱面，AI辅助设计的系统却能根据载荷、转速、配合公差自动推断出这里应该放一个深沟球轴承还是圆柱滚子轴承，甚至连轴肩高度怎么定、圆角怎么倒都可以给出推荐。这就是“从画图纸到会思考”的本质：让AI把工程师脑子里的隐形知识变成软件的显性能力。

这个方向适合谁去关注？三类人。第一类是制造业企业的数字化负责人，你需要判断AI在工业软件上到底能落地到什么程度，避免被概念忽悠；第二类是CAD/CAE/CAM相关工具的开发者，你想知道怎么把模型能力和传统几何内核结合起来；第三类是机械、电气、建筑等领域的资深工程师，你手里有大量经验数据，恰恰是AI落地的燃料。这篇文章我不讲空泛的“AI赋能工业4.0”，就讲我在实际项目里怎么把一个传统CAD工具一步一步变成“会思考的软件”，哪些环节能落地、哪些环节是坑，全给你摆出来。

1.2 AI在工业软件里的真实切入点：先分清“能做什么”和“不能做什么”

动手做之前，必须先把边界想清楚。工业软件最讲求确定性，图纸上一个尺寸错了，加工出来的零件就是废品。而大模型的本质是概率生成，它在文学创作、代码补全上表现很好，但在精度要求极高的工业场景里，直接让模型输出最终图纸是极其危险的。所以我的原则是：AI负责经验推理，几何内核负责精确计算，规则引擎负责兜底约束。

具体来说，工业软件里AI能干的活儿大致分四类：

• 经验检索与推荐：把历史设计案例、标准规范、企业内部设计手册做成知识库，工程师输入设计条件时，AI推荐相似方案和关键参数。这类活儿容错率高，推荐错了有人把关，最容易先落地。
• 设计意图识别与规则校验：AI理解图纸上的标注、公差、表面粗糙度等语义信息，自动检查是否符合企业规范或国标。这里AI做的是“阅读理解”，不用生成几何体，风险相对可控。
• 方案生成与优化：给定设计空间和约束条件（如重量最小、强度达标），AI生成初始方案或对已有方案做参数优化。注意是“初始方案”而不是“最终图纸”，最终还是靠仿真和人工确认。
• 交互方式升级：自然语言驱动建模，比如对软件说“在法兰面上均布六个M8螺纹孔，分布圆直径100”，AI自动转换成建模操作序列。这里AI是翻译官，真正执行操作的是CAD内核。

不能做的事情也很明确：AI不能凭空生成带精确公差的BOM表，不能对安全相关的受力件做最终强度判定，不能替代CAE仿真验证。凡是涉及“最终交付物”的场景，AI只能做助手，不能做决策者。把这条边界立住，后续项目推进才会顺，否则一上来就让AI“一键出图”，那基本是给自己挖坑。

2. 核心环节解析与实操要点

2.1 知识工程：把老师傅脑子里的经验搬进AI

工业软件AI落地最关键的一步，不是选模型，而是做知识工程。我见过太多团队上来就用通用大模型调API，指望它能回答“这个支架该用多厚的板”，结果模型一本正经地胡说八道。原因很简单——通用模型没见过你们企业三十年积累的设计案例和踩坑记录。

知识工程的做法分三步。第一步是数据盘点，把散落在图纸、工艺卡、设计规范、故障报告里的隐性知识找出来。很多企业图纸里的标题栏、技术要求、明细表其实都是结构化信息的富矿，比如“未注圆角R3”“调质处理HB220-250”这些短语，背后全是工艺经验。第二步是知识抽取，用规则加模型的方式把这些信息整理成语义单元，比如“零件材料=Q235B”“表面处理=镀锌钝化”“公差等级=IT8”。第三步是知识入库，按设计对象、工况条件、失效模式三个维度组织知识图谱，让AI能按需检索。

这里有个很容易被忽视的细节：工业知识是有上下文的。同样是“HT200”这个材料牌号，用在机床底座上关注的是减震性，用在阀体上关注的是耐压性。如果知识库不记录使用场景，AI推荐的结论就会偏。所以我在做知识工程时，强制要求每个知识条目都附带“适用条件”和“不适用情况”，宁可多写几条约束，也别让AI自由发挥。

从实操角度说，知识工程不是一次性的，得做成闭环。工程师在实际设计中对AI推荐做了修改，这些差异要能回流到知识库里，让系统越用越准。我习惯在推荐结果旁边加两个按钮——“采纳”和“修正”，修正的内容记录到反馈表里，定期人工审核后合并进知识库。这个机制看似简单，但它决定了AI系统能不能在企业里持续进化。

2.2 模型选型：大模型、专用模型与规则引擎怎么配合

工业软件场景不建议只用一种模型打天下。我的经验是把系统拆成三层。

第一层是对话与理解层，负责把工程师的自然语言转成结构化指令，把图纸上的标注识别成语义标签。这个层用通用大模型就够了，比如GPT系列或者国产的开源模型，重点考察中文工程术语理解能力。第二层是推理与推荐层，负责基于知识库给出设计建议、参数推荐、方案对比。这一层可以微调一个专用模型，也可以直接用RAG方式把知识库接入通用模型，优先选后者，因为工业知识更新频繁，微调一次成本太高，而RAG只要更新向量库就行。第三层是规则引擎与几何内核层，负责执行AI生成的指令序列，并做硬性校验。比如AI建议把轴径从40改成45，规则引擎就要立刻检查轴承座安装空间是否足够，如果不够，直接打回。

这三层的关系可以打个比方：大模型是“大脑”，负责思考和提出想法；RAG知识库是“记忆”，提供依据和背景；规则引擎是“小脑”，管着所有不能出错的精细动作。大脑再聪明，小脑执行力不行也会摔跤。

选型过程中最容易被带偏的是“非要本地部署大模型”。如果企业数据保密要求极高，本地部署没毛病；但大多数时候，工业AI的敏感数据根本不在模型参数里，而是在知识库里。参数敏感的，优先用私有化部署的开源模型，或者干脆用向量数据库加密存储知识文档，模型只做推理不透传原始数据。数据敏感的，用API接入通用模型时做脱敏和过滤，把图纸上的具体产品型号、客户信息剥掉再送出去。这个思路能省一大笔GPU投入。

2.3 场景切分：先选一个“小切口”跑通全链路

别想着一步到位做“全智能设计平台”，那是大厂PPT里的故事。真实落地的路径一定是先找一个高频、低风险、价值明确的场景做试点。我做得最多的试点是“基于历史案例的零件参数推荐”——工程师输入一个零件的功能需求和使用工况，系统从历史案例库里检索相似设计，推荐材料、关键尺寸范围和热处理方式。

为什么选这个场景？三个原因。第一，高频。一个机械设计工程师每天要处理十几个零件的选型和参数确定，效率提升空间大。第二，低风险。系统只做推荐不做最终决策，工程师可以不采纳，责任边界清晰。第三，数据现成。凡是干了三年以上的制造企业，图纸库里都有大量成熟设计案例，标注稍作清洗就能用。

选择切口时还有一个判断标准：尽量选“结果可验证”的场景。比如推荐气体压力容器壁厚，上来的结果可以直接用压力容器标准公式校核，AI建不建议一眼就知道对不对。这样调试模型时有明确的对错标尺，迭代速度快。反之，像“优化产品外观设计”这种主观评价场景，标注数据都难以统一，落地难度极大，一开始别碰。

3. 实操过程与核心环节实现

3.1 五步搭建一套“会思考的出图助手”

去年我给一家做非标自动化设备的企业做了一套AI辅助出图系统，整个过程走了五步，每一步都有值得记录的细节。这套系统的核心功能是：工程师用自然语言描述一个非标零件的功能需求，系统自动推荐结构方案、关键尺寸和加工工艺，并生成一个基础的三维模型供工程师继续修改。

第一步是搭建知识库。我们把这家企业近八年的非标设计图纸全部翻出来，先做OCR识别提取技术要求，再按“机构类型—功能需求—材料—加工工艺”四个维度分类存进知识图谱。这里踩过一个坑：图纸上的技术要求很多是简写和行业黑话，比如“发黑处理”“调制处理”，OCR出来错别字一大堆。后来我们针对高频术语做了一张规范词典，先做文本替换再入库，准确率才从七成涨到九成以上。

第二步是定义自然语言接口。工程师输入的请求五花八门，有人写“做一个能支撑200公斤的底座”，有人写“底板带四个安装孔，中心距150×100，厚度30”。为了让模型能稳定理解，我们设计了一套结构化的需求模板，引导工程师按“功能+约束+偏好”三段式描述，同时保留自由输入，靠提示词让模型自己提取关键信息。提示词模板后来沉淀成了我们内部文档，核心思路是：

你是机械设计专家，现在需要根据用户描述生成结构化设计需求。 请从描述中提取： 1. 功能目标（这个零件是干什么的） 2. 关键约束（载荷、尺寸、接口、环境等） 3. 可选偏好（材料偏好、工艺偏好等） 如果描述中缺少某项信息，输出时标记为“待确认”，不要自己编造。

第三步是设计推荐链路。模型先把结构化需求转成知识图谱查询语句，从知识库里召回相似的成熟案例，再对案例中的关键参数做基于约束的适配计算。比如客户要求承载从300公斤提升到500公斤，系统不会照搬原案例的钢板厚度，而是按强度公式做一个初步换算，再附上“建议使用有限元验证”的提醒。这里我们用了一组简化公式做粗算，虽然精度不高，但能把推荐结果控制在合理区间，减少工程师做无用功。

第四步是接入几何内核生成模型。AI推荐出来的方案参数，通过脚本传给CAD软件的参数化建模接口，自动生成一个带初步特征的三维模型。这一步是整个系统里最麻烦的，因为工业软件的数据结构非常复杂，直接用脚本驱动经常会遇到特征生成失败的状况。后来我们给每条推荐方案都绑定了对应的建模模板和参数映射表，AI只负责填参数，建模样式是预先定义好的，稳定性才上来。

第五步是建立反馈闭环。系统上线后跑了一个月，我们发现工程师真正“采纳原样”的只有不到三成，大部分人会微调尺寸或改材料，少部分人会推翻重来。我们把所有调整动作记录下来，定期分析哪些推荐偏差最大、为什么偏差。比如承重类零件推荐厚度总是偏厚，分析下来是因为历史案例里大部分设计都做了安全系数放大，而AI不理解“按惯例加厚”不等于“必须这么厚”。后来我们在知识库里给这类设计加了注释，说明“此数据已包含经验安全系数，实际计算时可酌情减小”，推荐精度明显改善。

3.2 大模型与CAD数据交互的工程化实现要点

如果你自己要开发类似的系统，最值得关注的技术难点是“让AI和CAD软件安全对话”。这里我分享两个工程化要点。

第一个要点是操作序列的原子化。AI生成的自然语言指令不能直接砸给CAD内核执行，必须翻译成一张有序的操作列表。比如“在法兰面均布六个孔”，底层可能要拆解成十几个原子操作：选择基准面、创建草图、绘制构造线、定义约束、执行阵列、选择布尔运算方式……每个原子操作都要有参数校验和失败回滚机制。我的做法是让AI只生成JSON格式的高层指令序列，然后由一个前置处理器映射成底层API调用，映射规则写死在代码里，不交给模型自由发挥。这样就避免了模型“发挥创意”导致内核崩溃。

第二个要点是上下文管理。CAD建模是有状态的，上一个特征决定了下一次操作的参考面。传统大模型的上下文窗口管理方式在CAD场景下不够用，因为每生成一个特征，模型需要感知当前模型的拓扑状态。我们实现了一个轻量级的“模型状态摘要器”，每完成一个操作就提取当前模型的关键信息（当前草图平面、最近的实体边界、特征树摘要），压缩成几百字的文本，拼接到下一次模型请求的上下文中。这个方案比让模型直接看全量模型文件高效得多，也省下大量token成本。

在实际部署时还要注意两点。一是给AI限定“能力边界”。我们的系统里专门加了一层权限过滤器，把“删除特征”“修改材料属性”这类高风险操作直接拦截，AI根本不会收到这类请求的授权。二是做好审计追溯。每一次AI发起的建模操作都要记录下来，包括请求原文、生成结果、工程师的最终操作，一旦出问题可以快速回溯是模型理解错还是工程师误操作。

3.3 精度与性能的平衡：实时推荐的量化调优

工业场景对响应速度的要求远高于普通办公场景。工程师在上手设计时，等AI推荐超过十秒就会失去耐心，直接自己手动画了。所以我们的系统设定的目标是：从自然语言输入到拿到推荐方案，端到端延迟不超过五秒。

五秒时间怎么分配？我实测下来大概是：语义理解0.8秒，知识库召回1.2秒，参数适配计算1.5秒，结果格式化输出1秒，其余是网络开销。这里面最大头的是参数适配计算，因为要对推荐案例的尺寸、载荷、材料做实时换算。这一阶段的优化思路是“能离线算的绝不在线算”：把常见材料牌号的许用应力、常见结构形式的承载系数、标准件库的尺寸规格全部预计算好，做成静态查询表，在线阶段只做查表和插值，不做复杂方程求解。

另一个优化点是缓存策略。同一类零件、相近的载荷条件，在工程实践中出现得非常多。我加了一层两级缓存：第一级缓存直接存相同输入条件下的推荐结果，命中就直接返回；第二级缓存存“相似输入”的近似结果，做一个简单修正后返回。实测下来，缓存命中率大概有百分之四十，系统的平均响应时间从4.8秒降到了2.9秒。

这里必须提醒一句：性能优化永远不能在正确性之前。我见过有些团队为了追求响应速度，把知识库检索的召回条件放宽，结果推荐出来的案例和输入需求风马牛不相及，工程师骂声一片。正确的做法是召回阶段宁可少返回几个结果，也要保证每个结果在关键属性上是吻合的。在系统提示里明确标注“当前推荐基于相似工况案例，最终参数需人工确认”，哪怕响应慢一点，信任感建立起来之后效率反而更高。

4. 常见问题与排查技巧实录

4.1 知识库检索不准：不是你模型不行，是数据没洗干净

AI落地工业软件，八成的问题出在“数据进不去、洗不净、连不上”三个环节。先说最典型的：你满怀期待地拿通用大模型去召回知识库里的历史案例，结果模型老是召回一堆相关性很差的文档。问题往往出在数据本身——图纸上的“BOM”“图号”“材料栏”这些字段，在历史档案里格式千差万别，有的是Excel导出的、有的是扫描件OCR的、有的是老系统里导出的乱码文本。向量检索模型再好，喂进去的数据是脏的，出来的一定是错的。

我的排查经验是四个字：先查源头。把每个入库文档自动做一次字段级校验，不达标的直接打回人工清洗队列。清洗规则要有优先级：零件名称、材料牌号、尺寸数值、热处理要求这四类是必须准确的，其余字段的容错率可以放宽。为了降低人工成本，我写了一套自动清洗脚本，用正则加词典做标准化替换，比如统一“未注圆角”和“未注倒角”的表述，“GB/T”和“国标”统一格式，能把百分之六十的脏数据自动修掉，剩下的再人工处理。

另一个容易踩的坑是“向量化时的粒度”。很多团队喜欢把整篇图纸说明文档作为一个整体做向量化，检索时返回整个文档，让模型自己找答案。这么做的问题是：一份图纸里可能包含材料、尺寸、公差、工艺、表面处理五类信息，整篇向量化后语义会被平均化，任何一类都匹配不精准。我改成按“段落语义块”切分，每个块对应一个知识主题，向量化的单位从“文档”变成“语义块”，召回准确率提升非常明显。特别是图纸技术要求里那种一句话包含多个技术参数的，按句切分后匹配精度要高得多。

排查检索不准时还有一个技巧：直接打印出召回的相似度分数和命中的语料片段，贴在调试界面上。看模型到底是被哪些片段误导的，比瞎调embedding参数有效得多。我遇到过的情况是，模型总被“材料牌号相同但使用工况完全不同”的案例带偏，比如Q235B既用来做普通钣金件也用来做承力焊接件，两者壁厚差了好几倍。后来我在知识库里给每个案例加了“工况标签”作为过滤条件，检索时先按工况筛选再算相似度，问题立刻解决。

4.2 模型“一本正经胡说八道”：给AI戴上工业规则的紧箍咒

大模型在工业场景里最让人头疼的就是幻觉。它能把一个不存在的材料牌号说得头头是道，也能把完全不合理的公差推荐得理直气壮。如果你让AI直接参与设计推荐，没有约束机制，早晚出大事。

我处理幻觉的办法不是单纯靠提示词，而是加了三重“物理防线”。

第一道防线是知识库答案溯源。凡是AI基于知识库做出的推荐，必须附带引用的案例编号和原文片段。如果工程师点开推荐结果发现引用的案例跟当前需求根本不沾边，可以直接打回。这道防线的关键是强制要求模型在输出时给出证据链，它就不敢那么放飞自我了。

第二道防线是规则引擎硬校验。所有AI输出的推荐参数，在展示给工程师之前，先跑一遍物理规则校验。比如推荐的钢板厚度必须满足给定的承载强度核算，推荐的材料必须存在于企业材料库中且供应链可用，推荐的公差等级必须符合该加工工艺的经济精度范围。任何一项校验不过，结果直接标记为“预警”或“驳回”，绝不允许原样展示。有些参数AI实在算不准的，就让它输出计算过程和假设条件，由规则引擎用设计公式复核。

第三道防线是人工审核闭环。每周汇总一次AI推荐被驳回的记录，分析驳回原因，反哺调整知识库和检索策略。这些被驳回的记录特别有价值，因为它们是错误的高浓度样本，比你随机找的测试数据更值得标注和学习。我用这个办法把一个轴承选型推荐系统的准确率从76%提到了92%，而且是在不重新训练模型的前提下做到的。

这里要特别说明：不要指望微调能彻底消除幻觉。工业知识持续变化，安全要求复杂，微调模型成本高、收敛慢、回报有限。与其花大价钱调模型，不如把工程约束写扎实。

4.3 系统老是“卡死”：工业软件API调用的稳定性陷阱

做AI和CAD集成的人，最经不起折腾的就是API稳定性问题。我遇到过CAD软件的参数化建模接口在连续调用三百多次之后开始无响应的情况，也遇到过撤销操作和AI生成操作叠加后数据结构错乱的情况。这些问题看着像玄学，其实根子都在“没有做好状态管理和异常恢复”。

第一个实际教训：AI的每个操作序列都必须能被撤销。传统CAD里的撤销是针对工程师手动操作的，AI批量生成的操作序列如果中间某一个失败，会导致模型有残留特征，后面全乱掉。我设计了一套“事务式操作”机制：AI的指令序列执行前，先把当前模型状态做快照；如果执行过程中任何一个操作失败，整体回滚到快照，不让半个特征留在模型里。代价是每次操作前要花零点几秒备份，但换来的稳定性完全值得。

第二个教训：不要把CAD内核的调用放到AI推理线程里。大模型推理有时延波动，一个请求可能几秒也可能几十秒，如果CAD内核调用和模型推理共享线程，很容易互相阻塞。正确做法是拆成两个服务，AI推理完成后，把指令写到消息队列，CAD执行端从队列拉取指令执行。这样即使模型服务出现超时，CAD服务也不会被阻塞，工程师的交互界面也不至于卡死。

第三个教训：给API调用加上熔断和降级机制。当CAD服务连续报错超过阈值时，自动熔断AI生成功能，降级为普通人工建模模式，避免故障像雪崩一样扩散。这个机制上线后，用户反馈的“白屏”和“卡死”工单数降了一半以上。工业场景里稳定性永远高于功能先进性，把这句话刻在项目组的墙上绝对不过分。

4.4 常见问题速查表

5. 多AI协作与Agent化：工业软件的下一步形态

5.1 从“单点助手”到“多Agent协作”的演进路径

现在很多工业软件AI项目卡在一个尴尬阶段：单个AI助手能干活，但工程师还是得在CAD、CAE、PLM、ERP等多个系统里来回切换。比如AI帮你出了一个结构方案，你得自己去CAE里做强度分析，分析完发现问题再回来改CAD，改完还要自己在PLM里走设计变更流程。这种体验还是“人在跑腿”，不是真正的智能化。

我最近在尝试把单点AI助手升级成多Agent协作系统，思路是让不同的AI代理分别负责“设计、校验、优化、审批辅助”四个环节，彼此之间通过消息总线通信。设计Agent生成方案后自动通知校验Agent做规则检查，校验Agent发现问题后带着具体修改建议把任务退回给设计Agent，设计Agent修改完再通知优化Agent做轻量级的多目标优化，最终结果推送给审核Agent整理成符合企业模板的设计说明文档。整个过程工程师只负责在关键节点做决策和确认。

这个架构里最核心的技术点是Agent之间的任务交接协议。每个Agent的输出不能只是文本结论，必须是一个包含“任务目标、约束条件、决策变量、置信度、可追溯依据”的结构化数据包。比如校验Agent给设计Agent退回任务时，得明确说清楚“哪个尺寸不满足哪条标准、建议修改范围是什么、修改后需要重新校核哪些参数”。有了这个协议，Agent之间才能有效协作，而不是鸡同鸭讲。

多Agent协作里最容易翻车的点是责任链断裂。A改了参数，B不知道；B校验通过，C用了旧数据。解决办法是给每个设计状态打一个“数字孪生时间戳”，所有Agent共享一个数据版本管理服务，任何修改都产生新版本，其他Agent只读最新版本，并且自动纳入版本变更记录。这样既能防止数据错乱，也方便追溯每个设计决策是谁在什么时候做的。加上这个版本管理机制后，多Agent协作的可靠性才真正达到可用的程度。

5.2 Agent在CAD场景里的并发与资源调度

多Agent听起来美好，落地时负责人往往被问蒙：“你这一堆Agent要一起上，服务器扛得住吗？工程师一多并发上来怎么办？”我讲一个实际测试数据供参考：一台24核48线程的服务器上，跑了3个设计Agent、1个校验Agent、1个知识库检索服务，8个工程师同时在线使用，每次AI调用平均耗时3.8秒，CPU峰值85%，内存稳定在64GB左右。其实Agent并发的瓶颈不在CPU，而在知识库检索的I/O和大模型推理的GPU资源。

做Agent调度时，我的建议是按任务优先级动态分配模型资源。设计生成任务重、耗时长，用完整的推理链路；简单的规则校验任务跑轻量模型就能完成；紧急的查询任务直接走缓存。调度器要能感知当前系统负载，当并发高时自动把低优先生成类任务排到队列后面，优先保证交互类任务的响应速度。说白了，不能让几个批量生成方案的重任务把GPU霸占了，让正在操作的工程师干等。

还有一个值得注意的坑：Agent互相调用形成循环依赖。设计Agent等校验Agent的反馈，校验Agent等设计Agent提交新版本，两边都在等，最后谁也没动静。我在Agent编排层加了一个“主流程托管机制”，所有Agent的协作都受一个编排器调度，编排器清楚整个任务的当前状态和下一步应该由谁执行。Agent之间不允许直接同步调用，只能通过编排器异步派发。虽然增加了一层消息流转的开销，但彻底避免了循环死锁。

5.3 工业知识的下一个入口：把“经验”本身变成产品

说句掏心窝子的话，我在这个项目里最大的体会是：工业软件AI化，价值最大的其实不是算法本身，而是把“老师傅的经验”从人脑搬到系统里之后形成的知识资产。以前老师傅退休，他一辈子的经验就带走了，企业什么也没留下。现在这些经验变成了知识库、变成了推荐模型、变成了规则引擎，企业数字化底座才算真正厚实起来。

这件事推进的路径我建议分三步走。第一步，把最优秀工程师的设计决策过程记录下来，这是短期就能做的；第二步，把企业历史设计数据整理成结构化知识库，并建立持续更新机制，把老师傅的经验通过“评审—入库—发布”流程沉淀下来；第三步，才是基于知识库做智能推荐和Agent协作，让每个工程师都拥有“冠军老师傅”的旁听视角。很多企业急着从第三步开始，结果知识库是空的，AI巧妇难为无米之炊。顺序一定不能倒。

如果你也想在自己企业里推动这件事，我的忠告是：别从“上一个大模型”开始，先找三个最典型的零件设计场景，手动整理出五十个高质量案例喂给系统，看看工程师用起来的真实反馈，再决定要不要扩大范围。工业软件AI不是靠一次性大投入堆出来的，是靠一个又一个能解决实际痛点的场景扎扎实实堆出来的。把这句话记在心里，比记住任何技术方案都管用。