做了十来年设计工具相关的事情一直有个执念能不能让非专业人士不碰 CAD 软件也能做出能拿到加工厂去生产的 3D 模型。Text-to-CAD 这个方向最近给了我一个很真实的答案。过去一年随着大语言模型在代码生成上的表现越来越稳这个概念从论文里钻了出来变成了一条可以实际跑通的流水线你打一句“一个长 100 宽 50 高 10 的底板四角打直径 6 的孔”系统就能吐出一个 STEP 文件。这篇文章想把这条流水线从里到外拆一遍——它到底在解什么题、有哪几条技术路线、真实跑起来是什么体验、坑在哪里以及最关键的一层什么需求适合交给它做什么需求千万别碰。如果你是机械设计师、创客、或者只是偶尔要画个零件图的产品经理这篇文章应该能帮你少走一段弯路。即便你只是好奇“AI 到底怎么把语言变成固体”下面的链路拆解也不会让你失望。1. 我为什么盯上 Text-to-CAD建模痛点的最后一公里CAD 建模难吗说实话几何概念本身不难难的是“把脑子里的东西准确翻译成软件操作”。传统建模的学习曲线大头根本不花在几何原理上而是花在软件交互上一堆菜单、坐标系、约束关系、特征树、视图操作全是你和几何之间的中间介质。你明明只想做一个带法兰的圆柱体脑子里想的是“圆柱加一圈凸缘加六个孔”手上却要做的是建草图、约束尺寸、拉伸、选面、再建草图、阵列、布尔运算……Text-to-CAD 恰好把这一段操作壳砍掉了。1.1 建模软件的操作成本远大于设计本身做过机械设计的人都有个默契同一个零件老手画一小时新手画三小时差的不是空间想象力而是对软件交互的熟练度。CAD 软件的本质是约束求解器加几何内核但为了驱动它们用户不得不学习一层厚厚的操作语言。参数化建模更是如此——你明明想的是“孔径 6mm孔距边缘 5mm”在软件里却要经历“选面、建参考、标注尺寸、加约束”四步一步都不能少。所以 Text-to-CAD 的第一性价值是去掉操作壳把命令式设计带回来。人类本来就会用语言描述零件工程师之间口头交流一个零件的结构从来不需要打开软件。Text-to-CAD 就是用大模型把口头描述转成软件能执行的指令相当于给 CAD 加了一个“同声传译”。这也是我这两年越来越看好它的原因它不是在一个已经很顺的流程上加速而是在填一个真实存在的能力缺口。1.2 谁会被 Text-to-CAD 解放三类典型使用者第一类是机械工程师拿来出概念草图。设计评审之前要快速验证几种结构方案不用每个方案都建一遍完整的特征树先让 Text-to-CAD 把大概轮廓抛出来再进软件细化。第二类是创客和硬件爱好者他们有想法但没受过 CAD 训练过去只能去模型站下载凑合用的 STL 文件现在可以自己“把模型说出来”。第三类是被迫提需求的产品经理心里想表达一个结构需求又不想被一句“你画个示意图呗”拦住Text-to-CAD 让他们能直接把自己的想法可视化。这三类人的共同点很明确设计意图清晰但不愿意、也没时间投入几百个小时去学软件操作。Text-to-CAD 不是要取代专业设计师而是把“从意图到模型”这最后一公里的翻译问题解掉。想清楚这个定位后面选型才不会跑偏。2. 文本到几何的完整链路语义、代码、内核三者如何分工要理解 Text-to-CAD 为什么能落地得先把链路拆开。现在主流的实现本质上是一条三段式流水线自然语言解析、程序化建模生成、几何内核执行。每一段解决一类问题没有任何一步是从零直接变出一个模型文件的魔法。2.1 第一步自然语言到结构化意图的“翻译官”文本进来之后第一件事是把它拆成结构化意图。拿“一个长 100 宽 50 高 10 的底板四角有直径 6 的孔孔距边缘 5”这句话来说模型需要识别出基础形状是长方体尺寸是 100×50×10特征类型是通孔直径是 6位置是四角偏移量是 5。这就是一个槽位填充加几何推理的双重任务。这一步目前由大语言模型承担它的优势在于懂常识——知道“四角”意味着四个位置“孔距边缘 5”意味着要留边距。传统 NLP 做不了这种开放性理解大模型则是在大量设计文档、图纸标注和工程师交流语料上训练过的对这类表述非常敏感。需要留意的是这一步的产物不是人类可读的文字而是一段结构化的指令通常是一段代码或结构化的数据对象直接喂给下一步执行。2.2 第二步程序化建模代码如何变成实体几何有了结构化意图接下来要把它变成几何。程序化建模是整个链路里最关键的一环用代码描述几何再用几何内核去解释执行。CadQuery 这类工具做的事情就是把“拉伸这个轮廓”“在这里打孔”“把两个体做布尔并集”翻译成内核的底层调用最终生成精确的实体模型。为什么用代码作为介质而不是直接把意图喂给内核因为代码可读、可改、可调试。生成结果不对你可以打开代码定位问题模型生成的代码如果只是参数写错了改一个数字重新执行就行。这种“生成—执行—反馈”的闭环天然适合大模型的迭代改进。几何内核负责最终落地以主流的边界表示BREP方式用面、边、顶点把实体边界精确描述出来。这一步保证了最终产物不只是一个好看的渲染图而是有真实几何数据、能被加工软件识别的实体。2.3 第三步渲染预览与尺寸校验闭环的最后一块拼图代码执行完交给内核生成实体但链路还没有结束。用户必须能看到结果并且能快速判断“这个模型对不对”。所以完整链路里还得有渲染器和尺寸校验器渲染器把 BREP 数据变成可视化窗口尺寸校验器自动检测关键尺寸是否落在容差范围内。这一步很容易被忽视但在实际系统里用户 90% 的挫败感来自“看起来对实际尺寸错”或者“实际几何对但预览丑得没法看”。好的 Text-to-CAD 系统会在生成后自动标注尺寸或者把原始指令和生成结果做成对照视图。没有这最后一步整个链路就只能算“能跑”不能算“能用”。3. 三种技术路线的取舍为什么“让模型写代码”暂时赢了目前公开的 Text-to-CAD 方案大致可以分成三条路线。我在评估时把它们都过了一遍包括跑一些公开实现结论可能跟你的直觉不太一样最直接的“用 AI 直接生成模型”那条路线反而不是最靠谱的。3.1 路线 A让大模型生成参数化代码代码合成这是当前实际效果最好、落地产品最多的一条路线。做法很朴素让大语言模型输出一段 CadQuery 脚本然后在沙箱里执行把执行结果转成 STL 或 STEP 文件渲染出来。去年公开的一些评测里这条路线在标准件数据集上的成功率明显领先其他两条。原因并不复杂。大模型本来就在海量代码上训练过生成代码是它的舒适区参数化建模脚本又是代码天然带反馈——执行失败、尺寸离谱系统能立刻发现并让模型修正。更重要的是代码是一个确定性的中间表示同样的代码内核执行结果永远一样这让调试变得非常轻松。你在 CAD 软件里“撤销一下”可能还要等重新计算但在代码链路上改一行、跑一下几秒钟就出结果。3.2 路线 B部署一个生成模型直接输出几何几何生成学术圈有不少工作是在训练 Transformer 或扩散模型直接从文本输出体素、点云甚至多面体网格。这条路线看起来很梦幻但落地上有一个致命问题几何精度。CAD 的核心是精确一个 6mm 的孔加工要求可能到 6.03mm而现有生成模型输出点云和网格的误差通常在毫米级这个精度离“可制造”还有数量级的差距。另外神经网络直接输出几何还有一个麻烦数据格式与主流 CAD 体系不兼容。你需要从网格逆向拟合成 BREP 实体这步拟合经常让精度进一步恶化。所以我的判断是这条路线适合做概念探索和形态研究不适合当生产工具用。3.3 路线 C从模型库检索模板再改参数参数检索还有一条折中路线先在已有模型库中检索最相似的模板再结合文本对模板的驱动参数进行调整。比如用户说“做一个更厚的支架”系统找到现有的支架模板把厚度参数改掉输出成品。这条路线的优点是输出质量非常稳定——模板本身是经过验证的几何不会崩。缺点是泛化能力弱模型库里没有的类型它就无能为力。它更适合企业内部这种模型种类受控、重复度高的场景适合做私有化落地不太适合做通用产品。3.4 三条路线横向对比精度、可编辑性、泛化能力维度代码合成直接生成几何模板检索 参数调整几何精度高内核级低毫米级误差高模板兜底可编辑性强改代码就行差网格难以修改中只能调参数泛化能力强任意描述中依赖训练数据弱依赖模型库落地难度中需要沙箱高需要海量数据低复用现成库适用场景通用设计概念形态探索企业标准件 / 参数化族表格一列为什么代码合成暂时胜出就一目了然了。当然这不代表另外两条路线没有价值——几何生成未来如果能把误差压到亚毫米级一定会反过来对代码合成形成压力。但就目前的工程实践而言代码合成是唯一能够稳定闭环交付的路线。4. 亲手搭一个最小闭环大模型生成 CAD 脚本的完整实操理论拆完了来点实际的。我花了一个周末搭了一个最小可用的 Text-to-CAD 系统全程用开源库目标只有一个把“一句话”变成一个“STEP 文件”。下面是完整过程每一步都是可以复现的。4.1 环境与分工我选了什么“翻译官”和“建筑工人”我的分工很简单大模型当“翻译官”负责把中文描述变成 CAD 脚本CadQuery 当“建筑工人”负责把脚本变成实体底层几何内核负责“质检记录”产出精确模型。技术栈选型上CadQuery 比直接用 OpenSCAD 更顺手因为它是 Python 库可以无缝嵌入处理流程不用额外启动子进程去调命令行工具。我用的环境是 Python 3.11 加 CadQuery 2.4支持直接导出 STEP 和 STL。大模型部分用的是通用大语言模型 API带函数调用能力方便做结构化输出。整套链路不需要 GPU一台普通笔记本就能跑。4.2 提示词工程把 CAD 的隐性规则写进系统约束很多人以为 Text-to-CAD 就是“把用户的话转发给大模型”结果生成的东西往往没法用。问题出在没有把 CAD 领域的隐性规则写进系统提示词。我的系统提示词里固定了这么几条硬约束你是一个 CAD 脚本生成器。你的任务是理解用户描述输出一段可执行的 CadQuery Python 代码。 硬性要求 1. 所有长度单位统一为毫米用户未说明单位时按毫米处理。 2. 输出只包含纯 Python 代码不要用 Markdown 代码块包裹不要加解释。 3. 每个特征必须显式标注尺寸禁止使用默认值或随机值。 4. 先创建主体几何再叠加特征孔、倒角、阵列。 5. 代码必须包含 result 变量并将最终结果赋值给 result。 6. 如果用户描述存在歧义自行选择最合理的解释并在代码注释中说明。这几条约束看起来简单但能挡掉 80% 的翻车场景。尤其是第 3 条大模型非常喜欢省略尺寸它会默认一个“看起来合理”的厚度而实际制造时这种未声明的尺寸就是坑。4.3 沙箱执行与三步重试让翻车概率从 70% 降到 20%代码生成完不能直接信任必须在沙箱里执行。我这里说的沙箱不只是安全性问题更是稳定性问题大模型生成的代码可能有语法错误、CadQuery API 用错、布尔操作的对象类型不对等等。我设计了一个三步重试循环首轮执行把生成代码直接丢进执行器。成功就立刻导出 STEP 并渲染预览。报错反馈执行失败时把完整报错信息回传给大模型让它对照报错改代码再重试一次。追加示例仍然失败时把“正确的 CadQuery 写法示例”作为 few-shot 附加到对话里再重试一次。三次都不行就放弃并告诉用户“这个描述超出了当前能力范围。”这个循环的收敛能力相当惊人。我实测下来首轮成功率高的时候也只有三成左右但加了两轮重试之后成功率能到八成。靠的就是前面说的“代码可执行、可反馈”这个特性这套路线的系统化改造潜力比另外两条路线大得多。4.4 完整演示一句话生成一个带法兰的圆柱体举一个真实跑通的例子。用户输入一个带法兰的圆柱体圆柱直径 40高 20法兰直径 60厚度 5法兰上均匀分布 6 个直径 8 的孔。系统最终输出的 CadQuery 代码大致长这样import cadquery as cq import math # 法兰盘直径 60厚度 5 flange cq.Workplane(XY).circle(60 / 2).extrude(5) # 法兰上均匀分布 6 个直径 8 的孔孔心圆直径 45 bolt_pts [] for i in range(6): angle math.radians(i * 60) bolt_pts.append((45 / 2 * math.cos(angle), 45 / 2 * math.sin(angle))) flange flange.faces(Z).workplane().pushPoints(bolt_pts).hole(8) # 中心圆柱直径 40总高 20法兰占 5圆柱还需向上拉伸 15 cyl cq.Workplane(XY).workplane(offset5).circle(40 / 2).extrude(15) # 合并主体与法兰 part flange.union(cyl) # 导出 STEP 文件 cq.exporters.export(part, flange_cylinder.step)这里有个细节值得留意孔是在法兰盘实体上先打好的然后才和圆柱做布尔并集。如果把顺序反过来——先合并再打孔——也能得到一样的结果但代码的表达就偏离了“法兰带孔”的制造逻辑后面如果要修改孔距会麻烦很多。执行完在渲染器里拉一下视角就能看到法兰盘上六个孔均匀分布中心圆柱和法兰的衔接很自然。导出的 STEP 文件直接丢给切片软件或 CAM 软件都不会有问题。5. 实测翻车现场五个高频坑和对应的止损方案能跑通只是第一步真正从“能跑通”到“能用”中间全是坑。这章把我实测过程中遇到的高频问题汇总一下每条都附上止损方案都是真金白银踩出来的经验。5.1 单位混用最隐蔽的毫米级灾难Text-to-CAD 最容易翻车的点是单位。用户说“1 寸厚的板”模型可能直接生成数值 1而 CadQuery 里的数字默认是毫米最后导出的实体薄得像纸一样。更隐蔽的是“直径”和“半径”的混淆模型经常把“直径 40”直接写成circle(40)实际应该是circle(20)。这个错误在视觉上几乎看不出来只有量尺寸才会发现。止损方案在系统提示词里强制统一单位、强制区分直径和半径关键词执行后做一次尺寸自动校验——拿文本里的关键尺寸和模型实际测量值比对超差就触发重试。5.2 特征顺序CSG 的布尔运算不是自然而然的直接按照自然语言的顺序去生成代码容易踩特征顺序的坑。比如用户说“先建一块板在板上打孔”模型可能真的就在拉伸之前对平面草图执行打孔操作结果孔跟着主体一起拉伸变成了盲孔而不是通孔。这不是代码语法错而是特征顺序不符合制造逻辑。止损方案在提示词里明确“先创建主体几何再叠加特征”并在代码审阅阶段做静态检查——如果一个 hole 操作之前的实体还只是二维草图就判定异常并重试。这是我从多次翻车里总结出来的规则写成检查规则之后这类问题基本绝迹。5.3 默认尺寸幻觉看似完工的模型其实缺约束大模型的“默认值幻觉”非常普遍。用户只说“底板长 100 宽 50”没说厚度系统生成的代码里可能就写了一个厚度 2。表面看模型完整实际这个尺寸没有任何依据造出来的零件和用户预期完全对不上。止损方案对文本里没提到、但代码里出现的关键尺寸做自动高亮要求模型在注释里写清默认值依据如果完全没有依据就统一规定一套设计默认值比如板材默认 10mm保证行为的确定性和可预期性。宁可让用户觉得“系统太啰嗦”也不能让用户拿到一个凭空生成的零件。5.4 解析器差异与 API 升级环境依赖的暗坑CadQuery 版本之间的 API 有差异大模型训练数据里可能混杂着不同版本的写法。比如旧版本用某个方法拉伸新版本换成了另一个模型生成了只有旧版 API 能跑的代码在你的环境里就会报错。止损方案在提示词里附上当前 CadQuery 版本的常用 API 速查表不给模型自由发挥的空间同时在沙箱执行器里固定依赖版本锁在专用虚拟环境里不随系统升级漂移。这个坑看起来不起眼实际能废掉你一个下午。5.5 复杂曲面的降级表现当前的硬天花板凡是涉及自由曲面的需求——鼠标外壳、饮料瓶身、汽车覆盖件——现有 Text-to-CAD 的代码合成路线都表现得非常挣扎。大模型熟悉的 CAD 特征大多是拉伸、旋转、阵列、倒角这类参数化特征对贝塞尔曲面、扫掠放样这类高级建模方式几乎没有可靠的生成能力。止损方案这类任务直接不接。我现在的策略是如果用户描述里出现“曲面”“流线型”“空气动力学”这类关键词就明确回复“建议使用专业曲面建模工具”不硬生成。诚实地说出能力边界用户反而更信任这个系统。6. 选型边界什么需求适合交给 Text-to-CAD什么需求别碰Text-to-CAD 不是万能钥匙它的适用边界其实很清晰。我把实际使用中总结的“接单原则”整理出来大家可以按这个清单对号入座。6.1 放心交出去的三类任务第一类参数化标准件。法兰、支架、外壳、卡扣这些零件特征明确、参数单调Text-to-CAD 生成效果几乎可以一次成功。第二类概念验证模型。做评审用的示意模型允许一定误差重点在于速度。第三类衍生式变体。在已有模型基础上改尺寸、改孔位本质上就是参数调整恰恰是代码合成路线的看家本领。这三类任务有一个共同特征几何关系是显式的可以表达成“哪些特征 哪些参数 哪些约束”。只要满足这一点Text-to-CAD 的效率优势可以轻松拉到 10 倍以上。6.2 宁可别碰的两类任务第一类精密制造件。需要公差在 0.01mm 以内、有 GDT 标注、有材料工艺考量的零件Text-to-CAD 现在给不了。它生成的是几何描述不是制造意图你拿到之后还得忍着性子自己重新标注反而更费劲。第二类复杂曲面产品。前面已经反复强调了自由曲面是硬天花板除非是宽容度很高的装饰件否则不要拿它冒险。多说一句现在很多企业想直接拿 Text-to-CAD 做生产图纸的前端我认为方向是对的但中间还缺一道专业工艺审查的工序。把系统定位成“草图画师”而不是“设计工程师”两边才不会互相失望。6.3 值得期待的演进方向虽然边界清晰但这个领域的演进速度确实很快。我比较关注的方向有三个一是多模态输入让草图、照片和文本混合描述把“说不清”的部分用“画示意”来弥补二是设计意图推理模型不只是生成几何还能理解“为什么这里要倒角”并主动提出工艺建议三是数据链路打通从现在的一次性模型生成变成和 PDM/PLM 系统连通的在线参数化设计平台。这三个方向一旦成真Text-to-CAD 就不再只是草图画师而是真正进入设计流程的主干道。最后分享一个我自己的体会。Text-to-CAD 刚火起来的时候我也觉得这不过是“大模型加脚本”的玩具组合直到我亲手把那条流水线跑通用一个周末做出了过去要花半天才能建好的零件模型才意识到真正被改变的不是建模速度而是“想法到实体”的距离。对一个脑子里构想还没完全成型的设计者来说最快的验证方式不再是打开软件而是先把话说清楚。这大概也是为什么我越来越愿意相信未来设计师的基本功里“把需求说精确”会比“把鼠标点熟练”更重要。