最近被问得最多的一个词就是 text-to-cad也就是用一句自然语言直接生成三维模型听起来像是“一句话建模”的魔法时刻。实测下来这个方向确实已经从论文里的概念变成了可以跑通的东西但离“输入一句人话就直接出工程可用模型”还有相当一段距离。我前阵子刚好集中调研并复现了几条主流技术路线从大模型生成脚本到扩散模型出体素再到直接预测特征树都摸了一遍过程中踩了不少坑也理清了一些关键判断。这篇就按我自己的实操顺序把技术原理、方案选型、完整流水线和避坑经验一次性讲透。1. text-to-cad 到底在解决什么问题1.1 从一句话到三维模型的本质不是翻译是约束求解很多人第一次接触 text-to-cad 时会有个错觉这不就是把自然语言“翻译”成三维模型吗语言模型负责理解句子然后后端再把它变成几何体。但真正做过一次就会发现问题远没有“翻译”这么简单。二维到三维之间隔着一条巨大的鸿沟语言是线性的、离散的符号序列而三维模型是连续几何、拓扑关系、尺寸约束和特征历史的结构化综合体。同一个“盒子”在自然语言里可能是“一个方形盒子”但在 CAD 里必须明确长宽高是多少、圆角半径多大、壁厚多少、孔在哪个面上、孔的直径公差是多少。换句话说text-to-cad 的核心不是理解语义而是把模糊的语义“映射”成一组完备且自洽的几何约束。这个映射过程更像是在做约束求解而不是做翻译。我自己的一个理解是它可以类比成“你给装修师傅口头描述一个柜子师傅一定会追问你柜子多高、多宽、用什么板材、要不要抽屉”。如果这些约束不确定师傅没法开工。text-to-cad 也一样模型要做的不仅是听清楚你在说什么更重要的是在信息不足时做出合理推测并且保证推测出来的几何是能真实加工、能编辑的实体模型而不是一个看起来像模型但实际上没法用的壳。1.2 传统 CAD 建模的痛点为什么“说人话建模型”是个真需求在说 text-to-cad 的价值之前得先聊聊传统建模有多痛才会明白这个方向为什么近几年突然被推到风口上。传统 CAD 建模不管是商业平台还是开源工具本质都是一套严谨的参数化特征系统。用户要建模一个零件脑子里得先规划清楚特征树先画哪个草图、拉伸多少、在哪开孔、怎么倒角。每一个操作背后其实都是几何内核里的布尔运算和约束求解。对于老工程师来说这没什么但对非专业人士来说学习成本极高。我见过不少做结构设计的朋友为了给散热器加几个螺丝孔得先学半小时工具栏怎么用。而更深层的痛点在于设计意图的表达是被限制在软件交互框架里的。你想做一个“类似 A 但稍微大一点、孔位分布不同的版本”在传统软件里你得找到特征树、修改草图和尺寸每一步都可能引发约束连锁报错。text-to-cad 想解决的正是把“设计意图”——注意是意图不是最终几何——直接用自然语言表达出来让系统去处理后续的参数化和特征重建。这对概念设计、方案比选、快速原型验证这几个场景尤其有价值你能在几分钟内把脑海里的想法变成可量化的三维模型而不是花一晚上画草图。另外一个被很多人忽视的真实需求是制造业里有大量老旧零件需要“逆向建模”成参数化模型。老工程师看一眼实物嘴里描述几句新人再去 CAD 里重建。如果 text-to-cad 足够成熟这一段“口头描述转模型”的环节就能被大幅压缩。所以它不只是一个 AI demo 方向背后是有明确工业场景支撑的。1.3 为什么是现在才火起来语言模型、几何数据与算力三件事同时到齐其实“用文字生成模型”的想象很早就有了。早年的自然语言建模系统可以追溯到上世纪八九十年代的语义建模研究但当时受限于两个硬条件自然语言理解能力太弱三维几何数据的获取和标注成本太高。没有高质量的数据集机器学习模型根本没法学到“语言到形状”之间的复杂映射。这几年突然井喷是因为三件事同时到位了。第一大语言模型在指令理解、常识推理和代码生成上的能力大幅提升这让“文本转参数化建模脚本”成为一条非常自然的技术路线。第二开源社区积累了一批文本-形状对齐的数据集和千万级三维模型库配合自动化的脚本生成与验证管线标注成本显著下降。第三算力尤其是 GPU 加速的几何处理框架越来越成熟让大规模训练和实时推理变得可行。这三点是相互促进的LLM 提供了“文本理解”这个缺失已久的入口数据集解决了“学什么”的问题算力让“学得动”成为可能。所以 text-to-cad 的火不是凭空来的它踩准了技术周期的交叉点。2. 三条技术路线深度解析与选型决策2.1 路线一大模型直接生成 CAD 脚本最务实、最容易落地第一条路线是让大模型写代码代码再驱动脚本化 CAD 内核建模。典型工具链就是大模型 CadQuery、OpenSCAD 或 FreeCAD 的 Python API。用户输入“一个长 100 宽 60 高 30 的盒子顶部倒圆角 10中心有一个通孔”模型输出一段 Python 脚本脚本执行后得到实体模型。这条路线的优势非常明显它输出的不是一次性网格而是带特征历史的参数化模型。这意味着用户可以回去改那个“倒角半径 10”改完模型自动更新。工程上最看重的“可编辑性”天然满足。另外脚本作为一种中间表示是文本形式人类可以读、可以调试、可以版本管理这对接入现有 PLM/PDM 系统非常友好。缺点同样明显。大模型生成的脚本经常有语法错误或语义偏差直接执行会产生一堆废模型而且它依赖一个相当“脆”的反馈机制脚本报错怎么改得把错误信息再喂回模型。调试链条长稳定性难保证。我实际跑下来简单的长方体、圆柱、孔特征成功率在七八成以上一旦描述带不对称特征、多实体联动、复杂曲面失败率会显著上升。如果要在这条路线上做出可靠产品必须要有一个“生成-执行-报错反馈-修正”的闭环这对后端的执行沙箱和错误归因能力要求很高。2.2 路线二扩散模型生成隐式几何视觉效果好但工程化困难第二条路线是借用图像生成领域成熟的扩散模型思路把三维形状当作体素场或隐式距离场来生成。模型输入文本描述输出一个 128 或 256 分辨率的体素网格再经过网格抽取比如 Marching Cubes变成表面模型。这条路线生成的几何形态非常丰富尤其适合自由曲面、有机形态这类传统参数化建模很难表达的造型。比如“一个像海豚一样弯曲的支架”参数化特征几乎无法描述但扩散模型可以生成一个合理形态。但问题也很致命生成的是网格mesh或隐式场不是 B-rep 边界表示更不是参数化特征。也就是说用扩散模型出来的模型没法直接在 CAD 软件里改尺寸、加倒角、做布尔运算必须重新进行曲面拟合和特征重构。这一步目前非常依赖人工甚至比从零建模更费劲。另外体素分辨率限制会让细薄的壁、小孔、倒角等制造相关细节丢失生成的网格要么过于平滑要么出现空洞和自相交距离“能加工”的标准还差得远。目前这条路线更适合做视觉概念、设计灵感探索和前期产品造型评估不适合直接进工程流程。2.3 路线三直接预测参数化特征序列最难的也是最理想的第三条路线是绕过脚本语言直接让模型输出一整套参数化特征序列也就是预测一个 CSG构造实体几何树或者特征操作序列。就像教一个 AI 学会“建模师的操作步骤表”第一步拉伸矩形草图第二步切除圆柱第三步倒圆角每一步都带参数。这条路线的理想状态是模型自动完成从语义到特征树的映射不需要中间代码也不会被语法错误卡住。推理时输出的就是一套结构化的特征描述可以完美转换成 CAD 内核里的特征历史。理论上它的上限最高因为它的输出本身就是工程意义上的参数化模型。但它也是目前最不成熟的路线。预测高维度结构化的特征序列是一个非常困难的序列决策问题搜索空间极大。描述稍有变化最优特征树就可能整个不同。训练数据方面需要大量带标注特征历史的 CAD 模型作为监督信号这种数据的获取成本远高于文本-网格对。所以目前这条路线大多还停留在论文和特定数据集上的评测阶段离通用化产品化差距最大。不过我自己的判断是未来成熟的 text-to-cad 最终形态大概率是这个方向因为它的输出形式和工程世界最贴合。2.4 三条路线怎么选我给出的决策建议如果你也想做个 text-to-cad 项目选哪条路线得先想清楚使用场景。如果目标是快速做出一个能用的工具解决工程场景里的重复建模选路线一脚本生成最划算。理由很简单现有大模型的代码能力已经够用CadQuery 这类库也成熟中低复杂度的零件能跑通。把精力放在提示工程、模板库和后处理校验上见效最快。如果目标是做设计可视化、展览展示、概念造型探索可以选路线二扩散模型。这条路线的视觉效果最容易打动非专业用户也适合做交互式创意工具但别指望它直接导出能在专业建模软件里流畅编辑的模型。如果目标是做长期技术壁垒、切真正的高端制造场景建议密切关注路线三并且尽早积累带特征历史标注的数据。前两条路线解决的是“从无到有”第三条路线解决的是“从有到正经可编辑”。我个人的选择是主力押注路线一用模板库把成功率拉高同时保留路线二做造型探索的入口路线三先追踪不急着投入。这个决策组合在公司资源有限的情况下最稳健。3. 实操拆解用 CadQuery 搭一套可复现的 text-to-cad 流水线3.1 整体架构与模块划分这一节我把自己的实操过程完整梳理一遍。整体架构大致分为四个模块文本解析、参数提取、脚本生成、执行校验。很多人一上来就指望大模型直接输出成品但其实把文本解析和参数提取独立出来成功率会提高非常多。核心思路是不要指望大模型从零“创作”建模逻辑而是让它做选择。先定义一套模板库每种模板对应一类几何形态盒子、圆柱体、带孔板、法兰等每个模板都有明确的参数槽位。大模型的任务是从输入文本中抽取参数并选中匹配的模板而不是自由发挥写代码。这相当于把一道开放式作文题变成了填空题准确率自然高。下面是一个模板示例的 JSON schema 设计{ template: box_with_hole, params: { length: {value: 100, unit: mm}, width: {value: 60, unit: mm}, height: {value: 30, unit: mm}, hole_diameter: {value: 16, unit: mm}, hole_position: {x: 0, y: 0}, fillet_radius: {value: 10, unit: mm} } }文本解析阶段我用的是一个纯 LLM 的抽取链路把模板 schema 放进系统提示词里要求模型只输出 JSON不输出任何解释。这样做有两个好处一是后续可以直接反序列化进 Python二是把模型的输出约束在结构化的空间里降低自由文本带来的不确定性。3.2 文本解析与参数提取让模型做填空而不是写作文文本解析这一步是整个流水线里最容易被低估的环节。我测试过直接让模型输出 CadQuery 脚本和让模型输出结构化参数两种方式前者的端到端成功率大概在 60%后者配合模板库能到 85% 以上。具体做法是在系统提示词里给出所有可用模板的名称、适用场景和参数列表然后让模型根据用户描述完成 JSON 抽取。有几个细节值得注意必须要求模型输出默认值。用户说“一个盒子”没说尺寸模型必须填默认值否则后续建模会因缺少参数而崩溃。默认值的设计要贴近真实使用习惯比如长方体默认 100x60x30壁厚默认 3孔直径默认 8。这些默认值最好由有 CAD 经验的人来定而不是让模型瞎猜。另一个细节是单位的处理。用户可能说“做一个两英寸的法兰”模型需要把英寸转换成毫米。为了保证转换正确我明确要求模型内部先转成毫米再填入 JSON同时保留原始描述里的单位痕迹以便复查。实测中这种“显式转换”的指令能让单位错误率下降很多。还有一个细节是对“数量语义”的识别。比如“四个角上各打一个孔”这句话里有复数语义和位置语义模型很容易漏掉“四个”或者只生成一个孔。我的处理方式是在 schema 里增加一个repetition字段把这类信息单独抽取出来生成阶段再用循环处理而不是让建模逻辑里偷偷塞进多个孔特征。3.3 模板库的设计参数化建模的核心资产模板库是这个流水线里真正的核心资产它的质量直接决定系统能覆盖的几何形态上限。每个模板本质上是一段封装好的 CadQuery 函数接收参数字典返回一个实体模型。以box_with_hole模板为例核心代码长这样import cadquery as cq def build_box_with_hole(params): length params[length][value] width params[width][value] height params[height][value] hole_d params[hole_diameter][value] pos_x params[hole_position][x] pos_y params[hole_position][y] fillet_r params[fillet_radius][value] result ( cq.Workplane(XY) .box(length, width, height) .edges(|Z) .fillet(fillet_r) .faces(Z) .workplane() .hole(hole_d) ) # 让孔的位置可调 if abs(pos_x) 0.001 or abs(pos_y) 0.001: # 重新定位孔先画孔中心点再挖槽 result build_with_offset_hole(result, length, width, height, pos_x, pos_y, hole_d) return result模板设计有几个重要原则参数要少而精不要追求一个模板覆盖所有情况特征顺序要稳定先主体后细节每个模板都要有对应的“失败回退策略”比如某个参数组合导致布尔运算失败就自动用简化几何替代保证系统不会直接崩掉。从工程角度看模板库不只是代码更是一套领域知识库。每个模板背后其实对应一种加工特征习惯比如“法兰盘”模板包含的同心孔、沉头孔特征都是机械设计里高频出现的。你把越多的领域特征固化进模板大模型需要“发挥”的空间就越小系统就越稳。这个思路也适合小团队起步先覆盖你最熟悉的那 20 类零件不要一上来就想做全品类通用建模。3.4 脚本生成、执行与校验端到端的闭环流程模板参数抽取完成后流水线会进入脚本生成与执行阶段。这里的脚本不是让大模型写的而是由模板代码拼接出来的。我维护了一个模板注册表键是模板名值是一个生成函数。根据解析阶段选中的模板名系统动态调用对应函数并传入参数 JSON。执行环境我建议使用沙箱。模型代码来自外部输入虽然模板代码是自研的但生成的参数值可能包含异常数据比如负数尺寸、超大圆角所以构造一个受限的执行环境很有必要。用 Docker 容器跑 CadQuery 执行限制 CPU 配额和内存上限超时就杀死进程这是最稳妥的做法。执行完成后要自动化校验。我设了三个指标实体是否非空、体积是否为正、是否有自相交面。CadQuery 的val().isValid()方法可以检查实体有效性体积可以通过result.val().Volume()获取。低于预设阈值就直接标记为失败进入重试或降级流程。降级流程就是走回退策略把圆角去掉、把孔位归零重新生成确保至少给用户一个“近似可用”的模型而不是干等报错。最后是格式导出。CadQuery 支持直接导出 STEP 和 STLcq.exporters.export(result, output.step)STEP 是工程领域最通用的中性格式几乎所有主流 CAD 软件都能打开并保留实体信息STL 则用于 3D 打印和可视化预览。两个文件都导出是个好习惯能覆盖更多下游场景。3.5 模型校验与格式导出的经验补充在实际跑通之后我补充了 PNG 渲染预览这一步。CadQuery 本身不带渲染功能但可以通过导出 STEP 之后用配套的可视化模块生成一张三视图缩略图。这样用户不用打开 CAD 软件就能快速判断生成结果是否合理。这里有个值得注意的坑STEP 文件本身不记录单位信息如果生成端用毫米消费端如果是英寸尺寸会差 25.4 倍。所以导出的时候一定要在文件名或者辅助的元数据 JSON 里把单位标注清楚。我在实际对接过程中遇到过因为单位不匹配导致整套夹具设计返工的情况这种问题在管线里非常隐蔽因为打开软件看视觉形态好像差不多一旦用测量工具一比全都对不上。另外对生成的模型我建议做一个参数合法性校验比如所有尺寸必须大于 0、孔径要小于对应面的宽度、圆角半径不能超过边长的一半。这些规则看起来是常识但大模型抽取参数时不会自动遵守所以必须用代码硬校验。违反规则时要么修正参数比如把负值改成默认值要么直接拒绝生成并给出修改提示绝不能带着非法参数进入几何内核否则内核会吐出一堆难以排查的诡异错误。4. 常见问题与排查实录我在实操中踩过的坑4.1 文本歧义同一句话十种理解最困扰我的问题就是文本歧义。“在一个圆角矩形的底板上放四个柱子”这句话我让不同模型解析得到过四种不同结果四个柱子分别是圆柱还是方柱底板的圆角半径多大柱子均匀排列还是靠边放模型需要脑补大量判断。我的解决方案是“交互式澄清”把关键歧义点做成选择题让用户手动确认一次。比如“四个柱子等距排列还是按给定坐标放置”这个交互只需要用户点一下但能极大地减少后续返工。更好的做法是在管线里内置“置信度”概念模型对抽取的参数没有把握时不要硬填而是标记为“待确认”在生成前弹一个快速的参数校验面板。这个设计方案让端到端体验提升了不少。也可以从提示词层面规避在系统提示词里明确要求“如果描述中有数字必须使用如果没有数字必须使用模板默认值”同时把模板默认值打印出来让用户提前知道。这样用户得到的结果至少是可预期的。4.2 约束冲突尺寸与几何打架模板参数之间是有隐含约束关系的。比如“长方体 100x60x30顶面圆角 25”这个圆角半径超过了侧面短边的一半几何内核就会报错因为多个圆角相交后拓扑失效。这类问题一旦出现生成的实体往往是空的或者自相交的校验阶段会直接标记失败。排查这类问题的常用手段是逐步简化先关掉所有圆角生成基础形状再逐个加上特征定位是哪个参数出了问题。我写了一个特征二分调试脚本自动把模板特征数组切开生成多组候选快速定位问题特征。这个脚本虽然简单但帮我节省了大量手动排查的时间。更治本的办法是给模板加了参数校验器在进入 CadQuery 之前做几何合理性判断。比如圆角半径必须小于 min(长,宽)/2孔直径必须小于所在面的最小边长。校验规则一开始只写了 5 条后来随着测试集扩大加到了 30 多条几乎每个模板都有一组专属约束。这也侧面说明了模板库真正落地需要长期的领域积累。4.3 执行环境的不确定性依赖与版本CadQuery 本身依赖一个几何内核库这个内核库的版本差异会导致同一个脚本在不同环境下生成不同的结果。最典型的是布尔运算的容差处理在老版本内核上能成功的“相交面切除”在新版本上可能因为容差偏严而失败。这种问题最隐蔽的地方在于它不会显式报错而是静默生成一个不正确的结果。处理办法是锁版本加容器化。我在 Dockerfile 里把内核库版本和 CadQuery 版本都固定下来并在 CI 里跑每日回归测试确保基础模板库的生成结果不会因为环境变化漂移。这套实践不仅适用于 text-to-cad任何依赖几何内核的自动化建模系统都应该这么做。还遇到过一个小坑CadQuery 的多线程执行并不完全安全几何内核的并发写保护不算完善。所以我用进程池替代线程池每个进程独立加载 CadQuery避免共享内核状态的竞争。虽然多开进程会吃更多内存但稳定性是第一位。4.4 质量评估怎么衡量“生成对了”要评估 text-to-cad 的效果不能只看“能不能生成一个模型”。我在测试集上标注了三档结果完全符合、部分符合、完全不符合。完全符合要求是几何形态、关键尺寸、特征数量全部正确部分符合是形态大体对但尺寸偏差明显完全不符合就是出现废模型。光用人的主观判断不够还需要客观量化。我从三个维度算分几何相似度通过采样点云算 Chamfer Distance参数正确率对比生成参数和标注参数在关键尺寸上的误差特征完整性检查应有的孔、倒角、槽等特征是否存在。这三个维度合起来能比较好地反映一个生成系统的真实水平。一个值得留意的现象是通用评估指标和工程可用性之间的相关性其实不高。有些系统在指标上拿高分Chamfer Distance 很好看但生成的模型带有非常薄的碎面根本没法加工。所以我后来增加了“加工可行性”的人工抽查项找几位机械设计师盲评分数的说服力比任何自动指标都强。这也提醒我不要被指标迷惑最终要以人的工程判断为锚。4.5 避坑速查表我整理了一张速查表基本覆盖了复现这个流水线最常踩的坑坑现象原因解决方案参数被“脑补”用户没说尺寸模型填了离谱数值抽取阶段自由度过高强制模型使用默认值输出 JSON schema单位不一致模型尺寸相差 25.4 倍英寸毫米混用显式要求模型转换并标注单位圆角过度实体变空/自相交圆角半径超限添加几何合理性校验器内核版本差异不同环境结果不同几何内核容差变化Docker 锁版本跑回归测试并发崩溃高并发下进程挂掉内核线程安全问题用进程池替代线程池生成模型无特征历史STEP 是死壳不能编辑直接输出网格坚持走参数化脚本路线这张表是我后期维护最频繁的文档之一每次遇到新问题都会往里补充。做这类系统经验沉淀比新颖算法更重要。5. 从 demo 到可用系统进阶方向与个人经验5.1 几个比“直接生成”更现实的应用方向在把直接生成的 demo 跑到一定成功率后我意识到一个现实与其执着于“一句话生成最终零件”不如把 text-to-cad 能力拆开嵌入更多实际工作流里。第一个方向是“参数化变体生成”。给定一个基础模型的模板用户用自然语言描述想改哪些尺寸或者加哪些特征系统基于模板做参数修改。比如“把底板加长 20孔距改成 50再加四个安装脚”。这种做法把问题从一个“全量生成”退化成“增量编辑”难度大大降低而工程需求恰恰大量集中在这个场景。第二个方向是“检索式模板匹配”。输入文本后先在已有的模型库或模板库里检索最接近的候选然后把文本中提到的差异参数应用到候选模型上。这个思路很接近“以文搜模型再自动调整”比从零生成的成功率和可控性都强得多。第三个方向是“草图转模型配合”。用户先用自然语言描述整体意图再用简易草图标注比例和位置系统结合文字和草图信息完成建模。视觉信息极大地消除了文本歧义这个融合方案我认为是更接近产品化的路径。这些方向的核心共同点是降低生成难度增加人为控制把 AI 放在辅助位置而不是完全取代设计师。当前技术水平下这才是 text-to-cad 真正能创造价值的姿势。5.2 我对这套技术的一个核心体会实际做下来我对 text-to-cad 整体判断是乐观的但对实现路径有了更现实的认识。它本质上不是一个纯语言问题也不是纯几何问题而是一个“如何把模糊需求变成严谨约束”的工程系统问题。指望一个大模型单枪匹马搞定所有环节目前不现实。真正让系统落地靠谱的是我前面反复提到的模板库、校验器、沙箱和交互确认闭环。这些工程组件看起来不性感但正是它们把成功率从 60% 拉到 85% 以上。如果你也想复现类似的系统我建议先把模板库做小做扎实再逐步扩充覆盖范围。最后分享一个我一直在用的判断标准任何 text-to-cad 输出必须能导出 STEP 并被人修改参数后重新生成才算“真正生成了一个 CAD 模型”。如果只是给了一堆三角形网格那它更接近“三维图片”而不是 CAD。抓住这个核心标准不管技术路线怎么演进你的方向都不会跑偏。