1. 从一句自然语言到一份可改参数的设计文件，text-to-cad 到底改变了什么

我第一次对 text-to-cad 这个方向产生强烈兴趣，是在看到一位机械组的实习生把一段口语化的设计需求丢给 AI，让它直接生成 CadQuery 脚本的时候。当时我的第一反应是：这是个噱头吧。但他当着我的面改了脚本里三个数字，重新导出，三十秒就出了一版新的 STEP 文件。让我印象深刻的不是那个模型有多复杂——它只是一个带孔的安装支架——而是“描述需求到拿到可编辑模型”之间那一大截沟通损耗被抹掉了。

传统流程里，一个口头需求要变成图纸，至少要经过手绘草图、方案评审、二维细化、三维建模好几轮。每个环节都有人与人之间的传话，传话必有信息衰减：你说的是“差不多 120 长”，到建模的人手里可能就变成了“大概 150 也无所谓”。而 text-to-cad 这条路线，恰恰把最枯燥的“把需求翻译成几何体”这层劳动接了过去，人只需要负责把话说准确。这也是这篇文章想讲清楚的核心：它不是让你抛弃 CAD，而是让你把“描述需求”到“生成模型”这一段自动化，然后由你把关、修改、落进现有的图纸流程。

这篇内容适合几类人看。一类是机械、家具、钣金、建筑设计方向的工程师，你们日常被重复建模、改图折磨，想试试 AI 但不知道怎么接进企业流程；另一类是做自动化、懂点 Python 的程序员，你们想要一个能跑通的“自然语言转 CAD 文件”最小链路。我会尽量少放黑话，但也不会回避必要的技术细节，保证看完之后你能自己动手跑通一版。

先把边界说清楚。我理解的 text-to-cad，并不是“AI 直接吐出一张完美定稿图纸”。以目前主流方案的能力，它实际做的是把自然语言翻译成一段参数化建模脚本，再由脚本驱动建模内核生成几何体。这意味着你拿到的是一个可以随时改尺寸、重新生成的“活文件”，而不是一张改起来要命的死图。这个定位贯穿全文：讲原理时你会明白为什么大家都绕不开参数化，讲实操时你会拿到能跑的代码，讲坑点时你会知道问题出在提示词还是出在坐标系。

2. 为什么工业路线普遍选择“生成脚本”而不是“AI 直接画图”

2.1 端到端生成模型的问题出在哪里

如果你关注 AI 绘画，可能会觉得“既然图像能端到端生成，CAD 模型为什么不能直接生成一个三维文件”？我也这么想过，而且真去试过几款号称能从文本直接生成三维网格的工具。结论是：它们做概念展示、游戏资产可以，做工程图纸基本不行。

原因在于工程模型的核心不是“像”，而是“准”。一张效果图让你觉得“这大概是个支架”，这就够了；但一份加工用的 CAD 模型，一个孔的直径差 0.5 毫米就没法装配。端到端生成的网格模型，参数是非结构化的，常见情况是视觉上很完整，但当你想去改一个孔的直径、把底板加长 10 毫米时，根本找不到一个可编辑的参数入口。它没有特征树，没有草图约束，没有尺寸链。这种文件在工厂里是没法用的，因为工艺人员拿到它之后，唯一的修改方式就是重画。

参数化建模脚本刚好反过来了。CadQuery、OpenSCAD 这类工具看起来是在“写代码建模”，但本质上它们把 CAD 操作变成了可复算的步骤：先画草图、再拉伸、再打孔、再倒角。每一步都有明确的几何操作语义，改一个尺寸参数，后面的结果全部联动更新。

我用一个生活化的类比来解释这件事：端到端生成类似于你给别人看一张做好的菜的成品照片，对方看了只能说“知道了”；参数化脚本则相当于把菜谱写下来，盐几克、油几毫升、火多大、烧几分钟全都写清楚，换个人也能照着复刻出来，而且想少放盐直接改那个数字就行。工业界要的从来都是菜谱，不是照片。

