1. 从一段话到三维模型text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个词很多人会下意识地把它理解成用嘴画图——说一句话软件自动帮你把零件画出来。这个理解方向没错但真正落地的时候它要解决的问题比画图本身要复杂得多。传统 CAD 工作流的起点是人的手打开软件、建草图、约束尺寸、拉伸、倒角、装配。一个中等复杂度的机械零件熟练工程师也要花上几十分钟到几个小时。而 text-to-cad 想做的事情是把这段手工劳动压缩成一段自然语言描述让程序去生成几何体再导出成 STEP、GLB、STL 这类通用格式直接进入下游的仿真、渲染、3D 打印或者装配流程。我接触这个方向是从一个很具体的痛点开始的手头有一批标准件和简单结构件形状高度重复只是尺寸和少量特征在变。每次改一个参数就要重新走一遍建模流程效率低得让人抓狂。后来我尝试用脚本化的方式批量生成再往后就自然走到了能不能用自然语言直接驱动这一步。text-to-cad 的核心价值就在这里——它不是要取代工程师而是把那些规则明确、重复度高、参数化程度强的建模任务自动化掉。需要先厘清一个概念text-to-cad 不是一个单一软件而是一类技术方案的统称。它的实现路径差异极大从最简单的模板 参数替换到基于大模型的代码生成让模型写 OpenSCAD 或 CadQuery 脚本再到端到端的几何生成网络跨度非常大。理解这一点很关键因为不同路径的适用场景、精度上限和落地难度完全不是一回事。下面我会把这几条路线拆开讲重点放在普通开发者和小团队真正能跑起来的方案上。这篇文章适合三类人看一是做机械设计或工业设计、想提升重复建模效率的工程师二是做 3D 打印、需要快速把想法变成可打印模型的创客三是做 AI 应用开发、想把自然语言和几何生成打通的技术人。不管你是哪一类读完应该都能拿到一套可以动手复现的思路。2. 三条主流技术路线模板参数化、代码生成、端到端生成2.1 模板参数化最土但最稳的路子模板参数化的思路非常朴素预先做好一个参数化模型把可变部分抽成参数然后用自然语言解析出参数值填进去重新生成。比如一个法兰盘参数就是外径、内径、螺栓孔数量、孔位圆直径、厚度。用户说外径 120、内径 60、8 个 M8 螺栓孔、厚 15程序解析出这几个数调用 CAD 的 API 重新建模。这条路子的优点是结果完全可控。因为几何逻辑是你自己写的生成出来的模型一定符合工程规范不会出现莫名其妙的曲面或者自交。缺点也很明显只能覆盖你预先定义好的模板遇到模板外的形状就无能为力。它本质上不是生成而是参数填充。我实测下来这条路子最适合的场景是标准件库和企业内部通用件。一个做非标设备的团队常用的连接件、支架、法兰可能就几十种把这些做成参数化模板配上自然语言解析效率提升非常直接。而且因为几何可控导出的 STEP 拿去装配、出图都不会出问题。2.2 代码生成让大模型写 CAD 脚本这是目前最热、也最有想象空间的一条路。核心思路是大语言模型不直接生成几何而是生成描述几何的代码比如 OpenSCAD、CadQuery、build123d 这些基于代码的 CAD 工具然后由这些工具去执行代码、生成模型、导出 STEP 或 STL。为什么绕一层代码因为直接让模型输出顶点坐标或者网格精度和可解释性都很差。而代码是结构化的、可读的、可修改的。模型写出来的 CadQuery 脚本你能看懂每一行在干什么改一个数字就能调整尺寸。这比一个黑盒的网格文件友好太多。举个具体的例子。你给模型这样一段描述生成一个长 80、宽 40、高 20 的长方体四个角做 R5 圆角顶面中心挖一个直径 10、深 8 的圆孔。模型会输出类似这样的 CadQuery 代码import cadquery as cq result ( cq.Workplane(XY) .box(80, 40, 20) .edges(|Z).fillet(5) .faces(Z).workplane() .hole(10, 8) ) cq.exporters.export(result, part.step)这段代码跑出来就是一个精确的实体模型导出 STEP 之后可以直接进装配。整个过程不需要你手动建模只需要检查代码逻辑对不对。这条路子的关键难点在于模型对几何语义的理解。大模型对圆角倒角抽壳阵列这些工程术语的理解程度直接决定了生成质量。实测中我发现对于简单到中等复杂度的零件主流大模型的表现已经相当可用但一旦涉及复杂的曲面、扫掠、放样出错率就明显上升。所以现阶段更现实的用法是模型生成初稿 人工修正而不是完全放手。2.3 端到端生成直接从文本到网格端到端生成指的是模型直接输出三维表示比如点云、体素、隐式场或者网格。这条路在学术上很热闹但在工程落地里目前还比较边缘。原因是生成的网格往往拓扑质量差、尺寸不精确、无法参数化编辑。你拿到一个 STL想改个孔径都无从下手因为它就是一坨三角面片。不过它在某些场景下有价值比如概念设计阶段的快速可视化、游戏资产的批量生成。这些场景对精度要求不高对快和多样要求高。但如果你的目标是出工程图、做装配、上机床端到端生成目前还撑不起来。把三条路线放在一起对比会更清楚各自的定位路线精度可编辑性覆盖范围落地难度典型场景模板参数化极高强窄低标准件、通用件代码生成高强中到宽中结构件、参数化零件端到端生成低到中弱宽高概念设计、可视化我的建议是先用模板参数化把高频需求吃掉再用代码生成覆盖长尾。端到端生成可以关注但别急着押注。3. 格式选择STEP、GLB、STL 各自的地盘text-to-cad 生成出来的模型最终要落到某个文件格式上。STEP、GLB、STL 这三个是最常被提到的但它们服务的目标完全不同选错了会白白浪费很多时间。3.1 STEP工程领域的通用语言STEP.step / .stp是基于边界表示B-rep的实体模型格式它记录的是精确的几何定义——面、边、顶点、曲面方程。这意味着它是参数化、可编辑、可精确测量的。你把它导入任何主流 CAD 软件都能继续做特征操作、出工程图、做装配约束。只要你的下游是机械设计、CNC 加工、钣金、装配STEP 就是首选。text-to-cad 用代码生成路线时CadQuery 和 build123d 都能直接导出 STEP这是它们相比网格生成方案最大的优势。有一个坑要注意STEP 有多个版本AP203、AP214、AP242不同软件对版本的兼容性不一样。AP242 支持颜色和 PMI产品制造信息但老软件可能读不了。我一般导出时优先选 AP214兼容性和信息量比较平衡。3.2 STL3D 打印的事实标准STL 只记录三角面片没有单位、没有颜色、没有拓扑关系就是一堆三角形。它的优点是几乎所有 3D 打印切片软件都支持缺点是精度靠面片密度堆文件容易大而且不可参数化编辑。从 text-to-cad 生成 STL 时最关键的一个参数是网格精度。精度太低曲面变成多边形精度太高文件爆炸。我通常的做法是先用中等精度预览确认形状没问题再针对打印需求调高精度导出。对于 FDM 打印弦高公差设在 0.05mm 左右通常够用对于光固化可以更细一些。3.3 GLB可视化与 Web 展示的利器GLB 是 glTF 的二进制版本专为实时渲染和网络传输设计。它体积小、加载快、支持材质和动画是 Web 3D、AR/VR、产品展示的首选。但它不是工程格式没有精确的几何定义不能拿去做加工。如果你的 text-to-cad 目标是做一个在线配置器让用户在网页上实时看到模型变化那 GLB 就是对的。生成流程通常是先用 CAD 内核生成精确模型再转成网格最后导出 GLB。把三者的关系理清楚STEP 是设计态STL 是制造态GLB 是展示态。一个完整的 text-to-cad 流水线往往需要同时支持这三种导出根据用户的下游需求切换。4. 搭一条能跑通的 text-to-cad 流水线4.1 环境准备Python 生态是当前最优解要自己搭一条 text-to-cad 流水线Python 生态目前是最现实的选择。核心依赖是 CadQuery 或 build123d它们底层都基于 OpenCASCADEOCCT这个工业级几何内核能生成精确的 B-rep 实体。安装 CadQuery 最省事的方式是用 condaconda create -n text2cad python3.11 conda activate text2cad conda install -c conda-forge cadquery为什么推荐 conda 而不是 pip因为 CadQuery 依赖 OCCT 的二进制库pip 安装经常在编译环节卡住conda 有预编译包省心很多。这是我踩过好几次坑之后总结出来的。如果你要用 build123d它和 CadQuery 可以共存安装方式类似。build123d 的 API 更接近现代 Python 风格写起来更直观但生态和文档还不如 CadQuery 成熟。新手我建议先从 CadQuery 入手。4.2 把自然语言翻译成建模代码流水线的核心环节是文本 → 代码。这一步用大模型来做关键在于提示词的设计。我试过多轮总结出一个比较稳的提示词结构明确告诉模型输出哪种 CAD 库的代码CadQuery 还是 build123d给出目标格式STEP / STL / GLB要求代码包含单位说明毫米要求代码可直接执行不要伪代码给出一个完整的示例让模型模仿风格一个实际用的提示词模板大概是这样你是一个 CAD 代码生成助手。请根据用户的自然语言描述 生成可执行的 CadQuery Python 代码。 要求 1. 所有尺寸单位为毫米 2. 代码必须能直接运行不要伪代码 3. 最后导出为 STEP 文件 4. 变量命名清晰关键步骤加注释 示例 用户生成一个 50x30x10 的板四角 R3 圆角 代码 import cadquery as cq result cq.Workplane(XY).box(50, 30, 10).edges(|Z).fillet(3) cq.exporters.export(result, plate.step) 现在请处理 用户{用户输入}实测下来加了示例之后模型输出的代码可执行率明显提升。没有示例的时候模型经常写出一些看起来对、跑起来报错的 API 调用。4.3 执行与校验别跳过这一步模型生成的代码不能直接信。我的流程里执行和校验是独立的一环。具体做法是把生成的代码放到一个受限的沙箱里执行捕获异常执行成功后检查导出的文件是否存在、体积是否合理再用几何库读回来检查包围盒尺寸是否和描述一致。import cadquery as cq import os def run_and_validate(code_str, expected_bboxNone): local_ns {} try: exec(code_str, local_ns) except Exception as e: return False, f执行失败: {e} # 检查导出文件 step_files [f for f in os.listdir(.) if f.endswith(.step)] if not step_files: return False, 未生成 STEP 文件 # 读回校验尺寸 model cq.importers.importStep(step_files[-1]) bbox model.val().BoundingBox() actual (bbox.xlen, bbox.ylen, bbox.zlen) if expected_bbox: for a, e in zip(actual, expected_bbox): if abs(a - e) 0.5: return False, f尺寸偏差过大: 期望{expected_bbox}, 实际{actual} return True, actual这段校验逻辑看起来简单但能挡掉相当一部分看起来对、实际错的生成结果。尤其是尺寸偏差检查能发现模型把单位搞错比如把毫米当厘米这类隐蔽问题。4.4 导出多格式一次生成多处使用模型生成好之后导出环节要按需切换。STEP 直接导出STL 需要先做网格化控制精度GLB 则需要经过网格转换。CadQuery 支持直接导出 STLGLB 一般要借助 trimesh 之类的库中转。import cadquery as cq import trimesh # 导出 STEP cq.exporters.export(result, part.step) # 导出 STL控制精度 cq.exporters.export(result, part.stl, tolerance0.05, angularTolerance0.1) # 导出 GLB先转网格再导出 mesh result.val().tessellate(0.05) # 用 trimesh 组装并导出这里有个经验STL 的 tolerance 参数不要设太小。我见过有人设成 0.001结果一个简单零件导出几百 MB切片软件直接卡死。0.05 到 0.1 之间对大多数场景足够。5. 实测中那些文档不会告诉你的坑5.1 单位问题最常见的隐形错误CAD 里单位搞错是灾难性的。模型生成时如果没明确单位有的库默认毫米有的默认米导出的 STEP 到了下游软件里可能大一千倍或者小一千倍。我的做法是在提示词里强制要求毫米并在校验环节检查包围盒尺寸。只要尺寸对不上立刻打回重生成。5.2 布尔运算失败几何内核的脾气代码生成路线里布尔运算并、交、差是最容易出问题的地方。两个实体如果面重合、边相切布尔运算可能失败或者产生退化几何。这不是代码的错是几何内核的数值精度问题。应对办法有几个一是避免完全重合的面在建模时留一点微小偏移二是把复杂布尔拆成多步逐步验证三是捕获异常后让模型重新生成换一种建模顺序。我在实际项目里布尔失败的重试机制是必备的。5.3 圆角和倒角的顺序陷阱圆角fillet和倒角chamfer对操作顺序非常敏感。先做大圆角再做小特征和反过来做结果可能完全不同甚至后者直接失败。经验法则是先做主体形状再做孔和槽最后做圆角倒角。而且圆角半径不能超过相邻边的最小尺寸否则内核会拒绝执行。5.4 大模型生成的代码需要防呆模型有时候会生成一些危险的代码比如死循环、超大内存分配、文件系统操作。所以执行环境一定要隔离限制执行时间和内存。我用的是子进程 超时 资源限制的组合跑飞了直接杀掉不影响主流程。6. 这套东西真正适合谁用6.1 非标设备与夹具设计非标行业的特点是每个项目都不一样但底层结构高度相似。支架、连接板、定位块这些零件形状逻辑固定只是尺寸和孔位在变。用 text-to-cad 把这些做成参数化生成工程师只需要描述需求模型自动出图省下的时间非常可观。6.2 3D 打印与快速原型做 3D 打印的人经常需要快速验证一个想法。传统流程是打开建模软件、画草图、拉伸、导出一套下来半小时。用 text-to-cad描述一句话几十秒出 STL直接切片打印。对于先打个样看看这种需求效率提升是数量级的。6.3 在线产品配置器电商或者工业品网站上的产品配置器用户选参数、实时看模型背后其实就是 text-to-cad 的思路。用户的选择被翻译成参数驱动模型重新生成再转成 GLB 在网页上渲染。这条路对格式转换和性能优化要求更高但商业价值很直接。6.4 教育和入门对 CAD 初学者来说text-to-cad 是个很好的学习工具。你可以描述一个形状看模型生成的代码理解这个形状在代码层面是怎么构造的。这种描述—代码—几何的对应关系比单纯看教程直观得多。7. 我踩过的几个真实坑和对应解法说几个具体的。第一个坑是中文描述里的尺寸歧义。用户说直径 10 的孔模型有时候理解成半径 10。后来我在提示词里明确要求直径用 D 表示半径用 R 表示并要求代码里注释清楚问题基本解决。第二个坑是导出路径混乱。多个模型连续生成时如果都用默认文件名会互相覆盖。我的做法是每次生成用 UUID 做文件名前缀生成完记录映射关系避免覆盖。第三个坑是STEP 导入下游软件后颜色丢失。这是因为默认导出的是 AP203不带颜色信息。改成 AP214 或者 AP242 就能保留。这个坑很隐蔽因为文件本身没问题只是显示不对。第四个坑是复杂模型的生成时间。大模型生成代码很快但几何内核执行复杂布尔和圆角可能很慢。一个带几十个特征的零件执行可能要十几秒。我的优化思路是把模型生成和执行做成异步前端先返回生成中后台跑完再通知。8. 关于精度和可编辑性的一点个人看法用了这么久我越来越觉得 text-to-cad 的价值不在于全自动而在于把人的精力从重复劳动里解放出来。它生成的初稿可能不完美但省掉了从零开始的那一步。工程师拿到代码或者模型改几个参数、调一下特征顺序很快就能得到想要的结果。精度上代码生成路线依托工业级几何内核导出的 STEP 是完全可用的工程模型这一点比端到端生成靠谱太多。可编辑性上因为中间产物是代码你能看懂、能改、能版本管理这比黑盒模型强太多。如果你现在就想动手我的建议是从一个小场景切入选一个你经常画的、形状固定的零件把它做成参数化模板再套上自然语言解析。跑通这一个你就理解了整条链路后面扩展就是复制和优化的事。别一上来就想着做通用系统那是个无底洞。