1. 项目概述text-to-cad 到底解决什么问题这几年 AI 生成内容的赛道从文案、图片一路卷到了视频但工业设计圈真正让我觉得有质变的反而是 text-to-cad 这种相对小众的方向。它的核心目标很简单你写一句话描述想要什么零件AI 直接给你生成一个能编辑、能出工程图、能进 CAM 流程的真正 CAD 模型而不是一张效果图。这话听起来像概念炒作但实际落地的产品已经不少了。Zoo原 KittyCAD 团队推出的 Text-to-CAD、Autodesk 的 Project Bernini、以及一批开源方案把 LLM 和 CadQuery/OpenSCAD 脚本结合起来基本把文字描述 → 参数化三维模型这条路跑通了。和普通人熟悉的 text-to-image 完全不同text-to-cad 生成的不是点云网格而是带参数约束、可二次编辑、能直接导成 STEP/STL 的实体模型——这意味着它可以直接接进你的设计流程而不是停在看个热闹的渲染图层面。我最初关注这个方向是遇到一个很实际的痛点内部工具里有一堆标准零件的变体需求每次都要在 SolidWorks 里手动拉伸、倒角、打孔重复劳动特别多。text-to-cad 解决的不是帮设计师画图而是把描述性需求快速变成可用的模型起点尤其适合概念方案比选、非标零件快速建模、以及给不懂三维软件的产品同事提供一条自助建模的路径。这篇文章不会只贴一堆官网链接而是把原理拆开讲清楚再给一套我自己用下来的工作流和踩坑记录不同基础的人都能照着上手。2. 技术原理拆解从文字到实体的三层结构2.1 为什么不是简单的 text-to-3D很多人第一次听说 text-to-cad第一反应是这不就是文生3D模型吗。这是个特别常见的误解也是理解整个技术的关键分岔口。传统的 text-to-3D比如 DreamFusion、Meshy、Tripo 这类生成的是三角网格模型本质上是一张包裹空间的面片集合。这种模型看起来像那么回事但内部没有实体拓扑没有参数历史没有特征树你拿到手之后没法改一个倒角半径、没法改一个孔的位置、更没法导出成 STEP 直接送去 CNC。text-to-cad 的产出物完全不同。真正的 CAD 模型是边界表示B-rep的实体由面、边、顶点以及它们之间的拓扑关系构成配合参数化特征历史才能在工程软件里被编辑和复用。所以业界普遍的做法不是让模型直接回归出几何坐标而是让 LLM 生成一段参数化建模脚本再交给 CAD 内核去执行。这段脚本可能是 CadQuery、OpenSCAD也可能是某个云平台私有的建模 DSL。这个思路本质上把设计意图和几何执行分离了大模型负责理解你的自然语言需求并翻译成建模指令底层内核负责把指令老老实实执行成带拓扑的实体。这个分离的架构带来一个很大的好处可解释性和可修正性。如果你对生成结果不满意可以直接去改脚本里的某个参数、某个布尔运算步骤而不是对着整个网格模型重新雕刻。调试 AI 输出的过程从反复重新生成碰运气变成了定位到脚本里某一行改掉它这是工程上能接受的迭代方式。2.2 LLM 如何理解空间语义让大模型理解一个直径 40mm 的圆盘中心有个直径 10mm 的通孔外沿倒角 2mm这类描述其实比理解日常对话要难得多。难点不在词汇量而在空间关系的消歧。比如在圆盘上方加一个凸台这句话上方到底是指沿 Y 轴正方向、沿 Z 轴正方向还是沿模型当前朝向的某个局部坐标方向凸台的高度、直径、形状收敛到哪一档公差范围这些都需要模型把自然语言映射到有明确数值语义的几何操作序列。当前的主流实现方式是借助代码生成能力。把 CAD 建模脚本当成一种特殊编程语言让大模型基于海量的脚本数据学习描述 → 代码的映射关系。Zoo 走的是自研内核加专用训练数据开源方案则普遍利用 LLM 的代码能力生成 CadQuery 脚本——CadQuery 本身就是一套 Python 库它的 API 设计得非常接近自然语言描述比如box(40, 20, 10)、hole(5)、fillet(2)。模型生成这些命令的准确率比直接回归三维坐标点要高得多因为中间多了一层语义符号化的缓冲。不过这里有个特别实际的差距大模型的空间想象力有但缺乏工程常识。它能理解几何操作但不太理解这个壁厚 0.5mm 注塑出来会缩水这几个特征之间的间距不够走刀这类制造语义。所以我在实际使用中从来不会把 text-to-cad 当成最终设计交付而是定位成从概念描述到基础几何的高速通道。这个定位决定了后面所有的工作流设计。2.3 参数化与非参数化的路线选择现在市面上的 text-to-cad 方案在底层还有个重要分叉参数化建模脚本路线和直接内核建模路线。搞懂这个分叉你选工具的时候就不容易被宣传词绕晕。参数化路线就是前面说的 LLM 生成 CadQuery/OpenSCAD 脚本。它的优势是模型完全可编辑——生成结果自带特征树你可以随时回去改参数重新生成。对我这种习惯了传统 CAD 工作流的人来说这一点极其重要因为没有任何一个 AI 第一次就能生成完全符合要求的东西后续调整是必然的。缺点是表达能力受限于脚本库的能力边界复杂曲面比如车身覆盖件、异形拓扑很难靠脚本堆出来。直接内核建模路线则是像 Zoo 这样在云端自建核心模型直接产出基于 B-rep 的几何数据但也会返回一个可读的建模脚本供你修改。这条路对复杂自由曲面的表现更好但工具生态目前还比较封闭导出到传统软件的格式兼容性和脚本的可读性需要时间验证。我的建议是如果你主要做机械结构件、外壳、支架这类棱角分明、特征规则的零件参数化脚本路线效率最高而且可以和版本控制系统结合把建模过程当代码管理。如果你需要流体曲面、有机形态的功能件可以关注内核路线的新进展但别指望它马上就取代 SolidWorks 的自由曲面模块。两者不是替代关系是不同需求下的分化。3. 工具选型实战当前可用的方案横向对比3.1 主流工具的能力边界我花了大半年时间把市面上的 text-to-cad 方案都过了一遍包括 Zoo 的 Text-to-CAD、Autodesk Project Bernini以及几个开源项目和基于通用 LLM 的 DIY 方案。横向对比下来各自的适用场景差异非常明显。工具/方案输出格式参数化可编辑复杂曲面适用场景学习成本Zoo Text-to-CADJSON/STEP/STL带脚本强中等概念快速方案、非标件低Autodesk Project Bernini仍在迭代中较强工业设计早期探索中LLM CadQuery开源 DIYSTEP/STLPython 脚本极强弱规则机械件、自动化批处理高LLM OpenSCAD开源 DIYSTL脚本强弱参数化外形、3D 打印件中Zoo 的云平台体验最完整直接网页上打字就能生成模型而且它会返给你对应的脚本让你改参数这对我这种习惯了本地设计流程的人很友好。但它的免费额度有限重度使用需要订阅。Project Bernini 目前给我的感觉更像技术预览适合跟进趋势不适合当生产工具。开源 DIY 方案的门槛主要在于你要自己搭环境、自己写 prompt 模板但胜在完全可控、数据不出本地、还能和 CI/CD 结合起来做批量建模。3.2 为什么我主力推荐 LLM CadQuery如果你问我在生产环境里最稳定的是什么方案我会毫不犹豫说 LLM 加 CadQuery。核心原因有三条每一条都是我在实际项目里被坑出来的结论。第一是可控性。开源方案的所有中间产物都是 Python 脚本我可以清楚地看到模型每一条特征是怎么生成的哪一步出了问题就直接改哪一行。云平台的自动生成虽然省事但如果它生成的脚本不够可读、或者修改接口做得不够灵活你就会被困在它的黑盒里。第二是版本管理。CAD 原生文件格式向来是版本控制的灾难——一个 SLDPRT 文件里塞了几百兆的二进制数据Git 都救不了你。但 CadQuery 脚本是纯文本天然能和 Git 集成。我现在的非标件库里每个零件就是一个 Python 文件加一个配置文件谁改了什么参数、哪次提交引入了问题全部有迹可循。这在团队协作里的价值怎么强调都不为过。第三是批处理能力。通过 API 调用大模型生成 CadQuery 脚本再加上参数扫描我可以在几分钟内生成几十个结构不同、尺寸连续的零件变体这在传统的 CAD 交互式建模里是不可想象的。比如我们之前做一批传感器安装支架需要适应六种不同尺寸的传感器、壁厚从 2mm 到 4mm 渐变用 text-to-cad 加脚本模板半小时全搞定换手工建模至少得两天。当然CadQuery 路线的短板也很明显复杂曲面基本做不了曲线曲面操作少得可怜。但这个短板可以通过混合工作流来弥补后面我会展开讲。3.3 自建方案的硬件和软件环境如果你的网络和 API 条件允许自建 text-to-cad 环境并不需要多豪华的硬件。我们团队现在的标准配置一台开发机就够了主要跑 CadQuery、Python 环境和 Docker 容器LLM 对接用云端 API按 token 计费日常开发测试一个月几十块钱本地跑推理就需要看模型大小了但说实话7B 量级的小模型生成 CadQuery 代码的准确率还是不太够我建议直接走 API。软件栈方面CadQuery 2.x 是当前稳定版本安装方式直接pip install cadquery。要注意的是 CadQuery 的版本迭代有破坏性变更不同版本的 API 有差异项目最好在 requirements.txt 里锁死版本。我经历过一次从 2.1 升到 2.4 之后老脚本的Workplane用法大面积报错的情况那滋味不好受。编辑器方面VS Code 加 CadQuery 插件就能实现本地预览修改脚本后可以一键在 Jupyter 里渲染出三维视图排查问题比传统 CAD 的撤销重做再撤销要高效得多。稍微麻烦的是要把 Jupyter 的三维渲染配置跑通但一次配置终身受益。4. 实操全流程从一句话到可制造模型4.1 需求描述的结构化方法text-to-cad 的 prompt 和文生图完全是两套逻辑。文生图你可以写一只戴帽子的柴犬赛博朋克风格抽象点无所谓图像模型会替你补全细节。但 CAD 模型不行——几何是精确的误差 0.1mm 就可能装不上。所以 prompt 必须结构化模棱两可的形容词越少越好。我总结了五要素描述法主体形状、关键尺寸、特征操作、位置关系、制造约束。以设计一个圆形法兰盘为例散文式描述是这样的一个圆形法兰盘外径 60mm内孔 30mm厚度 5mm外圈均布 4 个直径 6mm 的安装孔安装孔中心所在圆直径 50mm外缘倒角 1mm。对应的 CadQuery 脚本大致长这样import cadquery as cq result ( cq.Workplane(XY) .circle(60 / 2) .circle(30 / 2) .extrude(5) .faces(Z) .workplane() .circle(50 / 2) .hole(6) .edges(Z) .fillet(1) )把这段脚本喂给 LLM 做少样本示例模型就会学会你的描述习惯和输出格式。我的建议是建一个属于自己的 prompt 模板库里面存 10 到 20 个不同零件类型的示例对覆盖底板、支架、轴套、壳体、法兰、管路等常见类型。每次新任务先在模板库里找最接近的示例改改描述就行生成成功率比从零开始写 prompt 高好几个档次。4.2 迭代式生成策略没有一个 LLM 能一次生成完全正确的模型这是我在几十次项目里验证过的铁律。正确的心态是把生成当成迭代循环生成、检查、反馈、再生成。第一步先让模型生成一个草稿级模型只关心大体的特征结构和相对比例不要在一开始就纠结精确尺寸。这就像写代码先写框架再填逻辑过早抠细节会让模型的注意力分散导致整体结构出错。第二步做结构审查我会把生成的脚本在 Jupyter 里渲染出来先看宏观形状对不对再看特征数量有没有遗漏最后才核尺寸。结构审查通过之后再进入精确尺寸反馈阶段——把具体的公差、配合关系写清楚让模型修改。这里有个很重要的提示词技巧反馈的时候不要说改大一点调整一下要给出量化的修改指令。我实测下来明确说把壁厚从 2mm 改为 3mm把安装孔直径改为 8mm 并在 Y 方向偏移 5mm模型的执行准确率远比模糊表达高。因为 CAD 本身的语义就是定量的模糊表达对模型来说是负信息。整个迭代过程中我会把每次的 prompt 和对应输出都存下来。这些数据是最好的少样本微调素材积累到一定量之后你的私有模型或 API 调用效果会指数级提升。4.3 组装与干涉检查单零件生成的坑踩过之后你会遇到下一个更大的问题多个零件怎么保证装配关系正确这是 text-to-cad 目前最薄弱的一环。LLM 对这两个零件应该对齐的理解很多时候是概念层面而不是几何层面的。它知道法兰盘要和管道对齐但生成的模型里螺纹孔的位置可能差了几度。这个问题我建议这样处理不要把装配约束交给 LLM 的默认输出而是在 prompt 里定义好坐标系基准。比如你设计一个外壳加一个盖板在 prompt 里明确写壳体的原点位于底面中心盖板底面与壳体顶面重合Z 方向朝上四个角上的 M3 螺纹孔中心位置与壳体上对应的孔完全同轴。同时在生成的 CadQuery 脚本里用cq.Assembly模块组装再导出 STEP 做干涉检查。CadQuery 的Assembly支持刚体变换和约束关系可以把多个零件在脚本层面拼装好。这比逐个零件导入 FreeCAD 再手动配合要高效得多。干涉检查我一般用两个途径快速检查在 CadQuery 里直接布尔求交看有没有重叠实体详细检查导出 STEP 后拿到 FreeCAD 的 Part Workbench 里做 B-rep 级干涉分析。前者秒出结果适合迭代后者适合最终交付前把关。4.4 导出与下游工具对接生成合格的模型最终要导出给下游用这一步的格式选择取决于你的交付对象。如果目标是 3D 打印直接导出 STL要注意在 CadQuery 里设置合理的网格精度参数。cq.exporters.export(result, part.stl, tolerance0.01)里的 tolerance 参数越小网格越细文件越大但默认值 0.1mm 对大多数 FDM 打印都够用。如果做光固化或者精度要求高的打印调到 0.01 也问题不大。如果目标是 CNC 加工、模具或者和其他工程师协作就必须导 STEP。STEP 是工程界通用语言保留了 B-rep 实体拓扑进入 CAM 软件之后可以直接选面、建刀路。CadQuery 导 STEP 很简单一行代码的事但质量依赖几何内核——好在 CadQuery 走的是 OpenCASCADE 内核成熟度足够支撑常规机械件的导出。如果目标是 FE 仿真可以导 STEP 之后进网格划分工具也可以直接在 CadQuery 里用cq.occ_impl.shapes配合网格工具做前处理。我的实际经验是越早把模型导成 STEP 放进仿真流程越好因为后续所有基于网格的操作都会蚕食你宝贵的迭代时间。5. Prompt 工程经验如何让 AI 听懂工程语言5.1 常见失败模式与对应策略我在大量生成实践中总结了 LLM 在 text-to-cad 提示词上的几类典型翻车每一条都有对应的解法。第一个翻车点是用错单位制。8mm 厚容易被理解成 8 个模型单位最后导出的 STEP 里尺寸变成 8 英寸甚至 8 米。解决方法是 prompt 开头明确声明单位以下所有尺寸单位均为毫米mm不允许使用其他单位。同时在生成的脚本里检查数值量级——直径 8mm 的孔和直径 80mm 的孔在视觉上差异巨大一眼就能看出来。第二个翻车点是描述顺序混乱。模型遵循 attention 机制先看到的信息权重更高。如果先说一堆外观修饰再说关键尺寸尺寸部分容易失真。解决方法是严格按主体 → 特征 → 细节的顺序描述把最重要的结构约束放在最前面。第三个翻车点是负向提示缺失。系统生成的默认零件往往壁厚过大、倒角夸张一看就是AI 脑补出来的样子。我会在 prompt 末尾加一句负向约束壁厚不得超过 3mm外表面不得有不必要的装饰性圆弧所有圆角必须有明确的工程目的。这句话能显著减少拟合过头的产物。第四个翻车点是上下文长度不够。一个复杂零件描述下来prompt 可能超过 2000 token加上示例代码可能超 4000 token。有些 API 的上下文窗口吃紧模型会忘记你前面说的约束。对策是拆分任务先描述主体结构生成第一版再在已有代码上追加特征描述而不是一次性把所有特征都写进第一轮 prompt。第五个翻车点是盲目相信模型输出的尺寸标注。LLM 生成的脚本里可能写了hole(8)但它在生成过程中如果计算错了位置坐标你得到的孔还是会偏。尺寸数值本身准确不代表几何位置准确每个关键位置都要在检查阶段验证。5.2 少样本模板库的建设我建议每个认真用 text-to-cad 的人都要建一个少样本模板库这是投入产出比最高的投资。模板库的粒度不需要很细按零件大类来分就行。每类准备 2 到 3 个完整的描述 脚本示例对。模板本身要满足几个标准第一脚本必须已经验证过能正确执行而且生成结果在工程上说得过去第二描述必须覆盖尺寸、公差、位置关系、制造约束这几个维度作为标准格式范例第三脚本里的每个操作都要有注释说明这一步对应描述里的哪句话模型才能学会描述 → 操作的映射关系。有这个模板库之后新任务的 prompt 写法就变成了检索最相近的模板、复制模板描述、替换具体参数和名称、追加本次特有的约束。这套流程的效率比让模型从零理解需求高得多生成一次通过率能从 20% 提升到 60% 以上。5.3 用代码评审的方式审模型检验一个 text-to-cad 生成结果到底行不行最有效的方式是把生成的脚本当成别人提交的 PR 来评审。这个视角转变让我收获特别大。评审先从代码结构看起特征顺序是否合理拉伸、切除、布尔运算的先后关系对不对有些模型会把布尔差集放在拉伸之前导致结果完全错误有些会重复生成同样的特征浪费计算不说还容易出拓扑错误。然后看命名和注释——好的生成脚本会自己加注释说明每个步骤的意图这反过来验证了模型确实理解了描述语义。最后看参数复用——如果同一个数值在脚本里出现很多次说明模型没有把参数抽象出来后续手动调整会很痛苦。评审通过之后我还会把脚本丢进 CI 里跑一轮测试验证能记录每一步的时间。给模型加一个简单的回归脚本比如生成结果的内存占用和面数是否在合理区间这些都是浅层检查但很有用。本质上把 text-to-cad 的产物当代码管而不是当图看是我觉得这个技术正确打开方式的核心。6. 常见问题与排查技巧实录6.1 CadQuery 环境搭建的坑CadQuery 的安装不算难但有些坑很容易扎到新人。首先是版本兼容2.x 的Workplane对象和Shape对象的 API 变化很大网上很多教程是老版本的写法直接抄过来会报错。其次是 Python 版本CadQuery 目前对 Python 3.10 到 3.12 支持最好太新的版本可能有预编译包缺失的问题。还有 Jupyter 集成CadQuery 官网推荐的cadquery-ocp和jupyter-cadquery插件配置起来要注意 Jupyter 版本也不能太新。我试过在全新的 JupyterLab 4.x 上装 jupyter-cadquery直接装不上最后回退到 3.x 才搞定。这种新版本反而装不上的体验在这个生态里很常见方案就是按官方文档锁版本。一个非常隐秘的坑是 VSCode 的 Python 解释器选择。CadQuery 的预编译包是绑定具体 Python 小版本的如果你用 pyenv 管理多版本很容易装到一个错误的虚拟环境里。我建议每台机器只维护一个专门的 CadQuery 虚拟环境里面锁死所有依赖版本不要和其他项目的环境混在一起。6.2 生成失败的定位方法遇到生成失败第一步不是改 prompt而是先定位失败在哪一层。到底是 LLM 压根没生成出合法脚本还是脚本语法错误还是运行时几何错误这三类问题的处理方式完全不同。第一类LLM 输出非法脚本。多半是模型的代码能力不足或者缺少足够的少样本引导。先检查 API 返回有没有格式异常如果输出完整但语法错误把报错信息和失败的代码块回喂给模型让它自己修如果模型反复自修失败就换更强的模型或者补充更贴近的示例。第二类脚本语法正确但运行报错。CadQuery 的报错信息比大多数几何库友好得多会精确告诉你哪个操作在哪个平面上失败了。常见的有在空Workplane上执行操作、布尔运算对象不相交、fillet选了无法倒角的边。这类问题快速但烦人需要逐步注释代码定位确认每段基础几何是否正常生成。第三类运行成功但几何不符合预期。这是最难排查的因为没有任何报错只是结果不对。我的经验是先从整体尺度入手——生成一个 2m 的零件和生成一个 20mm 的零件在脚本里体现清清楚楚先排除单位和量级问题再到特征层面——逐个检查每个特征是否按描述生成最后才到位置关系——用intersect布尔运算验证相对位置是否正确。排查时一边看一边把怀疑的代码段标注出来效率远高于反复重新生成。6.3 几何缺陷的工程化规避text-to-cad 生成模型最常见的工程缺陷有三类每一类我都有对应的规避手段。第一类是非流形几何。布尔运算在边缘条件下可能产生零厚度的面或悬空边这种模型导出 STEP 后进 CAM 会各种报错。规避方法是在 CadQuery 生成结束后调用val().isValid()检查实体合法性再用fix_face_orientation()之类的方法修一遍。如果发现非流形实体直接放弃该版本重新生成——三维修补的投入产出比极低。第二类是微小特征炸裂。LLM 喜欢在外面加一圈 0.1mm 的装饰性圆角这种特征对实际制造毫无意义还会导致网格划分时产生海量小面片。规避方法是在 prompt 阶段就把最小特征尺寸写清楚所有圆角半径不得小于 0.5mm孔洞直径不得小于 2mm壁厚不得小于 1mm。第三类是开放壳体和封闭实体混淆。描述带开口的盒子时模型可能给你生成一个没有底面厚度、只有五个面的开放薄壳这在 B-rep 里不是实体模型。规避方法是在描述里明确该零件为实体所有壁面均为有厚度的实体材料并在检查阶段确认isSolid()返回真。6.4 常见问题速查表问题现象可能原因处理建议模型尺寸放大 10 倍/缩小 10 倍单位制混乱prompt 开头显式声明单位mm检查脚本数值量级特征位置错乱描述顺序混乱按主体→特征→细节重写描述把关键约束提前壁厚异常、圆角过多缺少负向约束在 prompt 末尾加最小尺寸和工艺约束条款生成结果充满拟合感模板示例不足补充少样本模板特别是同类零件的完整示例对脚本运行报错CadQuery 版本不兼容锁死 CadQuery 版本按官方文档匹配 Python 版本布尔运算失败操作对象不相交或嵌套逐步注释代码定位检查每个基础几何是否独立有效导出 STEP 后 CAM 不识别非流形实体调用isValid()检查非流形则直接重新生成多个零件装配关系错误缺少坐标系基准在 prompt 中定义原点、轴向和装配面约束7. 进阶玩法把 text-to-cad 嵌入真实产品流程7.1 参数化变体库的自动化构建text-to-cad 真正发挥威力的地方不是给你画一两个惊艳的模型而是把重复性建模劳动变成模板加参数扫描。我们团队在做一个传感器安装支架库的时候需求是一套覆盖 8 种传感器外壳尺寸、3 种安装朝向、2 种壁厚的变体集合。传统做法是在 CAD 里做一个参数化模型然后手动切参数批量生成每次改参数都要等模型重建耗时且容易出错。换成 text-to-cad 加 CadQuery 之后我把通用的几何逻辑写成一个带参数的脚本模板用 LLM 针对每种传感器尺寸生成对应的参数配置和特征变体再用循环批量执行生成 STEP。整个过程从两天缩到四十分钟而且所有脚本都在 Git 里谁改了哪个参数历史清清楚楚。这里有个关键设计不要把整个变体逻辑全部塞给 LLM。正确的姿势是让 LLM 做结构变体推理也就是根据传感器的形状差异决定加不加加强筋、改不改孔位布局而纯粹的尺寸参数交给配置文件管理。LLM 擅长处理的是语义层面的变化数值域内的变化用传统参数化方式更可靠两个结合才最高效。7.2 与三维打印工作流的整合三维打印用户是 text-to-cad 最大的受益群体之一很多玩打印机的朋友并不擅长传统 CAD。我身边好几个创客朋友已经用 text-to-cad 加 CadQuery 替代了主流的网格建模软件因为他们大部分需求是外壳、支架、齿轮、轴套这类规则件CadQuery 加 LLM 绰绰有余。整合工作流大概是用 text-to-cad 生成模型 → 导出 STL → 进入切片软件检查支撑 → 切片打印。关键点在于 STL 的网格质量。CadQuery 导出的默认网格精度有时候不够薄壁零件切片出来会有破面。我一般在导出前先做一次细化from cadquery import exporters exporters.export(result, bracket_shell.stl, tolerance0.01, angularTolerance0.1)angularTolerance控制曲面部分的网格细度如果模型里有圆弧面把小一点提升表面质量。这两个参数配合调整几次基本能找到适合 FDM 打印的最佳平衡点。再往深一点把生成结果直接接进切片软件的命令行接口就能做到描述零件 → 自动出 G-code这条自动化的潜力还远没有被挖掘完。7.3 团队协作从个人工具到团队资产text-to-cad 刚火的时候我以为这只是一个个人效率工具。用了一段时间后才发现它更是个团队协作模式变革器。传统 CAD 图纸是二进制文件评审只能在专业的看图软件里进行产品经理想看一个设计得专门装 SolidWorks。text-to-cad 生成的是脚本加文本描述任何懂代码的人都能通过 GitHub 提 issue、留评论、修改参数沟通成本大幅下降。我们团队现在的新设计流程是产品经理写需求描述 → AI 生成初版模型和脚本 → 结构工程师评审修改 → 导出交付。整个过程里产品经理和工程师用的是同一种语言——描述性文本A 和 B 之间的翻译损耗明显减少了。当然C 端和 B 端的协作模式不一样。如果只是自己玩打印这套流程的意义在于效率提升如果是一个团队协作它的意义还在于降低了参与门槛让非三维软件用户也能在设计早期就介入进来。这个变化的影响我认为比自己画图更快这件事要大得多。8. 我的最终体会与下一步尝试前面讲了这么多具体的工具、参数和流程最后还是想聊聊这些年实操下来的一些真实感受和建议毕竟纸面上的教程到处都是但该不该用、怎么定位这个东西只有踩过坑的人才说得明白。我在实际使用中最大的感悟是text-to-cad 不是一个取代 CAD 设计师的技术它更像是一个消灭重复劳动和降低启动门槛的技术。它把从概念到基础模型的时间压缩了一个数量级但它无法替代设计师对功能、制造工艺、装配关系、成本控制的综合判断。最理想的用法是让 AI 承担从零到六十的部分设计师专注于从六十到一百的部分。想明白这一层才不会对生成结果抱有不切实际的期待也不会浪费这个工具真正有价值的那一面。技术选型上我的建议是不要迷信任何单一方案。参数化脚本路线和直接内核路线各有各的适用场景自己 DIY 和云平台应用也不冲突。最实用的架构是用云平台做快速概念探索用本地 CadQuery 加自建模板做正式产品开发两边导出的 STEP 在同一个目录下统一管理和归档。下一步我准备尝试的方向是结合 RAG检索增强生成把企业内部的零件库标准和历史设计数据接入 prompt 上下文让模型在生成时自动遵循现有的设计规范和标准件库。这个方向如果能走通text-to-cad 就真正从通用生成器变成了符合企业标准的自动化设计助手。虽然这条路还有不少工程问题要处理但看到这个方向的发展节奏我觉得值得投入精力持续跟进。