2.2 参数化、约束与单位：决定生成结果是否可用的三座山

为什么目前能真正落地的 text-to-cad 工具，基本都是靠大语言模型（LLM）写参数化脚本？因为 LLM 的强项恰恰是代码生成。它在海量开源代码上训练过，对 CadQuery、OpenSCAD、Python 的语法非常熟悉。你给它一段语义清晰的需求，它能输出一段结构完整的建模代码。这条技术路线的成本低、见效快，而且生成结果继承了参数化内核的全部优点。

但代码生成只是第一步，模型能不能用，还看三件事。

第一是参数化是否彻底。好的生成脚本会把关键尺寸提成变量，比如plate_length = 120，而不是把 120 硬编码在十个地方。否则你想改尺寸时就要一行行找，跟改一张死图没有本质区别。我甚至见过 AI 生成的脚本里，同一个尺寸在代码里出现了六次，改了第一处后面的几何体就矛盾了。这种脚本生成出来只能看，没法进工艺。

第二是约束是否完整。真实设计里，孔距、同轴度、对称关系、与基准面的位置关系，这些比“形状像不像”更重要。AI 默认会按训练数据里的常见做法猜一套约束，但工程需求往往有自己的强制要求。这时候，提示词里如果没写清楚，它就给你按最通用、最平庸的方式处理，结果常常是形状对，装不上。

第三是单位体系。这是我最常踩的坑。同一句话，AI 在不同语言模型、不同提示词下，可能给你输出英寸、毫米，甚至把单位混用在同一个模型里。毫米和英寸的差异是 25.4 倍，底座规格差出这么多，后面全部白做。后文我会给一套模板，把单位、原点、坐标系固定在提示词里，宁可每次多写几句，也不要事后去猜 AI 用的是什么单位。

这三个问题，本质上都是“把模糊需求变成精确规格”的问题。AI 翻车不是因为技术不够，而是因为人没说清楚。所以，提示词工程在 text-to-cad 里的重要性，一点都不比模型本身低。

3. 工具选型：开源参数化、在线生成和 2D 图纸方案的取舍

3.1 三维参数化：CadQuery、OpenSCAD 与实际可用性

先讲三维。如果你要生成的是机械零件、五金件、钣金件这类规则几何体，我强烈建议从 CadQuery 入手。这是个 Python 库，API 设计得很像 CAD 操作——先选定一个工作平面，然后画草图、拉伸、打孔、倒角。它支持导出 STEP、DXF、SVG、STL 这些常见格式，其中 STEP 是机械设计里最通用的中间格式，几乎所有主流 CAD 软件都能打开。

CadQuery 对 text-to-cad 特别友好的原因在于，它的代码语义和设计师的操作习惯高度一致。AI 在生成这种“操作式”代码时的准确率，明显高于生成纯数学函数式建模的代码。因为你描述的自然语言本身就是操作序列：“底板画个矩形、拉伸、四个角倒圆角、顶部打四个通孔”。CadQuery 的语法几乎一比一对应这种描述。我自己实测下来，AI 写 CadQuery 的首次运行成功率，比其他同类库高不少。

OpenSCAD 则是另一种风格。它用声明式 CSG 布尔运算建模，适合齿轮、瓶体、壳类这类能用数学关系描述的模型。它的代码更像数学函数，与自然语言的直觉距离远一些，但适合对精确数学关系有强需求的场景。如果你要用的是“几何关系由参数方程定义”的零件，OpenSCAD 是更好的选择。

另外还有一大类是在线方案，比如 Zoo 出的 Text-to-CAD 这类服务，把提示词直接转换成可编辑的三维文件。优点是省去了搭环境的痛苦，浏览器里输入英文提示词就有结果；缺点是语言上基本只能用英文，免费额度有限，而且生成效果在复杂装配体上还比较弱。它更适合快速验证思路，不适合当作企业内部稳定的批量生成通道。

