文本转CAD：从自然语言到可编辑模型的落地实践

几个月前我在设计院和一个做施工图的朋友聊天，他半开玩笑地说了句："哪天我只要说'给我做个三层的办公楼，外立面用玻璃幕墙，带个屋顶花园'，CAD就能自己把图画出来，我就真解放了。"这句玩笑话放到今天，还真不是天方夜谭——text-to-cad（文本转CAD）这几年已经从论文里的demo，慢慢变成了能摸到、能落地、能塞进实际工作流的工具雏形。

所谓text-to-cad，简单说就是通过自然语言描述来驱动CAD模型的生成：你说一句话，它帮你把对应的几何体、草图、特征、甚至完整的零件模型搭出来。听起来很魔幻，但它背后并没有脱离CAD建模的本质，而是把"人通过鼠标键盘操作命令"这一层，替换成了"自然语言->结构化建模指令"的自动翻译。这篇文章我想从技术原理、落地路线、实际效果和翻车现场几个层面，把text-to-cad这个方向聊透。不管你是机械设计、建筑设计、电气布线还是做钣金加工的，都可以借此评估它离自己的日常到底有多远、现在能不能用、用起来怎么个用法。

1. text-to-cad的本质：为什么"会说话就会画图"至今没被完全实现

先说一个经常被误解的地方：text-to-cad不是让电脑"听懂人话"，而是让电脑"把你的话转成它本来就会执行的操作序列"。这里面最大的难点，从来不在语言理解本身，而在"语言到几何之间那道鸿沟"。

1.1 语言描述的天然模糊性与CAD的精确性冲突

CAD模型的本质是什么？是精确的、参数化的、能被制造和施工的几何定义。一根轴的长度是120mm还是119.5mm，在图纸上差之毫厘，实际加工出来就是废品。但自然语言天生是模糊的："一个差不多大的孔""稍微厚一点的板""放在大约中间的位置"——这些词人类听得出意思，机器却完全无法直接映射成数值。

所以text-to-cad要做的第一件事，不是"理解"你的意图，而是把模糊意图变成确定参数。目前比较聪明的做法是引入约束求解和默认假设：比如你说"开个通孔"，它就默认孔是圆形的、贯穿整个厚度、居中对齐；你说"加强筋"，它就默认是三角形筋板、厚度为壁厚的0.6到0.8倍。这些默认值其实不是模型自己"想"出来的，而是训练数据里大量既有设计习惯的统计结果。

用通俗的话讲：text-to-cad本质上是一个"填槽机器人"，它先识别出你描述里的关键实体和属性，再拿一套预置模板把剩余参数补全。所以它不受语言学派那些花里胡哨的语义理解理论制约，真正考验的是"槽位抽取准不准"和"模板覆盖全不全"。

1.2 CAD数据结构的门槛：从离散面片到参数化特征的鸿沟

这里有个更容易被忽略的技术壁垒。很多AI生成3D内容的工具（比如生成网格模型、生成NeRF场景）输出的是三角面片数据，这东西拿来渲染、拿来做视觉预览没问题，但拿来加工和生产就是灾难——因为面片模型天生没有特征树、没有尺寸约束、没有拓扑关系，你根本没法像编辑普通CAD文件那样改一个参数，整体联动变化。

而text-to-cad要真正进入工程领域，必须直接生成参数化特征历史（feature history），也就是要生成一长串操作序列：先干嘛、后干嘛、草图长什么样、拉伸多少、切掉多少、倒了多大圆角。这就要求模型在输出几何的同时，还在做一个"规划"任务——它必须理解建模步骤之间的依赖关系。

我见过不少新手在尝试这类工具时遇到同一个困惑：既然AI画图这么牛，为什么生成的模型看起来还行，一进CAD软件却"没法编辑"？答案就在这里——因为它生成的是"看起来像"的网格，不是"能被参数驱动"的特征模型。真正意义上的text-to-cad，要的是后者，而这也是目前绝大多数通用图像生成模型做不到的。

