“把一句‘我要一个带四个螺栓孔的外壳’丢进去几分钟后拿回来一个能编辑、能出工程图、能直接导出 STEP 的 CAD 模型这放在五年前我是不信的。”干这行的人都知道CAD 建模最磨人的从来不是“想不出来”而是“画不出来”。从草图、约束、特征树再到参数关联软件操作的比重远大于设计本身。text-to-cad 想做的就是这个切口用自然语言取代那套冗长的建模操作序列。今天我不打算只给你列一堆模型和论文标题而是把这条链路整个拆开把技术选型、实测流程、踩过的坑以及怎么稳定拿到 STEP 文件的完整方案一次说清楚。无论你只是想快速玩玩还是准备把 AI 接进正式设计流程这份内容都能直接照着落地。1. text-to-cad 不是什么“文字生成图片”而是把语言翻译成可编辑的实体模型1.1 它和文生图的本质区别很多人第一次听到 text-to-cad第一反应是“这不就是文字生成 3D 图片吗”。大错特错。文生图输出的是像素矩阵你可以拿它当效果图参考但它没有尺寸、没有特征树、没有公差概念也没法进加工流程。而 text-to-cad 要输出的是一个真正的参数化 CAD 模型包含实体几何、特征历史、草图约束和可调整的变量。打个比方文生图是在给你画一张零件照片text-to-cad 是在给你交一份完整的建筑图纸两者虽然都叫“AI 生成”但信息密度和工程价值完全不在一个量级。前者看一眼就完后者要能被修改、被重新生成、被送去加工。我最早接触这类项目时最震撼的也不是模型生成得多漂亮而是它真的能输出 STEP 这样的标准交换格式直接丢给 CAM 软件就能干活。1.2 它到底解决了谁的痛点过去十年CAD 软件的功能越来越强操作也越来越繁琐。一个熟练的工程师能把 SolidWorks 或 FreeCAD 玩出花来但对大多数非标件、3D 打印爱好者、机械专业学生来说软件操作本身就是一道高墙。你脑海里想得很清楚的一个支架打开软件后要先建草图、标约束、拉特征、倒圆角光是把想法变成模型就得折腾半天。text-to-cad 想压缩掉的正是这一大段“人机交互”成本。描述清楚形状、功能、关键尺寸系统替你完成底层的建模操作。它不取代设计师对结构和功能的判断但确实把执行层的效率拉高了一大截。我自己的实际感受是以前一天能画三五个简单零件现在同样时间可以清掉二十多个省下来的精力都用在了更值得思考的方案分析上。1.3 哪些场景最能吃到红利按我的实测这三类场景收益最明显。第一类是 3D 打印快速验证很多配件其实就几个孔、几条筋、一个卡扣用语言描述比开软件建草图快得多。第二类是机械非标件的前期概念客户一句话说“我要个电机安装座四角带孔中心开大孔”你先把模型生成出来再逐步精修比从空白画布开始从容很多。第三类是设计自动化管道把 text-to-cad 接到上游的 BOM 或配置表秒级生成不同尺寸的变体传统手工建模根本跟不上这个节奏。当然复杂装配、精密模具、需要严格工程图纸的场合目前的 text-to-cad 还远不能完全替代人工。但作为前段提速工具它已经实打实能用了。2. 技术路线怎么选代码生成、特征树生成、端到端生成2.1 路线一让大模型写 CadQuery 或 OpenSCAD 脚本这条路线最接地气。大模型天然擅长生成代码而 CadQuery、OpenSCAD 这类程序化建模库本来就是用代码描述几何。把“一句话需求”交给大模型让它生成一段 CadQuery Python 脚本然后本地执行脚本直接得到实体模型并导出 STEP。它的本质是“大模型负责把自然语言翻译成程序化建模接口调用几何内核负责真正算模型”。CadQuery 底层基于开源几何内核 OCP支持真正的 BREP 实体建模导出的 STEP 文件包含实体拓扑信息可以被 FreeCAD、Fusion 等软件继续编辑。OpenSCAD 则更偏 CSG 布尔建模语法更简单但参数化能力和实体质量弱一些。实际操作中这条路线的可靠性很高因为大模型写代码的能力已经在过去两年被验证得很充分。只要提示词给够约束生成脚本的语法错误率可以压到很低。而且代码是文本可以走 Git 版本管理每一步改动都可回溯这比操作一堆 UI 状态踏实得多。2.2 路线二让大模型直接生成特征树或调用 CAD 内核 API更“根正苗红”的路线是让大模型直接输出一个特征操作序列比如“创建草图→约束坐标→拉伸→倒角”然后由 CAD 内核逐条执行。这条路线的输出最接近传统建模流程模型里会保留完整的特征历史用户拿到手后可以像原生模型一样改参数、看步骤。不少 CAD 厂商的研究项目和早期产品走的都是这个方向。它对大模型的要求更高因为特征树的生成比代码生成更依赖对几何内核的深度理解而且不同 CAD 软件的特征体系并不通用要做大量适配。我见过的公开演示确实惊艳但一遇到复杂特征组合就容易卡壳稳定性暂时比不过代码生成路线。2.3 路线三端到端生成 B-rep 模型或图生 CAD还有一些研究在尝试让模型直接预测 B-rep 拓扑结构或者先从文本生成一张或多张 2D 视图再用视图重建 3D 模型。这条路线远看很美近看问题不少。直接预测 B-rep 的训练数据很难搞目前生成结果的拓扑错误率偏高图生 CAD 则绕了一大圈误差会在视图重建环节被放大。所以我的判断很明确对于个人开发者和小团队路线一是当下性价比最高的落地方案。它不依赖任何厂商的闭门生态用免费开源的 CadQuery 加上主流大模型就能搭起一套可用的管道输出格式标准出错还能直接改代码。路线二更适合有实力的大团队去做产品化路线三目前更多停留在学术价值层面。3. 我用过的工具组合和一套可以直接照搬的选型逻辑3.1 工具横向对比工具/方案工作方式输出格式上手门槛我实测的稳定性CadQuery 通用大模型LLM 生成 CadQuery Python 代码本地执行STEP、STL、DXF 等中等需要懂一点 Python高适合工程化OpenSCAD 通用大模型LLM 生成 OpenSCAD 脚本STL 为主STEP 需转换低语法简单中复杂布尔容易出错CAD 厂商的文本建模内测功能自然语言直接生成特征历史厂商私有格式低高但生态封闭Text2CAD 等学术原型专用模型生成参数化 CADSTEP 或自定义格式高需自己跑模型中可控参数少先说结论如果你的目标是“把文本稳定变成 STEP 文件并纳入后续流程”CadQuery 通用大模型是最省心的组合。OpenSCAD 更轻但导出 STEP 需要额外转换而且它对实体倒角、圆角这类操作的支持比较绕。厂商内测功能体验确实顺畅但格式和 API 都被绑定不适合作为可移植的解决方案。学术原型适合做研究参考离普通工程使用还有点距离。3.2 我的选型逻辑选型时我就三个标准。第一是输出必须能进专业流程不能只是 STL 网格因为网格模型没法在 CAD 里做特征编辑。第二是链路必须可拆开干预哪一步错了我能单独修而不是黑盒一团。第三是成本可控不依赖昂贵的闭源 API也不要求特定厂商的软件环境。CadQuery 精准满足这三点。它是纯 Python 库几何内核 OCP 开源且活跃导出的 STEP 文件能被所有主流 CAD 软件打开和二次编辑。更关键的是CadQuery 是代码构建模型大模型对它的语法理解足够好我实测下来在提示词里给一个 mini 示例后模型生成的脚本甚至不需要大改就能运行。如果你是零基础小白也不用担心。CadQuery 的建模思维跟传统 CAD 不完全一样但它的 API 设计非常直觉化工作平面、拉伸、挖孔这几个核心操作花半天就能上手。配合大模型生成代码你甚至不需要完全读懂每一行会改关键尺寸参数就能把流程跑通。4. 完整实操从一句需求描述到干净可用的 STEP 文件4.1 第一关需求描述怎么给才不翻车很多人第一次玩 text-to-cad 失败不是 AI 不行而是自己的描述太像口头禅。“做个带孔的板子”这种话换个人类工程师来也没法直接开干。想要稳定输出需求描述必须包含四个要素零件类型与功能、关键外形尺寸、必须包含的特征、约束条件。我习惯用固定的描述模板字段对齐后端解析也方便。一份合格的描述长这样请用 CadQuery 实现一个电机安装支架 底部是矩形底板长 80 毫米宽 60 毫米厚 5 毫米 四角各有一个直径 6 毫米的通孔孔心距边缘 8 毫米 底板中心有一个直径 30 毫米的圆台凸台高 15 毫米凸台中心开直径 12 毫米的通孔 所有尺寸使用毫米单位孔必须是贯穿孔。这段描述里零件、尺寸、特征位置、加工约束全部交代清楚了。模型生成出来即使细节不完美大方向绝不会错。如果只说“做个支架底座”AI 就只能在各种可能形状里猜结果自然不可控。4.2 第二关把自然语言翻译成 CadQuery 代码描述文本准备好后直接把它丢给大模型并在提示词里要求“只输出 CadQuery Python 代码不要解释”。大模型会返回类似下面的脚本import cadquery as cq # 参数化变量 base_length 80.0 base_width 60.0 base_thick 5.0 hole_d 6.0 hole_offset 8.0 boss_d 30.0 boss_h 15.0 center_hole_d 12.0 result ( cq.Workplane(XY) .box(base_length, base_width, base_thick) .faces(Z) .workplane() .rect(base_length - 2*hole_offset, base_width - 2*hole_offset, forConstructionTrue) .vertices() .circle(hole_d / 2) .cutThruAll() .faces(Z) .workplane() .circle(boss_d / 2) .extrude(boss_h) .faces(Z) .workplane() .circle(center_hole_d / 2) .cutThruAll() )这段代码的逻辑很直观先建立一个底板在底板上表面画四个定位孔并打穿再在中心位置拉伸一个圆台最后在圆台中心打穿一个通孔。这里有一个关键点代码里的尺寸全部被变量名收纳了而不是一堆散落的数字。这带来的好处是导出 STEP 之后你只要改上面的变量值重新跑一次脚本就能秒生成一个尺寸变体。参数化才是 text-to-cad 的隐藏价值很多人只盯着“生成”两个字忽略了这一步。4.3 第三关对大模型输出做自动校验大模型写的代码不一定一次就过。我的习惯是先做语法检查再实际执行不直接拿结果去导出。这一步看似多余却是整个流程稳定性的关键。我写了一个简单的校验脚本import ast import cadquery as cq # src 是大模型返回的代码字符串 def validate_and_build(src): try: # 1. 语法检查 ast.parse(src) except SyntaxError as e: return None, f语法错误: {e} ns {} try: # 2. 执行代码拿到 result exec(src, ns) except Exception as e: return None, f执行错误: {e} result ns.get(result) if result is None: return None, 出错了脚本里没有 result 变量 return result, None shape, err validate_and_build(llm_output) if err: print(err) # 可以把错误信息回喂给大模型让它修正后重新生成 else: print(模型构建成功实体数量, len(shape.vals()))如果校验失败我的流程是把错误信息连同原始描述一起再次提交给大模型让它自行修复。通常这一轮迭代后绝大多数脚本都能跑通。这个“描述→生成→校验→反馈→再生成”的闭环是 text-to-cad 工程化最核心的套路比指望模型一次写对靠谱得多。4.4 第四关导出 STEP 并检查质量模型构建成功后导出 STEP 只是最后一小步import cadquery as cq # 假设 result 已经由前面的代码生成 cq.exporters.export(result, motor_bracket.step)导出之前我还会顺手检查几项硬指标零件包围盒尺寸对不对、实体体积是不是合理值、有没有异常的自由边。CadQuery 的 bounding box 接口可以直接拿到尺寸bbox result.val().BoundingBox() print(fX: {bbox.xlen:.2f} mm) print(fY: {bbox.ylen:.2f} mm) print(fZ: {bbox.zlen:.2f} mm)这里特别提醒一个单位坑。大模型经常在不同单位间摇摆有时候把毫米描述理解成厘米生成结果的包围盒会整体大十倍。所以我要求描述里必须显式标注单位并在校验阶段用包围盒数据做一次尺寸核对。跑通了这一整套流程STEP 文件的质量基本不会让你在后续环节丢人。4.5 从描述到 STEP 的实际效果用第 4.1 节那个电机安装支架的案例我在本地跑完整条管道耗时大约十几秒其中大头是大模型的推理时间CadQuery 本身执行只占一两秒。导出的 STEP 文件能被 FreeCAD 顺利打开特征可以被重新编辑四角孔中心距与底板边距和描述完全一致中心凸台的尺寸也分毫不差。一个小提示生成的 STEP 虽然带实体几何但并不意味着你已经拿到了“原生特征历史”。CadQuery 导出的是 BREP 实体进入其他 CAD 软件后还是会被当作“哑模型”需要用软件里的特征识别功能转成可编辑特征。想要保留参数特征树就得停留在 CadQuery 脚本阶段把代码当模型源文件来管理。这是两条不同路线别混为一谈。5. 常见问题与排查技巧实录5.1 生成出来的模型能被编辑吗这是被问得最多的问题。很多人拿到 STL 文件放进切片软件一看是能打印的就说“text-to-cad 成功了”。严格讲这不算真正的 CAD因为 STL 是网格没有几何特征在 CAD 里只能看不能改。我自己的做法是坚持走 STEP 导出只把 STL 当作可视化预览。CadQuery 这条链路天然是 BREP 实体导出 STEP 后模型的几何拓扑是完全的任何专业 CAD 软件都能加载并继续操作。如果你的工具链只能产 STL多半是用了 OpenSCAD 或某些简化模型建议换成 CadQuery 或加一道格式转换环节。5.2 生成尺寸和描述对不上尺寸跑偏九成是单位问题。大模型没有内在的“毫米直觉”它在训练数据里见过毫米、厘米、英寸混用的场景经常自作主张换单位。解决方法是描述文本强制写明单位并在提示词末尾加一句“所有尺寸默认使用毫米不要进行任何单位转换”。校验阶段再用 bounding box 核对一遍基本能防住。另一个常见原因是方位词理解偏差。“左上角”“右边”这类相对位置大模型偶尔会把坐标系搞反。我的经验是尽量用绝对数字描述位置比如“孔心距左边距 10 毫米距上边距 10 毫米”比“左上角”可靠得多。5.3 布尔运算老是失败在 CadQuery 里做复杂的多实体布尔操作时偶尔会遇到几何内核报错比如面与面刚好贴合导致运算不稳定。这不是大模型的错而是几何内核的数值容差问题。遇到这种情况先别急着让大模型重写整段代码先把布尔操作的实体稍微改一点重叠量或者把“恰好贴合”的两个面改成有意交叉让内核能稳定求交。也可以提示模型“优先使用 cutThruAll 贯穿操作不要用 cutBlind 带深度盲切”后者更容易触发精度问题。5.4 环境装不起来CadQuery 的安装经常被吐槽。它依赖 OCP 几何内核PyPI 上虽然有安装包但某些平台容易编译出错。我实测比较稳的是用 conda 建独立环境安装命令就两条conda create -n cq python3.11 conda activate cq pip install cadquery装好后导入一下验证环境没问题再跑后续流程。如果你还同时装了其他 CAD 相关库建议尽量隔离避免依赖冲突把整个 Python 环境搞崩。5.5 一次生成一堆废模型高成功率的前提是描述规范、校验闭环、模型选型合适缺一个都会疯狂翻车。我用过一个比较弱的开源小模型同样的描述生成 CadQuery 代码的语法错误率接近一半根本没法工程化。换成能力更强的通用大模型后一轮通过率直接跳到八成以上。我的建议是别在最开始就把大量精力花在调一个小模型上。先用主流大模型把完整链路跑通确认流程没问题以后再考虑用开源小模型做私有化部署。链路本身是通用的换模型只是换掉底层“翻译器”前面的校验和导出逻辑完全能复用。6. 从踩坑到顺手我沉淀下来的几条实战心得6.1 提示词模板别贪多稳定才是第一我见过不少人上来就写两千字的提示词模板把材料、公差、表面处理、渲染要求全塞进去结果模型反而不知道重点在哪。提示词的核心是把几何关键信息说清楚而不是堆砌越多越好。我自己长期用的模板短到只有几行零件名称、外形尺寸、特征列表、位置约束、输出格式要求。额外信息只有在确实会影响几何结构时才加比如“需要卡扣”“需要加强筋”。其他工艺信息建议放到导出后的工程阶段再说别再这一步给模型添乱。6.2 把“参数化”刻进 DNA而不是只追求一次生成text-to-cad 最容易被忽略的威力是配合参数化设计做“模型族”。同一个支架逻辑底板从 80 毫米改到 200 毫米孔数从 4 个改成 8 个在 CadQuery 里就是改两个变量和循环体的事。我只用一次生成建立起代码模板之后每个变体都是秒级出图。这也意味着你的描述文本最好结构化把尺寸、数量、位置都拆成独立变量而不是揉在一段散文里。这样当你需要批量生成多个规格时只需要写一个小循环去改变量调用 text-to-cad 管道批量跑即可一次能出几十个变体。6.3 别指望它能一步到位把它当“可执行草图”我个人的最终体会是text-to-cad 成熟度远没到“甩锅式使用”的程度它更像一个可以自动执行的草图助手。你给它足够清晰的约束它把 90% 的建模体力活干完剩下的 10% 仍然需要你动脑特征顺序是否合理、加工工艺是否可行、装配关系有没有冗余。这些判断能力恰恰是一个工程师真正的价值所在。我踩过几次“完全放手”的坑之后现在的使用习惯是设计初期先用 text-to-cad 快速出方案再拿到传统 CAD 里精修关键配合面。一套组合拳下来既有速度又不丢质量。这套玩法还会继续迭代我已经把下一步方向定在让 CadQuery 代码模板和本地知识库联动等跑顺了再回来分享。