最近一个做结构设计的同事问我：现在不是有个 text-to-cad 吗，能不能把客户表格里的法兰尺寸直接变成三维模型？我第一反应是这活儿听起来跟 AI 画图差不多，但真正上手试了以后才发现，它跟文生图完全不是一回事。text-to-cad 要做的是把自然语言的需求描述，翻译成一套精确到毫米、可以编辑、可以导出到任何主流 CAD 软件的几何模型，而且这套模型带着完整的特征树和参数，不是一张渲染图片。这件事听着很酷，但落地过程中坑很多：尺寸单位会被猜错，直径半径会被搞混，特征顺序一乱整个布尔运算就报废。所以我写这篇东西，就是为了把原理、能用的工作流、以及我实测踩出来的坑一次性说清楚，给想试 text-to-cad 的伙伴们一份能直接抄作业的参考。

1. text-to-cad 的本质认知：从“画图”到“表达意图”的范式切换

1.1 一句话理解：给 CAD 配了个“需求翻译官”

如果有朋友问我 text-to-cad 到底是个什么，我通常用一个比喻：它像是给三维 CAD 软件配了一个需求翻译官。原来的工作流，是你脑子里有零件的形状，然后打开软件，画草图、加约束、做拉伸、打孔、倒角，一步一步把想法“翻译”成软件能理解的建模动作；现在，这个翻译环节被模型承担了一大部分，你直接说“我要一个外径 120、内径 60、厚度 15、六个直径 12 的孔均匀分布在直径 90 的圆周上的法兰盘”，它就替你写出一段程序化建模脚本，把特征按顺序生成好。对你来说，剩下的工作是检查结果、微调参数、导入装配体里试装。

需要特别强调的是，这个“翻译”不是简单的关键词匹配，它要理解工程语义。比如“外径 120”里的“外径”是一个物体的整体外围尺寸，“均布”意味着圆周上的角度均匀分布，“贯通”意味着孔要穿透整个厚度。这些词在工程里含义非常明确，模型需要把它们转换成几何操作，而不是笼统地画一个圆柱再随便挖几个洞。

1.2 它到底解决了哪些真问题

说句实话，我从很早开始就关注这个方向，最初也以为又是一阵炒作。但当我真的把 text-to-cad 用进工作流，发现它解决的是几个非常具体的痛点。

第一个痛点是建模软件的高门槛。很多做产品、做结构的同事，脑子里想法很清楚，但一打开 CAD 界面就抓瞎：图层、约束、草绘平面、特征树，任何一个环节不熟都会卡住。text-to-cad 的价值不在于让你从此不用学三维建模，而在于把“从想法到初步模型”这段路缩短，让不具备专业建模技能的人也能先产出可用的雏形。

第二个痛点是文档与模型之间的翻译成本太高。实际项目里，需求经常是写在技术协议、Excel 明细表或者会议纪要里的，多字段的零件参数需要人工逐项填进建模软件。人工翻译就容易出错——单位看错、公差漏掉、孔数不对，都是最常见的低级错误。把需求描述直接喂给 text-to-cad，等于把参数到模型这一步自动化了，至少能减少因为手抖造成的低级失误。

第三个痛点是批量变体的成本。比如管路项目里有十几种规格的法兰，如果每个都从零建模，工作量很大。但用 text-to-cad 的思路先得到一个参数化脚本，再在脚本里循环改尺寸，一份脚本就能批量生成所有规格，这种复利效应是传统手工建模很难比的。

1.3 和文生图、文生3D模型有什么不一样

很多人把 text-to-cad 和文生图、文生 3D 混为一谈，实际差别非常大。文生图（比如生成一张“未来感的水杯效果图”）的输出是像素，好看就行，不需要保证“杯子的直径是 80mm”。文生 3D（比如生成一个可旋转的杯子网格模型）输出的是表面网格，适合游戏素材或数字化展示，但网格通常是非流形的、精度未知，没法直接用于工程加工。

text-to-cad 要的是能进入 CAD 环境的实体模型，它必须满足封闭曲面、精确尺寸、可编辑特征、可导出 STEP/IGES 等工程格式。我自己整理过一个非常直观的对比：

看见没有，text-to-cad 和另外两者起点相似，都是自然语言输入，但验收标准完全不同。它追求的不是“看起来像”，而是“加工得出来”。这也是为什么这个领域早年尝试过直接让扩散模型生成三维体积数据，后来纷纷转向程序化建模路线——因为只有参数化模型才真正具备工程可用性。

2. 技术原理拆解：自然语言如何变成可编辑的几何体

2.1 第一层：语言理解与意图抽取

所有 text-to-cad 系统的最底层，都是一个大语言模型，第一步要做的是把一句话拆解成有工程意义的特征列表。我给模型发“外径 120、内径 60、厚度 15 的法兰盘”，它内部其实在做三件事。

