文末有个括号提示说明这是供 AI 参考的内部草稿不过不用管它——真正发布时只输出最终的文章内容。在制造业和 AI 的交叉地带text-to-cad 是最近一年最让我兴奋的方向没有之一。它要解决的事情特别朴素你输入一句带四个沉头孔的安装板系统直接给你一个能编辑、能制造、带特征历史树的三维 CAD 模型而不是一张渲染图、一个网格文件。这个能力听起来只是把自然语言和三维建模接了个口子但真做起来牵扯到意图解析、几何约束、拓扑修复、参数校验一整条链路每一环都有无数细节。这篇文章不是某个商业软件的测评而是我基于自己做过的项目、拆过的开源方案、踩过的坑整理出来的通用方法论。适合三类人看一是做结构和产品设计的工程师想用 AI 加速概念设计二是做 AIGC 工具开发的人想了解这个技术栈怎么落地三是准备入门三维智能建模的研究者看这篇能多少避开一些弯路。1. text-to-cad 到底在解决什么问题先理清一个底层概念计算机里的三维模型远不止一种表达方式。网格适合游戏和渲染点云适合扫描逆向体素适合深度学习的卷积操作但制造业真正依赖的是边界表示和参数化特征树。普通用户可能觉得 mesh 模型和 CAD 模型长得差不多但在工程视角上两者是完全不同的物种。网格模型就是一坨三角形面片没有孔的直径这个概念想改一个孔的大小就只能回到网格编辑里去手动拖顶点而 CAD 模型保留了完整的历史特征螺栓孔在特征树里就是一个带参数的 Hole 特征双击改数字实体自动重算。text-to-cad 的第一层价值就是把设计意图转成参数化特征。描述里的对称阵列圆角这些词模型必须意识到那不是表面装饰而是真实的建模操作。这是 text-to-cad 和 text-to-3D 最大的分水岭——后者追求视觉合理前者追求工程合理能落户到真实制造流程里。第二层价值是压缩沟通成本。过去设计师和需求方来回对齐想法要画草图、发图片、打语音电话信息损耗巨大。我在实际项目里见过一个真实场景标准件库的搭建法兰的一堆规格尺寸全靠人工查表、一个个建模几十个型号就要折腾好几天。如果能把法兰外径 100内径 45四孔均布孔径 12厚度 8这样的描述直接变成自动生成的脚本重复劳动的量能砍掉一大截。这就是 text-to-cad 很典型的落地场景——任务固定、参数清晰、重复性强。第三层价值可能也最容易被忽视是让没有 CAD 基础的人也能参与三维概念设计。产品经理和结构工程师之间经常因为一个简单造型反复拉扯PM 描述得天花乱坠工程师听完被迫画了好几个方案才摸清需求。如果有了 text-to-cadPM 可以先把候选形态粗生成出来再交给工程师沟通效率完全不是一个级别。不过我必须把话说在前面text-to-cad 的目的是给工程师减负不是取代工程师。材料选型、力学分析、加工工艺约束、装配干涉检查这些核心判断仍然依赖人的经验。它的合理定位是从设计意图到模型初稿这一段路的加速器。2. 主流实现路径从语言到模型是怎么走通的我拆过不少开源和商业方案的代码发现不管表面包装怎么变核心链路基本是固定的四步意图解析、模型表达生成、约束求解、结果校验。区别只在于每一步用了什么技术、侧重哪个环节。2.1 第一步意图解析这是离大模型最近的一环也是最见解析功底的地方。模型的输入是一句自然语言输出必须是一份结构化描述——通常是一段 JSON里面包含了实体列表、几何参数、特征操作和约束条件。举个例子输入底板长 200 宽 120 厚 10四角开沉头孔孔距边缘 15孔径 8解析结果大致是{ operations: [ { type: box, name: base_plate, params: {length: 200, width: 120, height: 10} }, { type: hole, pattern: rectangular, count: 4, params: {edge_offset: 15, diameter: 8, head_type: counterSink} } ] }这段 JSON 看着简单但里面藏着好几个难点。最大的问题是模糊信息的处理。真实用户不会像文档一样描述零件他们会说稍微厚一点孔别太靠边大概这么大。好的解析器应该学会把这种模糊量转成占位符留给下游参数优化流程去决定而不是直接让模型猜一个数字填进去。我在早期实验里就吃过亏模型特别爱把稍微厚一点翻译成一个看起来合理的随机数比如 3.2mm结果用户一看数据就笑了因为这不是他想要的。后来我们强制要求所有非明确数值必须标记为待定状态才算是勉强解决了这个毛病。2.2 第二步模型表达生成结构化 JSON 只是一个中间产物它还需要被翻译成真正可执行的建模指令。在这个环节业界大致走了三条技术路线各自适用的场景完全不同。第一种是脚本化生成。让大模型直接写参数化 CAD 脚本比如用变量和函数调用描述拉伸、打孔、阵列等操作。这种方式的好处非常突出生成结果天然带参数可解释性极强每个特征都能追溯修改和现有工程流程无缝衔接。缺点也很明显——模型必须真的会写代码而且生成的脚本经常出现边界条件错误比如拉伸方向搞反、布尔运算的实体顺序不对。以我自己的经验这类问题通常可以通过后面要讲的自动修复循环来兜底问题不大。第二种是隐式场建模典型做法是训练一个神经网络来学习空间场函数每个点判断在物体内部还是外部最后再用 Marching Cubes 算法提取网格。这种方式生成自由曲面特别强适合外观类零件像消费电子产品的壳体、玩具、雕塑造型。但它的致命问题是输出是网格没有特征历史树在 CAD 工程软件里几乎无法直接修改只能当设计参考离能制造还差得很远。第三种是混合方案这也是我个人最看好、最贴近工程落地的方向先用扩散模型或者检索的方式生成一个粗略形态作为空间约束再让大模型基于这个约束组织参数化特征去逼近。举个例子先让系统生成一个大概是圆润的盒子外形然后检索到结构类似的零件模板再修改模板参数来贴合这个外形。这样做既避免了纯脚本生成时闭眼画的问题又保证了最终结果具备完整的特征历史可以说是两条腿走路。2.3 第三步约束求解与几何修复这一步往往是新手最容易忽略但也是工程落地时最要命的。CAD 建模有一个绕不开的坎叫拓扑一致性本来应该共面的边可能出现缝隙布尔运算之后会出现退化面参数不合理时特征可能自相交。这类问题在代码生成里非常普遍因为模型对几何的直觉还不足以预判内核的容差处理方式。所以成熟系统里几乎都会有一个几何修复模块专门负责检查实体有效性、自动去除退化边、重新计算相交面必要的时候回查原始描述来修正参数。你可以把它理解成文档编辑器里的自动纠错功能只不过它纠的是三维模型里面的几何错误。我自己的实测经验是在文本生成模型的结果里这种几何错误的出现率大概有 30% 左右复杂度越高、特征越多概率越高。2.4 第四步结果校验与反馈最后一步是把生成结果交给用户但这不是简单抛出一个模型文件就完事了。我的习惯是同时输出一份文本—参数—实体对照表把描述里的每个尺寸、每个约束在模型里的对应参数都列出来一眼能看出系统理解得对不对。这个环节的体验细节非常重要直接决定用户敢不敢用这个结果。如果模型生成的尺寸全是瞎猜的又没有标注用户根本不敢把模型拿去做结构分析但如果你在界面里标注出这段文字对应这个 8mm 孔位其余尺寸为默认值用户至少能快速定位可疑参数并修改。这种透明感带来的信任提升往往比调模型算法本身更有效。3. 技术选型哪些坑值得提前知道真正动手做一个 text-to-cad 系统时会遇到几个绕不开的技术决策。这里我把关键的几个岔路口捋一遍顺便聊聊我的经验。3.1 数据从哪里来这是个真问题要做 text-to-cad横在面前的第一座山是数据。文本和三维模型的配对数据不像图文对那样到处都有。现实世界里的 CAD 文件绝大多数没有配套的自然语言描述而人们说的话又找不到对应的三维文件。目前业界主流的解法是合成数据。合成数据通常有两种做法各有取舍。第一种是在现有模型上反向生成描述拿标准件库里的零件把每个零件的参数和特征序列整理成描述模板自动生成法兰 4 孔、支架 L 型这样的句子。这种方法成本低、速度快但依赖现有零件的类型覆盖度——你做过的零件类型模型才会描述没做过的只能靠泛化。第二种更彻底直接从模型的历史树反推操作序列再用模板把操作序列转换成语言。这种方式的扩展性更好但工程复杂度高因为要处理各种不同的操作顺序和参数组合。我自己踩过最大的坑是模板合成数据可以轻松解决冷启动但模型在真实世界口语化描述上的泛化能力会差一大截。用户不会按照模板说话他们说的句子充满了省略、指代和模糊量词。后来我吸取教训在系统中专门保留了一小批众包标注的脏数据用来专门收录那些口语化、不精确、但人类能理解的样本。这批数据量不需要大但决定了产品在真实用户手里是惊喜还是翻车。3.2 大模型选开源还是闭源这是一个工程落地时必须正面回答的问题。闭源商用模型在复杂空间关系的理解上确实更胜一筹但产品化要考虑数据隐私、调用成本、延迟、定制能力等多重因素。我看到的大部分企业最终选择的路线是用开源模型做底座再在自建合成数据集上做微调以获得更好的领域效果和可控的成本。如果是从零开始做我建议先别急着微调。最实际的路径是先用现成的代码模型或通用大模型跑通端到端实验重点验证意图解析的准确性把这个环节的概率摸清楚。因为项目初期的卡点通常不是模型能力而是下游几何引擎的稳定性和前处理流程没打通。等你发现 90% 的失败都来自几何修复和参数校验时再回头微调模型效果提升会非常明显因为判断标准已经很清晰了。3.3 几何内核的选择会限制一切text-to-cad 输出的模型最终要能在工程软件里被编辑这就绕不开几何内核。不同内核的容差机制、布尔运算稳定性、特征表达能力差别很大。开源内核偏向轻量在复杂曲面操作和稳定性上一般要弱一些商业内核功能全面、稳定可靠但授权成本不低、生态相对封闭。在这个环节我吃过一次大亏项目早期我把几乎全部精力都花在优化模型输出上完全忽略了内核差异。结果同一段建模脚本在 A 内核里能成功拉伸成实体换到 B 内核就报拓扑错误。从那以后我养成了一个固定习惯所有生成结果都用同一套自动化回归脚本同时在两个内核上跑把兼容性问题提前暴露出来。每个团队选哪条路线没有标准答案但一定要在项目计划里给跨内核测试留出时间预算。4. 实操复盘我跑通的一个最小闭环方法论讲得再多都不如直接上案例。我复盘一下自己做过的 text-to-cad 最小项目目标是输入一个带四孔的安装板输出可编辑的 CAD 文件。整个链路跑通下来大致需要经历四个步骤任务拆分、提示词设计、生成与修复闭环、验证与导出。4.1 把任务拆成模型擅长的子问题第一次实验我直接甩给模型一句生成一个安装板结果输出了一个非常滑稽的、像积木搭起来的梯形块完全不是预想的样子。后来我仔细分析了失败原因发现问题出在我把一个非常模糊的目标直接丢给了模型它实在不知道安装板在工程语境里的具体含义。之后我把流程改了先把整个任务分解成模型更擅长处理的子问题把安装板先理解为底座平面加孔位阵列的组合再由模型推断四个孔的位置与尺寸遇到没有明确给出的参数先输出默认值并标注用脚本生成特征树和实体最后渲染出来供人工检查和修改。这个拆解的本质是扬长避短。大模型对三维空间直觉的把握还远不如人类工程师但它非常擅长把模糊需求映射到明确的操作序列。主动帮它拆分任务本质上是在降低推理难度也让我自己更容易定位出错环节——到底是理解错了解语义还是代码生成错了还是几何内核执行失败一目了然。4.2 提示词设计直接决定结果质量我在这个项目中使用的提示词模板大致长这样你是一个参数化 CAD 建模助手。你将收到一句用户的设计描述。请完成以下任务 1. 提取所有明确给出的尺寸、数量和空间关系 2. 对缺失信息给出符合工程常识的默认值并在结果中标注“默认” 3. 将建模步骤输出为 JSON 操作序列操作类型仅限于 base_extrude, hole, fillet, chamfer, pattern, boolean 4. 禁止在输出中添加任何解释性文字。这个模板不是随手写的每一条背后都有对应的理由。角色设定让模型进入工程师助手模式而不是自由创意模式输出结构固定后续解析脚本可以省掉一堆容错逻辑明确默认值要求是为了压制模型乱编尺寸的问题。我还在提示词里特意加了一条操作类型仅限于六种这种做法是在给模型减少选择空间。你可能会觉得这是限制创造力但在这个场景里恰恰是保护稳定性。文本生成建模本来就有很高的不确定性如果让模型自由发挥操作类型几何引擎执行时很容易遇到不支持的操作你需要限制一个安全的操作子集把出错率压低。4.3 生成与修复闭环比想象中更重要脚本生成之后直接执行十次里至少有三次会报错。这是我在项目里反复遇到的情况一点都不夸张。常见的报错类型有布尔运算失败、实体退化、尺寸参数超出有效边界。我的解决办法是给执行器外面包一层自动修复循环。执行失败时先把报错信息回传给大模型让它基于错误信息修正参数或操作顺序再重新执行。你可能觉得这样有点笨但实测下来两到三轮修复后成功率能从七成提高到九成以上。这背后的逻辑是让模型在错误信息里慢慢逼近正确结果比让它一次性生成完美代码要可靠得多。但这里有一个必须注意的问题每一轮修复都要做回归验证防止模型改好一个错误的同时又引入一个新的错误。比如为了让布尔运算能过模型可能把孔的位置偏移了表面看没问题但实际过孔位置已经偏离了原始描述。所以在修复循环里一定要在每次重生成后都跑一遍参数与原始描述的匹配检查。4.4 验证与导出别怕麻烦生成结果之后我习惯自动做三件事。第一检查实体体积是否在合理区间如果一个安装板的体积只有几立方毫米那大概率是参数单位搞错了。第二检查是否存在零厚度或退化面这个问题在机械结构里会导致网格剖分失败后续仿真根本没法进行。第三把模型的关键尺寸提取出来和原始文本做关键词对比用一个关键词匹配脚本自动检查直径有没有被理解成半径。验证通过后把模型导出成中性格式同时保留一份脚本源文件。这个细节很多人会忽视但特别重要——以后再改尺寸就是改脚本参数完全不用重新生成。也就是说text-to-cad 不仅仅是一个生成工具只要你保留中间脚本它就同时是一个参数化模板。5. 常见问题与排查实录这一节整理的是我在实际项目中遇到的高频问题基本都属于那种看起来没有 bug但结果就是不对的类型。5.1 模型生成的结果看着对但一检查尺寸全错在项目初期这个问题出现的频率最高。模型生成一个零件看起来有板有眼睛但对关键尺寸一检查发现全是模型自己编的原文里根本没有提到这些数值。这不是模型笨而是提示词没有明确要求尺寸必须来源于原文。解决办法是在提示词里强制加入规则如果原文中出现数值必须原样使用原文只说四个孔而不提尺寸则在参数列表里标注默认值或 None。另外解析 JSON 时不要直接信任字符串转数字要写一个类型转换函数统一接收整数、小数和带单位字符串。模型经常会把12mm输出成字符串 12mm 而不是数字 12一个容错解析器能帮你省不少事。5.2 布尔运算莫名失败这是机械结构建模里的经典毛病。两个实体明明看起来已经相交了几何内核却报错说无法求差集。实际原因往往是两个实体的某个面刚好共面或者存在微小的缝隙。处理思路有三种第一在布尔操作之前做微小偏移比如 0.001 毫米打断共面状态第二先用内核自带的修复功能整理拓扑再操作第三从源头上解决问题——在生成环节就要求模型给自己留一点建模余量比如打孔操作最好穿透整个板钻孔底部不要精确落在板表面。最后一点是设计习惯在 text-to-cad 的指令里加一条所有孔特征默认贯穿能让布尔运算的成功率明显提升。从工程角度也非常合理实际制造中没有哪台机床会允许钻头刚好停在板厚中间。5.3 刻度检查一切正常但用户说这不是我想要的这是最防不胜防的一类问题因为它不是代码层面的 bug而是语义层面的偏差。比如用户说支架心里想的是三角支撑结构模型理解成了 L 形弯板。这背后的原因是我们缺少对隐含前提的把握能力。我的经验是这种问题靠提示词优化解决不了必须在交互设计层面留出口。具体做法是在生成结果旁边提供部件类型切换和关键尺寸滑块用户不想改文字的时候直接拖动滑块就能调整模型参数。实际测试下来这种交互改造带来的满意度提升比单纯调模型算法大得多。本质上我们是把一次性生成完美模型的目标改成了快速生成可修调的候选模型后者要现实得多。5.4 生成速度慢到无法接受不少团队做原型时发现一个简单零件生成要 5 秒以上复杂一点的甚至要 30 秒。很多使用者等不了。这个问题往往出在修复循环上——每次执行失败后都要重新调用大模型一次失败就要多花好几秒。优化思路可以从几个角度下手一是给大模型增加缓存机制同样的操作序列和参数不去重复生成二是把固定操作序列比如多层拉伸、标准孔阵列写成原子模板避免每次从头调用模型三是针对高频特征做预编译把常见的法兰孔阵列底板圆角这类组合直接编译成函数库模型只用选类型加参数不需要重新推理整个流程。6. 应用场景与扩展空间6.1 面向制造前端的智能助手最直接的应用场景是产品概念设计阶段。工程师拿到需求后先借助 text-to-cad 快速拉出三五个候选方案再结合材料成本、加工工艺和装配约束进一步筛选。这个阶段对绝对尺寸精度的要求没那么高但关键是快和可改所以参数化生成路线比网格生成路线更合适。6.2 标准件与零件库的自动构建很多企业都有自己的零部件库维护成本颇高。用 text-to-cad 流程可以把订单描述直接转成三维模型入库配合自动化标注减少重复建模工作量。这类场景的数据相对规整描述也偏向标准化是现阶段最容易实现高准确率落地的场景。6.3 与仿真分析串联形成设计闭环更长远一点把 text-to-cad 的输出接到仿真工具做快速验证就形成了一个描述—建模—仿真—迭代的闭环。我在自己的实验里跑通过这样一个工作流输入安装支架的描述系统自动建模立即跑一次静力学分析发现应力集中区域后自动调整圆角半径再重新建模迭代。目前每一步的效果都还有优化空间比如自动判读应力云图的能力还不够聪明但这个方向本身已经可行未来想象空间非常大。6.4 教育领域给三维设计入门一个低门槛入口还有一个很多人没太注意的场景是工程教育。初学者学习三维建模时最大的障碍是对空间想象力和建模命令不熟悉。借助 text-to-cad学生可以先用自己的话来描述一个物体系统生成结果之后再展示每一步对应的建模操作和参数相当于一个建模语言翻译器。这种形式对教学的意义是在于降低了入门门槛让更多心思花在设计意图本身而不是工具操作上。个人体会做了这么久 text-to-cad 相关的事情我最大的感受是这项技术卡点其实不在算法本身而在工程系统的整合能力。模型能不能理解一句话很重要但更重要的是它能不能稳定产出能修改、能制造、能交付的模型。三者缺一个前面再惊艳的 demo 都只是 demo。如果你现在准备自己动手尝试我给一个最实际的建议不要一上来就追求自然语言描述的绝对自由。先固定一个小范围的任务比如板材孔圆角把完整链路跑通再逐步扩展特征类型。这个方向没有想象中那么遥远但也没有看 demo 时那么近需要亲手踩几次坑才能找到手感。希望这篇分享能帮你少走几步弯路。
