★ FEATURED ARTICLE 打开最近的技术趋势榜text-to-cad 这个名字频繁出现其实一点都不意外。做了几年 CAD 二次开发和自动化设计工具我很清楚这个方向踩中了多少痛点设计师脑子里想得清清楚楚的一个零件落到软件里要从草图、约束、拉伸一步步来中间还要反复修改参数。而 text-to-cad 的思路就是让你用一句话直接生成可编辑的参数化模型把想和做之间的路径缩到最短。这篇文章我不打算复述那些官方演示视频里的漂亮案例而是从实际落地的角度拆解 text-to-cad 背后的核心技术链、工具选型、提示词调优方法以及我在真实建模过程中踩过的坑和验证过的技巧。适合正在评估这个方向的设计师、对 AIGC 应用于工程领域感兴趣的开发者以及想快速上手 text-to-cad 的建模爱好者。1. 内容整体设计与思路拆解1.1 text-to-cad 到底在解决什么问题传统 CAD 建模有个绕不开的矛盾软件功能越强操作成本越高。一个简单的法兰盘熟练工程师五分钟搞定新手可能要对着草图绘制和约束关系研究半天。而 text-to-cad 的核心思路是把通过鼠标和键盘操作软件变成通过自然语言描述意图再由大模型把意图翻译成可执行的建模代码。这里的关键词是可执行的建模代码不是生成一张图片或者一个 mesh 网格。这也是 text-to-cad 和普通文生图、文生 3D 工具的本质区别。图片和网格是死的没法继续编辑而代码生成的模型是参数化的生成之后你还能改尺寸、改位置、改布尔运算关系。也就是说text-to-cad 不是替代设计师而是替代那些重复性的操作型建模工作把人的精力释放到更上层的设计决策上。从技术实现角度看text-to-cad 本质上是一个从自然语言到程序代码的翻译问题。准确说是翻译成 CAD 内核能够解析的脚本语言比如 CadQuery 的 Python 脚本、OpenSCAD 的 .scad 文件或者 FreeCAD 的 Python API。模型需要同时理解自然语言中的几何语义比如直径 20 的圆孔和工程语义比如法兰盘加强筋卡扣再转化成一系列几何操作序列。举个例子用户输入一个直径 80mm、厚度 10mm 的圆盘中心有一个直径 20mm 的通孔圆周上均匀分布 6 个直径 8mm 的螺丝孔。这句描述在传统 CAD 里需要至少三步操作画圆盘草图、拉伸、阵列打孔。而 text-to-cad 系统需要把这个过程拆解成 CadQuery 中对应的 workplane 操作、拉伸、打孔、阵列每一步的参数怎么算、操作的先后顺序如何决定这才是真正的难点。1.2 为什么选择基于程序化建模的路线市面上的 3D 生成方案不少很多项目走的是文生 3D 模型路线用扩散模型直接生成体素、点云或者隐式场再通过 marching cubes 算法提取网格。这类方案有一个通病生成结果非常好看但拿到实际工程场景里根本不适用。网格模型导入 CAD 软件之后没法做圆角、倒角、抽壳、布尔运算这些基础操作更别提这个孔从 20mm 改成 25mm这种天经地义的需求。所以真正靠谱的 text-to-cad 实现必须围绕程序化建模引擎来构建。CadQuery 是这方面最合适的选择理由有三个第一CadQuery 基于 Python模型对自然语言理解好、代码生成模型对 Python 的生成质量也非常成熟。第二CadQuery 构建的是 BREP 实体模型自带拓扑关系导出的 STEP 文件能被主流 CAD 软件原生识别不像网格模型需要一堆修复流程。第三CadQuery 采用自底向上的构建顺序描述一个长方体加一个圆孔代码顺序和自然语言的语序天然匹配降低了模型理解自然语言并映射到代码的难度。我测试过用 OpenSCAD 做同样的事情虽然也可以但 OpenSCAD 的 CSG 语法和自然语言的映射逻辑没有 CadQuery 那么直观。比如在圆盘圆周上均匀分布 6 个螺丝孔OpenSCAD 需要自己算角度坐标而 CadQuery 有现成的 polar 阵列直接对应自然语言中的均匀分布。这里必须补充一个容易被忽略的点text-to-cad 生成的不是最终模型而是建模过程的代码。这意味着用户拿到代码之后可以自由调整而不是被锁死在一个生成结果里。这个特性让它天然适合做设计探索阶段的快速原型你可以连续输入十个变体描述然后选择最满意的一个方向深入。2. 核心细节解析与实操要点2.1 文本到几何的语义映射机制在开始实操之前有必要理解系统内部是怎么把文字变成几何的。目前主流的 text-to-cad 实现模式分两层第一层是自然语言理解层负责抽取参数和语义第二层是代码生成层负责把抽取到的信息编译成 CAD 脚本。自然语言理解层通常是经过微调的大语言模型。输入是用户的一句话输出是结构化的中间表示常见的做法有三种。第一种是直接输出 CadQuery 代码端到端搞定这是最简单也最常见的方案第二种是先输出一段 JSON包含几何类型、尺寸参数、位置关系、特征操作表再通过模板转换器把 JSON 翻译成 CadQuery 脚本这种方案的参数可控性更强不容易出现模型记住语法但算错尺寸的问题第三种是让模型生成一个伪代码再用规则引擎逐步编译这个方案工程量大、目前落地不多。我实测下来直接生成 CadQuery 代码的端到端方案对简单零件箱体、法兰、支架的成功率最高简单描述基本一次成型。但对于复杂零件比如带抽壳、变半径圆角、多实体布尔运算的模型经常出现明显错误要么参数不匹配要么操作顺序不对。结构化中间表示的方案在小范围测试中错误率更低但模型需要额外推理应该生成一个什么样的 JSON 结构响应速度会慢一些。实操层面的一个关键是不要追求模型自动理解一切而是通过提示词约束它的输出格式。比如明确要求先定义变量再使用 CadQuery 命令每个步骤必须添加注释生成结果的稳定性和可读性都会大幅提升。2.2 参数命名与描述粒度的影响自然语言描述里的每一个修饰词都可能影响最终模型的参数表达。我做了大量对比测试总结出几个规律。描述粒度要精确。同样表达做一个圆盘直径 80mm 的圆盘和一个盘子生成结果完全是两个等级。前者生成的代码里会出现 Cylinder 实体的 radius 参数后者模型可能直接输出一个拉伸过的圆环甚至一个椭圆。text-to-cad 不是魔法它本质上是参数翻译器输入的信息密度直接决定输出的精度。尺寸单位要统一。CadQuery 默认使用毫米如果描述里混用厘米和毫米模型很可能忘记换算。我在测试中就遇到过半径 1.5cm被直接翻译成 radius1.5mm 的情况生成的模型肉眼不可见。我的建议是提示词里强制声明所有尺寸单位均为毫米并且在描述中全部使用毫米表达。几何关系要显式化。人理解圆盘上开孔很容易但模型需要知道开孔的中心点在哪里。描述中必须把中心孔偏心孔圆周分布这类位置关系说清楚。如果只说打一个孔模型可能默认在原点打孔也可能在盘面中心打孔表现不稳定。我一般会在描述里加上锚点信息比如以圆盘中心为圆心距离边缘 5mm 处这能让生成的成功率提升一大截。2.3 语言表达中模糊信息的处理策略自然语言天然带模糊性换一个角度说这是 text-to-cad 最大的优势——你可以用模糊的表达快速探索形态再用精确的表达收敛方案。但如果不理解模糊信息的处理策略使用体验就会很差。首轮探索阶段可以故意模糊。想让模型给你几个方案方向就输入一个类似手机支架的零件带有卡槽和倾斜面厚度适中模型大概率会给出一个基础形态。然后在它的基础上逐步追加精确参数卡槽宽度改为 12mm倾斜面角度 30 度厚度 5mm。我发现这种迭代方式比一次性输入完整描述更有效原因在于模型生成代码时对每一步修改的上下文理解更准确不容易把之前正确的内容推翻重来。遇到适中略微较大这类相对词建议直接把相对关系换算成具体值。比如厚度适中可以说成厚度 5mm稍微厚一点可以说成厚度在 5mm 基础上增加 2mm。我在测试中发现模型对相对词的处理能力比预想要弱经常出现适中 随机值的情况。这不是模型不行而是训练数据里缺乏大量带相对语义的 CAD 代码样本模型很难从自然语言里映射出相对尺寸。还有一个实用技巧在描述末尾加一句完成建模后不要解释代码直接输出完整代码。原因在于很多模型在推理时会把解释代码和生成代码混在一起在代码块之外输出大量文字而这些文字有时会被后处理脚本误认为是建模指令。强制约束输出格式是提高稳定性的性价比最高的手段。3. 实操过程与核心环节实现3.1 环境准备与工具选型text-to-cad 的开源生态里最直接可用的组合方案是CadQuery 微调的代码生成模型 本地脚本工具链。我使用的是基于开源代码生成模型微调过的版本推理框架用的 Ollama模型是 Qwen2.5-Coder 系列微调出来的。环境搭建并不复杂。CadQuery 的安装很简单一个 pip 命令搞定。需要注意的是 CadQuery 本身依赖 OCCT 内核Windows 下建议直接使用官方预编译 wheelLinux 下用 conda 安装最省事。安装完成后建议马上跑一个最小验证用 CadQuery 写一个简单的 box导出 STEP 文件再导入 FreeCAD 看一眼确认内核没问题。模型推理这块本地 Ollama 的好处是代码生成延迟低、上下文窗口可以拉得比较大。如果对效果更敏感可以调用云端 API但要注意代码生成的响应时间和网络稳定性会影响连续迭代的体验。我的建议是本地部署开源代码模型把 CadQuery 的官方示例和相关文档提前塞进提示词里作为参考上下文。3.2 从一句描述到一个完整零件的完整流程下面用一个实际案例演示完整流程。输入描述生成一个带安装座的 L 形支架垂直面高度 60mm水平面长度 80mm宽度 50mm厚度 5mm。垂直面顶部中间有一个直径 10mm 的通孔水平面四个角各有一个直径 5mm 的通孔。第一步把描述改写成更贴合代码生成模型的提示词。我会加几个关键约束指定使用 CadQuery声明所有尺寸单位是毫米明确操作顺序要求输出完整代码。改写后的提示词是这样的你是 CadQuery 建模专家。请使用 CadQuery 生成一个 L 形支架模型。 要求 1. 所有尺寸单位均为毫米。 2. 模型由两部分组成垂直面和水平面两个面共用一个实体。 3. 垂直面高度 60mm水平面长度 80mm宽度统一为 50mm厚度统一为 5mm。 4. 垂直面顶部中心位置挖一个直径 10mm 的通孔。 5. 水平面四个角落各挖一个直径 5mm 的通孔。 6. 请输出完整可运行的 CadQuery 代码不要输出解释。第二步把提示词发送给模型。模型返回了一段 CadQuery 脚本核心逻辑如下import cadquery as cq # 定义尺寸参数 height_vertical 60 length_horizontal 80 width 50 thickness 5 hole_dia_center 10 hole_dia_corner 5 # 创建垂直面看成一个平板先放置在工作平面上 vertical_plate ( cq.Workplane(XZ) .box(height_vertical, thickness, width) ) # 创建水平面 horizontal_plate ( cq.Workplane(XY) .box(length_horizontal, thickness, width) ) # 合并两个面并定位到正确位置 result ( cq.Workplane(XY) .union(vertical_plate.translate((0, 0, -width/2))) .union(horizontal_plate.translate((length_horizontal/2 - 0, -thickness/2, -width/2))) ) # 在垂直面顶部中心打孔 result ( result.faces(Z) .workplane() .center(0, 0) .hole(hole_dia_center) ) # 在水平面四个角打孔这里采取遍历方式 for x_offset in [-length_horizontal/2 10, length_horizontal/2 - 10]: for z_offset in [-width/2 10, width/2 - 10]: result ( result.faces(Z) .workplane() .center(x_offset, z_offset) .hole(hole_dia_corner) ) show_object(result)第三步运行代码并检查。这一步可以发现几个问题垂直面的定位可能不对、水平面孔的位置坐标需要验证。运行之后把 STEP 文件导出拖进 CAD 软件里肉眼检查。这段代码里有一个非常典型的容易出错的地方模型的定位基准。CadQuery 的 box 默认以工作平面原点为中心生成所以 create 出来的垂直面和水平面的坐标关系需要你手动去计算模型算起来也经常出错。我的做法是在提示词里就强制声明所有板件都以原点为一个端点朝正方向生成让模型用 Workplane.center 和 position 去修正而不是依赖 box 的默认中心。3.3 用迭代验证代替一次性生成text-to-cad 的实践中提示词一次到位是极少发生的。更真实的流程是先生成基础形状再逐步添加细节。我常用的流程是分三步走。第一步生成基础体块比如一个长 120mm、宽 40mm、高 30mm 的矩形体第二步添加特征比如顶面右侧生成一个凹槽深度 10mm宽度 20mm第三步做孔阵列和圆角处理。这样分步迭代的优势在于每轮生成的代码都很短模型在局部修改的上下文里保持正确性的概率远高于一次性长代码生成。实测数据对比一次性生成包含六个特征的完整描述成功率在 30% 左右分三步迭代成功率达到 75% 以上。代价是交互轮次变多但考虑到模型推理通常只需要几秒钟这个代价完全值得。迭代过程中还有一个容易被忽略的点让模型在每一轮输出时只修改上一轮的代码而不是从零开始重新生成完整代码。很多模型在第二轮迭代时会重新整理代码结构结果把上一轮正确的部分也改坏了。我会在提示词里加一句基于上一轮的代码做最小修改只新增或调整需要变化的部分。3.4 从代码到实体模型的验证闭环代码能不能跑是一回事跑出来的模型符不符合预期是另一回事。我一般用三层验证来把关。第一层是语法验证。CadQuery 脚本如果语法错误会直接抛出异常这一步最容易被发现。第二层是几何验证。用 CadQuery 的 val().Volume() 计算体积、用 BoundingBox 获取尺寸范围和描述里的目标值对比。比如描述里说支架宽度是 50mm生成模型的 BoundingBox 宽度如果是 60mm那一定是坐标定位出了问题。第三层是视觉检查。把 STEP 文件导入 FreeCAD在真实渲染环境里旋转、剖切、测量。很多特征之间的相对位置关系问题只有肉眼看模型才能发现。我自己踩过的坑是模型在处理面选择时经常选错。在垂直面顶部中心打一个通孔模型可能选到垂直面的底部或者选到水平面。因为 CadQuery 的 faces() 选择规则依赖于几何法向模型的代码生成逻辑对法向的推理不总是准确的。规避办法是提示词里直接给出面选择的过滤条件比如选择法向指向 Z 正方向的面。4. 常见问题与排查技巧实录4.1 尺寸不对被忽略的单位与基准陷阱尺寸问题是我遇到最多的故障类型。典型表现为长度方向正确但厚度方向差一倍、圆孔直径和描述不符合、整个模型位置偏移导致部分特征落在预设区域之外。排查路径分三步。第一步检查提示词中是否声明了单位。如果没有声明模型默认按毫米处理但如果你描述中混用了英寸英尺这类词结果很可能按英制处理。第二步检查模型代码里的尺寸变量定义。很多模型会把 20mm 的直径直接写成 radius20而 CadQuery 的 hole() 接收的是直径参数这时模型输出的孔就是预期尺寸的两倍。这里要特别注意 CadQuery 的 API 语义hole(10) 是直径 10mm 的孔不是半径 10mm。第三步检查 Workplane 的坐标系与偏移计算。我之前测试过一个把手模型描述是整体长 100mm宽 40mm高 20mm两侧各有一个半径 8mm 的圆角。模型生成的代码里宽度栏写的是 40但实际模型宽度变成了 60。排查后发现模型把两侧圆角的半径 8 加到了宽度上等于宽度被拉伸了 16mm。解决方法是把圆角和主体尺寸分开描述先生成带 100x40x20 的矩形体最后在四个竖直边添加半径 8mm 的圆角。4.2 特征丢失模型为什么少打了一个孔特征丢失的典型表现是描述中有均匀分布 6 个孔模型只生成了 4 个描述中有底部有加强筋模型完全没生成。这背后有两个原因一个是模型对数量词的理解不稳定另一个是生成代码时遍历循环写错了。排查特征是丢失时我会先确认提示词里没有使用模糊数量词。6 个孔和多个孔是完全不同的前者模型知道是固定数量后者模型会随机生成 3 到 8 个。其次检查循环里的 range 参数。CadQuery 的 polar 阵列通常写成 polar(6, radius) 就代表 6 个但如果模型用了 workplane.rect 或 array2D 的方式数量控制逻辑就容易出错。我曾经遇到一个很隐蔽的问题描述圆周上均匀分布 6 个孔模型生成的代码是 polar(6, 25)看起来没问题但运行后只出现了 3 个孔。原因是模型在 polar() 后接了 .hole()但 hole 在圆周阵列里的执行只保留了一个实体特征。改成先创建一个圆孔实体再和基体做差集阵列效果就正常了。这类问题需要一定的 CadQuery 经验才能定位新手建议在生成后放大视图仔细数一遍特征。4.3 布尔运算失败实体相交的边界情况CadQuery 里用 cut() 做布尔运算时如果两个实体只是刚好接触而不是相交重叠运算可能失败。典型场景描述在圆盘中心打一个直径 50mm 的孔圆盘直径正好 50mm这时孔和圆盘边界完全重合布尔运算结果不稳定。模型生成的结果有时候是一个实心圆盘有时候是半个环完全看内核心情。解决办法是在提示词里给孔一个安全余量。比如圆盘直径 60mm中心打一个直径 50mm 的通孔保证孔完全落在圆盘内部留出 5mm 的实体边界。这条约束需要在描述中显式出现否则模型很可能按字面参数执行把两个贴合实体放到位。另一种布尔运算失败和孔深度有关。描述底板上打一个盲孔深度 5mm底板厚度正好 5mm孔底部和底板底面共面CadQuery 的布尔运算也会有风险。建议描述里写深度 4.8mm或者底板厚度 6mm让孔和底面之间留出微小间隙。这类问题的本质是程序化建模对精确的数学关系敏感描述时预留工程余量是工程设计的常识text-to-cad 同样适用。4.4 拓扑命名稳定性问题修改代码时的幽灵面CadQuery 有一个经典痛点叫拓扑命名topological naming问题。简单来说CAD 内核在修改实体后面的编号和选择器可能变化。你在 face A 上打孔修改了其他特征后face A 可能变成了 face B导致整个后续操作链崩溃。text-to-cad 的代码生成模型天然容易触发这个问题因为模型生成的代码往往包含大量基于 faces() 和 edges() 的选择操作而这些操作在最初生成时没问题一旦在提示词里追加修改圆角半径这类需要重新构建拓扑的操作后续代码可能全部失效。我总结了一个在 text-to-cad 场景下的规避思路提示词要求模型在每个特征操作前重新选择面不要复用之前的面对象。这样生成的代码虽然啰嗦一些但每次操作都基于最新的几何状态大大降低了拓扑命名问题的影响。另一个思路是尽量使用基于原始草图的参数修改也就是把关键尺寸统一提为变量修改时只改变量值让模型重新执行整个脚本。实测下来变量驱动的方式比增量式修改更稳定。4.5 常见问题速查表问题现象可能原因解决方案所有尺寸等比例缩小单位为厘米但按毫米处理提示词声明所有尺寸单位均为毫米孔的直径是预期两倍把直径当成半径检查 hole() 参数CadQuery 的 hole 使用直径生成的模型位置偏移坐标基准不一致提示词要求所有板件以原点为端点阵列只出现部分特征布尔运算方式错误创建孔实体后和基体做差集特征选择错误faces() 选择器法向判断错误提示词指定法向方向如Z修改参数后整体崩溃拓扑命名不稳定使用变量驱动修改变量值而非修改操作步骤部分特征直接消失模糊数量词导致使用精确数字替代几个多个布尔运算无结果孔与基体边界共面留出安全余量孔比基体轮廓小 5mm圆角半径不对圆角被计算进长宽分步描述圆角独立于主体尺寸代码可运行但模型预期不符输出之前未做几何验证计算体积和包围盒对照目标值5. 模型选型与效果对比5.1 开源代码模型在 CAD 场景的实际表现text-to-cad 对代码生成模型的要求远高于通用编程任务。通用编程任务的错误多半是语法错误而 CAD 场景里语法正确的代码几何逻辑也可能完全错误。所以我总结经验时会把模型能力拆成三项来看CAD API 的掌握程度记忆、自然语言到参数映射的准确性理解、多步几何操作的规划能力推理。我实测下来Qwen2.5-Coder 系列和 CodeLlama 系列在记忆方面差距不大都对 CadQuery 的常见 API 有不错的覆盖。差异主要体现在推理层面Qwen 系列在处理自然语言描述中有多个条件和约束时能够更稳定地分解成多个建模步骤不会遗漏特征而 CodeLlama 在简单任务上也够用但约束一多就容易出现只生成一半特征的情况。DeepSeek-Coder 系列我也测过它的代码风格更简洁但有时简洁得过头把圆角、倒角这类修饰特征直接省略了。这个结论和模型规模强相关。14B 以下的小模型在简单零件一个主体、一两个孔上表现尚可但面对复杂描述基本不可用。7B 模型甚至在特征遗漏问题上有 30% 以上的概率。如果条件允许优先选 14B 或 32B 级别的模型。5.2 结构化输出 vs 非结构化输出我做了两组对比测试。第一组是让模型直接输出 CadQuery 代码第二组是先输出一个 JSON 结构包含实体类型、尺寸参数、特征列表再用转换器把 JSON 转成 CadQuery 脚本。直接输出代码的优点是灵活模型可以自由发挥遇到一些小众特征也能通过组合基础 API 实现。缺点是稳定性差经常出现低级的 API 误用比如把 Workplane.box 的参数顺序搞错、把 .edges() 和 .faces() 混用。结构化输出的优点是约束性强尺寸参数都集中在 JSON 里不容易出现单位错误缺点是模型需要额外推理我应该生成一段 JSON 描述这个模型如果推理结果里的 JSON 结构本身不完整后面的转换器也救不回来。从我的实际项目来看简单零件一两个特征用直接输出代码就够快复杂零件三个以上特征叠加用结构化输出更稳虽然多一步 JSON 到脚本的转换但整体成功率明显更高。有一个折中方案提示词要求模型先列出所有尺寸变量和特征操作的注释块再输出代码。相当于用注释块做一次隐式的结构化规划有效提升代码的稳定性同时不牺牲代码的自由度。5.3 微调数据从哪里来开源社区目前最常用的训练数据是自动化生成的合成数据用 CadQuery 编写一批参数化模板通过改变参数批量渲染出不同形状的零件同时用模板里的注释和变量名作为自然语言标注。这类数据的优点是量大、质量可控缺点是自然语言表达过于格式化和真实用户的自然描述差异较大。真实用户描述往往是一个能放在桌面上的小支架最好带防滑垫位而合成数据里的描述是L 形支架垂直面高 60mm水平面长 80mm宽 50mm厚 5mm。模型在真实场景的泛化能力会受到这个差异的直接影响。我在实际测试中用我手写的自然语言描述去测试模型成功率比用官方示例描述测试低了 20% 到 30%。如果你打算微调自己的模型建议在合成数据基础上补充一批非结构化的口语描述作为增强数据让模型学习从口语表达过渡到结构化参数的过程。6. 在真实工作流中接入 text-to-cad6.1 与主流 CAD 软件的联动方式text-to-cad 不是一个独立完成所有事的工具。它生成的是 STEP 文件或代码文件真正的使用场景需要和主流 CAD 软件联动。目前最顺畅的联动路径是CadQuery 导出 STEPSTEP 导入 FreeCAD 做工程图再通过 FreeCAD 导出各种格式给下游。也可以在 CadQuery 里直接导出 STL 给 3D 打印切片软件用。我自己验证过CadQuery 生成的 STEP 文件在 FreeCAD 和 Fusion 360 里都能正常导入模型精度没有问题边界表示完整没有网格化导致的破面。如果希望更进一步可以把 text-to-cad 生成的代码当作设计草稿导入 CAD 软件后使用原生工具继续编辑。但这一步有一个现实约束CAD 软件原生编辑器和生成代码之间不是双向联动的。你在软件里改了一个圆角生成代码不会同步更新你在代码里改了一个参数软件里的历史树也不会自动刷新。这个问题的本质是程序化建模和历史特征树的差异短期内没有完美的解决方案。我的经验是把 text-to-cad 定位在方案探索和初稿生成阶段不要在它上面做精细化终稿修改。6.2 text-to-cad 适合哪些场景不适合哪些场景从适用性上划分text-to-cad 在以下场景中表现很好设计探索快速生成多个结构变体用于评审和对比标准件生成法兰、支架、壳体类尺寸参数清晰、结构模式固定教学演示用自然语言生成模型展示建模思路非标件初稿根据口头需求快速建立 3D 草稿同时也有明显的短板复杂曲面建模如汽车覆盖件模型尤其不擅长多实体装配体的相对位置关系模型经常搞错对设计规范的严谨执行如公差标注、加工符号目前完全做不到需要大量内部逻辑判断的设计比如根据受力分析结果调整壁厚也不适合text-to-cad 更像是草图阶段的语言化表达工具而不是设计的最终交付工具。认识到这个边界使用体验会好很多。6.3 与参数化设计模板的结合思路在我看来text-to-cad 目前最有价值的应用不是从零生成而是与参数化模板库结合。做法很简单把常用的参数化模板法兰、支架、箱体、卡扣预先写好 CadQuery 脚本模板里的尺寸参数全部定义为变量然后让大模型做的事情不是生成代码而是从自然语言里抽取参数值填入模板变量最后执行模板生成模型。这个思路的巧妙之处在于它避开了代码生成模型最薄弱的部分——几何结构规划直接用人类工程师设计的模板保证结构正确性同时又利用了模型擅长的部分——自然语言理解和参数抽取。比如描述做一个直径 100mm 的法兰四个安装孔孔径 10mm模型只需要抽取出 diameter100、hole_count4、hole_diameter10然后调用预先写好的 flange 模板。这样的成功率可以接近 100%比从零生成高一个数量级。我目前的工作流里主体结构已经切换到了这种模式做新项目时先用 text-to-cad 自由试探形态一旦形态确定就把描述改写成标准参数直接套用对应的参数化模板生成正式模型。这样既保留了 text-to-cad 的灵活性又保证了最终模型的工程可靠性。7. 实测总结与经验沉淀text-to-cad 说白了核心价值在于把三维建模从空间操作变成了语言描述。这话听起来简单但工程落地的差距很大提示词里多写一句所有尺寸单位均为毫米成功率能差 30%把打一个孔改成以圆盘中心为圆心打一个直径 10mm 的通孔模型的输出稳定性能差一倍。我自己的习惯是建一个常用的提示词模板库。对于一个新需求先套模板确认基础结构跑通了再逐步添加细节约束。这个流程做顺了之后大部分简单零件的建模时间可以控制在 10 分钟以内包含文本编写、代码运行、STEP 导入验证的完整闭环。对比传统 CAD 建模流程效率提升非常明显。另外一个想特意提的点text-to-cad 生成的结果不要直接当作终稿用。任何自动生成的代码都值得花两分钟看一眼关键参数和操作顺序。这不是对工具不信任而是代码层面的走查能拦截绝大多数几何错误省去后面在 CAD 软件里返工的时间。我几乎每次都能在代码走查阶段发现一两个值得注意的问题这个习惯帮我避免了很多次模型生成一时爽、改图修图改到慌的场面。最后分享一个后续还能继续扩展的方向把 text-to-cad 和拓扑优化、有限元分析结合起来。先用语言描述生成设计空间然后用分析工具对模型做仿真再把仿真结果反哺参数调整形成一个完整的语言描述-生成模型-仿真验证-参数修正闭环。这个方向目前社区里已经有人在尝试我自己的项目也在往这个方向推进等跑出更多可复现的结论再单独写一篇分享。
阅读完成 · 觉得有帮助？
