1. 为什么说 text-to-cad 不是“3D版文生图”1.1 从“看得像”到“算得对”上周我在整理标准件库同事扔过来一句话“能不能直接说‘我要一个 M6×30 的六角螺栓’软件就自己画出来”我差点脱口而出“能”直到自己把 text-to-cad 的完整链路跑了一遍才发现这个词听起来浪漫做起来全是工程上的硬骨头。先说结论text-to-cad 的目标不是生成一张“看起来像螺栓”的渲染图而是生成一个可以被 CAD 软件打开、可以编辑特征、可以标注公差、可以进入装配体、可以出工程图、甚至可以直接送去加工的实体模型。也就是说它要从“像素级正确”跃迁到“几何级正确”和“语义级正确”。文生图模型画出六角头、螺杆、螺纹纹理那是视觉游戏而 text-to-cad 必须保证螺纹的牙型角是 60 度、公称直径是 6mm、对边宽度是 10mm这些数字差 0.1mm装配就会出问题。我对这个领域最早的判断是它很像是给 CAD 软件装了一个“人类语言前端”。传统 CAD 的操作门槛在于用户必须把脑子里的三维构思拆解成“草图 → 拉伸 → 倒角 → 阵列”这一系列离散操作。text-to-cad 则是反过来让用户直接描述最终物体或功能意图然后由模型自动补全中间步骤。这个设想如果成立机械设计、工业设计、3D 打印、零部件选型这些场景都会发生一次不小的效率跃迁。但真正动手之后你会发现它跟文生图完全不是一回事。文生图允许模型“自由发挥”画坏了重画一张就行CAD 模型则必须满足可计算、可验证、可制造这三个硬条件。哪怕模型长得完全正确只要五个面围不成一个封闭实体它就是废的。1.2 CAD 是一个强约束的符号系统很多刚接触的人会问直接用现在的 3D 生成模型比如生成 NeRF、 mesh、SDF不就行了吗把文本变成点云或者三角网格再丢给 3D 打印是不是就算 text-to-cad 了问题恰恰出在这里。CAD 领域的通用语言是边界表示B-Rep而不是三角网格。网格适合做渲染和 3D 打印切片但它没有“参数历史”没有“特征树”没有“草图约束”更难标注公差和表面粗糙度。你拿到一个 STL 文件想改一个孔的直径必须重新建模想在倒角半径从 2 改成 3网格根本不知道“哪个凸起是倒角”。工程师日常用的是“参数化实体模型”一个螺栓由拉伸六边形、旋转螺纹、倒角几个特征组成改一个参数全模型联动更新。这才是 CAD 的正规军。text-to-cad 之所以难就在于它输出的对象必须是这种强语义、强约束的符号系统。模型要理解“M6”不是“6 毫米长的线”而是“公称直径 6mm、螺距 1mm、牙型角 60 度的公制螺纹”这一整套工程语义。它还要理解“30mm 是螺杆长度还是总长度”“是否带全螺纹”“头部要不要内六角”这些隐藏信息。这些信息在自然语言里通常被压缩成一个名词短语但在 CAD 里是几十个参数。我还观察到用户输入的描述往往也分好几个层次。有人会说“我要一个能放手机的桌面支架”这是功能意图有人会说“设计一个 L 形支架底板 80×60×5立板 60×50×4两根加强筋孔距 55mm”这是参数化描述还有人直接说“按 DIN 933 标准M6×30”这是标准件语义。三种输入对 text-to-cad 系统的要求完全不一样。第一种需要 AI 做功能推理和结构设计难度最大第二种需要 AI 做参数抽取和特征识别目前最可控第三种需要系统内置标准件知识库几乎算不上生成更像是智能检索。想清楚你的用户属于哪一层才能选对技术路线而不是一听“自然语言生成 CAD”就热血上头。2. 我拆过的几条技术路线生成、参数化、检索2.1 端到端生成模型理想很丰满B-Rep 还很骨感学术界叫“text-to-cad”的技术路线最吸引人的是端到端生成模型。它的思路是把 CAD 建模过程表示成一个序列比如“拉伸一个正六边形高度 4mm在顶面画一个圆直径 6mm拉伸 30mm在末端切一个倒角……”然后用类似语言模型的自回归方式让模型根据文本预测这个序列。这样输出的不是网格而是可重建出 B-Rep 实体的建模指令序列。这个方向确实有论文做出了不错的结果比如用文本编码器像 CLIP 那种把描述映射成向量再用解码器生成草图参数和拉伸/倒角操作。我实际测试过一些开源权重简单场景还行一句话生成一个带孔方块、一个法兰盘、一个简化的支架这些都能跑通。但一旦文本里出现“四个均布孔”“螺纹深度 18mm”“与底面成 30 度夹角”这类工程约束模型就开始胡来。端到端模型最大的问题有三个一是训练数据不足。人类历史上留下的 CAD 模型很多但完整记录“建模操作序列自然语言描述”的数据极少导致模型学到的只是“形似”而非“神似”。二是几何合法性没有保证。自回归生成的是离散 token模型并不知道这些 token 拼起来能不能形成一个封闭实体。可能画出来的草图有自交线段可能拉伸方向反了可能两个特征根本没有相交。三是可解释性差。用户没法知道模型为什么选择这个倒角半径出了问题也没法局部修正。所以我的判断是端到端生成模型适合跑 demo、适合做造型灵感探索但离工程落地还有距离。2.2 LLM 参数化建模脚本当前最容易被工程化的路线我实际项目里最推荐、也最好落地的一条路是用大语言模型LLM做“语义到参数的转换”再用参数化建模引擎比如 CadQuery、OpenSCAD、FreeCAD把参数变成实体模型。原因很简单LLM 不擅长精确计算几何但非常擅长理解自然语言、抽取关键参数、生成符合格式要求的代码而参数化建模引擎恰恰相反它笨、但它算得准。整个流程是一个清晰的三段式先让 LLM 把输入的文本解析成结构化参数比如 JSON 对象然后把参数填入预先写好的建模模板函数生成 CadQuery/OpenSCAD 脚本最后用开源内核执行脚本输出 STEP/STL再做自动验证。这样做的好处是“AI 负责理解代码负责精确”。即使 LLM 输出的参数是错的你也可以通过校验规则拦截而不会让一个乱七八糟的几何体混进模型库。我在下面会详细展开这条路的实操细节。这里先给一个很直观的类比我们不是在训练一个“会画画的 AI”而是在给一个“会看图纸的实习生”配了一把绝对精确的数字卡尺。LLM 负责读懂图纸上写的是什么卡尺负责量出准确数字最后交给数控机床加工。只要卡尺是好的整个链路就基本可控。2.3 检索-装配式方案不生成去匹配还有一个容易被忽略但实际很高效的路线检索装配。很多用户说“生成一个 M6 螺栓”其实他们不想要一个从未见过的新螺栓而是希望从标准件库里快速找到对应规格。这种情况下与其让模型从零画不如让 LLM 把描述转成结构化查询条件去数据库里检索已有模型再把检索结果装配到目标位置。这套方案特别适合企业场景。绝大多数制造业公司里重复使用的标准件、通用件、历史件占整个物料体系的 70% 以上。它们不需要“发明”只需要“找得到”。text-to-cad 在这里的价值不是生成几何而是把“帮我找一个法兰面上的 8 个 M8 螺栓”这句话翻译成“螺栓规格 M8、长度 30、数量 8、分布圆直径 100、角度 45 度起始”的查询和装配指令然后自动完成装配。三种路线相比端到端生成上限最高但下限也最低LLM参数化脚本是当前投入产出比最高的选项检索装配则是最容易让老板看到实际收益的方案。我建议团队在立项时先想清楚你要做的是“创造新模型”还是“快速把已有模型用起来”。大多数场景其实是后者。3. 实操复盘用 CadQuery 把“M6 螺栓”变成实体模型这一节我用自己的实测过程演示 LLM参数化脚本这条路线怎么落地。我用的是开源工具链不需要商业 CAD 许可证预期效果是输入一句话输出一个带标准参数的 STEP 文件和一个可编辑的 CadQuery 脚本。3.1 先磨好环境Python/CadQuery/验证工具我的环境是 Python 3.11 CadQuery 2.4。安装非常简单用 conda 建一个干净环境然后 pip 安装即可conda create -n text2cad python3.11 -y conda activate text2cad pip install cadqueryCadQuery 底层封装了 OpenCASCADEOCP所以安装完之后你实际上等于拥有了一套完整的 B-Rep 建模内核。之后我还会装manifold3d做网格检查装numpy做坐标计算。如果你要本地跑 LLM可以再装vllm或者ollama我这次用了开源模型做参数抽取避免把整个流程绑在某个云服务上。这里有一个非常值得注意的坑CadQuery 对 Python 版本有要求拿到新环境先跑一句python -c import cadquery; print(cadquery.__version__)。很多所谓“装不上”的问题其实都是 conda 环境混用了不同 Python 版本。单独建环境别偷懒。3.2 提示词设计让大模型输出结构化参数LLM 做参数抽取不是把用户的原始描述直接丢给它然后让它“画一个模型”。我是用一套固定的提示词要求它只输出 JSON字段名全部提前定义好。下面是我常用的提取 schema{ part_type: hex_bolt, thread_dia: 6.0, pitch: 1.0, head_style: hex, head_width: 10.0, head_height: 4.0, body_len: 30.0, thread_len: 18.0, standard: DIN933, material: steel }提示词大致是这样的你是机械零件参数抽取器。根据用户输入的零件描述提取 JSON 参数。只输出 JSON不要解释。如果描述中缺少某个字段使用默认值填充。单位是毫米。如果描述中提到标准号优先按标准覆盖默认值。你可能会问为什么不直接让模型生成 CadQuery 代码而要先输出 JSON因为 JSON 是稳定的中间表示可以校验、可以存档、可以让后续不同的建模后端共用。直接生成代码模型一旦写了不存在的 API你就得不断修复JSON 参数就简单得多抽取值放在模板里十行代码跑完。3.3 生成代码与模型从 JSON 到 B-Rep拿到 JSON 之后我用一个预先写好的建模函数生成实体。下面是一个简化版的函数用来生成六角头螺栓的拉伸主体import cadquery as cq def hex_bolt(thread_dia6.0, pitch1.0, head_width10.0, head_height4.0, body_len30.0, thread_len18.0): # 头部正六边形拉伸对边宽度 head_width head (cq.Workplane(XY) .polygon(6, head_width / 0.866) # 六边形外接圆直径公式 .extrude(head_height)) # 光杆圆柱拉伸 shank (cq.Workplane(XY) .circle(thread_dia / 2) .extrude(body_len) .translate((0, 0, head_height))) return head.union(shank)这里polygon(6, x)的x是外接圆直径而螺栓头部对边宽度是 10mm所以要除以cos(30°)≈0.866。这就是建模模板里需要工程知识的地方LLM 不一定懂但我们预先写好的模板懂。真正的 ISO 螺纹我不会用简单的圆柱代替而是会用一个独立的make_iso_thread函数去生成螺旋体。但这部分代码较长而且涉及牙底圆弧、螺距补偿等情况。如果你只是做装配验证和渲染可以用简化螺纹如果要出加工图或 3D 打印还是建议去调标准的螺纹库。下面只展示最终导出 STEP 和 STLcq.exporters.export(bolt, M6x30.step) cq.exporters.export(bolt, M6x30.stl, tolerance0.01, angularTolerance0.1)导出 STL 时tolerance和angularTolerance要按用途来做有限元网格、快速预览分辨率可以低一点做 3D 打印切片建议tolerance0.01否则螺纹表面会呈多边形。3.4 模型验证清单面积、体积、干涉、加工性生成模型只是第一步紧接着要做自动验证。我把验证拆成四层有效性模型是不是一个封闭实体在 CadQuery 里shape.val().Volume()如果为 0说明模型可能不是实体或者根本没封闭。参数回读用importStep读回模型测量关键尺寸是否与期望一致。比如头部对边距离是否约等于 10mm光杆直径是否约等于 6mm。干涉检查把螺栓放进预先准备好的螺母模型里用布尔求交看干涉体积是否为 0。如果干涉大于某个阈值说明螺纹参数不匹配或者装配方向有问题。制造性这个比较主观但我们可以检查最小的壁厚、孔径与螺栓直径的比例甚至直接用切片软件做一次模拟切片。模型好看不等于能加工后面我会单独说。以下是简单的读回和体积检查shape cq.importers.importStep(M6x30.step) vol shape.val().Volume() if vol 1e-6: raise ValueError(模型体积为零生成失败) print(fVolume: {vol:.3f} mm^3)单项检查容易难的是把检查结果和文本描述做“闭环”。我最后的流程是如果验证失败就把失败原因和模型状态反馈给 LLM让 LLM 修正参数后重新生成。这个“生成→验证→再生成”的循环才是真正实用的 text-to-cad 形态。4. 我在实测中踩过的五个坑4.1 同一个词三种理解第一坑来自“M6×30”这个写法和语义歧义。我让模型生成一个“M6×30 六角螺栓”它给出了一个总长 30mm 的螺栓头部占掉 4mm光杆只有 26mm。但我预期的是“公称长度 30mm”即头部以下光杆加螺纹共 30mm。两种理解差出 4mm在装配时可能直接导致螺栓不够长。更麻烦的是“M6×30”还可能被理解成“螺纹长度 30mm”的命名方式。标准件行业里不同公司、不同时代的图纸都有自己的缩写习惯。解决办法不是去“纠正”模型而是在提示词里写清楚字段定义并且在产品界面上让用户二次确认。我后来在参数 schema 中增加了length_definition字段取值为overall_length或shank_length默认按 GB/DIN 的定义设为“公称长度头部以下长度”歧义率立刻降了很多。4.2 螺纹到底要不要画出来这个坑几乎每个做 text-to-cad 的人都躲不掉。大部分文生图模型输出的螺栓图片里螺纹是“画”出来的但 CAD 里螺纹是一个螺旋扫描特征计算量比圆柱大很多生成时容易报错而且对显示性能影响巨大。实际项目里我见过太多团队为了追求“看起来专业”非要在螺栓上生成完整螺纹结果一个 M6 螺栓的 STEP 文件体积超过 50MB下游装配变得奇慢无比。我的经验是先问用途。如果目标是快速选型、装配示意光杆简化螺纹环带就够如果目标是模具加工、3D 打印或有限元接触分析那必须建立真实的螺纹螺旋线并且按标准校验牙型。text-to-cad 系统里应该内置一个“螺纹精度等级”开关而不是一刀切。4.3 坐标系与装配方向单件看着对装配全错模型单独打开什么问题都没有往装配体里一放才发现螺栓轴线和孔轴线夹角不对或者头部方向装反了。这个问题不是几何形状的问题而是模型缺少“装配语义”。文本里说“把螺栓装入法兰”这其实包含位置、方向、配合关系三层信息。目前的 LLM 只会回答“螺栓头是六角形”要它理解“螺栓轴线与法兰孔轴线重合头部朝上”还需要额外提供装配接口。我在落地时采用了一个比较土但有效的办法让提示词固定输出一个placement字段包含原点(x, y, z)、轴向(dx, dy, dz)然后在建模模板里自动做一个旋转变换。这样至少让系统具备“先生成、再摆放”的能力不至于每一步都要人工拖拽。4.4 STL 好看不能算 CAD有一次我给团队看 demo生成出来的零件在渲染器里非常漂亮大家都很兴奋。后来一位老工程师问“这个模型能不能改孔距”我试了一下发现系统输出的只有 STL。那一刻我意识到text-to-cad 如果最终输出 STL那就等于把用户踢出了 CAD 工作流。STL 是万能的“显示格式”但不是“编辑格式”。改一个孔距需要把表面三角面片里的几百个节点全部重算这在工程上是不可接受的。正确做法是系统至少同时输出 STEPB-Rep 实体和原始建模脚本CadQuery/OpenSCAD 源码。STEP 用于下游 CAM/CAE脚本用于后期参数修改。如果只能输出一种我会毫不犹豫地放弃“好看”的 STL保存“耐改”的脚本和 STEP。4.5 大模型的“幻觉式公差”这是最隐蔽的坑。模型对“间隙配合”这类术语有模糊的理解有时会擅自决定配合间隙大小。比如描述里写“M6 螺栓和通孔间隙配合”模型生成一个直径 6.5mm 的孔。如果对方在精密装配里要求 H8/h7 的配合6.5mm 的间隙会造成明显松动根本没法用。解决办法是在建模模板里内置配合表当 LLM 识别到“间隙配合/过渡配合/过盈配合”系统自动根据公称尺寸查对应的公差带而不是把“间隙大小”交给 LLM 自由发挥。同样的逻辑也适用于倒角大小、壁厚、拔模斜度这些容易被 LLM 编出怪异数值的参数。一句话让 LLM 做选择题别让它做计算题。坑现象缓解手段长度定义歧义总长/杆长/螺纹长互相混淆增加字段定义强制约定标准螺纹细节简化或过于复杂按用途提供精度开关坐标系方向单件正常装配错位固定输出 placement 字段输出格式只有 STL无法编辑同时输出 STEP脚本公差幻觉配合间隙乱填内置配合表查表取值5. 对前线的价值判断与落地节奏5.1 最适合首批尝试的任务我建议团队在起步阶段别野心太大把 text-to-cad 用于下面几类任务成功率最高标准件库的智能调取把“M6 六角螺栓长度 30镀锌”变成标准件编码和装配关系。这不是生成是智能检索但用户体验上已经有“输入一句话就出来模型”的效果。简单拉伸/旋转类零件比如垫片、法兰、轴套、支架。这些零件特征数量少、参数清晰非常适合 LLM 参数抽取 模板建模。历史模型的参数化重构老图纸只有 PDF 或 STL让 LLM 读取文字标注生成参数化模型再人工确认。虽然还做不到全自动但能省掉 80% 的重复建模时间。创意阶段的快速打样设计师描述一个概念系统生成 3-5 个候选模型供用户挑选和修改。这里对精度要求低对多样性和出图速度要求高反而是端到端生成模型能发光的地方。5.2 短期不要碰的场景有些场景看起来很诱人但做起来容易翻车比如自由曲面产品设计汽车车身、消费电子外壳这些模型的曲面连续性、美学要求极高目前的 text-to-cad 根本生成不了可控的 A 级曲面。复杂装配体设计一台减速器几十个零件彼此有齿轮啮合、轴承配合、密封要求。文本很难表达完整装配逻辑系统也很难自动推理。安全关键件承力结构、压力容器、医疗植入物这类零件需要完整的强度校核和可追溯设计过程法律与合规上也不会允许“AI 直接生成图纸就投产”。需要频繁人工创意决策的场景如果整个设计过程是一连串的“非标选择”那 text-to-cad 只能做一个辅助工具不能作为主流程。5.3 团队落地的一些方法最后聊聊怎么把 text-to-cad 真正用起来。我发现最容易成功的落地方式不是做一个“万能输入框”而是圈定一个很小的零件家族做端到端闭环。先选 20 个典型零件人工写出标准提示词和标准建模模板把“输入一句话→生成 STEP→自动检查”→这个链路跑通。然后让设计团队每天用记录哪些描述经常被误解把误解案例反哺到提示词和校验规则里。这个循环跑上一个月系统的可用度会明显提升。另一个建议是不要追求 100% 自动化。合理的人机协作方式是AI 快速生成初稿CAD 工程师负责审单和微调。只要“从零开始建模”的时间能缩短一半这个工具就有价值。一次性把“全自动、免审核”作为目标实践里几乎都会卡在质量风险和信任问题上。从我个人的经验看text-to-cad 这个方向真正成熟还需要一段时间但“LLM 理解意图 参数化模板生成模型”这条路现在已经可以给实际工作流带来真金白银的效率提升。如果你也准备试不妨从小而美的场景切入跑通一个闭环再谈扩展。到时候你可能会发现最有用的不是那个“生成模型的 AI”而是你为了让它干活而梳理清楚的那套参数体系和标准规范。