Text-to-CAD 实战：从自然语言到参数化三维模型的工程化路径-北京尧图网络

1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到“text-to-cad”这个说法我脑子里蹦出来的画面是对着电脑说一句“给我来个带法兰的六角螺栓”屏幕上就自动长出一个可以导出加工的实体模型。这个画面在几年前还属于科幻范畴但现在已经有一批工具和方案在往这个方向靠了。所谓 text-to-cad直译就是“文本转计算机辅助设计”核心思路是把自然语言描述转换成参数化的三维几何模型或者至少转换成能驱动 CAD 软件生成模型的脚本与参数。它解决的问题很具体。传统 CAD 建模的门槛不在“画图”而在于你得先学会软件的操作逻辑、约束系统、特征树管理还要理解工程语义。一个机械工程师画一个标准件可能只要三分钟但一个产品经理、一个做概念验证的开发者、一个只想快速拿到某个形状做仿真的人往往卡在“我不会用 SolidWorks”这一步。text-to-cad 想干的事就是把这层操作门槛抹掉让描述本身成为建模指令。适合关注这个方向的人其实比想象中多。做快速原型的设计师需要批量生成不同规格的零件做对比做机器人仿真的研究者需要快速搭出场景里的各种几何体做教育的人想让学生把注意力放在几何思维而不是软件按钮上还有一类是做数据增强的需要大量带参数标注的三维模型来训练模型。这些场景的共同点是模型本身不复杂但数量多、变体多、手动建模不划算。我在这篇文章里会拆开讲几个层面文本到底怎么变成几何、参数化建模为什么是绕不开的中间层、实际跑通一条链路需要哪些组件、以及我在尝试类似方案时踩过的那些坑。不会只停留在“这个概念很酷”的层面而是尽量给到能上手复现的思路和判断依据。2. 文本到几何的三种技术路线以及为什么参数化脚本是当前最稳的落点2.1 直接生成网格看起来最直接实际最难控最直觉的路线是让模型直接输出三维网格比如点云、体素或者三角面片。这条路线在学术上有很多探索典型做法是把文本编码成一个向量再通过某种生成模型解码成三维结构。它的优点是端到端不需要中间表示理论上能生成任意形状。但问题也很明显生成的网格往往拓扑混乱、面片数不可控、尺寸没有工程意义而且很难做后续的参数修改。我试过用这类方法生成一个“带圆角的矩形底板”出来的东西远看像那么回事近看边缘是锯齿状的圆角半径也没法精确控制。对于做概念草图可能够用但一旦你要拿去做装配、做干涉检查、导出 STEP 文件给加工这条路基本走不通。所以直接生成网格更适合做视觉参考不适合做工程交付。2.2 生成 CAD 脚本把自然语言翻译成建模命令第二条路线是让模型输出一段脚本比如 OpenSCAD 的代码、FreeCAD 的 Python 脚本或者某种 CAD 软件支持的宏命令。这段脚本再被 CAD 引擎执行生成真正的参数化实体。这条路线的好处是几何是精确的尺寸是可追溯的改一个参数就能重新生成整个模型。举个例子你输入“一个长 50 毫米、宽 30 毫米、高 20 毫米的长方体中心挖一个直径 10 毫米的通孔”模型需要输出的不是网格而是类似这样的伪代码length 50 width 30 height 20 hole_dia 10 base Box(length, width, height) hole Cylinder(radiushole_dia/2, heightheight) result base - hole这段代码本身不难难的是让语言模型稳定地理解“中心”“通孔”“直径”这些工程语义并且映射到正确的 API 调用上。我实测下来对于结构清晰、尺寸明确的描述这条路线已经能跑出可用的结果但对于含糊的描述比如“一个好看的支架”模型就会开始自由发挥出来的东西往往不能用。2.3 参数抽取加模板匹配最笨但最可靠第三条路线是我个人最推荐的尤其是在你需要批量生成、需要稳定复现的场景下。它的思路是不指望模型直接写出完整脚本而是让它从文本里抽取出关键参数和特征类型然后套用预先写好的参数化模板。比如你有一个“法兰盘”的模板模板里定义了外径、内径、螺栓孔数量、螺栓孔分布圆直径、厚度这些参数。用户输入“一个外径 100、内径 40、厚度 10、6 个螺栓孔的法兰盘”系统只需要把数字和数量抽出来填进模板就能生成模型。这条路线的好处是可控性极强模板是你自己写的几何质量有保证模型只需要做它擅长的事——理解语言和抽取信息。三条路线的对比如下路线几何精度可修改性实现难度适用场景直接生成网格低差高视觉参考、概念草图生成 CAD 脚本高好中结构清晰的零件描述参数抽取加模板高好低批量生成、标准件变体我现在的做法是混合使用先用参数抽取加模板处理大部分标准结构遇到模板覆盖不了的形状再退回到生成脚本的方式并且加一层几何合法性检查。这样既保证了稳定性又保留了一定的灵活性。3. 跑通一条最小链路从文本输入到可导出模型的关键组件3.1 语言理解层别指望模型一次就懂工程语义语言理解层是整个链路的第一环也是最容易出问题的一环。很多人以为直接把用户输入丢给一个大模型就行了但实际跑下来会发现模型对工程术语的理解远没有想象中可靠。比如“倒角”和“圆角”在很多语境下会被混用“沉头孔”和“埋头孔”的区分也需要额外的知识注入。我的做法是在语言理解层加一个“术语归一化”的步骤。具体来说维护一个工程术语映射表把用户可能用的各种说法映射到标准术语上。比如“打穿”“打通”“贯穿”都映射到“通孔”“倒圆”“圆边”都映射到“圆角”。这个表不需要很大覆盖常见的一两百个术语就够用了。然后在提示词里明确告诉模型你是一个 CAD 参数抽取器只输出结构化的参数不要输出解释。输出格式我建议用 JSON因为它的结构清晰后续解析不容易出错。一个典型的抽取结果长这样{ shape_type: flange, parameters: { outer_diameter: 100, inner_diameter: 40, thickness: 10, bolt_hole_count: 6, bolt_hole_diameter: 8, bolt_circle_diameter: 80 }, units: mm }这里有个细节单位。很多用户不会主动说“毫米”但 CAD 建模对单位极其敏感。我的处理方式是默认毫米同时在提示词里让模型在检测到“厘米”“英寸”等词时做换算并标注。这个细节看起来小但实际用起来能避免大量“模型尺寸差了 25.4 倍”的尴尬。3.2 几何生成层OpenSCAD 和 FreeCAD 脚本的取舍几何生成层我主要用两个引擎OpenSCAD 和 FreeCAD。OpenSCAD 的优势是语法简单、纯代码、容易程序化生成缺点是它的几何内核在处理复杂布尔运算时性能一般而且导出的格式有限。FreeCAD 的优势是几何内核更强支持 STEP 导出适合做工程交付缺点是 API 比较庞杂脚本写起来更啰嗦。我一般的判断标准是如果模型只是用来做视觉展示或者 3D 打印OpenSCAD 足够如果需要导出 STEP 做后续加工或者装配就用 FreeCAD。下面是一个用 OpenSCAD 生成法兰盘的例子outer_dia 100; inner_dia 40; thickness 10; bolt_count 6; bolt_dia 8; bolt_circle 80; difference() { cylinder(douter_dia, hthickness, centertrue); cylinder(dinner_dia, hthickness2, centertrue); for (i [0:bolt_count-1]) { rotate([0, 0, i * 360 / bolt_count]) translate([bolt_circle/2, 0, 0]) cylinder(dbolt_dia, hthickness2, centertrue); } }这段代码里有个小技巧挖孔用的圆柱高度设成thickness2比主体高一点这样布尔减运算不会因为浮点误差在表面留下薄薄一层残留。这个坑我踩过好几次模型看起来没问题但导出 STL 之后切片软件会报“非流形边”的警告。3.3 校验与导出层几何合法性检查不能省模型生成出来之后千万别直接导出就完事。我至少会做三项检查第一包围盒尺寸是否和输入参数一致防止单位或者参数映射出错第二体积是否为正且合理防止布尔运算把实体减没了第三是否存在零厚度面或者非流形边这个可以用 trimesh 之类的库快速检测。import trimesh mesh trimesh.load(output.stl) print(包围盒:, mesh.bounds) print(体积:, mesh.volume) print(是否水密:, mesh.is_watertight)如果is_watertight返回 False说明模型有破面拿去打印或者做仿真都会出问题。这时候要么回到几何生成层调整参数要么在导出前做一次修复。修复工具我常用的是trimesh自带的fill_holes和fix_normals对于简单模型够用了。导出格式的选择也有讲究。STL 最通用但不带单位信息很多软件默认按毫米读也有按英寸读的容易出岔子。STEP 带单位、带拓扑信息适合工程流转但文件更大生成也更慢。我的习惯是内部流转用 STEP对外给 3D 打印用 STL并且在文件名里把单位标清楚比如flange_100mm.stl。4. 实测中那些让人抓狂的边界情况4.1 模糊描述当用户说“大一点”的时候文本转 CAD 最头疼的不是复杂模型而是模糊描述。用户说“一个大概这么大的板子”你没法知道“这么大”是多大。用户说“孔开大一点”你也不知道是直径加 2 毫米还是加 5 毫米。这类输入如果直接丢给模型它要么瞎猜一个数要么反问用户但反问在自动化流程里往往不可行。我的处理策略是设置默认值和范围约束。比如对于“板子”这个形状如果没有给尺寸就默认 100x100x5 毫米如果用户说“大一点”就在默认值基础上加 20%。同时在输出里标注哪些参数是推断出来的方便用户后续修改。这个做法不完美但比让模型自由发挥要可控得多。还有一种情况是描述里包含相对关系比如“孔的位置在板子中心偏左”。这种“偏左”没有量化模型很难处理。我的做法是把它转成比例比如“偏左”映射到 x 方向偏移 25% 的板宽。这个映射规则需要根据实际场景调没有万能公式。4.2 单位与精度25.4 倍的教训前面提过单位问题这里展开说一下。我遇到过一次典型的翻车用户输入“一个 2 英寸的立方体”模型抽取参数时把 2 存了进去但单位字段写的是毫米。结果生成出来是一个 2 毫米的立方体小了 25.4 倍。这个错误在视觉上不明显因为模型看起来就是个立方体但尺寸完全不对。后来我在流程里加了两道保险第一在参数抽取的提示词里明确要求模型检测单位词并做换算统一输出毫米第二在几何生成前做一次尺寸合理性检查如果某个维度小于 1 毫米或者大于 10000 毫米就触发警告让人工确认。这两道保险加下来单位错误基本没再出现过。精度问题也值得提一句。CAD 建模通常用双精度浮点数但导出 STL 的时候会做三角化精度会损失。对于大多数 3D 打印场景默认精度够用但如果模型里有很小的特征比如 0.5 毫米的倒角就需要在导出时调高精度否则倒角可能直接消失。OpenSCAD 里可以用$fn参数控制圆弧的分段数FreeCAD 里可以在导出时设置偏差值。4.3 布尔运算失败几何内核的脾气布尔运算是 CAD 建模里最常用的操作也是最容易出问题的操作。两个实体做差集如果它们恰好共面或者有极薄的相交区域几何内核就可能算不出来或者算出一个破面模型。这个问题在 OpenSCAD 和 FreeCAD 里都存在只是表现方式不同。我的经验是尽量避免让两个实体的面完全重合。比如你要在一个板上挖一个和板等高的孔不要把挖孔圆柱的高度设成和板厚完全一样而是稍微高一点让它在板的两侧都冒出来一点。这样布尔运算就不会遇到共面情况成功率会高很多。这个技巧在前面法兰盘的代码里已经用到了thickness2就是这个目的。如果还是失败可以尝试把模型导出成网格用网格布尔库来做比如trimesh的布尔功能或者pymesh。网格布尔的精度不如实体布尔但鲁棒性更好不容易直接报错。代价是生成的模型不再是参数化实体后续修改会麻烦一些。5. 把 text-to-cad 用起来的几个实际场景5.1 批量生成标准件变体做设计对比做机械设计的时候经常需要对比不同规格的标准件。比如你要选一个法兰盘外径有 80、100、120 三种螺栓孔有 4 个和 6 个两种组合起来就是 6 个变体。手动建模要重复六次用 text-to-cad 的话你只需要写一个模板然后批量替换参数就行。import subprocess variants [ {outer: 80, bolts: 4}, {outer: 80, bolts: 6}, {outer: 100, bolts: 4}, {outer: 100, bolts: 6}, {outer: 120, bolts: 4}, {outer: 120, bolts: 6}, ] for v in variants: scad_code generate_flange_scad(v[outer], v[bolts]) with open(fflange_{v[outer]}_{v[bolts]}.scad, w) as f: f.write(scad_code) subprocess.run([openscad, -o, fflange_{v[outer]}_{v[bolts]}.stl, fflange_{v[outer]}_{v[bolts]}.scad])这个流程跑下来六种变体几分钟就能全部生成而且尺寸精确一致不会出现手动建模时“这个孔好像偏了 0.5 毫米”的问题。对于需要做参数扫描或者优化迭代的场景这种批量生成能力非常实用。5.2 为仿真和机器人场景快速搭建几何体做机器人仿真或者物理仿真的时候场景里需要大量的几何体桌子、箱子、圆柱体、斜面等等。这些几何体不需要很精细但需要尺寸合理、位置准确。用 text-to-cad 的思路你可以用一段文本描述整个场景然后自动生成所有几何体并摆好位置。比如“一个 1.2 米长、0.6 米宽、0.75 米高的桌子桌面上放一个 0.3 米边长的立方体桌子旁边有一个直径 0.4 米、高 0.8 米的圆柱体”。这种描述用参数抽取加模板的方式很容易处理生成的模型可以直接导入仿真环境。相比手动在仿真软件里拖拽调整效率提升非常明显。5.3 教学场景让学生专注几何思维而不是软件操作我在和一些做工程教育的朋友交流时发现他们有一个共同的痛点学生花在学软件上的时间太多花在理解几何关系和工程约束上的时间太少。text-to-cad 在这个场景下可以做一个“几何思维训练器”学生用自然语言描述他们想要的形状系统生成模型学生再检查生成的模型是否符合预期。这个过程反过来会迫使学生把描述写得更精确。比如学生一开始写“一个带孔的板”生成的模型可能孔在正中间他如果想要孔在角落就必须学会说“孔位于板的左上角距离两边各 10 毫米”。这种“描述-生成-检查-修正”的循环其实是在训练工程语言表达能力这个能力在实际工作中比软件操作更重要。6. 我踩过的坑和总结出的几条实操原则第一个坑是过度信任模型的几何理解能力。我一开始觉得既然模型能理解“一个红色的圆”那理解“一个带倒角的圆柱”应该也不难。实际测试下来模型对颜色、形状这些视觉概念确实敏感但对“倒角”“沉头”“螺纹”这些工程特征的理解很不稳定。同一个描述换个说法生成的结果可能就差很多。所以后来我在提示词里加了大量工程术语的示例并且用 few-shot 的方式让模型模仿。第二个坑是忽略了导出格式的兼容性。有一次我生成了一批模型导出成 STL 发给合作方对方用某个软件打开后发现尺寸全乱了。排查了半天发现是那个软件默认按英寸读 STL而我的模型是按毫米建的。后来我养成了习惯导出 STL 时在文件名里带单位同时额外导出一份 STEP 作为参考。STEP 带单位信息不会出现这种问题。第三个坑是布尔运算的顺序。多个布尔操作叠加的时候顺序会影响结果也会影响计算成功率。我的经验是先做加法合并再做减法挖孔、切槽。因为加法通常比减法稳定先把主体形状合并好再在上面做减运算出问题的概率会低一些。如果反过来先在一个小实体上挖孔再和大实体合并有时候孔会被合并操作“吃掉”。第四个坑是参数默认值的选择。一开始我没设默认值用户不给尺寸模型就瞎猜结果五花八门。后来我给每个模板都设了合理的默认值并且在输出里明确标注哪些是默认值。这样即使用户描述不完整至少能生成一个尺寸合理的模型用户可以在上面改而不是从零开始。几条我总结出来的原则能用模板就不用自由生成能抽参数就不让模型写代码能导出 STEP 就不只导出 STL能在生成后做校验就不要直接交付。这几条原则看起来保守但实际用下来它们能把 text-to-cad 的可用性从“玩具级别”提升到“能干活级别”。最后分享一个我最近在用的调试技巧把每次生成的输入文本、抽取的参数、生成的脚本、导出的模型都存到一个带时间戳的文件夹里。这样当某个模型出问题时你可以回溯到具体的输入和中间结果快速定位是语言理解错了、参数映射错了、还是几何生成错了。这个习惯帮我省了大量排查时间尤其是在批量生成的时候没有这套记录根本不知道是哪个环节出的问题。

Text-to-CAD 实战：从自然语言到参数化三维模型的工程化路径

相关推荐

编译器扩展与C++兼容性：跨平台开发避坑指南

多智能体协作架构实战：用agency-agents构建自动化代理系统

逆数学导论：五大公理子系统如何度量定理强度

更多资讯

SpringBoot+微信小程序：网络安全科普系统论文转工程实战解析

Spring Boot核心配置解析：绑定、多环境与加密实践

信创文件传输系统有哪些？主流形态、选型要点与避坑指南

OWASP Top 10 2017 完整解读：十大 Web 应用安全风险详解与防御指南（仓库 2017/es 与 2017/en 版）

公务员计算机专业课备考：从数据结构到SQL的高效刷题策略

三级Linux真题精讲：从进程管理到LVM的运维实战拆解

今日更新

再见，SSE！你好，Streamable HTTP！轻松开发 Streamable HTTP MCP Server 并接入 TaoToken

工业软件标准化路线图：国产替代的落地施工图

VCMI安卓版实操指南：原生运行英雄无敌3的3步技术落地

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？