text-to-cad实践指南：自然语言驱动参数化代码生成CAD模型

上周同事扔给我一张手绘草图说“就这个法兰四个安装孔的位置稍微挪一下”。我改到第三版的时候忽然意识到如果有一条流水线能把“描述需求”直接变成“可编辑的数模”这种来回返工至少能省掉一半。我正在折腾的方向就是这两年设计圈讨论度很高的 text-to-cad用自然语言描述零件或结构让大模型理解设计意图再通过代码生成的方式输出真正可编辑、可装配、可出图的CAD模型。它适合每天做非标件、频繁改结构的设计师也适合想让三维建模门槛降下来的3D打印玩家。下面这些内容是我实际搭建和跑通这条链路后的经验记录希望能让后来的人少踩几个坑。1. 技术路径拆解为什么“代码生成”才是text-to-cad的主赛道1.1 三条路线的真实对比我最早接触text-to-cad时第一反应是“让大模型直接输出一个.obj或者.step文件不就行了吗”。真去试了才发现这条路在工程上非常难走。三维模型本质上是一堆点、面、拓扑关系纯文本输出格式就算勉强写出来也基本没法保证“水密”、自交、法向一致这些几何基本要求。目前市面上能看到的主流方案可以粗略分成三条路线。路线A是“LLM直接生成模型文件”比如让模型输出一段OBJ格式的顶点和面索引或者生成STEP的文本片段。优点是省事缺点是几乎不可用。三维格式的token效率极低一个简单的立方体要输出几十行坐标稍微复杂一点的特征就把上下文窗口撑爆了。更麻烦的是模型不懂几何拓扑约束输出的面经常是反的顶点顺序一错模型直接报废。路线B是“LLM生成参数化建模脚本”把自然语言转成CadQuery、OpenSCAD、FreeCAD的Python脚本或CSG声明式语言。这条路线是我现在的主力方案。它的核心逻辑是把几何问题转化成代码问题代码可以用解释器执行、渲染、报错模型在报错的引导下反复修正自己直到出图成功。路线C是使用扩散模型或隐式场做端到端生成输入文本输出体素或神经隐式曲面。这条路线论文里效果很好看但从实际落地来看精度低、可编辑性差生成的是“一张图片式”的网格根本没法进入工程流程。三条路线的对比结论其实很明确当前工程可用度最高的是路线B。它把“不可验证的几何生成”变成“可验证的代码生成”每一步都有中间表示可以检查这正好命中了大模型能力的天花板和短板。1.2 可编辑性才是真正的前提条件很多没做过设计的人会问能出一个模型不就行了为什么非要可编辑因为在真实工作流里设计是“改”出来的不是“生成”出来的。你拿自然语言让模型生成了一个支架看起来结构对但孔位要往后挪3毫米筋板要加厚到8毫米这些需求在后续装配中随时会发生。如果模型输出的是一块不可拆分的网格那这模型就是一次性道具设计人员还得重建一遍如果输出的是参数化脚本那改一个数字就完成一轮迭代。这里面的本质区别在于CAD模型的本质是“特征树约束”而脚本本身就是特征树的文本表示。CadQuery里每一条box、cut、hole都对应着设计意图的修改操作这个过程是可追溯的、可回滚的。OpenSCAD里的difference、hull本质上就是布尔运算和特征叠加。让大模型写脚本等于让它在设计特征的空间里工作而不是在离散三角形的空间里硬拼。我自己的体会是可编辑性这个门槛决定了text-to-cad到底是一场技术表演还是一个能融入现有设计流程的生产工具。凡是把“生成”作为终点的方案基本都停留在玩具阶段凡是把“生成脚本参数回传”作为闭环的方案才真正有落地的希望。2. 工具链与选型参考从开源脚本到在线服务2.1 脚本侧主力CadQuery、OpenSCAD、FreeCAD要搭text-to-cad工作流第一步是选一个能被大模型“写好”并且能稳定执行的建模脚本语言。我试过的工具里最值得推荐的是CadQuery、OpenSCAD以及正在快速成熟的build123d。CadQuery是基于Python的参量化建模库它的写法非常接近人类的建模步骤先在平面上建立工作平面再来拉伸、切孔、倒角。大模型对这种“步骤化”的API理解得很快因为它和人们描述建模过程的方式高度一致。OpenSCAD则更适合纯逻辑驱动的造型它的语法是函数式CSG特别适合那些能用“差集、交集、平移、循环”表达的结构比如齿轮、多孔板、格栅。FreeCAD的Python API也可以走这条路但它的API相对厚重大模型驾驭不好所以我在快速原型阶段几乎不碰它。以下是我对这些工具的简单对比。工具语法风格最适合的场景主要缺点CadQueryPython链式调用机械特征、孔槽、法兰、对称件环境依赖稍多新手编译易出错build123dPython面向对象复杂特征树、装配级参数化学习曲线比CadQuery高OpenSCAD声明式CSG数学化造型、阵列、布尔组合圆角倒角能力较弱FreeCAD Python重量级API已有FreeCAD生态内二次开发prompt生成效果不稳定如果只想选一个起步工具我建议直接选CadQuery。它生态最完整导出STEP、STL都很成熟而且大模型的训练语料里相关的代码示例足够多生成质量相对稳定。OpenSCAD可以作为第二工具补充使用用来生成那类“用循环描述几何”的零件。2.2 端侧模型与在线服务除了自己写代码市面上也出现了不少号称text-to-cad的在线服务和研究项目。有些是公司做的编辑器插件输入一句话自动生成基础模型有些是学术机构放出来的实验模型能读文本并输出CAD脚本或网格。它们的出现说明这个方向正在被更多人看见但说实话实验室工具离生产还有很长距离。我试用过几类工具后总结下来的经验是在线服务通常擅长“听起来很酷的单体造型”比如一只椅子、一个花瓶、一个抽象雕塑但一旦涉及工程上常见的长宽高尺寸、公差、配合关系它们就立刻露馅。原因很简单工程需求的约束是硬性的差1毫米装配就过不去而生成式模型天生擅长模糊匹配不擅长硬约束。所以我的建议是在线服务可以拿来找灵感、做概念阶段的视觉参考但真正的设计交付物还是靠自己搭的“大模型脚本”链路来保证。别把自己的交付能力绑在一个不透明的在线接口上很多时候你连它是怎么生成、能不能复现都不知道。3. 从零搭一个text-to-cad工作流demo3.1 环境准备Python CadQuery 大模型API我这里直接给一个能跑通的最简配置。假设你的机器上已经有Python 3.10以上版本那么只需要用pip安装CadQuery再准备好一个云端大模型API的调用密钥即可。pip install cadquery安装完成后可以用下面这段代码验证CadQuery是否能正常工作。import cadquery as cq part ( cq.Workplane(XY) .box(60, 40, 10) .faces(Z) .workplane() .rect(6, 6) .cutBlind(-10) ) cq.exporters.export(part, test_box.step)这段代码创建了一个60乘40乘10毫米的长方体然后在顶面挖了一个6乘6毫米的方孔。如果程序能跑通并生成test_box.step文件说明环境已经就绪。大模型API这里就不指定具体厂商了当前主流的云服务都能胜任关键是要在请求中明确要求“只输出CadQuery代码不输出解释”。3.2 Prompt模板与几何描述词汇表环境解决之后真正决定生成质量的是提示词设计。很多人用text-to-cad失败不是因为模型不行而是因为prompt里写的是散文不是工程需求。模型擅长理解“四个角上有孔”这种自然语言但如果你希望孔的位置精确就必须给它明确尺寸和数据。我这里有一个反复验证过的模板基本可用。你是一位参数化CAD工程师熟悉CadQuery。 当前零件单位全部使用毫米(mm)坐标系Z轴向上。 请根据以下需求生成CadQuery代码 任务设计一个矩形法兰底座。 尺寸长60mm宽40mm厚10mm。 中心有一个6mm x 6mm的通孔。 四个角各有一个直径6mm的安装孔孔中心距较近边缘的距离为10mm。 要求 - 只输出Python代码不要输出解释。 - 使用cadquery库导出STEP文件。 - 不要使用不存在的API不要使用未定义的变量。 - 先写代码再以注释形式标注每个特征的尺寸。注意“先写代码再以注释形式标注每个特征的尺寸”这句话很重要。它能让模型在输出代码时回到可解释的设计特征思路而不是生成一串难以理解的数字堆积。你还可以在系统提示词里维护一份“几何描述词汇表”比如“通孔完全贯穿”“盲孔只挖到一定深度”“沉头孔锥形底部”这能显著减少歧义。3.3 闭环校验编译、渲染、反馈、修正拿到模型生成的代码并不等于拿到模型必须经过执行和校验。我会把大模型输出的代码保存成一个临时文件用CadQuery执行并导出STEP再用可视化工具或免费查看器快速检查轮廓。如果代码报错就把错误信息连同原代码一起回传给大模型让它修正。这里给出一个自动循环的框架可以直接抄走。import cadquery as cq import subprocess def run_cq_code(code: str): try: exec(code, {cq: cq, export: cq.exporters.export}) return None except Exception as e: return str(e) user_prompt 设计一个矩形法兰底座长60宽40厚10... last_error None for attempt in range(4): if last_error: prompt user_prompt \n\n上一次生成的代码报错了报错信息\n last_error \n请重新生成完整可运行的代码。 else: prompt user_prompt code llm_generate(prompt) error run_cq_code(code) if error is None: print(生成成功) break last_error error我实际跑下来的经验是大部分第一次生成的代码会卡在“API记忆混乱”上比如CadQuery版本之间的函数名差异、忽略面选择的写法不对但只要把报错回传模型自己改对的比例非常高。三到四轮之内基本能产出可用的STEP文件。4. 实测踩坑记录LLM写CAD最容易翻车的五个场景4.1 单位与坐标系的混乱这是最常见、也最隐蔽的问题。大模型在训练语料中见过大量混合单位制的内容它可能上一秒在用毫米下一秒就切到英寸。装配场景下尤其危险一个零件是60毫米另一个零件是6厘米看起来数值不同实际相等但如果是英寸与毫米混在一起装配体直接乱套。我的对策是在每一次请求里都显式声明“单位全部使用毫米坐标系Z轴向上”并把这句话放在prompt的最前面而不是垫在最后。更重要的是生成完成后要抽查代码里的关键尺寸是否和需求一致不要默认模型执行了你的单位约定。4.2 拓扑错误与布尔运算失败模型生成的代码执行不报错不代表几何正确。最容易踩的一个坑是布尔运算导致的面缺失或自相交。比如在CadQuery里用cut操作切孔如果草图没有闭合有时不会报错但生成的重心或体积计算会异常在某些情况下导出的STEP文件进入CATIA或SolidWorks时会被提示几何有问题。对策是坚持“先构建闭合截面再拉伸或切除”的思路。我在prompt里会明确写所有草图必须闭合所有拉伸必须指定长度禁止依赖默认值。这个习惯帮我避开了大量后续问题。如果需要做严苛的仿真前处理生成后还要专门做一步几何修复比如导入到FreeCAD里用Shape Validator检查精度容差。4.3 命名冲突与装配配合问题当模型生成一个包含多个特征的零件时它经常给每个草图或特征取一个通用名字比如rect、hole、cut重复命名会直接导致代码失败。有时候循环体内创建的边或面没有显式命名后续引用时根本找不到对象。我解决这个问题的方式有点土但很有效让模型在生成代码时“每个特征使用带语义的变量名”比如flange_base、center_hole、mounting_hole_front_left。大模型对这种要求适应得很好一旦命名清晰了后续的代码修正、参数改动都变得顺很多。对于大型装配体我会要求模型使用显式的workplane和tag标记而不是依赖默认选择这样装配时不会选到错误的表面。4.4 模型幻觉一本正经地写不存在的API这个现象在大模型写代码时太常见了。模型可能写出一个看起来很有道理、但CadQuery库里压根不存在的函数比如extrude_from_face或者一个不存在的参数名。代码执行时立刻报错报错信息投喂回去后模型往往又会在下一轮编一个新的API出来。要制住这个毛病就得在prompt里限制“只能使用以下API”并附上一小段可用的API示例代码让模型照葫芦画瓢。你可以把自己验证过的示例代码贴进去比如上面的法兰底座代码模型会模仿这段代码的写法大幅减少幻觉。实测下来给一段示例代码比在prompt里写十句“不要编造”都管用。4.5 上下文丢失与多轮修改歧义在多轮修改中用户经常说“把孔往左挪一点”但“左”到底朝哪个方向、挪多少模型完全没概念。更常见的是模型在第三轮修改时已经忘了第一轮生成的零件长什么样直接在新结构上重复挖孔结果整个模型多出几十个孔。我现在的做法是每一轮修改时都把“完整的需求文档上一轮成功代码”一起发给模型而不是只发送“请把XX改一下”这一句话。同时要求模型在代码里保留所有原有特征的参数定义只改动目标参数。任何“改一下”的描述都必须补充具体尺寸或百分比否则退回去确认需求后再动手。5. 应用场景与落地边界text-to-cad到底适合做什么5.1 能做的事快速概念样件、标准件、参数化模板生成text-to-cad目前最适合的场景首先是非标零件的概念设计。比如客户说“我需要一个能装在40毫米方管上的L形支架带两个腰形孔”传统做法是找模型库、量尺寸、从草图开始拉现在可以直接用自然语言描述出一版能看能改的三维模型快速沟通结构方案。第二个我经常用的场景是扩充标准件库。很多企业的标准件库其实缺一堆“非典型”型号尺寸只差几个毫米却找不到现成模型。用text-to-cad的脚本生成思路把尺寸参数从自然语言里解出来批量生成同族不同尺寸的模型能把一上午的建模时间压缩到几分钟。第三个场景是产品教学。让初学者先描述自己想做的东西再看到代码和特征树的对应关系对理解“参数化建模”非常有帮助。工具生成得越差反而越能暴露设计意图描述的模糊之处这一点在带新人时意外地好用。5.2 暂不能做的事复杂装配、精密公差、仿真级模型我见过不少人对text-to-cad的信心过高拿它去生成复杂减速箱、完整管道系统结果当然很惨。这些场景的难点不在“画得出形状”而在“约束合理”。装配关系、配合公差、表面粗糙度、材料属性这些信息目前靠自然语言很难完整表达大模型也没有可靠手段去验证它们。更关键的是仿真级模型对几何质量要求极高。有限元分析前处理需要干净的中面抽取、无干涉装配、合理的圆角简化这些都是模型当前根本做不到的。生成一个看起来像样的箱体容易但生成一个能做模态分析的箱体完全是另一回事。所以要谨慎区分“视觉概念模型”和“工程可用模型”。前者是text-to-cad的主场后者还需要工程师在生成结果上做大量修整和验证。任何宣传“输入一句话直接上产线”的说法你都不妨先打一个问号。工程模型的可用性最终还是得用工程工具去检验。5.3 对CAD工作流的影响即便有上述边界text-to-cad对工作流的影响仍然值得重视。它真正改变的是设计师的工作内容。以前设计师大量时间花在“用手画模型”上现在这部分正在被自动化替代工作重心逐步转向“定义约束”和“审查生成结果”。这有点像程序员经历了从手写汇编到使用高级语言编译器的过程。写代码的人依然需要理解底层原理但日常效率完全不在一个量级。审图能力、约束定义能力、几何知识这些核心素养会变得更值钱而那些只会机械重复“建块、拉伸、倒角”的操作型岗位压力会越来越大。对于设计部门来说更现实的改变是“需求评审的颗粒度”要变细既然模型能快速生成需求必须表达得更精确否则错误的模型会生成得更快返工也更隐蔽。6. 工具选型建议与进一步探索6.1 选型建议速查表最后给一张我个人的选型建议表。如果你要快速搭自己的text-to-cad建议按下面这个组合来使用场景推荐组合理由快速概念建模通用大模型API CadQuery代码可控、报错好回传、STEP导出成熟以布尔运算为主的机械件build123d特征边界清楚复杂布尔更稳定教学与可视化逻辑OpenSCAD语法简单、CSG结构直观企业参数化模板库私有化大模型 RAG模板库复用历史设计资产保证数据本地化以上所有组合我都跑过一遍最稳定的还是第一行。CadQuery的报错信息相对清晰大模型通过几轮反馈基本能自己修正过来这是它适合作为底层引擎的很大优势。6.2 后续扩展方向多模态、RAG与自动验证text-to-cad接下来值得探索的方向我目前关注三个。第一个是多模态输入把“一张手绘图一段文字描述”同时喂给模型让视觉信息和语言约束互相补充。手绘图能提供空间位置的直觉文字提供尺寸和标准化需求两者结合后输出质量会有明显提升。第二个是检索增强生成RAG。把公司历史设计过的模型脚本、特征模板、标准规范存到向量库里让大模型在生成前先检索相似的零件结构作为参考能显著降低幻觉概率也让生成结果更符合企业内部的设计风格。第三个是自动验证闭环。生成模型后可继续配合轻量级仿真工具自动做静强度校核或干涉检查把不合格的模型直接打回重生成。这能把当前“人看完再修改”的流程进一步自动化也是我认为text-to-cad从玩具走向生产工具最重要的一个入口。6.3 我的实践体会回头看我自己的实践最能提升整体成功率的其实不是某个炫酷的模型或强大的后端而是把“需求描述”这层基本功打扎实。大模型对几何的理解能力已经超过大多数人的预期真正限制它的是人的表达足够不够工程化。尺寸、单位、基准面、约束逻辑这些在往常图纸上看似枯燥的内容在text-to-cad里变成了模型能听懂的唯一语言。另外建议你别追求一条prompt搞定所有零件。我目前的习惯是针对不同零件类型维护各自的结构化描述模板——板类、轴类、壳体类、支架类分开写配合各自的示例代码生成稳定性远高于一套通用模板打天下。text-to-cad和其他工具一样用得越精细回报越高。