ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

text-to-cad实战:用自然语言驱动参数化CAD建模

text-to-cad实战:用自然语言驱动参数化CAD建模 我去年第一次跑通text-to-cad时感触挺深。给大模型敲一句“生成一个带四个沉头孔的法兰盘外径60内径20螺栓孔节圆直径48”几秒钟后屏幕上真的出现了一个参数化法兰盘。这件事放在三年前想都不敢想。当时我第一反应是糟糕参数化建模的门槛要被踏平了。text-to-cad说直接点就是通过自然语言描述来生成可用于CAD工程建模的三维模型。它不像文生图那样只出个视觉概念而是直接产出能被CAD软件打开、编辑、修改尺寸、用于制造加工的几何模型。适合谁用一是没有系统学过三维软件的机械工程师、结构工程师二是天天被改图折磨、想用AI先出底稿的老手三是刚接触产品设计的新人。它能帮你把“脑子里的想法”快速变成“能进一步编辑的模型实体”省掉从空白草图开始拉约束的半小时。但这玩意儿没有网上吹得那么玄乎。我实测下来它最大的价值不是“一键出完美图纸”而是提供一种“自然语言驱动参数化建模”的交互范式。这篇文章就把我在实践过程中踩过的坑、总结出的提示词写法、参数设计逻辑和工具选型的真实体验完整摊开讲。1. text-to-cad到底在解决什么问题1.1 从自然语言到三维模型的距离很多人觉得“从文字到三维模型”和“从文字到图片”差不多都是AI生成内容其实完全不是一个量级的难度。文生图只要像素分布合理、视觉上像就行但CAD模型必须满足严格的几何约束面要封闭、边要闭合、布尔运算要能成功、尺寸要精确、参数要可调。你告诉AI“画一个杯子”图片模型无所谓但CAD里涉及杯壁厚度、杯口圆角、底部倒角、容积等这些全是可量化的数值。更要命的是人类语言本身是模糊的。比如“一个大一点的支架”多大算大“圆弧过渡”到底要R几传统CAD软件里每一步都是确定性的几何操作而自然语言天生不具备几何精确性。text-to-cad要解决的第一个问题就是把模糊描述翻译成确定性的几何指令序列这背后需要LLM有很强的“空间推理”和“代码生成”能力。1.2 为什么偏偏是CAD而不是其他3D格式现在市面上AI生成3D模型的产品不少很多是生成Mesh网格模型输出OBJ、GLB用渲染器看一眼挺漂亮但放进SolidWorks、Fusion 360或者FreeCAD里基本没法编辑。Mesh是由三角形面片构成的离散表面而CAD工业模型需要的是BREP边界表示也就是用NURBS曲面和精确曲线构造的实体模型甚至还需要记录建模历史、约束关系和特征树。我用一个生活化类比解释Mesh模型就像用乐高颗粒搭出的恐龙样子像但你没法把它车成一个带公差要求的轴套。CAD模型就像一份机械加工图纸不仅有外形还有每个特征怎么来的、尺寸怎么驱动的。text-to-cad如果只输出Mesh那它解决的只是“可视化”而非“工程建模”。所以技术路线上真正有实用价值的text-to-cad大多选择生成可以直接执行的代码比如OpenSCAD脚本、CadQuery脚本或者参数化Fusion 360脚本这样产出的模型才能二次编辑、才能进制造流程。1.3 现在到底能解决到什么程度先说结论对简单机械零件、结构件、3D打印原型这类场景text-to-cad已经能达到可用的程度。比如法兰盘、齿轮毛坯、支架、外壳、夹具、收纳盒、带孔板、管道接头这些特征清晰、对称性强、易于用参数表达的模型效果尤其好。我实测过不少次生成后丢进OpenSCAD直接渲染几何完整布尔运算不报错。但涉及复杂装配体、自由曲面外观件、精密配合面、需要符合具体制造工艺比如注塑模脱模斜度的场景目前只能算“半自动”。你要理解一个核心逻辑text-to-cad本质上是在“写代码建模”而不是“AI替你思考设计”。它能把你的意图转成几何却不能替你判断哪种结构更合理。所以现阶段最好的用法是把它当成一个高水平的建模提效工具而不是设计替代品。2. 主流实现路径与工具选型2.1 代码生成路线LLM OpenSCAD / CadQuery我最初接触的text-to-cad项目就是基于“大模型直接生成OpenSCAD代码”的路线。这也成了我最推荐的切入方式原因很简单openSCAD是文本化建模模型的本质是一段声明式脚本代码并且有原生的参数变量和模块化能力。LLM本来就擅长写代码让它写OpenSCAD脚本几乎是无缝对接。这条链路的工作流程是用户输入自然语言描述 - LLM生成OpenSCAD代码 - 本地OpenSCAD自动渲染 - 输出模型预览。如果要导出工业格式再加一步把OpenSCAD模型导出为STL或STEP。CadQuery跟这个类似只是用Python语法封装得更工程化生成的几何精度更高适合更复杂的操作链。这条路线最大的优点是天然参数化。因为LLM输出的是代码代码里可以直接写outer_diameter 60、hole_count 4这样的变量改一个参数整个模型联动变化。这也是它在工程场景比Mesh生成路线更有价值的根本原因。2.2 直接生成Mesh/体素的Diffusion路线另一条路线是模仿图像生成的Diffusion模型直接生成三维点云、体素或Mesh。用户说“一个花瓶”模型输出一个带卷边的花瓶网格。近两年有几篇很火的论文走这个方向视觉效果确实惊艳能生成自由曲面和有机形态这是代码生成路线很难做到的点。但工程落地时问题马上就暴露了。第一生成的网格模型非流形很多破面、交叉面、开放边司空见惯拿去做布尔运算基本一碰就碎。第二网格一旦生成改尺寸极其痛苦你没法在Mesh上直接说“孔距改成40”只能重新生成。第三从Mesh转BREP的自动重拓扑技术目前远不成熟虽然有一些逆向工程工具但结果在工程上很难用。所以这条路线更适合游戏资产、可视化Demo、概念造型展示放在text-to-cad的语境下只能算“旁支”。2.3 我为什么最终选了LLM OpenSCAD在对比了两条路线之后我几乎没犹豫就站到了代码生成这一边。原因是可调试、可复现、可改参数。生成Mesh是一锤子买卖结果不合意只能重新生成但生成OpenSCAD代码我能在文本编辑器里看到每个几何操作知道它错在哪里直接删一行代码就能修好。另外OpenSCAD的生态非常开放脚本本身就是一种“可执行文档”。同一个脚本改几个变量就能出不同规格特别适合做标准件族。Fusion 360、FreeCAD也都支持Python脚本本质上跟这条路线一样。如果你追求模型能直接进CAM加工CadQuery生成STEP文件是更好的选择。但作为入门和验证OpenSCAD成本最低、反馈最快。我建议新手先别急着折腾CadQuery或Fusion API先把OpenSCAD跑通理解了“AI写代码 - 参数化建模”的核心逻辑再迁移到更工业化的工具链。这个顺序能让你避免很多挫败感。3. 实操用text-to-cad生成一个带参数的法兰盘3.1 环境准备与调用方式先说环境。你需要三样东西OpenSCAD软件本体、一个大语言模型的API接口以及一段调用LLM生成OpenSCAD代码并自动渲染的胶水脚本。很多开源项目都把第三步做成了命令行工具本质流程都一样把用户输入塞进System Prompt里要求LLM只输出OpenSCAD代码保存成.scad文件再用OpenSCAD命令行渲染预览。以我个人习惯我直接把API封装成一个Python函数输入描述文本输出生成后的.scad文件路径。后续手动在OpenSCAD里打开、按F5预览、按F6进行CGAL渲染。这里有个很关键的习惯永远别把LLM第一次生成的代码当成最终结果。第一次生成往往是“能看但不好改”的半成品你需要跟它对话迭代一两轮。所以胶水脚本里一定要保留交互式修改的入口别做成一次性生成就结束。3.2 写好提示词的几个要点提示词对text-to-cad的影响之大怎么强调都不过分。你可能觉得“AI应该懂我的意思”但实测下来如果你只写“帮我做一个法兰盘”生成的模型大概率是个圆柱体带六个孔完全没有倒角和沉头更别说参数定义了。我总结了几个亲测有效的要点第一点明确单位。不写单位时LLM会默认毫米但有时候会突然用英寸导致比例完全失调。我习惯在提示词第一句就写“所有尺寸单位均为毫米”。第二点指定使用参数变量。直接说“请将所有关键尺寸定义为变量并在代码顶部集中列出包括外径D、内径d、法兰厚度t、螺栓孔数量n、螺栓孔节圆直径pcd、沉头孔直径ch”。这样生成出来的代码才具备参数化能力而不是散落一堆魔法数字。第三点限定建模策略。OpenSCAD里同一个法兰盘可以用旋转体、圆柱再打孔、平面前差集等好几种方式写。我会要求“用线性拉伸或者旋转体方式建模避免多个特征交错出现”因为这样可以减少布尔运算失败概率。看一个我常用的完整提示词样例用OpenSCAD写一个参数化法兰盘模型所有尺寸单位mm。 关键尺寸定义为变量并放在代码开头 outer_diameter60, inner_diameter20, thickness8, flange_hole_count4, pcd_diameter48, countersink_diameter8, hole_diameter5。 要求 - 法兰外圈有一个凸台外径44有效厚度4 - 四个螺栓孔沿pcd均匀分布需要沉头孔沉头直径10沉头深度2 - 中心内孔贯穿 - 生成后检查几何是否为流形实体。3.3 生成结果的校验与修复当我把上面的提示词跑通后拿到了一段OpenSCAD代码。直接按F6预览模型外形基本正确但第一次生成时出现了两个小问题一是沉头孔没做沉头深度只是通孔二是中心内孔与沉头孔之间的材料厚度过薄差一步就破壁了。这种小瑕疵几乎每次都会遇到。我的排错流程是先在OpenSCAD里开启“视图-显示-边线”和“检查网格”重点看有没有红色警告然后单独注释掉可疑的差集模块分步检查基础几何最后把关键尺寸变量手动改大改小看模型是否联动。这一步特别重要因为不少text-to-cad生成结果看起来对但一改参数就出错这往往是因为LLM把尺寸写死在多个子模块里没有统一用变量引用。修复时我一般直接在.scad文件里手动改代码或者在对话窗口里要求AI重写。实测下来让AI针对具体报错信息重写某个模块比自己动手改更高效因为OpenSCAD的报错信息已经很明确LLM能理解“WARNING: difference() not supported这种结构问题。3.4 参数计算过程与一套可直接用的代码这里展示一个我最终整理好的参数化法兰盘代码片段方便你参考。重点看参数顺序和几何模块的拆分。// 法兰盘参数 outer_diameter 60; // 法兰外径 inner_diameter 20; // 中心孔内径 thickness 8; // 法兰总厚 boss_diameter 44; // 凸台外径 boss_thickness 4; // 凸台厚度 hole_count 4; // 螺栓孔数量 pcd_diameter 48; // 螺栓孔节圆直径 bolt_hole_diameter 5; // 螺栓通孔直径 countersink_diameter 10; // 沉头直径 countersink_depth 2; // 沉头深度 module flange_base() { union() { cylinder(douter_diameter, hthickness, $fn120); translate([0, 0, thickness - boss_thickness]) cylinder(dboss_diameter, hboss_thickness, $fn120); } } module center_hole() { translate([0, 0, -0.01]) cylinder(dinner_diameter, hthickness 2 * boss_thickness 0.02, $fn120); } module bolt_holes() { for (i [0:hole_count-1]) { angle i * 360 / hole_count; x pcd_diameter / 2 * cos(angle); y pcd_diameter / 2 * sin(angle); translate([x, y, -0.01]) cylinder(dbolt_hole_diameter, hthickness 0.02, $fn60); // 沉头只在上表面做 translate([x, y, thickness - countersink_depth]) cylinder(dcountersink_diameter, hcountersink_depth 0.01, $fn60); } } difference() { flange_base(); center_hole(); bolt_holes(); }这套代码的逻辑很清晰基础体用两个圆柱并起来然后减去中心孔、螺栓孔和沉头孔。沉头孔是用小圆柱放在大圆柱上面效果是上表面有一个锥形台阶生产上如果要求标准沉头角度还需要用圆台不过对于3D打印和快速验证已经够用。值得提醒的是$fn这个参数决定圆柱分段数直接影响渲染速度和文件大小。预览阶段我用$fn60最终导出STL前根据表面质量要求调到120或更高。这里有计算逻辑分段数过低圆形变成多边形螺栓孔直径会偏小分段数过高文件体积暴涨切片软件也可能变慢。对一般机械零件圆周分段数取周长毫米数的四分之一到三分之一比较合适。比如外径60周长约188$fn取60到90就足够。4. 常见问题、坑和排查心得4.1 几何不封闭或破面布尔运算失败的根因text-to-cad生成过程里出现频率最高的坑就是几何不封闭。表现就是OpenSCAD用CGAL渲染时提示Object may not be a valid 2-manifold mesh或者布尔运算之后模型缺了一块。我排查下来根因十有八九是布尔操作体之间的空间关系没处理好。一个典型例子LLM经常在一个可执行代码里让两个圆柱恰好贴合比如第二个圆柱底面高度正好等于第一个圆柱顶面高度没有重叠量。在理论几何里这没问题但浮点计算时公差不够CGAL做并集时可能因为共享面判定失败而破面。解决办法很简单让参与布尔运算的实体之间有一点微小的重叠比如差集用的钻头圆柱高度多给0.02到0.1毫米。你可以把这个经验直接告诉AI“请在差集圆柱的首尾各预留0.1mm的过切量。”这样能显著降低失败率。另外如果提示是“不是有效2-流形”多半是有开放边。在OpenSCAD里开启“检查网格”后出现红色标记面就是问题区域。这种时候先不用急着重生成尝试把并集体改成union()显式合并或者将相关尺寸用round修正到整数毫米往往能救回来。4.2 参数化失效LLM被“魔法数字”带偏了我遇到过很多次模型外形完全对但改一个变量就崩掉的情况。比如把法兰外径从60改成90螺栓孔却不在节圆上了或者沉头孔深度变成了负数。看代码才发现LLM虽然定义了一些变量但仍然在某几行直接写死translate([24,24,6])这种硬编码坐标。这就是参数化失效。这类问题的高效解法是在提示词里要求“所有涉及位置的数值一律基于变量计算不得出现与变量无关的硬编码数字”。如果已经有代码出错了让LLM把硬编码数字全部替换为对应变量的表达式。说实话这一步比让AI直接“生成新模型”更靠谱因为硬编码位置通常意味着模型结构已经乱了重新生成反而更快。我在实操中养成了一个习惯每次生成完代码先用编译器的“变量列表”面板扫一遍看每个变量是否被引用到了。没被引用的变量直接删掉防止后续改参数时出现迷惑。这里有个小技巧把提示词里所有尺寸都列成表格发给AI并要求它“写出一个包含参数表的Excel式注释块”后续维护会方便很多。4.3 提示词工程在CAD场景的特殊性文生图的提示词讲究“风格、意境、细节”text-to-cad完全不是这么回事。我在摸索过程中意识到CAD场景的提示词更像“给实习生的工程指令”必须把测量基准、约束优先级、几何语义讲得滴水不漏。举个典型的失败案例我最初说“加四个螺栓孔”AI默认把四个孔均匀分布在圆周上这没问题。但当我要求“在四角加安装孔”时我忘了说孔间距和孔径AI随意给了几个离谱数值。后来我就加了这样一个提示词模板“孔间距应为X孔径为Y孔到边缘的最小距离应大于Z。”在CAD语境里“最小距离”“名义尺寸”“公差”这类词AI理解得很好但你必须主动提供。还有一个坑是“对称性”。语言里“左右对称”在CAD里可能意味着镜像、阵列、旋转对称或者中心对称处理方式完全不同。AI经常自作主张把对称做成镜像结果零件变为不可用的左手版。我现在的提示词会明确写“本零件关于XY平面对称所有特征必须成对出现。”这个约束对工程件几乎都是必要的。4.4 现在工具的边界与适用性判断说句实在话text-to-cad虽然很惊艳但离“设计创意降维输出”还差得远。我自己看到网上很多夸张演示一个提示词生成一个完整机器人外壳点开看大部分是视觉效果根本没有可以加工的特征结构。真正的工程件不只需要外形还需要考虑应力集中、脱模斜度、配合间隙、公差累积这些AI目前基本无能为力。所以我把text-to-cad的适用范围收缩到这三类概念验证模型、3D打印原型、标准件族自动化。这三类场景的共同点是“尺寸驱动、特征明确、容错率高”。反过来如果你要做的是滑动配合件、密封件、精密铸件强烈建议只用AI生成的模型做初始外形参考之后必须在专业CAD里重做一轮完整的尺寸链和公差分析。我能给的一个最现实的建议把text-to-cad当成“快速把你脑子里的草图变成可交互的三维底稿”的助手然后你在这个底稿上修修补补效率比从零开始画高得多。别指望它一个人扛下整个设计流程现在的技术还做不到硬上也只会让你觉得“这AI怎么这么蠢”。5. 影响范围与后续扩展思路5.1 对设计工作流的实际影响text-to-cad真正改变的不是“画模型”这步而是“想法到模型”之间的距离。以前工程师拿到需求要开CAD软件、建草图、受约束、加特征本质上是在做“翻译”工作——把人的意图翻译成几何操作。现在这个翻译工可以由AI代劳工程师只需要负责决策和审查。我在实际项目中已经开始这么用接到一个“设计小型电机安装支架”的需求后我先用text-to-cad生成一个粗略的参数化支架包含安装孔、加强筋和走线槽然后导入FreeCAD修改尺寸链再出工程图。整个过程从两小时压缩到四十分钟而模型质量反而因为初始结构更干净而变好了。这套流程特别适合非标自动化里的快速打样、治具设计、工装设计。5.2 与现有CAD/PDM体系的融合未来如果text-to-cad要进入正规流程必须解决“生成结果如何与管理体系对接”的问题。现在很多工具输出STL工程师还要手动转STEP。建议选择支持CadQuery或FreeCAD脚本的路线因为它们能直接生成带特征历史的原生CAD文件比OpenSCAD的STL导出更适合进PDM。我对接PDM的做法是把已验证的OpenSCAD代码同时生成一个STEP文件并附上一份包含材料、表面粗糙度、热处理要求的参数表。这样AI生成的模型就不再只是一个“几何孤岛”而是可以进入BOM和工艺路线的有效数据源。5.3 后续可以自己扩展的方向如果你还想继续深入有两个方向特别值得投入。第一个方向是“自建私域模型库”攒一批验证无误的text-to-cad脚本把提示词和输出代码做成模板下次碰到同类零件直接套用效率翻倍。第二个方向是“反馈闭环”在OpenSCAD脚本里加入自定义断言、尺寸检查函数生成后自动判断内孔是否大于壁厚、螺栓间距是否小于标准值之类减少人工复查。这个思路比单纯堆提示词更工程化也是我现在主要的优化方向。我个人在实际操作中的体会是text-to-cad最有价值的地方不在那个“生成”的瞬间而在它让你重新理解了CAD建模的语言本质——当你把建模过程拆成“参数、特征、约束、布尔运算”这样的原子操作时AI的发挥空间才会真正打开。我踩过最深的坑就是一开始把提示词写得像跟朋友聊天后来改成“给实习生的工程指令”生成质量立刻上了一个台阶。这个细节比换更强的模型还管用建议你下次跑text-to-cad时先试试。
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进