1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个词很多人脑子里冒出来的画面是对着电脑说一句给我画个齿轮屏幕上就自动长出一个可以加工的三维模型。这个想象方向没错但真正落地的时候它解决的问题比省几下鼠标要深刻得多。传统 CAD 建模的流程是这样的你先在脑子里把零件想清楚然后打开软件选基准面、画草图、标尺寸、加约束、拉伸、倒角、打孔、装配。一个中等复杂度的零件熟练工程师也要折腾一两个小时。问题在于这个过程中大量的时间花在了翻译上——把脑子里的几何意图翻译成软件能理解的草图约束和特征操作。而 text-to-cad 想做的就是把这层翻译工作交给机器让工程师用自然语言直接描述设计意图由系统生成对应的参数化模型或几何体。它适合谁我观察下来有三类人最需要一是做概念设计的产品经理和工业设计师他们脑子里有想法但未必精通 CAD 操作二是需要批量生成标准件、变型件的工程师比如一堆只有孔径和长度不同的支架三是做仿真、做 AI 训练的数据工程师他们需要大量带标注的三维模型手工建模根本喂不饱模型。这三类人的共同点是他们要的是快速拿到可用的几何结果而不是享受建模过程。这里必须先把一个概念说清楚否则后面全是糊涂账。text-to-cad 目前有两条完全不同的技术路线很多人把它们混为一谈结果选型的时候踩大坑。第一条路线是参数化脚本生成。系统理解你的文字后生成一段 CAD 脚本比如 CadQuery、OpenSCAD 或者某个软件的 API 调用再由 CAD 内核执行这段脚本输出真正的 B-rep 实体模型。这条路线的产物是真 CAD——有精确的尺寸、有特征树、可以继续编辑、可以直接导出 STEP 去加工。第二条路线是生成式几何合成。用类似大语言模型或扩散模型的思路直接画出三维网格mesh。这条路线的产物是三角面片看起来像那么回事但尺寸是模糊的没有特征历史想改一个孔的位置基本等于重做。我个人的判断是如果你的目标是能拿去加工、能进装配、能出工程图那必须走第一条路线如果你只是要个视觉参考、做个渲染图、或者喂给下游的 AI 模型第二条路线也能凑合。这个区分是理解整个 text-to-cad 领域的第一把钥匙后面所有的工具选型、效果评估、踩坑经验都建立在这个区分之上。2. 拆解 text-to-cad 的技术链路文字是怎么变成实体的2.1 意图解析层把人话翻译成设计语言用户输入的是一个长 80 毫米、宽 40 毫米、厚 5 毫米的板四角各有一个直径 6 毫米的孔孔中心距边缘 8 毫米。这句话对人来说很清晰对机器来说却是一团需要拆解的语义。意图解析层要做的事情包括识别出这是一个板类零件提取出尺寸参数80/40/5/6/8识别出特征类型拉伸体 四个孔阵列还要推断出隐含的约束孔是对称分布的孔中心到两条边的距离都是 8。这一层现在主流做法是用大语言模型做结构化抽取输出一个 JSON 或者类似的结构化描述。我实测下来这一步的准确率是整个链路里最不稳定的环节。原因很简单自然语言天生有歧义。厚 5 毫米到底是拉伸高度还是壁厚四角各有一个孔如果板是圆角矩形孔该放在圆角圆心还是理论角点这些歧义人靠常识能补模型经常补错。一个实用的经验是在提示词里主动消除歧义。与其说一个厚板不如说一个拉伸高度为 5 毫米的矩形板。与其说四角打孔不如说在矩形四个理论角点向内偏移 8 毫米的位置各打一个直径 6 毫米的通孔。你多打几个字后面返工的时间能省一大截。这不是模型笨而是自然语言本身就不精确工程场景又恰恰要求精确。2.2 脚本生成层结构化描述到可执行代码拿到结构化描述后系统要把它变成 CAD 内核能执行的代码。以 CadQuery 为例上面那块板大概会生成这样的东西import cadquery as cq result ( cq.Workplane(XY) .box(80, 40, 5) .faces(Z) .workplane() .rect(80 - 2*8, 40 - 2*8, forConstructionTrue) .vertices() .hole(6) )这段代码的逻辑是先建一个 80×40×5 的长方体然后选顶面作为工作平面画一个内缩 8 毫米的构造矩形在它的四个顶点上打直径 6 的通孔。注意这里有个细节——孔的位置是通过构造矩形顶点来定位的而不是硬编码四个坐标。这样做的好处是如果后面要把板宽从 40 改成 50孔的位置会自动跟着调整保持边距 8 毫米不变。这就是参数化的价值。脚本生成层的核心难点在于同一个几何意图有多种写法选哪种直接影响模型的可编辑性。硬编码坐标写起来简单但改一个尺寸就全乱用约束和引用写起来绕但改尺寸的时候模型能自适应。我见过不少自动生成的脚本第一眼能跑通第二眼想改就发现全是魔法数字根本没法维护。所以评估一个 text-to-cad 工具别只看它能不能生成要看它生成的脚本像不像人写的。2.3 几何内核层脚本到实体的最后一步脚本写好了得有人执行。CAD 内核就是干这个的。常见的开源内核有 OpenCASCADECadQuery、FreeCAD 底层都用它商业的有 Parasolid、ACIS。内核负责把拉伸打孔这些操作变成真正的 B-rep 数据结构——用解析曲面和拓扑关系来描述实体而不是用三角面片近似。这一步对用户是透明的但它决定了很多东西。比如为什么有些工具生成的模型导出 STEP 之后尺寸是准的有些就飘了因为前者走的是真内核后者是网格近似。再比如为什么有些工具打孔特别慢因为布尔运算从实体里减去圆柱是内核里最耗时的操作之一孔越多越慢。我踩过的一个坑是早期用某个基于网格的方案做带几十个孔的板生成速度飞快但导出 STEP 之后发现孔变成了多边形近似直径 6 毫米的孔实际是 5.97 到 6.03 之间波动的多边形。拿去加工直接被师傅打回来。后来换成基于 OpenCASCADE 的方案速度慢了一半但尺寸是精确的。在工程场景里精确性永远优先于速度这个取舍要想清楚。3. 主流实现方案横向对比别被演示视频骗了3.1 基于代码生成的方案CadQuery / OpenSCAD 路线这条路线的代表是各种LLM CadQuery的组合。用户输入文字模型生成 CadQuery 的 Python 代码然后本地执行。优点是产物是真 CAD可导出 STEP/STL可参数化可版本控制代码就是模型。缺点是对模型的代码能力要求高生成的代码经常有语法错误或者 API 用错。我实测过几个不同的模型来生成 CadQuery 代码结论是代码能力强的通用大模型在这件事上明显优于专门微调过的小模型。原因在于 CadQuery 的 API 虽然不算复杂但组合方式极其灵活需要模型有比较强的编程常识。专门微调的小模型往往只会背几个常见模板遇到稍微非常规的需求就抓瞎。用这条路线有几个实操要点值得记下来。第一一定要在提示词里给出 CadQuery 的版本和关键 API 示例否则模型会用错方法名。第二生成的代码要先做语法检查再执行直接 exec 有安全风险。第三给代码加超时因为有些布尔运算会卡死。第四把常用零件做成函数库让模型调用而不是从零生成稳定性会高很多。3.2 基于网格生成的方案扩散模型路线这条路线的思路完全不同把三维形状表示成某种隐式场或者点云用扩散模型直接生成。代表工作是各种 text-to-3D 的模型。优点是生成速度快、视觉效果好、能处理非常复杂的有机形状。缺点是产物是网格尺寸不精确没有特征结构改不动。我拿这类方案做过一个测试让它生成一个带法兰的管道接头。出来的东西远看挺像近看法兰的螺栓孔是随机分布的管道内径和外径的比例也不对。作为概念参考图可以作为工程输入完全不行。所以这条路线我的定位很明确概念阶段的视觉探索可以用进入工程阶段立刻切换到代码生成路线。3.3 两条路线的关键差异对照对比维度代码生成路线网格生成路线输出格式B-rep 实体STEP/STL三角网格OBJ/GLB尺寸精度精确可标注近似有误差可编辑性高改参数即可低基本重做生成速度较慢依赖内核运算较快复杂曲面弱适合规则几何强适合有机形状工程可用性可直接加工仅作参考典型工具CadQuery、OpenSCAD各类 text-to-3D 模型这张表是我自己在选型时反复对照的。核心结论就一句话先想清楚你要的是能用的模型还是能看的模型再选路线。这个判断做错了后面所有努力都是白费。4. 从零搭一个可用的 text-to-cad 流程我的实操步骤4.1 环境准备与依赖选择假设你要自己搭一套我建议的最小可行组合是这样的Python 3.10 以上CadQuery 2.x一个代码能力强的通用大模型 API再加一个简单的 Web 界面Streamlit 就够。为什么选 CadQuery 而不是 OpenSCAD因为 CadQuery 是 Python 库能直接和模型生成的代码在同一进程里跑调试方便OpenSCAD 是独立语言还得跨进程调用链路更长。安装 CadQuery 有个坑要提醒它依赖 OpenCASCADE 的二进制包在某些系统上直接 pip install 会编译失败。稳妥的做法是用 conda 装或者用官方提供的预编译 wheel。我第一次装的时候在编译环节卡了快一个小时后来换 conda 五分钟搞定。这种环境问题看着低级但真的会劝退很多人。conda create -n text2cad python3.10 conda activate text2cad conda install -c conda-forge cadquery装完之后跑一个最小验证确认内核能用import cadquery as cq box cq.Workplane(XY).box(10, 10, 10) cq.exporters.export(box, test.step) print(内核正常)能导出 STEP 文件说明环境没问题可以往下走。4.2 提示词工程让模型稳定输出可执行代码这一步是整个流程里最需要打磨的地方。我的做法是准备一个系统提示词里面包含四块内容CadQuery 的版本信息、常用 API 的签名和示例、输出格式要求只要代码不要解释、以及几条硬性约束比如不要使用未定义的变量所有尺寸用变量表示。一个我反复验证有效的技巧是给模型几个少样本示例。比如给一个生成带孔板的完整代码再给一个生成阶梯轴的完整代码模型照着这个风格生成出错率会明显下降。这比单纯用文字描述要求管用得多因为代码这种东西示例比描述精确。还有一个细节要求模型把关键尺寸提取成顶部的变量。这样生成的代码长这样LENGTH 80 WIDTH 40 THICKNESS 5 HOLE_DIA 6 EDGE_OFFSET 8后面如果用户说把长度改成 100你只需要改一个变量重新执行不用重新问模型。这个设计让整个流程从一次性生成变成了可迭代调整实用性提升一大截。4.3 执行沙箱与错误处理模型生成的代码不能直接在主进程里 exec这是基本的安全意识。我的做法是开一个子进程执行设置超时比如 30 秒捕获所有异常把错误信息回传给模型让它自我修正。自我修正这个环节特别关键。实测下来模型第一次生成的代码大概有 30% 到 40% 的概率跑不通但把报错信息喂回去让它改第二次的成功率能到 80% 以上。常见的错误包括方法名拼错、参数顺序搞反、忘记 import、workplane 选错面。这些错误模型自己看报错基本都能改对。import subprocess def run_cadquery_code(code, timeout30): try: result subprocess.run( [python, -c, code], capture_outputTrue, textTrue, timeouttimeout ) if result.returncode ! 0: return None, result.stderr return result.stdout, None except subprocess.TimeoutExpired: return None, 执行超时可能是布尔运算过于复杂这段代码是我实际在用的简化版。注意超时处理因为有些几何操作真的会卡住没有超时保护整个服务就挂了。4.4 结果验证怎么判断生成的模型对不对代码跑通了不代表模型是对的。我见过生成的代码能执行、能导出文件但尺寸完全不是用户要的情况。所以必须加一层验证。验证分两个层面。几何层面检查包围盒尺寸是否和用户描述一致检查孔的数量和位置。这个可以用 CadQuery 自己的 API 做比如box.val().BoundingBox()能拿到包围盒。语义层面把生成的模型渲染成图片让多模态模型看一眼判断这像不像用户要的东西。这一层能抓住一些几何检查抓不到的错比如用户要的是L 形支架结果生成的是T 形。我个人的经验是几何层面的自动检查能覆盖 70% 的错误剩下的靠人工确认或者多模态复核。完全自动化的闭环目前还不现实但把人工介入点从每次都要看降到只在可疑时看效率提升已经很大了。5. 实战中真正会遇到的坑几个典型场景复盘5.1 尺寸歧义导致的返工有个场景我印象很深用户说做一个能放下手机的盒子。这句话里没有任何一个精确尺寸。模型只能猜猜出来一个 150×80×10 的盒子。用户一看说不对我要的是能放下带壳的手机而且要有 2 毫米余量。于是重新描述模型再生成来回好几轮。这个坑的本质是自然语言描述天然缺少工程所需的精度。解决办法不是让模型更聪明而是在交互设计上做文章——当用户描述里缺少关键尺寸时系统主动追问而不是自己猜。我后来在流程里加了一个参数确认环节模型先输出它理解的参数列表让用户确认或修改确认后再生成代码。这一步加进去之后返工率下降非常明显。5.2 布尔运算失败与几何退化打孔、开槽、倒角这些操作本质都是布尔运算。布尔运算在几何上有个麻烦当两个面恰好重合或者相切时内核可能算不出来或者算出退化结果。比如你要在一个直径 6 的孔的位置恰好那里有个直径 6 的凸台两者相切布尔减就可能失败。我遇到过一次生成一个带沉孔的板沉孔深度恰好等于板厚结果沉孔底面和板底面重合内核直接报错。解决办法是把沉孔深度设成板厚减 0.01留一点余量。这种工程上的小聪明模型是不会主动想到的得靠人在提示词里加约束或者在错误处理里加自动修正规则。提示在提示词里加一条避免任何两个面完全重合的几何操作必要时留 0.01 毫米余量能规避掉相当一部分布尔运算失败。5.3 复杂装配体的组合爆炸单个零件好办一旦涉及装配难度陡增。用户说把这三个零件装在一起轴穿过两个轴承座模型要理解的不只是三个零件的几何还有它们之间的配合关系、同轴约束、间隙。我试过让模型直接生成装配代码结果经常是零件位置对不上或者配合面有干涉。我的做法是分而治之先分别生成每个零件确认无误后再用一个单独的步骤处理装配。装配这一步用显式的坐标和约束描述而不是让模型自由发挥。虽然麻烦一点但可控性高得多。装配这件事目前阶段还是人给约束、机器执行比较靠谱。5.4 生成结果的版本管理用代码生成模型有个巨大的好处模型就是代码可以用 Git 管理。我现在的做法是每次生成都存一个带时间戳的脚本文件配合一个简单的元数据记录用户输入、生成时间、是否通过验证。这样出问题能回溯好的结果能复用。这个习惯看起来不起眼但用久了价值很大。有一次用户说上次那个支架挺好的就是孔再大一点我直接翻出历史脚本改一个变量重新生成两分钟搞定。如果没有版本管理就得从头再来一遍。6. 这套东西的边界在哪里什么能做什么别指望6.1 适合自动生成的零件类型根据我的实践以下几类零件用 text-to-cad 生成的成功率最高板类零件带孔、带槽、带倒角、轴类零件阶梯轴、带键槽、带螺纹、简单的支架和连接件、标准件的变型不同尺寸的螺栓、垫圈、法兰。这些零件的共同特点是几何规则、特征明确、参数化程度高。反过来以下几类目前别指望自由曲面比如汽车外形、叶轮叶片、复杂的有机形状、需要大量工程判断的结构比如考虑受力优化的拓扑结构、高精度配合的装配体。这些要么几何太复杂要么需要领域知识模型目前搞不定。6.2 精度与公差的现实text-to-cad 生成的是名义几何也就是理想尺寸。但实际加工需要公差。模型不会主动给你标公差也不会考虑配合间隙。所以生成的模型只能作为设计的起点公差标注、配合选择这些还是得工程师来做。我一般会把生成的模型当作第一版草图然后在这个基础上手动加公差、加技术要求。这样整体效率还是比从零建模高但别指望它一步到位出成品图。6.3 和现有 CAD 工作流的衔接生成的 STEP 文件能导入主流 CAD 软件但导入之后是一个哑实体——没有特征树没有草图改尺寸得用直接建模的方式。如果你需要保留参数化特征那得用 CadQuery 脚本本身作为源文件而不是 STEP。我的建议是把 CadQuery 脚本当作设计源文件管理STEP 当作交付格式导出。这样既有参数化的可编辑性又能和下游工具对接。这个工作流和传统 CAD 的源文件 导出逻辑是一致的只是源文件从二进制变成了代码。7. 我踩过的几个印象深刻的坑第一个坑是过度信任模型的几何直觉。有一次让模型生成一个壁厚 2 毫米的方管结果它生成了一个实心方块。我盯着代码看了半天才发现模型把方管理解成了方的管子但生成的时候用的是 box 而不是带抽壳的体。这种错误不是语法错误代码能跑但语义完全错了。从那以后我养成了习惯生成完先看包围盒和体积体积明显不对就说明理解错了。第二个坑是忽略单位。CadQuery 默认单位是毫米但有些模型生成的代码里混入了英寸的数值。有一次生成的零件尺寸大了 25.4 倍导进 CAD 一看像个巨型雕塑。后来我在提示词里强制要求所有尺寸单位为毫米并在代码注释里标注单位这个问题就少了。第三个坑是布尔运算的顺序。先打孔再倒角和先倒角再打孔结果可能不一样。模型有时候会选一个导致几何问题的顺序。我的经验是在提示词里明确要求先做加法拉伸、凸台再做减法打孔、开槽最后做倒角和圆角这个顺序最稳妥。第四个坑是对简单的误判。用户说很简单就一个圆柱结果这个圆柱要带螺纹、要带退刀槽、要带中心孔。模型按字面理解生成了一个光圆柱。这提醒我用户的简单和工程的简单不是一回事交互时要多问一句有没有其他特征要求。8. 给想上手的人的几条实在建议如果你现在想动手试试 text-to-cad我的建议是按这个顺序来。先用现成的工具跑几个例子感受一下能力边界别一上来就自己搭。然后从最简单的零件开始比如一块带四个孔的板把整个链路跑通。跑通之后再逐步增加复杂度每次只加一个变量这样出问题容易定位。工具选型上如果你要工程可用的结果认准基于 CadQuery 或类似代码生成路线的方案如果你只是要视觉效果网格生成路线更省事。别在选型上纠结太久两条路线各花半天试试感受比看一百篇对比文章都直接。最后说一个心态问题。text-to-cad 现在的能力大概相当于一个刚学会 CAD 基本操作的实习生——能干活但需要你盯着需要你给清晰的指令偶尔会犯低级错误。把它当实习生用你的预期就对了把它当资深工程师用你一定会失望。这个定位想清楚了用起来反而顺手因为你会在合适的地方介入而不是指望它全自动。我自己现在的用法是概念阶段用它快速出几个方案选定方向后用生成的脚本作为起点手动细化。这样既享受了自动化的速度又保证了工程的严谨。这个人机协作的模式我认为是现阶段最务实的做法。