第一件事是实体识别。它要从自然语言里找到“外径 120”是一个参数对象，“内径 60”是另一个，“厚度 15”是第三个。第二件事是关系判断。它需要知道这些参数之间是什么关系：外径和内径都是针对一个旋转体而言的，厚度是这个旋转体沿轴向的长度，三者共同构成一个中空圆柱体。第三件事是默认知识补全。模型需要知道法兰盘一般会有螺栓孔，但这些孔到底几个、多粗、分布在哪个圆上，需要从上下文或行业常识推断，如果拿不准就会在回复里问，或采用最常见的默认配置。

这一步直接决定后面代码能不能对。如果模型把“外径 120”理解为半径，后面生成的圆柱就会大一倍，整个设计全错。所以，操作上我基本都会在提示词里做“防呆”：明确告诉模型所有尺寸的默认语义，并要求它在生成代码前先复述一次自己的理解。这个“复述确认”机制看着笨，却能筛掉大量歧义。

2.2 第二层：从意图到程序化建模代码

第二步是整个链路的核心：把特征列表转化成一段可执行的程序化建模脚本。目前在工程圈里比较主流的落地形式，是把语言模型当成一个“代码生成器”，让它生成 CadQuery、OpenSCAD 这类工具的脚本。CadQuery 是 Python 库，背后基于 OpenCascade 几何内核，支持拉伸、旋转、布尔、倒角、阵列等参数化特征；OpenSCAD 则是用类似编程语言的语法描述几何体。两者生成的模型都保留完整的特征信息，可以二次编辑。

为什么这个环节选择了代码生成，而非直接生成 B-rep 模型？因为对语言模型来说，生成代码是它的强项，而直接输出精确几何体则难得多。一个工程上可用的 B-rep 模型需要完美的拓扑结构，差一点就是无效曲面；扩散模型在生成体素或网格时，很难保证上千个网格面拼起来仍然是一个封闭、无自交、可加工的整体。相比之下，用代码描述“拉伸一个圆，减去一个同心小圆，再打六个孔”，每一步都是确定性的几何运算，只要语法正确，几何内核就会算出合法实体。所以，与其说 text-to-cad 在“生成模型”，不如说它在“自动写建模脚本”——大家常调侃这是“代码生成套上了一件 CAD 外套”，其实这话挺准确的。

2.3 第三层：几何内核的实体化与验证

模型生成代码后，脚本会被交给几何内核执行。CadQuery 调用的 OpenCascade 会负责拉伸、布尔减、倒角这些底层运算，最终生成一个实体对象。这一步其实最见真章：如果代码是错的，比如在打孔之前忘记先建模主体，内核就会报错；如果特征顺序不对，比如先打孔再拉伸主体，孔就会被后续的实体“填掉”，生成一个完好无损的圆柱。这些错误编译器不会完全帮你拦住，最终要靠眼见为实的验证，以及检查体积、面数、边界框等量化指标。

这里还涉及一个重要机制：可校验性。做文生图的时候，图好不好看是主观的，你没法自动判定；但做 text-to-cad，一个模型是否满足“外径 120、内径 60、厚度 15”，可以通过读取实体的 BoundingBox、截面尺寸、体积来客观判断。我自己在自动化工序里会专门写一段校验脚本，用几何内核自带的方法量取结果的尺寸，如果误差超过 0.01 毫米就打回重来。这个闭环是 text-to-cad 区别于 AI 绘画的最大优势，也是它能被工程化使用的前提。

3. 从零跑通一个 text-to-cad 工作流：环境、提示词与完整案例

3.1 环境与工具选型

先说环境。我用的方案是“大语言模型 API + CadQuery + Jupyter”，以 Python 为主体。基础环境是这个组合：

• Python 3.10 / 3.11，建议用 conda 单独建一个虚拟环境，避免依赖冲突
• 安装 CadQuery：pip install cadquery，它自带 OpenCascade 内核
• 安装 Jupyter：pip install jupyter，我用 Notebook 来交互调试，因为可以快速看渲染结果
• 一个能正常使用的大模型 API，按你有权限访问的模型服务来配置即可

如果你更偏好“所见即所得”的验证，另外推荐 OpenSCAD 作为备份方案：语法更简单，模型生成速度快，而且自带在线查看器。但 OpenSCAD 在复杂装配、特征树管理上不如 CadQuery 灵活，所以我的主路径始终是 CadQuery。

安装完成之后，跑一个最小验证：创建 Workplane 并拉伸。如果这一步能正常出结果，说明环境已经打通。很多人卡在 CadQuery 的导入问题上，一般是 conda 环境里 Python 版本过高或 OpenCascade 动态库没有正常加载，建议直接用 CadQuery 官方推荐的虚拟环境解决，别硬怼系统 Python。

