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 专业的人让他们用自然语言描述同一个零件然后收集这些描述作为你解析规则的测试用例。你会发现真实用户的表达方式比你想象的丰富得多也混乱得多。把这些真实语料吃透你的系统才算真正可用。 
长河君 · 2026/10/24 22:49:27 · 阅读 1.2k text-to-cad 技术解析：从自然语言到三维模型的实现路径
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 专业的人让他们用自然语言描述同一个零件然后收集这些描述作为你解析规则的测试用例。你会发现真实用户的表达方式比你想象的丰富得多也混乱得多。把这些真实语料吃透你的系统才算真正可用。