text-to-cad：自然语言驱动的参数化CAD建模实践

不用补充平台信息、不用铺垫我直接进入正文内容。1. 整体思路拆解text-to-cad 到底在解决什么问题这两年 AI 生成 3D 内容的赛道异常热闹图像生成、视频生成、点云生成都往前走了一大步。但真正落到机械设计、结构设计、加工制造这些工程场景里你会发现一个尴尬的事实绝大多数 AI 生成的三维模型看起来漂亮实际上没法用。网格模型面数混乱、没有参数约束、倒角圆角随意堆叠导入 CAD 软件之后根本没法编辑更不能直接出工程图。所以当我第一次看到 text-to-cad 这个方向时第一反应是这玩意儿才是工程人真正需要的。text-to-cad 的底层逻辑和常见的 text-to-3D比如生成 NeRF 或高斯泼溅模型完全不同。它不直接生成网格而是让大语言模型理解你的自然语言描述把它翻译成一段程序化建模代码通常是 OpenSCAD 或 CadQuery 这类基于代码的参数化建模脚本然后由代码执行引擎在云端完成渲染和模型生成。这个过程意味着你拿到的不是一个“死模型”而是一棵有完整构建历史的建模树。你可以在事后修改参数、调整尺寸、更换逻辑甚至可以把它当作一个参数化模板反复复用。这套思路对应的工程意义非常直接。传统 CAD 建模的痛点从来不是“画不出来”而是“改起来要命”。设计评审会上老板说“法兰厚度再加 2 毫米、螺栓孔从 6 个改成 8 个”工程师得回到模型里找特征树、改草图、重新约束搞不好还要连带修改下游的圆角和螺纹孔。而 text-to-cad 生成的是代码改参数就是改一个数字改完重新执行脚本新模型立刻出来。这件事在传统建模流程里是“参数化建模高手才能做到的事”在 text-to-cad 流程里变成了“大语言模型帮你把参数化建模做好了”。它的适用人群也很有针对性。第一类是有 CAD 基础但不想把时间耗在重复建模上的工程师描述清楚需求拿到可编辑模型直接进下游装配和出图。第二类是结构设计初期需要快速探索多种方案的产品经理或创客脑子里有个大概形状用自然语言快速验证能不能做、大概什么比例不需要先学会某个 CAD 软件怎么操作。第三类是自动化程度较高的企业研发团队希望把历史设计经验沉淀成可复用的参数化零件库text-to-cad 这种“描述即代码”的方式正好适合批量搭建标准件库。当然也得说清楚边界。这不是“一句话变出一个完整装配体”的魔法。它擅长的是中等复杂度的单零件或部件级建模支架、法兰、外壳、齿轮、轴承座、管路接头、简易箱体之类的。遇到大型装配体、复杂曲面车身、精密模具分型面哪怕生成的代码能跑通建模思路和加工工艺之间的鸿沟也还非常大。所以更准确的定位是text-to-cad 是传统参数化建模流程的 AI 加速器而不是替代品。2. 核心原理与关键技术方案选型2.1 为什么选代码生成路线而不是直接生成网格工程领域对模型格式有近乎苛刻的要求。下游的 CAM 编程、有限元分析、装配干涉检查、出工程图全部要求模型具备精确的边界表示B-Rep。STL 网格在渲染和 3D 打印场景够用但机械加工领域里网格转实体一直是老大难问题转换后的曲面精度和连续性都很难保证。text-to-cad 选择代码生成路线本质上是把“三维几何推理”这个难题转换成了“代码生成”这个相对成熟的问题。大语言模型在代码生成上的能力已经被验证过了不管是函数调用、逻辑循环还是参数传递模型都表现得不错。而 OpenSCAD 和 CadQuery 这类库恰好又是“能用代码表达几何”的典型代表。把三维建模问题映射到代码生成问题上等于用自己最强的能力去解决最难的问题这个选型思路非常务实。我最初接触这个项目时看到的是基于 CodeLlama-7B 微调的底座模型专门在合成 CAD 数据上做了大量训练。用自然语言描述加对应的 OpenSCAD 或 CadQuery 代码作为监督训练语料让模型学会“听描述、写建模代码”的映射关系。推理阶段再接入云端的 GPU 实例和渲染引擎把生成的代码跑起来、渲染出来给你看效果。整个过程像是一个“AI 建模师傅”坐在云端你说要求他写代码写完立刻用真实渲染引擎验证结果。2.2 参数化建模脚本的核心价值可编辑、可复用、可版本管理程序化建模方案里OpenSCAD 和 CadQuery 各自有明确的使用习惯。OpenSCAD 是 CSG构造实体几何思路用基本的 cube、cylinder、sphere 做布尔运算偏“积木式”建模。CadQuery 则是用 Python 写链式操作更接近传统 CAD 软件的拉伸、旋转、倒角、抽壳操作习惯。text-to-cad 类工具的常见做法是同时支持这两种语言让熟悉不同建模习惯的用户都有得选。参数化带来的直接好处是版本管理变得容易了。传统 CAD 文件是二进制格式两个版本之间到底改了哪里用 diff 工具根本看不出来。但代码文件就是纯文本直接进 Git。设计改版、评审反馈、历史回溯全部交给 Git分支策略还能支持同一个零件演化出多个变体每个变体都保留完整决策历史。还有一个容易被忽略的优势模型的可测试性。代码建模意味着你可以在生成后立刻运行几何检查比如抽壳厚度是否一致、孔间距是否满足最小壁厚、布尔运算是否产生退化面。传统 CAD 里这些检查要手动去做而代码流程里全部可以写成自动化测试脚本。对团队协作来说这相当于给三维模型也上了一套“CI/CD”流程。2.3 云端推理与本地运行两条路线的取舍text-to-cad 项目最初做的是云端推理的方式网页对话框里输入描述后台的 GPU 实例跑大模型的推理生成代码之后自动渲染并回传到浏览器。这种模式最大的好处是零部署成本浏览器打开就能用。而且云端渲染更快、更稳定不依赖你本地显卡和 OpenSCAD 环境的配置。但工程实践里我强烈建议你在本地也搭一套环境。原因很现实云端服务往往有会话次数限制、API 调用配额还可能因为网络问题导致生成中断。更重要的是本地跑通之后你可以完全掌控参数调试 prompt、调整采样参数、自己加后处理脚本这些操作在云端黑盒子里做不了。本地方案其实也不复杂。拉一个大语言模型可以是量化过的 CodeLlama 或专门的 text-to-CAD 专用模型装一个 OpenSCAD 命令行工具或 CadQuery 的 Python 包再写一个几十行的脚本串起来就能跑。生成速度慢点但胜在完全可控。在后面的实操环节我会把本地方案的完整配置过程一步步列出来。3. 实操准备与核心参数配置3.1 工具链清单与安装步骤先把我实际测试过的本地工具链列个清单这套配置兼顾了稳定性和上手难度。组件推荐选项说明大语言模型推理框架llama.cpp 或 Ollama轻量CPU 也能跑小模型基础模型CodeLlama-7B / DeepSeek-Coder-6.7B 等代码专用模型代码能力比通用模型强很多建模语言CadQueryPython OpenSCAD二选一或都装渲染预览OpenSCAD 自带渲染可以直接导出 STL、OFF、AMF自动化脚本Python 3.10串起模型推理和建模执行安装过程我直接给命令。Ollama 是最快的方式一条命令装好框架然后拉模型curl -fsSL https://ollama.com/install.sh | sh ollama pull codellama:7b-codeCadQuery 建议用 conda 环境装避免和系统 Python 环境冲突。conda create -n cadquery python3.10 -y conda activate cadquery pip install cadqueryOpenSCAD 在 Ubuntu 下可以直接 apt 安装macOS 下用 Homebrew# Ubuntu / Debian sudo apt install openscad # macOS brew install openscad装完之后验证一下 CadQuery 能正常运行import cadquery as cq result cq.Workplane(XY).box(10, 10, 10) cq.exporters.export(result, test.step)如果这段代码跑通并生成了一个 test.step 文件说明整个建模执行链路没问题。Confirming 这一步很关键很多问题出在模型能推理但建模库环境没配好白耽误时间。3.2 推理参数怎么调才出好结果用大语言模型做代码生成采样参数对结果质量影响极大。这个项目在推理阶段的默认参数是 temperature0.1、top_p0.1看起来参数值很小这里面有明确的工程考量。代码生成任务和创意写作不同代码要么能跑要么不能跑语法错误、语义错误、发散性生成都会直接导致建模失败。temperature 设低意味着模型每次输出的概率分布更尖锐倾向于选最高概率的 token这样代码风格更稳定、错误更少。top_p 设低进一步缩小候选 token 范围去掉长尾的“创意选项”。我自己实测temperature 超过 0.3 之后生成的代码开始出现一些“看起来很合理但实际会报错”的问题比如函数名写错、参数顺序颠倒、直接调用不存在的 API。所以如果你在本地跑自己的推理脚本默认参数不要动先按 0.1 试。另外也别忽略 seed 参数。固定 seed意味着相同输入会得到相同输出这在调试 prompt 时非常有用。你可以先设 seed 固定跑通一个比较满意的生成结果后把整个配置固化下来之后再针对不同零件描述做微调。如果不固定 seed每次生成结果都有随机性调试时你不知道改的是 prompt 的效果还是随机因素造成的这个坑很隐蔽。一个额外的技巧把 max tokens 设到 2048。零件描述复杂时模型需要输出较长的代码约束太紧会因为截断导致不完整代码直接渲染失败。2048 基本覆盖了中等复杂度零件的代码长度。4. 实操过程从一句话到可加工模型的完整跑通4.1 写一个能用的建模描述这一步的 prompt 质量直接决定生成效果。但“质量高”的标准和很多人想的不一样——不是句子越长越好而是约束越明确越好。我试过非常多描述总结出几条实操经验必须明确基本形状和比例关系例如“一个底座 100 毫米长、60 毫米宽、10 毫米厚四角各有一个直径 6 毫米的安装孔孔位距边缘 10 毫米”。不要出现含糊的相对描述“一个好看的外壳”这种话模型无法理解。建议给出几何约束和空间关系“顶部开一个直径 30 毫米的圆孔圆心距前端面 25 毫米”。加工相关的特征要说清楚圆角半径、倒角尺寸、螺纹孔规格、抽壳厚度。一次生成一个零件不要幻想着描述一个带六个零件的装配体模型。复杂需求拆成多次生成再单独做装配。举个实际案例。我想生成一个带法兰的圆柱管接头我的描述是生成一个 CadQuery 零件法兰底座为外径 80 毫米、内径 30 毫米的圆环厚度 10 毫米法兰上均布 4 个直径 8 毫米的通孔螺栓孔中心圆直径 60 毫米圆环上方竖直伸出外径 40 毫米、壁厚 3 毫米的圆管长度 60 毫米法兰底面和圆管末端均做 1 毫米倒角。把这段话交给模型后它会在 CadQuery 里生成一段类似这样的代码结构import cadquery as cq flange ( cq.Workplane(XY) .circle(80 / 2) .circle(30 / 2) .extrude(10) .faces(Z) .workplane() .circle(40 / 2) .circle((40 - 2 * 3) / 2) .extrude(60) ) flange ( flange.faces(Z) .workplane() .hole(8) )实际生成的代码会包含完整的位置计算。CadQuery 的绘图逻辑是从二维草图拉伸成三维特征孔位可以先在法兰面上用 polarArray 实现均布flange ( cq.Workplane(XY) .circle(80 / 2) .circle(30 / 2) .extrude(10) .faces(Z) .workplane() .pushPoints([(60 / 2, 0), (0, 60 / 2), (-60 / 2, 0), (0, -60 / 2)]) .hole(8) )这个过程中模型的角色更像是一个“翻译器”你给出工程语言它帮你转换成建模语言。如果生成的代码存在语法错误或者实际渲染结果和描述明显不符通常说明你在描述里引入了歧义。比如“上方”“后面”“中间”这类相对方位词在三维空间里可以有很多种解释。改成“从法兰顶面沿 Z 轴正方向延伸”这种明确指令成功率会显著提升。4.2 渲染、导出与结果验证代码生成后第一步是渲染成可交互的三维预览。OpenSCAD 自带的渲染器可以直接跑openscad -o flange.stl flange.scadCadQuery 这边导出方式更丰富cq.exporters.export(flange, flange.step) # 用于CAD互操作 cq.exporters.export(flange, flange.stl) # 用于3D打印/可视化我建议优先导出 STEP 格式。STEP 是工程领域通用格式导入 SolidWorks、Fusion 360、FreeCAD 都没有问题保留了精确几何面。STL 虽然看起来方便但只能用于网格场景后续要改尺寸还得回到代码改。拿到模型文件之后干的第一件事不是“哇好漂亮”而是做几何尺寸验证。最朴素的方法是用 FreeCAD 或 Fusion 360 的测量工具检查关键尺寸是否符合描述。但更高效的做法是写自动化验证脚本。CadQuery 的优势在这里体现得很充分你可以直接用代码查询几何体的体积和包围盒bbox flange.val().BoundingBox() print(长度:, bbox.xlen) print(宽度:, bbox.ylen) print(高度:, bbox.zlen)再算一下核心特征尺寸是不是和设计意图一致。比如这个法兰管接头的管内径 40 - 2 × 3 34 毫米程序直接查内孔直径# 查询顶面圆心处的内径用截面法验证 cut flange.faces(Z).workplane().circle(34 / 2).cutBlind(-1)甚至可以做一个简单的体积比对圆柱管 3.14 × (20² - 17²) × 60 ≈ 2091 立方毫米法兰片 3.14 × (40² - 15²) × 10 ≈ 42810 立方毫米加起来大约 44901 立方毫米。如果 CadQuery 查出来的体积和这个理论值差得太远说明建模代码有问题。这种“代码算体积”的方式是程序化建模特有的优势传统 CAD 里你得手动点测量工具。4.3 prompt 迭代一个真实的调优案例我第一次用这套流程生成一个“U 型支架”时翻车了。描述里写的是“一个 U 型支架两侧立板厚度 5 毫米底部横板长度 80 毫米、宽度 50 毫米、厚度 5 毫米两侧立板高度 40 毫米立板顶部各有一个直径 10 毫米的安装孔”。模型生成的代码跑通了但渲染出来的形状不是 U 型是一个底板加一个侧板另一侧没有了。原因是我用了“两侧”这个描述模型没有理解成“沿宽度方向的两侧”而是把“两侧立板”理解成了两次重复添加同一位置的特征。调整策略是把几何定义改成“以 YZ 平面对称生成两块立板间距 80 毫米”。第二次生成的结果立刻正确了。这让我意识到一个重要的原则你写的不是“给 CAD 软件的指令”而是“给大语言模型的约束描述”。它需要知道几何元素的位置关系、坐标系方向、对称性等约束信息才能准确翻译成建模代码。后来我把自己的 prompt 模板固化成了几个模块基础形状与位置原点尺寸参数全用数字标注特征操作顺序先拉伸、再开孔、后倒角对称性、阵列等几何约束导出格式目标每次生成后先看代码能否跑通再验证关键尺寸最后才渲染预览。整套流程下来成功率从最初的不到五成提升到了八成以上。5. 本地推理链路搭建把云端服务搬到自己电脑上5.1 最小可用脚本的完整实现如果你不想依赖云端服务自己搭一条 text-to-cad 推理链路是可行的。我用 Python 写了一个最小可用的脚本链路结构非常清晰调 Ollama 的 API 让模型生成代码然后把代码字符串传入 OpenSCAD 执行渲染。import urllib.request import json import subprocess import tempfile import os def generate_scad(prompt: str, model: str codellama:7b-code) - str: payload { model: model, prompt: f[INST] 你是CAD建模助手。根据下面的描述生成完整的OpenSCAD代码。 f只返回代码不要解释。\n\n{prompt} [/INST], stream: False, options: { temperature: 0.1, top_p: 0.1, max_tokens: 2048, seed: 42 } } req urllib.request.Request( http://localhost:11434/api/generate, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json} ) with urllib.request.urlopen(req) as resp: result json.loads(resp.read().decode(utf-8)) return result[response] def scad_to_stl(scad_code: str) - str: with tempfile.NamedTemporaryFile(suffix.scad, deleteFalse, modew) as f: f.write(scad_code) scad_path f.name stl_path scad_path.replace(.scad, .stl) subprocess.run([openscad, -o, stl_path, scad_path], checkTrue) return stl_path if __name__ __main__: prompt 生成一个50毫米长的圆柱销直径10毫米两端各倒角1毫米。 scad_code generate_scad(prompt) print(生成的OpenSCAD代码\n, scad_code) stl_path scad_to_stl(scad_code) print(STL文件生成于, stl_path)这个脚本是最小骨架实际使用中你可以扩展检查生成的代码里有没有明显语法错误、自动清理模型输出的 markdown 标记包裹、把渲染结果自动上传到本地 Web 查看器。特别注意一个问题模型输出有时会带上代码块标记scad需要你解析时剥掉。这个细节看起来小但往往会卡住不少人OpenSCAD 一打开这种文件直接报语法错误。5.2 模型选型和显存/内存规划本地跑 text-to-cad模型选型基本决定了体验上限。我自己实测过几条路线模型参数量量化级别内存/显存效果CodeLlama-7B7BQ4_K_M约 4.5GB能出可运行代码复杂逻辑易出错DeepSeek-Coder-6.7B6.7BQ4_K_M约 4GB中文理解更好代码质量不错CodeLlama-13B13BQ5_K_M约 8GB明显更稳推荐DeepSeek-Coder-33B33BQ4_K_M约 20GB效果最好普通电脑跑不动实际选择上如果电脑只有 16G 统一内存或者 8G 显存优先用 7B 级模型模型能跑起来永远比模型效果好重要。因为 text-to-cad 的瓶颈往往不在模型能力而在 prompt 是否清晰。描述清楚了7B 模型也能出好结果。反过来描述模糊33B 模型照样给你一堆能跑但不对的废代码。内存规划方面要留足余量。模型加载之后推理过程中内存占用比加载时还要高 20%-30%。建议在满足模型最低要求的基础上再留 4GB 以上空间给操作系统和渲染程序不然容易内存交换导致卡死。5.3 OpenSCAD 和 CadQuery 怎么选投影到实际使用场景两条路径各有优势。OpenSCAD 的文件格式是文本上手直观生态里现成的开源零件库非常多。CadQuery 则胜在 Python 生态和自动化工具链整合更顺畅尤其在需要进行几何参数化计算时Python 的灵活性高出很多。我的做法是快速验证概念用 OpenSCAD因为它的渲染预览速度快布尔运算直观。一旦确定方案需要往工程下游走立刻改用 CadQuery 重建因为后续可以接 STEP 导出、接 FreeCAD 再编辑、接 FEA 前处理。两条路都用没必要只选一条。6. 实际过程中踩过的坑与排查经验6.1 高频问题速查表整理一下我在实际使用中高频遇到的问题做成速查表症状原因解决办法生成的代码一直报语法错误温度参数过高模型发散把 temperature 降到 0.1 并固定 seed模型输出带代码块包裹指令里没要求只输出代码在 prompt 里明确“只返回代码不要解释”渲染出来是空的/缺少特征几何位置描述有歧义改用明确坐标系方向和尺寸约束零件几何“看着像”但尺寸不对没有验证尺寸用 CadQuery 查询 BoundingBox 和体积孔位不在法兰上草图平面选错了面确认工作平面定位.workplane(offset...)本地推理巨慢底层用的通用模型而非代码专用模型换 Q4 量化的代码专用模型布尔运算后模型破碎两个几何体位置刚好共面给特征之间加 0.01mm 的偏移量关于布尔运算的问题这个是我踩得最深的一个坑。OpenSCAD 里两个几何体如果刚好共面差值运算经常产生退化面或微小碎面渲染出来感觉像是“被咬掉一块”。比如法兰和圆柱接头连接处如果建模时不小心让两者共面渲染出来就破相。解决办法很简单让圆柱稍微“插进去”0.01 毫米保证几何体重叠足够发生实体运算。这类问题在传统 CAD 里也存在但在代码建模里因为看不到交互预览更容易漏掉只能靠渲染后仔细检查。6.2 提示词设计隐藏的技巧经验积累下来我发现最影响成功率的是“预先把几何语义写清楚”。下面几类是我反复用且效果不错的结构化描述模板底板类零件写明底板长宽高及圆角孔位均布方式、孔径及沉头尺寸是否有腰形槽及方向。回转体类零件写明旋转轮廓二维草图的关键点坐标或者用外径内径壁厚的阶跃描述内部是否有台阶孔两端倒角大小。钣金类零件写明板材厚度、折弯半径、折弯角度、展开状态下各面尺寸孔位相对折弯线的偏移。另外一个特别实用的技巧把“参考”那层含义拆分成“必须”和“可选”。比如“底座必须有四个通孔”是刚性约束“孔可以做沉头”是柔性约束。模型对这种强弱约束的表达响应很敏感写清楚可以大幅减少后续返工。6.3 生成失败的排查顺序如果生成的模型和预期不符我的排查顺序是固定的先确认提示词里的每个尺寸都写了数字并且单位统一毫米就是毫米别混英制公制第二步检查代码里的坐标系假设Z 轴是不是自己以为的“上方”第三步检查布尔操作顺序有没有先切后拉伸导致特征丢失最后才考虑模型能力不足换更大模型或增加描述细节。按照这个顺序排查基本能把九成以上的失败原因定位到 prompt 不精确或描述歧义上。这其实也反向印证了 text-to-cad 当前阶段的核心局限性它不是一个能读懂你“潜台词”的系统而是一个极其依赖输入质量的“纪律型工具”。7. 后续扩展方向把 text-to-cad 接进自己的生产流程7.1 批量生成标准件库当你验证了单条链路的稳定性以后我首要推荐的扩展方向是把重复描述模板化利用脚本批量跑标准件库。比如弹簧垫片、六角螺栓、轴承盖这类高频标准件写成模板参数循环输入给推理模型一次性生成几十个变体。配合 Git 管理整个标准件库的版本演进和变更记录都留下来了比手工建模再存文件的方式不知道清晰多少倍。这个做法的核心收益是“模型参数和建模逻辑分离”。你要生成一个 M6 和 M8 的垫片传统 CAD 流程要开两个文件分别画。text-to-cad 流程只需要准备一份参数化描述模板M6 和 M8 只是模板里替换直径值。模型生成的是可变参数的代码最后沉淀下来的是一套有完整逻辑的可复用代码资产。7.2 与参数化设计体系和装配流程对接再进一步是把 text-to-cad 生成的零件统一纳入现有参数化设计体系。我目前的做法是所有生成的 CadQuery 零件统一输出 STEP 格式然后在 FreeCAD 里建立装配约束。生成代码阶段只是完成了“零件造型”装配关系和运动约束仍然需要在 CAD 工具里完成这个环节 AI 暂时还替代不了。不过好消息是CadQuery 生成的零件保留了特征树导入 FreeCAD 之后可以继续编辑不会变成死模型。这意味着你能把“AI 生成建模代码”和“传统参数化装配设计”组合起来扬长避短。我现在做机械结构方案时标准件和外购件直接走 text-to-cad 批量生成非标的核心机构件仍然手工建模效率和可编辑性两头都占。7.3 为团队搭建统一能力平台如果你是团队里负责工具链建设的人我的建议是不要直接铺开给所有人用云端服务而是先自建一条本地推理链路把 prompt 模板沉淀成团队专属的“设计描述规范”再配上一套自动验证脚本。让团队里的成员不需要懂 AI 也能按照规范写描述自动化地生成、验证、归档零件代码。等积累足够多的零件代码资产后它可以反过来微调一个私有模型专门适配你们团队的设计语言和零件族风格。这个方向做深了是真正的量产级能力远远超越“拿 AI 玩一玩”的阶段。我个人的体会是text-to-cad 这类工具最有价值的时刻不是第一次成功生成零件的时候而是当你发现它能稳定复用、能嵌进流程、能替代掉重复劳动的那些时刻。第一次跑通只是起点把它变成你工具链里可靠的一环才是真正的回报区。这一路上最大的坑就是把 AI 当成“什么都能画”的神笔马良实际它更像是一个需要你写清楚需求文档的外包工程师——需求越规范交付越稳定。把精力花在建好 prompt 模板和验证链路上回报比调来调去尝试各种神秘参数要高得多。