1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个说法我脑子里蹦出来的画面是对着电脑说一句给我画一个带法兰盘的六角螺栓然后屏幕上就自动长出一个可以导出加工的 3D 模型。这个画面听起来像科幻但它背后指向的需求非常真实——用自然语言直接驱动参数化建模把描述变成几何。传统 CAD 工作流是什么样你得先想清楚尺寸、约束、基准面然后在软件里一步步拉伸、旋转、倒角、打孔。一个熟练的机械工程师画一个中等复杂度的零件半小时到两小时是常态。问题在于很多时候我们脑子里的设计意图是模糊的、口语化的比如一个大概 80 毫米长、能卡住 10 毫米管子的夹子这种描述没法直接喂给 CAD 软件必须先被人翻译成精确的草图约束和特征树。text-to-cad 想干的就是把这层人肉翻译自动化掉。它适合谁我梳理了三类人。第一类是做快速原型的产品经理和工业设计师他们需要在不精通 CAD 的前提下快速把想法变成可视化的三维草模用来跟团队对齐。第二类是需要批量生成标准件的工程师比如一批不同规格的支架、垫片、连接件与其一个个手画不如用文本模板批量生成。第三类是做 AI 应用开发的程序员他们想把大语言模型的理解能力接到几何内核上做一个能对话的建模工具。但这里必须先泼一盆冷水text-to-cad 目前不是一个成熟到可以替代 CAD 工程师的技术。它更像是一个意图到初稿的加速器。你给它一句描述它给你一个能看、能改、能继续加工的起点而不是一个可以直接上机床的成品。理解这个定位后面的所有技术选型和踩坑才有意义。我见过太多人一上来就期待全自动出图结果在几何精度和约束完整性上撞得头破血流。所以这篇文章我想聊的不是text-to-cad 有多神而是一个从业者如果要自己搭一套 text-to-cad 的流程到底该怎么拆解问题、选什么工具、哪些环节最容易翻车。核心链路其实就三段自然语言理解、参数化几何生成、模型校验与导出。每一段都有它自己的坑我们一段段来。2. 拆解 text-to-cad 的三段式链路语言、几何、校验2.1 第一段把口语描述解析成结构化参数大语言模型在这里的角色不是画图而是翻译。你输入一个长 100、宽 50、厚 5 毫米的矩形板四角各有一个直径 6 毫米的圆孔孔中心距边缘 10 毫米模型要输出的不是几何而是一段结构化的参数比如 JSON{ type: plate, length: 100, width: 50, thickness: 5, holes: [ {diameter: 6, position: [10, 10]}, {diameter: 6, position: [90, 10]}, {diameter: 6, position: [10, 40]}, {diameter: 6, position: [90, 40]} ] }这一步的关键在于约束的显式化。人类说四角各有一个孔隐含了对称和等距的约束但机器必须把这些约束写死。我实测下来直接用大模型输出几何代码比如 CadQuery 或 OpenSCAD 脚本比输出纯 JSON 更实用因为代码本身就能表达约束和参数关系而且可以直接执行验证。这里有个经验不要让模型自由发挥单位。我踩过的坑是模型有时候把厚 5理解成 5 厘米有时候理解成 5 毫米导致生成的模型尺寸差十倍。解决办法是在系统提示里强制规定所有长度单位默认为毫米除非用户明确指定其他单位并且在输出结构里带上单位字段做二次校验。2.2 第二段参数化几何生成选对内核少走一半弯路几何生成这块市面上的方案大致分三档我做了个对比表方便你按需求选方案代表工具优点缺点适合场景脚本化建模OpenSCAD、CadQuery纯代码、易被 LLM 生成、可版本控制不支持复杂曲面、渲染弱结构件、标准件、教学参数化内核FreeCAD 脚本接口、build123d支持 B-rep、精度高、可导出 STEP学习曲线陡、依赖重工程件、需后续加工网格生成Blender 脚本、trimesh渲染好看、生态丰富非精确几何、不适合加工视觉展示、游戏资产我的建议很直接如果你的目标是能继续在 CAD 里编辑、能导出 STEP 去加工选 build123d 或 CadQuery 这类基于 OpenCASCADE 内核的方案如果只是要个好看的模型做展示Blender 脚本更省事。OpenSCAD 介于两者之间语法最简单LLM 生成准确率最高但不支持真正的曲面和圆角过渡做复杂件会很难受。为什么强调LLM 生成准确率因为大模型对 OpenSCAD 的语法熟悉度明显高于 build123d前者是声明式的、结构简单后者是 Python 面向对象、API 复杂。我做过小样本测试同样一句描述OpenSCAD 代码一次跑通的比例大概七成build123d 只有四成左右剩下的需要人工修。这个差异直接决定了你的自动化流程能不能跑起来。2.3 第三段校验与导出最容易被忽视却最致命模型生成出来不等于能用。我见过生成的模型有自相交的面、有零厚度的壁、有孔打穿到不该打穿的地方。这些在屏幕上可能看不出来但一导出 STEP 或者送去切片就会报错。所以校验环节必须做三件事几何有效性检查、尺寸回读、可视化预览。几何有效性检查可以用内核自带的isValid()方法OpenCASCADE 系的内核都提供。尺寸回读是把生成模型的包围盒尺寸读出来跟原始参数对比偏差超过阈值就报警。可视化预览则是把模型渲染成图片让用户或下游流程能肉眼确认。这三步里尺寸回读是最容易被跳过但最救命的——它能抓住单位错误、参数解析错误这类低级但高频的问题。3. 用大模型生成建模脚本的提示词工程实战3.1 系统提示词怎么写才不翻车提示词是 text-to-cad 的命门。我试过十几种写法最后稳定下来的结构是这样的角色定义 输出格式约束 单位约定 安全边界 示例。角色定义让模型知道自己是参数化建模助手输出格式约束强制它只输出代码不输出解释单位约定统一毫米安全边界规定如果描述不完整使用合理默认值并在注释里标注。一个我常用的系统提示词骨架长这样你是一个参数化建模助手使用 OpenSCAD 语法。 规则 1. 只输出可执行的 OpenSCAD 代码不要输出任何解释文字。 2. 所有尺寸单位为毫米。 3. 如果用户描述缺少必要尺寸使用工程常识默认值并在代码注释中标注 [assumed]。 4. 代码开头用变量定义所有关键尺寸方便后续修改。 5. 不要使用 $fn 以外的特殊变量$fn 统一设为 64 保证圆滑度。这里每条规则都是踩坑换来的。比如代码开头用变量定义尺寸是因为模型经常把数字硬编码在几何调用里用户想改一个尺寸得满代码找。$fn 统一设为 64是因为默认的圆有时候只有 8 个面看起来像多边形用户会以为生成错了。3.2 少样本示例比长篇规则更管用大模型对示例的敏感度远高于规则。与其写五百字规则不如给两三个高质量示例。我一般会放一个简单件带孔板和一个稍复杂件L 型支架带加强筋的输入输出对。示例的作用是锚定风格让模型知道你要的代码长什么样、注释怎么写、变量怎么命名。但示例不能太多超过五个反而会让模型过度模仿示例结构遇到新类型零件时不会变通。我一般控制在两到三个覆盖板类和支架类两种最常见形态就够了。3.3 处理模糊描述默认值策略与追问机制用户说做个盒子这信息量几乎为零。这时候有两条路一是用默认值直接生成二是追问。我的做法是能默认就默认但把假设显式标注出来。比如盒子默认生成 100×100×50 的开口方盒壁厚 3 毫米代码注释里写清楚每个假设。这样用户看到模型后能立刻判断这不是我要的然后补充描述重新生成比来回追问效率高。追问机制只在关键参数缺失且无法合理默认时启用比如做一个能装下 X 的盒子——X 的尺寸未知这时候必须问。判断标准很简单这个参数错了会不会导致整个模型报废。会就问不会就默认。4. 几何内核选型OpenSCAD、CadQuery 还是 build123d4.1 三个内核的真实差异在哪OpenSCAD 是声明式的你描述结果是什么它自己算怎么实现。CadQuery 和 build123d 是命令式的你描述怎么做一步步构建。这个差异决定了 LLM 生成代码的难度声明式代码结构简单、嵌套少模型容易一次写对命令式代码有状态、有顺序依赖模型容易漏步骤或顺序错乱。但声明式的代价是能力受限。OpenSCAD 的布尔运算在复杂模型上容易产生退化面圆角fillet和倒角chamfer支持很弱做机械件时经常卡住。CadQuery 基于 OpenCASCADE能处理真正的 B-rep 几何圆角、抽壳、放样都支持导出的 STEP 文件能被主流 CAD 软件无损打开。build123d 是 CadQuery 的现代化重写API 更 Pythonic用上下文管理器组织代码可读性更好。但它的社区资料比 CadQuery 少模型对它的熟悉度也低。我目前的建议是追求生成成功率用 OpenSCAD追求几何质量用 CadQuery追求代码优雅用 build123d。三者不冲突可以在同一个系统里按零件复杂度路由。4.2 什么零件该走哪条路我总结了一个简单的路由规则。规则几何体板、盒、圆柱、简单支架走 OpenSCAD生成快、成功率高。带曲面或复杂过渡的零件手柄、外壳、流线型结构走 CadQuery因为 OpenSCAD 做不出来。需要参数化族、批量生成的零件走 build123d它的类封装更适合做模板。这个路由可以由一个前置分类器完成也可以让大模型在解析阶段就判断零件类型并选择内核。我倾向于让模型判断因为它在理解描述时已经掌握了零件特征顺手输出一个kernel字段成本很低。4.3 内核切换的成本与收益切换内核不是免费的。不同内核的代码风格、API、错误处理都不一样你的提示词、示例、校验逻辑都要跟着改。所以不要为了技术先进频繁切换而是先跑通一条链路再按实际失败案例决定要不要引入第二个内核。我最初只用 OpenSCAD跑了两个月发现曲面件全部失败才引入 CadQuery 做补充这个节奏是合理的。5. 实测中最容易翻车的五个环节5.1 单位与坐标系混乱这是最高频的问题。模型有时候把 Z 轴当高度有时候当深度有时候原点在角落有时候在中心。结果是生成的模型位置飘忽多个零件装配时对不上。解决办法是在系统提示里强制约定坐标系原点在零件包围盒中心Z 轴向上单位毫米。所有生成的代码都必须遵守校验环节再读一次包围盒确认。5.2 布尔运算产生的退化几何OpenSCAD 做差集运算时如果两个面恰好共面会产生零厚度的面导出时直接报错。这个坑非常隐蔽因为屏幕上看起来完全正常。我的应对是在布尔运算前给一个微小的偏移量比如 0.001 毫米让面不共面。这个技巧在机械建模里是老生常谈但 LLM 生成的代码不会自动加需要你在提示词里明确要求。5.3 参数传递的隐式依赖用户改了一个尺寸结果另一个尺寸跟着变了因为代码里两个地方用了同一个变量但语义不同。这种隐式耦合在 LLM 生成的代码里很常见因为它倾向于复用变量名省事。解决办法是要求每个独立尺寸用独立变量命名带语义前缀比如plate_length、hole_diameter不要用a、b、x这种。5.4 圆角与倒角的顺序陷阱在 CadQuery 里圆角必须在正确的边上做而且顺序会影响结果。先倒角再打孔和先打孔再倒角结果可能完全不同。LLM 经常搞错顺序导致圆角失败或者作用在错误的边上。我的经验是把圆角放在最后做并且明确指定边的选择器不要用所有边这种模糊表达。5.5 导出格式的兼容性STL 适合 3D 打印STEP 适合 CAD 编辑OBJ 适合渲染。选错格式会导致下游流程失败。更麻烦的是有些内核导出的 STEP 在特定 CAD 软件里会丢失颜色或装配信息。我的做法是默认导出 STEP 和 STL 两份STEP 给工程用STL 给预览和打印用用户按需取。6. 把 text-to-cad 接进真实工作流的几种姿势6.1 作为独立小工具命令行 网页双入口最简单的落地形态是一个命令行工具输入描述输出模型文件。再套一个网页界面左边输入文字右边实时预览改一句重新生成。这种形态适合个人和小团队开发成本低一周能出原型。技术栈上后端用 Python 调内核前端用 three.js 做预览中间用 WebSocket 推生成进度。6.2 作为 CAD 软件的插件如果你团队重度依赖某个 CAD 软件可以把 text-to-cad 做成插件在软件内部调用。好处是生成的模型直接进当前工程不用来回导入导出。难点是插件开发要适配软件的 API而且大模型调用要走网络有延迟。我的建议是先做外部工具验证价值再考虑插件化不要一上来就啃插件开发。6.3 作为批量生成流水线的一环这是我觉得最有价值的场景。比如你要生成一百个不同规格的支架把规格表读进来每行拼成一句描述批量调用 text-to-cad输出一百个模型文件。这种场景下稳定性比单次质量更重要所以要用最简单的内核OpenSCAD、最严格的提示词、最完善的校验确保批量跑不中断。7. 精度、约束与可制造性text-to-cad 的边界在哪7.1 它能做到什么精度参数化生成的模型尺寸精度取决于内核OpenCASCADE 系的精度可以到微米级完全够工程用。但精度不等于正确。模型可能尺寸精确但结构错误比如孔打在了错误的位置。所以精度是内核保证的正确性是校验保证的两者不能混为一谈。7.2 约束完整性为什么难保证真正的工程模型不只是几何还有约束关系这个孔必须和那个槽同心这个面必须和那个面平行。LLM 生成的代码通常只表达几何不表达约束。这意味着你改一个尺寸相关特征不会自动跟着更新得手动改。这是 text-to-cad 目前最大的短板也是它无法替代参数化 CAD 的根本原因。7.3 可制造性检查该放在哪一层可制造性壁厚是否够、是否有倒扣、是否超出加工范围不应该由 text-to-cad 负责而应该由下游的专门工具做。text-to-cad 的职责边界是生成符合描述的几何制造性检查是另一个专业领域。把这两件事混在一起会让系统复杂度爆炸。我的做法是生成后接一个独立的检查模块用规则引擎做基础校验复杂的交给专业软件。8. 我踩过的坑和几条实在的经验说几个具体的。第一不要相信模型输出的注释。它经常在注释里写直径 6 毫米实际代码里写的是 8。注释是给人看的代码才是真的校验必须读代码不读注释。第二生成失败时先看代码再看提示词。大部分失败是代码语法或 API 用错不是理解错改提示词没用得改示例或加约束。第三保留每次生成的输入输出对攒够几百条后你会发现失败模式高度集中针对性优化比盲目调提示词有效得多。还有一个反直觉的体会限制模型的自由度反而提升质量。一开始我让模型自由选择建模方式结果五花八门、难以校验。后来我强制它只能用几种预定义的零件模板板、盒、圆柱、支架质量立刻稳定了。这跟软件工程里约定优于配置是一个道理约束不是限制是让系统可预测。最后分享一个实用技巧给生成的模型自动配一张三视图截图。用户看文字描述和代码都没感觉看三视图立刻能判断对不对。这个功能实现成本很低用内核的投影功能加个渲染就行但对用户体验的提升是巨大的。我自己用下来加了三视图之后返工率降了差不多一半因为错误在第一时间就被肉眼抓住了。