1.3 从"生成一根轴"到"生成一台机器"的难度放大

还有一个经常被低估的问题：复杂度的指数级增长。你说"生成一个法兰盘"，也许几秒就出来了；但你要说"生成一个减速机"，里面的齿轮、轴、轴承、箱体、密封件之间的配合关系、干涉检查、运动约束，根本不是一句自然语言能涵盖的。

所以现在真正可用的text-to-cad工具，基本都聚焦在单零件、规则几何、简单装配这个层面。想要一句描述直接生成完整装配体，至少在现阶段就是伪需求。这个认知很重要，它可以帮你在评估工具时保持清醒，不至于被demo视频里那些炫酷的展示误导。

2. 可行路线：从语言描述到可编辑CAD模型的三种主流实现方式

既然目标是生成可编辑、可制造的参数化模型，那现在就存在三条技术路线，各有取舍。我把它们对比着讲，方便你按自己的需求选择。

2.1 大语言模型驱动脚本代码生成

这是目前最容易落地、也最适合普通设计师尝试的路线。原理不复杂：调用大语言模型（LLM），让它在你选定的CAD平台上生成对应的脚本代码，比如SolidWorks的VBA宏、FreeCAD的Python脚本、AutoCAD的AutoLISP或者OpenSCAD的代码，然后在CAD软件里执行脚本，自动把模型建出来。

这条路线最大的优势是透明可控。脚本代码是明文，你可以检查、修改、重新执行；而且它直接调用CAD原生内核，生成的就是正经的参数化特征。我实际测试过用LLM生成FreeCAD脚本，给一句描述："生成一个直径50mm、长度100mm的圆柱体，顶部带一个直径10mm、深度8mm的中心孔"，模型生成的Python脚本直接跑通，特征树干净标准。这个体验比"生成网格再转格式"舒服太多。

缺点也很明显：LLM生成的代码质量不稳定，一遇到复杂几何就容易出Bug，比如漏掉一个坐标系转换、搞错一个旋转方向，生成的模型就是歪的。而且它对CAD平台API的认知依赖训练数据，如果你的平台比较冷门，模型可能一本正经地编造出根本不存在的API函数。

2.2 专用数据集训练的text-to-CAD模型

这是学术界和工业界都在猛攻的方向。思路是用大量参数化CAD模型及其对应的自然语言描述训练一个专门的生成模型，典型代表是斯坦福等机构开源的项目，让模型直接学会从文本到序列化建模指令（Feature Tree）的映射。

这条路线的上限很高，因为它是在"建模逻辑"层面解决问题，而不是靠拼凑脚本。理论上，模型学会了"开孔"对应什么命令、"倒角"对应什么参数，就能组合出复杂的建模流程。但我个人判断，它的成熟期还远未到来——专业数据集目前规模有限、标注成本极高、泛化能力差。换句话说，你现在能玩到的demo，大概率只对训练集里的那几类形状效果好，换个冷门结构就露馅。

2.3 规则模板驱动的"意图识别+参数匹配"

说说目前企业落地最务实的路线。它不看什么炫酷的AI模型，本质上是把常见的设计场景做成模板库，再用一个意图识别模块把用户的话映射到某个模板，然后抽取出关键参数填入模板，最后调用CAD API生成模型。

比如在电气设计里，你说"放一个双联开关，距地1.2米"，模板库里有"墙壁开关布置"这个模板，意图识别模块抽出"双联"、"1.2米"两个参数，其余坐标、连线规则全部走默认值，一键生成。这条路线的精髓在于"不求广，只求准"——模板覆盖的范围可以很窄，但每一个模板都做得极其稳定可靠。

它虽不性感，但很管用。自动化设计工具真正进工厂，走的都是这个路线。text-to-cad这个概念要想变成生产力，短期内大概率还是要靠这种"AI做识别、模板做兜底"的组合。

下表把这三种路线的核心差异做了个对比，方便你直接判断该关注哪个方向：

3. 落地实践：用自然语言驱动参数化草图与特征建模的完整流程