3.2 二维图纸：ezdxf + LLM 是中文设计环境下最务实的组合

如果说三维方案是舞台中心，那二维图纸才是很多工程师每天真正面对着的东西。施工图、加工图、下料图，大量交付物仍然是 DXF/DWG。这个场景下，我最常用的组合是 ezdxf 加 LLM。ezdxf 是一个纯 Python 的 DXF 读写库，支持从 R12 到 R2018 的多种版本，能创建线条、圆、多段线、文字、图层、块，也能读入已有图纸做批量修改。

为什么在二维场景里我反而更推荐用代码生成图纸，而不是追求“AI 直接画”？因为二维工程图的本质不只是几何线框，还包括图层组织、线型、比例、标注、文字字体这些图纸规范。代码生成的方式，能把所有规范写成固定模板，每次只让 AI 替换几何参数。你控制的是规则，AI 只负责填充具体数值，这样出图的一致性非常高。

中文环境下特别要留意字体问题。后文排查部分我会展开讲 SHX 字体缺失导致文字显示乱码的坑。这里先留一个结论：生成图纸时，直接在提示词里规定文字样式使用 TrueType 字体，比如仿宋或 Arial，别用默认的 txt.shx。

3.3 选型思路对照

我把三条路线放在一起对比，方便你根据自己手里的活来做决定。

我个人的建议是：先判断交付物是三维模型还是二维图纸。偏三维机械设计的，优先 CadQuery；偏二维出图、且最终要进 AutoCAD 流程的，优先 ezdxf。两条路线都不需要你安装破解版 CAD，生成端和消费端可以完全分离——你在服务器上批量生成 DXF，再把 DXF 丢进 AutoCAD 或中望 CAD 里审核出图。

4. 实操跑通最小案例：从自然语言提示词到可导入 AutoCAD 的文件

4.1 准备环境

这个案例的目标是：说一句话，生成一个带安装孔的支架模型，并导出 STEP 和 DXF 各一份。我默认你已经装了 Python 3.10 以上的版本。强烈建议用虚拟环境，别直接装在系统 Python 里，因为 CadQuery 依赖 OpenCascade 内核，包体积大，跟其他地理信息、机器学习库混装容易产生版本冲突。

python -m venv cad_env source cad_env/bin/activate # Windows 下执行 cad_env\Scripts\activate pip install cadquery ezdxf

安装完成后，先跑一句最简单的 CadQuery 代码验证环境：

import cadquery as cq result = cq.Workplane("XY").box(100, 50, 10) cq.exporters.export(result, "test.step") print("OK")

能打印 OK 就说明环境没问题。接下来进入提示词环节。

4.2 设计提示词：让 AI 只输出可执行代码

调用大语言模型时，我习惯把系统提示词固定成下面这样，把规矩立在前头：

你是一个 CAD 脚本生成器。只输出 Python 代码，不允许输出解释。代码中不允许出现中文注释。单位默认毫米，原点在 XY 平面。先定义所有关键尺寸变量，再建模。

用户提示词我给一个典型的口语化需求：

创建一个安装支架。底板长 120、宽 60、厚 8，四个角倒圆角 R5；底板上开四个直径 8 的安装孔，孔中心距左右边缘 10、距前后边缘 10，对称分布；在底板上方中心位置立一块竖直安装板，高 40、厚 5、宽 30，安装板与底板之间用 R3 的圆角过渡。

把这段丢给模型，正常得到一个类似这样的 CadQuery 脚本：