3.2 提示词设计的五个关键点

实测下来，text-to-cad 的结果质量七成取决于提示词，三成取决于模型能力。我总结了一套自己的提示词模板，核心是五个关键点。

第一，指定建模工具和语言。开头直接写“请用 CadQuery+Python 实现一个零件”，避免模型自由发挥生成 OpenSCAD 或者其他奇怪的库。第二，显式声明单位。写“所有尺寸单位均为毫米，不要进行任何缩放”，防止它拿英制单位或者做比例换算。第三，规定特征顺序。“先构建主体，再切除内孔，最后添加倒角/圆角”，这一条特别重要，因为顺序错了，布尔运算结果完全不同。第四，补充工程语义。比如“螺栓孔均布，共 6 个，中心圆直径 90”，而不是笼统说“六孔”。第五，要求只输出代码。加上“只输出可运行的 Python/CadQuery 代码，不做解释”，能省去后续解析的一堆麻烦。

我还习惯在提示词末尾加一句“请在代码中直接使用上面给出的尺寸，不要自行修改或估算”。实测下来，加入了这句话之后，模型“好心帮你调整尺寸”的概率会下降不少。另外，如果模型经常把单位搞混，我会在提示词里直接给一个换算示例：“半径 = 直径 / 2”，大多数模型看到公式就不会再犯半径直径的错。

3.3 完整案例：生成一个带孔法兰盘

下面放一个我自己反复测试过的例子。目标零件：一个圆形法兰盘，外径 120 毫米，内径 60 毫米，厚度 15 毫米；在外径和内径之间，均布 6 个直径为 12 毫米的螺栓孔，螺栓孔中心圆直径 90 毫米；外圆边缘做 1 毫米倒角。标准提示词如下：

“请使用 CadQuery+Python 生成一个法兰盘模型。单位统一为毫米。特征要求：主体为圆柱体，外径 120 毫米，内径为 60 毫米的贯通中心孔，厚度 15 毫米；6 个直径为 12 毫米的螺栓孔沿中心圆均布，该中心圆直径为 90 毫米；外圆两端边缘做 1 毫米倒角。建模顺序：先拉伸主体圆柱，再切中心孔，最后打 6 个螺栓孔并倒角。只输出可直接运行的 Python 代码，不做解释。”

我实测生成的一份可运行代码长这样：

import cadquery as cq # 主体：外径120mm => 半径60mm part = cq.Workplane("XY").circle(60).extrude(15) # 中心孔：直径60mm，贯通 part = part.faces(">Z").workplane().hole(60) # 螺栓孔：6个直径12mm，均布在直径90mm的圆上（半径45mm） part = ( part.faces(">Z") .workplane() .polarArray(45, 0, 360, 6) .hole(12) ) # 外圆边缘倒角：选择半径大于50的圆形边，做1mm倒角 part = part.edges("%CIRCLE", lambda e: e.radius() > 50).chamfer(1) # 导出STEP格式 cq.exporters.export(part, "flange.step")

注意，我针对 AI 输出做了两点调整：一是把可能的“直径/半径混淆”显式化，用注释标注了为什么是 60、为什么是 45；二是用polarArray替代了模型有时会生成的circle(forConstruction=True).vertices()方式，因为后者在环形布孔时很容易跑出错误结果。这两类坑，基本是 text-to-cad 最常见的“模型以为对了但其实错了”的场景。

3.4 生成结果的三重校验

代码跑通不等于结果正确。我的习惯是至少做三层校验。第一层是看渲染图，在 Notebook 里把 part 显示出来，确认形体大致符合预期。第二层是量化检查，用part.val().BoundingBox()量总尺寸，用part.volume()和part.area()确认没有多一块少一块，必要时用截面运算精确测量内径。第三层是把导出的 STEP 文件拖进自己熟悉的 CAD 软件，做一次正式的尺寸标注和干涉检查，确认它是可以被装配环境正常识别的几何体。

这三层校验听起来繁琐，但能挡住绝大多数问题。特别是第三层，我见过太多 AI 生成模型在 CadQuery 里渲染没问题，一进主流 CAD 软件却发现曲面方向反了或者精度标记异常。STEP 格式虽然兼容性不错，但导出时的精度设置、实体单位都需要确认一遍。如果只做外观预览，STL 导出也可以，但要做加工、装配、继续编辑，一定走 STEP。

4. 能用在哪儿，不能用在哪儿：边界与场景

4.1 真正落地的几个场景

以我目前的实践看，text-to-cad 最适合的领域是“从需求描述到初步方案”的加速，尤其在机械非标设计、结构件快速选型、教学演示这三类场景最有价值。