前面讲了不少原理，可能你还是觉得虚。这章我拿一个具体案例，从头到尾演示一次text-to-cad的实操流程。选什么平台？我个人推荐FreeCAD——因为它是开源免费、带完整Python API、任何读者都能零成本跑通的软件。而且用脚本建模的体验和商业软件没有本质差别，学会了这套逻辑，换到SolidWorks、中望CAD等平台只是换个API的问题。

3.1 环境准备与工程化思路

先用一段话概括我要做的事：给定自然语言描述，让大语言模型生成FreeCAD Python脚本，再在FreeCAD中执行脚本完成实体建模。为了让这个流程可复用，我把它拆成三个模块，各干各的活：

• 描述输入模块：接收用户的一句话需求，这里顺便设定好输出格式要求，比如"必须是Python脚本、必须使用FreeCAD的Part设计工作台API、必须在脚本末尾输出模型的体积和质量属性"。
• 生成与校验模块：调用大语言模型接口生成代码，然后做一个静态检查——查一下有没有明显的问题，比如是否引用了不存在的模块、是否缺少关键步骤。这一步看起来简单，但它能拦截掉大量低级错误。
• 执行与反馈模块：在FreeCAD里执行脚本，执行完采集报错信息，把报错扔回给大模型做自我修正。这实际上是给AI加了一道"试验-纠错"的闭环，能明显提高成功率。

用Python把这三个模块串起来，写一个简单的命令行工具。贴一段核心示意的代码，它做的事是：读取描述的JSON配置，调用LLM接口获取代码，然后通过FreeCAD的命令行接口执行脚本：

import subprocess import openai import json def get_cad_script(description: str) -> str: prompt = f"""请根据以下自然语言描述，生成一段FreeCAD Python脚本，要求： 1. 使用FreeCAD的Part模块创建实体 2. 所有尺寸显式定义为变量 3. 脚本末尾输出模型体积 描述：{description} 只输出Python代码，不要附加任何解释。""" resp = openai.ChatCompletion.create( model="gpt-4o", messages=[{"role": "user", "content": prompt}], temperature=0.2, ) return resp.choices[0].message.content def run_script_in_freecad(script: str) -> str: with open("_gen_model.py", "w", encoding="utf-8") as f: f.write(script) proc = subprocess.run( ["freecad", "console", "_gen_model.py"], capture_output=True, text=True, timeout=120 ) return proc.stdout + proc.stderr if __name__ == "__main__": desc = "生成一个外径60mm、内径40mm、高度20mm的环形垫片，边缘倒角0.5mm" script = get_cad_script(desc) result = run_script_in_freecad(script) print(result[-2000:])

之所以要把脚本执行放在子进程里，而不是直接在FreeCAD的GUI里跑，原因很简单：子进程可以严格控制执行时间，加了timeout参数，防止模型生成死循环脚本把CPU占死；而且子进程的stdout能干净地拿到报错信息，方便后面做自动纠错。

3.2 一个真实生成案例的前后对照

这里看一个实际跑通的例子。我给大模型输入这句描述：

"生成一个法兰盘，外径100mm，内径50mm，厚度15mm，周围均匀分布6个直径10mm的螺栓孔，孔中心所在圆直径为80mm，外缘倒角2mm。"

模型经过两轮纠错后给出的核心脚本如下：