import cadquery as cq plate_length = 120 plate_width = 60 plate_height = 8 hole_dia = 8 fillet_r = 5 vertical_plate_h = 40 vertical_plate_t = 5 vertical_plate_w = 30 transition_r = 3 result = cq.Workplane("XY").rect(plate_length, plate_width).extrude(plate_height) result = result.edges("|Z").fillet(fillet_r) result = ( result.faces(">Z") .workplane() .rect(plate_length - 20, plate_width - 20, forConstruction=True) .vertices() .hole(hole_dia) ) vertical = ( cq.Workplane("YZ") .center(0, plate_height) .moveTo(0, 0) .lineTo(vertical_plate_w / 2, 0) .lineTo(vertical_plate_w / 2, vertical_plate_h) .lineTo(-vertical_plate_w / 2, vertical_plate_h) .lineTo(-vertical_plate_w / 2, 0) .close() .extrude(vertical_plate_t) ) result = result.union(vertical).edges().fillet(transition_r) cq.exporters.export(result, "bracket.step") cq.exporters.export(result, "bracket.dxf")

注意，这段代码在细节上不一定跟你的模型输出完全一致，比如圆角过渡那段，AI 可能放在不同的边集上，需要微调。这正是我要强调的：text-to-cad 给你的是一个“底稿”，不是终稿。它最大的价值，是把原来要从空白画布开始的建模工作，压缩到了只需检查、微调的阶段。

4.3 导出、导入和验证

脚本运行成功之后，目录下会出现bracket.step和bracket.dxf两个文件。

• bracket.step是三维模型，丢进 SolidWorks、FreeCAD、中望 3D 都能打开。
• bracket.dxf是二维线框导出，可以直接在 AutoCAD 里打开。

打开 DXF 后，第一步别急着看形状，先做三个检查。第一是单位对不对，用测量命令量一下底板长度，应该是 120；如果显示 120 但明显偏大或偏小，检查图形单位设置是不是毫米。第二是图层结构，AI 生成的 DXF 可能把所有线都放在 0 层，颜色、线型不分，这在你个人验证时没问题，但要是交出去的图纸，还是要统一整理。第三是文字字体，如果图纸里有标注文字变成了问号，那就是字体缺失，后面有专门一节处理。

如果你最终工作在 AutoCAD 里，更推荐直接用 DXF 打开后再另存为 DWG。DXF 是公开格式，兼容性最好，而 DWG 是 AutoCAD 的私有格式，各种版本之间的兼容历史问题非常多。用一个稳定的 DXF 版本（比如 R2010）作为中间交换格式，出问题的概率最小。

5. 提示词工程：把模糊的“大概意思”翻译成机器能执行的规格

5.1 一个结构化的规格化模板

很多人第一次试 text-to-cad，提示词就写一句话：“生成一个支架”。好一点的加个尺寸：“生成一个 120x60 的支架”。结果往往是不理想的，因为“支架”在 AI 的训练数据里对应着几百种形态。你没有指定它的组成部分，AI 就按统计分布挑了一个最常见的组合，那个组合很可能不是你想要的。

我把自己的提示词整理成了一个固定模板，五个部分，每次填空就行：

• 对象与部位：先说这个模型整体叫什么，由哪些部分组成，每个部分用什么基本操作生成。
• 尺寸体系：每个部位的长、宽、高或直径必须写全，孔系要写清楚中心距和边距。
• 方向与基准：说明正视图的基准面，底部是放在 XY 平面还是以某个面为基准对齐。
• 约束关系：孔和孔是否对称、谁在谁的中心、倒角是内角还是外角、是圆角还是倒角。
• 单位与图层：单位默认 mm、原点位置、是否分图层、文字字体用什么。

拿前面的安装支架举例，把模板填进去，和最初那句“生成一个支架”相比，生成结果的可读性和可用性完全不是一个量级。

5.2 单位、原点、图层：最容易被忽略却最决定成败的全局参数

单位问题我在前面埋了伏笔，这里展开细讲。AI 训练数据里英寸和毫米混在一起，如果提示词不含单位，模型就随机猜。我最开始踩坑的时候，生成了一个底座是 3048 毫米宽的板子，而数据源其实给它的是 120 英寸。关键是模型自己毫无错误提示，因为它只是在执行“默认单位”的推断。

