如果你过去半年在 GitHub 或 Hacker News 上晃悠，大概率刷到过这样的 demo：输入一句“一个带四个通孔的安装底座，孔距 40mm，底部加加强筋”，几秒钟后输出一个可以直接进 CAM 软件编程的 STEP 文件。这个方向就是 text-to-cad，直接用自然语言生成可编辑、可制造的 CAD 模型。

我一直在做 CAD/CAM 相关工具链的开发，这个方向一出来我就盯上了。原因很简单，它解决的是 CAD 行业一个非常痛的刚需：大量重复的标准件、非标零件、工装夹具建模，本质上就是把需求用语言描述出来再在软件里“画”一遍，这个过程又枯燥又容易出错。如果模型能直接把口语转成带特征历史树的参数化模型，设计师省掉的不只是几分钟，而是把整个工作流的前半段自动化了。

这篇文章我把这个方向从技术路线、工具选型到实操踩坑完整拆一遍，写给两类人看。一类是做 CAD 二次开发或 CAM 编程的工程师，想评估这技术能不能接进自己现有流程；另一类是玩 LLM 应用开发的，想知道这类“生成式建模”到底怎么落地。我不讲虚的，全是实际跑过的流程和参数。

1. text-to-cad 在做一件什么事

1.1 核心需求解析：为什么 CAD 生成比 AI 绘图难这么多

先说个很直观的对比。AI 画图发展到现在，你输入“一只穿宇航服的柴犬”，它生成的是一张像素图，就算网格有瑕疵、手指多一根，人类肉眼看着“像”就满意了。但 CAD 模型不是给人看的，是要拿去加工、装配、做有限元分析的。

CAD 的本质是精确的几何表达。一个直径 10mm 的孔，不能是 9.98 或者 10.03，加工出来就得是 10mm，配合关系才成立。更关键的是 CAD 文件不只是“长得像”就行，它背后是一个特征历史树：先拉伸一个长方体，再在上面打孔，孔的类型是通孔还是盲孔，同心还是阵列排布，这些特征顺序直接决定了模型能不能做工程变更。这就是为什么 text-to-cad 的技术难度和 AI 绘图不在一个量级——你生成的不只是形状，而是一整套可参数化、可重新编辑的建模指令序列。

我之前把生成结果拿给一位干了二十年结构设计的老工程师看，他第一反应是：“这模型三项公差没标，材料没给，粗糙度没写，怎么用？”这恰恰说明 text-to-cad 的“够用”标准不是几何相似，而是能接进现有的制造链路。理解了这一点，后面的技术路线分析才有判断基准。

1.2 和传统参数化建模、生成式 AI 绘图的位置关系

如果把 CAD 建模工具的发展按逻辑排一下，传统参数化建模是“人通过 GUI 操作特征命令”，脚本化建模是“人通过 Python/C++ 调用建模 API”，那 text-to-cad 就是把最后这层手动操作也去掉，直接用语言驱动模型生成对应的 API 调用序列。

它跟生成式 AI 绘图是平行的两个方向，但底色完全不同。AI 绘图的底层是 2D 像素分布建模，输出本身不承载工程语义；text-to-cad 的底层是几何约束求解和程序化特征生成，输出的是边界表示（B-Rep）、特征树、装配关系这些硬核工程数据。所以如果你之前做过 AI 绘图的模型，想迁移到 text-to-cad，第一课就是忘掉“像素误差”、重新学习“拓扑修正”。

从应用位置看，text-to-cad 最适合卡在“需求描述”和“模型初稿”之间。设计师拿着客户的文字需求或自己的草图语言，先让模型快速生成一版可以编辑的基础几何，再进 SolidWorks/Fusion 360 里做后续的结构细化和出图。它不是替代你从零做复杂设计，而是消灭“从空白文件开始”的启动成本。

2. 技术路线拆解：文本到 CAD 的三条主流路径

2.1 代码生成派：让 LLM 直接写建模脚本