import FreeCAD as App import Part D_out = 100 D_in = 50 thickness = 15 bolt_circle_d = 80 bolt_d = 10 bolt_count = 6 chamfer = 2 doc = App.newDocument("Flange") # 主法兰体：外圆拉伸 outer_wire = Part.Wire([Part.Circle(App.Vector(0,0,0), App.Vector(0,0,1), D_out/2)]) outer_face = Part.Face(Part.Wire(outer_wire.Edges)) inner_wire = Part.Wire([Part.Circle(App.Vector(0,0,0), App.Vector(0,0,1), D_in/2)]) inner_face = Part.Face(Part.Wire(inner_wire.Edges)) ring = outer_face.cut(inner_face) ring_solid = ring.extrude(App.Vector(0,0,thickness)) # 螺栓孔 for i in range(bolt_count): angle = 360/bolt_count * i x = bolt_circle_d/2 * __import__("math").cos(__import__("math").radians(angle)) y = bolt_circle_d/2 * __import__("math").sin(__import__("math").radians(angle)) bolt_hole = Part.Circle(App.Vector(x,y,0), App.Vector(0,0,1), bolt_d/2).extrude(App.Vector(0,0,thickness)) ring_solid = ring_solid.cut(bolt_hole) # 外缘倒角 edge_to_chamfer = ring_solid.Edges[0] # 简化：取第一个边缘 ring_solid_ch = ring_solid.makeFillet(chamfer, [edge_to_chamfer]) Part.show(ring_solid_ch) doc.recompute()

执行之后，FreeCAD的模型树里清清楚楚地出现了"Ф100×15法兰盘、6×Ф10阵列螺栓孔、外缘倒角2"这个模型的所有特征。整个过程从输入文字到拿到模型，总共不到1分钟——换手工画，再快也得三五分钟，还得担心孔距算错。

这类案例的意义在于：text-to-cad其实已经开始具备"初级生产力"了。但注意我加了限定词——"初级"。因为一旦模型形状复杂一点，比如生成一个带加强筋的不规则壳体、或是一个需要多个基准面的支架，脚本就会开始大量出错。这个边界在哪，下面单独说。

3.3 纠错闭环：为什么你的AI生成脚本总是一次跑不通

说句实话，在我测试的几十个例子里，一次生成就完美跑通的，不到三成。大多数情况是代码有语法错误、漏了导入模块、坐标系搞错、布尔运算报错等等。这些东西你能接受吗？能。关键在于你要为AI配一个"纠错闭环"。

我的做法是这样：执行脚本拿到报错信息后，不要急着人工分析，直接把报错文本、出错行、以及原始需求一次性拼回给大模型，让它出修改版。这个迭代过程快的话一两轮、慢的话五六轮，最终能跑通的概率会大幅提升。核心代码如下：

def auto_repair(description, script, error_msg, max_rounds=5): for i in range(max_rounds): result = run_script_in_freecad(script) if "Error" not in result and "Traceback" not in result: return script prompt = f"""你生成的FreeCAD脚本执行报错了。 原始需求：{description} 当前代码： {script} 错误信息： {result[-1500:]} 请根据错误信息修正代码，只输出修正后的完整Python代码。""" resp = openai.ChatCompletion.create( model="gpt-4o", messages=[{"role": "user", "content": prompt}], temperature=0.1, ) script = resp.choices[0].message.content return None

不过要提个醒：自动纠错不是万能的。遇到重复出错超过5轮，下面两种原因居多：一是你的原始描述里有自相矛盾的尺寸要求（比如外径小于内径），模型怎么改都不可能合法；二是模型一直在用不属于FreeCAD的API，比如混入SolidWorks的命名习惯。这种时候别硬调，赶紧人工介入，或者在prompt里把API文档片段喂给它参考。

4. 实际项目中的效果与翻车现场：它能做什么、做不了什么

前面说的都是单零件实验。到了真实工程项目里，text-to-cad的表现是什么样的？我直接把它放进几个典型工作流里做了测试，结果有好有坏。这一章我用对比的方式讲透，帮你建立对这项技术的正确预期。

4.1 表现稳定的场景：标准化零件与参数化族设计

在标准化程度高的领域，text-to-cad已经可以直接上岗。我试了几个典型场景：

• 法兰、垫片、轴类零件：只要你把外径、内径、孔数、倒角尺寸说清楚，生成结果基本零失误，而且特征树干净，改参数就跟改模板一样自然。
• 钣金折弯件：描述"板厚1.5mm，折成U型槽，外宽60mm，槽深40mm，折弯半径1.5mm"，模型生成的脚本一气呵成，还能自动展开成平面视图，直接对接激光切割。
• 建筑构件标准化布置：一句话在图上布一批尺寸规格统一的窗框、门洞、设备基础，正确率极高，因为它本质上就是"参数化族+规则摆放"。

