1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 “text-to-cad” 这个说法是在一个做机械设计的朋友那里。他当时正对着屏幕上一堆草图发愁嘴里念叨着“要是能直接打一行字就出模型谁还愿意一根线一根线去画。” 这句话其实点到了很多做产品设计、工业建模、甚至三维打印的人心里最痒的那个地方——用自然语言直接生成可编辑的 CAD 模型。text-to-cad拆开来看就是 text 到 CAD。text 是自然语言描述比如“一个边长 50 毫米、壁厚 3 毫米、带四个 M4 安装孔的正方体外壳”CAD 则是计算机辅助设计模型通常指参数化实体、网格或者可继续编辑的工程文件。它要解决的问题很直接把人类脑子里的几何意图用最省事的方式翻译成机器能理解的三维结构。传统路径是打开建模软件画草图、拉伸、打孔、倒角一套流程下来简单零件也要十几分钟。text-to-cad 想做的是把这段重复劳动压缩成一句话。适合关注这个方向的人其实比想象中多。做快速原型的产品经理需要频繁验证外观和装配关系做三维打印的玩家想批量生成小配件但不想学复杂建模做机器人仿真的工程师需要大量结构相似但尺寸不同的零件还有做教育演示的老师想让学生用文字描述就能看到三维结果。这些人未必都是 CAD 高手但都有“把想法快速变成三维实体”的刚需。我实测下来目前 text-to-cad 并不是一个单一软件而是一类技术路线的统称。有的走代码生成路线把文字转成 OpenSCAD 或 CadQuery 脚本有的走大模型直接生成网格路线输出 STL 或 OBJ还有的走参数化模板匹配路线从预置库里找最接近的模型再微调。每条路线的成熟度、可控性和输出质量差别很大后面会逐一拆开讲。注意text-to-cad 目前还远没到“一句话出完美工程图”的程度。它更像一个高级草稿生成器能帮你跳过从零开始的阶段但尺寸校验、公差配合、可制造性检查仍然需要人工介入。2. 三条主流技术路线拆解与选型逻辑2.1 代码生成路线文字转 OpenSCAD 或 CadQuery这是目前最可控、最适合工程场景的一条路。核心思路是让大语言模型把自然语言翻译成参数化建模脚本再由脚本引擎渲染出三维模型。OpenSCAD 和 CadQuery 是两个最常被选中的目标语言。OpenSCAD 的优势是语法极简本质上是“描述几何体的编程语言”。比如要一个带孔方块代码大概长这样difference() { cube([50, 50, 20], centertrue); translate([0, 0, 0]) cylinder(h25, r2.5, centertrue, $fn64); }这段代码的意思是先做一个 50x50x20 的方块然后在中心挖一个半径 2.5、高度 25 的圆柱孔。大模型要做的就是把“边长 50、厚 20、中心有一个直径 5 的通孔方块”这样的描述映射成上面的代码结构。CadQuery 则更偏向工程化基于 Python能输出 STEP 这种标准工程格式方便后续导入 SolidWorks 或 Fusion 360 继续编辑。它的代码风格是这样的import cadquery as cq result ( cq.Workplane(XY) .box(50, 50, 20) .faces(Z) .workplane() .hole(5) )选这条路线的原因很实在生成结果可复现、可参数化、可版本管理。你拿到一段脚本改几个数字就能得到新零件特别适合做系列化设计。而且脚本是纯文本方便用 Git 管理团队协作时 diff 一目了然。但这条路线也有门槛。大模型生成的脚本经常有语法错误比如括号不匹配、变量未定义、坐标系搞反。我试过让模型生成一个“带四个角孔的板”结果它把孔打在了侧面而不是顶面原因就是 workplane 选错了。所以代码生成路线必须配一个“执行-报错-修正”的闭环不能指望一次成型。2.2 网格直接生成路线文字转 STL 或 OBJ这条路线更接近“AI 画画”的思路。用大规模三维数据集训练扩散模型或自回归模型输入文字描述直接输出三角网格。代表思路包括基于点云扩散、基于隐式场、基于体素的方法。它的最大优点是形状自由度高。你描述一个“流线型、带有机曲面、像水滴一样的支架”代码生成路线很难用简单几何体拼出来但网格生成模型可以输出一个视觉上很接近的曲面。做概念设计、角色道具、艺术造型时这条路很吸引人。问题也同样明显。第一尺寸精度不可控。你说“长 100 毫米”它生成出来的模型可能实际尺寸是 97.3 毫米而且没有参数可以调。第二拓扑质量参差不齐。三角面片可能自交、法线翻转、存在非流形边直接拿去打印会切片失败。第三不可编辑。你没法像参数化模型那样改一个孔的位置只能重新生成。我个人的判断是网格路线适合“看形状”的阶段不适合“做零件”的阶段。如果你只是想要一个视觉参考或者做渲染图它可以省很多事。但如果你要装配、要受力、要加工还是得回到参数化路线。2.3 模板匹配与参数填充路线这条路线介于前两者之间。系统预置一批参数化模板比如“法兰盘”“支架”“外壳”“齿轮”“铰链”。用户输入文字后模型先做意图识别判断属于哪类零件再抽取关键尺寸参数最后把参数填入模板生成模型。它的优势是输出质量稳定、尺寸精确、生成速度快。因为模板本身是人工校验过的几何拓扑没问题参数一填就能用。对于标准件、常用结构这条路最实用。局限在于覆盖范围受模板库限制。你描述一个模板库里没有的形状系统就无能为力或者只能强行套一个不合适的模板。所以这条路适合做垂直场景比如“只做 3D 打印常用小配件”而不是通用建模。下面这张表可以帮你快速判断该选哪条路路线输出格式尺寸精度可编辑性形状自由度适合场景代码生成SCAD/STEP/Python高高中工程零件、系列化设计网格生成STL/OBJ低低高概念造型、渲染展示模板匹配STEP/STL高中低标准件、垂直场景实操心得如果你刚开始尝试 text-to-cad建议从代码生成路线入手。它的反馈最直接出错也最容易定位。网格路线看起来酷但调试成本高容易打击信心。3. 核心环节实操从文字到可打印模型的完整流程3.1 提示词怎么写才不容易翻车很多人以为 text-to-cad 的提示词就是随便说一句话其实不然。自然语言有大量歧义而几何建模对歧义零容忍。“一个圆角盒子”这句话圆角半径是多少盒子是空心还是实心圆角加在哪些边这些不写清楚模型只能猜猜错概率极高。我总结了一个五要素提示词结构实测能显著提升首次生成成功率主体形状方块、圆柱、球体、锥体、拉伸体、旋转体或者组合描述。关键尺寸长宽高、直径、半径、壁厚单位统一用毫米。特征细节孔、槽、倒角、圆角、凸台、螺纹说明位置和数量。空间关系对称、居中、阵列、同心、垂直、平行。输出要求格式STEP/STL/SCAD、是否需要参数化、是否需要可打印。举个例子不要写“做一个安装板”而要写“一个长 120 毫米、宽 80 毫米、厚 6 毫米的矩形安装板四角各有一个直径 4.5 毫米的通孔孔中心距边缘 10 毫米所有棱边倒 1 毫米圆角输出 STEP 格式尺寸参数化。”这样一段描述代码生成模型基本能一次写出可运行的 CadQuery 脚本。我试过用五要素结构对比随意描述首次成功率从不到三成提升到七成以上。3.2 代码生成路线的执行闭环搭建光有提示词还不够你需要一个能自动执行、捕获错误、反馈修正的闭环。我自己的做法是用 Python 写一个轻量调度脚本流程如下接收用户文字描述。调用大模型生成 CadQuery 或 OpenSCAD 代码。在沙箱环境中执行代码捕获标准输出和异常。如果执行失败把错误信息拼回提示词让模型重新生成。最多重试 3 次仍失败则返回错误报告。成功后导出 STEP 和 STL 两种格式。关键点在于错误信息要完整回传。比如 CadQuery 报 “ValueError: Null topology”你要把整段 traceback 都喂给模型它才能定位到是哪一步的 workplane 或布尔运算出了问题。只给一句“出错了”模型基本修不对。另外执行环境一定要隔离。大模型生成的代码可能包含死循环、超大内存分配、文件系统操作。用 Docker 容器或者子进程加超时限制避免把主环境搞崩。我一般设置单次执行超时 30 秒内存上限 2GB足够跑大多数零件脚本。3.3 尺寸校验与可打印性检查模型生成出来只是第一步能不能用是另一回事。我习惯在导出后加两道自动检查第一道是包围盒校验。读取生成模型的 bounding box和提示词里的尺寸对比。如果偏差超过 5%就标记为可疑。比如你说长 100 毫米结果模型长 103 毫米可能是某处圆角或倒角把外形撑大了需要人工确认。第二道是壁厚检查。对于要 3D 打印的模型最小壁厚不能低于喷嘴直径的 1.5 倍。0.4 毫米喷嘴对应最小 0.6 毫米壁厚低于这个值打印出来会破。可以用 trimesh 库做射线检测估算最薄处的厚度。import trimesh mesh trimesh.load(output.stl) # 检查包围盒 print(Bounding box:, mesh.bounds) # 检查是否水密 print(Is watertight:, mesh.is_watertight) # 检查体积 print(Volume:, mesh.volume)如果is_watertight返回 False说明网格有破洞或非流形边切片软件可能报错。这时候要么回到代码生成阶段调整布尔运算顺序要么用网格修复工具补洞。注意STEP 格式是实体模型天然水密STL 是网格模型才需要检查水密性。如果你走代码生成路线优先导出 STEP省去很多麻烦。4. 常见问题与排查技巧实录4.1 模型生成失败或形状完全不对这是最常见的问题原因通常出在提示词歧义或模型能力边界。排查顺序建议如下先看提示词有没有矛盾。比如“一个空心方块壁厚 10 毫米外形尺寸 15x15x15”那内腔只剩 5x5x5如果还要求“内腔放一个直径 8 的球”就物理上不可能。模型会强行生成一个错误结果而不是报错。再看坐标系描述是否清晰。“在顶面打孔”和“在上表面打孔”在代码生成时可能被理解成不同 workplane。统一用“Z 方向面”“XY 平面”这类明确表述。最后看模型是否超出训练分布。特别复杂的有机曲面、大量阵列特征、非标准螺纹代码生成模型容易胡编。这时候要么拆成多个简单步骤要么换网格生成路线。我踩过的一个坑是让模型生成“一个渐开线齿轮”它直接编了一个近似圆弧的轮廓齿形完全不对。后来改成“一个 20 齿、模数 2、压力角 20 度的直齿轮”并指定用 CadQuery 的 gear 扩展库才得到可用结果。专业特征要用专业术语不要用日常比喻。4.2 生成速度慢或频繁超时text-to-cad 的耗时主要花在大模型推理和代码执行两步。如果走本地模型推理时间可能从几秒到几十秒不等走云端 API 则受网络和排队影响。优化手段有几个一是缓存常用模板对于重复出现的标准结构直接查缓存不重新生成二是限制生成长度代码生成不需要长篇大论设置 max tokens 在 1024 以内通常够用三是并行执行如果批量生成多个零件可以用多进程同时跑但注意每个进程独立沙箱。代码执行超时多半是布尔运算过于复杂。比如一个模型里做了几十次差集和并集CadQuery 的 OpenCASCADE 内核会非常慢。解决办法是合并操作能一次布尔运算完成的不要拆成多次。另外圆角操作尽量放在最后做因为圆角会显著增加拓扑复杂度。4.3 导出文件在切片软件里报错STL 导入切片软件报错九成是网格问题。常见错误包括非流形边、法线不一致、自交面、零面积三角形。排查可以用 trimesh 或 MeshLab 先做一轮清理。报错类型可能原因处理方式非流形边布尔运算残留用 netfabb 或 trimesh 修复法线翻转生成时朝向错误统一重算法线自交面曲面生成精度不足提高网格密度或换参数化路线零面积面退化几何删除退化面并补洞如果走的是代码生成路线导出 STEP 再转 STL 通常能避免大部分网格问题。因为 STEP 是 B-Rep 实体转网格时由内核保证拓扑正确。我现在的习惯是工程用途一律 STEP展示用途才用 STL。4.4 参数化修改后模型崩溃参数化是代码生成路线的核心优势但改参数导致模型崩溃也很常见。比如你把孔直径从 5 改成 8结果孔壁和外形面相交了布尔运算直接失败。预防办法是在脚本里加约束检查。比如hole_d 8 wall 3 outer_d 20 assert hole_d 2 * wall outer_d, 孔太大壁厚不足这样在生成前就能发现参数不合理而不是等到执行时报错。另外关键尺寸尽量用变量表达不要硬编码数字。这样改一个地方所有相关特征自动联动。实操心得我习惯在 CadQuery 脚本开头集中定义所有参数后面全部引用变量。这样不仅好改而且方便做参数扫描批量生成不同尺寸的系列零件。5. 工具链选型与本地环境搭建建议5.1 大模型选择本地还是云端如果你对数据隐私不敏感云端 API 是最省事的选择推理质量也通常更好。但如果你的设计涉及未公开产品或者你想离线使用本地模型是必须的。本地跑 text-to-cad对硬件有一定要求。7B 参数级别的代码生成模型量化后大约需要 6-8GB 显存13B 级别需要 12-16GB再大就得上多卡或 CPU 推理速度会明显下降。我实测下来7B 量化模型在消费级显卡上就能跑出可用结果虽然偶尔语法出错但配合重试闭环基本够用。选模型时重点看它在代码生成任务上的表现而不是通用对话能力。有些模型聊天很流畅但写 CadQuery 脚本一塌糊涂。可以先用几十条标准提示词做一轮评测看首次执行成功率。5.2 执行引擎与依赖管理OpenSCAD 和 CadQuery 是两条最成熟的执行引擎。OpenSCAD 安装简单命令行调用方便适合快速验证。CadQuery 基于 Python依赖 OpenCASCADE安装稍麻烦但输出格式更工程化。我建议用 conda 或 venv 隔离环境避免和系统 Python 冲突。CadQuery 的安装命令大致如下conda create -n cadquery python3.10 conda activate cadquery conda install -c conda-forge -c cadquery cadquerymasterOpenSCAD 则直接下载对应平台的安装包把可执行文件路径加入环境变量即可。命令行调用方式openscad -o output.stl input.scad如果你要同时支持两种引擎可以在调度层做路由简单几何走 OpenSCAD复杂工程件走 CadQuery。5.3 版本管理与协作text-to-cad 的产出物包括提示词、生成脚本、模型文件三部分。提示词和脚本是纯文本用 Git 管理最合适。模型文件是二进制不建议直接入库可以用 Git LFS 或者只保留生成脚本需要时重新生成。我自己的仓库结构是这样的project/ prompts/ # 提示词模板 scripts/ # 生成的 CadQuery/OpenSCAD 脚本 outputs/ # 导出的 STEP/STLgitignore checks/ # 校验脚本 README.md这样每次修改提示词或脚本都有记录出问题可以回滚。团队协作时别人拉下代码就能复现同样的模型不需要传大文件。6. 影响范围与能力边界哪些场景已经能用哪些还早6.1 已经比较成熟的场景标准结构件快速生成是目前最稳的场景。法兰、支架、外壳、安装板、简单齿轮、皮带轮这些形状规则、参数明确、模板丰富的零件text-to-cad 已经能显著提效。我实测一个带孔安装板从写提示词到导出 STEP熟练后不到两分钟比手动建模快五到十倍。批量系列化设计也很适合。比如你需要 20 个外形相同但长度不同的支架用参数化脚本改一个变量就能全部生成不需要一个个画。这在做产品系列、实验夹具、教学套件时特别有用。三维打印前的快速验证同样受益。很多打印玩家不需要精确工程图只要形状对、尺寸大致对就行。text-to-cad 生成的网格模型直接切片打印省去学建模软件的时间。6.2 还需要人工深度介入的场景复杂装配体目前基本做不了。多个零件之间的配合关系、运动约束、公差链自然语言很难描述清楚模型也缺乏全局装配推理能力。你可以生成单个零件但装配还得手动做。高精度配合面也不可靠。比如轴承孔、导轨槽、密封面这些对尺寸公差和表面粗糙度有严格要求text-to-cad 生成的模型只能算毛坯必须人工精修。有机曲面与自由造型虽然网格路线能生成但质量不稳定而且不可编辑。做概念图可以做产品不行。可制造性设计更是空白。模型不知道你的加工方式是 CNC、注塑还是打印不会自动加脱模斜度、圆角、加强筋。这些仍然依赖工程师经验。我的判断是text-to-cad 在未来几年会成为一个高效的“第一稿工具”但不会取代 CAD 工程师。它把重复劳动自动化让人专注于真正需要判断力的部分——功能定义、装配逻辑、制造约束。7. 我踩过的坑与最后分享的几个技巧第一个坑是过度信任模型输出的尺寸。早期我直接拿生成模型去打印结果装配时发现孔位偏了 0.5 毫米整批零件报废。后来养成习惯任何关键尺寸都用卡尺量一遍或者用切片软件的测量工具核对。text-to-cad 给的是“名义尺寸”实际几何可能有微小偏差。第二个坑是提示词里用了模糊形容词。“大一点”“薄一些”“差不多”这类词模型只能猜。现在我一律用具体数字实在不确定就先给一个估计值生成后再调参数。第三个坑是忽略单位。有些模型默认单位是英寸有些是毫米混用会导致尺寸差 25.4 倍。我在提示词里永远写明“单位毫米”脚本里也统一用毫米。最后分享一个提效技巧建立自己的提示词片段库。把常用的结构描述存成模板比如“四角安装孔”“中心通孔”“边缘倒角”“阵列散热槽”需要时拼装组合。这样写提示词从每次十分钟缩短到一两分钟而且质量稳定。还有一个技巧是用截图反推提示词。如果你看到一个想要的形状但不知道怎么描述可以先让多模态模型看图生成文字描述再把描述喂给 text-to-cad。虽然多一道转换但比凭空想词容易得多。这个方向变化很快工具和模型几个月就更新一轮。我的建议是保持关注但不要追新追到影响干活。先把一条路线跑通形成自己的提示词库和校验流程比什么都重要。