CAD这行当有个特别拧巴的地方设计师脑子里想的是一个直径80毫米、带四个M8沉头孔的法兰盘手上干的却是先画中心线、再偏移、再修剪、再打孔、再标注这一长串机械动作。中间隔着的这层翻译就是几十年没被真正解决的老大难。Text2CAD想干的事说白了就是把中间这层翻译交给模型——你说人话它出模型。这个方向这两年热度一直往上走但真正落地到能用的程度坑比想象中多得多。下面我按自己折腾这套东西的实际经验把从文本到CAD模型这条链路拆开讲清楚包括它到底怎么工作、哪些环节最容易翻车、以及怎么把它接进你现有的工作流里。1. Text2CAD到底在解决哪个环节的问题1.1 先搞清楚CAD模型的三种存在形式很多人一上来就以为Text2CAD是输入一句话直接吐出一个能加工的零件这个理解偏差会让人在后面调试时完全找不到方向。CAD模型在计算机里其实有三种截然不同的存在形式理解这三层是理解整个技术链路的前提。第一种是参数化特征树也就是你在SolidWorks、中望CAD、Fusion里看到的那个左侧历史树里面记录的是拉伸1、圆角2、阵列3这样的操作序列每个操作带着具体参数。这是最值钱的形式因为它可编辑、可修改、可驱动后续加工。第二种是边界表示BRep也就是用数学曲面拼出来的实体几何能算体积、能做布尔运算但改起来很麻烦。第三种是网格Mesh就是一堆三角面片渲染好看、3D打印能用但没有任何工程语义。Text2CAD目前主流的技术路线绝大多数产出的是第二种和第三种能直接产出第一种的极少。原因很简单特征树要求模型理解操作顺序和参数依赖这是序列决策问题比生成几何难一个量级。所以你在评估任何Text2CAD方案时第一个要问的问题就是它输出的是特征树、BRep还是Mesh这个答案直接决定了你拿到结果之后能不能改。1.2 文本到几何的语义鸿沟具体卡在哪从一个带四个沉头孔的法兰盘这句话到真正的几何体中间要跨过好几道坎。第一道是尺寸缺失人说话天然省略尺寸但CAD没有尺寸就建不了模模型必须自己补全或者反问用户。第二道是拓扑关系模糊四个孔均匀分布里的均匀到底是等角度还是等弧长在圆盘上是一回事在椭圆盘上就完全是两回事。第三道是特征顺序不确定先打孔再倒角和先倒角再打孔结果可能完全不同。这三道坎对应着三类不同的技术手段尺寸补全靠参数预测模型拓扑消歧靠约束求解器特征排序靠序列生成模型。市面上很多demo看着惊艳其实是把这三块里最难的部分偷偷简化掉了——比如只支持固定尺寸的标准件或者只输出网格不输出特征。你在选型时如果发现某个方案对输入文本的格式要求特别严格必须写成长X宽Y高Z这种那基本可以判断它绕过了语义理解这一关。1.3 为什么这个方向突然能做了五年前做这件事基本没戏因为那时候的文本模型理解不了工程语义几何生成模型也生成不了带精确约束的实体。这两年能推进核心是两件事凑齐了一是大语言模型对工程描述的解析能力上来了能把自然语言拆成结构化的特征列表二是**程序化CAD如CadQuery、OpenSCAD这类代码驱动建模**成熟了让文本→代码→模型这条链路变得可行。这里有个关键洞察当前最靠谱的Text2CAD路线其实是文本→建模脚本→CAD模型而不是文本→几何直接生成。因为脚本是可读、可改、可版本控制的模型生成错了你还能去看脚本哪一行写歪了。直接生成几何的话错了你连从哪下手都不知道。这个认知能帮你省下大量调试时间。2. 拆解一条能跑通的文本到模型链路2.1 整体架构四段式流水线我把实际能用的链路拆成四段每段职责清晰出问题也好定位。阶段输入输出核心技术常见失败点语义解析自然语言描述结构化特征列表大语言模型提示工程特征漏识别、单位混淆参数补全特征列表带完整参数的规格规则库默认值推理尺寸瞎猜、公差缺失代码生成规格建模脚本代码生成模型模板语法错、API用错执行验证脚本CAD模型建模内核执行几何无效、布尔失败这四段里第一段和第三段是模型负责的第二段和第四段是工程兜底的。很多人只盯着模型那两段结果发现模型再强也架不住参数乱补和执行报错。真正决定这套东西能不能用的往往是第二段和第四段的工程质量。2.2 语义解析阶段提示词怎么写才不翻车语义解析这步模型要把一个外径100、内径60、厚10的垫圈边缘倒个R2的圆角拆成结构化的东西。这里提示词设计有几个实战要点。第一强制结构化输出。别让模型自由发挥直接要求它输出JSON字段固定。我常用的字段包括零件类型、特征列表每个特征带类型和参数、单位、对称性、约束条件。字段固定之后下游解析才不会崩。第二单位必须显式声明。工程里毫米和米混用是灾难模型默认可能给你按米算。提示词里明确写所有尺寸单位为毫米未标注时默认毫米能挡掉一大类错误。第三要求模型标注不确定项。与其让模型硬猜不如让它把没把握的地方标出来比如输出一个uncertain: [孔径未指定, 孔数量未指定]字段。这样下游可以走默认值或者反问用户而不是默默生成一个错的东西。一个实际可用的提示词骨架大概是这样你是一个CAD特征解析器。将用户的自然语言描述转换为JSON格式的特征列表。 规则 1. 所有尺寸单位为毫米未标注默认毫米 2. 每个特征包含 type、parameters、position 三个字段 3. 无法确定的参数放入 uncertain 数组不要臆造 4. 只输出JSON不要任何解释文字 用户描述{user_input}2.3 参数补全阶段默认值库比模型更重要模型解析完你会发现一堆参数是空的。这时候别指望模型再猜一遍正确做法是建一个默认值库。比如沉头孔没给尺寸就按M6/M8/M10的标准沉头尺寸查表补圆角没给半径就按板厚的十分之一给个经验值。这个默认值库的价值在于可预测。模型每次猜可能都不一样但查表每次结果一致出了问题也好复现。我一般会维护这么几类默认规则标准件查表螺栓孔、沉头孔、键槽按国标查比例经验值圆角取板厚1/10倒角取1~2mm壁厚取跨度的1/20对称推断如果描述里出现均匀分布对称自动补全阵列参数单位归一所有输入统一转成毫米再往下走提示默认值库一定要版本化。你今天改了圆角默认规则三个月后复现老项目时如果找不到当时的规则结果就对不上了。2.4 代码生成阶段为什么选脚本而不是直接出几何前面提过脚本路线比直接生成几何靠谱得多。这里展开说下具体怎么落地。以CadQuery为例一个法兰盘的建模脚本大概长这样import cadquery as cq # 法兰盘主体 result ( cq.Workplane(XY) .circle(50) # 外径100 .circle(30) # 内径60 .extrude(10) # 厚10 .edges(|Z) .fillet(2) # 边缘R2圆角 ) # 四个M8沉头孔均匀分布 result ( result.faces(Z) .workplane() .polarArray(35, 0, 360, 4) .cboreHole(4.5, 9, 5) # M8沉头孔 ) cq.exporters.export(result, flange.step)这段脚本的好处是每一行都能对应到设计意图。外径不对改circle(50)。孔位置不对改polarArray的半径。模型生成错了你打开脚本一眼就能看出是哪一步歪了。如果换成直接生成几何你面对的就是一坨面片改都不知道从哪改。代码生成这步的提示词关键是给足API示例。模型对CadQuery、OpenSCAD这些库的API记忆不一定准你需要在提示词里塞几个典型特征的写法示例让它照着套。我一般会准备一个特征-代码片段对照表覆盖圆、方、孔、阵列、倒角、圆角、抽壳这些高频操作生成时按需注入。2.5 执行验证阶段几何有效性检查不能省脚本跑完不代表模型能用。CAD内核执行时可能遇到布尔运算失败、自相交、零厚度这些问题。这步必须加自动检查体积检查算出来的体积是不是正数、是不是在合理范围包围盒检查尺寸是不是和预期一致拓扑检查是不是有效的实体solid而不是一堆散面导出测试能不能成功导出STEP/STL任何一项不过就把错误信息回传给代码生成环节重试。这个自动重试循环是让整套系统从能跑demo到能干活的关键。我实测下来加上两轮重试成功率能从六成提到八成五以上。3. 实测中最容易翻车的几个地方3.1 单位陷阱模型默认按米算的坑这个坑我踩过不止一次。你写直径100心里想的是100毫米模型可能理解成100米生成一个直径一百米的圆盘导出的时候直接爆内存。更隐蔽的是有些建模库内部默认单位是米你传100进去它当100米处理最后模型尺寸差一千倍。解决办法是在链路两端都做单位校验。输入端强制声明单位输出端检查包围盒尺寸是否在合理范围比如零件尺寸超过10米就报警。别嫌麻烦这个检查能挡掉一大类低级错误。3.2 特征顺序先打孔还是先倒角前面提过特征顺序问题这里给个具体例子。一个带孔的板如果先打孔再对边缘倒角倒角不会影响孔如果先倒角再打孔孔如果靠近边缘可能会切到倒角面导致几何异常。模型生成脚本时如果顺序搞反轻则形状不对重则布尔运算直接失败。实战中的处理办法是在提示词里规定特征顺序优先级先做主体形状再做减材料特征孔、槽最后做修饰特征倒角、圆角。这个顺序符合大多数加工逻辑也能避开大部分几何冲突。3.3 阵列参数的歧义等角度还是等弧长均匀分布这个词在圆形阵列里没歧义但在非圆路径上就有歧义了。比如沿椭圆边缘均匀分布8个孔是角度均匀还是弧长均匀两者结果完全不同。模型默认往往按角度均匀处理但工程上很多时候要的是弧长均匀。这类歧义没法靠模型自己解决得靠提示词里明确约束或者干脆在参数补全阶段反问用户。我的做法是凡是涉及非圆路径阵列的一律标记为uncertain走人工确认。宁可多问一句也别生成一个错的。3.4 布尔运算失败的排查链路布尔运算失败是最高频的报错排查起来也有套路。我一般按这个顺序查看是不是零厚度两个面贴在一起没重叠布尔就会失败。检查特征之间有没有留间隙。看是不是自相交生成的几何自己和自己相交内核处理不了。常见于复杂的扫掠和放样。看是不是精度问题两个面理论上重合但数值上有微小偏差导致内核判定为无效。可以适当放宽容差。看是不是特征顺序问题回到3.2节说的调整顺序重试。这个排查链路我整理成了一张对照表出问题时按表走比瞎试快得多报错类型首要怀疑快速验证方法布尔失败零厚度/自相交单独导出每个特征看是否有效导出为空单位错误/尺度异常检查包围盒尺寸形状错位坐标系/阵列参数打印每个特征的定位点圆角失败半径过大/边不连续减小半径重试3.5 模型幻觉出不存在特征的处理大语言模型有个毛病你描述里没提的东西它可能自己加。比如你说一个圆柱它可能给你加个倒角理由是通常圆柱都有倒角。这在聊天场景无所谓在CAD里就是灾难——多一个特征可能导致装配装不上。对策是在提示词里明确禁止臆造并且要求模型对每个生成的特征标注来源是用户明确说的还是推断的。推断出来的特征走单独确认流程。我一般会在输出JSON里加个source: explicit或source: inferred字段下游据此决定要不要人工过一遍。4. 把它接进真实工作流的几种姿势4.1 单件快速建模当草稿生成器用最直接的用法是把它当草稿生成器。你脑子里有个大概形状先用文字描述让模型生成一版然后在这个基础上手动改。这种用法不要求模型一次到位只要方向对就行能省掉从零开始画的时间。实测下来对于规则的回转体、板类零件、简单支架这套流程能省一半以上的时间。对于复杂曲面、自由造型基本帮不上忙还是得手动来。所以定位要清楚它是加速器不是替代品。4.2 批量变型设计参数化模板的自动化这个用法价值更大。如果你有一类零件形状固定只是尺寸变可以先用Text2CAD生成一个参数化脚本模板然后把尺寸参数抽出来做成表格批量跑。比如一系列不同规格的法兰盘你只要维护一张尺寸表脚本自动生成所有型号。# 批量生成不同规格法兰盘 specs [ {od: 80, id: 40, thickness: 8, holes: 4}, {od: 100, id: 60, thickness: 10, holes: 6}, {od: 120, id: 80, thickness: 12, holes: 8}, ] for i, spec in enumerate(specs): model build_flange(**spec) cq.exporters.export(model, fflange_{i}.step)这种批量场景下Text2CAD的价值不在生成而在帮你把自然语言需求快速转成可复用的参数化脚本。脚本一旦成型后面就是纯工程活了。4.3 和现有CAD软件的衔接生成的STEP文件可以直接导入中望CAD、SolidWorks这些软件继续编辑。但要注意导入的模型是没有特征树的就是一堆几何。想改尺寸得用直接建模工具或者回到脚本改。所以如果你的工作流重度依赖特征树建议把脚本也一起存下来改的时候改脚本重新生成而不是在CAD里硬改几何。另外如果团队里有人不熟悉脚本可以把脚本包装成一个简单的表单工具填参数点生成降低使用门槛。这块用Python的Streamlit或者Gradio搭个界面半天就能搞定。4.4 版本管理和可追溯性用脚本路线的一个隐藏好处是可追溯。每个模型对应一个脚本脚本进Git谁改了什么一目了然。这在做系列产品、需要追溯设计变更的场景下特别有用。相比之下直接生成的几何模型没法diff改了什么根本看不出来。我一般会把项目组织成这样project/ ├── specs/ # 自然语言描述和解析后的JSON ├── scripts/ # 生成的建模脚本 ├── models/ # 导出的STEP/STL └── defaults.yaml # 默认值库这样从需求到模型整条链路都可追溯出了问题能快速定位是哪一环。5. 关于这套技术现阶段的能力边界5.1 它擅长什么、不擅长什么用下来Text2CAD目前的能力边界挺清晰的。擅长的规则几何、标准件、参数化程度高的零件、批量变型。不擅长的自由曲面、复杂装配、需要大量工程判断的设计比如考虑受力、散热、装配工艺的。这个边界短期内不会有大变化因为自由曲面和复杂装配涉及的设计意图太多不是文本能描述清楚的。所以别指望它替代设计师把它当成一个把明确需求快速变成几何的工具就好。5.2 精度和公差的处理工程图上的公差、表面粗糙度这些目前Text2CAD基本处理不了。它能生成名义几何但公差标注、技术要求这些还得人工加。所以它产出的是设计初稿不是可交付图纸。这个定位要清楚不然会失望。5.3 和AI Agent结合的可能性最近AI Agent这个概念很热Text2CAD和Agent结合是个有意思的方向。想象一下一个Agent接收需求自动解析、生成脚本、执行、检查、发现问题自动修正、最后输出模型。这个闭环目前技术上可行但工程上还需要不少打磨尤其是错误自动修正这块模型的自纠能力还不够稳。我试过一个简化版的Agent流程让它自己跑生成-检查-重试循环简单零件能跑通复杂一点的就容易陷入死循环。所以现阶段还是人在环里比较靠谱Agent负责跑腿人负责判断。5.4 数据安全和本地化部署的考虑如果涉及企业设计数据把描述文本发到外部服务是有风险的。这时候可以考虑本地部署开源模型虽然效果比云端大模型差一些但数据不出内网。建模脚本的执行本来就在本地这块没问题。选型时把数据流向搞清楚别把敏感设计描述发到不该发的地方。6. 给想上手的人的几条实在建议如果你打算试试这套东西我给几条踩过坑之后的建议。第一从脚本路线入手别碰直接生成几何的方案。脚本可读可改可追溯调试成本低一个量级。直接生成几何的方案看着酷出问题你连从哪查都不知道。第二先把默认值库建起来。别指望模型把参数都补全工程兜底比模型猜测靠谱。默认值库建好了整套系统的稳定性会明显提升。第三自动检查一定要加。体积、包围盒、拓扑、导出这四项检查花不了多少代码但能挡掉大部分低级错误。加上重试循环成功率提升很明显。第四定位成草稿生成器别指望一步到位。现阶段它产出的是设计初稿后面的人工修改和工程判断省不掉。心态摆正了用起来就顺。第五单位、顺序、阵列这三块重点盯。这三个是最高频的翻车点提示词里把规则写死能省很多事。最后分享一个我自己的小习惯每次生成完模型我都会把当时的提示词、解析出的JSON、生成的脚本、导出的模型四个文件一起存档。过几个月回头看能清楚知道当时是怎么想的、模型为什么长这样。这个习惯在排查为什么这个模型和预期不一样的时候特别有用因为你能完整复现当时的整条链路。CAD这行讲究的就是可追溯用AI生成模型也一样链路清楚了心里才踏实。