原点位置同样重要。你不说，AI 可能把模型放在 Z=0，也可能整个模型的底面在 Z=-50 的位置。这个偏移对单模型没影响，对装配体却致命——你装配的时候所有零件对不上基准。所以提示词里我固定加一句“模型底面位于 Z=0 平面，对齐原点”。就这一句话，省掉了我大量手动平移修正的时间。

图层和线型的规范，对于要直接交付的图纸更重要。你可以让 AI 在 ezdxf 脚本里按你的模板写图层：轮廓线一层、标注一层、中心线一层、文字一层，颜色、线宽都配好。这样出来的 DXF，到 AutoCAD 里不需要重新刷图层，打印样式也对得上。这才是二维图纸流程能自动化的关键前提。

5.3 三个典型失败案例复盘

我把自己实际遇到过的三类失败情况列出来，你看了之后能少走半天弯路。

第一个是缺尺寸导致的“比例正确但数值错误”。我让 AI“做一个底板 120 宽的支架”，没写长度。AI 默认按黄金比例给了一个长度，形状完全合理，但根本不是我需要的 100 长度。这个问题不是 AI 能力不行，是我漏了参数。解决方案就是模板化，五个部分逐项检查。

第二个是对称基准没说清楚导致孔位偏移。有一次我要在底板左侧边缘 10mm 处开一个定位孔，然后以它为基准向右等距复制三个孔。提示词里我写的是“均布四个孔”，AI 就按中心对称处理了。实际加工要求必须以左边缘为基准，结果孔位整体偏了。后来我把提示词改成“以左边缘为基准，孔中心距左边缘 10，三个孔间距 30 向右排列”，第二版就对了。

第三个是圆角和倒角的混淆。AI 在文本理解层能区分 fillet 和 chamfer，但如果你写“倒角”，它不一定知道你说的圆角还是斜角。这不是语义问题，是行业黑话的歧义。我的建议是：凡是需要圆角就用“圆角 R3”，需要斜角就用“斜角 3x45°”，不要单独写一个“倒角”两个字。

这些失败案例说明，text-to-cad 的核心竞争力，其实是使用者把需求表达清楚的能力。工具本身只是放大器，需求表达得越好，放大出来的效果越好。

6. 实际落地绕不开的兼容性问题和排查路径

6.1 从 SHX 字体到图纸合并：日常 CAD 使用者最关心的几个坎

我在文章开头列出的那些搜索热词，比如“cad shx 字体大全”“cad导入layout步骤详解”“cad图纸合并”，看起来是软件操作问题，但每一个在后面做 AI 生成图纸时都会换个形式重新出现。

先说 SHX 字体。生成 DXF 时，AI 很容易给文字样式设置成本地没有安装的 SHX 字体，打开图纸后文字全变成问号。排查路径是这样的：先在 AutoCAD 里输入STYLE命令，看当前文字样式指向的字体文件名；如果是txt.shx或hz.shx这类 SHX 文件，而你的系统没装对应字体，就会显示异常。修复方法有两种，一种是用STYLE命令把文字样式改成 TrueType 字体，另一种是直接用 Python 打开 DXF 批量替换字体样式名。用 ezdxf 遍历所有TEXT和MTEXT实体，把样式名改成预设好的 TrueType 样式。这个过程几分钟就能跑完。

再看图层和图纸合并。AI 生成的单张图纸往往内容散乱，图层全在 0 层。要把它并进整套施工图，不要直接复制粘贴实体，那是自找麻烦。我的做法是：把生成的图纸内容定义成块，统一命名前缀AI-，然后通过外部参照或插入块的方式合入主图。这样既保留源文件的独立性，又方便以后 AI 重新生成后一键替换块。

