最近一段时间我一直泡在 text-to-cad 相关的工具链里面从生成一个小方块到拼出一个带装配关系的零件组算是把这个方向的套路摸了一遍。这篇文章不打算写那种“AI 未来已来”的空话只聊实际能落地的路径一句话描述怎么变成可编辑的 CAD 模型、底层用的什么生成范式、我在复现过程中踩过的坑以及一套从提示词到成品模型的完整实操流程。适合刚接触这个方向、想快速判断它能否提效的设计师、结构工程师和创客也适合准备做二次开发的程序员。先说结论text-to-cad 真正成熟的地方不是“直接画模型”而是“生成参数化建模代码”。这个思路的差别很大决定了你能拿到的是一个能改尺寸、能出工程图、能继续装配的 CAD 文件还是一个只能看不能动的网格体。下面我把整个逻辑拆开讲。1. 为什么 text-to-cad 选择“生成代码”而不是“直接生成模型”1.1 核心范式自然语言 → 程序化建模 → CAD 实体text-to-cad 最常见的实现路径是让大语言模型LLM读懂自然语言需求然后输出一段程序化建模脚本再交给 CadQuery、OpenSCAD 这类几何内核去解析最终得到 STEP、STL 或原生 CAD 格式。也就是说AI 不直接“画”模型而是把设计意图翻译成指令。这个范式有个关键优点输出的中间产物是代码不是一张死图。我拿到代码以后可以改参数、改逻辑比如把螺纹孔直径从 M3 改成 M4或者把阵列数量从 4 改成 6重新执行脚本就能得到新模型。这种可编辑性对工程场景来说几乎是硬需求因为你不可能每次需求微调都重新让 AI 生成一遍。对比之下如果 AI 直接输出网格模型比如通过神经场或扩散模型生成 STL模型往往是三角面片堆出来的无法直接用于参数化修改转成 B-Rep边界表示还会出现破面、缝隙下游做布尔运算很容易翻车。所以“生成代码”这条路本质上是用文本的可解释性换取了几何的可操作性。1.2 直接生成网格/神经场的路线为什么不够用在 text-to-cad 的探索中确实有人尝试过端到端生成几何输入文字输出的直接是体素、点云或三角网格。这类方法在视觉上很惊艳能生成有机形态比如雕塑、装饰件也能生成类似椅子、杯子这种语义明确的对象但一到工程领域就露怯。最现实的问题是精度。文本描述里的“直径 6.5mm”“中心距 40mm”“四孔均布”这些约束理论上是精确数值但扩散式生成器输出的是概率采样不会天然尊重毫米级尺寸。我见过很多生成结果外形像模像样拿卡尺一量圆孔是 6.7mm圆心距是 39.3mm这对装配来说是致命的。另外网格模型的拓扑结构乱导出到 CAM 做数控加工或者做有限元分析都很麻烦。它的应用场景更多是概念设计、可视化、游戏资产而不是真正进入制造流程。所以目前工业向的 text-to-cad 工具几乎都押注在代码生成路线上不是没道理的。1.3 底层工具链CadQuery、OpenSCAD 与原生 API 的分工程序化建模这个领域有两套代表性工具text-to-cad 的实现基本绕不开它们。CadQuery 是一套基于 Python 的库它以“工作平面 二维草图 拉伸/旋转/扫掠/布尔”为核心交互方式生成的几何体是 BREP 实体符合标准 CAD 的拓扑逻辑。我实际用下来CadQuery 的代码可读性好适合做参数化零件尤其是带精确尺寸和复杂布尔操作的件。它底层可以导出 STEP这是最通用的工程交换格式。OpenSCAD 用的是函数式语言靠 CSG构造实体几何把基本体元做交集、并集、差集。它的语法很简洁适合生成那种“纯粹布尔操作堆出来”的零件但可读性和二次开发体验不如 Python。很多 text-to-cad demo 选择 OpenSCAD是因为它的语法更简单LLM 更容易生成出可执行代码但真到了工程项目我宁愿用 CadQuery。还有一个方向是直接生成原生 CAD API 脚本比如用 Python 操作 FreeCAD 的 Part 模块或者给 Fusion 360 写脚本。这条路最贴近生产环境但 LLM 对特定 API 的掌握程度参差不齐生成出来的代码经常报错我目前的经验是它还不适合作为主力方案适合做辅助参考。2. 提示词与约束拆解从“一句话”到“几何约束”2.1 一句话需求里隐藏了哪些设计意图text-to-cad 最容易被低估的是提示词工程。很多人觉得“AI 画图”嘛随便描述两句就行但 CAD 生成对约束的敏感度远高于图像生成。图像生成漏掉一个细节你还能看到一张“差不多”的图CAD 漏掉一个约束生成出来的就是错误尺寸、错误装配关系的废件。我拿到需求时通常先把它拆成四类信息外形与轮廓、尺寸与公差、特征与操作、约束与装配。比如“做一个 60mm×40mm 的底座四个角倒 R5 圆角上面有一个直径 12mm 的凸台凸台高度 6mm中心位置在 X30、Y20 处”这句话里外形是底座尺寸是 60×40特征是圆角和凸台约束是凸台中心坐标。提示词里没有说清楚的东西AI 就会做“默认假设”。比如你没说圆角半径它可能不导圆角也可能倒一个 R2都可能。你没说凸台是圆形还是方形它可能随机选一种。所以 prompt 的核心工作是补全约束而不是增加修饰性语言。2.2 参数化设计与关键尺寸的换算逻辑程序化建模里尺寸不是孤立数值它们之间存在推导关系。比如四个螺栓孔的间距通常等于底座长宽内缩一个边距凸台中心坐标往往等于板材中心位置孔的数量如果是 4那分布方式可能是“矩形阵列”或“沿圆周均布”这两种模式对应的几何参数完全不同。我写提示词时会明确要求模型把所有数值都“显性化”。比如不要只说“厚度适中”而要写“厚度 8mm”不要说“均匀分布”而要写“在长宽方向各均匀分布 3 个孔孔距 20mm边缘距离 10mm”。这样生成代码时变量的可读性和后续可改性都会好很多。另一个容易踩坑的地方是单位。CAD 领域默认毫米但很多开源几何库内部有自己的单位约定。如果提示词里出现“几个厘米”或者“英寸”LLM 生成代码时可能直接填 4 而忘记换算结果模型差了 25.4 倍。我习惯在提示词开头写一句“本模型所有尺寸均使用毫米 mm”或者更狠一点在每个关键数值后面标注 mm。2.3 我在提示词里总结的五个加分习惯这五个习惯是我反复试错之后固定下来的写法能明显提高生成成功率和修模效率。第一先给全局再给局部。把整体外形、材料厚度、大致比例放在第一句再逐步展开细节特征。这样 LLM 生成代码时的结构顺序会跟着你的描述走代码可读性更好。第二用操作动词代替状态描述。比如“在顶面拉伸一个圆柱”比“顶面有一个圆柱体”更容易被转换成 CadQuery 的circle().extrude()因为动词直接对应建模 API。凡是涉及特征尽量用“拉伸、切除、倒角、阵列”这类建模操作词。第三给特征起变量名。提示词里写清楚“设底板厚度为 t_base 8mm”比直接写“厚度 8mm”要好。这样生成的代码往往自带参数定义后续修改只需要改变量值不用改逻辑。第四固定基准面和方位。“模型默认放在 XY 平面Z 轴向上拉伸”这句话能避免一半的方位错误。LLM 对空间坐标的理解没有三维软件里那么直观明确基面能减少代码里的workplane错乱。第五对于对称件主动说明对称规律。“关于 X 轴对称、关于 Y 轴对称”这种描述能让模型生成的代码更简洁也避免它把左右镜像做成两套独立特征。3. 实操记录用一个电机安装座完整跑一遍 text-to-cad 流程3.1 要做什么从需求到最终模型为了让流程可复现我用了一个很典型的机械件电机安装座。需求是这样的底板长 80mm宽 50mm厚 6mm底板四个角有直径 8mm 的安装孔孔中心距边缘 10mm底板中心有一个外径 30mm、内径 22mm 的圆形凸台凸台高度 15mm凸台面沿圆周均布 4 个直径 3.2mm 的螺钉孔中心圆直径 26mm。这个零件尺寸明确、特征典型、布尔操作多非常适合做 text-to-cad 的测试基准。我把这个需求整理成提示词后跑了三个不同实现路径直接让模型生成 CadQuery 代码、生成 OpenSCAD 代码、以及生成 FreeCAD 宏脚本。3.2 分步生成与迭代修正过程第一步是让模型输出 CadQuery 脚本。我先给了一段空模板要求它只填写内部逻辑。生成的初稿跑出来的结果是底板尺寸正确安装孔位置正确但凸台做成了实心圆柱内孔没有切除四个螺钉孔也没有打穿凸台面。这个结果挺典型的说明 LLM 理解“外径、内径”不够彻底它生成了圆柱的外形却忘了做第二次拉伸去挖孔。我用工具检查生成的代码定位到凸台生成段发现它只写了一步extrude(15)就没有后续操作。我的修法是补上挖孔操作在凸台顶部建立新的工作平面画直径 22mm 的圆向下拉伸切除 16mm。同时螺钉孔也在同一工作平面上用圆周阵列polar array实现。改完以后重新运行脚本几何体符合要求。第二步测试 OpenSCAD 路径。我让模型生成的是difference()堆叠结构一颗立方体做底板一个圆柱做凸台再用若干圆柱做差集。OpenSCAD 的优点是代码逻辑直白缺点是没有参数化工作平面的概念想要让凸台精确落在底板中心必须手动计算坐标偏移。这里我遇到了一个经典问题模型生成的凸台坐标写的是 40, 25但它忘了这个坐标应该对应底板的中心。我修正为 40, 25结果就对上了。第三步测试 FreeCAD 宏脚本。这个路径的成功率最低生成的脚本调用了多个模块函数运行时报错“找不到 Part.makeCylinder”原因是它把方法名猜错了。修脚本花的时间比生成时间还长我目前只把它当验证性尝试不会作为主力方案。3.3 导出、装配前的检查事项模型生成后不能直接拿去做加工或装配需要过一遍基础检查。我通常看五个点首先是单位对不对导出 STEP 的元数据里确认是毫米然后是布尔操作是否残留内部实体用剖面视图看有没有隐藏的生成线然后是表面质量如果模型用于 3D 打印检查是否有非流形边然后是尺寸复验拿测量工具量关键孔位和高度最后是命名规范给特征和草图起有名有姓的名字方便下游同事接手。如果你用的是 CadQuery导出 STEP 很容易一个exporters.export(result, motor_mount.step)就行如果你要 STL 做打印需要先转三角网格用横向细节参数控制曲面精度。我多次实测发现STL 导出时如果不设置弦高容差圆柱面会导出成明显的多棱柱所以要调整容差参数通常 0.01mm 左右就够了。4. 常见问题与排查技巧实录4.1 单位错乱与默认值问题text-to-cad 工具和通用 LLM 一样对单位的理解都是从语料里学的不是从测量系统里学的。如果提示词里用了“cm”“inch”“厚一点”“大约”这类模糊表述它很容易直接生成数字而不换算。我的排查办法是生成代码后先扫描全部数字手动核对量纲。比如这段代码里如果出现box(8, 5, 0.6)大概率它不是你要的 80mm×50mm×6mm而是把“毫米”理解成了“厘米”之后的错误尺寸。还有一种情况是模型用默认值兜底你没指定倒角半径它直接不倒你没指定孔数默认给你 4 个你没指定圆角是外侧还是内侧它可能两边都给你导。这些默认值导致的偏差在生成图片时无所谓在生成 CAD 时就是硬伤。所以审查提示词时我会把每个特征都对应到一个显式参数上去不给默认值留下空子。4.2 布尔运算失败与实体不闭合CadQuery 和 OpenSCAD 都是实体建模内核布尔操作失败通常有两个原因拓扑退化或共面冲突。共面冲突最好理解当两个实体在同一个平面精确接触时比如一个立方体放在另一个立方体正上方求并集时内核往往因为无法确定边界而失败。解决方案很简单让接触面稍微重叠 0.001mm比如把上方实体的底面往下延伸 0.01mm布尔结果完全一致但内核不再报错。实体不闭合问题常出现在从网格转换为实体时以及在 CadQuery 中用了不符合流形规则的操作时。比如你用一个圆环扫掠出一条很复杂的路径生成结果可能自相交。排查时我用的是直接检查法result.val().isValid()如果返回 False就用剖面拉一个切面看内部结构。多数情况下问题出在草图的曲线方向不一致或者拉伸深度为 0 导致退化面。4.3 文字描述引起的特征遗漏LLM 对长文本的注意力是分布式的这导致它在实现特征时容易顾此失彼。比如我前面说的电机安装座模型生成了底板和凸台却漏了凸台内孔和螺钉孔。这不是个例我在测试其他零件时也发现特征越多、遗漏率越高尤其是那些藏在“内部”的特征挖孔、槽、内螺纹模型常常优先完成外部轮廓内部细节就丢掉了。我的对策是分阶段生成第一步只生成外形确认外形没问题第二步生成主特征比如凸台和主要孔位第三步生成次特征比如倒角、孔阵列、加强筋。每阶段用肉眼和测量工具双重检查确认无误再进入下一步。这样做虽然多花几次生成时间但整体调试成本反而比一次生成大杂烩低很多。4.4 我的避坑清单速查表常见问题根因排查方法解决方案圆孔变成多边形STL 导出弦高容差过大放大视图检查圆弧边缘设置弦高容差 0.01mm尺寸错误 10 倍单位理解错误扫描代码中的数字提示词明确使用毫米 mm凸台实心没有内孔内部特征遗漏查看剖面分阶段生成特征零件一分为二布尔失败/实体分离isValid() 检查制造微小重叠面代码执行报错API 调用名错误对照文档检查方法名用 CadQuery 官方示例做基准特征基准面错乱未声明方位查看 workplane 链提示词首行声明 XY 平面Z 轴向上孔距与中心距不符参数化推导缺失测量孔距用变量定义中心距引用变量生成孔阵列这张表是我在实际测试中整理出来的大部分问题不是一次出现一个而是连锁出现。比如单位错会导致尺寸差尺寸差会导致布尔操作位置偏移偏移最终导致装配干涉。所以排查时要从根源表格里的“单位理解”开始逐项推进不要看到一个报错就改一个报错。5. 工具选型与工作流编排5.1 本地部署还是在线服务text-to-cad 方向目前有几种工具形态。在线服务类通常封装好了 UI输入文字直接出模型上手最快但可控性差往往只能得到结果拿不到中间的建模脚本或者拿到的脚本跟 UI 显示不完全一致。本地开源方案则是自己搭 LLM CadQuery/OpenSCAD 的管道可控性好能完全定制 prompt 和代码生成逻辑但对环境搭建有一定要求。我的建议是如果只做原型验证、偶尔生成一两个概念件用在线服务足够如果要把 text-to-cad 纳入日常设计流程、批量生成参数化件、或者做二次开发必须走本地管道。我自己倾向于本地方案的原因是它能保留每一轮生成的代码我可以直接在代码上改而不是每次都从头生成。5.2 CadQuery 在本地方案中的主力地位在本地管道里CadQuery 是我最常用的几何内核。它适合做“特征树”式建模代码顺序跟操作顺序一致LLM 更容易生成准确的链式调用。CadQuery 还有一个很关键的点是内置了工作平面的操作机制可以非常自然地表达“在顶面开孔”“在侧面开槽”这类空间操作。如果你已经用惯了 OpenSCAD接 text-to-cad 也不差因为 OpenSCAD 的 CSG 语法极其简单LLM 生成时出错率低而且它在渲染速度上有优势。但 OpenSCAD 没有真正意义上的“草图-特征”结构做复杂曲面零件能力有限适合做对精度要求不高的工艺造型。我目前的工作流是这样的需求文本 → 提示词模板 → LLM 生成 CadQuery 脚本 → 本地执行脚本 → STEP/STL 导出 → 在 FreeCAD 或 Fusion 360 里做装配验证。如果模型有误我直接修改生成的脚本而不是让 LLM 重新生成全量代码这样对复杂零件的稳定性高很多。5.3 提示词模板的工程化沉淀本地方案最值得投入的是沉淀一套自己的提示词模板。我把常用零件结构拆成了模板模块板类件模板、轴类件模板、壳体件模板、装配件模板。每个模板固定了坐标约定、单位声明、命名规则和输出格式要求再把具体参数作为变量填入。这样做的好处是同一套逻辑生成出的代码风格统一出问题的时候定位非常快不用反复跟 LLM 解释设计规范。比如我的板类模板里固定写这一段# 板件模板底座类 base_length: float 80.0 # 总长 mm base_width: float 50.0 # 总宽 mm base_thickness: float 6.0 # 厚度 mm fillet_radius: float 5.0 # 四角圆角 mm之后才进入具体建模逻辑。这段参数块的好处是模型生成的代码里可以显式引用这些变量而不是魔法数字。后续改尺寸只需要改参数值重新执行脚本即可。这其实就是把 text-to-cad 从“一次性生成工具”升级成“参数化生成基座”的关键一步。6. 对 text-to-cad 未来落地的一点思考我在个人项目里用 text-to-cad 造了大量零件从外壳、支架、夹具到简单的传动件最大感受是它不是来替代 CAD 建模师的而是把“从需求到零件”的前置筛选流程压缩了。过去遇到一个需求我得先画草图、定尺寸、建特征遇到自己没把握的部分还要查手册现在变成先让模型出初版我再把注意力集中在约束审查和装配干涉上效率确实提升了一个级别。但也必须承认当前 text-to-cad 对复杂曲面、大型装配体、带公差标注的工程制图依然无能为力。你让它生成一个“符合人体工学的鼠标外壳”它大概率给你一个对称的椭球你让它生成“基于 ISO 公差配合的轴承座配合孔”它理解不了公差等级的含义。所以使用它的正确姿势是把它当成“快速概念几何生成器”和“参数化草图助理”而不是万能建模机器人。我个人的实践体会是text-to-cad 的真正价值不只在“生成模型”这一步而在于把设计过程重构成“文字约束 代码参数 自动重建”的模式。以前我改一个零件要重新打开原生工程文件找到对应特征手动修改约束再重新生成派生图纸现在只要改提示词里的参数块或者改脚本里的变量值整个零件族就重建出来了。这种模式对系列件、非标件的管理特别有用它让“设计”本身变成了可以版本控制的代码资产。如果你现在正打算进入这个方向我建议从一个小批量、强约束的零件开始比如门板、支架、安装座把它完整跑通一遍从文字到 STEP 的流程。这个过程中你会深刻感受到最花时间的不是 AI 生成而是你如何把脑子里含糊的“想要什么”翻译成精确的约束条件。把这一步练扎实text-to-cad 就能真正从玩具变成工具成为你设计流程里稳定的一环。