1. 从一句提示词到可编辑模型Text-to-CAD到底在做什么第一次看到“Text-to-CAD”这个词很多做机械设计或者工业建模的朋友第一反应是又来了每隔几年就有人喊一次“设计师要失业”。从最早的参数化建模到后来的生成式设计再到现在的AI辅助建模每次技术往前挪一步都会有人把“失业”两个字挂在嘴边。但真正在一线画图、出图、改图的人心里都清楚事情远没有标题党说得那么夸张。Text-to-CAD真正有意思的地方不是它能不能取代设计师而是它把“从想法到第一版几何模型”这段最耗时的路压缩到了一个前所未有的程度。先把概念说清楚。Text-to-CAD直译就是“文本转CAD”指的是用自然语言描述一个零件的形状、尺寸、特征由模型直接输出可用的CAD文件通常是STEP、IGES这类通用交换格式或者直接生成B-Rep边界表示数据结构。它和传统的“参数化建模”最大的区别在于传统建模需要人一步步画草图、拉伸、打孔、倒角每一步都是显式操作而Text-to-CAD是把这些操作序列交给模型去推断人只需要描述“我要一个长100宽60厚10的板四角各有一个直径8的通孔中心有一个直径30的沉孔”。这里必须点出一个关键的技术底座B-Rep。CAD模型和普通的3D网格模型比如游戏里的模型本质上是两套东西。网格模型用三角面片逼近表面看起来像就行但没法精确表达“直径8的孔”这种工程语义。B-Rep用解析曲面平面、圆柱面、圆锥面、样条面加拓扑关系来描述实体每个面都有精确的数学定义所以能直接用于加工、出工程图、做有限元分析。Text-to-CAD要真正有用输出的必须是B-Rep而不是一个好看的网格。这也是为什么很多早期demo看起来惊艳实际一用就露馅——它们输出的是网格导入CAD软件后没法编辑特征树。从能力边界来看目前这类工具擅长的是规则明确、特征清晰的中小零件支架、法兰、连接件、简单的壳体、带孔位和槽的板类零件。它不擅长的是复杂自由曲面比如汽车外覆盖件、大型装配体、有大量工程约束和配合关系的场景。所以把它定位成“快速出草模、快速验证想法、快速生成标准件变体”的工具比定位成“替代设计师”要准确得多。对于机械工程师、产品结构工程师、做非标自动化的朋友以及需要频繁出零件图的创客和硬件创业者这个方向值得花时间了解。2. 文本是怎么变成B-Rep的拆解背后的生成链路2.1 从自然语言到建模操作序列的映射Text-to-CAD不是一步到位的魔法它内部通常是一条多阶段的流水线。第一步是语义解析把“长100宽60厚10的板四角直径8通孔”这句话解析成结构化的意图包括基体类型板、尺寸参数100/60/10、特征列表四个角上的孔、孔的参数直径8、通孔。这一步本质上是一个信息抽取任务模型需要理解工程语境下的量词、方位词和特征词。第二步是操作序列生成。解析出来的意图要映射成CAD的建模命令序列比如创建草图→画矩形→标注尺寸→拉伸10mm→在四个角点创建圆→标注直径→拉伸切除。这个序列就是所谓的“特征树”。不同的CAD内核Parasolid、ACIS、OpenCASCADE命令体系不一样所以这一步往往需要针对目标内核做适配。很多开源方案会选OpenCASCADE因为它是开源的B-Rep能力完整STEP导出也成熟。第三步是几何求解与B-Rep构建。操作序列交给几何内核执行内核负责实际的布尔运算、曲面求交、拓扑构建。这一步是传统CAD的强项AI在这里不直接参与它只负责“告诉内核做什么”具体“怎么做”还是内核的活。这个分工很重要它意味着Text-to-CAD的几何精度上限取决于它调用的内核而不是模型本身。2.2 为什么训练数据是这件事最大的门槛要训练一个能生成建模序列的模型需要海量的“文本-建模序列”配对数据。但现实是CAD模型文件比如STEP里只有最终的几何没有建模历史也没有对应的文字描述。这就导致训练数据极度稀缺。业内的常见做法有几条路一是用程序化脚本批量生成合成数据比如用Python脚本随机生成参数化的支架、法兰同时自动生成对应的文字描述这样能造出几十万条配对二是从开源3D模型库和CAD社区里爬取带标注的模型但标注质量参差不齐三是用大模型对现有模型做“反向描述”先生成文字再对齐。合成数据这条路最现实但也有明显问题合成数据的分布太“干净”生成的零件都是规整的、参数化的一旦遇到真实世界里那些奇形怪状、带各种工艺特征的零件模型就容易懵。这也是为什么很多Text-to-CAD工具在demo里表现很好一上真实需求就翻车。数据分布的鸿沟是当前这类工具最核心的瓶颈比模型结构本身更关键。2.3 API在整条链路里扮演什么角色关键词里出现了API这不是偶然。Text-to-CAD要落地几乎不可能做成一个纯本地软件因为模型推理需要算力几何内核的调用也需要服务化。常见的架构是前端网页或插件收集文本→调用后端API→后端跑语义解析和序列生成→调用几何内核服务→返回STEP文件或预览图。API在这里承担的是“能力封装”的角色把模型推理、内核调用、文件转换这些脏活累活包起来让上层应用只需要发一个HTTP请求。对开发者来说这意味着你可以把Text-to-CAD的能力集成到自己的工具里。比如你做一个面向非标自动化的选型平台用户输入“我要一个M8螺栓对应的法兰盘”后台调Text-to-CAD API直接生成模型用户下载STEP去加工。这种集成方式比让用户自己装一个CAD软件再手动建模体验上是一个量级的提升。但要注意API调用是有成本的模型推理和几何运算都吃算力做产品化的时候得把调用频率和缓存策略想清楚。3. 亲手跑一遍从提示词到STEP文件的完整实操3.1 环境准备与依赖选择如果你想自己搭一个最小可用的Text-to-CAD流程最省事的路线是Python OpenCASCADE通过pythonocc或cadquery 一个大模型API做语义解析。cadquery是个很好的选择它用Python代码描述建模过程语法接近自然语言而且底层就是OpenCASCADE导出的STEP是标准B-Rep。安装上cadquery可以通过conda装因为它依赖OCCT的二进制库pip装容易出问题。我实测下来用conda创建一个独立环境最稳conda create -n text2cad python3.10 conda activate text2cad conda install -c conda-forge -c cadquery cadquery2.4装完之后先跑一个最简单的例子验证环境import cadquery as cq result (cq.Workplane(XY) .box(100, 60, 10) .faces(Z).workplane() .rect(80, 40, forConstructionTrue) .vertices().hole(8)) result.val().exportStep(plate.step)这段代码生成一个100x60x10的板在四个角内侧打四个直径8的通孔导出STEP。跑通这个说明几何内核没问题了。3.2 用大模型把自然语言翻译成cadquery代码接下来是核心让模型把用户的话翻译成上面那样的cadquery代码。这里可以用任意支持代码生成的大模型API提示词的设计是关键。我的经验是提示词里必须包含三样东西cadquery的API约束、输出格式要求、几个few-shot示例。import requests SYSTEM_PROMPT 你是一个CAD建模助手把用户的自然语言描述翻译成cadquery Python代码。 要求 1. 只输出代码不要解释 2. 代码最后必须调用 exportStep 导出到指定路径 3. 单位统一用毫米 4. 只使用cadquery的标准API 示例 用户一个直径50高20的圆柱中心有一个直径10的通孔 代码 import cadquery as cq result (cq.Workplane(XY) .circle(25).extrude(20) .faces(Z).workplane().hole(10)) result.val().exportStep(output.step) def text_to_cad(user_input): resp requests.post( https://your-llm-api-endpoint/v1/chat/completions, headers{Authorization: Bearer YOUR_KEY}, json{ model: your-model, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input} ], temperature: 0.1 } ) code resp.json()[choices][0][message][content] return code拿到代码后用exec执行就能生成STEP文件。temperature设低一点0.1左右因为建模代码需要确定性不能让它自由发挥。3.3 实测中暴露的三个典型问题跑通demo之后我拿十几个真实需求测了一轮暴露出来的问题很有代表性。第一个问题是尺寸歧义。用户说“一个厚一点的板”模型不知道“厚一点”是多少。这时候要么在提示词里强制要求用户给具体数值要么让模型主动追问。实测下来强制要求数值是最省事的因为追问会打断流程。第二个问题是特征顺序错误。比如“先打孔再倒角”和“先倒角再打孔”结果可能不一样。模型有时候会把顺序搞反导致倒角把孔边切掉一块。解决办法是在提示词里明确“先做基体再做切除特征最后做倒角和圆角”。第三个问题是坐标系约定。cadquery默认在XY平面建模Z轴向上。但用户描述“竖直的板”时模型可能理解成在XZ平面。这个需要在提示词里固定坐标系约定并且让模型在代码里显式指定workplane。提示不要指望一次生成就完美。实际产品里通常要生成3-5个候选让用户选一个最接近的再手动微调。这比追求“一次成型”现实得多。4. 精度、可编辑性与工程可用性的真实差距4.1 生成模型和手工模型的差距在哪很多人关心的是AI生成的CAD模型能不能直接拿去加工我的结论是简单零件可以复杂零件不行。差距主要体现在三个层面。第一是尺寸链和公差。手工建模时工程师会考虑配合、间隙、公差带比如一个孔标注直径8H7这是有工程语义的。AI生成的模型通常只给名义尺寸没有公差信息导出的STEP里也不带公差标注。要用于实际加工还得人工补公差。第二是特征树的合理性。手工建模的特征树是工程师精心组织的方便后续修改。AI生成的特征树往往是“能跑就行”可能用了很多不必要的布尔运算或者把本该参数化的尺寸写死了。这导致后续改图很痛苦改一个尺寸可能整个模型崩掉。第三是工艺特征。真实零件有拔模角、圆角、退刀槽、中心孔这些工艺特征AI模型如果没有在训练数据里见过足够多的真实零件很容易漏掉。漏掉一个退刀槽加工时就可能出问题。4.2 怎么把生成结果接进现有工作流比较务实的做法是把Text-to-CAD当成“第一版草模生成器”生成之后导入你常用的CAD软件SolidWorks、Fusion 360、中望CAD等在它的基础上改。STEP格式是通用的导入后特征树可能丢失但几何是完整的你可以基于导入的实体重新做特征识别或者直接在它上面加特征。如果你的CAD软件支持脚本比如SolidWorks的API、Fusion 360的Python API还可以把Text-to-CAD生成的cadquery代码转译成目标软件的脚本这样能保留特征树。这个转译工作有一定工程量但对于高频使用的场景值得做。4.3 什么场景下它真的能省时间我自己的使用经验是这几类场景收益最明显一是标准件的变体生成比如不同尺寸的法兰、不同孔位的安装板描述清楚参数就能批量出二是概念阶段的快速验证脑子里有个想法先出个模型看看比例和干涉比手画快得多三是非专业人员的建模需求比如做硬件的创业者不懂CAD但能描述清楚要什么形状用Text-to-CAD出个初版再找工程师细化。反过来这几类场景不建议用精密配合件、复杂曲面、大型装配体、有严格公差要求的零件。这些场景下AI生成的模型改起来比自己画还费劲。5. 落地时必须想清楚的几个工程问题5.1 几何内核的选型与授权如果你要做产品几何内核的选型是绕不开的。OpenCASCADE开源免费但文档和社区支持一般遇到深坑得自己啃源码。Parasolid和ACIS是商业内核稳定性和支持好但授权费不便宜。选型时要考虑你的目标用户用什么CAD软件他们需要什么格式的导出如果只需要STEPOpenCASCADE够用如果需要原生格式比如SLDPRT那就得用对应厂商的API成本和复杂度都上一个台阶。5.2 模型推理的成本控制大模型推理是按token计费的Text-to-CAD每次调用都要消耗不少token提示词代码生成。如果用户量大成本会很快上去。常见的优化手段有缓存常见需求的生成结果、用小模型做意图分类再路由到大模型、把few-shot示例精简到最少。我实测下来把提示词从2000 token压到800 token生成质量下降不明显但成本降了一半多。5.3 错误处理与用户预期管理AI生成代码一定会有失败的时候。失败分几种语法错误代码跑不起来、几何错误布尔运算失败、语义错误生成的形状和用户想要的不一样。产品设计上语法错误可以自动重试几何错误要捕获异常并给用户友好提示语义错误最难处理通常需要让用户确认或提供反馈。把失败当成常态来设计而不是当成异常这是做这类产品的心态基础。6. 关于“设计师失业”这件事我的真实看法回到标题里那个问题。我做了十几年设计相关的工作见过太多“XX要失业了”的标题。Text-to-CAD确实会改变一些东西但它改变的是工作的重心不是工作的有无。以前工程师花大量时间在“把想法变成第一版模型”上以后这部分时间会被压缩省下来的时间会转移到“定义问题、验证方案、优化设计、处理工程约束”上。这些恰恰是AI目前做不好的。真正会被影响的是那些只做重复性建模、不参与设计决策的岗位。但这类岗位本来就在被参数化和自动化侵蚀Text-to-CAD只是加速了这个过程。对于愿意把AI当工具用的工程师它是个放大器对于拒绝变化的人它是个威胁。这个逻辑和当年CAD取代图板、参数化取代纯手工建模是一样的。我自己的做法是把Text-to-CAD当成一个“快速出草模的助手”用它处理那些规则明确、不需要太多思考的建模任务把精力留给真正需要判断力的部分。工具在变但工程判断力的价值短期内看不到被替代的迹象。