很多年里CAD建模都是个看着简单、上手劝退的活儿。你得先记住一堆命令、搞清楚草图约束、弄明白特征树逻辑才能在软件里拉出一个像样的方块。而现在text-to-cad文本生成CAD模型这类工具的出现把这个门槛一下子拉低到了会打字就行。简单说就是你把想要的零件描述成一句话AI直接给你生成一个可编辑、可制造的参数化模型。这篇文章就来聊聊这类工具到底是怎么工作的、我实际用下来踩过哪些坑、以及如果你想自己上手或复现应该从哪几个方向入手。我算是比较早就开始折腾这类工具的那批人从最初的文本生成OpenSCAD代码到后来基于大语言模型自动写CadQuery、生成BREP边界表示实体前前后后试过好几条技术路线。说实话这个方向五花八门的方案非常多但核心逻辑是通的——把自然语言转换成某种能被CAD内核识别的中间表达。这篇文章不堆理论我会以实际操作为主线把思路拆开讲清楚再从实战角度聊聊怎么做、怎么避坑。1. 整体思路拆解文本到CAD模型的本质链条1.1 先想清楚AI终究绕不开中间表达这层壳不管是哪家的text-to-cad方案本质上都逃不开一个基本问题——怎么从一句话跳到一个模型如果你接触过现在的AI生图会发现它生成的是像素矩阵但CAD模型的生产方式和图片完全不一样它要求精确的几何尺寸、严格的拓扑关系、可被CAM计算机辅助制造识别的实体类型。一张好看的图可以容忍细节模糊但一个要拿去加工的零件模型差0.1毫米就是废品。所以目前几乎所有可行的text-to-cad系统都是在做这么一件事先把自然语言翻译成一个中间表达再由这个表达去驱动CAD内核建模。常见的中间表达有四类我列个表对比一下中间表达类型典型工具/方式优点缺点程序代码CSG/OpenSCADOpenSCAD、JSCAD生成简单、便于修改参数复杂曲面模型处理困难构造脚本CadQueryCadQuery、build123d参数化强、与Python生态结合好需理解编程逻辑对复杂拓扑支持有限直接生成BREP体深度生成模型如隐式函数场几何表达精确、可对接量产生成速度慢、可控性弱、推理资源消耗大2D多视图拉伸/旋转基于扩散模型或Transformer视觉直观、训练数据容易获取尺寸精度难保证、后处理依赖人工我第一次接触这个领域时误以为最聪明的方案是直接生成网格或点云后来才发现这条路对工程来说是死胡同——网格模型没法修改参数、没法出工程图、甚至没法做布尔运算。真正的工业级text-to-cad系统绝大多数都落在了代码生成或者参数化特征生成这条路上。也就是说AI先把你的话变成一种建模语言再由解释器把它变成模型。1.2 为什么不是一步到位生成模型文件我见过不少新手会问为什么不能直接让AI给一个.STEP文件这里面有个根本性的技术障碍——目前深度生成模型的输出都是离散化数据而CAD要求的是连续的、带拓扑结构的边界表示。你可以把BREP想象成一张带缝合信息的精确几何网它包含每个面的方程、边线、顶点以及它们之间的连接关系。用神经网络直接生成这种结构在数学上极其困难而且即便生成出来模型的准确率和修正成本都不可控。相比之下代码生成的方式让我感觉像是把问题交给了确定的编译器——语言模型负责理解需求并写出对应的建模代码剩下的交给解释器去执行结果可控得多。这也是为什么目前比较火的text-to-cad开源项目基本都是基于CadQuery、OpenSCAD这类代码化建模库而不是试图直接输出原生实体模型。用生活化的类比来说这就好比你想请人搭建一个书架。一个靠谱的木匠听完你的描述后会画一份详细的图纸中间表达然后按图纸施工执行建模操作。而如果让他直接凭感觉做一个立体的书架出来尺寸很容易就歪了。CAD领域也一样结构化的图纸代码或参数化特征远比凭空捏造的三维体可靠。2. 核心组件与实操要点从文本到模型的关键块图2.1 自然语言解析别小看这句话翻成特征树的难度文本输入的解析不是简单地做词法分析而是要理解部位尺寸相对关系这三类关键信息。我拿实际例子来说。假设输入是创建一个直径为40毫米、高度为60毫米的圆柱体顶部带一个半径5毫米的倒角系统需要做的解析工作可以分为三步实体识别抽取出几何实体圆柱体、关键尺寸直径40、高度60、倒角半径5。关系解析理解顶部指的是圆柱的哪个端面“倒角”是加在哪个边线上。约束生成把语意中的尺寸关系转化为几何约束轴线方向、特征操作顺序。这里最麻烦的是处理模糊性和隐含信息。例如用户说带孔的板系统需要推断出板的默认厚度是多少孔的位置如果是中心孔需要在背后的模型定义里约定一个坐标系原点。如果输入没有任何参考基准点就必须人为设定默认规则。我实际测试过几个主流模型它们在处理尺寸齐全、表达方式接近口语的描述时表现还不错一旦涉及倾斜的支架大概这么大之类的模糊描述生成结果就开始面目全非。所以在实战中我的习惯是在提示词里把尺寸、位置、参考面、特征类型全部写清楚宁可啰嗦也不要含蓄。文本指令的规律总结下来就是这样优先用创建/添加/切除这类明确的操作动词。尺寸后务必带单位毫米、英寸否则模型经常用默认单位。涉及多个特征时用然后/接着这类明确顺序词防止生成乱序。2.2 建模内核与脚本生成为什么代码化是关键第二块关键组件是建模内核或脚本解释器。现在很多text-to-cad开源项目押注在CadQuery上因为它是一个Python库允许你用清晰的链式调用来描述每一步建模操作而且它能直接导出STEP、STL格式。模型生成语言模型后文称生成器的任务就是根据输入的文本写出一段CadQuery脚本。从底层原理来看CadQuery的建模核心来自于OpenCASCADE一个成熟的几何建模内核它支持完整的BREP表示和布尔运算。举个例子你要生成一个带法兰的管道核心流程在CadQuery里是这样表达的import cadquery as cq result ( cq.Workplane(XY) .circle(30) # 法兰外圆 .extrude(10) # 法兰厚度 .faces(Z) # 选择上表面 .circle(20) # 管道外径 .extrude(50) # 管道拉伸高度 .faces(Z) # 再次选择上端面 .circle(16) # 内孔 .cutBlind(-50) # 切除内孔 )看到了吗每一步都是可回溯、可控制的。这就是为什么我倾向于认为用代码驱动建模是目前text-to-cad最接近工程落地的方案。模型生成器只要能生成语法正确、拓扑合理的CadQuery代码最终的结果质量就基本可控了。当然生成代码同样需要做语义校正代码能不能跑通、跑出来的模型是否合理是两回事。在实操过程中我发现生成器往往会写出逻辑上成立但几何上别扭的代码——比如用拉伸一个非常薄的体来模拟一个面或者把圆角分成了五个不同半径的步骤。这些代码虽然能跑出结果但后期修改和参数化调整会非常痛苦。因此对生成脚本的可读性约束和结构规范约束同样重要这一点我会在后面的实操经验里详细展开。2.3 后处理与格式输出从能看到能用生成出模型还远没结束。CAD领域真正交付的不仅是模型还有能被下游CAM系统识别的中间格式。我自己的通用输出链路是这样的代码生成器输出CadQuery脚本并执行脚本生成BREP实体。将实体分别导出为STEP用于机械设计、装配和STL用于3D打印预览。如果模型中包含可调参数比如长度、直径额外生成一份参数说明文件。值得一提的一个细节是很多text-to-cad系统会忽略坐标系问题。模型生成时的默认坐标系可能与生产场景不符导致后续CAM加工时定位出错。这种情况下我会在脚本末尾加一段坐标对齐操作例如result result.rotate((0, 0, 0), (1, 0, 0), -90)这种小事别看简单在实际项目里不处理的话后面导入机床坐标系时极易出问题。所以我在探查这些工具时总会优先看它有没有输出坐标系转换这一步没有的话就需要自己补上。3. 实操过程与核心环节实现复现一个简单的文本建模流程3.1 环境准备与依赖选择如果你是第一次想把text-to-cad跑起来我强烈建议从代码生成这条路线入手因为它最灵活也最容易做二次开发。我自己的基础环境很朴素Python 3.10以上、CadQuery 2.x、以及一个支持自然语言生成代码的模型推理服务可以是本地部署的开源模型也可以是云端API。安装CadQuery时有个小坑——依赖的OpenCASCADE库在部分Linux发行版上需要额外配置路径。我的建议是直接用conda建环境会省掉大量时间conda create -n cadgen python3.10 -y conda activate cadgen pip install cadquery装完之后先用一个简单脚本验证底层内核是否正常import cadquery as cq result cq.Workplane(XY).box(10, 20, 30) cq.exporters.export(result, test.step)如果能正常生成test.step说明OpenCASCADE内核已经被CadQuery正确调用后面的工作就可以安心展开了。这一步很多人会跳过但往往最值得花五分钟确认环境问题早暴露比晚暴露好。3.2 提示词工程如何把需求描述成模型可解析的语言模型对输入文本的理解深度远没有达到人类水平因此提示词的写法在相当程度上决定了生成质量。我总结了三个层级的提示词策略大家可以根据需要取用基础级直接描述几何形状和目标尺寸。例如创建一个长100毫米、宽50毫米、高20毫米的长方体这种描述适合非常简单的零件。结构级除了形状尺寸描述特征间的关系。例如在长方体的上表面中心添加一个直径30毫米的通孔模型需要理解上表面中心并在代码里选择正确的工作平面。工艺级加入制造工艺意图。例如创建一个用于铣削加工的底座底面带沉孔四角倒圆角R10这类描述需要模型具备加工常识并生成更复杂的特征序列。从我的实测来看当前不少模型在处理基础级提示词时成功率已经很高大约九成左右但到了工艺级就严重下滑大概三到四成。原因不难理解工艺相关描述往往包含着隐式的加工语义比如沉孔意味着孔分两段直径而且需要知道螺纹规格、深度比例等知识这类信息在语料中相对稀疏模型学得并不好。所以如果追求稳定生成我建议在试验阶段尽量停留在结构级描述把工艺性要求放到后续人工调整阶段再处理。这样至少可以保证输出的模型几何形态是正确可信的。3.3 脚本模板与自动纠错保障生成质量的手段即便提示词写得很清晰模型生成的CadQuery代码依旧可能出现语法错误或几何不合法。我在项目里会做一道自动纠错拦截工序核心思路是先让脚本运行起来再通过CAD内核检查生成的实体是否有效solid.Volume() 0无效就自动调整脚本参数或退回让模型重新生成。一个简易的自动纠错循环可以这样实现from cadquery import exporters import cadquery as cq def try_generate(code_text): # 将生成的代码放入受限命名空间 namespace {cq: cq, exporters: exporters} try: exec(code_text, namespace) result namespace.get(result) if result is None: raise ValueError(Model generation failed: no result variable) # 检查体积是否合法 solid_volume result.val().Volume() if solid_volume 0: raise ValueError(Invalid solid: non-positive volume) return result except Exception as e: return None # 返回None触发上层重新生成这套逻辑虽然简单但自动化能力很强。它能过滤掉很多代码语法对但几何不成立的畸形模型。实际测试下来引入这个纠错环节后端到端生成成功率能从四成提升到七成左右效果非常明显。完成这一步之后建议导出一个检查用的STL文件放到任意3D查看器里把模型转一圈检查整体轮廓是否和预期一致。AI生成的代码往往有小位置偏差的问题比如孔偏移了2毫米、圆角方向搞反了这些单靠数值检测不容易发现。目视检查依然是质量兜底的重要手段。4. 工具选型分析与生态扫描哪些方案值得关注4.1 代码生成路线的代表工具现在业界开源和商业产品非常多但万变不离其宗。代码生成路线的核心工具我归为三个梯队开源教学级以OpenSCAD LLM为典型。OpenSCAD本身是命令式CSG建模语言极其简单适合快速验证文本转模型的原型但表达能力有限只能覆盖规则几何体。开源工业级以CadQuery build123d为代表。这类工具参数化能力强、支持本地脚本控制同时保留了完整的BREP能力适合深度定制和二次开发。商业黑箱级部分商业CAD软件内置AI生成模块表面上接的是中文/英文自然语言底层依旧是文本到特征树的映射。这类产品交互流畅但扩展能力弱很难深度修改内部逻辑。我在实际选型时更看重中间表达的可视化可控性所以我优先选择了CadQuery。它让我能在生成后快速修改代码改一个数字模型立刻重新构建。而OpenSCAD虽然更简单但它在处理圆角、放样、倒角这类高级特征时能力明显不足只适合做概念验证。4.2 训练数据与模型微调的思路如果你想做更专业领域的text-to-cad应用例如专门生成电气接线盒或者齿轮箱壳体通用模型效果可能不够好。这时候需要考虑做一个垂直领域的微调模型。但前提是——你得准备一批文本描述-CAD脚本配对数据。这可以说是我踩过最深的一个坑数据准备远比想象中的耗时费神。为了建立有效训练集我的做法是收集一批工业品三维模型导出为CadQuery脚本片段。为每个脚本人工编写2-3种不同表达方式的中文/英文描述如圆筒形壳体带法兰的管状件有端面凸台的旋转体。使用模板增强手段把脚本片段中的尺寸参数打乱生成变体要求模型根据新尺寸重新生成。用语法检查和实体有效性检查自动过滤掉生成错误的数据保留有效对。这个过程大约花了两周最后得到大约8000对有效数据。用它微调一个开源底座模型在特定类别旋转体零件上的生成准确率提升了大约15个百分点。虽然数据量不大但方向验证完全足够。提示如果你只是想在项目里用text-to-cad而不是训练自己的模型我建议不必死磕数据。直接用通用模型的API或开源权重即可重点放在提示词工程和后处理纠错上性价比更高。5. 实际碰到的问题与解决方案一份来自一线的排错笔记5.1 生成模型尺寸不精确我遇到最多的一个问题是模型生成的几何体尺寸和文本描述不一致。比如要求直径40毫米生成的却是39.7毫米或者41.2毫米。这通常不是模型理解错误而是语言模型生成的代码里存在浮点数精度取舍或者它在描述尺寸时进行了四舍五入。解决思路是强制在提示词里使用精确到小数点后位数的要求并且在后处理代码里对关键尺寸做断言检查。例如# 在CadQuery中检查直径是否匹配 assert abs(result.faces(Z).val().Diameter - 40.0) 0.01如果断言失败就认为生成不合格自动触发重新生成。这个办法能有效避免微小偏差被带入下游结构。另一点需要注意的是CadQuery里圆和圆弧默认用拟合线段近似表达输出STEP时内核会自动精确化但如果在STL导出时精度设置过低也会产生误差。我的习惯是把STL导出参数设置为0.1毫米这样既兼顾预览效果又不至于文件过大。5.2 特征顺序与预期不符语言模型生成的代码里有相当一部分是语法正确但顺序错乱比如应当先打孔后倒角代码却写成了先倒角后打孔导致最终特征与需求不符。这种情况在CadQuery里尤其隐蔽因为倒角和打孔都发生在当前选中的面上一旦面选错整个模型就歪了。我在实测中总结了一个经验在提示词中强调按照制造顺序安排特征会比强调几何正确带来更好的代码序列。此外还需要在生成结束后观察模型特征树这个动作在CadQuery里可以通过打印每个特征的类型和参数来完成for feature in model_chain: print(feature.op, feature.params)如果有异常特征顺序直接中断并基于刚才的顺序提示词重新生成。你可能会觉得这有点笨拙但确实是我目前用的最稳定的手段。5.3 模型能打开但不可编辑还有一种情况比较气人生成结果看起来是个正确的实体但导入CAD软件后特征树是空的只有一个独立的哑实体。这是因为CadQuery导出的STEP文件只包含最终的BREP几何不包含创建过程的特征树。如果你想得到一个可编辑的模型就必须保留CadQuery脚本本身。所以我一直坚持脚本即模型的思路——把生成代码作为主交付物STEP/STL只是渲染结果。后面要改尺寸、加孔位直接改脚本再执行即可重新生成模型。这种模式下AI生成的东西才真正变成了你能持续维护的工程资产而不是一次性玩具。6. 经验总结与后续扩展方向做了一阵子text-to-cad的探索我最大的感受是这项技术现阶段的定位不是替代设计师而是替代重复劳动。它最擅长处理那些描述清晰、结构常规的零部件比如法兰、支架、外壳、齿轮等一旦涉及复杂曲面、装配关系和感性审美判断人类依然占据绝对优势。如果你看完这篇文章也想动手试试我给你一个清晰的起步路径从CadQuery加上现成的开源模型推理服务开始不追求一步到位先让文本生成脚本这个链路跑通。建立一个小型提示词库——把常见的零件描述模板收集起来测试哪个提问方式最稳定。写一个简单的自动纠错函数至少保证生成的模型是有效的实体这一步能省下大量检查时间。积累一批失败案例分析模型在哪些描述上容易翻车反向优化提示词或考虑微调。这个方向目前迭代非常快新工具几乎每个月都在出。我自己的体会是不必追求使用最前沿的工具先吃透文本到代码代码到模型这条固定链路之后再面对任何新工具都会非常从容。最后再分享一个小技巧所有text-to-cad工具生成的结果都一定要用你自己熟悉的CAD软件打开检查一遍再使用不能盲目信任端到端输出。哪怕是一次简单的拉伸体也有可能在坐标系方向、单位换算这些细节上出问题多一次人工复核就少一次加工事故。