刚接触设计软件那年带我的师傅反复说一句话好的图纸不是画出来的是想出来的。当时不理解直到做了几年方案设计、天天和各种零件图纸打交道才慢慢明白他的意思——画图只是把设计意图落地的最后一步前面那些构思、计算、约束、取舍才是真正花时间的地方。而这两年逐渐火起来的text-to-cad方向恰恰是在解决这个核心问题能不能直接用一句自然语言把脑子里的想法变成可编辑、可出图、可加工的CAD图纸text-to-cad翻译过来就是文本转CAD本质上是一条自然语言 → 结构化设计参数 → 几何模型 → 工程图纸的自动化链路。它不是简单地在画布上画个圆、拉根线而是让计算机理解你说的一块带中心孔的法兰盘外径50厚度5到底需要构建什么样的几何体、施加什么样的约束、配什么样的标注。适合谁看我的判断是三类人做设计但每天被重复建模耗掉太多时间的工程师想把手绘草图或口头需求快速变成图纸的创业者以及刚刚接触CAD、想知道这个行业未来会怎样演化的新手。这篇文章不会堆术语我会按照我实际折腾这套流程的经验把原理、选型、踩坑、复现路径尽量讲透。1. text-to-cad在解决什么问题1.1 从一句话到一张图技术语义拆解我们先把这四个字母拆开看。text是输入CAD是输出中间那条横线to才是技术含量最高的地方。为什么这么说因为从文本到CAD不是一次简单的翻译而是一次从自然语言到形式化语言的跨域映射。人的语言极度模糊。你说做一个支架支架可以是L形的、T形的、三角形的可以是钣金件也可以是焊接件孔位可以两边的也可以四角的。同一个词在不同老师傅脑子里对应的是完全不同的模型。传统CAD软件解决不了这件事因为它的建模逻辑是你告诉它做什么、怎么做而text-to-cad的逻辑是你告诉它要什么、它自己决定怎么做。要做到这一点系统内部至少要完成四步工作。第一步是意图提取。大语言模型把做一个带中心孔的法兰盘解析成法兰盘中心孔两个核心要素顺带识别出隐含的连接方式、受力方向、配合关系这些没说出口但设计者默认的信息。第二步是参数抽取。系统要把描述中出现的具体数值抽出来——50mm、10mm、5mm还要补齐没说的值比如你没有指定法兰盘的螺栓孔数量时它会按照通用规则默认为4个均布孔。第三步是参数化建模执行。这一步会调用CAD内核用脚本语言把参数变成实际几何体。第四步是输出标准化生成符合制图规范的图纸包括但不限于图层、线型、标注样式、标题栏。很多人问这不就是个自动化宏吗还真不是。自动化宏是固定的流程参数一变整个流程就可能崩。text-to-cad是动态的它能在建模过程中根据描述自动调整构建顺序和约束关系这完全是两个量级的技术难度。1.2 text-to-cad与传统CAD操作的本质差异传统CAD操作的本质是手工作业加软件辅助。你脑子里有个模型手上用矩形、圆弧、倒角这些命令一点一点堆出来。这个过程非常考验空间想象力也极度依赖熟练度。我见过太多新手理论知识背得滚瓜烂熟一到软件里连个视图切换都找不到更别提什么草图约束、父子关系了。text-to-cad改变的是人机交互方式。它把操作软件变成了描述需求。打个比方传统CAD像是你亲自下厨一步步切菜、放油、翻炒text-to-cad则像是你告诉厨师我要一盘鱼香肉丝后面备菜、调味、装盘全交给后厨。前者给你对过程的完全控制后者把你从重复劳动里解放出来。这种差异带来的好处集中体现在三个方面。第一上手门槛大幅降低。不会画图的人也能通过一句话生成图纸样稿这听起来好像是在降低设计师的价值实操中其实是把设计师从画图里拉回到真正的设计思考上。第二批量变体效率翻倍。传统方式做一个系列零件比如5种不同直径的法兰盘你得重复进入草图环境改尺寸、更新特征一个不小心还容易因为约束冲突报错。text-to-cad只需要在描述里改一个数字剩下的交给程序处理。第三设计意图完整保留。传统画图流程中最终图纸只能看到几何看不到当初为什么这么设计。text-to-cad可以顺带保留描述中的使用工况、材料要求、加工工艺这些语义信息后续改图时这些信息会直接参与判断。当然也别急着把CAD软件卸载。理解两者的差异更重要——text-to-cad是新的前端传统CAD是必须的后端几何内核、制图规范这些东西它依然离不开后面你会看到这一点反复出现。1.3 为什么这两年才火起来技术底座的变化text-to-cad这个概念其实不算新早在参数化设计刚出来的那几年就有人尝试过当时做出来的东西只能算玩具。为什么因为传统规则系统处理不了自然语言的多样性和歧义性。你说圆板它只能匹配到预设的圆板模板换个说法带孔的回转体它立刻就懵了。这两年情况发生了本质变化背后的技术底座主要在三方面。第一是大语言模型带来的语义理解能力。模型知道回转体和圆柱是什么关系知道法兰默认带有螺栓孔和中心孔这是基于海量语料训练出来的常识不是规则表能覆盖的。第二是拓扑推理能力。现代的几何约束求解器越来越强能够处理复杂的特征依赖关系。别再拿它跟早期玩具项目比了。第三是可执行代码生成能力。大模型能把几何描述转换成Python脚本驱动FreeCAD、AutoCAD、SolidWorks这些软件干活。这一层相当于打通了语言模型和CAD引擎之间的任督二脉AI生成的脚本经过语法校验后可以直接执行。技术底座成熟了应用起来才有价值。所以别看现在text-to-cad的工具还不够完美方向已经非常清晰。真正要研究的是它和现有工作流怎么接、边界在哪、哪些环节必须人工把关。2. 核心技术点拆解语义怎么变成几何2.1 自然语言解析从描述到结构化参数我把这套流程从头到尾跑过一遍之后最大的感受是最难的不是建模而是怎么让程序准确理解人话。你跟我说的做一个圆板和我跟我同事说的做一个圆板表达的复杂程度完全不同。所以任何text-to-cad系统第一步必须是规范化描述。现在的方案基本有两种。一种是受限输入系统提供固定的表格模板让你填参数一种是用大模型自由解析你随便说它努力理解。后者的做法通常是把解析结果输出为JSON格式的结构化参数。举个例子同样一句帮我画一个直径50厚度5的中心带孔圆板解析后可能是{ object_type: circular_plate, params: { outer_diameter: 50, thickness: 5, center_hole: { exists: true, diameter: 10 }, unit: mm, material: unspecified } }这样一来后面的建模引擎就不用面对杂乱的自然语言了。它只需要读取这个JSON识别object_type是circular_plate然后调用对应的建模块传入参数。这一步看起来简单实操里容易出问题的点在于隐含信息的补全。你只说带孔圆板没说要几个孔、孔怎么分布。做机械设计的都知道孔的位置分布是图纸的灵魂错一个孔位整个零件就废了。现在的方案是先按行业默认值推断比如中心孔直径取外径的20%、均布孔数量取4个然后给用户一个确认和修改的环节。这比完全放到生成后几何上调整要可靠得多。2.2 参数化建模最核心的一环参数解析之后下一环就是把参数变成真正的几何实体。这里我可以负责任地说所有直接生成像素级别图片的方案在工程CAD里都靠不住。图纸要求的是精确的数学描述不是模糊的渲染效果图。当前最可靠的路线是参数化建模。参数化建模的实现方式我实践下来有三种各有各的适用场景。第一种是直接调用CAD软件的脚本接口。比如AutoCAD的ActiveX接口FreeCAD的Python APISolidWorks的API加宏录制。这种方式生成的模型和手工绘制的模型完全一样可控性最强能保留完整的历史树但前提是你能读懂软件API文档初始开发成本高。第二种是用独立的几何内核库比如Open CASCADE。用Python封装之后可以直接在内存中构建模型再导出为STEP、IGES或DXF。这种方式轻量适合批量生成但没有图形界面调试靠可视化插件。第三种是用DXF/SVG这种2D通用格式直接画图。适合激光切割、线切割、钣金展开这类平面的场景。我自己的习惯是做三维零件时优先用FreeCAD的Python API因为它是开源的不需要为正版软件授权发愁脚本写错了也不毁坏工作环境。做二维图纸时优先用ezdxf库直接生成DXF输出轻量、兼容性好几乎所有CAD软件都能直接打开。贴一段我实际跑通过的代码就是用ezdxf画一个带中心孔的圆板import ezdxf # 创建新文档使用AutoCAD 2018格式 doc ezdxf.new(R2018) msp doc.modelspace() # 设定参数 outer_r 25.0 # 外圆半径 hole_r 5.0 # 中心孔半径 # 添加外圆和中心孔 msp.add_circle((0, 0), radiusouter_r, dxfattribs{layer: 轮廓线}) msp.add_circle((0, 0), radiushole_r, dxfattribs{layer: 中心孔}) # 保存文件 doc.saveas(flange_plate.dxf) print(DXF文件已生成)这段代码就干了text-to-cad流程里执行这一步的活。真实产品里前面那层JSON解析结果会直接填充到这些radius参数里循环跑一遍就能生成一批不同尺寸的同类零件。这才是能落地的批量设计逻辑。2.3 几何约束与图纸规范防止能画但没法用我在第一次跑通text-to-cad流程后最大的挫败不是我画不出来而是画出来了却没法直接投产。原因无他图纸规范这块严重缺课。从文本生成的几何体默认情况下只是个形状。它可能满足了你说的直径50但这张图纸放到车间老师傅根本没法加工视图表达不完整、尺寸标注漏了关键位置公差、没有粗糙度符号、图框标题栏空白、线条粗细不分。所以说任何成熟的text-to-cad系统后面一定挂着一套出图引擎专门负责把裸几何变成能出厂的工程图。具体来说这套出图引擎至少要处理四件事。第一是图层规范化。在CAD里不同线型、颜色代表不同的含义粗实线是轮廓、细实线是尺寸线、虚线是隐藏线、点画线是中心线。脚本生成时要按规则分流不能把一堆线全画在0层上。第二是标注自动排布。尺寸线的位置、字高、精度、前后缀都需要按制图标准生成。第三是几何约束检查。说白了就是过约束检查和欠约束检查该固定的尺寸必须固定不该冲突的约束不要冲突。第四是干涉检测。装配体场景下两个零件不能有重叠实体这一步现在靠人工肉眼检查还是主流但这实在是个糟心的活应该是自动化算法的用武之地。提示这个环节是很多团队做text-to-cad时最容易偷懒的地方。他们觉得只要模型画得像就行却忘了工程图的真正目的是无损传递设计意图。没有规范化的输出前面投入的算力、时间全是白费。3. 实操从零跑通一个text-to-cad最小闭环3.1 环境准备与应用选型思路如果你看完前面原理心里已经痒痒想自己跑一套这一节就是我踩过坑之后总结出的最小可落地路径。先说环境准备。我推荐最低配置如下一台能正常跑Python的电脑装好Anaconda或直接装Python 3.9以上版本一个文本编辑器推荐VS Code一个CAD软件用来打开验证输出文件我自己常用免费的LibreCAD或免费的FreeCAD验证DXF图纸足够了。如果你有商业CAD软件验证起来更方便但没有也不是问题。核心依赖库方面我主要用的是这几个openai或国内大模型接口用来做自然语言解析你也可以用本地部署的模型替代ezdxf用来生成DXF格式的二维图纸pythonocc-core用来做三维几何内核这个包比较大新手可以先不装先用二维跑通全流程。选型思路上很多人一开始就纠结用什么大模型、要不要本地部署。我的建议是先跑通最小闭环别想得太复杂。用免费的API额度也好直接用最简单的规则解析也行先把文本→参数→图这条链路跑通后续再升级哪一环都来得及。3.2 第一步写解析中间层我习惯先把解析和建模分开写这样以后换模型、换CAD内核都不至于全盘推翻。解析中间层负责把一句话变成JSON这一段我直接用一个简单的大模型API调用实现把系统提示词写清楚。from openai import OpenAI client OpenAI(api_key你的API_KEY) def parse_text_to_json(user_input: str) - dict: system_prompt 你是一个机械零件参数提取助手。请从用户描述中提取以下字段 - object_type: 零件类型 - params: 外径、厚度、孔径、孔数等 如果描述中缺少某个字段根据机械设计常识推断默认值 但必须把推断出的默认值标记为inferred: true。 只输出JSON格式不要输出其他内容。 response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: system_prompt}, {role: user, content: user_input}, ], temperature0.2 ) return json.loads(response.choices[0].message.content) # 测试 print(parse_text_to_json(做一个直径80的圆盘厚度10中间打一个20的孔))输出大概是{ object_type: circular_plate, params: { outer_diameter: 80, thickness: 10, center_hole_diameter: 20, hole_count: 0, unit: mm }, inferred: [] }关键是把temperature调低到0.2以下。做工程不是写诗解析结果必须稳定可复现。temperature一高同样的描述每次解析出来的参数可能都不一样这在我们这行是不能接受的。3.3 第二步生成CAD脚本并批量变体JSON拿到手下一步就是把JSON映射成ezdxf绘图指令。我写一个简单的生成函数直接读取参数自动画图import ezdxf def cad_generate(json_params: dict, file_path: str): doc ezdxf.new(R2018) msp doc.modelspace() # 解析参数 outer_d json_params[params][outer_diameter] center_hole_d json_params[params].get(center_hole_diameter, 0) # 画外圆 msp.add_circle((0, 0), radiusouter_d / 2, dxfattribs{layer: 轮廓线}) # 画中心孔 if center_hole_d 0: msp.add_circle((0, 0), radiuscenter_hole_d / 2, dxfattribs{layer: 中心孔}) # 保存 doc.saveas(file_path) print(f已保存: {file_path}) # 批量生成不同直径的圆板 sizes [50, 80, 100, 120] for d in sizes: params { object_type: circular_plate, params: { outer_diameter: d, center_hole_diameter: 10, unit: mm } } cad_generate(params, fplate_{d}mm.dxf)这段代码跑完你就得到了4个不同直径的DXF文件全程没有手动画一笔。这也回应了一直以来很多人头疼的python批量对cad修改场景——有了结构化参数批量生成和批量修改本质上是一回事改参数、重新生成、覆盖保存而已。3.4 第三步图纸后续处理转PDF、合并、layout生成的DXF文件只是中间产物真正交付给同事或者外协厂时通常还要转成PDF、合并多张图纸、或者放在统一的layout里出图。转PDF这块我试过几种方案。最简单的是LibreCAD命令行或用图纸空间手动导出缺点是不能批量。稍微进阶的方式是用ezdxf的绘图模块配合matplotlib后端渲染但那个只适合简单预览线宽、文字样式都比较难控制。工程上最靠谱的还是走CAD软件本身的批量出图接口比如AutoCAD的批量打印工具把图框、比例、打印机样式一次配好。日常用这招就够了别自己造轮子。图纸合并倒是比较直白。如果你手里有一堆分散的DXF文件想合并到一个文件里方便管理可以用ezdxf做图块插入。思路是新建一个总图文档然后把每个零件的DXF作为外部参照或块定义插入再统一施加上下左右的位置偏移。这样总图和零件图永远保持联动改任何一个子图总图重新打开就能更新。layout相关的处理如果你拿到的不是DXF而是DWG且对方用的软件不支持直接编辑布局我的建议是走模型空间画图布局空间出图的老路子先把内容放在模型空间再在布局里创建视口指定比例尺。这套流程和text-to-cad本身无关但它是图纸交付绕不开的一环建议单独花点时间把软件里的布局功能摸清楚。4. 常见问题与排查技巧实录4.1 描述不精确导致的幽灵尺寸问题我一开始玩text-to-cad时遇到的最大坑就是幽灵尺寸。说的是你明明只说了一个圆板生成的图纸上却多出来一堆压根没提过的尺寸。问题是这些尺寸不是瞎编的是系统根据训练数据里的高频特征推断出来的。比如法兰盘默认要有4个螺栓孔轴默认要有倒角。从架构上看这算合理的智能补全但从使用感受上这就是一言不合在图纸上乱加料。排查思路很简单先看解析中间层输出的JSON里有没有inferred字段哪些参数是系统自己默认出来的全部要人工确认一遍。再不行就把系统提示词改成严格的只提取用户明确提到的参数缺失一律置空并提示用户补充。宁可多一轮交互也不要让幽灵尺寸混进正式图纸。我用过一个比较温和的做法每次生成完在CAD软件里用选择类似对象功能把所有标注批量选出来过滤检查。这个方法土但很有效。4.2 单位、坐标系和图层混乱跨系统协作时单位不统一是重灾区。你用Python脚本时默认的是mm但接收方打开的图纸可能是英寸。一旦单位错乱一个直径标注为50的圆到了对方那里可能变成直径1270毫米的巨型圆盘整个装配全乱了。避免单位混乱的原则就一句话所有输入输出统一走同一个单位系统中间层JSON里必须显式携带unit字段。有些老图纸标准的模板层名和设备不匹配地带也容易躺枪。我见过有人生成的DXF所有图元全在0层线条颜色乱七八糟打开后屏幕一片白排查半天才发现是图层映射没建。解决办法是提前建好一套符合国内制图标准的图层模板——轮廓线、尺寸线、中心线、文字、图框各归各层生成时按规则写入别偷懒。4.3 字体、线条样式等显示类问题生成后的图纸发给别人看最常见的一句话是怎么只有形状字全是问号。这就是字体跨平台缺失的经典症状。CAD软件的字体分两类一类是Windows的ttf字体一类是CAD专用的shx字体。后者高度自定义不同人电脑上装的shx字体库不一样你的图纸里用了某个专业符号字体对方电脑没有就会显示成乱码或问号。解决方案几个思路。一是尽量使用通用ttf字体比如宋体、黑体它们跨平台兼容性好。二是在交付前用文字样式替代功能把这些shx字体统一映射到你电脑上存在的字体然后另存一份。三是如果对方确实没有图纸所需字体直接把shx字体文件随图纸一起发过去放到对方CAD安装目录的Fonts文件夹里重建即可。这个问题跟text-to-cad本身关系不大但只要走到交付环节十有八九会碰上提前准备别等到被问。4.4 工具链集成问题命令失效与脚本报错画图之外很多人顺着AI生成的辅助脚本折腾CAD时还遇到过一些很玄学的问题比如CAD里面F命令用不了、激活页面脚本发生错误。这些虽然是传统CAD的老问题但和text-to-cad流程组合后更容易暴露。F命令用不了通常不是软件坏了而是命令被某个LISP程序或快捷键配置劫持了。排查路径是先输入FULL命令确认当前设置再去自定义用户界面里查快捷键绑定最后考虑是不是某个插件自动加载时改了命令别名。类似的还有脚本生成报错常见原因是字符串里有中文引号、换行符没转义生成代码时两个系统之间的编码不一致报错信息会一直顶到你麻木。我的处理规范是所有脚本文件统一保存为UTF-8代码里尽量用英文参数名中文只出现在注释和图层名里这样能少踩一半以上的坑。关于安装CAD一直出现C2005错误这个属于安装环境问题经常是系统缺少对应版本的VC运行库或者之前卸载不干净导致注册表残留。跟text-to-cad核心关系不大但如果你的电脑装不了CAD后面测试环节全卡住。建议安装前把旧版本彻底卸载干净——不只是控制面板里删程序还要清理安装目录和注册表残留最后重启再装。这样能避免绝大多数卸载后二次安装失败的悲剧。4.5 常见问题排查速查表问题表现根因方向排查思路解决建议生成图纸多出未要求的尺寸解析层默认值推断检查JSON中inferred字段严格化提示词缺失参数由用户确认打开图纸尺寸变大或变小单位不一致检查JSON与DXF单位字段全流程统一mm单位文字显示问号缺少shx字体或字体映射缺失查看字体替换表改用通用ttf字体或附带字体文件生成的圆板没有中心线图层与线型未配置查看图层设置建立国标图层模板按规则分流F命令失效命令别名被覆盖检查自定义用户界面与插件重置命令设置或修改别名CAD激活页面脚本错误安装环境残留检查VC运行库与注册表彻底卸载重装清理残留批量生成时脚本中断编码或特殊字符查看报错行号统一UTF-8编码转义特殊字符4.6 一句话总结排查的心法排查这类问题的总思路永远是分层定位。text-to-cad的链路是文本→解析层→建模层→出图层→人工交付出问题时先明确是哪个层出了事描述不清找解析层几何不对找建模层图纸不规范找出图层软件报错再看环境配置。逐层缩小范围比在CAD界面里盲调快得多。我自己已经把这套排查流程做成了checklist每次出问题按顺序过一遍基本五分钟内能定位到根因。写在最后的一点个人经验把text-to-cad的整套思路跑通到现在我最大的体会其实不是AI有多厉害而是工程规范有多重要。AI负责把重复劳动压缩掉但压缩出来的东西能不能用全靠你有没有一套扎实的制图基本功打底。你还得懂图层、约束、标注样式、出图流程不然AI的产出一到你手里就是一摊乱麻。如果你打算入坑这个方向我给三条实在建议。第一别一上来就搞复杂的装配体先用圆板、法兰、垫片这类对称件跑通全流程。第二永远保留人工确认环节哪怕系统再成熟出图前也要过一遍关键参数。第三把你的公司制图标准固化成模板让AI生成的结果直接对接企业标准这才是text-to-cad在团队里真正产生价值的方式。再分享一个我最近常玩的扩展玩法把公司里那些重复性极高的系列零件全部整理成text-to-cad的模板词条录入一套企业级的提示词库。内部同事想要什么型号的零件直接发一句话给机器人机器人返回图纸草稿工程师确认后直接转给下游生产。这个流程跑了一个多月制图岗的重复劳动肉眼可见地减少了。工具永远是工具但用对了工具人就能回到更像人的工作上去。