上周一个做非标机械的朋友给我发来一段话说他用一句“做一个带四个安装孔的方形法兰盘外径60内径25厚度8”就让电脑自动生成了一个可编辑的三维模型。这不是什么科幻桥段就是当下很热的 text-to-cad 方向。所谓 text-to-cad是指用自然语言描述直接驱动 CAD 建模把“脑子里想的形状”翻译成“软件里能用的实体”核心价值是替设计师省掉从构思到成图之间最枯燥的那一段操作时间。适合做机械设计、3D 打印、工艺验证、参数化建模的人参考。我过去半年一直在折腾这个方向从最初拿大模型 API 硬套到后来自己搭了一套“语言解析→参数校验→程序化建模→有效性检测”的完整流程踩了不少坑也积累了一些真正可复用的经验。这篇文章就围绕 text-to-cad 这个主题把整体设计思路、工具选型逻辑、实操细节和典型问题都拆开讲一遍。不会只停留在“调用 API 生成一段代码”这种入门层面更多是聊聊怎么让它从“能跑”变成“能用”。1. 内容整体设计与思路拆解1.1 为什么是“文本→代码→模型”而不是“文本→网格”刚开始接触 text-to-cad 时很多人第一反应是直接用大模型生成一个三维模型文件不就好了但真上手就会发现这条路走不通。大模型本质上是概率模型擅长生成 token 序列要让它在一次推理里输出一个拓扑正确、流形封闭、尺寸精确的 STEP 或 IGES 文件几乎是不可能的。就算强行生成了网格文件那种模型进了 CAM 软件加工路径计算都会出问题进了装配体配合面、基准面全部丢失等于废品。所以现在主流且工程上可行的路线是“文本→程序化建模代码→CAD 实体”。也就是让模型输出 OpenSCAD、CadQuery 或 FreeCAD 脚本再由 CAD 内核去执行生成实体。这就像你请了一个非常熟悉制图的助手他不用替你握着鼠标画图而是帮你在命令行里写好了脚本你按一下回车图就出来了。程序化建模代码天然是参数化的后续改尺寸、改特征都极其方便而且生成的模型带有完整的几何拓扑信息可以直接用于 CAM、3D 打印切片和装配分析。1.2 系统级思考语言层、参数层、几何层我后来把整个 text-to-cad 项目重新梳理了一遍总结成三层结构每一层做一件事层与层之间通过结构化数据对接互不干扰。语言层负责把用户的中文或英文描述解析成结构化指令比如形状类型、尺寸参数、特征操作参数层负责校验这些参数是否合理像直径不能为负、孔不能打在实体外面、倒角不能大于边长几何层负责把校验过的参数翻译成 CAD 代码并执行最后做一次模型有效性检测。这样分层最大的好处是每一层都能独立替换。大模型迭代很快今天用 A 模型明天换 B 模型只要语言层输出的 JSON 结构不变后面两层完全不用改。CAD 库也一样昨天用 OpenSCAD今天想换 CadQuery几何层只需要重写底部的执行模块语言层和参数层都不受影响。分层设计我强烈建议从第一天就做哪怕是个人项目。别觉得自己只写个脚本不需要架构等你想换模型或者换建模库的时候就知道这个决定有多值钱。2. 核心技术与工具链选型解析2.1 大模型选型零样本能力优先别急着微调text-to-cad 项目里大模型承担的是“自然语言到结构化参数”的翻译工作这个环节用通用大模型基本够用。我用 GPT-4 和 Claude 都做过零样本测试对于常见的几何体描述像“长 40 宽 25 高 10 的长方体”“直径 12 的通孔”“半径 5 的倒角”它们都能准确输出结构化参数。真正复杂的是带有隐含语义的描述比如“做一个适合 M6 螺栓的沉头孔”模型需要知道 M6 对应多大的头径和沉头深度这种就超出纯粹的语言理解范畴需要知识库支持。先不要急着微调模型。微调的成本很高而且通用模型的几何常识已经在基座训练里积累得不错了。更经济的方式是在提示词里注入一份“参数映射表”把常见零件的标准规格写进去比如螺纹孔尺寸表、轴承座尺寸表。实测下来这种知识注入的效果对于中小规模场景已经够用了。等你积累了足够的业务数据再考虑针对特定领域做微调性价比会更高。2.2 CAD 建模库怎么选OpenSCAD、CadQuery 还是 FreeCAD这是整个项目里最关键的技术选型决策。我把主流方案整理成了一个对比表方案编程方式布尔运算支持参数化能力输出格式上手难度适用场景OpenSCAD自有 DSL完善强STL、OFF可转 STEP低快速验证、3D 打印草图CadQueryPython API完善强STEP、STL、SVG、DXF中机械零件、装配体FreeCAD PythonPython API完善强STEP、FCStd中高需要 GUI 反馈的重型建模build123dPython API完善强STEP、STL中CadQuery 的现代替代品我个人推荐 CadQuery。原因有几个第一它是真正的 Python API可以直接嵌入你的 text-to-cad 服务不需要额外启动 GUI 进程第二它的几何内核基于 OpenCASCADE业界老牌内核导出的 STEP 文件在主流 CAD 软件里兼容性非常好第三它的 API 设计比 FreeCAD 的 Python 接口更清爽对于“从一个草图拉伸”“在面上打孔”这类高频操作代码量比 FreeCAD 少一半以上。如果你只需要做 3D 打印快速验证OpenSCAD 也足够但一旦涉及工程图纸和机加工我还是建议直接上 CadQuery。2.3 部署形态本地脚本、HTTP 服务还是 CAD 插件text-to-cad 做成什么形态取决于你准备把它用在什么地方。初期我建议先做成本地脚本输入一句描述文本输出一个 STEP 文件这个闭环跑通最重要。有了一定的稳定性之后再把它包成一个 HTTP 服务前端做个文本框后端异步执行建模任务并返回模型下载链接。第三种形态是插件化把 text-to-cad 集成到 FreeCAD 或 Onshape 这类软件里用户在软件内选中基准面输入文字描述直接生成特征。这种体验最好但开发成本也最高不是第一阶段的合理目标。我自己是把项目做成服务的形式后端 Python CadQuery前端一个极简页面输入描述、点击生成、预览 STEP、下载文件。整个过程大约 3-5 秒。如果对延迟敏感的业务比如在线设计平台需要把这个链路拆成消息队列做异步生成和缓存这块后面在问题排查部分再详细说。3. 实操过程与核心环节实现3.1 环境搭建与最小闭环先把最小可运行环境跑起来这是整个项目的起点。我用的是 Ubuntu Python 3.10核心依赖两个库CadQuery 和 OpenSCAD。CadQuery 负责主链路的建模OpenSCAD 用来做交叉验证和快速三维预览。# 安装 CadQuery pip install cadquery # 安装 OpenSCAD用于 STL 快速预览和交叉验证 sudo apt install openscad # 需要 OpenAI 接口时安装对应 SDK pip install openai装完之后写一个最简单的文本转模型脚本。别急着上大模型先用写死的参数跑通 CadQuery 的建模链路确认环境没问题。比如生成一个带圆角的长方体import cadquery as cq result ( cq.Workplane(XY) .box(40, 25, 10) .edges(|Z) .fillet(5) ) cq.exporters.export(result, demo.step)这个脚本能跑出 STEP 文件说明链路是通的。之后再把“写死的参数”替换成“大模型输出的参数”就算是真正的 text-to-cad 最小闭环了。3.2 文本指令的拆解与参数映射最核心的部分来了如何让大模型把一句自然语言描述变成结构化的建模指令。我的做法是要求模型输出标准 JSON而不是直接输出 CadQuery 代码。原因很简单JSON 便于解析、校验、容错代码容易出现语法错误而且难以在不执行的情况下做参数检查。我设计了一个统一的指令结构{ type: box, parameters: { width: 40, length: 25, height: 10 }, operations: [ {op: fillet, target: |Z, radius: 5}, {op: hole, target: top_face, diameter: 8, through: true} ] }这里 type 决定主体用什么特征创建parameters 是主体尺寸operations 是按顺序执行的特征操作。大模型只需要做好两件事识别描述中的实体类型和尺寸数值然后映射到这个结构里。识别实体靠的是模型的语言理解能力这个现代大模型已经做得很好映射到结构则是靠提示词的规范性约束。为帮助大家理解我整理了一份实体抽取的对照表这是我在实际项目里反复打磨过的直接用会很顺手常见中文描述实体类型关键参数默认值长方体 / 矩形块boxwidth, length, heightwidth40, length25, height10圆柱体 / 圆棒cylinderdiameter, heightdiameter20, height30圆孔 / 通孔holediameter, depth, positiondiameter6, throughTrue法兰盘flangeouter_diameter, inner_diameter, thickness, hole_countouter60, inner25, thick8, hole_count4安装板 / 底板base_platewidth, length, height, hole_positionsheight5, holes4拿法兰盘举例描述是“做一个带四个安装孔的方形法兰盘”模型先识别出 typeflange再识别出 hole_count4剩下没提到的参数全部用默认值覆盖。这一步非常关键因为真实对话中用户很少把参数说全缺省值是保证系统不报错的第一道防线。3.3 提示词模板的工程化设计text-to-cad 的成败有 70% 取决于提示词设计。我用了很长时间才打磨出一个相对稳定的模板核心思路是“先约束角色再给出格式最后强调校验规则”。你是 CAD 建模参数抽取引擎。你的任务是把用户的三维建模描述转换为结构化 JSON 指令不要输出任何其他内容。 约束 1. 所有长度单位为毫米默认值无小数取整数。 2. 识别用户描述中的实体类型和参数缺失参数使用默认值。 3. 尺寸范围限制宽度/长度/高度/直径必须在 1-500 之间超出范围设为边界值。 4. 布尔操作顺序固定先主体再打孔最后倒角/倒圆。 输出格式严格 JSON { type: box | cylinder | flange | base_plate, parameters: {...}, operations: [...] } 用户描述{这里插入用户的自然语言描述}这个模板能用的关键就是每一条约束都有明确目的。要求所有长度单位为毫米是为了避免模型在英寸和毫米之间摇摆尺寸范围限制是给后端的参数校验留缓冲固定操作顺序是因为 CAD 内核执行布尔操作时顺序不同结果天差地别先打孔再倒角和先倒角再打孔产生的几何体纹理完全不一样。另外我强烈建议在提示词里给一个“坏例子”和一个“好例子”。大模型特别吃这一套你只给规范它容易自由发挥给一组对比样本它就知道界限在哪了。我用的是“坏例子长方体长 40得到了一个圆形空腔 —— 这会让后端报错。好例子长方体宽 40 长 25 高 10得到了完整的 box JSON 结构。”3.4 模型有效性校验从“能生成”到“能使用”生成 STEP 文件不代表任务完成最关键的一步是校验模型是否物理合理。我碰到过不少模型从屏幕上看是那么回事但一检查体积是负的或者面根本不封闭这种模型交给加工厂就是废料。校验逻辑我分了三层参数层校验、几何层校验、制造可行性校验。参数层校验最简单就是检查大模型输出的参数是否在合理范围内比如螺栓孔直径不能是 1000mm壁厚不能是 0.001mm。这一层用简单的字典约束就能做掉我在代码里实现了一个参数裁剪函数PARAM_LIMITS { width: (1, 500), length: (1, 500), height: (1, 500), diameter: (1, 200), radius: (0.5, 50), thickness: (0.5, 100), } def sanitize_params(params): sanitized {} for key, value in params.items(): if key in PARAM_LIMITS: low, high PARAM_LIMITS[key] sanitized[key] max(low, min(high, float(value))) else: sanitized[key] value return sanitized几何层校验就复杂了需要直接检查模型的特征。CadQuery 底层是 OpenCASCADE我可以调用它的几何内核来做校验。检查实体的体积是否大于 0边界框尺寸是否合理实体是否封闭。如果模型有孤立面或非流形边基本可以判定布尔运算出了问题。import math def validate_shape(shape): volume shape.Volume() if volume 0: return False, f体积异常: {volume} bbox shape.BoundingBox() for dim in [bbox.xlen, bbox.ylen, bbox.zlen]: if dim 0.1 or dim 1000: return False, f边界尺寸异常: {dim} return True, ok制造可行性校验这一步可以放到后期做主要看最小壁厚、最小孔径是否符合加工工艺。3D 打印和 CNC 加工对最小特征尺寸要求不一样这一层需要按目标工艺配置阈值。我自己做手板验证时会把最小壁厚设为 1mm小于这个值就报警因为打印出来容易断。4. 常见问题与排查技巧实录4.1 尺寸幻觉与参数越界大模型在数字上经常“一本正经地胡说八道”。我遇到过描述说“壁厚尽量薄”模型直接输出 0.01mm 的壁厚这显然不是设计的本意。参数越界不解决后面的建模一定报错或者生成废件。应对方法就是上面提到的 sanitize 函数把所有输出参数都钳制在物理合理的区间里。同时在语言层就做好提醒在提示词里显式声明“厚度小于 0.5mm 请输出警告”这样模型自己会先去反思再输出。还有一个实操细节让模型在 JSON 里附带一个 confidence 字段表示它对参数理解的置信度。低于 0.6 的自动进入人工确认流程。这个字段特别有用能帮你在早期发现模型的“硬编答案”行为。4.2 中文描述里的模糊语义怎么处理中文描述天然有歧义。“大一点”“厚一点”“稍微偏右”这类说法没有明确数值模型再强也猜不准。我一开始图省事让模型自己猜结果同一个描述每次生成的尺寸都不一样。后来我在语言层加了一个模糊语义映射模块专门处理这类词。逻辑是如果你检测到“一点”按默认值的 10% 做增量“稍微”按 5%“很多”按 30%。这些阈值可以按场景微调但有一个固定的规则比每次都让模型自由发挥要稳定得多。另一个常见坑是单位。很多人说“一寸”其实想说的是 25.4mm说“一公分”其实是 10mm。建议在提示词最后加一句“如描述中使用非毫米单位请在 JSON 中额外标注 original_unit 字段”这样既可以保留用户原始意图又能在参数层统一转换。4.3 布尔运算失败与模型不封闭这是最让人头疼的问题。表现为明明输入参数都对CadQuery 在执行 fillet 或 subtract 时突然报错“BRep_API: command not done”。这种错误大多原因是参数在几何上不合法比如倒圆角半径大于边高或者切割圆柱与被切主体不相交。排查思路有个固定路径先降级操作比如把 fillet 半径减半再检查相交性用 BoundingBox 判断两个特征是否重叠最后实在不行就跳过这个操作返回一个带警告的模型。做这种 fallback 逻辑时一定要给每个操作加上独立的 try-except否则一个特征失败整条链路都崩掉体验非常差。还有一类隐藏问题CadQuery 的 fillet 对多条边同时操作时如果其中一条边不符合圆角条件整个命令失败。我的处理是先把边按类型分组逐个边独立 fillet每一次失败就跳过这样至少能保留一部分圆角效果比整单失败强太多了。4.4 上下文窗口和长指令处理当你描述一个多特征的复杂零件一个 prompt 塞进去大模型很容易顾此失彼。我测试过描述“底座长 60 宽 40 高 8顶部四个角各有一个 M4 沉孔中间开一个 20 的圆槽侧面有一个 15 的方形凸台”这种多特征描述直接生成的结果经常缺特征。后来我换成了“分步生成法”第一步让模型抽取出特征清单列成 JSON 数组第二步逐个特征生成对应的建模代码片段第三步在 CadQuery 里按顺序组合。三步走看起来慢但成功率从不到一半提到了 85% 以上。结合我的实践给出一份应对不同类型的排查速查表遇到问题可以直接对照处理现象可能原因一级排查二级处理模型尺寸离谱大模型幻觉参数是否超出合理范围sanitize 钳制 置信度检查布尔运算报错特征几何不合法倒角半径 边长 / 切割不重合降级半径 独立 try-except输出 JSON 解析失败模型格式不服从正则提取 JSON 片段提示词强制输出 重试一次轴定位错误基准面理解错误检查 Workplane 方向提示词明确坐标系规则中文描述带模糊词语义歧义是否有“一点/稍微”模糊语义映射模块按比例展开重复生成消息API 超时或误判检查接口返回幂等键 消息队列去重4.5 性能问题从“生成慢”到“能用”的距离text-to-cad 的性能瓶颈通常不在大模型而在 CAD 内核执行复杂布尔运算时需要的时间。一个大模型 API 调用可能 1 秒就返回了 JSON但 CadQuery 做一个多特征模型的 fillet 和布尔减除可能要花 5-10 秒。对交互式体验来说这个延迟需要后端异步化处理。我后来把生成任务丢进 Redis 队列前端通过 WebSocket 订阅任务状态生成完拉取模型文件体验顺畅了很多。还有一个偏方对高频的简单模型比如长方体、圆柱、法兰盘加一层结果缓存同参数同操作的模型直接复用别每次都傻乎乎地重新建模。5. 把 text-to-cad 放到真实的项目流程里这个方向有不少人问过我是不是模型再强一点就能全面替代工程师了。我的看法是把 text-to-cad 放到真实的项目流程里短期目标不是替代人而是把重复性、标准化的建模任务自动化。比如非标自动化里常见的法兰盘、轴承座、连接板、固定支架这类零件结构差异不大无非是尺寸和孔位变化用 text-to-cad 生成初版模型工程师只做微调和验证效率提升非常明显。我现在自己的流程是设计阶段手工建模为主参数化标准件直接 text-to-cad 生成3D 打印验证用 text-to-cad 生成快速模型配合切片软件直接打印外发加工前用生成的 STEP 文件进行强度和装配检查。这样跑下来标准件建模时间基本缩短到原来的五分之一。我个人在实际操作中的体会是这个方向真正的价值不在“一句话生成完整整机”那太遥远而是在特定零件类型的小闭环里把建模效率拉到极致。建议从自己最常画的 5-10 种零件开始为每种零件准备模板提示词、参数化建模函数和校验规则先把闭环跑通再慢慢扩充零件库。等你积累了足够多的零件模板会发现 text-to-cad 从一个“玩具”变成了真正的生产力工具。大家如果在自己的建模语言和提示词设计上遇到了具体的报错或者离奇结果欢迎拿来一起讨论这个方向的细节问题多到一个人根本踩不完。