打开文本编辑器写提示词的那天晚上我其实没抱太大希望。结果十几秒后一个带安装孔和加强筋的底座模型就出现在渲染窗口里轮廓比例合理倒角也对了。那一刻我意识到text-to-cad 已经不再是论文里的概念演示而是实实在在能进到工作流里的效率工具。这篇内容我打算从技术链路、工具选型、实操过程和踩坑实录四个角度展开把我最近实际用下来的经验一次性讲透。如果你是做结构设计、机械零件、创客 DIY或者单纯想用自然语言把脑子里那个“大概长这样的东西”变成可编辑的三维模型这篇文章应该能帮你少走一个月的弯路。1. 文本到CAD到底在解决什么问题——先理清技术链路1.1 从自然语言到三维模型的完整链路很多人第一次听到 text-to-cad第一反应是“这不就是 AI 生成三维模型吗”。我在接触之前也是这么想的但真正上手之后才发现它和那些直接生成网格模型的 AI 工具走的路线完全不是一个路子。一条完整的文本到CAD流程实际上是四个环节的串联文本理解、工程意图解析、几何推理、程序合成。文本理解这部分跟普通的对话式 AI 没什么区别核心就是把你的话拆成一个个设计要素。难点在于工程意图解析。举个例子“给我一个 M8 螺栓能穿过去的通孔”这句话看着简单但 AI 需要知道 M8 螺栓的头部直径是 13 毫米、通孔直径通常是 8.4 毫米或者 9 毫米取决于配合等级还需要知道孔的位置、方向、是否沉头。这里面既有机械常识又有经验值纯靠语言模型硬猜是猜不出来的。等到几何推理环节系统会把语言描述转换成几何约束和实体操作序列拉伸、旋转、布尔运算、倒角、阵列。最后通过程序合成生成一段可执行的建模脚本这段脚本会被 CAD 内核执行才得到最终的三维实体模型。这也解释了一个关键问题为什么 text-to-cad 生成的一定是带参数的可编辑模型而不是一堆三角形面片构成的网格模型。因为整条链路走的是“程序化建模”路线语言模型负责写代码真正的几何运算交给 CAD 内核。这也是它跟那些文生图、文生网格工具最本质的区别。1.2 为什么“程序合成”是关键而不是直接生成网格实体我看过一些基于扩散模型直接生成三维网格的方案坦白说作为灵感参考是有价值的但距离真正可用还有不小距离。主要原因有三个。第一网格模型不可编辑。你拿到一个 .obj 或者 .stl 文件想改一个孔的直径对不起做不到只能回炉重造。而 CAD 建模的核心诉求恰恰是修改和迭代零件不是一次性艺术品是要反复调整的。第二网格模型没有工程语义。实体模型里有孔、有面、有倒角有尺寸约束和配合关系。网格模型只有三角形面片没有哪一层是“面”、哪一坨是“孔”的概念。你没法在网格模型的拓扑结构上做布尔运算也没法直接导出用于加工的刀具路径。第三网格模型经常是非流形或者破损的。做过 3D 打印的朋友肯定有经验一个破损的网格模型导入切片软件要么切片预览有明显破洞要么打印到一半悬空结构全部塌掉。程序化生成的实体模型天然是封闭的、流形的因为每一步都是基于准确几何内核的布尔运算不存在封闭性问题和面片翻转问题。所以我在实际使用中的结论非常明确text-to-cad 这类工具能进入生产流程靠的就是“程序合成”这四个字。它的本质不是让 AI 直接“画”模型而是让 AI 去写构建模型的“施工图纸”然后交给人去执行和修改。2. 工具选型解析不同技术路线的取舍2.1 OpenSCAD、CadQuery 还是自由建模——建模语言决定成败既然核心是程序合成那么底层用什么建模语言就决定了生成结果的可控性和可编辑性。目前市面上主流的文本到CAD工具底层基本都是这两条路线OpenSCAD 和 CadQuery或者 FreeCAD 的 Python 接口。OpenSCAD 走的是 CSG 构造实体几何路线代码风格偏函数式你用 cube、cylinder、difference、union 这些基础体素去拼出复杂模型。它的优势是语言简洁规则清晰AI 非常容易生成正确的代码。因为整套语法就那几个核心操作模型复杂一点也无非是嵌套多几层。我在实际体验中OpenSCAD 路线的生成成功率确实更高出错的概率明显低。CadQuery 则是完全面向对象和参数化的 Python 库它模拟的是你在真实 CAD 软件里的建模思路先画草图、再拉伸、再打孔、再阵列。CadQuery 生成的代码可读性很强一个特征对应一段代码修改起来思路非常清晰。但它的 API 层级更深语言模型偶尔会生成不存在的函数名或者参数组合如果项目自身没有做好 API 文档的约束生成结果的稳定性会差一些。自由建模路线比如让 AI 输出 STEP 或 BREP 数据目前还不太成熟理论上是未来的终极形态但现阶段工程化落地还不够我就不多推荐了。2.2 主流文本到CAD方案横向对比我实际用过几个方案给它们做了个简单的对比方便大家快速选型。方案底层建模语言生成稳定性可编辑性适合场景基于OpenSCAD的路线OpenSCAD高中等参数少修改靠改代码快速原型、参数化零件、创客DIY基于CadQuery的路线Python中高高特征树清晰可读性好结构件、装配体、复杂特征基于自由建模的路线STEP/BREP低高研究阶段暂不推荐生产使用文生网格扩散模型无/网格高但不可用不可编辑灵感探索、概念展示说实话现阶段我没有只押一个方案。日常做快速验证的时候我会用 OpenSCAD 路线生成速度快、成功率高几秒钟就能看到形态方向对不对。等到要进入细化设计、给零件加工程语义、做装配验证的时候就切换到 CadQuery 路线优点是可读性和结构化程度更好。2.3 我自己的工具组合建议如果你现在想开始用 text-to-cad我建议先别急于选型从最容易上手的 OpenSCAD 路线开始。理由很简单语言足够简单AI 不容易写错你能快速建立起“文本到模型”的完整心智模型。跑通一条链路之后再尝试 CadQuery 路线去生成那种带装配约束或者复杂孔位分布的零件。这个时候你已经有基础认知了就能更清楚地感受到两种路线的差异也更容易判断自己实际项目里更适合哪一种。另外强烈建议给建模语言配一份精简版的“API 速查表”放在提示词上下文里。很多工具支持系统级提示词注入你可以直接把 OpenSCAD 的常用函数清单、CadQuery 的常用方法签名丢给 AI生成准确率会明显上一个大台阶。后面我在实操部分会给出具体示例。3. 实操过程与核心环节实现3.1 写提示词的技巧把“人话”翻译成“建模语言”的能力text-to-cad 能不能出好活一半看模型能力一半看你的提示词功底。我试过大量不同风格的说法最后总结出一个核心原则你的提示词越像一份设计需求文档生成结果就越贴近预期。先看一个反面典型“做一个法兰盘”。这种说法信息量太低了AI 不知道法兰盘外径多少、厚度多少、孔数几个、孔径多大、中心孔要不要凸台。结果就是它根据自己的“平均印象”给你生成一个通用法兰大概率和你想要的对不上。再看我一般怎么写的生成一个圆形法兰盘外径 80mm总厚度 12mm。中心有一个直径 20mm 的贯穿孔中心孔周围均匀分布 6 个直径为 6.5mm 的螺栓安装孔螺栓孔中心圆直径 60mm。法兰盘外圈倒角 1mm所有边缘需要光滑过渡。材质按铝合金处理只输出三维模型。这种描述方式有三个好处尺寸信息明确、位置关系清楚、加工语义附加在上面。AI 在解析时能顺畅地完成“文本要素 → 几何约束 → 建模操作”的映射生成出来的代码质量自然高。还有一个进阶技巧把设计意图讲清楚而不是只报参数。比如你写“这个支架底部要加一条加强筋因为受力方向垂直于底面”AI 就能推理出筋应该沿受力方向布置、厚度和高度要有一定的尺寸比例。这一段“意图描述”往往比单纯加参数更有价值。3.2 从模型文案生成可编辑的CAD脚本我拿 OpenSCAD 路线举个例子展示一下从提示词到最终代码的全过程。假设需求是做一个带提手的圆形盖子盖体直径 100mm厚度 5mm中心有一个拱形提手。我先写提示词用 OpenSCAD 生成一个大直径 100mm 的圆形盖子盖体厚度 5mm。盖体中心上方有一个半圆拱形提手拱形内径 40mm提手截面为矩形宽 15mm、高 10mm。提手两端自然融入盖体表面连接处做圆角过渡。整体对称输出结构化清晰的 OpenSCAD 代码。实际生成出来的核心代码大致长这样// 盖体 module cover_body() { cylinder(h 5, d 100, $fn 120); } // 提手横向梁 module handle_bar() { translate([0, -7.5, 5]) cube([40, 15, 10]); } // 提手拱形部分 module handle_arch() { difference() { cylinder(h 10, d 50, $fn 120); translate([0, 0, -1]) cylinder(h 12, d 40, $fn 120); } } // 整体组合 module lid_cover() { union() { cover_body(); translate([-20, 0, 0]) handle_arch(); translate([20, 0, 0]) handle_arch(); handle_bar(); } } lid_cover();生成结果不是一次到位的。实际跑第一版的时候提手两端和盖体的连接处是直角过渡视觉上比较生硬。我把反馈丢回去“提手与盖体连接处增加 5mm 圆角过渡确保连接自然平滑”AI 重新生成了带圆角过渡的版本通过引入 hull 操作把两个圆柱体做了外轮廓融合最终效果就顺眼多了。这类基于反馈的迭代过程正是 text-to-cad 相比传统 CAD 建模最有趣的地方。传统建模里你每改一处都是手动操作而这里你只需要描述问题代码层面的修改由 AI 完成。3.3 后处理与参数化调整的实操记录拿到生成代码之后我一般不会直接用。先检查几个关键点尺寸数值是否符合预期、布尔运算是否产生多余的内部面、倒角和圆角是否应用在正确的位置。检查通过之后我会把关键尺寸提取成变量做成参数化模型。还是以法兰盘为例我会把外径、厚度、孔数、孔径都定义成顶部变量outer_diameter 80; plate_thickness 12; center_hole_diameter 20; bolt_hole_diameter 6.5; bolt_circle_diameter 60; bolt_hole_count 6;这样后面改一个参数整个模型自动更新。在批量生成系列化零件比如不同规格的法兰、支架、盖板时这个参数化能力价值极大。AI 帮你生成一次逻辑你就能用一个参数控制一个系列。还有一个实操细节筛选器设置。OpenSCAD 里我习惯把 $fn 设置为 120 以上保证圆柱面和圆弧足够光滑但要提醒的是这种高精度扫描显示会增加预览计算量。我的做法是预览时用 $fn60导出 STL 时再切换到 $fn200兼顾流畅度和精度。4. 常见问题与排查技巧实录4.1 尺寸瞎编怎么办——几何约束的闭环text-to-cad 最常见的翻车事故就是尺寸问题。AI 有概率把两个互相矛盾的尺寸一起写进代码比如法兰外径 80mm、螺栓孔中心圆直径却写了 90mm结果螺栓孔直接跑到法兰外面去了。这类问题的本质是语言模型缺少“无效结果验证”能力。它写代码的时候并没有把几何约束关系实时校验一遍。我在实践中用了一个比较可靠的兜底方案要求生成代码里必须包含 assert 检查或者要求关键尺寸之间的关系以等式形式体现。示例提示词可以这样加一句“如果螺栓孔中心圆直径大于外径减去 2 倍边距请给出警告并自动调整。”这样即使 AI 一开始写错了它也会在生成逻辑里加入约束检查后续修正就只是参数跳动的问题。另一个笨办法但很有效生成之后用测量工具快速核对几个关键尺寸。我一般在 FreeCAD 里加载 STEP 文件直接量一遍20 秒就能排查掉大半问题。尺寸可信度在 text-to-cad 里永远不会是 100%人工抽查是必要的质控环节。4.2 生成结果无法编辑怎么处理还有一种高频问题AI 给出了一个很唬人的模型图片但你发现代码里所有操作都是硬编码的改一个尺寸等于重写整个文件。这种模型“能看不能用”比生成失败更让人头痛。我的应对思路是在提示词里强制要求“模块化拆分”。把每个特征独立成模块模块内部用参数、模块之间通过坐标变换组合。module base_plate(w, h, t) { translate([0, 0, 0]) cube([w, h, t]); } module mounting_holes(x, y, dia) { translate([x, y, -1]) cylinder(h 4, d dia, $fn 32); }如果你拿到的代码已经是硬编码的也有补救办法。先把代码丢给 AI附加指令“识别这段代码里所有硬编码尺寸提取为顶部参数变量并保持模型形状不变”连改造带回归测试一次完成。我试过把一段 30 行的硬编码代码改造成 60 行的参数化版本模型形状完全没变后续改尺寸就很舒服了。4.3 迭代失败的几个典型场景和排查思路迭代式生成过程中一个常见痛点是“上一轮改好了这一轮又改回去了”。AI 在生成新版本代码时有时会丢弃之前的修正内容。这个问题在长对话里尤其明显上下文太长模型注意力分散。排查思路很简单每一轮迭代之后把当前代码固定下来作为基准下一轮提示词里带上“基于以下代码修改不要重写整个文件”。如果 AI 仍然重写就改用 diff 工作流让 AI 只输出修改部分的代码块而不是完整模型代码。这样你就能以补丁方式手工应用修改最大限度地避免回归。另外一个典型场景是布尔运算产生了非预期的实体碎片。举个例子在一个圆柱体上切 6 个孔个别情况下会留下薄壁残片或者内部孤立实体。这种问题通常是编程上的逻辑错误比如差集对象并没有完全贯通主体差集深度小于主体厚度。排查方向是检查截切体的尺寸是否足够穿越主体必要时把差集体的高度额外增加 0.1mm 做重叠处理。5. 应用场景与影响范围5.1 设计早期探索从概念到草模的效率革命text-to-cad 目前对我价值最大的使用场景并不是最终出图而是设计早期的概念探索阶段。以前做结构设计脑海里有个初步想法要把想法变成可评估的三维形态至少要在 CAD 里经过建模操作就算熟练工也得花一两个小时。而且一旦形态方向不对这一两个小时就白费了。现在我的做法是用文字描述初始概念几分钟内生成三五个不同形态的候选方案快速在视觉层面和结构层面做初筛选出一个方向后再基于参数化结构进入精细设计。相当于把“三维头脑风暴”的成本压缩到了原来的十分之一。这种方式的改变不仅仅是快更重要的是思维模式的改变。以前因为建模成本高你会有意无意地收敛思路不敢多做几个变体。现在是零成本生成你更愿意放开脑洞去尝试不同方向这在设计过程中是极其可贵的。5.2 非专业用户参与定制化设计我在社区里看到不少非专业用户的案例他们可能完全没学过三维建模软件但通过文本对话的方式做出了像样的定制化零件给空气净化器做一个适配旧款滤芯的转接环、给手柄加一个符合手型的舒适握把、给桌面支架打一组心形排布的孔位。这些人并不是工程师他们的优势在于很准确地知道“我要什么”缺的只是“怎么把它画出来”的能力。text-to-cad 恰好把后者代劳了。自然语言是人类最基本的表达方式让 AI 做“翻译”非专业用户也能参与到过去需要多年软件经验才能完成的设计活动中来。不过也要泼一盆冷水非专业用户在使用时更容易踩“尺寸瞎编”的坑。他们通常没有预判尺寸合理性经验生成什么就信什么最后打印出来装不上、对不齐的情况屡见不鲜。所以我一直建议非专业用户至少要学一个基础技能会测量、会看尺寸。知道自己物品的关键尺寸并在提示词里明确写出来很多问题就能从源头避免。5.3 对工程师工作流的影响边界说到工程师群体我有几句比较实在的观察。text-to-cad 不会取代工程师的设计能力但它确实在挤压常规、重复、低创造性建模工作的空间。批量零件库建立、系列化规格派生、标准件变体生成这些工作以前需要工程师手动花时间做参数化建模。现在只要语义描述准确AI 能在几分钟内生成规格系列模型。工程师的工作重心正在从“操作建模软件”转向“定义需求和验证结果”。但设计始终有它的硬边界需要物理试验、强度仿真、加工工艺验证的地方AI 替代不了。任何一套文本生成的模型最终都必须经过工程校核才能投产。理解这个边界你才能真正把 tool 用成工具而不是神化成万能方案。写在最后的一点个人体会用了一段 text-to-cad 之后我的一个直观感受是真正拉开差距的不是会写提示词而是你脑子里有没有清晰的几何和工程概念。AI 再怎么强它也只能作为你的“执行放大器”负责把模糊的想法快速变成具体模型但想法本身的质量、判断模型是否合理的眼光仍然是人力核心价值所在。另外一个我一直在用的习惯是生成结果之后永远要亲自检查一遍关键尺寸和装配关系。AI 能帮你把 80% 的重复劳动消化掉剩下 20% 的工程判断需要你自己兜住。这种“人机各司其职”的配合方式应该就是接下来的主流形态。如果你正准备尝试 text-to-cad我建议直接从一个小零件开始给它配好参数、写好需求描述、跑通一次完整流程那种感觉会瞬间打开你对设计工具想象力的边界。