我刚接触 text-to-cad 这个方向的时候心里其实有点犯嘀咕不就是用文字生成三维模型吗和之前火过一阵的“文本生成图像”能有多大差别真上手跑过几个开源项目、试过商用 API 之后才发现这里面藏着的门道比想象中深得多。这篇文章就把我这一路摸爬滚打的实操经验、踩过的坑、总结出来的选型思路一次性整理出来分享给大家。1. 内容整体设计与思路拆解1.1 核心需求解析text-to-cad字面意思就是“从文本生成 CAD 模型”但它和常见的“AI 生成图片”完全是两码事。图片生成追求的是视觉相似度像素对了就行CAD 生成追求的是工程可用性生成出来的东西必须能进装配体、能出工程图、能拿去加工或 3D 打印几何精度和拓扑关系错一点都不行。先拆一下这个需求背后的核心痛点。传统 CAD 建模的门槛高在哪不是软件操作本身而是建模思路。你让一个机械专业的学生画一个法兰盘他得先想清楚用旋转特征还是拉伸特征先画草图还是先建基准面这些决策过程需要大量空间想象力和经验积累。text-to-cad 想解决的就是把这个“决策过程”从人脑搬到模型里让用户直接用自然语言描述需求系统自动拆解成建模步骤再执行出来。这里有个关键点text-to-cad 不是要替代 SolidWorks 或者 Fusion 360它更像是给你配了一个“会画图的助手”。你告诉它“我要一个 M8 的内六角螺栓头部直径 13 毫米总长 40 毫米”它帮你把特征树搭好把参数填好你拿到手的是完全可编辑的原生参数化模型而不是一堆三角面片拼成的“样子货”。1.2 从语言到几何的技术断层为什么 text-to-cad 比 text-to-image 难那么多因为自然语言和 CAD 几何模型之间存在一个巨大的“语义断层”。语言是模糊的、有歧义的。“一个好看的底座”这句话在图像生成里可以被“审美”消化掉在 CAD 里就完全没法执行——什么叫“好看”圆角多大算好看壁厚多少拔模角度要不要这些信息语言里根本没有需要系统去猜、去补全而补全得对不对直接决定了模型能不能用。更麻烦的是CAD 模型本身不是一张图它是一棵“特征树”。一个零件从毛坯到成品的每一步加工逻辑都记录在这棵树里先拉伸一个长方体再切掉一个槽再倒一个圆角……树的结构稍有不同最终几何体可能一样但可编辑性天差地别。这就要求 text-to-cad 系统不仅要理解语言还要理解“建模顺序”得能规划出合理的特征树结构这比单纯的几何生成高了整整一个维度。2. text-to-cad 的主流实现路线与工具选型2.1 三类主流路线对比我把现在市面上能跑通 text-to-cad 的方案归成三大类各有各的适用场景没有绝对的好坏选错了方向才是真踩坑。第一类是端到端生成模型。代表是 OpenAI 的 Point-E 衍生产品、Autodesk 的 CLIP-Forge 这类研究项目以及一些创业公司推出的“文本直出模型”服务。思路是用大模型直接学习“文本-点云/体素/网格”的映射用户输入一句话模型直接吐一个三维几何体出来。优点是快缺点是生成结果几乎都是网格mesh格式不是参数化实体修改起来极其痛苦而且几何精度很难保证拿去加工基本不现实。第二类是程序化生成引擎 LLM 编排。代表是最近社区里很火的 CadQuery 结合 GPT-4 的方案以及部分开源项目里用自然语言转 OpenSCAD 代码的做法。思路是让大模型充当“程序员的角色”把自然语言翻译成一串参数化建模代码再由 CadQuery/OpenSCAD 引擎真正执行建模。这类的优点是生成的模型是完完全全的参数化实体每一个尺寸都可以改缺点是模型的表达能力受限于你选的代码库太复杂的自由曲面玩不转。第三类是检索与组装式生成。代表是部分工业软件内置的“标准件智能搜索”功能以及一些做“衍生式设计”的工具。思路是先建一个庞大的标准零件库用户输入描述后系统用语义检索找到最接近的零件模板再做参数适配。优点是非常稳适合标准件、常用结构件场景缺点是只能做“库里有”的东西创新能力约等于零。2.2 现阶段我为什么推荐“LLM CadQuery”路线个人实测下来如果你现在是以“学习、做样品、验证方案”为目标LLM 编排 CadQuery 代码这条路是性价比最高的理由有三点。一是可编辑性。CadQuery 输出的是真正的 BREP 实体模型配合 FreeCAD 或者直接导出 STEP 文件下游的 CAM 编程、有限元分析、3D 打印切片全都能接上。这一点是端到端生成路线做不到的。二是可控性。大模型生成的代码如果出错你看到的是一段可以 inspect 的 Python 脚本哪里错了改哪里而不是一个不可解释的坏几何体。这在实际工程里太重要了——你总不能拿一个“我也不知道怎么生成的”模型去做承力件吧。三是门槛友好。CadQuery 本身是开源免费的API 设计得很像自然语言比如box()就是建立一个长方体fillet()就是倒圆角大模型对这种命名友好的库学习得非常快出错的概率远低于让它直接写 OpenSCAD 或者 FreeCAD 的宏脚本。当然不是说其他两种路线没用。如果你要快速做概念展示不关心后续工程化端到端生成模型几分钟出个外形轮廓效率确实高如果你所在的公司有标准件库积累检索式方案的上线速度最快。我的建议是手头至少掌握一种路线遇到需求时再按场景灵活切。3. 实操全流程从一句话到一个能用的 STEP 零件3.1 环境准备与依赖安装先把基础环境搭起来我用的是 Python 3.10 CadQuery 2.x配合 FreeCAD 做可视化和格式转换。# 创建虚拟环境避免污染系统 Python python -m venv cad_env source cad_env/bin/activate # Windows 用 cad_env\Scripts\activate # 安装 CadQuery pip install cadquery # 安装 FreeCAD 的 Python 绑定用于 STEP 转换和可视化 pip install freecad # 大模型接口这里以 OpenAI 兼容接口为例 pip install openai这里有两个坑提前说。第一个CadQuery 的版本一定要选 2.x1.x 的 API 很不一样网上很多教程用的还是老版本照着抄容易心态崩。第二个FreeCAD 的 pip 包和桌面版可能冲突如果你电脑上已经装了 FreeCAD 桌面版建议在虚拟环境里单独装一份 Python 绑定不要混用。3.2 提示词工程让大模型“说人话”我在跑 text-to-cad 的头几天最大的感悟就是问题往往不出在建模引擎而出在你给大模型的提示词太烂。直接给一句“画一个法兰”会让大模型无从下手这不是它笨是你信息给得不够。经过反复试验我总结出一套“结构化提示词模板”实测稳定性和生成成功率都提升了一大截你是资深机械设计工程师使用 CadQuery 库帮我生成一个参数化模型。 需求如下 - 零件名称支撑法兰 - 关键尺寸外径 80mm内径 35mm厚度 12mm法兰螺栓孔 4 个直径 6.5mm孔中心圆直径 60mm - 附加特征外圈倒角 1mm - 旋转轴默认 Z 轴 - 代码要求使用变量定义尺寸方便后期修改 请直接输出完整的 Python 代码不要加解释。这个模板里每一句话都不是废话。“你是资深机械设计工程师”是角色设定能大幅提升代码的专业性“用变量定义尺寸”是为了拿到可参数化的代码“不要加解释”是为了省 token 的同时避免模型夹杂一堆 markdown 干扰解析。3.3 完整案例拆解用 CadQuery 生成法兰盘直接看代码。以下是我实际运行通过的一个例子用来生成一个带螺栓孔的法兰盘。import cadquery as cq # 参数定义 outer_d 80.0 inner_d 35.0 thickness 12.0 bolt_hole_d 6.5 bolt_circle_d 60.0 chamfer_size 1.0 # 主体外圆柱减去内圆柱形成环形法兰基体 result ( cq.Workplane(XY) .circle(outer_d / 2) .extrude(thickness) .faces(Z) .workplane() .hole(inner_d) ) # 打螺栓孔沿圆周均匀分布 4 个孔 for angle in [0, 90, 180, 270]: result ( result.faces(Z) .workplane() .polarArray(bolt_circle_d / 2, 0, 360, 4) .hole(bolt_hole_d) ) # 外圈倒角 result result.edges(|Z).chamfer(chamfer_size) # 导出 STEP 文件供 CAM/CAE 使用 cq.exporters.export(result, flange.step)这段代码看下来其实核心逻辑就三步画圆拔高生成圆柱体挖掉内孔变成法兰环再沿圆周阵列打螺栓孔。CadQuery 的 API 写起来像在说英语这也是我说它对大模型友好的原因——代码本身就是一种“结构化语言”。实际操作中我踩过一个坑polarArray的用法。CadQuery 里它接收的参数依次是半径、起始角度、总角度、数量。我最开始传参少了半径导致螺栓孔全部挤在圆心调试了好久才发现是数组用法不对。后来我学乖了凡是遇到阵列类的特征先手动算一遍坐标再用代码验证。3.4 从文本到代码的自动化管道上面的代码是手工写的text-to-cad 的核心则在于“让大模型替你写”。我的自动化处理流程大概是这样的import openai import cadquery as cq import re # 1. 构造提示词 user_input 生成一个外径80、内径35、厚度12的法兰盘带4个直径6.5的螺栓孔分布在直径60的圆上 prompt build_prompt(user_input) # 用上一节的模板 # 2. 调用大模型接口 resp openai.ChatCompletion.create( modelgpt-4o, messages[{role: system, content: prompt}], temperature0.2, ) # 3. 提取 Python 代码 code_text resp[choices][0][message][content] code_text re.sub(rpython|, , code_text).strip() # 4. 执行代码并导出模型 exec(code_text)注意到temperature0.2这个参数没有这是非常关键的一手。生成代码不像生成文案你要的是确定性最高的输出而不是“有创意的代码”。如果 temperature 太高模型会在 API 调用上“自由发挥”今天用circle()明天用rect()导致同一条文本每次生成的模型结构都不一样。我把它压在 0.2 以下基本能做到同输入同输出。4. 常见问题与排查技巧实录4.1 CadQuery 生成时报错“No shape to export”这是我遇到最高频的错误十次里有三次撞上它。原因是生成的代码里根本没有产生有效的三维实体最常见的场景是extrude()里给的厚度是 0 或者负数或者circle()的半径传了 0。CadQuery 在这种状态下会认为“没有实体可导出”直接抛错。排查方法也很简单把导出的代码拆成几步每步后面都查一下.val()是否返回正常实体。我当时写了个小工具函数每执行完一个特征就打印当前实体数量定位到具体是哪一步把模型搞“没了”。4.2 大模型“撒欢”生成的零件和描述完全对不上这种情况多见于提示词写得不够结构化。比如你说“一个复杂的机械零件”模型直接给你来个像外星飞船的东西尺寸标注乱到没眼看。解决办法就是我在 3.2 里写的那套模板把所有关键尺寸数字化、明确化。如果条件允许可以在提示词里给模型几个“参考范例”让它模仿。比如附上一句“参考如下 CadQuery 代码的结构风格”然后把一个已知正确的零件代码贴进去。这招对模型理解“什么才是符合规范的 CAD 代码”非常有效比单纯说教强得多。4.3 中文描述 vs 英文代码的兼容问题大模型对英文的 CadQuery API 理解得最好但对中文描述处理起来偶尔会出幺蛾子。比如“倒一个 45 度角”中文描述里没有明确“倒角大小”模型可能给个chamfer(45)而 CadQuery 里这个参数的意思是“45 度对应的直角边长度”不是角度本身。我的应对策略是在提示词里要求模型“所有尺寸必须带单位mm”并且针对每个特征参数给出参考范围。宁可在提示词里多说几句也别让模型自由发挥。实测下来加一句“所有长度单位均为毫米布尔运算前确保 solid 存在”就能减少一半以上低级错误。4.4 生成速度慢到怀疑人生如果你的模型生成一个简单法兰盘都要十几秒先别怪大模型算力贵大概率是你的代码结构有问题。CadQuery 有一个著名的性能陷阱过度使用布尔运算。能用拉伸加挖孔的组合去做的模型千万别叠十几个union/cutCOG计算几何内核处理复杂布尔运算的速度非常感人。优化办法是尽量用 CadQuery 内置的“构造式建模”方法。比如要做一个带法兰边的轴套先在草图里把轮廓画成完整的截面再一次性旋转成型而不是轴套部分转一圈、法兰部分再叠一圈、最后做布尔合并。代码改写完速度往往能提升 5 到 10 倍。4.5 导出 STEP 后导入其他软件出现破面这个问题主要出现在端到端生成路线的网格模型上但其实 CadQuery 偶尔也会遇到。如果代码里做了非常复杂的曲面裁剪导出 STEP 后再导入 SolidWorks 或 Fusion 360可能会出现微小裂缝或面的法向反转。一个土办法导出成 STEP 后用 FreeCAD 的“几何检查”工具跑一遍有坏面的话先用Part.oX系列工具修复边界。如果确认是 CadQuery 的建模逻辑问题就返回去检查是否用了不合理的倒角顺序——顺序调整一下往往就好了。5. 对 text-to-cad 未来演进的一些个人观察text-to-cad 这个方向接下来很可能会沿着两条线往前跑。一条是往“更懂工程”的方向走也就是模型开始理解加工工艺、公差配合、材料属性能直接生成满足国标或者 ISO 标准的工程图、标注和 BOM 表。另一条是往“多模态融合”的方向走文本之外还支持手绘草图、参考图片、点云扫描数据作为输入自然语言只是其中一种交互方式。我个人的建议是现在这个阶段别等“完美方案”出来再动手。先把 CadQuery 学扎实再上手大模型 API 封装一个最小可用的 text-to-cad 工具哪怕只能生成法兰盘和支架这个过程本身就能帮你建立起“文本—特征—代码—实体”这套完整通路的直觉。等以后更强的模型出来了你迁移过去也只是一个接口替换的事核心方法论不会变。最后分享一个小经验text-to-cad 的输出质量七分靠提示词两分靠后处理管道一分才靠模型选型。很多人在这一步把精力花在“换更强的模型”上其实不如回头优化自己那段构造提示词的代码。把用户的模糊需求拆成“零件类型 关键尺寸 特征列表 约束条件”这一步做好了哪怕用的不是最顶级的模型出来的结果也够用。反过来提示词稀烂再好的模型也救不了你。 
长河君 · 2026/10/27 5:47:36 · 阅读 1.2k text-to-cad实战：从自然语言到可编辑STEP模型的关键技术
我刚接触 text-to-cad 这个方向的时候心里其实有点犯嘀咕不就是用文字生成三维模型吗和之前火过一阵的“文本生成图像”能有多大差别真上手跑过几个开源项目、试过商用 API 之后才发现这里面藏着的门道比想象中深得多。这篇文章就把我这一路摸爬滚打的实操经验、踩过的坑、总结出来的选型思路一次性整理出来分享给大家。1. 内容整体设计与思路拆解1.1 核心需求解析text-to-cad字面意思就是“从文本生成 CAD 模型”但它和常见的“AI 生成图片”完全是两码事。图片生成追求的是视觉相似度像素对了就行CAD 生成追求的是工程可用性生成出来的东西必须能进装配体、能出工程图、能拿去加工或 3D 打印几何精度和拓扑关系错一点都不行。先拆一下这个需求背后的核心痛点。传统 CAD 建模的门槛高在哪不是软件操作本身而是建模思路。你让一个机械专业的学生画一个法兰盘他得先想清楚用旋转特征还是拉伸特征先画草图还是先建基准面这些决策过程需要大量空间想象力和经验积累。text-to-cad 想解决的就是把这个“决策过程”从人脑搬到模型里让用户直接用自然语言描述需求系统自动拆解成建模步骤再执行出来。这里有个关键点text-to-cad 不是要替代 SolidWorks 或者 Fusion 360它更像是给你配了一个“会画图的助手”。你告诉它“我要一个 M8 的内六角螺栓头部直径 13 毫米总长 40 毫米”它帮你把特征树搭好把参数填好你拿到手的是完全可编辑的原生参数化模型而不是一堆三角面片拼成的“样子货”。1.2 从语言到几何的技术断层为什么 text-to-cad 比 text-to-image 难那么多因为自然语言和 CAD 几何模型之间存在一个巨大的“语义断层”。语言是模糊的、有歧义的。“一个好看的底座”这句话在图像生成里可以被“审美”消化掉在 CAD 里就完全没法执行——什么叫“好看”圆角多大算好看壁厚多少拔模角度要不要这些信息语言里根本没有需要系统去猜、去补全而补全得对不对直接决定了模型能不能用。更麻烦的是CAD 模型本身不是一张图它是一棵“特征树”。一个零件从毛坯到成品的每一步加工逻辑都记录在这棵树里先拉伸一个长方体再切掉一个槽再倒一个圆角……树的结构稍有不同最终几何体可能一样但可编辑性天差地别。这就要求 text-to-cad 系统不仅要理解语言还要理解“建模顺序”得能规划出合理的特征树结构这比单纯的几何生成高了整整一个维度。2. text-to-cad 的主流实现路线与工具选型2.1 三类主流路线对比我把现在市面上能跑通 text-to-cad 的方案归成三大类各有各的适用场景没有绝对的好坏选错了方向才是真踩坑。第一类是端到端生成模型。代表是 OpenAI 的 Point-E 衍生产品、Autodesk 的 CLIP-Forge 这类研究项目以及一些创业公司推出的“文本直出模型”服务。思路是用大模型直接学习“文本-点云/体素/网格”的映射用户输入一句话模型直接吐一个三维几何体出来。优点是快缺点是生成结果几乎都是网格mesh格式不是参数化实体修改起来极其痛苦而且几何精度很难保证拿去加工基本不现实。第二类是程序化生成引擎 LLM 编排。代表是最近社区里很火的 CadQuery 结合 GPT-4 的方案以及部分开源项目里用自然语言转 OpenSCAD 代码的做法。思路是让大模型充当“程序员的角色”把自然语言翻译成一串参数化建模代码再由 CadQuery/OpenSCAD 引擎真正执行建模。这类的优点是生成的模型是完完全全的参数化实体每一个尺寸都可以改缺点是模型的表达能力受限于你选的代码库太复杂的自由曲面玩不转。第三类是检索与组装式生成。代表是部分工业软件内置的“标准件智能搜索”功能以及一些做“衍生式设计”的工具。思路是先建一个庞大的标准零件库用户输入描述后系统用语义检索找到最接近的零件模板再做参数适配。优点是非常稳适合标准件、常用结构件场景缺点是只能做“库里有”的东西创新能力约等于零。2.2 现阶段我为什么推荐“LLM CadQuery”路线个人实测下来如果你现在是以“学习、做样品、验证方案”为目标LLM 编排 CadQuery 代码这条路是性价比最高的理由有三点。一是可编辑性。CadQuery 输出的是真正的 BREP 实体模型配合 FreeCAD 或者直接导出 STEP 文件下游的 CAM 编程、有限元分析、3D 打印切片全都能接上。这一点是端到端生成路线做不到的。二是可控性。大模型生成的代码如果出错你看到的是一段可以 inspect 的 Python 脚本哪里错了改哪里而不是一个不可解释的坏几何体。这在实际工程里太重要了——你总不能拿一个“我也不知道怎么生成的”模型去做承力件吧。三是门槛友好。CadQuery 本身是开源免费的API 设计得很像自然语言比如box()就是建立一个长方体fillet()就是倒圆角大模型对这种命名友好的库学习得非常快出错的概率远低于让它直接写 OpenSCAD 或者 FreeCAD 的宏脚本。当然不是说其他两种路线没用。如果你要快速做概念展示不关心后续工程化端到端生成模型几分钟出个外形轮廓效率确实高如果你所在的公司有标准件库积累检索式方案的上线速度最快。我的建议是手头至少掌握一种路线遇到需求时再按场景灵活切。3. 实操全流程从一句话到一个能用的 STEP 零件3.1 环境准备与依赖安装先把基础环境搭起来我用的是 Python 3.10 CadQuery 2.x配合 FreeCAD 做可视化和格式转换。# 创建虚拟环境避免污染系统 Python python -m venv cad_env source cad_env/bin/activate # Windows 用 cad_env\Scripts\activate # 安装 CadQuery pip install cadquery # 安装 FreeCAD 的 Python 绑定用于 STEP 转换和可视化 pip install freecad # 大模型接口这里以 OpenAI 兼容接口为例 pip install openai这里有两个坑提前说。第一个CadQuery 的版本一定要选 2.x1.x 的 API 很不一样网上很多教程用的还是老版本照着抄容易心态崩。第二个FreeCAD 的 pip 包和桌面版可能冲突如果你电脑上已经装了 FreeCAD 桌面版建议在虚拟环境里单独装一份 Python 绑定不要混用。3.2 提示词工程让大模型“说人话”我在跑 text-to-cad 的头几天最大的感悟就是问题往往不出在建模引擎而出在你给大模型的提示词太烂。直接给一句“画一个法兰”会让大模型无从下手这不是它笨是你信息给得不够。经过反复试验我总结出一套“结构化提示词模板”实测稳定性和生成成功率都提升了一大截你是资深机械设计工程师使用 CadQuery 库帮我生成一个参数化模型。 需求如下 - 零件名称支撑法兰 - 关键尺寸外径 80mm内径 35mm厚度 12mm法兰螺栓孔 4 个直径 6.5mm孔中心圆直径 60mm - 附加特征外圈倒角 1mm - 旋转轴默认 Z 轴 - 代码要求使用变量定义尺寸方便后期修改 请直接输出完整的 Python 代码不要加解释。这个模板里每一句话都不是废话。“你是资深机械设计工程师”是角色设定能大幅提升代码的专业性“用变量定义尺寸”是为了拿到可参数化的代码“不要加解释”是为了省 token 的同时避免模型夹杂一堆 markdown 干扰解析。3.3 完整案例拆解用 CadQuery 生成法兰盘直接看代码。以下是我实际运行通过的一个例子用来生成一个带螺栓孔的法兰盘。import cadquery as cq # 参数定义 outer_d 80.0 inner_d 35.0 thickness 12.0 bolt_hole_d 6.5 bolt_circle_d 60.0 chamfer_size 1.0 # 主体外圆柱减去内圆柱形成环形法兰基体 result ( cq.Workplane(XY) .circle(outer_d / 2) .extrude(thickness) .faces(Z) .workplane() .hole(inner_d) ) # 打螺栓孔沿圆周均匀分布 4 个孔 for angle in [0, 90, 180, 270]: result ( result.faces(Z) .workplane() .polarArray(bolt_circle_d / 2, 0, 360, 4) .hole(bolt_hole_d) ) # 外圈倒角 result result.edges(|Z).chamfer(chamfer_size) # 导出 STEP 文件供 CAM/CAE 使用 cq.exporters.export(result, flange.step)这段代码看下来其实核心逻辑就三步画圆拔高生成圆柱体挖掉内孔变成法兰环再沿圆周阵列打螺栓孔。CadQuery 的 API 写起来像在说英语这也是我说它对大模型友好的原因——代码本身就是一种“结构化语言”。实际操作中我踩过一个坑polarArray的用法。CadQuery 里它接收的参数依次是半径、起始角度、总角度、数量。我最开始传参少了半径导致螺栓孔全部挤在圆心调试了好久才发现是数组用法不对。后来我学乖了凡是遇到阵列类的特征先手动算一遍坐标再用代码验证。3.4 从文本到代码的自动化管道上面的代码是手工写的text-to-cad 的核心则在于“让大模型替你写”。我的自动化处理流程大概是这样的import openai import cadquery as cq import re # 1. 构造提示词 user_input 生成一个外径80、内径35、厚度12的法兰盘带4个直径6.5的螺栓孔分布在直径60的圆上 prompt build_prompt(user_input) # 用上一节的模板 # 2. 调用大模型接口 resp openai.ChatCompletion.create( modelgpt-4o, messages[{role: system, content: prompt}], temperature0.2, ) # 3. 提取 Python 代码 code_text resp[choices][0][message][content] code_text re.sub(rpython|, , code_text).strip() # 4. 执行代码并导出模型 exec(code_text)注意到temperature0.2这个参数没有这是非常关键的一手。生成代码不像生成文案你要的是确定性最高的输出而不是“有创意的代码”。如果 temperature 太高模型会在 API 调用上“自由发挥”今天用circle()明天用rect()导致同一条文本每次生成的模型结构都不一样。我把它压在 0.2 以下基本能做到同输入同输出。4. 常见问题与排查技巧实录4.1 CadQuery 生成时报错“No shape to export”这是我遇到最高频的错误十次里有三次撞上它。原因是生成的代码里根本没有产生有效的三维实体最常见的场景是extrude()里给的厚度是 0 或者负数或者circle()的半径传了 0。CadQuery 在这种状态下会认为“没有实体可导出”直接抛错。排查方法也很简单把导出的代码拆成几步每步后面都查一下.val()是否返回正常实体。我当时写了个小工具函数每执行完一个特征就打印当前实体数量定位到具体是哪一步把模型搞“没了”。4.2 大模型“撒欢”生成的零件和描述完全对不上这种情况多见于提示词写得不够结构化。比如你说“一个复杂的机械零件”模型直接给你来个像外星飞船的东西尺寸标注乱到没眼看。解决办法就是我在 3.2 里写的那套模板把所有关键尺寸数字化、明确化。如果条件允许可以在提示词里给模型几个“参考范例”让它模仿。比如附上一句“参考如下 CadQuery 代码的结构风格”然后把一个已知正确的零件代码贴进去。这招对模型理解“什么才是符合规范的 CAD 代码”非常有效比单纯说教强得多。4.3 中文描述 vs 英文代码的兼容问题大模型对英文的 CadQuery API 理解得最好但对中文描述处理起来偶尔会出幺蛾子。比如“倒一个 45 度角”中文描述里没有明确“倒角大小”模型可能给个chamfer(45)而 CadQuery 里这个参数的意思是“45 度对应的直角边长度”不是角度本身。我的应对策略是在提示词里要求模型“所有尺寸必须带单位mm”并且针对每个特征参数给出参考范围。宁可在提示词里多说几句也别让模型自由发挥。实测下来加一句“所有长度单位均为毫米布尔运算前确保 solid 存在”就能减少一半以上低级错误。4.4 生成速度慢到怀疑人生如果你的模型生成一个简单法兰盘都要十几秒先别怪大模型算力贵大概率是你的代码结构有问题。CadQuery 有一个著名的性能陷阱过度使用布尔运算。能用拉伸加挖孔的组合去做的模型千万别叠十几个union/cutCOG计算几何内核处理复杂布尔运算的速度非常感人。优化办法是尽量用 CadQuery 内置的“构造式建模”方法。比如要做一个带法兰边的轴套先在草图里把轮廓画成完整的截面再一次性旋转成型而不是轴套部分转一圈、法兰部分再叠一圈、最后做布尔合并。代码改写完速度往往能提升 5 到 10 倍。4.5 导出 STEP 后导入其他软件出现破面这个问题主要出现在端到端生成路线的网格模型上但其实 CadQuery 偶尔也会遇到。如果代码里做了非常复杂的曲面裁剪导出 STEP 后再导入 SolidWorks 或 Fusion 360可能会出现微小裂缝或面的法向反转。一个土办法导出成 STEP 后用 FreeCAD 的“几何检查”工具跑一遍有坏面的话先用Part.oX系列工具修复边界。如果确认是 CadQuery 的建模逻辑问题就返回去检查是否用了不合理的倒角顺序——顺序调整一下往往就好了。5. 对 text-to-cad 未来演进的一些个人观察text-to-cad 这个方向接下来很可能会沿着两条线往前跑。一条是往“更懂工程”的方向走也就是模型开始理解加工工艺、公差配合、材料属性能直接生成满足国标或者 ISO 标准的工程图、标注和 BOM 表。另一条是往“多模态融合”的方向走文本之外还支持手绘草图、参考图片、点云扫描数据作为输入自然语言只是其中一种交互方式。我个人的建议是现在这个阶段别等“完美方案”出来再动手。先把 CadQuery 学扎实再上手大模型 API 封装一个最小可用的 text-to-cad 工具哪怕只能生成法兰盘和支架这个过程本身就能帮你建立起“文本—特征—代码—实体”这套完整通路的直觉。等以后更强的模型出来了你迁移过去也只是一个接口替换的事核心方法论不会变。最后分享一个小经验text-to-cad 的输出质量七分靠提示词两分靠后处理管道一分才靠模型选型。很多人在这一步把精力花在“换更强的模型”上其实不如回头优化自己那段构造提示词的代码。把用户的模糊需求拆成“零件类型 关键尺寸 特征列表 约束条件”这一步做好了哪怕用的不是最顶级的模型出来的结果也够用。反过来提示词稀烂再好的模型也救不了你。