这是目前落地最快的一条路线，核心思路很简单：LLM 本身已经很擅长生成 Python 代码，如果有一套完善的建模库，让模型输出建模脚本，再执行脚本生成几何，那文本到 CAD 就能复用整个 LLM 的代码能力生态。

这里的关键是有没有一套“语义贴近自然语言”的建模封装。以我用过的 CadQuery 为例，它把建模操作写成链式方法，比如box(10, 20, 30).faces(">Z").hole(5)，读起来几乎像英文句子。LLM 生成这种代码的命中率，远比生成一堆底层的 vertex、face 操作要高。另一个常见方案是 SolidPython，本质是把 OpenSCAD 的 CSG 操作封装成 Python，适合布尔运算为主的结构件；还有企业级方案直接让模型写 FreeCAD 的 Python API 或者调用 Siemens NX 的二次开发接口，代价是各家 API 风格差异大，模型需要针对性微调。

我用代码生成派跑过一个很典型的测试：让模型生成“一块 120mm x 80mm x 8mm 的铝板，四角做 M4 沉头孔，中心开一个 30mm x 20mm 的腰形槽”。LLM 给出的 CadQuery 代码中，沉头孔的counterSink参数和腰形槽的slot2D调用方式居然一次就对了。这对实际工程来说意义很大，因为模型输出的不是一堆三角面片，而是可以直接改尺寸、换位置、进 CAM 的带特征历史模型。

这条路线最大的红利是“可解释性”。代码摆在那里，工程人员一眼就能看出建模逻辑对不对，错在哪里也能直接改，而不是对着一个黑盒输出的网格发愁。它的天花板也显而易见：如果目标零件本身结构复杂到需要大量曲面放样、自由造型设计，LLM 生成普通代码的复杂度会指数级上升，容易生成逻辑正确但代码不可执行的“幻觉脚本”。

2.2 隐式场生成派：让神经网络表示几何

第二条路线是把文本和几何都放进神经网络里，用隐式场来表示形状。这类方法的代表是 OpenAI 的 Point-E / Shap-E 系列，以及后来学界大量跟进的“文本到神经场”工作。思路是：把几何表达成一个连续函数，对空间任意一个点，函数输出它是实体还是空腔，再通过 Marching Cubes 之类的方法把隐式场提取成网格。

说实话，这条路线在“视觉像不像”上进步很快，我第一次用 Shap-E 生成“一把扳手”时，输出结果确实有扳手的轮廓，曲面过渡也平滑。但问题在于它的输出是无特征历史的三角网格，如果想在 CAD 系统里编辑尺寸、改孔位，等于把这张网格重新逆向成参数化特征，这个逆向过程比从零建模还要费劲。

我在实际测试中发现，隐式场派生成的模型还存在“拓扑致密”问题。比如你要求“一个带圆孔的球”，它可能会生成一个表面整体封闭但圆孔没有真正打穿的实体，或者圆孔位置跑偏。原因在于隐式场模型是在连续空间里做密度回归，对“语义位置”和“几何精确位置”的对应关系天然不够敏感。在我的评估里，这条路线更适合做“概念草模”和“需求可视化”，比如工业设计前期的造型预研，拿给客户看造型方向，而不太适合直接进制造流程。

但必须说一句公道话：隐式场派在处理有机曲面、拓扑自由形态上有先天优势。比如生成人体工学鼠标外壳、汽车内饰曲面这类造型优先的场景，参数化建模反而很难快速描述，而这正是扩散模型擅长的领域。可以预见后续的演进方向，多半是隐式场出造型、再通过一个“参数化逆向”模块转成 CAD 特征，而不是直接替代 CAD 内核。

2.3 程序化生成检索派：让模型“组装”而不是“生成”

第三条路线理念完全不同，它不试图凭空捏造几何，而是把 CAD 零件看成“若干可复用程序化特征的组合”。这类系统的典型逻辑是：先从已有的 CAD 模型库或特征库中提取出大量标准特征，比如加强筋、凸台、阵列孔、滚花、法兰边，再把文本输入解析成特征序列和控制参数，最后通过参数化模板“拼装”出目标模型。

