1. 从一句话到三维模型：text-to-cad 到底在解决什么问题
第一次听到 “text-to-cad” 这个说法，是在一个做机械结构设计的朋友那里。他当时正对着屏幕上一堆拉伸、旋转、倒角的操作发愁，嘴里念叨着：“要是能直接打一行字，模型就自己长出来就好了。” 这句话其实精准地概括了 text-to-cad 的核心诉求——用自然语言描述一个零件的形状、尺寸、特征，由系统自动生成对应的三维 CAD 模型。
传统 CAD 建模的流程，无论是参数化建模还是直接建模，本质上都是“人告诉软件每一步怎么做”：先画草图，再约束尺寸，然后拉伸成实体，接着打孔、倒角、阵列。一个中等复杂度的零件，几十上百个特征操作是家常便饭。而 text-to-cad 想做的事情，是把“怎么做”这一层隐藏掉，让用户只描述“要什么”。比如输入“一个长 80mm、宽 40mm、高 20mm 的矩形块，四个角倒 R5 圆角，中心有一个直径 10mm 的通孔”，系统直接输出一个可编辑的 CAD 文件。
这件事听起来像是“AI 画图”的三维版本，但难度完全不在一个量级。二维图像生成可以容忍模糊、可以“大概像”，但 CAD 模型是要拿去加工、装配、出工程图的，尺寸必须精确，拓扑必须合法，特征必须可编辑。所以 text-to-cad 不是一个单纯的“生成”问题，而是一个“生成 + 约束 + 可制造性”的复合问题。
这篇文章适合几类人看：一是做机械设计、工业设计、建筑结构的朋友，想了解这个方向到底能不能落地、怎么落地；二是做 AI 应用开发的工程师，想知道从文本到三维模型这条链路里有哪些坑；三是对 CAD 自动化感兴趣但还没动手的人，我会把关键步骤和参数选择讲清楚，让你能照着搭一个最小可用的原型。
需要先说明一点：text-to-cad 目前不是一个成熟到“开箱即用”的通用工具，它更像是一个正在快速演进的领域。不同团队的做法差异很大，有的走“大模型直接生成 CAD 脚本”的路线，有的走“文本解析 + 参数化模板”的路线，还有的走“文本到中间表示再到 B-rep”的路线。我会把这几条路线的逻辑、优劣和实操要点都拆开讲，你可以根据自己的场景选一条最合适的。
2. 三条主流技术路线拆解：为什么没有“唯一正确解”
2.1 路线一：大模型直接生成 CAD 脚本
这是目前最“性感”的一条路。核心思路是：把 CAD 软件的操作 API 或者脚本语言（比如常见的参数化建模脚本、Python 建模库）作为目标语言，让大语言模型根据自然语言描述直接生成一段可执行的建模代码。代码跑完，模型就出来了。
这条路的优势很明显：灵活。只要模型能理解你的描述，理论上可以生成任意复杂的形状，不受预定义模板的限制。而且生成的脚本本身就是可编辑的，用户拿到之后可以改参数、加特征，符合工程师的工作习惯。
但坑也很多。第一，大模型对三维空间关系的理解并不稳定。你让它“在顶面中心打一个孔”，它可能把孔打到侧面去；你让它“沿 X 轴阵列 5 个”，它可能阵列方向搞反。第二，生成的脚本经常有语法错误或者 API 调用错误，需要反复调试。第三，也是最要命的一点：大模型生成的模型，尺寸精度没法保证。它可能给你一个“看起来差不多”的模型，但实际尺寸和你的描述差了几毫米，这在工程上是不可接受的。
我实测下来的经验是：这条路适合做“概念草图”或者“形状探索”，不适合直接出生产图。如果你要用，一定要在提示词里把尺寸、坐标系、特征位置写得极其明确，并且生成后必须人工核对关键尺寸。
2.2 路线二：文本解析 + 参数化模板
这条路的思路更“工程化”：先定义一套参数化模板库，每个模板对应一类常见零件（比如法兰、支架、齿轮、外壳）。然后写一个文本解析器，从自然语言里抽取关键参数（长宽高、孔径、孔位、圆角半径等），把参数填进模板，生成模型。
优势是稳定、可控、尺寸精确。因为模板本身就是参数化的，只要参数抽对了，模型一定是对的。而且生成速度快，不需要跑大模型，普通服务器就能扛住。
劣势是覆盖面有限。模板库只能覆盖你预先定义好的零件类型，遇到没见过的形状就无能为力了。而且文本解析器对自然语言的容错性比较差，用户换一种说法可能就抽不出参数了。
这条路适合什么场景？适合“批量生成标准件”或者“企业内部有固定产品系列”的情况。比如一家做铝型材连接件的公司，产品就是那几十种规格，完全可以用模板 + 解析的方式做一个内部工具，让销售或者客户直接输入需求，自动出模型。
2.3 路线三：文本到中间表示再到 B-rep
这是最“学术”但也最接近本质的一条路。核心思想是：自然语言先转成一种中间表示（比如特征树、CSG 树、或者草图约束图），再从中间表示生成最终的 B-rep（边界表示）模型。
中间表示的好处是，它把“语义”和“几何”解耦了。文本理解模块只需要负责把“一个带圆角的矩形板，中间有个孔”转成“板 + 圆角特征 + 孔特征”这样的结构，而不需要直接操心坐标和拓扑。几何生成模块再根据这个结构去计算具体的点和面。
这条路目前还在研究阶段，工程化案例不多。主要难点在于中间表示的设计：太简单了表达不了复杂形状，太复杂了文本理解模块又搞不定。而且从中间表示到 B-rep 的转换，涉及到大量的几何计算和拓扑处理，鲁棒性是个大问题。
不过我个人觉得，这条路是长期最有前途的。因为只有把语义和几何解耦，才能让系统既理解人的意图，又保证几何的合法性。如果你是在做研究或者长期产品规划，建议重点关注这个方向。
3. 核心实操：搭一个最小可用的 text-to-cad 原型
3.1 环境准备与工具选型
先说工具选型。如果你走的是“大模型生成脚本”路线，需要一个能跑大模型的環境，以及一个支持脚本建模的 CAD 内核。常见的组合是：用 Python 做胶水语言，用某个开源或商业的几何内核做建模，大模型通过 API 调用。
如果你走的是“模板 + 解析”路线，工具可以更轻量：一个文本解析库（比如正则或者简单的 NLP 工具），加上一个参数化建模库，就能跑起来。
我下面以“模板 + 解析”路线为例，因为这条路最容易复现，也最容易看到效果。大模型路线我会在后面的章节里补充关键注意点。
环境准备清单：
- Python 3.9 以上
- 一个参数化建模库（选你熟悉的即可，关键是支持脚本创建基本体、布尔运算、倒角、打孔）
- 一个文本解析方案（初期可以用正则，后期可以上小模型）
- 一个简单的 Web 界面或者命令行入口
注意：不要一上来就追求“通用”。先选一个你最熟悉的零件类型，把这一类的文本到模型跑通，再逐步扩展。我见过太多人一开始就想做“什么都能生成”的系统，结果三个月过去连一个法兰都没跑通。
3.2 定义模板与参数抽取规则
假设我们选“矩形板 + 孔 + 圆角”这一类零件作为起点。模板的定义大概是这样：
# 伪代码，展示模板结构 template = { "type": "plate_with_holes", "params": { "length": {"type": "float", "unit": "mm", "required": True}, "width": {"type": "float", "unit": "mm", "required": True}, "thickness": {"type": "float", "unit": "mm", "required": True}, "corner_radius": {"type": "float", "unit": "mm", "default": 0}, "holes": {"type": "list", "items": { "diameter": "float", "x": "float", "y": "float" }} } }参数抽取规则，初期用正则就够了。比如：
- 长宽高：匹配“长 80mm”“宽度 40”“厚度 20 毫米”这类模式
- 圆角：匹配“倒 R5”“圆角半径 5”“R5 圆角”
- 孔：匹配“直径 10 的通孔”“四个角各有一个 M6 的孔”
这里的关键是：规则要写得足够宽容，但抽取结果要足够严格。宽容是指用户怎么说都能识别，严格是指抽出来的数值必须带单位、必须能转成浮点数、必须在合理范围内。
我踩过的一个坑：用户说“打一个 10 个的孔”，这个“10 个”到底是直径 10mm 还是 10 个孔？后来我在规则里加了一条：如果“个”前面是数字且后面没有“孔”字，优先解释为数量；如果有“的孔”或者“孔”，优先解释为直径。这种歧义处理，是文本解析里最耗时间但也最有价值的部分。
3.3 从参数到模型的生成流程
参数抽出来之后，生成模型的过程就相对机械了。以矩形板为例：
- 根据 length、width、thickness 创建一个长方体
- 如果有 corner_radius，对四条竖直边做圆角
- 遍历 holes 列表，在每个 (x, y) 位置打一个直径 diameter 的通孔
- 导出为 STEP 或 STL 文件
这个过程里，有几个参数选择需要说明：
圆角半径的选择：圆角半径不能大于板厚的一半，否则几何会自交。比如板厚 20mm，圆角半径最多给到 9.9mm 左右。如果用户输入的圆角半径超了，系统应该给出警告并自动截断，而不是直接报错退出。
孔位坐标系：一定要明确原点在哪里。我建议把原点设在板的左下角，X 轴沿长度方向，Y 轴沿宽度方向。这样用户说“在中心打孔”时，坐标就是 (length/2, width/2)，不容易搞错。
孔与边的距离：如果孔太靠近边缘，会导致壁厚过薄甚至破边。一般建议孔边到零件边缘的距离不小于孔径的 1/4。这个规则可以在生成前做一次校验，不满足就提示用户。
实操心得：生成模型之前，一定要做一轮“几何合法性检查”。包括：尺寸是否为正、圆角是否过大、孔是否超出边界、孔与孔是否干涉。这些检查花不了多少代码，但能避免大量无效生成。
3.4 输出格式与后续编辑
生成的模型最好导出为 STEP 格式，因为 STEP 是通用的三维交换格式，几乎所有 CAD 软件都能打开和编辑。如果只是做展示，STL 也可以，但 STL 没有特征信息，没法参数化编辑。
如果你希望用户能在 CAD 软件里继续修改，那就要确保生成的模型是“特征化”的，而不是一个死实体。这就要求建模库支持特征树，或者你生成的脚本本身就是参数化的。这一点在选型阶段就要考虑清楚。
4. 大模型路线的关键细节与避坑指南
4.1 提示词怎么写才能让模型少犯错
如果你走大模型生成脚本的路线，提示词的质量直接决定输出质量。我总结了一个“四段式”提示词结构：
第一段：角色和任务。明确告诉模型“你是一个 CAD 脚本生成助手，根据用户描述生成可执行的建模脚本”。
第二段：API 说明。把建模库的核心 API 列出来，包括创建长方体、圆柱、打孔、倒角、布尔运算的函数签名和参数含义。这一步非常关键，模型不知道你的 API 长什么样，就只能瞎编。
第三段：约束和规则。比如“所有尺寸单位统一为毫米”“坐标系原点在零件左下角”“孔必须是通孔”“圆角半径不能超过板厚的一半”。
第四段：用户输入。把用户的自然语言描述放进去。
实测下来，加了 API 说明之后，脚本的首次可执行率能从不到 30% 提升到 70% 左右。剩下的 30% 主要是空间关系理解错误和尺寸计算错误，需要人工修正或者加后处理校验。
4.2 尺寸精度问题的处理策略
大模型生成的最大风险是尺寸不准。我的处理策略是“双重校验”：
第一重，在提示词里要求模型输出一个参数表，把所有关键尺寸列出来。比如“请先输出一个 JSON 格式的参数表，包含长、宽、高、孔径、孔位坐标，然后再生成脚本”。
第二重，脚本生成后，用正则或者 AST 解析的方式，从脚本里反向提取实际使用的尺寸，和参数表对比。如果不一致，就报警或者自动修正。
这个策略不能保证 100% 准确，但能把错误率降到可接受的范围。对于精度要求高的场景，最终还是需要人工核对关键尺寸。
4.3 常见错误类型与修复方法
我整理了一个常见错误速查表：
| 错误类型 | 典型表现 | 修复方法 |
|---|---|---|
| API 调用错误 | 函数名拼错、参数个数不对 | 在提示词里给完整 API 文档，加后处理校验 |
| 坐标系错误 | 孔打到侧面、阵列方向反了 | 明确坐标系定义，要求模型先输出坐标计算过程 |
| 尺寸单位混乱 | 把 mm 当成 cm，或者漏写单位 | 统一在提示词里规定单位，后处理做单位校验 |
| 几何自交 | 圆角过大导致面重叠 | 加几何合法性检查，超限自动截断 |
| 特征顺序错误 | 先打孔后倒角导致孔变形 | 在提示词里规定特征顺序，或者后处理重排 |
注意：不要指望大模型一次生成就完美。把它当成一个“快速草稿生成器”，生成后必须有人工校验和修正的环节。完全自动化的 text-to-cad，目前还不现实。
5. 应用场景与影响范围分析
5.1 哪些场景最适合先用起来
text-to-cad 不是万能的，但在以下几类场景里，它能带来实实在在的效率提升：
场景一：标准件和常用件的快速生成。比如螺栓、螺母、垫圈、法兰、轴承座。这些零件形状固定，只是尺寸不同。用模板 + 参数抽取的方式，可以让非专业人员也能快速生成模型，减少工程师的重复劳动。
场景二：概念设计阶段的形状探索。在产品定义阶段，结构工程师需要快速试几种不同的形状方案。用大模型生成脚本的方式，可以在几分钟内得到多个可编辑的模型，比手动建模快得多。虽然精度不够，但用于讨论和评审足够了。
场景三：客户定制化需求的快速响应。比如做非标设备的企业，客户经常给一个简单的描述就要报价。如果能快速生成一个大概的模型，用于估算体积、重量、材料成本，能显著缩短报价周期。
场景四：教学和培训。初学者学 CAD，最大的障碍是“不知道从哪里下手”。text-to-cad 可以让他们先用自然语言描述一个形状，看到生成的模型，再反过来学习建模步骤。这是一种“逆向学习”的路径，效果不错。
5.2 对 CAD 工程师工作方式的影响
短期来看，text-to-cad 不会取代 CAD 工程师，但会改变他们的工作重心。以前大量时间花在“画图”上，以后可能更多花在“审核”和“优化”上。工程师需要具备的能力，从“熟练操作软件”逐渐转向“准确描述需求”和“判断模型质量”。
长期来看，如果 text-to-cad 的精度和鲁棒性继续提升，那么“建模”这个动作本身可能会被重新定义。就像现在很少有人手写汇编语言一样，未来可能很少有人手动拉伸草图。但这需要时间，也需要整个工具链的配合。
5.3 当前的技术边界与不能做的事
必须说清楚，text-to-cad 目前做不到的事情：
- 不能生成复杂曲面（比如汽车外形、涡轮叶片）
- 不能保证装配体的配合关系（比如齿轮啮合、轴承配合）
- 不能处理工程图标注、公差、材料属性等制造信息
- 不能替代工程师对可制造性的判断
这些边界不是技术不够好，而是问题本身太复杂。三维几何的复杂性，远不是“文本生成”这一个技术能覆盖的。所以我的建议是：把 text-to-cad 当成一个“辅助工具”，而不是“替代方案”。用它来处理那些重复性高、形状简单的任务，把工程师的时间释放出来做更有价值的事。
6. 实操中踩过的坑与独家经验
6.1 文本歧义是最大的敌人
自然语言里充满了歧义。“打一个 10 的孔”可以是直径 10mm，也可以是 10 个孔。“倒个角”可以是倒圆角，也可以是倒直角。“中心对称”可能是指关于原点对称，也可能是指关于某个面对称。
我的处理经验是：不要试图让系统“猜对”，而是让它“问清楚”。当解析结果有歧义时，系统应该主动列出可能的解释，让用户确认。比如：“您说的‘10 的孔’，我理解为直径 10mm 的孔，对吗？如果是 10 个孔，请告诉我孔的位置。” 这种交互式澄清，比强行猜测要可靠得多。
6.2 单位问题比想象中更常见
我见过太多因为单位搞错导致模型差 10 倍甚至 1000 倍的案例。用户说“长 100”，可能是 100mm，也可能是 100cm，还可能是 100 英寸。如果系统默认按 mm 处理，而用户心里想的是 cm，那模型就完全错了。
我的做法是：强制要求用户输入单位，或者在界面上提供一个单位选择器。如果用户没写单位，系统不要默认，而是追问。这个小小的交互设计，能避免大量低级错误。
6.3 几何合法性检查不能省
前面提过，但这里再强调一次：几何合法性检查是 text-to-cad 系统里最容易被忽视、但最不能省的一环。我踩过的坑包括：圆角半径大于板厚导致建模失败、孔位超出边界导致打孔失败、孔与孔之间距离太近导致壁厚为零。
这些错误如果不在生成前拦截，就会在建模库里报错，而建模库的报错信息通常很难懂。用户看到一堆几何异常信息，根本不知道是自己描述错了还是系统有问题。所以一定要在生成前做一轮“人类可读”的检查，把问题翻译成用户能理解的语言。
6.4 不要追求“一次生成完美”
这是心态问题。很多人做 text-to-cad，总想着“用户说一句话，系统出一个完美模型”。这个目标在简单零件上可能实现，但在复杂零件上几乎不可能。
更现实的做法是：把 text-to-cad 定位成“快速草稿”工具。用户描述需求，系统生成一个大概的模型，用户在这个基础上修改、调整、补充。这样既发挥了 AI 的速度优势，又保留了人的判断力。我实测下来，这种“人机协作”的模式，比追求全自动化的模式，实际效率更高，用户满意度也更好。
7. 后续扩展方向与个人建议
如果你已经跑通了一个最小原型，接下来可以考虑几个扩展方向。
第一个方向是增加模板库的覆盖面。从矩形板扩展到圆柱体、圆锥体、齿轮、弹簧等常见形状。每增加一个模板，系统的适用范围就扩大一圈。但要注意，模板不是越多越好，维护成本会随着模板数量增加而上升。建议优先覆盖你实际业务中最常用的那几类。
第二个方向是引入更强大的文本理解能力。初期用正则，后期可以换成小型的语言模型，专门做参数抽取和意图识别。这样能处理更灵活的表达方式，减少“用户换个说法就识别不了”的问题。
第三个方向是和现有 CAD 软件集成。把 text-to-cad 做成一个插件，用户在 CAD 软件里直接输入描述，模型就出现在当前工作区。这种无缝体验，比单独做一个 Web 工具要实用得多。
第四个方向是加入反馈学习机制。记录用户对生成模型的修改，比如改了哪个尺寸、加了什么特征，把这些修改作为反馈数据，用来优化模板和解析规则。用得越多，系统越懂你的习惯。
我个人在实际操作中的体会是：text-to-cad 的价值不在于“替代建模”，而在于“降低建模的门槛”。它让不会 CAD 的人也能表达自己的设计意图，让会 CAD 的人从重复劳动中解放出来。这个方向值得投入，但不要指望一夜之间改变一切。从一个小场景开始，跑通闭环，再逐步扩展，是最稳妥的路径。
最后分享一个小技巧：如果你不确定用户会怎么描述一个零件，最好的办法是找几个非 CAD 专业的人，让他们用自然语言描述同一个零件，然后收集这些描述，作为你解析规则的测试用例。你会发现，真实用户的表达方式，比你想象的丰富得多，也混乱得多。把这些真实语料吃透，你的系统才算真正可用。
