1. text-to-cad 到底在解决什么问题
先说结论：text-to-cad，就是用自然语言直接生成 CAD 模型。你输入一句话，比如“做一个直径 40mm、厚度 3mm 的圆盘法兰，周围均匀开 6 个直径 5mm 的螺栓孔”，模型直接输出一个可以编辑、可以导出的参数化 CAD 文件，而不是一张图片、一个点云或者一个粗糙的网格。这两年这个概念在机械设计、3D 打印、自动化设计领域讨论度很高，从学术论文里的 demo 到工程上真正能用的工具，进展比想象中快。
为什么这事儿值得关注？因为传统 CAD 建模的门槛真的不低。你让一个没有受过系统训练的人打开 SolidWorks 或者 Fusion 360，光是搞明白“草图-拉伸-切除-倒角”这一套逻辑就得花不少时间。就算熟练工，面对一个稍微复杂的零件，从画草图到把特征树整理干净，快则半小时，慢则一整天。而 text-to-cad 想做的事情，是把“我脑子里的想法”到“电脑里的三维模型”这段路径大幅缩短，你只需要描述清楚需求，剩下的建模动作交给算法。
适合谁来参考这篇内容？如果你在做 AI 应用、自动化设计工具链，或者你想评估 text-to-cad 能不能用在你的工作流里，这篇文章应该能帮你搞清楚原理、上手路径和坑在哪。如果你是建模老手，也可以把它当成一个新的效率工具或者“灵感生成器”来用——很多情况下它生成的模型不是最终答案，但可以给你一个起点。我会从原理拆解、数据从哪来、模型怎么选、实操怎么跑通、问题怎么排查这几个角度，把这件事说透。
2. 关键技术实现原理
2.1 核心思路：文本不是直接变成模型，而是变成建模指令
这是理解 text-to-cad 最重要的一点。现在的主流实现，基本都不是“端到端”地让模型直接吐出一个三维模型文件，而是分两步走。
第一步，用一个语言模型把文本描述翻译成一段结构化的建模指令序列。第二步，把这段指令交给一个 CAD 内核去执行。那“建模指令”长什么样？常见的有两种：一种是直接生成 OpenSCAD 的脚本代码，OpenSCAD 本身就是用代码描述模型的工具，语法简单直观，比如 cube([20,20,10]) 就是画一个方块；另一种是生成更接近工业软件内部操作的指令序列，比如“创建草图平面”“画一条直线”“做拉伸特征”“加倒角”，这种方式更接近人在 SolidWorks 里的操作逻辑，生成的模型也更利于后续参数化修改。
为什么不能像文生图那样端到端直接输出模型？核心原因是三维模型的表示方式太不统一了。图片是像素矩阵，天然是规则的；而 CAD 模型在底层是 NURBS 曲面、B-Rep 边界表示，或者 CSG 布尔运算树，每一种表示都是一大堆顶点、曲线、面片和拓扑关系的组合。让模型直接生成这么复杂的数据结构，在现有的深度学习框架下非常困难，输出质量也不可控。把问题拆成“生成指令 + 指令解析执行”，等于把难点分成两块：语言理解交给语言模型（这是它的强项），几何计算交给成熟的 CAD 内核（这是它的强项），各干各擅长的。
2.2 数据从哪来：没有标注数据的瓶颈是怎么被突破的
想训练一个能听懂“圆盘法兰”这种描述并生成建模指令的模型，第一个绕不开的问题就是数据。CAD 模型库其实不少，但绝大多数是原始几何文件，没有对应的文字描述，语言模型没法直接学。给上万个三维模型手动写描述，成本大到不现实。
所以 2024 年那篇著名的 Text2CAD 论文，干了一件非常取巧的事情：用大模型给模型库“批量写说明”。他们从 ABC 数据集（一个大型 CAD 模型集合）里抽了几万个模型，然后用参数化的方式把每个模型的建模过程还原成命令序列。这些命令序列本身就是现成的“答案”。他们再把命令序列丢给 GPT-4 级别的模型，让它反过来生成对应的自然语言描述。这一步做完，就有了 18 万条“文本-CAD”配对数据。
听起来是不是有点像鸡生蛋的问题？模型还没有，怎么让模型造数据？其实这里有个非常关键的逻辑：造数据的模型和真正干活用的模型是两回事。GPT-4 这种通用大模型虽然不会直接生成 CAD 模型，但它读得懂 CAD 命令序列，也能把一条命令序列总结成一句人话。这种“伪标注”的质量足够用来训练一个更小的、专门干活的模型。他们用异常检测算法过滤掉一批质量差的数据，再用 CLIP 类似的双塔结构验证文本和模型是否匹配，最终数据质量是可以接受的。这也给后面的从业者一个启发：垂直领域缺数据，不一定非要从零标注，用强通用模型做数据生产，再做清洗和校验，是一条性价比非常高的路。
2.3 模型选型：通用大模型还是专用小模型
现在做 text-to-cad，模型选型基本有三条路线。
第一条，直接让 GPT-4、Claude 这类通用大模型输出 OpenSCAD 代码或者 Python 脚本，然后执行脚本生成模型。这条路最省事，不需要训练，开箱即用，适合做原型验证和临时任务。坏处也很明显：通用大模型对 CAD 工具的理解不深，经常生成语法正确但几何上完全不对的东西，而且输出不稳定，同一个描述每次可能给你差十万八千里的结果。
第二条，用开放的工具链加规则解析。比如你用现成的文本转代码模型，把输出限制在某个特定 CAD 库的 API 范围内，再用规则去校验和修正。这种方案对简单零件很有效，但遇到复杂特征就抓瞎，规则写不穷尽。
第三条，用前面说的配对数据去微调一个开源语言模型，比如 Code Llama、DeepSeek 系列，专门练出一个“能输出 CAD 参数化指令”的小模型。这也是 Text2CAD 论文采用的路线。走这条路效果上限高，训练出来的模型对建模格式的掌握更专精，输出也更稳定，但需要你有一定的动手能力去复现数据处理和训练流程。
我不建议一上来就追求第三条路。先拿通用大模型跑通一个最小闭环，搞清楚你的需求复杂度到底在哪个水平，然后再决定要不要上微调。很多做业务的人容易一步到位选最复杂的方案，结果数据准备阶段就卡住了。
3. 上手实操：从零跑通一个 text-to-cad 流程
3.1 环境准备与工具选择
如果你想最快速度体验 text-to-cad 的效果，不需要自己训模型，直接用现成的东西组装一条流水线就行。我推荐的方向是：语言模型负责生成 OpenSCAD 代码，OpenSCAD 负责渲染和导出 STL/STEP 文件。这套组合最大的优点是组件之间完全解耦，出了问题很容易定位。
OpenSCAD 本身是免费开源的，直接去官网下载安装就好。它做的事情非常简单：读入你写好的 .scad 代码，渲染出三维模型。这里务必注意：OpenSCAD 的代码是声明式的，不像普通编程语言按顺序执行那么容易调试，它描述的是“最终状态的约束”，但你不需要理解这个细节也能用起来。
语言模型这块，选 API 还是本地部署？我是建议一开始直接调 API，百来行的脚本就能跑通。模型对话接口返回一段代码，你把代码存成 .scad 文件，再用命令行方式调 OpenSCAD 渲染。这里有个统一入口很关键：OpenSCAD 支持 -o 参数指定输出文件，也支持 -p 和 -P 参数做参数化导入，所以完全可以做成批量的自动化处理管线。
3.2 提示词怎么写：这是我踩过最深的一个坑
要说 text-to-cad 实操里什么最重要，我的排序是提示词 > 模型 > 工具链。很多人以为 AI 建模就是输入一句话就完事，然后抱怨效果差。实际上你会发现，给大模型的描述和给人类设计师的描述，要求是完全两样的。
人类设计师你要说“做一个圆盘”，他能自己去想直径、厚度、是不是要中心孔；模型不会，它要所有信息都给到。我总结了一套相对靠谱的提示词模板，大概长这样：
请用OpenSCAD代码生成一个零件模型，要求： - 形状：圆形法兰盘，外径60mm，内径20mm，厚度5mm - 特征：在半径为45mm的圆周上均匀分布6个通孔，孔径5mm - 材料性能不重要，重点是几何形状准确 - 使用单位：毫米 - 代码中不要include任何外部库你看，我把单位、坐标系、特征的相对位置都说清楚了。真实建模的时候，有一个经常被忽略的细节就是定位基准。一个零件上的孔、槽、凸台，相对于谁定位？你说“右下角开一个槽”，模型就得猜“右下角”是哪个面、哪个方向。更靠谱的写法是“在主体顶面中心向右平移 20mm 处，开一个长 30mm 宽 10mm 的矩形槽”。把“基准-动作-尺寸”三要素写全，生成成功率会提升一个档次。
还要提醒一点：不要试图一次描述一个包含十几个特征的复杂零件。大模型生成的代码一旦超过几百行，几何错误率和语法错误率都会急剧上升。我的习惯是一个零件分几次生成，先做主体外轮廓，再一个一个往上加次特征。这跟人类建模里的思路完全一致：先加基础特征，再加细节特征。
3.3 从生成到可用：验证闭环怎么做
模型的输出永远可能是错的，所以一定要有一个“生成-验证-反馈”的闭环。最简单的验证方式就是让 OpenSCAD 把代码编译成渲染结果，程序报错或者生成的结果乱成一团，那就是失败的。
我在实测中摸索出来一套比较高效的人工验证流程：
代码语法能不能编译通过。这一步 OpenSCAD 会直接告诉你哪一行有问题，大部分问题出在多余的括号、漏掉分号、函数名拼错。
视觉检查渲染出来的模型轮廓。把模型旋转一圈，看有没有明显的破面、多余的悬空体、或者尺寸比例明显不对的地方。
导出 STEP 或者 STL 后，导入专业 CAD 软件里做量测。这一步最关键，因为 OpenSCAD 的渲染视图有时候有视觉欺骗性，你自己一比一的尺寸测量才是硬标准。
我自己用的检查流程是生成后导入 Fusion 360 或者直接用 Blender 的 MeasureIt 插件量关键尺寸，跟提示词里的主要数值对一遍。不要觉得这步麻烦，大模型对数字的把握能力远没有你想象中那么强，尤其是经过几轮叠加修改后，尺寸漂移是高频问题。你让模型创建“边长为 50mm 的立方体”，它给你写成 50.001mm，虽然视觉上看不出来，但导入装配体时就成了 0.001mm 的干涉量，强迫症也能让你疯掉。
另一个重要技巧是，把生成出来的模型“固化”成自己的零件库。比如我最开始让模型生成了一个带燕尾槽的滑块，做完验证没问题，我就把这段 .scad 代码和参数说明整理存下来。以后再有类似需求，直接把参数告诉我自己沉淀的提示词模板，一次成功的概率能到 80% 以上。这也是 text-to-cad 工作流里容易被忽略的长期价值：你一直在积累可复用的“语言-几何”映射资产。
4. 实际业务中的应用方法
4.1 能用在哪：从手板快速原型到参数化族库
text-to-cad 离业务到底有多远？我说几个我见过真实落地的场景。
第一个场景是 3D 打印快速验证。很多创客或者小工厂拿它生成样品的初始版本，建模可能只要几十秒，出来的模型虽然不是最终设计，但拿来做尺寸验证、装配验证足够参考了。我认识一个做机械零件外协的朋友，他把客户发的文字需求和手绘草图，直接粘进 text-to-cad 工具里先生成一个初始模型，跟客户确认概念之后再在 SolidWorks 里做精修。原本要来回两三个小时的沟通，现在十几分钟就能确认个大概方向。
第二个场景是参数化族库的批量生成。建筑和工程行业常有大量的标准件，比如不同规格的管道接头、支架、法兰。以往建族库是人工一个个对着参数表画，又累又无聊。用 text-to-cad 的方式，把模型逻辑写成一套带参数的脚本，然后让语言模型根据需求填参数值，批量跑出来再导入审查。这个流程一旦跑通，生成几百个变体就跟流水线一样。
第三个场景稍微慢热一点，就是跟已有的设计自动化流程做衔接。比如你把 text-to-cad 生成的结果作为下游仿真分析的前置输入，跑一轮快速结构验证，从一堆方案里挑出靠谱的再深入设计。这个用法其实很妙，因为设计初期的方案对比不需要高精度模型，能给出大概的几何和重量分布就够了。
4.2 别高估也别低估：text-to-cad 的能力边界
说完了优点，我得泼一下冷水。现在的 text-to-cad 在两类东西面前非常吃力：一类是钣金件，因为钣金有自己的加工约束，比如最小折弯半径、料厚、展开计算，这些依赖制造工艺知识而不是纯几何知识；另一类是复杂的装配体，比如一个包含几十个零件、有运动副、有配合关系的东西，现在的模型只能生成单个零件的几何外形，离生成整个装配结构还差得远。
还有一类问题是“功能语义”理解。你跟模型说“做一个能固定 42mm 宽 PCB 板的卡扣支架”，模型生成出来的几何外形可能合理，但强度和装配公差完全没谱。原因很简单，text-to-cad 模型是学几何翻译，不是学结构设计和公差分析。它可以又快又准地把你的语言翻译成形状，但它不懂力学，不懂材料属性，更不懂你后续工艺的加工限制。所以，把它定位成“加速从想法到初步几何”的工具是最合理的期待值。
5. 常见问题与排查技巧实录
5.1 高频问题速查表
我把实际操作中最容易遇到的几个问题整理了一下，方便你对照排查。
| 现象 | 最常见原因 | 解决方向 |
|---|---|---|
| 生成代码语法报错 | 模型对 OpenSCAD 语法掌握不牢，括号或分号缺失 | 修改提示词，让模型只输出纯代码块，不要解释；或者用代码格式化工具先过一遍 |
| 尺寸跟描述差很远 | 单位混淆（把 mm 写成 inch）；多个特征叠加时参数被覆盖 | 提示词里强制规定单位；模型输出后用脚本扫描关键数值做自动核对 |
| 模型形状对但位置偏移 | 定位基准描述不清 | 回到提示词，明确“相对于哪个面/哪条边/哪个轴”来定位 |
| 布尔运算失败或破面 | 两个体相交的数值刚好是临界值；精度设置太低 | 微调几何尺寸或把相交部分加大一点点；把 OpenSCAD 的精度参数$fn调高到 100 以上 |
| 同样的描述每次生成结果都不同 | 模型采样温度太高，或者 API 默认设置 | 把 temperature 参数调低到 0.1~0.3；使用固定 seed 参数 |
| 模型说自己生成了，但文件打不开 | 输出格式不匹配或编码问题 | 检查是不是存成了 .scad 但内容其实是 JSON 或 Markdown 包裹的代码 |
5.2 三个值得说的排查案例
第一个案例是精度问题。我让模型生成一个 M6 螺母外接圆直径 11.05mm 的六角形底座，结果渲染出来变成了一个带圆角的六边形。查下来发现模型的提示词里写了“rounded hexagon”，它就把六边形的角全部倒圆了。这提醒我：描述几何时尽量用模型能准确映射的术语，别用“圆润”“光滑”这种主观词，除非你真的要那些圆角特征。
第二个案例是特征丢失。有一次我让模型生成一个带 4 个加强筋的底座，结果 OpenSCAD 渲染出来底座有了，加强筋一个都没有。排查后发现原因在布尔运算：加强筋和主体求并集时，因为加强筋尺寸太小，在系统默认精度下运算被自动忽略了。把加强筋尺寸放大零点几毫米后问题就解决了，这也算是一个比较典型的“几何容差”问题。
第三个案例是“幻觉尺寸”。我给了一张 50mm 宽的参考描述，模型生成的板子宽度变成了 50cm，直接大了十倍。这种错误在纯文本生成里看不出来，导出 STL 才发现。后来我在提示词里明确加上一句“所有未注明单位的数据默认视为毫米”，并在生成后用一个小脚本扫描数字跟描述里的关键词比对，基本能把这类低级错误过滤掉。
5.3 通用排查思路：先拆解再归因
这里分享一个通用的排查思路，遇到任何 text-to-cad 问题都可以按这个顺序过一遍。
第一层，看模型反应。把同样的描述发给另一个模型，比如把 ChatGPT 换成 Claude 开源版，如果结果同样离谱，大概率是描述本身有问题，而不是模型理解能力的问题。第二层，看代码执行。把模型生成的代码单独保存下来，直接人工阅读，看看是逻辑错误还是执行错误，这能帮你区分是生成阶段的问题还是引擎阶段的问题。第三层，看几何输出。把渲染结果导出成 STEP，在专门的查看器里做截面检查，确认是不是有内部空洞、反法向面这类视觉上看不出的问题。
这套分层的思路，本质上是把“语言问题”跟“几何问题”剥离开。很多人遇到生成结果不对就急着换模型、调参数，往往浪费了大量时间。先定位问题出在哪一层，才能对症下药。
6. 一些个人体会
做到现在，我的整体感觉是 text-to-cad 正在经历一个从“技术 demo”到“实用工具”的临界点，但离真正的“设计助手”还有一段路。它最让我惊喜的地方不是一次生成多完美，而是在我积累了一批“语言到模型的映射模板”之后，它的可复用性非常好。我给它描述同样的需求，基本能稳定输出合格的结果，这在很大程度上解放了我做重复建模的时间。
我个人在实际操作中最受益的习惯是：永远保留一份“描述-代码-验证”的记录文档。每一段成功的描述，配上生成的代码和最终模型截图，就是一个你自己的 mini 训练集。后续无论是调试提示词，还是训练更个性化的模型，这些记录都是最有价值的资产。
如果你打算入坑，我的建议是先别纠结大而全的方案，用一条最简单的流水线跑起来，收集几个真实需求，看它能在多大程度上帮到你。等确认了需求频率和复杂度，再评估要不要上微调模型。这条路走通之后，你会发现“从语言到模型”的距离，确实比想象中短得多。