这在工程软件里其实早有实践原型，很久以前就有“智能标准件库”之类的功能，但当时只是固定的参数化模板，不能理解自然语言需求。现在把 LLM 塞进来当解析器，情况就变了。模型可以根据句子识别出零件类型（法兰、底座、支架）、关键尺寸（直径 50mm、厚度 5mm）、特征要求（均布 6 个孔），然后从模板库中选择合适的基础体，挨个堆叠特征并更新参数。

这条路线的好处是“良品率”极高。因为所有特征模板都已预先验证过，生成的模型大概率是可制造、无破面的，这对工业落地非常重要。坏处也非常明显：它只能生成模板库里有的形状，遇到真正新颖的造型设计就抓瞎，本质上是“覆盖低 + 精度高”的组合。

我自己在这条路线上做过一个小实验，用一段语意解析规则把“带安装耳和轴承座的底座”转换到指定模板。解析出了三个关键槽位：主体底座尺寸、安装耳数量与孔位、轴承座内径。结果生成模型的尺寸全对，但整体造型一看就是从模板堆出来的，缺乏灵活性。所以我的结论是：面向“非标零件的参数变型”场景，这条路是当前最稳的生产级选择；面向“从零创新设计”，它做不了。

2.4 三条路线如何选型：我的判断框架

如果你现在要在项目里引入 text-to-cad，不用纠结“哪个路线最先进”，而是要看“哪个路线能正面刚你的业务约束”。我给自己定了一个四维判断框架：输出格式能否被下游工具直接消费、生成结果能否被工程师快速改、新形状覆盖度够不够、单次生成成本是否可控。

按这个框架，做非标自动化设备的，优先选代码生成派，因为输出 CadQuery 脚本或者 FreeCAD 脚本之后，可以在自家系统里二次编辑，甚至能自动转成 CAM 加工路径。做消费电子或者文创产品的，造型变化多且加工精度要求相对低，隐式场派反而能带来更多造型灵感。做标准件、模具配件这类强系列化产品的，程序化检索派能拿最小成本满足 80% 需求。

我还想说一个被很多人忽略的点：不要迷信模型输出的“一步到位”。真实工程中效率最高的用法是，把 text-to-cad 当作“语义到参数”的转换器，先生成草稿，再用传统手段精修。就像写代码用 AI 补全一样，没人指望 AI 直接写出整个生产系统，但用它对 CRUD 接口做快速原型是真香。

3. 实操：从文本提示词到 CAD 文件的全流程

3.1 工具选型实战：开源模型的采样对比

如果你现在就想上手，我建议按“先易后难”的顺序来。第一步先用现成的开源模型 ZOO Text-to-CAD 跑通流程；第二步接 CadQuery，把输出脚本化和参数化；第三步再考虑用企业级 API 接进自家 CAD 插件。

我实际测试 ZOO 这个模型时印象很深。第一，它对“简单机械零件描述”的理解力超出预期，输入“需要一块 40mm 边长的正方形板子，厚度 5mm，四角得有四个 3mm 直径的孔，孔距离板中心都是 15mm”，它输出的模型在尺寸精度上误差很小。第二，它对“复杂装配关系”处理得不够好，比如描述“一个齿轮泵壳体，内有轴孔和两个端面法兰”时，生成的模型内部结构逻辑会混。第三，它生成结果不是直接传 STEP 文件的，而是先生成描述脚本，再在云端或本地转换成可下载的 CAD 格式。我们团队把生成好的模型导入到 Fusion 360 试过，特征树是可读的，这一点非常关键，意味着可以直接在 CAD 软件内调整参数，而不是传统 Neck 那种“只能看不能改”的模型。