这几个场景的共同特征是：形状比较规则、参数维度少、尺寸间有明确数学关系。AI在这种地方发挥的不是"想象力和创造力"，而是"快速准确的执行力"，恰好是它最擅长的事。

4.2 崩溃高危区：异形曲面、多基准面配合与装配逻辑

一旦跨过规则几何的边界，text-to-cad的体验就会急转直下。我遇到的典型翻车案例包括：

• 用曲线放样生成异形壳体，模型生成的放样路径和截面轮廓方向经常不一致，导致曲面严重扭曲。可能是生成算法对"曲线方向"这个隐式约束理解不到位。
• 多基准面上的特征建模，比如要在三个不同角度的面上各开一个异形槽，它生成的草图和拉伸方向经常乱套，特征树里一片红。
• 涉及装配关系的场景更惨：让它"生成一个装两个轴承的轴承座，内孔与轴承外圈配合"，它能画出单个零件，但对"配合"这种语义完全没有概念，生成的两个零件在装配空间里统统都是世界坐标系原点。

把这些翻车案例放在一起看，结论非常清楚：text-to-cad目前是单零件的"描述员"，不是整机级的"设计师"。如果你想让它直接替代工程师画总装图，还早得很。

4.3 实际工作中怎么正确使用它：人机分工的正确姿势

那么现在就完全不能用了吗？当然不是，关键看你把它放在工作流的哪个环节。

我个人的做法是把text-to-cad当成"草稿生成器"和"模板预填器"。比如做一个标准件库，以前要对着手册把所有规格的模型一个个手动建，现在写一段支持参数扫描的脚本，让AI一次性批量生成几十个规格的模型，再用CATIA或SolidWorks的批量导入接进产品数据管理系统，效率提升非常明显。再比如设计前期做概念方案，AI快速生成几种不同尺寸比例的初版形态，设计师评估之后挑一个，在AI生成的参数化模型基础上继续精修，这个流程比从零建模快很多。

核心原则就一句话：让AI做它擅长的高速草拟，把判断和决策留给自己。如果你抱着"说一句话CAD全画好"的预期来用，多半会失望；但你把它当成一个思维敏捷、偶尔马虎的新实习生，给它明确任务边界、验收标准，结果会惊喜不少。

5. 从玩票到生产力：text-to-cad嵌入现有CAD工作流的三个关键问题

最后这章，聊点更实际的东西。工具选型其实不是最难的，真正难的是把text-to-cad这类能力塞进你现有的CAD环境和工作流程里，让它成为日常的一部分，而不是又一次"尝鲜后吃灰"。根据我自己的经验，有三件事必须提前想清楚。

5.1 与现有CAD平台打通：别绕开原生格式

很多人忽略了一个细节：text-to-cad工具再聪明，生成的东西如果不能直接进你的主力CAD软件，价值就得打八折。你在用中望CAD、AutoCAD、SolidWorks还是FreeCAD？每个平台的脚本接口、文件格式、二次开发方式都不一样。选路线之前，先确认你平时画图的是哪款软件。

以国内用的比较多的几款为例：

• FreeCAD：Python脚本接口完整，文本生成脚本的路线最顺，而且是开源免费的，最适合练手。
• SolidWorks：有VBA宏和API，但COM接口比较复杂，大模型要准确写对SolidWorks API需要比较强的训练支撑，实测错误率偏高。
• AutoCAD：AutoLISP虽然老，但语法简单，模型很容易上手；另外它也支持.NET API，适合做稍复杂的自动化。
• 中望CAD：兼容AutoCAD的LISP接口，所以AutoCAD能用的脚本，中望上基本也能跑，迁移成本很低。

所以如果你是个人玩票，直接FreeCAD；如果在企业里落地，优先考虑你现有CAD的那套API体系。不要为了用text-to-cad去换掉你已经用熟的工具，那是本末倒置。

5.2 企业落地的门槛：模板库、验收标准和数据沉淀

