text-to-cad实战：从一句描述到可编辑B-rep模型的路与坑-北京尧图网络

做这行久了你会发现一个很有意思的现象凡是带文生两个字的AI工具落地时基本都要打三折。文生图能出海报但出不了印刷文件文生视频能出氛围但出不了成片。所以当text-to-cad这个词开始频繁出现时我本来也以为它只是又一个演示级玩具——直到我把一句我想要一个四孔定位底板M6沉头孔中心距40毫米的提示词丢进去几秒钟后拿回了一个能改参数、能出工程图、能直接丢进CAM软件做刀路的实体模型。那一刻我才意识到text-to-cad和前面那些文生完全不在一个维度上它生成的不只是形状而是一套完整的、可编辑的几何构造过程。这篇文章我不聊概念只聊实操把我试过的几条技术路线、三次真实翻车现场、以及现在我自己在工程里真正在用的混合流程全部摊开来讲。1. 先把生成的东西拆清楚text-to-cad不是文生图也不是文生网格1.1 它到底输出什么B-rep、特征历史、可编辑参数很多人第一次接触text-to-cad时脑子里代入的是文生图的逻辑——说一句话模型吐一张图完事。但CAD领域的产出物根本不是一个形状而是一份几何定义。这份定义里有边界表示法也就是常说的B-rep记录了每个面、每条边、每个顶点之间的拓扑关系同时还有一条参数化历史记录了这个零件是通过什么样的顺序一步步建出来的。用个不太严谨但好懂的生活化类比文生图给的是打印好的照片text-to-cad给的是PS源文件里面图层、蒙版、调整图层全都在你想改哪儿改哪儿。这带来的直接后果是判断一个text-to-cad工具好不好用不能只看模型预览像不像要看它导出的STEP文件能不能被主流CAD内核干净地读进去。我实测下来很多开源项目生成的模型在自家浏览器预览器里看着非常像回事一旦导入SolidWorks或者Fusion 360就会出现破面、烂边、实体无法缝合的问题。原因很简单预览器只显示了渲染外壳但底层压根没有建立完整的B-rep数据。换句话说它只是画了一个模型给你看而不是建了一个模型给你用。1.2 三个关键概念草图、挤出、特征树想让text-to-cad真正落地必须搞清楚CAD建模里最基础的三板斧。第一是草图也就是二维的线段、圆弧、圆、约束关系它决定了零件的基础轮廓第二是挤出、旋转、放样这类特征操作它们把二维草图变成三维实体第三是特征树它把前面这些操作按照先后顺序记录下来。目前大多数实用的text-to-cad工具本质上就是在做自然语言到草图加特征操作序列的翻译。一个标准的生成流程大概是模型先理解你的文字描述拆出尺寸、位置、孔洞、倒角这些信息然后生成带约束的二维草图最后调用挤出、打孔、倒圆角这类特征指令形成一个可以继续编辑的建模过程。注意这里的关键词是过程不是结果。一个只输出三角网格的text-to-cad工具哪怕生成速度再快、效果再炫也只能拿去3D打印看个样无法进入真正的产品研发链路。1.3 为什么说可编辑性才是核心指标我见过不少团队评估text-to-cad工具时首先看的是生成得逼真不逼真这是一个方向性的错误。对工程师来说一件事情的真正价值在于拿到模型之后能不能把板厚从2毫米改成2.5毫米能不能把四个通孔的位置整体往右移5毫米能不能在特征树里找到那个倒角并单独调整它的半径。如果不能那这个模型就只是一个固定的几何体它的价值和一个STL扫描模型没有本质区别。可编辑性决定了这个模型是设计资源还是一次性消费品。目前市面上真正成熟的text-to-cad方案都会在输出里保留参数化历史最典型的是生成一个CAD程序或者特征指令列表你拿到之后还能回头改参数。我在实际项目里最看重的就是这一步生成结果导入之后我在CAD软件里能否双击特征、修改草图中的尺寸并且整个模型能够自动跟随更新。能说明工具进入了可用区间不能那它还在玩具区间我会毫不留情地在评估表里打叉。2. 目前行业的四种实现路线我逐一对比过2.1 端到端生成模型用噪声预测操作序列第一种路线是训练一个深度学习模型直接学习从文本到CAD建模操作的映射。这条路线的代表作有Text2CAD、CAD-MLLM这些底层通常基于扩散模型或者自回归Transformer训练数据来自DeepCAD这类大型CAD数据集。DeepCAD里面的数据长什么样呢它把Fusion 360或者SolidWorks里的模型扒下来转成草图加挤出操作序列每个模型对应一串离散的建模指令。从原理上说这种端到端模型做的事情很像语音听写你说一句话它把它翻译成一串建模动作。问题也出在这里自动语音识别还有一个词汇表可以做约束而CAD建模指令的组合空间几乎是无限的模型很容易学着学着就开始自由发挥。我复现过其中一个开源项目生成的模型在简单拉伸类零件上表现还不错比如平板、阶梯块、法兰盘一旦描述里出现多个不同方向的特征或者有复杂的约束关系输出的指令序列就开始变得不合逻辑经常出现拉伸方向反了、草图没有完全约束导致后面特征跟着错位这类低级问题。这个路线的优势是自动化程度高、输入门槛低劣势是通用性差、稳定性不够目前更适合学术界继续往前推生产环境里用它还是要慎之又慎。2.2 大语言模型直接写建模语言Zoo text2cad这条路第二种路线是大语言模型直接写建模语言。代表就是Zoo的Text to CAD底层思路是把CAD建模表达成一种结构化的DSL让GPT这类大模型去生成这个DSL代码再有专门的几何内核把它解释成实体模型。你可以把它理解成让大模型代替你写建模脚本出来的不是一个裸模型而是一段可以回放、可以改参数的建模程序。这个路线的体验很有意思。你输入一句一个带中心孔的圆形法兰外径80毫米内径25毫米边缘均布4个M6通孔它不直接给你一个网格而是返回一段描述建模过程的代码或者JSON结构Zoo自己的查看器会解析这段结构实时构建出模型。我实际用下来它对几何描述的理解能力确实强尤其是尺寸和数量这类信息基本不会漏但代价是你得先把需求说清楚。越是工程师产品经理写需求文档式的大白话它的表现越好越是那种帮我搞个好看的外壳的模糊口语它就越容易在无意义的地方自由发挥。对设计流程来说这反而是可以接受的因为工程师本来就要先把自己的需求量化成具体参数。2.3 CAD二次开发脚本路线门槛最低但最可控第三条路线最朴素直接用自然语言让大模型生成OpenSCAD、FreeCAD或AutoCAD的建模脚本。OpenSCAD本身就是用代码描述几何的工具天然适合作为大模型的输出目标AutoCAD有AutoLISPFusion 360有Python APIFreeCAD也有Python脚本接口。你把一个写好的CAD脚本模板喂给大模型让它按你的描述去改参数、加特征然后本地运行脚本生成模型。这条路线最稳也最容易在小团队甚至个人项目里落地。因为大模型不直接操作几何内核它只负责生成一段普通文本代码任何语法错误、逻辑错误都能在脚本执行阶段暴露出来不会出现界面看着对、底层几何烂掉的情况。我拿OpenSCAD做过一个验证性项目让大模型生成一个带散热槽的外壳底板输出.scad文件后本地打开直接就能预览还能通过参数调节槽的数量和宽度。整个过程可控出了问题很好定位是代码的问题还是描述的问题不会像端到端模型那样一翻车就完全黑盒。对大多数工程师来说这条路线是理解text-to-cad成本最低的切入点。2.4 四条路线放在一起对比路线输入输出形态可编辑性上手成本落地稳定性端到端扩散模型自然语言建模操作序列中取决于特征历史是否完整高需要跑模型训练低简单件尚可、复杂件易崩LLM加建模语言自然语言结构化CAD程序高程序本身就是参数化历史中依赖商用API中高描述清晰时很稳CAD脚本生成自然语言加脚本模板OpenSCAD/Fusion脚本高脚本即历史低只要懂基础语法高输出可明确定位命令宏调用自然语言原生命令流较高但依赖CAD版本低中换软件版本容易挂需要泼一盆冷水的是目前没有任何一条路线能做到放之四海而皆准。我在评估时一般不问哪条路线最好而是问我手头的场景适合哪条路线。比如要给客户做概念方案对比用LLM加建模语言最合适要给老工程师做一个重复率高的制图辅助工具CAD脚本生成反倒是性价比之王。3. 实操笔记我把一个零件从中文描述变成STEP文件的全过程3.1 先用Zoo的Text to CAD跑通第一遍为了验证text-to-cad在真实工作流里的表现我挑了一个非常常见的零件一个100毫米乘以60毫米的铝板支架厚度2毫米四角有R5的圆角底部有四个直径6.5毫米的通孔孔中心到边缘的距离是10毫米。我把这句描述输入Zoo的Text to CAD界面等了几秒钟系统返回了一个预览模型。模型看起来没问题但我不看这个我只看两件事。第一导出STEP文件是否成功第二把这个STEP文件导入Fusion 360后特征树长什么样。结果让我比较意外它没有直接给我一个焊死的实体而是给了可编辑的建模过程里面有草图、有拉伸、有打孔孔的参数也能改。我把一个孔的直径从6.5改成7模型自动更新没有报错。这种体验和几年前那些文生3D模型工具完全不一样那些工具给的是网格文件你只能在MeshMixer里像捏泥巴一样处理而这个至少能进入标准CAD管线。当然它的缺点也很明显。整个交互必须用英文对中文描述的支持还不完善我后来用中文输入同样一句话输出的模型出现了明显的特征错乱。另外它对复杂装配体的描述支持有限我试过描述一个由底板、侧板和加强筋组成的U型焊接件它反馈说当前版本更适合单体零件装配场景需要额外处理。总的来说如果是简单机械零件Zoo这条路已经具备在概念阶段试用的价值但离替代工程师做详细设计还差得远。3.2 用LLM加OpenSCAD做穷人的text-to-cad由于商用text-to-cad服务有次数和数据安全限制我另外搭了一套更可控的方案让大模型输出OpenSCAD代码。OpenSCAD的语法简单到像写作文它本来就是一个把几何描述写成代码的工具。我给模型的提示词也不复杂就是一段带占位符的建模脚本模板加上一句根据以下描述修改参数并补全模型。第一次尝试我让它生成一个带有四个安装孔的L型角码。模型给出了完整的.scad代码核心逻辑是定义length、width、thickness这些变量然后用linear_extrude把二维轮廓拉起来再用cylinder加上通孔。我把代码保存成一个.scad文件在OpenSCAD里按F5刷新模型直接出来了。整个过程不到五分钟。更关键的是OpenSCAD的语法错误会明确指出来不会出现端到端模型那种看起来对但内部烂掉的情况调试思路非常直观。如果你是个人开发者或者小团队想在内部快速搭一套text-to-cad服务我强烈推荐先从这个方案试起成本低、透明、可控。3.3 现阶段最稳的组合LLM抽参数加参数化模板跑完前面两个实验我慢慢意识到真正在生产环境里效率最高的方式不是让AI从头到尾自由发挥而是让AI做它最擅长的事情把自然语言里的规格参数提取出来填充进一个预先做好的参数化CAD模板里。这就好比做饺子皮和馅都是现成的AI只负责把一个个客人随口说的韭菜猪肉、多放葱、咸一点翻译成具体配比。具体做法是你先在CAD里搭好一个参数化模板比如一款标准支架把板厚、孔距、孔数、长度、宽度这些变量全部定义成参数然后用大模型做一个简单的信息抽取把用户描述里的尺寸和约束填到JSON里最后用脚本读JSON驱动CAD批量生成衍生模型。这套流程在稳定性上吊打一句描述直接生成整个模型因为大模型不直接决定拓扑结构它只填参数填错顶多是尺寸不合理不会造成几何崩溃。我在实际项目中用Fusion 360的API做过类似验证一早上让AI处理了20条客户描述生成了20个变体模型其中只有2个因为描述里缺少孔距信息需要回头确认。要是靠纯手工建模这批活儿起码要干三天。这个数字很能说明问题text-to-cad的合理定位不是取代设计师而是把重复性的参数化变体工作自动化。4. 三个真实翻车案例比任何宣传资料都有教育意义4.1 翻车一生成的实体看起来完整实际上是一块坏几何第一次用端到端模型生成一个带侧向安装槽的电机座时预览器里模型非常漂亮槽的位置和大小都对。我没多想直接导出STEP丢进另一个CAD软件准备加倒角结果系统连续报错说无法将曲面缝合为实体存在非法边。检查之后发现模型内部有几条边重叠交叉面与面之间存在微小的自交。这种问题在预览器里根本看不见因为渲染只是显示视觉表面不会去做实体合法性校验。这件事给我最大的教训是从text-to-cad工具里导出的任何一个文件在进入正式流程之前必须用传统CAD内核做一次完整的体检。所谓体检就是导入后试着做实体操作比如布尔运算、圆角、薄壳拉伸只要任何一步报错这个模型就要打回去重新生成。不能因为预览看起来没问题就直接发给供应商供应商会把文件打回来的而且打回来的时候往往已经是项目时间最紧张的时候。4.2 翻车二单位、公差和基准信息在描述里丢失第二个翻车案例更隐蔽发生在单位上。我给同一个工具分别输入了两句描述一句话里写直径12毫米的轴孔另一句话里写直径12英寸的轴孔。第一次输出的是一个直径12毫米的零件第二次我本以为它会转换单位结果它直接生成一个直径12单位的孔而默认单位用的是毫米。这意味着第二句话被当成12毫米处理英寸完全被忽略。更麻烦的是有些工具对被描述为通孔的特征会默认加公差有些则完全不加生成出来的孔连间隙配合都做不到。在机械设计里单位、公差、基准面这些信息决定了零件能不能被制造出来。当前大多数text-to-cad工具对这些信息的敏感度非常低它们更擅长处理形状描述不擅长处理工程语义。所以我的建议是任何对外形有精密配合需求的零件不要把text-to-cad的输出当作最终结果它只适合做方案阶段的参考工程师需要在传统CAD环境里把公差、基准、表面粗糙度重新标注一遍。4.3 翻车三特征顺序乱了倒角变成自交面第三个翻车案例让我记忆深刻因为它发生在最不该出问题的简单零件上。我给一个text-to-cad工具描述了一个带中心通孔的法兰盘要求孔的两端做C1倒角。生成的模型在没有倒角的步骤前一切都正常但最后一步倒角直接导致实体自交报错。我打开它生成的特征历史才发现模型把倒角放在最后一次布尔运算之前倒角的边界没有正确匹配上孔的轮廓于是整个特征链崩了。这个问题的本质在于CAD里很多特征的先后顺序是有强约束的倒角通常要放到最终形态之后打孔之前还是之后也直接影响结果。端到端模型在生成操作序列时往往缺少这种特征顺序的推理能力它只知道要做这些操作不知道操作之间的依赖关系。现在我再看到text-to-cad生成的模型第一件事就是打开它的特征历史检查每一个特征的父亲节点和先后顺序。顺序合理的模型编辑起来才顺手顺序乱的模型就算形状对了改起来也让人想砸电脑。5. 如何把text-to-cad塞进自己的工程流程而不翻车5.1 第一个最佳位置概念阶段的批量变体以我目前的实践来看text-to-cad最适合放在概念设计阶段尤其是需要大量变体比对的场景。客户说想要一款更小、更轻、安装方式不变的支架传统做法是CAD工程师花一下午改尺寸出三稿现在我可以把客户的原话扔进去让它一口气生成六八个参数不同的变体快速筛出两个靠谱方向再让工程师在传统CAD里精修。这个阶段出错成本低就算模型生成得不好也只需要重新描述一次不会造成实际损失。批量变体还有一个额外的好处它能倒逼团队明确需求边界。因为提示词写得不清楚AI生成的结果就一定乱七八糟这反而逼着产品经理把更小、更轻翻译成长度减少20%重量不超过200克。这个过程本身就是对团队需求管理能力的一次提升。5.2 我固定保存的质检清单在把AI生成模型纳入正式流程之前我给自己定了一个固定的质检流程每一步都不能跳过导入主CAD软件确认系统识别为实体而不是曲面能选中内部体积。尝试进行一次实体布尔运算比如切割一个孔检查是否会报错。打开特征历史确认每个特征都有明确父节点顺序符合B-rep建模规范。修改一个关键参数比如板厚或孔距确认模型自动更新且不崩。用测量工具校准几个关键尺寸和原始描述做比对。如果涉及装配把STEP文件放进整机装配体检查干涉和配合面。这套清单看起来简单但它能拦住我上面说的绝大多数翻车。我用它筛掉了差不多三分之一生成模型其余三分之二才敢继续往下走。5.3 数据安全、许可与边界判断最后提醒一句用text-to-cad服务时数据安全往往是被低估的问题。我见过不少公司直接把内部图纸描述复制粘贴到在线工具里生成结果确实方便但描述文本里往往藏着产品结构、尺寸链、材质选型这些核心信息。对外部的在线服务我的原则是敏感设计一律不传最多用它验证思路真正要用于内部流程的数据必须走私有化部署或者上面说的本地脚本方案。这也是为什么OpenSCAD那套穷人的text-to-cad在工业环境里更受青睐数据不离开内网比任何功能点都重要。6. 我现在实际使用的人机分工方法6.1 分工原则模型做结构人类做决策磨合了半年多我自己对text-to-cad的使用原则已经非常明确AI负责结构性重复的活人类负责判断和决策。凡是照着描述把参数填进既有模板这类事全部让AI干凡是这个设计是否合理、这个配合是否可靠、这个工艺能否实现这类事坚决自己拍板。这个分工让我的效率提升了不止一个档次同时也守住了设计质量的下限。我目前的工作流非常固定先用LLM加参数化模板批量生成变体再用CAD质检清单筛选最后把合格的模型交给工程师做详细工艺评估。整个过程里text-to-cad不是一个替代者而是一个极其高效的解析器——它把语言转换成模型的脏活累活都接过去了留下来的核心决策依然在人手里。6.2 给刚接触text-to-cad的人三句话如果你现在刚准备尝试text-to-cad我给三句实在的建议。第一不要迷信预览器把文件导入传统CAD软件里做一次真刀真枪的编辑这比任何演示都有说服力。第二从OpenSCAD或参数化模板这种半自动方案起步稳定的可控性比炫酷的端到端更重要。第三把每一次失败案例记录下来整理成自己的提示词手册里面写清楚什么描述能生成稳定结果什么描述会翻车这份手册的参考价值比任何官方文档都高。我自己的体会是text-to-cad真正开始变得有用不是从它能一次生成完美模型那一刻开始的而是从我承认它生成不了完美模型那一刻开始的。承认它的边界把它放在对的位置上它立刻就从玩具变成了生产力工具。以后你再听到一句话生成CAD模型的宣传不妨先问一句能改参数吗特征树能编辑吗能过实体校验吗这三个问题能帮你省下大量试错时间。

text-to-cad实战：从一句描述到可编辑B-rep模型的路与坑

相关推荐

HarmonyOS 7 textSearchImage：相似度门限样本校准与空结果降级

为AI助手配置外置记忆：claude-mem 实现跨会话上下文保留的完整指南

claude-mem：为 Claude Code 搭建跨会话长期记忆的 MCP 方案

更多资讯

4800张真实废弃物图像分类：从数据清洗到迁移学习全流程实战

串口为何在IIoT中不可替代？从物理层到组网的实战经验解析

MNIST手写数字识别实战：PyTorch搭建CNN神经网络与训练避坑指南

飞腾D3000+银河麒麟：116英寸国产红外触控物资看板部署实战

JSP物资管理系统实战：架构、数据库与部署避坑指南

工业级电源路径主动防护设计：电子保险丝与MCU协同方案

今日更新

Agent Skills 完全指南：原理、写法、安装与实战避坑

Agent Skills 实战：从 Genkit 定义到 GKE 部署与排查

Agent Skills 实战：从设计到调试的完整指南

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？