如果你打算在本地跑或者嵌入自己的流程，我建议第一步配置环境时把 Python 版本固定好。很多几何库对 Python 版本比较敏感，我在 3.11 上跑 CadQuery 经常遇到莫名其妙的导入错误，退回 3.9 反而顺畅。另外强烈建议一开始就用 Docker 封装，把所有几何内核依赖、渲染依赖、模型依赖都打包在一个容器里，省得在部署阶段跟底层的 OpenCascade 库版本较劲。

3.2 代码示例：用 CadQuery + LLM 搭建一个最小可用系统

与其等别人做工具，不如自己搭一个低配版 text-to-cad 流水线，完全不复杂。整体流程就是：输入文本 -> LLM 生成 CadQuery 脚本 -> 执行脚本生成几何 -> 导出 STEP -> 进 CAD 查看。下面给一段我实际跑过的最小示例，注意这里用到了最长见的 CadQuery 封装，重点看它怎样把语义和代码对上。

import cadquery as cq # 构造一个带底板和中心孔的简易零件 result = ( cq.Workplane("XY") .box(80, 60, 10) # 底板 80x60x10 .faces(">Z") .workplane() .hole(20) # 中心通孔直径 20 .faces(">Z") .workplane() .rect(30, 20, forConstruction=True) .vertices() .hole(4, 8) # 四个角打 M4 沉头孔，沉头直径 8 ) # 导出 STEP 用于后续 CAM / CAE cq.exporters.export(result, "base_plate.step")

在实际运行时，我会在脚本外面套一层语言模型的生成结构：先把用户输入文本塞进提示词模板，让模型输出一段符合 CadQuery API 的代码，然后本地执行这段代码，通过捕获异常来反馈错误信息，如果执行成功就导出文件。这个流程其实已经把“文本到 CAD”的核心链路跑通了。

提示词模板我一般是这样写的：

你是一名熟练的 CAD 建模工程师，使用 CadQuery 库生成 Python 代码。 用户需求：{用户描述} 要求： 1. 只输出可直接运行的 Python 代码，不要多余解释。 2. 优先使用参数化尺寸，方便后期修改。 3. 命名变量要清晰，关键尺寸用变量赋值。 4. 导出为 STEP 文件的最后一行代码务必存在。

这里有个细节值得说。如果不加“优先使用参数化尺寸”，模型生成的脚本会把所有数字写死，后续想在代码里改一个板厚就得满文件找。加了这句之后，模型会把长度、厚度、孔径这些关键量提到脚本顶部，工程价值立刻上一个台阶。这就是提示词工程对生成结果的结构性影响。

3.3 从文本到质量可控的 STEP 文件

生成脚本和执行脚本只是整个流水线的前半段，真正决定“能不能用”的是后半段的几何校验和格式转换。很多新手会把“生成成功”当成“结果可用”，但在 CAD 世界里这俩隔着十万八千里。

我踩过最典型的一个坑，是模型生成了一段看起来完美、执行也成功的 CadQuery 代码，导出的 STEP 文件拿进 Fusion 360 打开却提示“实体无效，无法进行布尔运算”。排查下来发现是模型中存在“非流形边”——两个面仅共用一条边但没有体积连通性，这在可视层面看不出来，但在几何内核校验阶段会直接判定失败。从那时候起，我在生成环节之后多了三件套校验：用checkers检查实体有效性、用Volume()检查体积是否为正值、用BoundingBox检查整体尺寸是否符合预期范围。

格式方面，如果你只做 3D 打印或视觉展示，STL 就够了；但如果要做 CNC 加工或装配干涉检查，务必导出 STEP 格式，因为它保留精确的 B-Rep 几何和拓扑关系。CadQuery 导出 STEP 的接口非常成熟，本质上调用了 OpenCascade 内核，所以转换出来的 STEP 可以被主流 CAD 软件无缝识别。但要注意，不同 CAD 软件对 STEP 的 tolerance 设置不同，如果默认导出精度导致小圆角、小倒角丢失，可以在导出时设置write_tolerance参数提高精度，代价是文件变大、加载变慢。

