做CAD设计的这几年我一直在关注AI辅助建模的进展。今年有个方向让我觉得特别值得投入时间研究就是text-to-cad——用自然语言直接生成CAD模型。听起来像科幻但实际上已经有能跑通的开源项目和商用API效果虽然谈不上完美但在机械零件、标准件、简单壳体这些场景里已经能显著提升前期方案设计的效率。这篇文章我打算用一个下午能读完的篇幅把text-to-cad从原理到实操拆开讲清楚。内容包括它到底干了什么事、为什么它能生成带尺寸的模型而不是一堆好看但没法用的三角网格、目前靠谱的工具链怎么选、一个能直接跑的Python调用示例、以及我在实际测试中踩过的坑和排查思路。如果你有CAD参数化建模基础或者正在做AI辅助设计的方案调研这篇文章应该能帮你省不少试错成本。1. 内容整体设计与思路拆解1.1 text-to-cad到底在解决什么问题传统CAD建模的核心痛点在于设计意图到几何表达之间的鸿沟。你脑子里想的是一个带四个安装孔、底部倒圆角、总高40mm的支架但落到SolidWorks或FreeCAD里你需要依次创建草图、标注约束、拉伸、阵列、倒角。这个过程不是“设计”而是“表达”——真正的设计决策其实在你打开软件之前就已经完成了。text-to-cad的思路就是把这个“表达”环节自动化输入一段描述输出一个参数化CAD模型。但这里有个关键区分——它输出的不是普通文本生成3D的那种网格模型比如用扩散模型生成的OBJ/STL而是真正的BREP实体模型包含草图、约束、拉伸特征、倒角这些建模历史。这意味着生成的模型可以继续在CAD软件里编辑、标注、出工程图也能直接丢进CAM做加工路径规划。我接触这个方向的第一个疑问是AI凭什么能生成带精确尺寸的模型答案是它不是在“画几何”而是在“写程序”。目前主流方案把CAD建模过程设计为一连串程序化的建模指令模型只需要学会生成这些指令序列就能在底层引擎里重建出实体。这个思路决定了它的能力边界生成的模型精度取决于指令系统能表达的范围而不是AI对几何空间的直觉。1.2 为什么选择“程序合成”而不是“直接生成几何”我在测试不同实现时发现这个方向存在两条技术路线一条是直接用深度生成模型输出体素或点云再走曲面重建另一条是先生成建模操作序列再用CAD内核执行。前一条在视觉上更自由能生成有机曲面但输出的是网格尺寸精度差后续编辑能力基本为零。后一条更符合工程习惯但受限于预定义的建模操作集合。我自己更偏向后者原因是工程场景里我们需要的不是“像”而是“对”——尺寸要对、孔位要对、特征要能编辑。程序合成方案天然保留了建模历史每个孔、每个倒角都能追溯到具体参数。而且从工程交付角度设计评审时要能讲清楚“这个尺寸为什么是这样”程序合成方案更容易回溯和修改。实测下来程序合成方案还有一个容易被忽略的优势数据效率。直接生成几何的模型需要海量三维形状数据做训练而程序合成方案训练的是命令序列这类数据可以用CAD脚本批量合成。我在本地跑过用规则脚本生成一万个简单零件并转成训练数据的过程成本远低于采集真实三维模型。1.3 这个技术的适用边界在哪里text-to-cad适合什么场景这个问题我花了不少时间才想清楚。初期我拿它去生成复杂的装配体结果一地鸡毛。后来调整预期专注于单件零件、钣金件、壳体、支架这类结构规则、特征清晰的模型效果立刻好了很多。目前比较可靠的应用范围包括概念设计阶段的快速方案对比输入三五句话生成三五个变体供讨论标准零件库的自动化扩充比如各种规格的安装支架、法兰盘非标设计的起点模板生成基础形态后导入CAD细化教育场景帮助学生理解“设计意图→建模特征”的映射关系不适合的场景也很明确有机曲面、复杂曲面连续、需要精确配合关系的多零件结构、有行业标准强制要求的零件比如齿轮参数、螺纹规格。这些还是老老实实用专业模块去做text-to-cad目前替代不了。2. 工具选型解析从开源到商用API2.1 值得关注的项目全家福我梳理了目前能用、且真实跑通的项目分成三个梯队。第一梯队是学术开源项目比如Text2CAD相关工作、CAD-GPT这类第二梯队是面向开发者的API服务比如Zacero算是这个方向商业化走得比较靠前的第三梯队是把text-to-cad作为内置功能放进大型CAD平台的插件方案。学术开源项目的问题是工程化程度参差不齐。我试过几个项目有的环境配置就要折腾半天有的训练代码和推理代码分离得不够清晰有的依赖特定版本的PyTorch和CUDA。但它们的优势在于可定制性强你能看到完整的模型结构、数据管线、训练细节适合做二次开发或者学术研究。商用API正好相反开箱即用几行代码就能拿到结果但内部实现是个黑盒你没法控制中间过程。尤其关键的是商用API目前对中文提示词的支持普遍偏弱我在测试时发现中文描述经常导致特征遗漏比如“四个沉头孔”可能只生成两个。所以我的建议是动手验证用API深入定制用开源。2.2 各方案的核心参数对比我在测试不同工具时整理了一张对比表方便大家快速决策方案建模内核提示词语言输出格式中文支持可编程性成本开源Text2CAD类项目自研参数化引擎或OpenCASCADE英文为主STEP/IGES弱高仅算力成本Zacero APIOpenCASCADE英文为主中文支持弱STEP/GLB/PNG弱中按次计费CAD插件方案原生内核SolidWorks等中英文混合原生格式中低订阅制参数化引擎这个指标很容易被忽略但它决定了生成模型的边界。OpenCASCADE这类开源内核的好处是格式通用、生态成熟STEP格式输出后几乎所有CAD软件都能打开。坏处是生成的模型特征树通常不够“干净”导出的原点、基准面命名这些细节可能需要手动整理。我在选型时最终采用了“双轨”策略日常方案验证用Zacero这类API快速确认提示词描述的可行性正式项目里用开源方案跑批处理把生成结果接入自己的建模流程。这样既保证了效率又保留了可控性。2.3 为什么提示词语言这么关键text-to-cad对提示词的理解深度直接影响生成质量。实测下来英文提示词的成功率比中文高出一个档次。这背后的原因不难理解训练数据里面英文标注的CAD模型占绝对主力模型对英文里的尺寸表达、特征命名、几何关系术语学习得更充分。但这不代表中文彻底没法用。我的做法是先用中文写描述再用翻译工具转成英文人工检查一遍关键特征词是否准确。重点检查三类词特征类型hole/notch/chamfer/fillet、尺寸表达diameter/depth/thickness、位置关系centered/evenly spaced/through all。这些词直接决定了模型能不能把你脑子里的结构“听”懂。3. 实操过程与核心环节实现3.1 准备运行环境与依赖我先以Zacero的API为例说明从零到拿到第一个模型的全过程。这套流程我在Windows和Linux上都试过Windows下的坑主要是Python版本和SSL证书Linux下主要注意网络代理设置。基础的依赖就三样Python 3.9以上版本、requests库、一个能打开STEP文件的查看器推荐FreeCAD或Autodesk Viewer网页版。安装命令很简单pip install requests pip install open3d # 可选用于快速预览生成的网格文件环境变量的配置这块Zacero允许通过环境变量传入API Key好处是不会把密钥写死在代码里。Windows下用set命令Linux下用export命令具体看你的系统习惯set ZACERO_API_KEY你的密钥 # 或者 export ZACERO_API_KEY你的密钥有个细节容易踩坑requests库的版本不要太旧我遇到过旧版本在HTTPS请求时证书校验失败的问题升级到2.31.0以上版本就正常了。如果你在公司内网可能需要设置HTTP代理环境变量这也是requests库里的标准用法不影响代码逻辑。3.2 核心调用代码与逐行解析这里是一段我在项目里实际用过的调用代码经过多次调整加了日志输出和超时处理相对可靠import os import json import requests import time import sys def generate_cad_from_text(prompt: str, output_path: str) - bool: 通过text-to-cad API生成CAD模型 api_key os.environ.get(ZACERO_API_KEY) if not api_key: print([错误] 未找到ZACERO_API_KEY环境变量) return False headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { prompt: prompt, format: step, source: python-sdk-demo } create_url https://api.zacero.com/v1/generate try: print([1/4] 创建生成任务...) resp requests.post(create_url, headersheaders, jsonpayload, timeout30) resp.raise_for_status() task_data resp.json() task_id task_data.get(task_id) if not task_id: print(f[错误] 响应中缺少task_id完整响应: {task_data}) return False print(f[2/4] 任务已创建task_id: {task_id}) print([3/4] 轮询结果...) status_url fhttps://api.zacero.com/v1/tasks/{task_id} max_attempts 30 for attempt in range(max_attempts): time.sleep(5) status_resp requests.get(status_url, headersheaders, timeout30) status_resp.raise_for_status() status_data status_resp.json() status status_data.get(status) print(f 第{attempt 1}次查询状态: {status}) if status completed: break elif status failed: error_msg status_data.get(error, 未知错误) print(f[错误] 生成失败: {error_msg}) return False else: print([错误] 等待超时) return False if status ! completed: return False result status_data.get(result, {}) download_url result.get(download_url) if not download_url: print([错误] 未找到下载地址) return False print([4/4] 下载STEP文件...) file_resp requests.get(download_url, timeout60) file_resp.raise_for_status() with open(output_path, wb) as f: f.write(file_resp.content) file_size len(file_resp.content) print(f完成STEP文件已保存至: {output_path}大小: {file_size} 字节) return True except requests.exceptions.Timeout: print([错误] 请求超时) return False except requests.exceptions.RequestException as e: print(f[错误] 请求异常: {e}) return False except Exception as e: print(f[错误] 未预期异常: {e}) return False if __name__ __main__: # 这里建议强制使用英文提示词成功率更高 default_prompt ( Create a rectangular mounting bracket with four through holes at the corners, overall size 80mm x 50mm x 5mm, hole diameter 6mm, holes centered 5mm from each edge, with 2mm fillets on all outer edges. ) sys.exit(0 if generate_cad_from_text(default_prompt, bracket.step) else 1)这段代码的逻辑很直白创建任务、轮询状态、下载结果。但有两个设计是经过实际验证的一是采用异步任务而不是同步等待因为text-to-cad的生成时间通常在二十秒到两三分钟HTTP连接不可能一直挂着异步轮询更稳二是超时和失败处理一定要到位我在早期测试时就是因为少写超时参数导致程序在网络波动时直接卡死。3.3 提示词编写中的参数选择逻辑提示词是text-to-cad使用中影响最大的变量。我遇到的最常见失败原因不是模型能力不行而是提示词写得含糊或者自相矛盾。尺寸参数要写绝对数值不要写相对描述。比如不要写“一个大一些的支架”要写“整体尺寸80mm x 50mm x 5mm”。对于孔位这些关键特征最好明确参考基准比如“from each edge”或者“centered on the top face”否则模型会自由发挥。特征的逻辑关系要表达清楚。如果你想生成一个带底座的圆柱体底座边长80mm圆柱直径30mm居中高度20mm英文可以这样写Create a cylindrical boss with a square base plate. The base plate is 80mm x 80mm x 8mm. The cylinder is positioned at the center of the plate, with a diameter of 30mm and a height of 20mm. Add a 2mm chamfer to the top edge of the cylinder.这种描述同时包含了尺寸约束、空间关系和特征操作模型理解起来能少走弯路。还有一个经验是尽量把最重要的约束前置模型对开头部分的关注度明显更高。我在写提示词时强烈建议采用结构化模板而不是自由发挥。下面是我整理的一个基础模板你可以直接套用Create a [零件类型] with [基础特征描述]. The overall size is [长]mm x [宽]mm x [高]mm. Add [附加特征1] with [特征尺寸描述], positioned [位置描述]. Add [附加特征2] with [特征尺寸描述], positioned [位置描述]. Apply [表面处理/倒角/圆角] to [目标区域].这个模板的好处是把“几何是什么”和“特征怎么做”分成两层模型不容易混淆。我对比过用模板和自由组织语言的生成结果模板化提示词的特征完整率大概能提升三成。3.4 生成结果的验证与后续处理拿到STEP文件只是第一步验证模型是否满足要求才是关键。我一般用FreeCAD打开检查三步一是核对整体尺寸用测量工具验证长度宽度高度是否和提示词一致二是检查特征数量四个孔是不是真的生成了四个位置是否在预期的地方三是检查面的连续性有没有奇怪的破面或者细碎特征。FreeCAD里Python控制台可以直接导入STEP并读取模型属性批量验证时效率很高。下面是一个我之前用的简单验证脚本import FreeCAD as App import Part doc App.openDocument(bracket.step) shape doc.Objects[0].Shape bounding_box shape.BoundBox print(f尺寸: {bounding_box.XLength} x {bounding_box.YLength} x {bounding_box.ZLength}) print(f体积: {shape.Volume} mm^3) print(f面数: len(shape.Faces)})生成的模型如果不符合预期多数情况下不是重新生成一版而是调整提示词重跑。因为text-to-cad的随机性客观存在同样的提示词跑两次结果可能有细微差别。我在实际流程里通常一次提交三到五个生成任务从中选最接近预期的一个这个思路很像AIGC产品里的“抽卡”玩法但确实有效。4. 核心原理与关键技术点4.1 提示词编码器是怎么理解你的话的要理解text-to-cad为什么对标尺寸敏感、对模糊描述容易出错得从模型的编码机制说起。大多数方案的起点是一个预训练的自然语言编码器它把你的文本转换成高维向量。这个编码器在通用语料上训练过能理解“支架”“凸台”“沉孔”这类词面的意思但问题在于它不一定能理解工程语境里这些词的精确定义。比如“支架”在机械设计里可以指钣金折弯支架、铸造支架、焊接支架语义差别很大。编码器如果只理解字面意思模型生成的结果就会偏向训练数据里的常见形态而不是你当前语境里的应用形态。这就是为什么提示词里必须添加足够的限定词把语义空间不断压缩到你的特定意图。我做过一个实验不写“mounting bracket”写“L-shaped sheet metal bracket with two mounting ears”生成结果明显更接近钣金件如果只写“bracket”生成结果就比较随机。这说明编码器不是完全“听不懂”而是它需要你帮它缩小候选空间。从工程角度来说这是可以接受的——毕竟和人沟通时图纸上的技术要求也得写清楚。4.2 从语义向量到几何约束的映射过程这是text-to-cad最核心也最难说清楚的部分文本向量如何变成一串可执行的建模指令。我没法拿到每个模型的内部权重但从实验结果和论文描述来看这个过程可以理解为分两层。第一层是从语义向量中识别出关键实体和关系比如零件、特征、尺寸、位置、操作第二层是把这些实体关系映射到一个程序化建模操作集合里。映射的难点在于歧义消解。同样是“through hole”工程师可能理解为通孔也可能理解为贯穿特定厚度的孔一个“diameter 6mm”到底指的是孔径还是沉头直径模型必须通过上下文判断。这些歧义在自然语言里很常见但对一个需要精确到毫米的生成系统来说每一次错误映射都意味着废案。从我的使用经验看当前系统的语义容错并不好。这意味着提示词里的每个修饰词、每个数字单位、每个位置描述都要尽量明确不能指望模型像人类一样从上下文里推断你省略的信息。这一点和跟人沟通完全不同需要刻意适应。4.3 为什么生成的模型能保持尺寸精确text-to-cad输出的STEP文件之所以能直接进CAM是因为底层的参数化引擎用的是精确的数学表示——NURBS曲面和BREP边界表示而不是网格离散逼近。你在提示词里写的80mm在最终模型里就是精确的80.000000mm不是79.8也不是80.2。这个特性既是优势也是制约。优势在于生成的模型可以直接用标准检查工具验证配合公差分析软件做进一步处理制约在于提示词里的任何尺寸错误都会被完整保留下来AI不会主动帮你“纠正”一个不合理的尺寸。所以输入的尺寸数值一定要自己先确认过。另外要注意的是模型生成的倒角和圆角半径通常是整数或标准系列值这一点和人类设计习惯没有太大差异。但在处理复杂特征时偶尔会出现相邻特征干涉的情况也就是一个倒角吃掉了一个孔的一部分这在工程上是不能接受的。验证时重点看一眼特征的布尔并集结果是否干净必要时需要在CAD软件里手动修复。5. 常见问题与排查技巧实录5.1 特征丢失或数量不对这是我遇到最多的一个问题。提示词写“four through holes”结果生成了两个或者六个。刚开始我以为是自己描述问题后来发现和模型的注意力机制有关——当提示词里包含多个特征约束时模型对早期提到的特征关注度高对后面补充的特征容易忽略。解决方式有两个一是把最重要的特征放到提示词最前面二是把需要精确数量的内容单独成句比如“There must be exactly 4 through holes with a diameter of 6mm”用加粗语义强调。实测下来第二句加“exactly”这个限定词特征数量的准确率有明显提升。还有一个排查方向是确认模型的输出格式是不是真的带特征历史。某些API默认输出带特征历史的STEP但也有人遇到输出的STEP是单实体网格化后的曲面。如果你需要的是可编辑特征模型务必确认输出选项里是否开启了保留建模历史的模式。5.2 尺寸偏差超出预期尺寸偏差分两种一种是明显的量级错误比如把80mm生成了8mm这种情况通常是提示词里的单位没有被模型正确解析另一种是微小的偏差比如6mm的孔生成了5.8mm这在严格公差场景下不能接受。第一种情况建议检查提示词里是否用了统一的单位体系不要混用mm和cm。第二种情况需要了解当前的text-to-cad系统对尺寸的还原带有一定近似性它生成的尺寸严格来说是一个“建议值”而不是强制值。如果你的应用场景对公差有硬性要求生成后必须在CAD软件里重新标注或调用参数化驱动来校正。我的处理方法是把text-to-cad当作方案生成器而不是最终模型来源。拿到STEP后导入CAD软件重新约束关键尺寸再进入下游流程。这个流程多花十分钟但能避免很多交付阶段的问题。5.3 生成速度慢或任务卡住text-to-cad的生成速度波动很大。简单零件二十秒左右能完成复杂零件可能需要几分钟。如果用了轮询机制建议超时设置在五分钟以上不要因为一次查询超时就直接判定失败。我遇到过一次任务卡在“queued”状态超过十分钟的情况后来发现是API服务端的排队机制在高峰期生效并不是代码问题。这个时候不要重复提交相同任务只会让队列更长耐心等就行。如果连续多次卡住先清理本地DNS缓存试试有些网络环境下DNS解析异常会导致连接重置。还有就是要确保API Key没有过期我有一次换了密钥没更新环境变量查了半天才发现是这个问题。5.4 中文提示词生成效果差的应对方案在这个方向上中文的命中率目前确实不如英文这没办法训练数据的分布决定了模型能力。我的应对方式是建立一个中英文对照的术语库每次用中文构思设计意图后对照术语库逐条替换成英文提示词。这里可以分享一个我整理的常用对照覆盖了高频使用的机械特征词中文English备注通孔through hole贯穿整个零件沉头孔countersunk hole带锥形沉头盲孔blind hole不贯穿螺纹孔threaded hole注意可能需要指定标准倒角chamfer线状边缘处理圆角fillet曲面过渡凸台boss圆柱形或矩形凸起加强筋rib / stiffener薄壁加强结构安装耳mounting ear / tab常见的连接结构钣金折弯sheet metal bend需要钣金模块支持抽壳shell壁厚特征阵列pattern线性或圆周阵列建立术语库的过程其实不难但能显著降低排查时间。词组对应关系够用就好不用追求大而全重点覆盖你业务里最高频的那些特征。5.5 开源项目环境配置的避坑指南如果你决定深入开源项目环境配置是第一道坎。最常见的坑是CUDA版本不匹配和依赖库冲突。我的建议是直接用conda创建独立环境不要往base环境里装任何东西。另外很多开源项目的README写得不完整缺少pretrained model的下载链接。遇到这种情况先看看项目的releases页面有没有附带模型文件再去HuggingFace查找同名或相似名称的模型库最后才考虑自己训练通常不建议数据准备成本太高。测试时先用项目自带的示例提示词跑通整个流程再替换成自己的提示词。这样可以隔离“环境问题”和“模型能力问题”避免混合在一起排查浪费时间。我从实践中得到的经验是八成跑不通的情况是环境问题先解决环境再评判模型好坏。写在最后的个人体会text-to-cad这个方向我用了大概半年时间最大的感受是它不是来替代CAD工程师的而是来替代那些重复性的方案表达工作。以前出五个方案可能要花一整天现在用text-to-cad生成初版人工调整关键尺寸半天就能完成而且方案覆盖度更广讨论时的思路也更开阔。当然限制也很明显。复杂特征、精密配合、行业规范这些领域它完全帮不上忙强行使用反而增加返工成本。我现在的使用原则是概念阶段放手用细化阶段人工接管交付阶段严格审核。这个原则让我在效率和质量之间找到了平衡。如果你正准备尝试这个方向我的建议是从一个你熟悉的零件类型开始先跑通提示词到STEP的完整链路再逐步增加特征复杂度。等你对模型的“脾气”摸熟了它的作用会比想象中大得多。最后提醒一句生成的模型涉及商业项目时记得确认工具的授权条款商用授权和学术授权的边界要分清这一点在选型时就要想清楚。