1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个词很多人脑子里浮现的画面大概是对着电脑敲一句“给我画一个带法兰的六角螺栓”然后屏幕上就自动长出一个可以旋转、可以导出、可以拿去加工的模型。这个想象不算离谱但真正落地的时候它比“AI 画图”要复杂得多也务实得多。text-to-cad 的核心是把自然语言描述转换成结构化、可被工程软件识别的几何数据最终产出的是 STEP、URDF、G-code 这类“机器和机床都认”的格式而不是一张好看的 PNG。我自己是从传统建模一路摸过来的早期用 CAD 画一个标准件光是查手册、算倒角、对螺纹规格就得折腾小半天。后来接触到参数化脚本再到这两年 text-to-cad 这类思路逐渐成熟最大的感受是它不是在替代工程师而是在把“重复性建模”这件事的边际成本压到接近于零。你描述需求它生成初稿你负责审核和修正整个链路从“从零画”变成“改现成的”。这篇文章适合几类人看一是做机械、结构、建筑方向天天和 CAD 打交道想提效的从业者二是做机器人仿真、需要批量生成 URDF 模型的开发者三是搞增材制造、CNC 加工想把设计到 G-code 的链路打通的技术人员四是对 AI 辅助设计好奇、想自己动手搭一套流程的爱好者。不管你是哪一类下面这些内容都能让你少走弯路——因为我自己踩过的坑基本都写进去了。需要先明确一点text-to-cad 不是一个单一软件而是一类工作流。它通常由“语言理解层 参数化几何生成层 格式导出层”三部分组成。理解这个分层是理解后面所有实操的前提。很多人一上来就问“哪个工具最好”其实问错了问题真正该问的是“我的场景需要哪一层做到什么程度”。2. 核心思路拆解为什么是 STEP、URDF、G-code 这三个出口2.1 三种格式对应三种完全不同的下游需求text-to-cad 生成的东西最终要流向哪里决定了你该导出什么格式。这不是随便选的选错了下游软件直接打不开或者丢信息。格式全称/含义典型下游关键特点适用场景STEP产品数据交换标准主流 CAD、CAM 软件保留精确 B-rep 几何、装配层级机械零件、装配体、加工前处理URDF统一机器人描述格式机器人仿真平台描述连杆、关节、运动学树机器人建模、仿真、运动规划G-code数控加工指令CNC、3D 打印机刀具路径、层高、进给速度减材/增材制造执行STEP 是“精确几何”的代表。它记录的是数学意义上的曲面和实体不是网格近似所以你在 CAD 里打开还能继续改尺寸、加特征。text-to-cad 如果输出的是网格比如 STL那基本就“死”了只能看不能改。这也是为什么做机械方向的人一定要盯紧 STEP 这个出口。URDF 是另一套逻辑。它不关心你零件表面多光滑它关心的是“这个机器人有几个连杆、每个关节怎么转、转轴在哪、限位多少”。所以 text-to-cad 生成 URDF 时重点在于拓扑结构和运动学参数而不是精细外形。我见过不少人拿一个超精细的 STEP 硬转 URDF结果仿真里跑得卡死就是因为没理解这两者的关注点完全不同。G-code 则是“执行层”。它不描述模型本身而是描述“刀具怎么走”。从 text 到 G-code中间其实必须经过几何模型这一步所以 text-to-cad 生成 G-code 通常是“先生成模型再切片/生成刀路”。理解这个链条你就不会指望一句话直接吐出可用的 G-code——那中间少了太多工艺参数。2.2 为什么参数化是 text-to-cad 的命门自然语言是模糊的几何是精确的。这两者之间的桥梁就是参数化。你说“一个大概 50 毫米长的支架”机器必须把它变成“length50mm”这样的确定参数才能生成几何。我早期尝试过用纯文本直接生成网格效果很差——因为网格没有参数改一个尺寸就得重新生成而且形状不可控。后来转向参数化模板的思路预先定义好一类零件的参数骨架比如法兰、支架、齿轮语言层只负责“填参数”几何层负责“按参数建模”。这样生成的结果既精确又可复现改一个数字就能重新出图。提示如果你要自己搭 text-to-cad 流程优先选择支持参数化建模的内核如 OpenCASCADE、CadQuery 这类而不是直接操作网格。这是决定你后续能不能“改”的关键。参数化的另一个好处是可验证。生成完模型后你可以自动检查“壁厚是否小于最小值”“孔径是否匹配标准螺纹”这些检查在参数层面做非常容易在网格层面做就很痛苦。工程场景里能自动校验比能自动生成更重要。2.3 语言理解层别指望它“懂工程”要让它“填表格”很多人对 text-to-cad 的误解是以为语言模型要理解复杂的工程语义。实际上更靠谱的做法是让语言层做它擅长的事——抽取和归一化把“M6 的内六角螺栓长度 20”解析成{type: bolt, thread: M6, head: hex_socket, length: 20}这样的结构化字段剩下的交给确定性的几何代码。这样做的好处是可控。语言模型偶尔会“幻觉”但如果你只让它填字段填错了也能通过字段校验发现。而如果让它直接生成几何代码一旦出错可能整个模型都是歪的还很难定位问题。我在实际项目里用的策略是“双保险”语言层输出结构化 JSON几何层用严格 schema 校验任何字段缺失或超范围就拒绝生成并报错。这套机制上线后生成失败率从早期的三成降到了个位数百分比。3. 核心细节与实操要点从描述到模型的完整链路3.1 描述怎么写决定了模型能不能用text-to-cad 的输入质量直接决定输出质量。我总结了一套“描述三要素”实测下来能显著提升一次成型率几何类型明确是板、轴、齿轮、支架还是装配体。别只说“一个零件”。关键尺寸长宽高、直径、孔径、壁厚能给数字就给数字给不了就给范围。特征与约束有没有倒角、圆孔阵列、螺纹、配合面以及哪些面需要平行/垂直。举个例子差的描述是“做一个固定电机的架子”。好的描述是“一个 L 型支架底板 80x60x5mm立板高 50mm 厚 5mm底板四角各一个 M4 通孔孔中心距边缘 8mm立板中心一个直径 22mm 的电机轴孔”。后者几乎可以直接生成可用模型前者只能生成一个“大概像”的东西。注意描述里尽量避免“差不多”“大概”“美观一点”这类词。工程建模里没有“美观”这个参数机器无法执行。3.2 参数校验生成前的最后一道闸在几何生成之前一定要做参数校验。这一步很多人省掉结果生成一堆废模型。我常用的校验规则包括校验项规则示例不通过的后果尺寸范围壁厚 ≥ 1mm模型太薄无法加工孔位合理性孔中心距边缘 ≥ 1.5 倍孔径孔会破边螺纹匹配M6 对应底孔约 5.0mm装配拧不进去关节限位URDF 关节角度在合理区间仿真穿模或报错这些规则不复杂但能挡掉大量低级错误。我建议把校验规则写成配置文件方便不同项目复用和调整。3.3 几何生成内核的选择逻辑几何生成层是整个流程的“发动机”。选型时主要看三点是否支持参数化、是否支持 STEP 导出、是否有成熟的脚本接口。如果偏机械零件优先选支持 B-rep 的内核导出 STEP 无损。如果偏机器人选能直接输出 URDF 运动学树的工具链。如果偏加工选能对接切片/刀路生成的方案。我自己的经验是不要追求“一个工具全搞定”。语言层、几何层、导出层分开每层用最合适的工具通过标准数据格式JSON、STEP串联反而更稳、更好维护。耦合太紧的系统改一处崩一片。4. 实操过程手把手搭一条 text-to-cad 流水线4.1 环境准备与依赖安装先说明下面这套流程是我自己跑通的方案基于 Python 生态因为它的几何库和语言处理库都最成熟。你需要准备# 建议用虚拟环境避免污染系统 Python python -m venv tcad-env source tcad-env/bin/activate # Windows 用 tcad-env\Scripts\activate # 核心依赖 pip install cadquery # 参数化几何建模 pip install ocp # OpenCASCADE 的 Python 绑定 pip install pydantic # 结构化数据校验 pip install numpy # 数值计算CadQuery 是我强烈推荐的一个库它把 OpenCASCADE 封装成了接近“写代码画图”的体验而且原生支持 STEP 导出。相比直接啃 OCC 的 C 接口上手快太多。提示安装 OCC 相关库时Windows 上偶尔会遇到 C 运行库缺失的报错类似装 CAD 时遇到的 C2005 错误。解决办法是装一遍微软常用运行库合集基本能解决。4.2 定义结构化参数 Schema这一步是“语言层”和“几何层”的接口。用 Pydantic 定义好字段语言模型输出后直接校验from pydantic import BaseModel, Field from typing import Literal class BracketSpec(BaseModel): part_type: Literal[L_bracket] L_bracket base_length: float Field(..., gt10, le500, description底板长度 mm) base_width: float Field(..., gt10, le500) base_thickness: float Field(..., ge1, le50) wall_height: float Field(..., gt5, le300) wall_thickness: float Field(..., ge1, le50) hole_diameter: float Field(..., gt1, le50) hole_margin: float Field(..., gt2, description孔中心距边缘 mm) motor_hole_diameter: float Field(0, ge0, le100)字段上的gt、le就是前面说的校验规则。任何超范围的输入Pydantic 会直接抛错不会进入几何生成。这套机制帮我挡掉了大量“看起来合理但实际做不出来”的需求。4.3 几何生成把参数变成实体有了参数几何生成就是确定性的代码。以 L 型支架为例import cadquery as cq def build_bracket(spec: BracketSpec): # 底板 base ( cq.Workplane(XY) .box(spec.base_length, spec.base_width, spec.base_thickness) ) # 立板贴在底板一端 wall ( cq.Workplane(XY) .center(0, -spec.base_width/2 spec.wall_thickness/2) .box(spec.base_length, spec.wall_thickness, spec.wall_height) .translate((0, 0, spec.base_thickness/2 spec.wall_height/2)) ) part base.union(wall) # 底板四角通孔 hole_r spec.hole_diameter / 2 x_off spec.base_length/2 - spec.hole_margin y_off spec.base_width/2 - spec.hole_margin part ( part.faces(Z).workplane() .pushPoints([(x_off, y_off), (-x_off, y_off), (x_off, -y_off), (-x_off, -y_off)]) .hole(spec.hole_diameter) ) # 电机轴孔如果有 if spec.motor_hole_diameter 0: part ( part.faces(Y).workplane() .hole(spec.motor_hole_diameter) ) return part这段代码里每个尺寸都来自参数改参数就改模型完全可复现。这就是参数化的威力——你不需要重新“画”只需要重新“算”。4.4 导出 STEP 与 URDF生成实体后导出 STEP 非常简单result build_bracket(spec) cq.exporters.export(result, bracket.step)STEP 导出后可以直接在主流 CAD 里打开继续编辑装配层级和精确几何都保留。URDF 的生成逻辑不同它需要你定义连杆和关节。对于简单机构可以手写 URDF 模板把参数填进去robot namesimple_arm link namebase_link visual geometry box size0.1 0.1 0.05/ /geometry /visual /link joint namejoint1 typerevolute parent linkbase_link/ child linkarm_link/ axis xyz0 0 1/ limit lower-1.57 upper1.57 effort10 velocity1/ /joint /robot关键点在于axis和limit这两个决定了关节怎么转、能转多少。text-to-cad 生成 URDF 时语言层要能识别“绕 Z 轴旋转”“限位正负 90 度”这类描述转成对应字段。4.5 从模型到 G-code 的衔接G-code 不是 text-to-cad 直接吐出来的而是模型生成后交给切片或 CAM 软件处理。以 3D 打印为例流程是STEP → STL → 切片 → G-code。这里有个坑STEP 转 STL 时的网格精度会影响打印质量精度太低表面会有明显棱角。# STEP 转 STL注意 tolerance 参数 cq.exporters.export(result, bracket.stl, tolerance0.01)tolerance越小网格越细文件越大。0.01mm 对大多数打印件够用精密件可以到 0.001mm。这个参数没有标准答案取决于你的精度需求和文件大小容忍度。5. 常见问题与排查技巧实录5.1 生成失败或模型异常速查表现象可能原因排查方向解决思路模型是空的参数全为 0 或负值检查 Schema 校验是否生效加最小值约束孔破边孔位太靠边检查 hole_margin 与孔径关系强制 margin ≥ 1.5×孔径STEP 打不开导出时几何无效检查布尔运算是否产生非流形生成后做几何有效性检查URDF 仿真穿模关节限位或连杆尺寸错检查 axis 和 limit用可视化工具先看运动学树G-code 打印错层STL 网格精度不足检查 tolerance调小 tolerance 重新导出语言层解析错描述歧义看结构化输出优化 prompt 或加字段约束这张表是我实际排查时总结的基本覆盖了八成以上的常见问题。遇到新问题先对照这张表能省不少时间。5.2 独家避坑经验坑一别用语言模型直接生成几何代码。我早期试过让模型直接写 CadQuery 代码结果十次有三次语法错、两次逻辑错调试成本极高。改成“模型填参数 固定代码生成几何”后稳定性大幅提升。语言模型擅长理解意图不擅长精确计算让它做擅长的事。坑二STEP 和 STL 别混用。有人图省事全程用 STL结果要改尺寸时发现改不动。记住需要后续编辑的一律走 STEP只用于展示或打印的才用 STL。坑三URDF 的坐标系要对齐。我见过太多 URDF 导入仿真平台后模型“飘”在天上或者穿进地里基本都是坐标系原点没对齐。生成 URDF 时务必确认每个 link 的原点位置和 joint 的变换关系。坑四批量生成要加去重和命名规则。做批量零件时如果命名混乱后期根本找不到哪个文件对应哪个需求。我的做法是用“类型_关键尺寸_时间戳”命名比如bracket_80x60x5_20240115.step一眼就能认出来。坑五G-code 前一定要做工艺校验。模型没问题不代表能加工。壁厚、悬垂角、最小孔径这些工艺约束最好在生成 G-code 前用脚本自动检查一遍避免打废材料。5.3 性能与规模化的注意点当你要批量生成几百上千个模型时单线程跑会很慢。我的做法是把生成任务拆成独立进程用多进程并行。CadQuery 的几何运算比较吃 CPU并行能显著提速。但要注意OCC 内核在多进程下偶尔会有资源竞争建议每个进程独立初始化不要共享内核实例。另外批量生成时建议加日志和断点续跑。跑到一半崩了能从上次的位置继续而不是从头再来。这个在长时间任务里能救命。6. 工具选型与场景适配的实战判断6.1 不同场景该选什么组合场景语言层几何层导出格式备注机械零件快速建模任意 LLM JSON 校验CadQuery / OCCSTEP重点是参数化机器人仿真建模LLM 运动学解析自建 URDF 模板URDF重点是关节定义增材制造LLM 工艺参数CadQuery 切片器G-code重点是工艺校验建筑/土木构件LLM 尺寸抽取参数化构件库STEP/DWG注意单位统一选型的核心逻辑是下游要什么上游就产什么。不要为了“统一”而强行用一种格式那样只会两头不讨好。6.2 和传统 CAD 工作流怎么配合text-to-cad 不是要取代 CAD而是做 CAD 的“前置草稿机”。我的实际用法是用 text-to-cad 生成初稿 STEP导入 CAD 后做精细调整、加工程标注、出图。这样比从零画快得多尤其是标准件和重复结构。对于需要精确配合的装配体text-to-cad 生成的模型可以作为“占位件”先确定布局和干涉关系再逐步细化。这种“先粗后精”的流程在方案阶段特别高效。6.3 关于“CAD 下载”和“插件”的现实提醒网上搜 text-to-cad 相关词时会看到大量“CAD 下载”“CAD 插件免费版”之类的内容。我的建议是核心建模能力尽量用开源、可脚本化的工具链别过度依赖某个闭源插件。因为一旦插件不更新或者授权变化你的整条流水线可能就断了。开源工具虽然上手陡一点但可控性和长期稳定性好得多。至于“CAD 如何彻底卸载不影响二次安装”这类问题本质是安装残留和注册表问题。如果你把 text-to-cad 流程建立在脚本化工具上这类烦恼基本就绕开了——因为脚本环境是隔离的卸载重装不影响系统。7. 我个人的几条实操体会搭这套流程的过程中最大的体会是text-to-cad 的价值不在“自动”而在“可复现”。自动生成一次不难难的是每次都能生成一样的结果且能追溯是哪个参数导致的。参数化 结构化校验就是保证可复现的关键。第二个体会是别追求“一句话生成复杂装配体”。现实里复杂结构拆成多个简单零件分别生成再在 CAD 里装配比让模型一次生成整个装配体靠谱得多。分而治之是工程里永远有效的策略。第三个体会是工艺知识不能丢。text-to-cad 能帮你画得快但画得出来不等于做得出来。壁厚、公差、材料特性这些还是得靠人的经验把关。工具再强也只是放大器放大的还是你自己的判断力。最后分享一个小技巧如果你要频繁生成某一类零件把它做成参数化模板库语言层只需要识别“这是哪类零件 关键尺寸”生成速度和稳定性都会大幅提升。模板库越丰富你的 text-to-cad 就越好用。这个积累过程本身就是一笔资产。