我在实际项目中把这三步固定成了一个流水线：文本输入 -> LLM 生成脚本 -> 脚本静态检查 -> 执行建模 -> 几何校验 -> 导出 STEP -> 归档。每个环节都有日志输出，出了问题按日志倒查，比在 CAD 软件里对着烂面猜原因快得多。

3.4 工程实操：从文本到 CAM 前模型的一个完整案例

这部分我完整跑一遍，让大家感受下真实的输入输出是什么样的。假设业务部门提了个需求：做一个电机安装支架，底板边长 100mm，厚度 6mm，中心开直径 32mm 的通孔用于电机轴穿过，四角有四个 M6 安装孔，孔距 80mm x 80mm，支架一侧竖直伸出高 60mm 的立板，立板中心开一个直径 10mm 的过线孔。

这段文本如果是人肉建模，大概要五分钟；我用 text-to-cad 流水线跑，生成脚本大概花了七八秒，导出 STEP 后再进 CAM 软件做后处理，总共一分多钟就拿到了可加工的模型。需要说明的是，这里生成的不是“一次性死模型”，立板的高度、过线孔的直径、安装孔的间距全部是参数变量，加工时如果客户要求板厚改成 8mm，我只需要改一行代码重新生成。

当然不是所有案例都这么顺。我试过让模型生成“一个带涡旋状流道的散热器盖板”，这属于包含自由曲面的复杂铸造件，LLM 用 CadQuery 这类程序化建模手段很难描述涡旋流道，折腾了好几次生成的模型曲面质量都不达标。后来我发现，对这种造型件，更好的思路是用隐式场模型先出一版曲面造型，再导入 CAD 软件用“曲面拟合成实体”功能转换，让两条路线协同而不是互斥。这个认知帮我省了很多无用功。

4. 踩坑实录与质量调优

4.1 常见问题速查：生成失败、模型非流形、语义理解偏差

先说生成失败的问题。我统计了大约 100 次生成请求，发现 LLM 直接生成 CadQuery 脚本的失败率并不低，其中语法错误占 30%，API 调用参数错误占 45%，“逻辑上可行但几何输出出人意料”占 25%。语法错误好修，把报错信息直接回传给模型让它重写就行；API 参数错误就棘手一些，比如hole()方法不理会被传入的“沉头深度”参数，模型其实不知道该调哪个 API。

我用的一个非常有效的缓解办法是“少样本引导”。在提示词里给模型展示 3 到 5 个典型的“文本-代码”配对示例，最好跟你当前任务类型接近。这样做的效果好得出奇，模型对 API 的记忆准确率会显著提升，因为它在模仿而非凭空推理。有人说这是投机取巧，但工程上有效就是硬道理，谁用谁知道。

第二个高频问题是模型非流形。这算 CAD 领域的“翻车之王”，我在前文提过一次，这里展开讲怎么处理。最简单的加固手段是在建模脚本末尾强制加一段“实体检查代码”：如果检查出非流形边或者体积异常，就自动触发一次“修复流程”——尝试调用combine把相邻实体合并，或者用copy重建一个干净的实体。如果自动修复失败，就不导出 STEP，而是返回“模型生成异常”的提示，避免脏数据流入下游。

第三个问题是语义理解偏差。比如我输入“一个 M8 的螺丝”，模型可能生成“螺杆直径 8mm 的螺丝”，也可能生成“带 M8 螺纹特征的螺丝”，两者几何表达差很多。真实 CAD 中 M8 不是直径，是公制粗牙螺纹的规格代号，对应的大径约 7.98mm。要解决这类问题，必须给模型一份“机械语义词汇表”，把工程图纸上常见的名称、代号、公差术语预先映射到具体数值和建模策略。这也是为什么我前文反复强调，text-to-cad 不是纯 AI 问题，是“AI + 工程语义 + 几何内核”的三体问题。

4.2 提示词与后处理的微调技巧

如果你只想做轻量微调，把精力花在“提示词模板”和“后处理脚本”上，性价比最高。

