从一句话到三维模型text-to-cad 技术拆解与实战复盘这两年AI 生成内容的战火已经从文生图、文生视频烧到了工程建模领域。text-to-cad 这个方向简单说就是输入一句话比如“一个带有四个圆孔的矩形法兰盘”系统直接给你吐出一个可编辑、可制造的三维 CAD 模型而不是一张渲染图。这个东西之所以值得关注是因为它和 Midjourney 那类生成像素图的技术路线完全不一样——它生成的是真正的几何实体带参数、带特征树能直接进 CAM 编程或者 3D 打印切片软件。这篇文章我打算从方案选型、技术路径、实操流程和踩坑记录几个维度把我在这块摸索的经验完整写下来给正在做相关开发的工程师、想用 AI 辅助建模的机械设计师还有准备入坑这个方向的算法同学一些参考。先说结论text-to-cad 目前的成熟落地形态不是让它像 ChatGPT 那样直接“想象”一个模型出来而是走“大语言模型理解意图 程序化建模代码生成”的路子让 LLM 输出 OpenSCAD、CadQuery 或者 Python 脚本再由参数化内核去执行生成模型。这么做的好处是可以保证模型的精确性、可编辑性和可制造性而这恰恰是工业场景的底线。1. 内容整体设计与思路拆解1.1 为什么 text-to-cad 不能走文生图的套路我见过不少刚接触这个方向的人第一反应都是“这东西不就是 3D 版的 Stable Diffusion 吗”。这个直觉可以理解但实际工程落地时会撞上一堵厚墙文生图的评价标准是“像不像”“美不美”而 CAD 模型的评价标准是“对不对”“能不能造”。扩散模型也好、NeRF 也好本质是在学习一个从噪声到数据的分布映射生成的是离散的网格Mesh或者隐式场SDF。这种表示方式存在三个致命问题不可编辑生成的网格是一堆三角形面片的集合没有特征树、没有约束关系。设计师想改个孔径抱歉你得把整个网格重新生成一遍。拓扑不稳定网格模型经常出现破面、非流形边、自相交这类几何缺陷拉到切片软件里直接报错。不满足制造语义CAD 模型背后是有设计意图的比如“这个孔是通孔还是盲孔”“这两个面是平行还是垂直”这些语义信息在网格表示里彻底丢失了。所以现在行业里真正能用的 text-to-cad 系统几乎全部绕开了“直接生成几何”这个思路转而让大语言模型去写程序化建模代码。模型生成的是一段 CAD 脚本脚本执行后由 CAD 内核自动构建出精确的实体模型。这种方式下设计师拿到的不只是一个结果而是一棵完整的建模历史树改参数、改约束、改特征全部可行。说白了LLM 在这里的角色不是“建模师”而是“编程员”——它用自然语言理解你的需求然后把需求翻译成一段可执行的建模指令序列。1.2 方案选型的决策逻辑我为什么选了 CadQuery 这条技术路线现在主流的程序化建模语言有 OpenSCAD、CadQuery、Build123d还有工业界的 ANSYS DesignModeler 脚本化接口等。我在实际项目中对比试用了这一圈最后把主力方向定在了 CadQuery核心考量有四点。第一CadQuery 的建模范式符合机械设计的直觉。它用的是构建实体几何CSG加工作平面Workplane的组合方式你可以理解为“在一块虚拟钢板上先拉伸出一个主体再在工作平面上打孔、开槽、倒角”。这种“面向特征”的建模方式和 SolidWorks 里的操作习惯非常接近LLM 生成这类代码时语义对齐成本低。第二CadQuery 基于 Python。这意味着和当前整个 AI 生态无缝衔接不管是调用 LangChain 做任务编排还是用 FastAPI 封装服务都是同一套技术栈省掉了跨语言通信的麻烦。第三CadQuery 支持 STEP 格式导出。STEP 是工业界通用的中性交换格式几乎所有主流的 CAD/CAM/CAE 软件都能识别。这意味着 AI 生成的结果可以无缝进入工程链路而不是被锁死在某个 demo 里。第四社区生态相对活跃。CadQuery 的文档和示例代码量在程序化 CAD 里算是比较丰富的LLM 预训练数据里相关的代码片段也比较多这直接决定了 text-to-cad 系统的生成质量上限——模型的训练语料里都没有的东西它是不可能凭空编出来的。当然OpenSCAD 也有自己的优势比如语法更简单、纯函数式、不容易产生非法几何如果要快速验证一个 demo用 OpenSCAD 会更省事。我的建议是如果做技术验证两种都可以如果要往产品级方向走CadQuery 或者 Build123d 的后续潜力更大。2. 核心细节解析与实操要点2.1 程序化建模语言的基础语法与执行流程要把 text-to-cad 讲透绕不开程序化建模本身。我用 CadQuery 的一小段代码来演示它是怎么工作的这段代码生成的是一块带中心孔的圆形法兰底座import cadquery as cq base ( cq.Workplane(XY) .circle(50) # 半径50mm的圆 .extrude(10) # 拉伸10mm .faces(Z) # 选中顶面 .workplane() # 在顶面建立新工作平面 .circle(15) # 画半径15mm的圆 .cutBlind(-10) # 向下挖穿10mm ) cq.exporters.export(base, base.step)这段代码的执行逻辑是先在 XY 平面上画一个直径 100mm 的圆向上拉伸成 10mm 厚的圆柱体然后选中顶面在顶面上画一个直径 30mm 的圆向下挖穿 10mm形成一个通孔。整个操作序列对应着 CAD 软件里的“拉伸凸台”和“拉伸切除”两个特征操作。text-to-cad 系统要做的事情就是让 LLM 把用户的自然语言指令翻译成上面这样的代码。这里的难点在于自然语言是模糊的、有歧义的而代码是精确的、有唯一执行结果的。比如用户说“一个带圆角的板子”模型需要自己推断圆角半径取多少合适用户说“底座上放一个柱子”模型需要推断柱子的位置、直径、高度。这些推断如果全凭 LLM 的“想象力”那结果就是每次生成的模型都不一样。所以实际工程里需要配合一套约束体系来把关键参数钉死。2.2 关键操作参数的计算与动态推导这一节我重点写一下在实际系统中参数是怎么被解析和填充的。text-to-cad 的工作流通常分为三步意图解析、参数抽取、代码生成与执行。意图解析阶段LLM 负责判断用户的输入属于哪类建模任务。比如“创建一个 Ø30 的孔”和“在顶面中心打一个直径 30 的孔”这两句话虽然都涉及打孔但前者缺少位置信息后者信息完整。系统需要在解析阶段识别出缺失的参数并决定是向用户追问还是使用默认值。参数抽取阶段是直接让 LLM 以 JSON 格式输出结构化参数。这里我实际验证过一种比较稳的做法就是先给 LLM 一段固定的“参数抽取任务说明”把目标函数的签名、参数名、参数类型、单位、默认值和取值范围全部列出来再让它从用户输入中抽取。举例{ operation: counterbore_hole, parameters: { diameter: {value: 30, unit: mm, source: user_input}, depth: {value: 10, unit: mm, source: default}, position: {x: 25, y: 25, source: user_input} } }第三阶段把抽取出来的参数填充进预置的代码模板。代码模板是预先写好的、经过测试的 CadQuery 函数LLM 不需要从头“创作”代码只需要做参数填充。这一步是最可控的因为模板的几何正确性是人工保障的LLM 只负责填数即使填错了也是参数问题而不是整体结构性错误。我在实际系统中对这三步做了一个重要修正一开始我尝试让 LLM 直接从自然语言生成完整代码后来发现一个问题——代码生成的成功率受模型能力和提示词影响波动极大而且生成的代码经常调用不存在的 API 或使用了已被废弃的用法。改成“参数抽取 模板填充”之后成功率直接提升到了 90% 以上因为 LLM 的任务难度降低了从“写一段完整程序”降到了“从一句话里提取几个数字”。3. 实操过程与核心环节实现3.1 一个可落地的 text-to-cad 系统架构我这边搭建的系统分五层前端交互、意图解析、参数抽取、代码生成、几何验证。前端交互层目前用一个简单的 Web 页面用户输入自然语言描述后端调用 LLM 处理后进入执行管线最后把生成的 STEP 文件和模型预览图返回给用户。意图解析层用了 LangChain 的 Function Calling 机制。具体做法是定义几个核心建模操作函数比如 create_plate、add_hole、add_counterbore、add_fillet、add_chamfer然后让 LLM 判断用户意图并调用对应的函数。LangChain 的 Function Calling 比单纯让模型输出 JSON 更可靠因为它把函数签名结构化地传给了模型模型只需要选择要调用的函数和填充参数。参数抽取层用了一个小技巧在调用 LLM 之前先做一轮“单位归一化”预处理。因为用户经常会输入“一个 3 英寸的法兰”“5 厘米高的盒子”而 CadQuery 默认是毫米单位。如果直接让 LLM 抽取它可能会把“3”直接当成毫米导致生成的模型小得离谱。我的处理办法是在系统中维护一个单位换算表让 LLM 在抽取参数的同时标注原始单位再由系统统一换算成毫米。代码生成层我预置了一套 CadQuery 工具函数库每个函数对应一种经典建模特征。这样生成代码的任务就变成了组合调用这些函数而不是从零写几何操作。比如用户说“一块 100x80x10 的板子四角倒圆角 R5中心加一个 M8 螺纹孔”生成的代码会是这样from utils import create_plate, add_fillet, add_thread_hole part create_plate(length100, width80, height10) part add_fillet(part, edgesall, radius5) part add_thread_hole(part, diameter8, position(50, 40), threadTrue)3.2 提示词工程的实测经验提示词是整个 text-to-cad 系统里最容易出效果也最容易翻车的环节。我踩过的坑不少这里直接分享几条经验。第一条必须给 LLM 一个“角色设定 输出格式约束”的开场白。不要让它自由发挥。我实测过一个明确的系统提示词System Prompt对输出质量的影响远大于模型本身的能力差异。推荐模板你是一个专业的 CAD 建模指令解析器。你的任务是将用户的自然语言描述转化为结构化的建模参数。 要求 1. 只输出 JSON不输出任何其他文字。 2. 所有长度单位统一换算为毫米mm换算关系1英寸25.4mm1厘米10mm。 3. 如果用户描述中存在歧义优先选择最常规的工业设计解释。 4. 如果信息缺失使用默认值填充并在 JSON 中标记 source: default。 5. 禁止生成 CadQuery 代码只生成参数 JSON。这里注意一个反直觉的点在提示词里明确禁止 LLM 生成代码、只让它输出参数时整个系统的稳定性大幅提升。原因是 LLM 一旦开始生成代码就会开始“表演”你很难约束它的代码风格。但当它只输出 JSON 时它的任务边界非常清晰输出结构化的概率大幅提升。这不是什么高深原理就是任务难度管理。第二条对于常见建模意图做一个“用户说法的等价映射表”喂给 LLM。比如用户说“弄个底座”“加个盘子”“铺一层板子”这些说法的语义本质都是 create_plate。用户不会总是使用工程术语他们可能说“我想在一个方形的块上挖个洞”而不是“创建一个板类零件并在中心添加通孔”。把这些口语化表达提前映射好可以显著减少 LLM 的语义理解错误。第三条多轮对话中的参数记忆。一个实用的系统不能只处理单轮输入用户经常会追加“再加两个孔”“改成不锈钢材质”“尺寸放大 50%”。这就要求系统维护一个“当前模型状态”的上下文包含当前模型的参数、操作历史、单位体系。在每次新指令进来时把当前模型状态摘要和用户新指令一起发给 LLM让它输出“增量修改操作”。3.3 几何验证层的必要性生成代码跑完之后不代表就可以直接交付了——必须做一轮几何验证。CadQuery 本身提供了几何对象的合法性检查手段包括检查是否包含实体val().isValid()、检查体积是否为正、检查边界表示B-Rep是否存在退化面。我这边在验证层做了三个检查执行成功检查代码是否无异常执行完有没有抛出运行时错误。实体合法性检查返回的 Workplane 对象是否至少包含一个 Solid且 Solid 的 Volume 大于 0。参数一致性检查输出的 STEP 文件能打开、能正确显示模型如果系统把模型预览图返回给用户渲染能正常出图。在实际系统中几何验证层还有一个用途自动纠错。如果验证不通过系统会把错误信息返回给 LLM让 LLM 根据错误信息修正参数重新生成。这个“生成-验证-修正”的循环回路可以把成功率再往上推 10 到 15 个百分点。我建议所有做这个方向的朋友一定要设计这个闭环否则用户一句话上去直接报错体验是非常糟糕的。3.4 实操现场记录一个真实生成案例的完整链路为了让大家更直观地理解整个流程我把一次实际生成过程完整记录下来。用户输入是这么一句话“一个长方形板子长 100 宽 60 厚 8四个角打圆角 R6四角分别打一个直径 6 的孔孔距边缘 10。”系统处理流程如下第一步预处理。文本清洗去掉多余空格确认无单位词系统默认使用毫米。意图解析层识别出这是一个“复杂板类零件”任务包含创建板、倒圆角、四角打孔三个子操作。第二步参数抽取。LLM 输出如下 JSON{ plate: {length: 100, width: 60, height: 8}, fillet: {radius: 6, edges: 4_vertical}, holes: { diameter: 6, count: 4, margin: 10, arrangement: corners } }第三步代码生成。系统将上述 JSON 映射到预置工具函数from utils import create_plate, add_fillet, add_holes part create_plate(100, 60, 8) part add_fillet(part, radius6) part add_holes( part, diameter6, count4, margin10, arrangementcorners ) cq.exporters.export(part, output.step)第四步执行与验证。代码执行成功实体体积为 48000 立方毫米减去倒角和孔的体积验证通过。系统生成预览图接口返回给用户整个流程耗时约 4 秒其中 LLM 推理约 2.5 秒几何运算约 0.8 秒渲染约 0.7 秒。这个案例展示了核心逻辑系统真正做的是“把一句话翻译成结构化参数再把参数喂给一个确定性的几何引擎”而不是让 AI 漫无边际地建模。4. 常见问题与排查技巧实录4.1 问题速查表我在开发和使用 text-to-cad 的过程中整理了以下高频问题这里以速查表的方式列出问题现象根因分析解决方案生成的模型尺寸明显偏大/偏小参数抽取阶段漏掉了单位换算对用户输入做单位归一化预处理强制指定默认单位为毫米生成的模型位置错乱特征跑到主体外部LLM 对“位置”的理解和 CAD 坐标系不一致在提示词中明确坐标系规则中心默认为原点边距相对于边界倒角/倒圆角执行报错提示选中了不存在的边模板中边缘选择器的语义太宽泛或写死了名称用edgesall或精确的边选择器避免依赖边的名称多次生成同一句话每次结果都不一样LLM 的采样温度导致参数随机性设置 temperature0并在系统提示词中要求“确定性输出”生成结果能跑通但模型存在自相交或破面CadQuery 中布尔运算顺序不稳定调整特征操作顺序先做切除再做倒角或者合并为单次布尔操作用户追加要求“再加点东西”但生成结果丢失了之前的内容多轮上下文没维护当前模型状态在对话上下文中保存“当前模型状态摘要”每轮输入都携带该摘要以上问题里最常遇到的是第五个布尔运算顺序导致几何错误。我在实际开发中发现CadQuery 的逻辑其实非常依赖操作顺序——如果你先对某个面做倒角再做贯穿该面的切除切除边缘的倒角就会失效或者报错。推荐的做法是所有切除类操作先执行倒角类操作最后统一执行。这是经验之谈不是文档里会明确写的内容。4.2 提示词层面的排查方法如果发现生成结果的失败率比较高我的排查顺序是这样的第一步看失败是发生在“参数抽取”阶段还是“代码生成”阶段。怎么区分如果 LLM 输出的 JSON 本身就是残缺的、参数值缺失那是抽取阶段的问题如果 JSON 完整但代码执行报错那是映射阶段的问题。这两个问题的解决策略完全不同前者要优化提示词后者要优化代码模板和参数校验。第二步对提示词进行“单变量测试”。每次只改一个变量——比如只改动格式约束其他全部不变跑 10 个测试用例看成功率变化。我见过不少人一上来就大改提示词结果根本分不清是哪个改动起的作用。第三步检查是否有历史对话污染。在多轮对话系统中如果前一轮的上下文残留到下一轮LLM 可能会把旧参数带进新模型。解决办法是每次生成前重置系统提示词只保留用户输入和当前模型状态摘要不保留中间推理过程的详细对话。4.3 独家避坑技巧这里分享几个我沉淀下来的独家技巧算是花了不少时间摸索出来的。第一个技巧尽量把系统的建模能力范围限定在“参数化模板集合”内而不是让 LLM 自由生成 CadQuery 代码。这个思路和很多人的直觉相反AI 生成内容应该越自由越强大啊但实际工程里自由带来的是不确定性。真正进入生产环境时你需要保证系统不会生成一个不可制造的模型。限定模板集合本质是把系统的创造性约束在一个可控的范围内模型能做什么、不能做什么系统开发者说了算。第二个技巧对于生成结果永远保留“参数 JSON”而不是只保存 STEP 文件。因为 STEP 文件一旦生成你再想改某个尺寸就非常困难了——你需要重新生成。但如果保存的是参数 JSON用户说“把孔径改到 8”你只需要改一个数字再重新执行。这决定了系统的可编辑性极限。第三个技巧针对 CadQuery 的写法我总结了一套“安全写法”目前实测下来没有出现过非流形错误。核心包括拉伸和切除优先使用工作平面操作而不是绝对坐标命令倒角全部放在最后避免在同一组面上连续执行两次布尔运算使用cq.exporters.export导出前先调用computeVolume()验证体积。第四个技巧当用户输入的表达特别复杂时不要指望一次生成成功。先在系统内部做一个“子任务拆分”——把“一个带底座的盒子底座四角打孔盒子上开个观察窗”拆成三个子任务创建底座、创建盒子、在底座上打孔、在盒子上开窗。逐个执行再合并。这个方法在复杂场景下的成功率远超一次生成完整模型的成功率。4.4 关于模型选型与托管text-to-cad 系统的效果上限很大程度取决于底层 LLM 的代码理解能力和函数调用能力。我测试过几种模型这里给出一个主观但是基于实测的排序目前最强的闭源模型在意图解析和参数抽取上表现最好但开源模型通过结构化提示词工程也能达到接近的水平。这里的关键是不要盲目追求模型“会 CAD”而是要选“指令遵循能力”强的模型——因为我们设计的系统里LLM 的职责是遵循指令输出结构化参数不是真的懂几何建模。在实际部署时如果使用云端 LLM API需要关注响应延迟。text-to-cad 的用户体验非常依赖端到端延迟如果 LLM 推理耗时超过 5 秒用户就会觉得“卡”。我实测过几条优化经验尽量精简系统提示词去掉不必要的背景说明参数抽取任务只输出必要字段不要多余的格式包装使用流式输出或异步任务机制让用户先看到“正在解析”的进度反馈。如果是本地部署开源模型需要保证显存足够且推理框架高效。这个方向现在还在快速演进中但基础的流程设计和工程架构是稳定的——理解了这条链路后续换更强的模型只是替换一个组件的事。5. 性能调优与工程化落地5.1 端到端响应延迟的瓶颈分析一个生产级的 text-to-cad 系统端到端延迟是决定用户体验的生死线。我这边实测的延迟数据大致分布如下LLM 推理占 40% 到 60%几何内核执行占 15% 到 25%文件导出和渲染占 10% 到 20%网络传输和前端渲染占剩余部分。最值得优化的点是 LLM 推理这一块。减少给模型的输入长度是最简单有效的手段——系统提示词不要写超过 200 个 token 的“长篇大论”参数抽取示例最多给 3 个上下文只保留当前模型状态摘要而不是完整对话历史。同时把 temperature 设为 0避免随机采样带来的额外耗时。另一个优化重点是在几何内核上。如果生成的模型非常复杂比如有几百个特征操作CadQuery 的执行时间会显著上升。这里建议做“特征简化”对于不可见区域比如内部加强筋尽量不创建实体而是用简化的几何体替代。或者对生成结果做一次模型简化操作使用近似几何体替换多面体细节降低后续渲染和导出的计算量。5.2 模型的安全性与约束校验工业环境下一个错误的 CAD 模型可能导致的后果比一个错误的图片严重得多。所以系统的安全校验机制是必须的不能只靠 LLM 单方面保证输出正确。我这边实现的安全机制分三级第一级是参数范围校验所有的长度参数必须为正且处于合理区间比如 0.1mm 到 1000mm第二级是几何合法性校验执行后必须存在有效实体且无干涉第三级是制造可行性校验检查最小壁厚是否小于制造允许值、是否存在无法加工的封闭内腔等。这里有一个经验把安全校验做在“参数 JSON 生成之后”比做在“代码生成之后”要高效得多。因为参数错了代码一定错但代码错了参数不一定错。尽早拦截无效参数可以省下大量的几何计算时间。5.3 多格式输出的工程价值系统只输出 STEP 文件是不够的实际应用中不同下游环节需要不同格式。3D 打印用户需要 STLCNC 编程需要 STEP轻量化预览需要 glTF 或 OBJWeb 展示需要嵌入 3D 查看器。CadQuery 内置了多格式导出能力而且导出质量比较可靠from cadquery import exporters exporters.export(part, output.step) exporters.export(part, output.stl) exporters.export(part, output.glb)STL 导出会三角化整个网格适合直接切片STEP 保存精确边界表示适合 CNC 和 CAMglTF 适合 Web 端即时预览方便用户不下载模型就能检查结果。一个完整的 text-to-cad 产品应该把这三种格式同时返回给用户而不是只给一个 STEP。6. 未来扩展与个人心得text-to-cad 这个方向目前还在摸索期但我个人判断它的发展路径已经比较清晰了。短期看单一文本输入只能解决简单零件建模复杂装配体还需要人工介入中期看多模态输入草图加文字、图片加语音会大幅降低使用门槛长期看AI 辅助设计会深入到拓扑优化、生成式设计和大规模装配布局这些领域。我现在手里的扩展计划包括三个方向第一个是加入基于视觉的闭环校验将生成的模型渲染成图送回给多模态模型检查外观是否符合预期第二个是支持变更管理用户说“把孔从 6 改到 8”系统能准确识别并只修改对应的参数而不是重新生成第三个是尝试用用户反馈数据微调模型让系统逐渐学会某类用户的表达习惯比如机械工程师习惯说“沉头孔”而创客可能会说“螺丝沉进去的孔”。最后说一点个人体会。我在做这个项目的过程中最大的感受是text-to-cad 真正难的地方不在于让模型学会“想出”一个模型而在于让它学会“听人话、做对事”。自然语言里的歧义、省略和比喻是工程化落地时最大的敌人。所以我大半个项目周期都在和提示词、参数校验、上下文管理较劲而不是在调模型结构。这给后来者一个很实在的建议AI 能力只是起点工程化约束才是把技术变成产品的关键不要把所有赌注押在“模型更强”上多花时间打磨任务分解和结果校验这套骨架系统的稳定性和可用性会以更快速度上升。如果你也正在做相关项目希望这篇文章里的路线和踩坑记录能帮你少走一些弯路。