1. 从一段文字到三维实体text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个词很多人脑子里浮现的画面大概是对着电脑敲一句给我画一个法兰盘然后屏幕上就自动长出一个三维模型。这个想象不算离谱但真正落地的时候它解决的问题比自动画图要具体得多也琐碎得多。text-to-cad 的核心是把自然语言描述转换成计算机辅助设计软件能识别的几何数据。这里的CAD不是单指某一个软件而是一整条数据链路从文本意图解析到参数化建模再到导出成 STEP、GLB、STL 这些通用格式。它真正想干掉的是传统建模流程里最耗时的那个环节——把脑子里的尺寸和结构一个特征一个特征地手动点出来。我接触这个方向最初是因为一批标准件建模的活儿。几百个规格的支架、连接板、垫片结构高度相似只是孔距、板厚、倒角半径不一样。手动在 CAD 里改参数、重建特征一天下来眼睛都花了。那时候我就在想如果能把长 120、宽 80、厚 6、四角 M8 通孔、孔距 100×60这样一句话直接变成模型文件效率能翻好几倍。text-to-cad 要做的正是这件事。它适合谁三类人最该关注。第一类是做批量标准件的工程师参数化程度高、重复劳动多收益最直接。第二类是做产品原型的设计者需要快速把概念变成可预览、可 3D 打印的模型用来验证比例和装配关系。第三类是做 AI 应用开发的程序员想把大语言模型的文本理解能力接到几何生成上做一个能对话的建模工具。但这里必须先泼一盆冷水text-to-cad 目前不是说人话就出完美模型的魔法。自然语言天生模糊一个好看的支架这种描述机器没法直接转成几何。真正能跑通的方案都是把文本约束到结构化参数上再用参数驱动建模内核。理解这一点是后面所有实操的前提。提示如果你的需求是任意复杂曲面、艺术造型text-to-cad 现阶段基本帮不上忙。它的强项是规则明确、参数清晰的工程件。2. 文本怎么变成几何拆解 text-to-cad 的三层处理链路要自己动手做一套 text-to-cad 流程先得搞清楚中间到底发生了什么。我把它拆成三层语义解析层、参数映射层、几何生成层。每一层都有各自的坑跳过任何一层最后出来的模型都会看着像但用不了。2.1 语义解析层把一句话拆成机器能读的槽位自然语言输入进来第一步是抽取实体、尺寸、约束、操作这四类信息。比如长 120 宽 80 厚 6 的板四角打 M8 通孔孔中心距边 15解析后应该得到这样的结构{ shape: plate, dimensions: {length: 120, width: 80, thickness: 6}, features: [ {type: hole, count: 4, diameter: 8, thread: M8, position: corner, offset_from_edge: 15} ] }这一步用大语言模型做信息抽取是最省事的。给它一个明确的 schema让它输出 JSON比传统正则匹配鲁棒得多。但要注意模型很容易把孔距 100理解成孔到边的距离所以 schema 里字段命名必须无歧义最好在提示词里给两三个例子。我踩过的一个坑早期我让模型直接输出尺寸数字结果它把厚 6 毫米里的6和孔距 60里的60搞混了。后来改成要求模型输出带单位的键值对并且对每个数值标注它属于哪个特征错误率立刻降下来。这个细节看起来小但它决定了后面几何生成会不会直接崩掉。2.2 参数映射层把槽位翻译成建模内核的调用拿到结构化参数后要把它映射成具体建模操作的调用。这里有个关键选择用现成 CAD 软件的 API还是用几何内核库自己搭。用现成软件 API比如通过脚本驱动参数化建模好处是稳定、功能全、导出格式多坏处是依赖软件环境部署重。用几何内核库比如 OpenCASCADE 这类开源内核好处是轻量、可嵌入、能跑在服务端坏处是很多高级特征要自己实现学习曲线陡。我的建议是原型阶段用几何内核库快速验证生产阶段再考虑接 CAD 软件 API。因为原型阶段你最需要的是快速看到模型长什么样而不是导出符合某软件标准的工程图。参数映射里最容易出错的是单位。文本里说厚 6到底是毫米还是厘米如果解析层没统一映射层就会把 6 毫米当成 6 米模型直接飞出屏幕。我的做法是在解析层强制统一到毫米并在 schema 里写明单位字段任何没标单位的数值默认按毫米处理。2.3 几何生成层布尔运算与特征树的顺序问题到了真正生成几何这一步顺序非常关键。还是拿带孔板举例正确顺序是先建板体再打孔。如果反过来先建孔再建板布尔运算的结果可能完全不对。更麻烦的是多特征叠加。比如一块板既要打孔又要倒角还要开槽。这时候特征树的顺序会影响最终形状。倒角如果放在打孔之前孔边缘的倒角可能被后续布尔运算吃掉放在之后又可能因为孔太靠近边导致倒角失败。我的经验是按从大到小、从外到内的顺序排列特征。先做主体形状再做减材料特征孔、槽最后做修饰特征倒角、圆角。这个顺序和大多数工程师手动建模的习惯一致也最不容易出问题。3. 导出格式怎么选STEP、GLB、STL 的适用边界模型生成出来只是第一步真正交付的时候格式选错等于白干。text-to-cad 场景下最常打交道的三种格式是 STEP、GLB、STL它们各自解决不同的问题混用会出大麻烦。3.1 STEP工程交付的普通话STEP 是边界表示B-rep格式保留完整的几何拓扑信息——面、边、顶点、曲面类型全都记录在案。这意味着它可以被 CAD 软件重新编辑尺寸、特征都还在。如果你的模型要交给别人继续改、要出工程图、要做精确装配必须用 STEP。它是工程领域事实上的交换标准几乎所有主流 CAD 软件都能读写。但 STEP 有个特点它描述的是理想几何不包含网格信息。所以它不能直接拿去 3D 打印也不能直接渲染。而且 STEP 文件通常比 STL 大传输和加载都更慢。3.2 STL3D 打印和网格处理的通用语STL 是三角网格格式用一堆三角形面片拼出模型表面。它简单、通用3D 打印切片软件基本都认它。但 STL 的致命问题是它只有表面没有实体信息。你没法从 STL 里读出这是一个直径 8 的孔只能看到一圈三角形。所以 STL 适合打印和渲染不适合再编辑。热词里出现的sw 中 stl 转 stp、3dsmax2012 修复 stl 模型的 uv、qopengl 加载 stl本质上都是在处理 STL 的先天不足——要么把它转回可编辑格式要么在网格层面做修补。这些操作都很费劲所以能拿到 STEP 就别用 STL 中转。3.3 GLB网页预览和轻量分发的首选GLB 是 glTF 的二进制版本专为实时渲染和网络传输设计。它体积小、加载快浏览器里用 Three.js 之类的库能直接显示。如果你的 text-to-cad 工具要做成网页应用让用户在线预览模型GLB 是最佳选择。它支持材质、颜色、光照信息视觉效果比 STL 好得多。但它同样不是工程格式几何精度和可编辑性都不如 STEP。所以典型做法是后台生成 STEP 存档前台导出 GLB 预览一份数据两种用途。格式几何类型可编辑适用场景典型体积STEPB-rep 实体是工程交付、装配、出图较大STL三角网格否3D 打印、网格处理中等GLB网格材质否网页预览、轻量分发较小注意从 STEP 转 STL 是降级精度由网格细分参数决定从 STL 转 STEP 是逆向需要曲面重建结果往往不理想。尽量在源头就选对格式。4. 动手搭一条最小可用链路从文本到 STEP 文件理论讲完来点能直接抄的。下面这条链路是我实际跑通过的最小可用方案用大语言模型做语义解析用 Python 几何库做建模最后导出 STEP。整套流程不依赖任何商业 CAD 软件能跑在普通服务器上。4.1 环境准备与依赖选择核心依赖两个一个负责调大语言模型做解析一个负责几何建模。几何这块我选CadQuery它基于 OpenCASCADE 内核用 Python 写参数化模型非常顺手而且原生支持导出 STEP 和 STL。pip install cadquery openaiCadQuery 的好处是代码即模型每个特征都是一行链式调用和 text-to-cad 的参数驱动思路天然契合。你解析出来的参数直接喂给 CadQuery 的 API 就行。环境上唯一要注意的是CadQuery 依赖 OpenCASCADE 的二进制库Windows 和 Linux 下安装方式略有差异。如果pip install报错优先检查 Python 版本建议 3.9 到 3.11和系统架构是否匹配。4.2 用大语言模型做结构化抽取这一步的目标是把自由文本变成严格 JSON。关键是提示词里给足约束和例子别指望模型自己猜。import json from openai import OpenAI client OpenAI() SYSTEM_PROMPT 你是一个CAD参数抽取器。把用户描述转成JSON。 规则 1. 所有尺寸单位统一为毫米未标注单位默认毫米。 2. 只输出JSON不要解释。 3. 字段shape, dimensions, features。 4. features里每个特征标注type、count、diameter、position等。 示例输入长100宽50厚5的板中间一个直径10的通孔 示例输出{shape:plate,dimensions:{length:100,width:50,thickness:5},features:[{type:hole,count:1,diameter:10,position:center}]} def parse_text(user_text): resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_text} ], temperature0 ) return json.loads(resp.choices[0].message.content)temperature0很关键它让输出尽量确定减少同一句话两次解析结果不一样的情况。实测下来加了示例之后简单工程件的解析准确率能到九成以上。4.3 参数驱动建模与导出拿到 JSON 后用 CadQuery 建板、打孔、导出。下面是一个带四角孔的板import cadquery as cq def build_plate(params): d params[dimensions] plate cq.Workplane(XY).box(d[length], d[width], d[thickness]) for feat in params[features]: if feat[type] hole: r feat[diameter] / 2 offset feat.get(offset_from_edge, 15) x d[length] / 2 - offset y d[width] / 2 - offset plate (plate.faces(Z).workplane() .pushPoints([(x, y), (-x, y), (-x, -y), (x, -y)]) .hole(feat[diameter])) return plate params parse_text(长120宽80厚6的板四角打直径8的通孔孔中心距边15) result build_plate(params) cq.exporters.export(result, plate.step) cq.exporters.export(result, plate.stl)这段代码跑通你就有了一个从一句话到 STEP 文件的完整闭环。导出 STL 是为了方便马上 3D 打印验证导出 STEP 是为了后续能继续编辑。4.4 实测中暴露的三个问题第一次跑通不代表能用。我实测下来有三个问题反复出现必须提前处理。第一孔位坐标算错。上面代码里x length/2 - offset假设孔在四角但如果用户说孔距 100×60那指的是孔与孔之间的距离不是孔到边的距离。这两个概念差一个孔径模型就错了。解决办法是在解析层就把孔距换算成坐标别留到建模层。第二薄板打大孔导致布尔失败。如果板厚 2 毫米孔直径 20 毫米孔边缘可能超出板面布尔运算直接报错。我的处理是在建模前做几何可行性检查孔直径加两倍边距不能超过板的最小边长否则拒绝生成并提示用户。第三导出 STEP 后单位丢失。有些下游软件读 STEP 时默认按米处理导致模型缩小一千倍。CadQuery 导出时默认单位是毫米但为了保险我会在导出后用文本编辑器打开 STEP 文件检查头部单位声明确认是 MILLIMETRE 而不是 METRE。5. 那些文档里不会写的坑text-to-cad 实操避雷清单工具链跑通只是开始真正决定这套东西能不能用在生产里的是那些没人会主动告诉你的细节。下面这些坑我基本都亲自踩过一遍。5.1 自然语言的模糊性远比想象中严重打几个孔——几个是几个稍微倒个角——倒多大厚一点——厚多少这些描述在人看来有上下文能猜机器完全没法处理。我的做法是在解析层设置追问机制如果关键参数缺失或模糊不硬猜而是返回一个追问列表让用户补充。比如检测到孔但没检测到直径就返回请提供孔径。这比生成一个错误模型再让用户返工要高效得多。另一个技巧是给常见描述建立同义词表。通孔和穿孔是一回事沉头孔和埋头孔是一回事。把这些映射关系写进提示词或后处理逻辑能显著提升解析稳定性。5.2 特征顺序错了模型就废了前面提过特征顺序这里再强调一次因为它太容易出错。我见过一个案例用户要带圆角的板板上开槽。如果先开槽再倒圆角槽口边缘的圆角可能和板的圆角冲突导致几何自交。正确顺序是先倒板的外圆角再开槽。判断顺序的通用原则是修饰性特征圆角、倒角尽量放在减材料特征之后但涉及外轮廓的修饰要放在最前。这个规则不是绝对的遇到复杂件还是要具体分析。我的建议是把特征顺序做成可配置项让用户或上层逻辑能调整而不是写死在代码里。5.3 导出格式的精度陷阱STL 导出时有个**弦高chord tolerance**参数它决定曲面被三角化的精细程度。弦高设大了圆柱面看起来像多边形设小了文件体积爆炸。对于 text-to-cad 生成的工程件我的经验值是弦高取 0.01 到 0.05 毫米。这个范围下直径 10 的孔看起来足够圆文件也不会太大。如果模型要用于精密装配可以调到 0.005如果只是预览0.1 也够用。GLB 导出则要注意是否合并顶点。不合并的话每个三角形独立存储顶点文件会大很多。大多数导出库都有合并选项记得打开。5.4 批量生成时的命名与版本管理当你一次生成几百个模型时文件命名会变成灾难。plate.step、plate(1).step、plate_final.step这种命名过两天自己都认不出来。我的做法是用参数哈希做文件名。把解析出的 JSON 排序后算一个短哈希拼在文件名里。这样同样的参数永远生成同样的文件名不同参数不会冲突还能天然去重。再配合一个索引文件记录哈希和原始文本的对应关系追溯起来很方便。常见坑表现处理方式参数模糊模型尺寸随机追问机制同义词表特征顺序错几何自交或失败顺序可配置外轮廓优先网格精度不当圆柱变多边形或文件过大弦高 0.01~0.05 毫米文件命名混乱无法追溯版本参数哈希命名索引文件6. 把 text-to-cad 接进真实工作流几个落地场景单机跑通和真正用起来是两回事。下面这几个场景是我觉得 text-to-cad 最能发挥价值的地方也是我实际尝试过或见过别人跑通的。6.1 标准件库的批量生成这是收益最直接的场景。企业里往往有几百上千个标准规格的零件结构一样只是参数不同。传统做法是一个个手动建或者用 Excel 驱动参数化模板。text-to-cad 的改进在于你可以用自然语言描述规格批量生成。比如把产品手册里的规格表读进来每行转成一句话批量跑解析和建模一次性产出所有 STEP 文件。我做过一个测试两百个规格的支架从文本到全部 STEP 导出总共花了不到十分钟其中大部分时间还是在调大语言模型的接口。这里的关键是建立规格文本的模板。别让用户自由发挥而是给一个固定句式比如型号 X长 A 宽 B 厚 C孔距 D×E孔径 F。模板化之后解析准确率接近百分之百。6.2 概念设计阶段的快速可视化产品经理或设计师有个想法想快速看看比例对不对。传统流程是找工程师建模来回沟通好几天。text-to-cad 可以做到几分钟出 GLB 预览在网页里转着看。这个场景对精度要求不高但对速度要求极高。所以链路要精简解析用轻量模型建模只做主体形状导出直接 GLB。别在这个阶段纠结 STEP 和工程图那是后面的事。我自己的做法是做一个简单的网页界面输入框敲描述点生成右边直接显示 GLB。整个响应控制在十秒以内体验就很流畅了。6.3 和现有 CAD 流程的衔接text-to-cad 生成的模型最终往往还是要进到传统 CAD 流程里。这时候STEP 的兼容性就很重要。我遇到过一个情况生成的 STEP 在某些软件里打开后特征树是空的只有一个实体。这是因为 STEP 只记录几何结果不记录建模历史。如果下游需要改特征就得重新参数化。解决办法有两个一是同时输出参数 JSON下游用脚本重新建模二是在 STEP 里保留命名实体比如把每个孔命名为hole_1、hole_2方便识别。CadQuery 支持给实体打标签这个功能在交接时很有用。提示如果你的下游流程重度依赖特征树text-to-cad 目前只能做毛坯生成精细特征还是得人工补。别指望它一步到位。7. 关于精度、性能与扩展性的一些个人体会写到这里核心链路和坑都讲得差不多了。最后分享几点我在实际使用中攒下的体会都是些不成体系但很实在的经验。精度这件事源头比末端重要。很多人花大力气优化网格细分、优化导出参数但模型不准的根源往往在解析层——尺寸理解错了后面再精细也是错的。我的精力分配是解析层占六成建模层占三成导出层占一成。性能瓶颈通常不在几何计算而在大语言模型调用。生成一个简单零件几何计算可能只要几十毫秒但调一次模型接口要一两秒。批量生成时这个延迟会被放大。我的优化方式是把能缓存的解析结果缓存起来相同或相似的文本直接命中缓存不再调接口。扩展性要从第一天就考虑。一开始只支持板这一种形状没问题但代码结构要留好口子。我的做法是把形状生成做成注册表每种形状一个函数新增形状只要注册进去就行。特征也是同理孔、槽、倒角各自独立方便后续加新特征。别忽视错误处理。text-to-cad 的输入是自然语言天然充满意外。用户可能输入一句完全没法解析的话也可能输入一个几何上不可能实现的组合。这些情况都要有明确的错误提示而不是抛一个看不懂的异常。我的做法是给每类错误定义错误码和友好提示让用户知道是哪里出了问题、该怎么改。最后保持对结果的怀疑。自动生成的模型一定要有验证环节。简单的验证是检查包围盒尺寸是否符合预期复杂一点的可以检查体积、表面积、孔的数量。我习惯在生成后自动跑一遍这些检查不通过就拒绝交付。这一步能挡掉大部分低级错误。这套东西我还在持续打磨每次遇到新的输入类型就补一条规则、加一个测试用例。text-to-cad 不是一蹴而就的方案它更像一个需要慢慢喂养的系统。但只要链路搭对了它省下的重复劳动是实打实的。