提示词层面有四个位置值得放精力。第一，开头身份设定不能省，明确“你是 CAD 建模工程师”，模型输出的术语体系和代码风格会立刻不同。第二，结尾必须给出“输出格式约束”，比如“只输出代码”“不要解释”，否则它会给你生成一段夹杂自然语言的代码块，解析时又多一层麻烦。第三，任务描述尽量带上“几何参数约束”，比如“板厚优先给变量，孔径_主 = 20”，模型会更倾向按参数化方式生成。第四，加入“避免事项”，比如“不要生成装饰性圆角”“不要在铸造件上添加机加工倒角”，这些细节能挡住一大批专业错误。

后处理层面我的体会是“能离线校验就不要实时反馈”。在我前面的流水线里，模型生成脚本后我先做正则级别的代码安全检查，再把脚本放到一个带超时控制的子进程里执行，避免模型生成死循环或者无意中调用危险操作。这一步对生产环境尤其重要，因为你不能假设模型每次都会生成“好人代码”。

另外一个很多人没注意的技巧：把“生成结果”和“用户期望”做一个关键词级别的相似度比对。比如用户输入提到“安装孔”，那导出的 STEP 里必须有至少四个孔的特征；提到“沉头”，那孔特征必须带有沉头角度参数。这个比对不需要搞什么高深算法，用关键词和特征映射表就够了，但能在交付前拦下大量语义漂移的案例。

4.3 精度与性能：实测数据与可控性分析

说到性能，我实测下来，在本地 RTX 4090 上跑一个开源 text-to-cad 模型，单次生成大概 5 到 20 秒，视复杂度而定；如果用 API 走云端，单次大概 10 到 30 秒。相比人工建模的几分钟到几十分钟，这个速度优势已经很明确。

精度方面要分开看。几何尺寸精度其实很容易做到高，因为最终输出是以脚本驱动几何内核，长度、直径、角度公差只要脚本参数正确，几何内核就会给出精确值。真正的坑在“语义精度”，也就是模型有没有把你说的“法兰”理解成真法兰、把“通孔”做成真的通孔。我测试过一批包含机械术语的文本，整体语义命中率大概在 70% 到 85% 之间，提高命中率最有效的方法就是给模型喂“专业词汇-几何特征”对照表。

可控性也是工业场景最关心的。如果你要让一个三维模型从“像”变成“可用”，必须让用户能改参数，能回退特征，能替换材料。text-to-cad 在这方面的天然优势是脚本输出本身就可编辑，但我建议你在产品里额外加一个“特征树预览”界面，把模型生成的每个操作步骤列出来，让用户点步骤就能定位到代码对应行，这样“黑盒感”会大大降低。

5. 评估与落地：除了生成还要看这些

5.1 怎么评估一个 text-to-cad 系统是好是坏

如果你要在工程里做选型评估，我给你一套实测好用、不依赖主观感受的指标维度。第一项是“语法通过率”，指生成代码能被 CAD 环境直接执行的百分比，低于 60% 基本没办法投入生产。第二项是“特征语义匹配率”，把用户输入的必选特征列成清单，对照输出模型的属性，逐项打分，比如“有 4 个安装孔”“孔径公差符合要求”。第三项是“可制造性评分”，模型导出的 STEP 文件是否能在 CAM 软件里顺利生成刀路，是否存在倒扣、负角、薄壁等加工陷阱，这一步最好请有经验的工艺工程师人工复核。

我见过不少团队在评估时只盯着“像不像原图”，这是一种误导。比如输入“一个法兰盘”，生成结果如果外形酷似、但所有孔位是均匀阵列而不是设计图纸要求的定位孔位，那这个“像”根本没有工程价值。在 CAD 领域，“可编辑、可制造、可复用”永远排在“视觉相似”前面。

另外，评估时不要只看单一模型，要跑清楚“输入微调后的稳定性”。同一个描述，换一种说法、调整一下尺寸前缀，生成结果是接近还是天差地别？如果稍微变一下输入措辞结果就完全不可用，那即便指标再高也不能上线。我实测过几个模型，发现措辞鲁棒性差距很大，这跟模型的指令跟随能力和领域知识都有关系，而不仅仅是参数规模。

