我第一次看到 text-to-cad 这个词的时候第一反应是以后是不是只要会写字就能画图了后来自己动手跑了一遍发现事情没那么玄但也足够让人兴奋。text-to-cad说白了就是让 AI 把你的自然语言描述翻译成一个真正可用于制造的 CAD 模型最终输出 STEP、IGES 这类工业界认的格式而不是一张渲染图或一个网格体。这个方向最近在三维建模、参数化设计和 AI 生成设计的圈子里热度很高制造工程师、产品设计师、创客、甚至做自动化设计的开发者都在盯它。这篇文章我想从原理到实操把这条技术路线完整拆给你看。我踩过不少坑也翻过不少车最后整理出一套最小可复现的 text-to-cad 工作流。它不一定能直接做到“一句话生成一个飞机发动机”但足以让你理解这类系统的核心逻辑并且能照着代码自己跑通“长方块倒圆角”这种基础场景。如果你是做 CAD 二次开发的、搞 AIGC 的或者单纯对“语言生成三维实体”这件事好奇这篇文章就是写给你的。1. text-to-cad 到底是什么它解决什么问题1.1 一句话说清楚这个概念text-to-cad 是 text-to-3D 的一个分支但它和常见的文本生成三维模型有本质区别。市面上大部分 text-to-3D 工具生成的是网格模型也就是由三角面片拼出来的表面适合看、适合渲染、适合放进游戏引擎但没法直接拿来加工因为工业制造需要的是边界表示也就是 B-Rep 模型带拓扑关系、带参数历史、带精确几何。text-to-cad 的目标是绕过中间步骤直接从文字生成这种带完整工程语义的 CAD 实体。举个例子我说“创建一个 M8 的内六角螺栓长度 30 毫米”一个合格的 text-to-cad 系统应该能在几秒内给出一个包含螺纹、头部六角、倒角等特征的 STEP 文件。这个 STEP 文件放进 Fusion 360、FreeCAD 或 SolidWorks 里是可以继续编辑、继续改参数的而不是一张只能看不能动的表面。1.2 它和普通 AI 生图的区别到底在哪平时大家玩的 Midjourney、Stable Diffusion本质是在做像素生成模型学到的是“看起来像”的分布。text-to-cad 要学的则是“几何上正确、拓扑上合理、制造上可行”的实体这个难度不是一个量级的。我举个类比文字生成图片像是让一个人按描述画一幅油画画得再抽象也能欣赏文字生成 CAD 模型则是让一个人按描述加工一个零件尺寸差 0.1 毫米装配的时候就装不上。所以 text-to-cad 系统的评价指标不是“好看”而是“准确、可编辑、可制造”。这也是为什么这类系统到现在还没有像文生图那样遍地开花因为它对几何约束的要求极其严格。1.3 适合谁用、用在哪我总结下来下面这几类人最需要关注 text-to-cad机械工程师 / 产品设计师设计初期快速概念建模用一句话生成候选方案再在 CAD 软件里细化。非专业建模人群比如采购需要快速给供应商描述一个零件外形不再依赖工程师画图。CAD 二次开发工程师把 text-to-cad 能力嵌入自己的自动化设计流程把自然语言接口包装成内部工具。教育 / 创客领域降低三维建模的入门门槛先有模型再学命令学习曲线会平缓很多。我自己的实际体验是text-to-cad 现阶段最靠谱的定位不是替代 CAD 软件而是充当“意图到参数的快捷翻译器”。它负责把模糊的自然语言转成明确的几何参数剩下的精确建模和制造工艺还是需要人工确认。2. 核心原理AI 怎么把一句话变成可编辑的 CAD 实体2.1 先拆解语言意图再生成几何要理解 text-to-cad 的底层思路得先明白一个关键点语言和几何之间不是直接映射的关系而是经历了“意图结构化”这个中间层。比如用户说“做一个底板长 100 宽 60 高 10四个角打 M6 的安装孔孔距 80 和 40”。这句话里有几类信息一是实体类型底板二是基础尺寸100×60×10三是特征操作打孔四是特征参数M6、孔距。text-to-cad 系统要做的第一件事就是把这些信息抽成一个结构化的操作列表类似{ operations: [ {type: box, length: 100, width: 60, height: 10}, {type: hole, diameter: 6.0, positions: [[10, 10], [90, 10], [10, 50], [90, 50]]} ] }拿到这个结构化描述之后再交给 CAD 内核去执行。这也是目前最主流的做法把 text-to-cad 拆成“LLM 做意图解析 程序化建模引擎做几何生成”两边各干各的活。2.2 为什么不能直接端到端生成 B-Rep有人可能会问那有没有可能训练一个大模型直接输出 CAD 原生文件格式理论上可以实践上非常难。核心难点在于 CAD 原生的 B-Rep 数据结构和图像、点云完全不同。它不是一个规则的二维数组也不是简单的点集合而是一堆面、边、顶点以及它们之间的拓扑关系组成的图结构而且这些几何量是连续的浮点数。你让神经网络去直接预测一串浮点数坐标和拓扑关系输出结果的精度和一致性问题几乎无解。就算预测出来了也大概率是不合法的实体比如面与面之间出现裂缝、边没对上、法向翻转。所以现实中的工程化方案几乎都走了同一套路语言模型负责“理解”参数化建模引擎负责“执行”。语言模型不直接生成几何它生成的是参数和操作序列再交由 OpenCascade、Parasolid 这类成熟几何内核去构造实体。这样既利用了大语言模型的语义理解能力又保证了输出模型的工程合法性。2.3 两条主流技术路线对比我梳理了一下目前业内比较常见的实现路径大体分三类技术路线实现方式优点缺点LLM 参数化模板库用户描述被映射为预设的零件族模板和对应参数精度高、可靠性强、适合标准件只能覆盖有限的零件类型LLM 程序化建模脚本LLM 直接生成 CadQuery / build123d / OpenCascade 脚本代码灵活度较高、可处理组合特征代码可能跑不通调试成本高端到端生成模型训练专用模型直接输出 B-Rep 结构上限高、不依赖预定义模板当前技术成熟度低、工程化难我自己的实践经验是现阶段最稳的是第一条路线就是“模板 参数抽取”。你把常用的零件族做成可参数化的模板函数LLM 只负责把用户描述转换成模板函数需要的参数。这样做的好处是你永远不用担心 LLM 生成一段诡异代码把建模内核搞崩溃而且尺寸精度完全可控。缺点是你要提前把模板库建好。做自动化设计的同学应该能感觉到这其实就是把传统的参数化设计思路跟大语言模型做了一个结合。3. 技术路线选型自建还是用现成的3.1 全自建方案的优劣势如果你打算从零搭建一套 text-to-cad 工作流最典型的技术栈是 LLM API CadQuery/OpenCascade。Python 生态里我觉得 CadQuery 是对新手最友好的一个库它把 OpenCascade 的能力封装成了链式调用的方式写起来像搭积木而且导出 STEP 格式非常方便。自建路线的优势在于可控性你可以完全掌握 prompt、模板、几何参数校验逻辑甚至可以把公司内部的零件库、设计规范全部写进模板里做成内部专用的文本建模工具。缺点也很明显就是工作量不小你不仅要写参数化模板还要设计一套可靠的意图解析流程并且要处理各种所谓的“边缘情况”比如用户说“大约 100 毫米”的时候系统该怎么办。3.2 用现成 SDK 和平台能省多少事如果不打算从零造轮子也可以直接用市面上的第三方 text-to-cad API 或插件。一些主流的 CAD 软件厂商和初创公司已经提供了类似能力输入一句话直接生成可编辑模型。这类方案的好处是开箱即用底层几何内核和导出质量都有保障适合快速验证场景。但用现成方案也有我比较在意的两个问题一是可定制性不足用户无法控制内部的模板库和参数规范二是数据安全因为设计数据都要传到云端很多制造业企业根本不会接受。所以我给团队的建议通常是可以用现成 API 做技术验证和原型演示但真正要落地到生产环境还是得走自建路线。3.3 判断一个系统靠不靠谱的四个指标不管自建还是现成判断一个 text-to-cad 系统好坏我一般看四个维度几何正确性生成的模型能不能通过几何内核的合法性检查比如用 OpenCascade 的BRepCheck_Analyzer验证。可编辑性输出模型能不能在 CAD 软件里继续改参数理想情况下应该是参数化历史完整的原生文件而不是一个“死”实体。格式兼容性能否导出 STEP、IGES以及各 CAD 软件的原生格式。鲁棒性换一种说法表达同一个需求时结果是否一致遇到模糊描述时是主动追问还是瞎猜。我自己在选型时会把“几何正确性”放在最高优先级。因为如果不能保证模型合法后面的一切都无从谈起。宁可系统老实告诉你“这个指令我生成不了”也不要给你一个看起来差不多但实际不能用的模型。4. 从零写一个最小可用的 text-to-cad代码实操接下来是这篇文章干货最集中的部分。我会基于“LLM 解析意图 CadQuery 执行建模”的架构手把手写一个最小可用的 text-to-cad 脚本。它不复杂但五脏俱全能让你亲眼看到从一句话到一个 STEP 文件的完整链路。4.1 环境准备和依赖先说明一下我的环境Python 3.10安装cadquery和openai两个核心库。CadQuery 2.x 版本目前对 Windows 和 Linux 的支持都很成熟直接用 pip 安装即可。pip install cadquery openai如果你不想调用云端大模型 API也可以用本地模型替代只要能输出 JSON 格式的结构化结果就行。不过在动手之前建议先把流程跑通再优化模型选型这样排错会容易很多。我这里的做法是先用 OpenAI API 做演示因为它的 JSON 输出模式最稳定。4.2 第 1 步让 LLM 输出结构化参数这一步是整个系统的“翻译官”。我设计了一个精简的意图解析函数它接收用户的一句话返回一组标准化的几何操作参数。为了让 LLM 输出可解析的 JSON我在 prompt 里做了强约束并且开启了response_format{type: json_object}。import json from openai import OpenAI client OpenAI() SYSTEM_PROMPT 你是一个 CAD 意图解析器。用户的输入会被你翻译成几何操作参数只输出 JSON不要输出任何解释。 目前支持的操作为 box长方体和 fillet圆角。 JSON 结构示例 {operations: [ {type: box, params: {length: 100, width: 50, height: 20}}, {type: fillet, params: {radius: 5}} ]} 要求 - 所有尺寸默认单位是毫米。 - 如果没有明确给出尺寸使用合理默认值。 - 不要输出 JSON 以外的任何内容。 def parse_user_input(user_text: str) - dict: response client.chat.completions.create( modelgpt-4o-mini, response_format{type: json_object}, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_text} ], temperature0 ) content response.choices[0].message.content # 清理意外包裹的代码块标记 content content.strip() if content.startswith(): content content.split(\n, 1)[1].rsplit(, 1)[0].strip() return json.loads(content)这里有两个细节我特别提醒一是 temperature 一定要设成 0否则 LLM 会有随机性同一个描述两次生成的参数可能不一致这对工程化是致命的二是 prompt 里必须写明“只输出 JSON”并且给出明确的结构示例。实测下来只要给了样例GPT 系列模型的输出稳定性会好很多。4.3 第 2 步用 CadQuery 把参数变成实体拿到结构化参数之后建模部分就非常简单了。我用cq.Workplane(XY)作为起始平面按操作列表依次执行。这里我先支持box和fillet两种操作足够演示完整链路。实际工程中使用hole、extrude、cut、array等操作也只是在elif里继续增加分支的事。import cadquery as cq def build_model(operations: list) - cq.Workplane: model cq.Workplane(XY) for op in operations: op_type op[type] params op[params] if op_type box: model model.box( params[length], params[width], params[height] ) elif op_type fillet: # 对所有竖直边统一做圆角 model model.edges(|Z).fillet(params[radius]) else: raise ValueError(f不支持的操作类型: {op_type}) return model这一环节有个容易踩的坑fillet不是随便就能成功的。如果圆角半径超过边的长度或者相邻边过短几何内核会直接报错。我通常会在执行倒角前做一个参数合理性检查比如判断半径是否大于 0 且小于模型最小边尺寸的一半。这个在后面的避坑章节还会展开。4.4 第 3 步导出 STEP 并做合法性检查模型建好之后最重要的一步是导出 STEP 文件。STEP 是工业界通用的中性格式几乎所有的 CAD 软件都支持导入。CadQuery 导出 STEP 的方式非常简单def save_step(model: cq.Workplane, file_path: str): cq.exporters.export(model, file_path)不过仅仅能导出还不够我还建议在导出前做一个合法性检查。CAD 建模过程中偶尔会出现自相交或退化实体用 OpenCascade 的检查器可以提前发现问题from OCC.Core.BRepCheck import BRepCheck_Analyzer from OCC.Core.TopoDS import topods def validate_solid(workplane): # 先拿到底层 Solid再交给 BRepCheck_Analyzer 验证 solid workplane.val() analyzer BRepCheck_Analyzer(solid) return analyzer.IsValid()如果你的环境里没装pythonocc-core也可以直接信任 CadQuery 内部不报错就是合法。但对要求严格的制造场景建议还是加上这一道验证尤其是后续要接自动化流水线的时候不能让脏数据往下游跑。4.5 完整执行流程演示最后把三个环节串起来一个完整的 text-to-cad 程序就成型了def text_to_cad(user_text: str, output_path: str): # 1. 解析意图 spec parse_user_input(user_text) print(解析结果:, json.dumps(spec, ensure_asciiFalse)) # 2. 构建模型 model build_model(spec[operations]) # 3. 校验并导出 save_step(model, output_path) print(STEP 文件已生成:, output_path) if __name__ __main__: text_to_cad( 做一个长 100 宽 50 高 20 的长方体四条竖直边做半径 5 的圆角, demo.step )我在本地实测时输入这句话大概 1 秒多就能拿到 STEP 文件整个流程非常流畅。你用 Fusion 360 或 FreeCAD 打开这个 STEP 文件能看到一个带圆角的长方体实体虽然不是多惊艳的模型但“从自然语言到工业模型”的链路已经完整跑通了。5. 实战案例三个典型的文本到模型任务代码搭好之后我更想聊的是怎么把它用到实际场景里。下面三个案例分别对应了标准件、自由特征、特征阵列三种常见建模需求难度依次增加帮你理解 text-to-cad 在“能用”和“好用”之间的差别。5.1 案例一标准件“M8 的内六角螺栓”标准件是 text-to-cad 目前落地最容易的场景因为它的参数可以被高度模板化。比如 M8 内六角螺栓的头部直径、头部高度、六角孔对边距、螺纹公称直径、螺距等参数在标准手册里都是固定的。你要做的只是让 LLM 输出几个必要的可变参数比如螺纹长度、总长度然后在地图里查表补全其他参数。输入一个 M8x30 的内六角螺栓螺纹长度 20 毫米理想情况下LLM 解析出的参数应该是{thread_type: M8, total_length: 30, thread_length: 20}。然后模板函数从参数表查出头部直径 13 毫米头部高度 8 毫米六角孔对边距 6 毫米再用 CadQuery 或 OpenCascade 依次生成头部六角体、螺纹柱、倒角等特征。这类模板化方案的好处是稳定每个参数都有据可查出活快而且永远不会出现几何错误。5.2 案例二带圆角的壳体类零件壳体类零件比标准件灵活因为长宽高和圆角半径都是自由参数LLM 的自由度更大但也更容易出错。比如用户说“做一个外壳长 120 宽 80 高 30壁厚 3顶面四个角圆角 10”。输入一个塑料外壳长 120 宽 80 高 30壁厚 3顶面四个角 R10正确解析后的操作逻辑应该是先建立一个 120×80×30 的外轮廓长方体再在里面建立一个缩进壁厚后的内腔并做切除。这个过程中LLM 需要正确理解“壁厚 3”的含义而不是把整个模型都缩小 3 毫米。这里就体现出 prompt 设计和模板设计的重要性了——你需要在系统层面把“外壳、壁厚、圆角”这些常见术语映射到正确的几何操作序列上。5.3 案例三带阵列安装孔的底座阵列安装孔是机械设计中非常常见的需求而且它的描述方式多种多样很考验解析能力。用户可以说“四个角打孔”也可以说“两排三列间距 50”还可以说“沿着 X 轴阵列 5 个”。输入一个 200x100x10 的底座上面打 6 个直径 6 的安装孔两排三列X 向间距 60Y 向间距 40这种场景下功能模块的划分又变了。你需要先建立一个hole_array模板函数接收孔直径、行列数、行列间距等参数然后用 CadQuery 的rarray方法一次生成所有孔位。LLM 的职责不再是从零构造整个模型而是把自然语言里的阵列信息映射到rarray的参数上。经过这种拆分之后看起来复杂的需求实际落到代码上就只有几行。我做了这么多案例之后的感受是text-to-cad 真正工程化的时候重点不在于提高 LLM 的“智商”而在于提前设计好你的模板函数库和意图词表。模型能跑通 100 种描述方式远不如 50 个设计良好的模板函数有价值因为后者让你永远处于可控状态。6. 常见问题与避坑指南这部分是我实际调试 text-to-cad 工作流踩过坑之后总结出来的基本每条都是真金白银换来的教训。6.1 单位不统一尺寸整个错乱LLM 在处理“英寸”和“毫米”时经常出问题。比如用户说“做一个 5 英寸见方的盒子”模型很可能会直接当成 5 毫米生成这在制造场景里是灾难。我的对策是在系统 prompt 里强制声明默认单位毫米并且要求 LLM 在输出 JSON 时始终带上单位字段再在代码里统一转换。最好的做法是你在意图解析阶段就规范化单位永远不要拿原始数值直接建模。6.2 LLM 输出的 JSON 不稳定哪怕已经用了 JSON 模式我也遇到过输出内容里夹带多余文本、偶尔嵌套代码块、甚至直接给你一段 Markdown 的情况。所以我在parse_user_input函数里加了几层防御性清理去掉首尾空白、剥掉代码块标记、如果解析失败就重新请求一次。这些都跑完还不成功就让系统返回“没听懂”而不是拿脏数据去建模。6.3 倒角失败、实体退化fillet和chamfer操作对参数非常敏感圆角半径太大、太小、或者模型中存在退化边都可能导致建模内核抛异常。我之前做的一个 R5 圆角操作因为某个面被切割后残留了一条极短的边CadQuery 直接报错。解决办法是先检查模型的最小边尺寸再动态限制圆角半径的上限另外尽量在特征操作完成后统一做圆角不要在中间状态频繁操作。如果你追求高稳定性最好在 geometry 操作外面包一层 try-except一旦失败就回退到无圆角版本并给用户明确提示。6.4 上下文一长描述就丢信息用户说“还是刚才那个底座不过孔距改小一点”系统需要记住上一轮生成的模型状态。实现多轮对话式 text-to-cad 比单次生成复杂很多。我建议把历史对话中涉及的关键参数持久化到一个上下文字典里每次用户输入先和这个字典合并再构建新的完整 prompt。不要尝试让 LLM 自己记住状态它是真的会忘而且忘得很没有规律。6.5 Token 成本和响应延迟我实际测试下来单次意图解析大概消耗几百到一两千 token如果每次都在 prompt 里塞一大堆模板和示例成本会明显上升。优化方法有两个一是精简 system prompt只保留最关键的信息二是把常用模板和参数表放到代码里不要塞进对话上下文。后者既省 token 又提升准确率因为 LLM 不需要在输出的 JSON 里重复输出那些固定参数。7. 这个方向还能往哪走我的个人经验与扩展建议跑通整套 text-to-cad 流程之后我自己最大的感受是这东西现阶段还不是“无脑生成”更像是“把自然语言转换成参数化建模的指令语言”。它最大的价值是让原本需要熟悉 CAD 命令才能实现的建模过程变成了一句人人都能说的人话。制造业里积累了大量标准件库、零件族模板这些如果能被语言模型唤醒设计师的重复劳动会大幅减少。我给想继续深入的朋友三个方向第一去完善某个垂直领域的模板库比如钣金件、法兰、机箱外壳别贪多第二接入本地大模型把整套链路完全私有化部署解决数据安全问题这也是很多制造业客户的核心诉求第三把 text-to-cad 和拓扑优化、仿真分析连起来让 AI 不仅帮你把模型建出来还帮你把模型改好。说实话前两条路线的拼图已经基本现成就差有人把它们认真串起来了。如果你也在跑 text-to-cad 相关的工作流建议先把我上面的最小示例跑一遍把“一句话到 STEP 文件”的链路刻在脑子里再去填你自己的模板库。这个方向很有意思但需要耐心我试错的成本比别人高是因为我一开始就试图让模型一步到位生成复杂装配体结果翻车翻得很惨。从最简单、最可控的场景开始才是最快到达目的地的路。