第一个场景是非标机械里的标准件批量生成。法兰、垫片、轴承座盖、防护罩这类零件，结构规律但规格繁多。让 text-to-cad 先生成一个参数化脚本，再通过脚本批量生成不同尺寸的型号，效率提升非常明显。我最近的一个项目里就靠这个路子，把几十种规格的垫片从模型库里自动生成了 STEP 文件，导入到总装里做干涉检查，省了至少两个工作日。这个用法本质上是把 AI 当成“参数化脚本的起点”，而不是直接依赖它每次输出新零件。

第二个场景是产品概念阶段的快速验证。设计师还在头脑风暴时，可以先让模型生成几个粗略的形体，配合手头的尺寸约束做筛选，比每换一个方案都重新画一遍草图要高效得多。第三个场景是高校和职业培训里的教学演示。学生用自然语言描述一个小零件，再对照模型看特征树，对理解建模顺序、特征语义都很有帮助。我自己带新人的时候，也会让他在 text-to-cad 的基础上改参数，比从空白草图开始练要容易建立整体感。

4.2 现阶段明显的短板

但是我也要把丑话说在前面。text-to-cad 目前不是万能的，有三类任务我坚决不让它碰。

第一类是复杂曲面造型。像水瓶曲面、汽车外观、有机形态的壳体，这些需要 NURBS 曲面和精细光顺控制的场景，语言模型很难用几条语句描述清楚，生成的代码往往只能给出一个非常“方正”的近似，达不到曲面设计要求。第二类是强工程约束场景。比如注塑件的拔模角度、公差配合、材料收缩率、应力圆角等工艺性约束，模型可能完全不理解这些参数之间的物理关系，生成了“形状对但工艺完全不能落地”的模型。第三类是复杂装配体。text-to-cad 目前基本还是单零件思维，涉及多零件、相互约束、传动关系时，它生成的装配结构往往逻辑混乱，还是要人工搭建装配树。

所以我的判断很明确：现阶段把它当“参数化模型的自动生成器”最合适，把它当“全自动工程师”则一定会失望。任何生成结果进入正式流程前，都应该有工程师做一次审核，这东西省的是重复劳动，不是专业判断。

5. 踩坑记录与常见问题速查

5.1 踩过的典型坑

我在这条路上踩坑真不少，挑三个最典型的分享。

第一个是直径半径的“坑中坑”，这是加密版。早期我让它生成“外径 120”的法兰盘，它居然写了一个半径 120 的圆，整个模型大了一倍。我当时一度以为生成环境出了问题，后来反复测试发现，只要提示词里不强调“直径”和“半径”的区别，模型就会随机猜。现在我的提示词里都有“圆半径等于直径除以二”这样的显式说明，出错率大幅下降。

第二个是特征顺序的坑。有一次它先生成了中心孔再拉伸主体，结果是孔被实体填没了，导出来的模型是一个实心圆柱。这类“布尔运算被特征顺序反转”的问题最难排查，因为它不会报错，渲染看起来还很正常，只有量尺寸时才发现中心孔不见了。现在我会在提示词里写清楚特征顺序，并且坚持用校验脚本检查内径。

第三个是单位混乱的坑。模型有时会生成 25.4 倍或 0.03937 倍的模型，明显是它把毫米和英寸的换算逻辑搞混了。这类错误非常隐蔽，只看形体会觉得“还挺像”，一量尺寸就发现全盘皆错。所以我每次生成后都强制做量化校验，而不是只看比例。

5.2 常见问题速查表

我整理了一张速查表，按“现象—可能原因—处理方式”三列排，平时排查直接对照着来：

5.3 几句大实话

用 text-to-cad 已经小半年了，我的个人体会是：这个工具真正改变的不是“建模”这个动作，而是“把需求转成模型”这条路径的起点。以前我们面对一页技术参数表，看到的是密密麻麻的二维数字，现在可以直接把这些数字组织成一段结构化的描述，让模型替我们完成从描述到特征树再到实体模型的翻译。但它毕竟不是万能的，很多行业经验、制造约束、装配逻辑，还是得靠人来把关。我自己最稳妥的用法是：生成模型 → 量化校验 → 导出 STEP → 在主流 CAD 环境里做复核和修正，把它当一个“特别会写参数化脚本的前同事”，而不是“全自动设计师”。

最后再分享一个压箱底的小技巧：当你准备用 text-to-cad 生成某个标准零件时，别急着写一句话让模型自由发挥，先搜一下这个零件在行业里的常用参数表，比如法兰的密封面厚度、螺栓孔数量标准，然后把关键参数直接写进提示词。这样生成的结果往往一次就能满足工程需求，比你反复调提示词修改要省事得多。这条经验，是我自己用多轮试错换来的，真心希望能帮你少走几步弯路。