5.2 从模型到产品：接入 CAD 插件与团队协作流程

最后聊一聊把 text-to-cad 接进真实产品时的组织层面问题。技术选型只是第一步，整个链路要想真正跑起来，还需要在 CAD 插件侧做“特征反向标注”，也就是把生成结果中的每个操作步骤映射回可读的命名，比如#特征1_底板、#特征2_支撑柱、#特征3_阵列孔。这样团队协作时能自然理解模型做了哪些改动，而不是面对一坨天书脚本。

我在团队里推过一个工作流：设计师先把客户需求拆成一段结构化描述，填入系统；text-to-cad 生成基础模型；另一名工程师在 CAD 软件里做尺寸标准化和出图；最后由工艺人员做可制造性审查。每个环节通过后留下一条可追溯的记录，哪一步人工改了什么，模型在下次生成时会不会参考这些修改，都一目了然。

这里有一个平台化的坑要提醒：如果你们团队已经深度绑定某一个 CAD 软件，比如 SolidWorks，那在引入 text-to-cad 时首要评估的不是模型多聪明，而是你导出的格式能不能被这个 CAD 的 API 正确读取并保留特征树。STEP 格式虽然在通用性上最好，但有些 CAD 软件对 STEP 的特征识别能力有限，解析出来是一堆“缝合曲面”而不是可编辑特征。针对这种情况，我建议优先考虑直出原生格式的方案，比如 CadQuery 配 FreeCAD 就是同源的，导出后特征保留效果远好于跨平台转换。

5.3 我目前看到的边界与下一步扩展

讲完落地，说说这个方向的边界。就目前的模型水平，text-to-cad 还不适合做“精密模具设计”和“复杂装配体”，它的舒适区集中在简单到中等难度的单件结构件、标准件变型、概念验证模型。如果你想强行用于精密传动系统零件的设计，生成结果在公差、表面粗糙度、热处理要求这些工程标注上完全缺失，还得靠人工补充，反而增加工作量。

扩展方向上，我目前最看好的是“文本到 CAD + 仿真反馈”的闭环。要让生成的模型不只是能看能改，还能直接跑一轮有限元应力分析，然后根据分析结果自动调整壁厚、增加加强筋或改变圆角半径。这样一个闭环一旦跑通，设计师的输入就从一个需求描述升级为一个经过仿真验证的初步设计，那才是真正的效率革命。

另一个我最近在关注的方向是“装配体级 text-to-cad”。现在的模型基本都是“一个描述对应一个零件”，但真实工程往往是“一个描述对应一套机构”。比如那句“做一个由电机、同步带轮、张紧架和底板组成的传动模组”，目前没有任何开源模型能直接生成一套带装配约束关系的多零件模型。谁能先把这层啃下来，谁就能在这个赛道上拉开差距。

我在实际试用中还发现一个很有意思的小现象：对同一句描述，如果不限定生成引擎，不同模型给出的建模策略差异非常大。CadQuery 路线的模型倾向于“先拉伸再打孔”的加工式思路，而隐式场路线的模型则倾向于“直接拟合整体形状”。这个差异背后其实是“制造思维”和“造型思维”的对撞。你选哪个路线，本质上是在选你的产品偏向制造还是偏向设计，这比单纯比较指标分数更有决策意义。

如果让我给一个快速上手的建议，我会说：先用现成的 ZOO 模型跑通“文本到 STEP”的体验，再花半天时间搭一个 CadQuery + LLM 的最小流水线，然后把一个你们团队真实的简单零件拿进去测。不要追求一步到位，先在内部找到一个重复率最高的零件类型，比如垫片、支架、安装板，一旦在这个小池子里跑顺了，再把池子一点点扩大。这个方向真正让人兴奋的不是“模型取代建模师”，而是“把工程师从重复劳动里解放出来，去做真正需要判断力的设计决策”。