还有 layout 批量导入的问题。如果你有一批 AI 生成的 DXF 文件，想每张图建一个布局并插入视口，手工操作会崩溃。更合理的思路是写一个 Python 脚本，批量遍历文件夹、创建布局、添加视口并设置比例。这一步不要求你成为脚本高手，只要能跑通循环和基本属性设置就够了，关键是把机械性重复的步骤交给程序。

6.2 Python 批量与生成模型衔接：从“一次生成”到“一套图纸”

text-to-cad 真正厉害的地方，不是生成一个模型，而是生成一条可批量复用的流水线。

举个例子。你接到一个任务，要给五种不同规格的支架各出一份图纸。传统做法是五个模型建五遍，现在只需要在提示词里把尺寸参数做成变量，然后让程序循环调用多次生成：每循环一次，改一个底板长度，其余结构不变。生成结果保存成五个 DXF，再用 ezdxf 统一加上图框、标题栏、零件号，一次性输出一套图纸。整个过程半小时不到，而且每份图纸之间不存在人为抄错尺寸的问题。

这就是代码生成路线碾压手工建模的核心优势：一致性。同一套逻辑跑出来的五份图纸，图层、比例、线型、标注风格完全统一。这些图纸在 AutoCAD 里打开，看起来就像同一个熟练工程师画的，而不是五个不同的人各画一套风格。

6.3 AI 产出的“半成品”如何接进现有 CAD 工作流

工程师看完 AI 生成的文件，最容易产生的疑问是：这东西能替代我干活吗？我的答案很直接：它能替代的是建模前 70% 的重复劳动，替代不了的是后 30% 的工艺判断。

AI 生成几何体的能力目前已经很能打了，但它不懂加工工艺。比如它可能给你生成一个无法用常规刀具加工的深窄槽，或者把倒角半径设得比板厚还大。这些错误需要经验来判断。所以我的工作流是：AI 出方案，人出判断。AI 生成的 STEP 文件只作为初稿，人工检查关键尺寸、工艺可行性、装配干涉，确认后我再进入正式的 CAD 环境做细化标注。

这样做的好处是，将 CAD 操作从“从零建模”变成了“审核和修改”。同样一个支架，过去要画四十分钟，现在用 AI 生成底稿，人工修改、确认，十分钟就能进流程。省下来的半小时不是消失，而是转移到了更值钱的工艺思考上。

7. 我的几点实践体会与建议

走完这一整套实验之后，我对 text-to-cad 的判断是：它不会替你画图，但它能帮你把“画图的体力活”压缩到极限，前提是你能把需求的每个细节钉死在提示词里。

如果你想在实际项目里试水，我建议从最小的闭环开始，不要一上来就追求 AI 出全套施工图。先选一个结构简单的零件，跑一遍“自然语言到脚本、脚本到模型、模型到 DXF、DXF 到 AutoCAD”，把这一步跑顺了，你就能体会到每个环节真正的痛点和收益在哪里。跑通之后再把同一个逻辑复制到批量场景中去。

另外有一个容易被忽略的落地细节：把生成脚本纳入版本管理。AI 生成的脚本一次可能不完美，你会迭代很多版，不保存版本历史的话，改到最后你可能已经忘了哪一版是能用的。git 记录的好处是让每一次修改都能追溯，回滚也方便。我甚至会把每次的原始提示词也写在提交信息里，这样半年后再看，也能回忆起当初那个模型是怎么来的。

最后再分享一个技巧。如果你所在的团队有多个人要用这个流程，建议把提示词模板固化成一个内部文档，每个人生成模型时都按同一套规范写“对象、尺寸、方向、约束、单位”五个部分。一是保证输入一致，输出才可控；二是把个人经验沉淀成团队能力，不要今天你踩一遍单位换算的坑，明天他再踩一遍。

这条路线还在快速迭代中，但已经足够有价值。至少对我来说，它帮我把大量重复性的建模工作压缩成了写提示词和点运行的几秒钟，剩下的时间，终于可以用来做些真正需要思考的事。