做机械设计的朋友应该都有过这种经历：半夜改图改到怀疑人生，一个支架、一个法兰、一个标准的齿轮轴承，明明是成熟的标准件，却还得在CAD里一步步拉伸、旋转、倒角。更别提刚入行的新人，光是把CAD装明白、把工具栏摸熟，就劝退了一半人。所以text-to-cad这种“你说一句话，模型自动出图”的思路，最近能在圈里炸开锅，一点都不奇怪。简单讲，text-to-cad就是把自然语言描述直接翻译成可编辑的CAD三维模型——你输入“帮我设计一个支架底座，底板长80宽60高8，竖板高40厚5，底板两端各一个直径8的安装孔”，它真的能在几十秒内给你一个可以打开、可以测量、可以继续编辑的实体。这篇东西我不打算写PR稿式空话，而是把这门技术从模型原理到实操完整拆一遍：它到底在做什么、需要什么环境、怎么写描述AI才听得懂，以及我在真实使用里踩过的坑。适合做机械设计、工业设计、智能制造的朋友，哪怕你刚摸CAD两天，也能看懂。
1. 先说清楚：text-to-cad 到底是个什么东西
1.1 传统 CAD 建模的三个老问题
传统CAD建模，说白了就是“人围着机器转”。你画一个零件，核心动作无非三件：画草图、定约束、做特征。拉伸、旋转、扫描、放样，翻来覆去就这些操作，但每个操作都要你亲手去点、去拖、去输参数。这是一个典型的“低创意消耗、高重复劳动”过程。
把这个过程拆开看，有三个老问题绕不开。第一个是学习门槛，CAD软件功能多到菜单层层叠叠，新手光是要搞清楚“基体法兰”和“钣金法兰”的区别，就得翻半天帮助文档。第二个是标准化件重复劳动，法兰盘、轴承座、腰形孔、通风口，这些标准的不能再标准的东西，每次都要人一步步建模。第三个是改图成本，甲方轻飘飘一句“厚度加3毫米”，你可能就要把整个装配重新过一遍约束检查，改一个尺寸牵一发动全身。
text-to-cad瞄准的恰恰是这三个问题。它不替你思考设计创意，但能替你把“从意图到实体”这条路上最枯燥的部分走掉。说白了，它更像一个“会干活的实习生”：你告诉它要什么规矩、什么尺寸，它帮你先把粗坯做出来，你再做精修。这个定位决定了它的价值不在于取代设计师的创造力，而在于把那些消耗时间的执行步骤压缩到分钟级。
1.2 text-to-cad的技术路线：不是“识图出模型”，而是“语义驱动参数化建模”
很多人第一次听到text-to-cad，以为是拿一张图片让AI生成3D模型，其实不是。严格说，text-to-cad是“文本生成程序化建模脚本，再由脚本驱动三维引擎构形”。这个区别很关键。
我见过不少人混淆这两件事，以为它是图像生成模型的CAD版。但图像生成模型做的是“像素级生成”，它生成的是网格或者隐式场，本质上是一个“看起来像”的三维形状，精度和可编辑性都很不靠谱。而text-to-cad走的是“程序化建模”路线：语言模型把自然语言翻译成一段参数化脚本，比如OpenSCAD脚本或者CadQuery代码，脚本执行后生成真正的BREP实体模型。BREP这种数据结构意味着它有精确的数学曲面边界，可以支持工程上需要的测量、布尔运算、圆角倒角、参数修改。
这么说吧，图像生成模型给你的是一个“雕塑”，只能看不能改；text-to-cad给你的是一个“毛坯件”，能上车床继续加工。这两者的工程价值完全不在一个量级。理解了这一点，你就能明白为什么text-to-cad背后的工程界会对这条路投入那么大热情——它不是在做一个玩具，而是在重构CAD建模的输入方式。
2. 核心原理拆解：一句人话是怎么变成三维模型的
2.1 第一层：自然语言解析与参数抽取
当你输入“做一个六角法兰螺栓，螺纹段长20mm，头部对边13mm”这句话，语言模型要做的第一件事，就是从这句话里抽取出“实体类型（六角法兰螺栓）、关键尺寸（螺纹段20、对边13）、隐含特征（六角、法兰、螺纹）”这些结构化信息。
这一步看似简单，实际最容易出错。自然语言是模糊的，比如“头部对边13mm”是代表六角头的对边距，还是法兰外径？“螺纹段长20mm”是总长度还是露出部分？模型需要结合上下文做出推理。实操上，描述越接近“设计意图+关键参数”的格式，模型抽取得越准。
我在测试中发现一个规律：给它“我要造一个螺栓”这种太口语化的描述，它经常生成一个看起来像螺栓但比例失真的东西；而给它“六角头螺栓，M8，公称直径8，螺距1.25，头部厚度6，螺杆长度40”这种结构化描述，出来的模型基本一次到位。这不是模型笨，而是自然语言本身承载的信息密度不够，AI没有义务替你脑补缺失的参数。
2.2 第二层：程序化建模代码生成
参数抽取完成之后，语言模型会把这些结构化信息映射到一段程序化建模代码上。这一步是text-to-cad的核心技术跃迁。
它相当于在回答一个问题：“如果你是一个熟练的OpenSCAD用户，你会怎么写这个零件？”大模型在训练阶段看过海量代码仓库和CAD脚本，它学会了“圆角怎么加、阵列怎么铺、布尔运算怎么写”这些程序化建模技巧。你给它一个设计要求，它就把它脑内那个“模型用户”会写的代码给吐出来。
这里有个非常重要的点：模型生成的代码不一定是“最优实现”，但一定是“可执行实现”。它经常用最稳妥的写法——先画一个圆柱，再画一个六角棱柱，然后并集或者差集——这种写法不是最高效的，但一定不会出语法错误。我在OpenSCAD里检查过它生成的代码，很多地方都有冗余的union()和translate()嵌套，但胜在结构清晰、容易改。对于不熟悉代码的用户，这反而是一种友好：每一行都在做一件独立的事，删掉哪行，对应的特征就消失，特别好排查。
2.3 第三层：渲染、校验与输出格式转换
代码生成之后，工具链会在本地或云端执行这段脚本，通过三维内核构形出实体模型，然后实时渲染给你看。
这一层还有一个容易被忽略的模块：校验。模型不是生成代码就完事，它会用一系列规则检查“代码能不能跑”“生成的实体是不是封闭实体”“有没有自相交面”。比如生成一个法兰盘，如果布尔运算后的实体不是一个watertight（水密）实体，它就会触发重新生成。这一点对下游制造非常重要——一个watertight的模型才能被切片、被CAM、被3D打印，否则就是一堆破烂三角面。
输出格式也在这层完成。工具通常会让你下载STEP、IGES、STL或者直接导出OpenSCAD源码。作为工程用途，我建议优先选STEP格式，它能保留精确曲面和装配信息，几乎所有主流CAD软件都能无损导入。如果你只是做3D打印验证，STL就够用，文件还小得多。
2.4 为什么选OpenSCAD/CadQuery，而不是直接建模
如果读者接触过CAD二次开发，可能知道市面上能“写代码建模”的方案不少，除了OpenSCAD和CadQuery，还有FreeCAD的Python API、SolidWorks的API、Fusion 360的API，甚至是Rhino的Grasshopper。
text-to-cad的主流落地工具偏偏选了OpenSCAD这类“脚本即模型”的方案，原因不复杂。其一，可解释性：模型生成的是纯文本脚本，用户可以逐行检查、手动修改，不需要打开一个重型CAD程序。其二，可移植性：OpenSCAD脚本是普通文本文件，Git可以管理，markdown可以展示，网页可以渲染。其三，零重型依赖：跑一个OpenSCAD脚本只需要一个轻量引擎，不像SolidWorks API那样要在Windows下安装几十G的商业软件。
这和我前面说的“不用装几十G套件”是一致的。程序化建模是text-to-cad的天然土壤，因为它把“描述、代码、映射关系”这三者的边界拆得非常干净，每一步都可以单独调试。出了问题，你既能改描述，也能改代码，还能跳过AI直接手写。这种透明的链式结构，是黑箱式的网格生成模型给不了的。
3. 实操过程：从一句话到可修改的 CAD 模型
3.1 环境准备：轻量到感人
text-to-cad实操的门槛，比大多数人想象的低得多。
如果你只是想体验一下，进网页端就能用，连安装都不用。如果你希望把text-to-cad集成到自己工作流里，大概需要这几样：一个OpenAI或同类模型的API key，用于自然语言到代码的转换；一个本地的OpenSCAD执行环境，或者直接用集成了内核的云服务；一个能打开STEP/STL文件的CAD查看器，连浏览器里的轻量查看器都行。
我的主力环境是：Python 3.10，装了一个OpenAI的SDK，本地装了OpenSCAD命令行版，外加一个FreeCAD用来做最终检查和转格式。整套配下来，占用磁盘不到2G，比传统CAD动辄20G的安装包轻一个量级。很多朋友最初是在搜“cad下载”“cad安装”的时候误入这个领域的，体验过这种轻量方案之后，基本就不愿再回头去折腾巨型安装包了。说白了，一台普通的办公笔记本，跑一套text-to-cad工作流绰绰有余。
3.2 描述词是门手艺：三段式描述法
这是整篇里最值得抄作业的部分。我用了很多次之后总结出一套“三段式描述法”，实测能显著提高text-to-cad的一次生成成功率。
三段式就是：主体形状 + 关键尺寸 + 附加工艺特征。
- 主体形状：这个零件是什么、主要构成是哪几个几何体？比如“一个圆柱体底盘，顶部有一个立方体凸台”。
- 关键尺寸：每个主要形体的尺寸必须用数字明确。比如“底盘直径60mm，高10mm；凸台长40mm，宽30mm，高15mm”。
- 附加工艺特征：把圆角、倒角、孔、螺纹、阵列这些“加工特征”单独列出来。比如“底盘边缘做R5圆角，凸台上表面中心开一个直径8mm的沉头孔，底部阵列6个直径5mm的定位孔，均匀分布在半径25mm的圆上”。
记住，不要写“一个大圆盘上面有个小方块”这种口语化描述，模型不是人，它理解不了“大”“小”的相对关系。把尺寸全部数字化，哪怕你不确定尺寸，先给定一个合理值，也比模糊描述强。误差可以后续调整，歧义就真的没法收拾。
3.3 一次完整的生成示例：法兰盘的诞生
我拿一个最常见的法兰盘来当例子，走一遍完整流程。我输入的是这样一段文字：“设计一个圆形法兰盘零件。底盘为圆柱体，外径80mm，厚度12mm，中心有一个通孔直径32mm。底盘上围绕中心均匀分布6个安装孔，孔径10mm，安装孔中心所在圆的直径为60mm。底盘外缘做C1倒角，通孔两端做1x45度倒角。材质按普通Q235钢即可。”
这段描述包含：主体形状（底盘圆柱+中心通孔）、关键尺寸（外径80/厚12/内径32/安装孔径10/分布圆直径60）、附加工艺特征（外缘C1倒角、通孔两端1x45度倒角）。
生成过程大约35秒。第一步输出OpenSCAD代码，第二步本地执行渲染，第三步给出一个可旋转的3D预览。我看到的模型和设计意图基本吻合，安装孔均匀分布、倒角都加上了。唯一需要手动调整的是，它默认生成的圆角过渡方式在孔口处略显“生硬”，我直接在OpenSCAD脚本里改了倒角参数重跑一次，总共不到两分钟，模型达到我预期。
这个例子的意义在于：text-to-cad不是“一次出成品”，而是一套“描述→生成→局部修改→重新生成”的循环。你要把它当成人来协作，而不是当做一个自动售货机。把“修改反馈”也纳入你的工作流，效率才会真正上去。
3.4 拿到模型之后：导出、检查、修改
生成模型并不意味着工作结束，反而真正的工程工作才刚刚开始。text-to-cad的输出通常可以导出为STEP、STL、SCAD等格式。
我的建议是，导出STEP之后，用正规CAD软件做一次“体检”：检查实体是否封闭、尺寸链是否自洽、面与面之间有没有微小缝隙，必要时再做一次布尔修复。这一步并不是对text-to-cad不信任，而是任何自动化生成工具都有自己的盲区——语言模型写代码时，偶尔会在“相邻特征干涉”这类问题上犯低级错误，比如把螺孔和通孔重叠了却没告诉你有干涉。
如果你是要3D打印，我建议直接把它生成的模型导入切片软件前，先用一个mesh修复工具跑一遍watertight检查。我在使用中遇到过两三次这种坑：模型看起来完美，一切片就报错，检查后发现是内部有悬空面。花两分钟跑一次修复，能省下半小时的返工。
4. 常见问题与排查技巧实录
4.1 描述太“像人话”反而容易翻车
第一个坑是过度口语化。我试过输入“给我做一个零件，装在水管上的那种，一边大一边小”，结果text-to-cad给我生成了一根莫名其妙的锥形管，一头42另一头30，中间还有一段扭曲的过渡，跟水管接头完全不是一回事。后来我才意识到，问题不在AI，而在我给的信息就没法“几何化”。
我复盘了一下，问题出在“装在水管上”“一边大一边小”这些描述缺少精确参数。对语言模型来说，“水管接头”这个实体概念它能理解，但“大”“小”的具体程度它只能瞎猜。正确的做法是把“一边大一边小”改成“一端外径42mm，另一端外径30mm，总长50mm，内径25mm”。同样的语义，信息密度完全不同。
教训就是：和text-to-cad对话，要像和一个聪明的、但没有视觉经验的实习生对话，你要把“看到的想象”翻译成“可测量的数据”，而不是指望它通过想象补充所有未知信息。它在文本理解上很强，但在“看图脑补”这件事上跟新手一样。
4.2 尺寸和公差：AI 对精度是“不敏感”的
第二个高频问题：模型对公差的处理非常随意。你以为写上“螺栓孔直径8mm”就完事了，结果text-to-cad会在模型上生成一个精确的8.000mm的孔——图纸上标注8mm通孔的时候，工程师心里默认的其实是8.5mm的间隙孔，这个潜规则AI完全不知道。
工程上这里的逻辑是：螺栓通孔和螺栓之间通常要有0.3到1mm的间隙，具体取决于配合等级。但语言模型没有“装配意图”概念，它只会忠实执行你给的数字。解决办法也很简单：你在描述里就要把配合关系写明白，比如“孔直径8.5mm，与M8螺栓间隙配合”。你要当公差设计者，不能把公差交给AI决定。
这是text-to-cad目前最大的工程短板，也是实际使用中最容易出问题的一环。我在批量化测试时碰到过“产品设计图上标着10mm孔，实际批量生成之后装配检查不过”的情况，原因就是没在prompt层面预留公差。如果你要做装配体，尤其要留意这一点。
4.3 复杂装配体经常爆内存或超时
第三个坑：text-to-cad处理简单单件很利索，我拿法兰盘、支架、端盖这类零件测试，基本都能在几十秒内给出结果。但你不能一口气让它生成“包含20个零件的齿轮箱装配体”，我试过一次，模型整整跑了十分钟，最后GPU资源耗尽也没出来，还差点把浏览器给卡死。
因为程序化建模的每一段脚本都要经过完整内核计算，大量实体的布尔运算非常吃资源。我尝试过一次让text-to-cad生成一个带4个齿轮的行星减速机构，等了十分钟，最后资源耗尽也没出来。
我的策略是“单件生成，装配体拼接”：分别生成每个零件模型，然后在CAD软件里做装配约束。这样既绕开了性能瓶颈，又让每个零件保持独立编辑性，比一次性生成一个整体的“铁坨”更好用。零件之间的配合尺寸，你在描述里预留好就行，装配体阶段再微调。
4.4 输出质量与可制造性的差距
还有一个不能忽视的现实问题：AI生成的模型，从“几何正确”到“可制造”之间还有很长的路。这个距离不是靠优化prompt就能抹平的，它涉及整个工程表达体系的差距。
举个具体的例子：text-to-cad可以轻松生成一个虎钳的整体模型，但如果你要按照它去实际加工，会面临两个致命问题：第一，没有标注粗糙度、形位公差、热处理工艺等制造信息；第二，模型里的很多特征，比如深孔、薄壁、倒扣结构，在真实工艺下可能根本没法加工，或者会干涉刀具路径。
这是我在实际工程中要不断提醒自己的：text-to-cad是概念设计和前期验证阶段的利器，目前它还替代不了专业的详细工程设计。你拿它做方案演示、做设计沟通、做结构轮廓，非常好用；拿它直接给车间下料，还不行。我见过有人拿它生成的模型直接去线切割，结果薄壁特征完全变形，浪费了一批料。
4.5 排查速查表
| 问题表现 | 可能原因 | 解决思路 |
|---|---|---|
| 生成结果跟描述完全不相干 | 描述太口语化、缺少关键尺寸 | 使用“主体形状+尺寸+工艺特征”三段式 |
| 尺寸不对，与输入不符 | 自然语言中单位或数字冲突 | 统一用毫米，避免“约、大概、左右” |
| 零件是一个不封闭的实体 | 布尔运算生成自相交 | 手动在脚本里添加union/intersection指令，或重新生成 |
| 生成过程超时 | 单个任务实体数太多 | 单件生成，后期做装配 |
| 模型看起来对但切片报错 | 内部有悬空面 | 切片前用工具做watertight修复 |
| 装配体无法导出STEP | 缺少装配树和约束信息 | 分别导出单件，在CAD里组装 |
5. 应用场景与影响范围：谁在用它、它改变什么
5.1 最受益的三类人群
text-to-cad目前受益最大的，我观察下来主要是这三类人：非专业设计人员、初期方案设计师、自动化流水线上的重复出图人员。
非专业设计人员指的是那些有想法、有原型，但没有受过系统CAD训练的人。比如产品经理、硬件创业者、机械爱好者，他们脑子里的想法一直卡在三维表达这一关。text-to-cad给了他们一个可以直接把想法变成“可编辑工程模型”的入口，不用先花三个月学软件。
初期方案设计师也很受益。概念设计阶段需要大量尝试不同结构形态，如果一个方案可以让AI快速生成十几个候选结构，设计师只需要从中筛选、优化，效率提升非常明显。我见过有设计师让text-to-cad一口气生成三种不同加强筋布局的支架方案，然后挨个导入仿真软件对比刚度，这是以前不敢想象的效率。
还有一类是重复出图人员——很多企业有成套的标准化零件库，虽然库里有模型，但每次项目微调尺寸还是要重新出图。text-to-cad搭配参数化生成脚本，可以做到“改一行文字就重新出图”。这类工具对他们来说，不是“锦上添花”，是实打实地把一周的活变成一天。
5.2 对行业工作流的影响：从“画图”到“审图”
更深远的影响在于，text-to-cad在悄悄改变设计师的角色定义。
过去，CAD建模是完全的“手艺人”工作，设计师花大量时间在“如何把几何特征搭建出来”上。当text-to-cad这类工具成熟后，这种“执行型建模”工作正在被越来越多地自动化掉。设计师的核心竞争力，正在从“熟练操作CAD软件”向“精确描述设计意图、校验AI生成结果、做出工程决策”迁移。
说白了，未来很多CAD岗位的工作流可能会变成：设计师在对话框里输入设计意图和约束，AI生成初步模型，设计师检查、修改、确认，最终出图。这个流转了很多传统“画图员”的岗，但同时也把设计师从重复劳动里解放出来，去做更有创造性的工作。真正的价值所在，是判断“这个设计合不合理”的能力，而不是“能不能画出来”的熟练度。
当然，这件事不会一蹴而就。当前text-to-cad还做不到复杂的装配级智能设计，它的成熟度大约处于“高级辅助工具”的层面。但这个方向已经明确，技术迭代也很快，值得每个CAD从业者留意。你不需要现在就转型，但至少要理解这条线在往哪里走。
5.3 局限性依然是硬约束
写到这里，我必须诚实地强调它的边界。现有的text-to-cad工具，距离“万能造物”还非常遥远。它适合轴套类、板类、箱体类等规则几何体；对复杂曲面（比如汽车A柱、异形手柄、自由曲面外壳），它生成的精度远远不够。
另外，它对“非几何属性”是无感的。材料、热处理、表面处理、制造工艺、成本，这些工程上至关重要的信息，它一概不会去思考。这也是为什么我一直强调，text-to-cad在“概念模型”阶段可以大展拳脚，在“制造release”阶段必须由人来收口。把它当成一个强大的起点，而不是终点，才是正确的心态。
最后分享一点我的真实体会。自从开始用text-to-cad，我最明显的变化不是出图速度，而是思考方式。以前画图的时候，精力都花在“这步该用什么命令”上；现在写描述的时候，反而逼着我把“我要的到底是什么”想得更清楚——形状、尺寸、加工特征，全都必须先用自然语言表达到位。这个过程反过来让我对零件结构设计更敏感。
如果你也想试试，我的建议很简单：不要指望它一次生成完美模型，把它当做一个可以无限重来的“快速草稿员”。先拿一个最简单的法兰盘试一试，把描述写细，把验收流程跑通，再逐步尝试更复杂的零件。等你用顺了，你会明显感觉到原来的建模流程慢得不像这个时代的工具。
另外多说一句，不管你是老CAD用户还是新人，现在都是入场text-to-cad的好时机。这门技术距离“人人都能描述CAD”的目标还有距离，但已经足够真实地改变一部分工作流了。早点上手，你就能在别人还在纠结CAD安装包要不要卸载重装的时候，先一步用另一种方式把模型做出来。