企业里想真正把text-to-cad用起来，不是给工程师装个AI工具那么简单。我观察到的可行做法是三步走：

第一步是把你业务里最高频的零件按类别整理出来，建一套参数化模板。这一步本质上是在给AI划定它只擅长的小领域，比如"法兰类""轴套类""钣金支架类""电缆桥架类"，每类定义好尺寸变量、默认工艺值。

第二步是给AI接一个固定的输入格式，让工程师按表格填参数，然后再由AI自动补全描述，生成建模脚本。不要让人直接打自由自然语言——太自由了反而容易出错。规范化的表格+固定提示词模板，能让成功率稳定维持在很高水平。

第三步是所有的生成案例、错误案例都录进数据库，定期把错误类型反馈给prompt模板，持续迭代。这个闭环一旦跑起来，工具会越用越准，走的就是"规则模板+意图识别"那条务实路线。别一上来就追求什么大而全的通用AI，那不叫落地，叫砸钱。

5.3 版权、数据与审图责任：AI画完图谁签字

最后提一个在项目里必须面对、但很多技术帖不讲的问题——责任归属。生成式AI训练数据里有没有别人家的设计图纸？AI生成的模型如果抄袭了某个专利设计，算谁的？这些都是悬而未决的问题。我自己的建议是：宁可多花点时间用AI生成"概念草稿"，也别把AI生成的最终模型直接发出去用于制造或报审。关键环节必须有持证工程师的审核和签名，这既是对项目负责，也是对自己负责。

另外，如果你所在的公司有严格的数据保密要求，直接调用云端大模型接口要格外小心。你输入的零件描述，本质上也是一种技术秘密。合规的做法是部署私有化模型，或者至少在脱敏后再描述，把关键尺寸模糊掉，只保留形状逻辑。这个问题现在没出大事，是因为真正把text-to-cad当生产力用的企业还少，但将来一旦普及，数据合规就是绕不开的坎。

6. 我做了几十个测试后的实操体会和下一步建议

写了这么多，最后想分享几个我在反复测试中体会最深的事。

第一个体会是：提示词的结构化程度，直接决定生成质量。你给AI一个"做个连接件吧"这种笼统描述，得到的只能是垃圾脚本。正确做法是把它当成给新人派活：先给整体目标，再列关键尺寸，最后提特殊要求。比如"生成一个L型连接支架，水平臂长80mm、垂直臂高60mm、厚度8mm、水平臂末端开一个直径12mm的圆孔、垂直臂根部加一个三角加强筋、材料默认Q235"，成功率和信息完整度强相关，这句话里每一个数字都会变成脚本里的一个变量。

第二个体会是：不要试图让AI理解工艺合理性。它知道"直径10mm的孔"，但它不知道这个孔距离板边太近会导致加工时崩边；它知道"倒角2mm"，但它不知道这个倒角在装配时会不会跟隔壁零件干涉。工艺审查请务必自己做，这跟有没有AI无关。

第三个体会特别想分享给正在选工具的朋友：判断一个text-to-cad工具好不好用，别只看它生成模型有多快，要看它生成的模型能不能改。能不能在设计树里看到特征？能不能双击尺寸然后从头更新？能不能在不推翻整个设计的前提下调整某个细节？这几点决定了它到底是生产工具还是玩具。好的工具生成的是"过程"，差的工具只给你"结果"。

至于下一步，我打算沿着"规则模板+意图识别"这个方向做一个小工具集，先把自己工作里最高频的十来类零件做成模板，再用大模型做参数抽取，目标是让新来的工程师也能用大白话驱动模型生成。等这套跑顺了，再考虑扩展模型类型。这条路没什么玄学，就是踏踏实实把AI能力嵌进CAD工作流的一个小角落，但它带来的效率提升，是实实在在的。

说到底，text-to-cad与其说是一个技术概念，不如说是一种交互范式的变化——我们正在从"用鼠标指挥CAD"慢慢过渡到"用语言指挥CAD"。这一天不会一夜之间到来，但它已经在路上了。