text-to-cad 实战：从自然语言到参数化 CAD 模型的完整落地链路-北京尧图网络

1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个词很多人脑子里浮现的画面大概是对着电脑说一句给我画个带法兰的弯管接头屏幕上就自动旋转出一个可以导出加工的 3D 模型。这个想象不算离谱但真正动手做过的人都知道从自然语言到参数化 CAD 实体之间隔着的不是一层窗户纸而是一整套需要精心设计的映射链路。我前后折腾过几套不同思路的实现方案踩过的坑足够写满一个笔记本今天就把这套东西拆开揉碎讲清楚。先说清楚 text-to-cad 是什么。它的本质是把自然语言描述转换成计算机辅助设计软件能够识别和编辑的几何模型。这里的CAD不是指随便生成一个网格模型或者点云而是指带有尺寸约束、特征树、可参数化修改的实体模型比如常见的边界表示B-rep实体或者基于特征的参数化模型。这一点非常关键因为如果你只是想要一个好看的 3D 网格那用文本生成 3D 网格的技术路线完全是另一回事两者在数据结构、精度要求和后续可用性上差别巨大。它能做什么最直接的价值是降低 CAD 建模的入门门槛和重复劳动。一个非机械专业的产品经理脑子里有一个支架的形状以前只能画草图然后求工程师建模现在他可以用一段结构化的文字描述让系统生成一个初版模型工程师在此基础上微调。另一个场景是批量变体生成比如同一类零件有几十种尺寸规格与其一个个手动改参数不如用文本模板批量驱动生成。还有一个场景是设计意图的快速验证在概念阶段用文字快速生成几个候选形状比手动画草图快得多。适合谁来参考这篇内容如果你是有一定编程基础、想把自己领域的建模需求自动化的工程师这篇会给你完整的落地思路如果你是 CAD 软件的深度用户想理解背后的几何内核和约束求解逻辑也能找到对应的章节如果你只是对文字生成模型这件事好奇想搞清楚它到底靠不靠谱、边界在哪里我也会把真实的能力上限和翻车场景讲明白。需要提前说明的是text-to-cad 目前远没有到说人话就出完美模型的程度它更像是一个需要精心设计输入格式和中间表示的半自动工具把它当成魔法会失望把它当成效率杠杆才合理。我下面会从几何内核的选择讲起因为这是整个系统的地基选错了后面全是返工。然后讲自然语言到结构化参数的解析层这是最容易低估的部分。接着是参数到几何的构建层以及实测中最容易翻车的几个环节。最后聊聊怎么把这套东西接进真实工作流以及我对它未来走向的判断。2. 几何内核选型为什么这一步决定了整个项目的天花板2.1 三种主流几何表示方式的本质差异在动手写任何代码之前必须先回答一个问题你生成的模型用什么数据结构来表示这个选择不是技术细节而是决定项目能走多远的根本决策。目前主流的三条路线分别是网格表示Mesh、边界表示B-rep和构造实体几何CSG它们的能力边界完全不同。网格表示用一堆三角形面片拼出物体表面优点是生成简单、渲染快、和游戏引擎天然兼容缺点是没有精确的几何信息。一个圆柱在网格里就是一圈多边形逼近你没法问它这个孔的直径是多少因为它根本没有直径这个概念只有顶点坐标。如果你后续要做数控加工或者精确装配网格表示基本是死路。边界表示B-rep是专业 CAD 软件的核心它用精确的数学曲面平面、圆柱面、NURBS 曲面等来描述物体的边界同时维护顶点、边、面之间的拓扑关系。一个圆柱孔在 B-rep 里就是一个带半径参数的圆柱面你可以随时查询和修改它的半径。这是 text-to-cad 真正应该瞄准的目标表示因为只有它才能保证生成结果可编辑、可加工、可参数化。构造实体几何CSG是一种用简单形体通过布尔运算组合出复杂形体的思路比如一个长方体减去一个圆柱等于带孔的方块。它天然适合用文字描述因为文字描述本身就常常是先这样再那样的操作序列。CSG 通常作为 B-rep 的构建手段存在最终还是会落到 B-rep 上。表示方式几何精度可参数化可加工性生成难度适合场景网格 Mesh近似否差低可视化、3D 打印预览边界表示 B-rep精确是好高工程 CAD、加工制造构造实体几何 CSG精确是好中参数化建模、特征组合2.2 开源几何内核的实战对比选定了 B-rep 路线之后接下来是选具体的几何内核。我实际用过并且踩过坑的主要有三个方向这里把真实体验讲一下。第一个是OpenCASCADEOCCT这是工业界用得最广的开源 B-rep 内核功能极其完整布尔运算、倒角、抽壳、曲面建模全都有。它的 Python 绑定是 pythonocc-core装起来稍微麻烦但能用。优点是功能全、精度高、社区资料多缺点是 API 设计比较老旧学习曲线陡峭而且布尔运算偶尔会失败需要写容错逻辑。我印象最深的一次是做一个带多个相交孔的零件OCCT 的布尔减运算在特定尺寸下会报错最后靠调整运算顺序和加微小容差才绕过去。第二个是CadQuery它其实是构建在 OCCT 之上的高层封装用链式调用的方式描述建模过程写起来非常接近自然语言。比如cq.Workplane(XY).box(10,10,10).faces(Z).workplane().hole(3)就描述了一个带孔的立方体。它是我最推荐 text-to-cad 项目起步用的工具因为它的 API 天然就是操作序列和自然语言解析出来的结构化指令能一一对应。第三个是FreeCAD 的 Part 模块它同样基于 OCCT但更偏向 GUI 操作脚本化能力不如 CadQuery 顺手。如果你的项目需要和 FreeCAD 生态深度集成可以考虑否则直接用 CadQuery 更省事。提示几何内核的布尔运算失败是常态而非例外任何 text-to-cad 系统都必须内置容差处理和失败重试机制否则用户输入稍微刁钻一点就崩。2.3 为什么我最终选了 CadQuery 作为主力说几个具体理由。第一它的代码即模型一段 CadQuery 脚本本身就是一个可读的建模说明书这让我在调试自然语言解析结果时能直接看生成的脚本对不对而不是面对一堆二进制几何数据干瞪眼。第二它的参数化能力天然契合文本驱动脚本里的数字就是参数改数字就改模型这正好是 text-to-cad 需要的。第三导出格式齐全STEP、STL、DXF 都能出STEP 是工程交换的标准格式能直接进专业 CAD 软件继续编辑。当然它也有局限。CadQuery 对复杂自由曲面的支持不如直接调 OCCT 底层 API 灵活如果你要做的是汽车外形那种流线型曲面CadQuery 会比较吃力。但对于以规则几何体为主的机械零件、支架、连接件、外壳这类场景它完全够用而且开发效率高出一大截。我的建议是先用 CadQuery 把主流程跑通遇到它搞不定的曲面再下沉到 OCCT 底层不要一上来就啃底层 API那样项目大概率死在半路。3. 自然语言解析层把人话翻译成机器能懂的建模指令3.1 为什么不能直接把自然语言丢给大模型生成代码很多人第一反应是现在大模型这么强直接把用户的话丢给模型让它生成 CadQuery 代码不就行了我试过结论是能跑通简单案例但生产环境不可靠。原因有几个。第一大模型生成的代码经常有几何逻辑错误比如把孔的位置算错、把布尔运算的顺序搞反这些错误在代码层面看不出来只有渲染出来才发现模型是错的。第二尺寸和单位容易混乱用户说直径 5 厘米模型可能按 5 毫米生成了。第三缺乏一致性同一个需求换个说法生成的代码结构可能完全不同导致后续维护困难。所以正确的做法是在自然语言和代码生成之间加一层结构化的中间表示。这一层负责把模糊的自然语言解析成明确的、带单位和约束的参数对象然后再由确定性的代码生成器把参数对象翻译成 CadQuery 脚本。这样大模型只负责它擅长的理解意图不负责它容易出错的精确几何计算。3.2 中间表示的设计一个零件描述应该包含什么我设计的中间表示是一个 JSON 结构核心字段包括基体形状、特征列表、尺寸参数、约束关系、单位。举个具体例子用户说一个 100 毫米长、50 毫米宽、20 毫米厚的板四个角各有一个直径 6 毫米的孔孔中心距离边缘 10 毫米解析出来的结构大概是这样{ unit: mm, base: { type: box, length: 100, width: 50, height: 20 }, features: [ { type: hole, pattern: rectangular, count_x: 2, count_y: 2, diameter: 6, offset_from_edge: 10, through: true } ] }这个结构的好处是每个字段都有明确语义和单位代码生成器拿到它就能确定性地生成 CadQuery 脚本不需要再做任何理解。而且这个结构可以被校验比如检查孔直径是否小于板宽检查偏移量是否导致孔超出边界这些校验在自然语言层面很难做在结构化层面就很容易。3.3 用大模型做解析的提示词设计要点让大模型输出上面这种结构化 JSON提示词设计有几个关键点。第一必须给出完整的 schema 定义和字段说明不能只说输出 JSON否则模型会自由发挥。第二必须给足示例尤其是容易混淆的场景比如通孔和盲孔的区别、阵列和单个特征的区别。第三必须要求模型输出单位并且明确默认单位是什么。第四要求模型对不确定的地方显式标注而不是瞎猜比如用户没说厚度模型应该输出一个height: null并附带need_clarification: true而不是随便填一个数。我实际用下来few-shot 示例的质量直接决定解析准确率。我准备了大概二十个覆盖常见零件类型的示例对从简单方块到带沉头孔的复杂支架都有模型照着示例的格式和粒度输出准确率比零样本高出很多。另外要注意的是不要让模型一次处理太复杂的描述如果用户一句话里塞了十几个特征解析错误率会飙升。我的做法是引导用户分步描述或者把长描述拆成多个短句分别解析再合并。注意大模型解析出来的结构化数据一定要经过一轮规则校验再进入几何构建我遇到过模型把直径 6理解成半径 6的情况这种错误如果不拦截生成的模型尺寸直接翻倍。4. 从参数到实体几何构建层的实现细节与翻车点4.1 CadQuery 脚本生成的基本骨架拿到结构化参数之后代码生成器的工作就是把 JSON 翻译成 CadQuery 脚本。基本骨架是先建基体再依次应用特征最后导出。上面那个带孔板的例子生成的脚本大概是这样import cadquery as cq # 基体 result cq.Workplane(XY).box(100, 50, 20) # 四角孔距边缘 10mm直径 6mm result (result .faces(Z) .workplane() .rect(100 - 2*10, 50 - 2*10, forConstructionTrue) .vertices() .hole(6) ) # 导出 cq.exporters.export(result, plate.step)这段脚本的逻辑很清晰在顶面建立一个工作平面画一个比板子小一圈的构造矩形取它的四个顶点作为孔中心然后打直径 6 的通孔。构造矩形这个技巧是 CadQuery 里做矩形阵列孔的常用手法比手动算四个坐标简洁得多也不容易算错。4.2 特征顺序为什么会影响成败几何构建里最容易翻车的地方是特征的应用顺序。布尔运算不是可交换的先打孔再倒角和先倒角再打孔结果可能完全不同。举个真实例子一个方块要在一个角上倒圆角同时角附近有一个孔。如果先打孔再倒角倒角的刀具可能会切到孔的边缘产生奇怪的几何如果先倒角再打孔孔可能会打穿倒角面导致孔不是完整的圆柱。正确的顺序取决于设计意图而设计意图往往藏在用户的描述里需要解析层把它提取出来。我的处理方式是在中间表示里给特征加一个显式的顺序字段并且定义一套默认顺序规则基体 → 大特征凸台、凹槽→ 小特征孔、螺纹→ 修饰特征倒角、圆角。如果用户描述里明确说了顺序就按用户的来没说就按默认规则。这套规则覆盖了大部分常见场景遇到特殊情况再单独处理。4.3 布尔运算失败的排查链路布尔运算失败是 text-to-cad 最头疼的问题我踩过的坑包括面重合导致运算歧义、微小特征导致数值不稳定、非流形几何导致内核报错。排查这类问题的完整链路是这样的。第一步确认失败发生在哪一步。CadQuery 的报错信息有时候很模糊我会在每一步操作后加一个几何有效性检查用result.val().isValid()判断当前实体是否有效这样能精确定位到出问题的操作。第二步检查是否有面重合。两个实体如果有一个面完全贴合布尔运算可能因为分不清哪边是内哪边是外而失败。解决办法是给其中一个实体加一个微小的偏移比如 0.001 毫米让面不再完全重合。这个技巧我用过很多次屡试不爽。第三步检查是否有过于微小的特征。如果某个孔的直径只有 0.01 毫米而整体尺寸是 100 毫米数值精度可能不够。解决办法是在解析层就拦截过小的特征提示用户尺寸不合理而不是等到几何构建时才报错。第四步尝试改变运算顺序。有时候把先减后加改成先加后减就能绕过内核的某个 bug。这不是优雅的解法但在工程实践中有效。失败现象可能原因排查方法解决手段布尔运算报错面完全重合检查两实体接触面加 0.001mm 偏移结果几何无效微小特征精度不足检查最小特征尺寸拦截并提示用户运算结果错误特征顺序不当逐步验证每步结果调整特征应用顺序内核崩溃非流形几何检查输入实体有效性重建基体4.4 单位换算这个看似简单实则要命的环节单位问题我在项目里栽过跟头必须单独讲。CAD 内核通常以毫米为内部单位但用户可能用厘米、米、英寸。如果解析层没有统一单位后面全是灾难。我的做法是在中间表示里强制统一成毫米解析时就把所有尺寸换算好并且在生成的脚本里注释原始单位和换算过程方便追溯。比如用户说2 英寸的管中间表示里存 50.8 毫米脚本注释里写清楚这是从 2 英寸换算来的。这样即使后面发现换算错了也能快速定位。还有一个隐蔽的坑是角度单位。有些场景用户说倾斜 30 度这个 30 度是相对于哪个面、哪个轴必须明确。我的处理是在中间表示里把角度描述成相对于某参考面的旋转参考面用明确的标识而不是含糊的倾斜。5. 实测中最容易翻车的四类输入与应对策略5.1 模糊描述用户说大一点到底多大用户输入把这个孔弄大一点这种相对描述是解析层最难处理的。系统不知道这个指哪个孔也不知道大一点是多少。我的应对策略是引入对话式澄清机制当解析层检测到相对描述或指代不明时不强行猜测而是生成一个澄清问题返回给用户比如您指的是哪个孔希望增大到多少毫米。这比瞎猜一个值然后生成错误模型要好得多。如果非要自动处理可以基于上下文推断。比如前面刚提到直径 6 毫米的孔那大一点可以暂时按增大 20% 处理生成一个 7.2 毫米的候选同时标注这是基于常见调整幅度的推测请确认。关键是让用户知道系统做了假设而不是默默替用户做决定。5.2 矛盾描述又要薄又要强度高用户有时候会给出物理上矛盾的要求比如一个 2 毫米厚的板要能承受 500 公斤的载荷。这种描述在几何层面能生成但实际不可行。text-to-cad 系统本身不做力学分析但可以在解析层加一个合理性检查对明显不合理的尺寸比例给出警告。比如厚度和跨度的比例超过某个阈值时提示该尺寸可能导致结构强度不足建议增加厚度或减小跨度。这不是系统的核心功能但能显著提升用户体验避免生成一堆没法用的模型。5.3 超长描述一句话塞了二十个特征前面提过超长描述会让解析准确率暴跌。我的处理是在解析前先做分句和特征提取把长描述拆成多个独立的特征描述分别解析后再按顺序合并。比如一个方块上面有个凸台凸台上有个孔孔旁边有个槽槽的深度是 5 毫米……这种拆成方块基体凸台特征孔特征槽特征分别处理每个都简单明确准确率就上来了。拆分的关键是识别特征之间的从属关系。凸台上的孔说明孔是依附于凸台的合并时孔的操作要在凸台之后。这个从属关系可以用简单的依存句法分析提取不需要太复杂的模型。5.4 专业术语沉头孔、螺纹孔、键槽怎么处理机械领域有大量专业术语用户可能直接说打个 M6 的螺纹孔或者开个键槽。这些术语背后有标准化的几何定义比如 M6 螺纹孔有标准的底孔直径和螺纹深度。我的做法是建一个术语到几何参数的映射表把常见标准件的参数固化下来。用户说 M6系统查表得到底孔直径 5 毫米、螺纹深度等参数直接生成。这样既准确又高效比让大模型去理解螺纹标准靠谱得多。这个映射表需要持续维护遇到表里没有的术语就回退到让大模型解析并把解析结果记录下来人工确认后加入映射表。这是一个越用越准的系统前期投入建表的功夫后期会成倍回报。6. 把 text-to-cad 接进真实工作流的几种姿势6.1 作为独立工具输入文字输出 STEP 文件最简单的集成方式是做成一个命令行工具或者网页应用用户输入文字描述系统输出 STEP 或 STL 文件用户下载后导入自己的 CAD 软件继续编辑。这种方式的优点是解耦彻底、易于部署缺点是用户需要在两个工具之间来回切换体验不够流畅。适合概念验证阶段或者低频使用场景。实现上一个最小的命令行工具大概长这样text2cad 100x50x20 的板四角各一个直径 6 的孔距边 10 -o plate.step背后就是解析、构建、导出三步。这种工具我建议一定要支持从文件读取描述因为复杂零件的描述往往很长命令行里敲不方便写成文本文件再读取更实际。6.2 作为 CAD 插件在软件内直接调用更深入的集成是做成 CAD 软件的插件用户在软件里选中一个菜单项输入描述模型直接出现在当前文档里。这种方式体验最好但开发成本高需要针对不同 CAD 软件分别适配。如果目标用户集中在某一款软件值得投入如果用户分散还是先做独立工具更划算。插件方式的一个额外好处是可以利用 CAD 软件已有的几何内核和特征树不需要自己维护一套完整的建模能力。比如插件只需要生成特征操作序列由宿主软件执行这样能保证生成的模型和手动建模的模型在数据结构上完全一致。6.3 作为 API 服务批量生成和系统集成如果需求是批量生成大量变体模型或者把建模能力集成到更大的系统里那就需要做成 API 服务。用户通过 HTTP 请求发送描述服务返回模型文件或下载链接。这种方式的关键设计点是异步处理因为复杂模型的生成可能耗时几秒到几十秒同步请求容易超时。我的做法是提交任务返回任务 ID客户端轮询任务状态完成后下载结果。批量场景下还要考虑参数模板。与其让用户为每个变体写一遍完整描述不如定义一个带占位符的模板用户只提供变化的参数值。比如模板是长度 {L}、宽度 {W}、厚度 {T} 的板四角孔直径 {D}用户提供一组参数组合系统批量生成。这在产品系列化设计里非常实用。7. 我对 text-to-cad 能力边界的真实判断折腾了这么久我对这项技术的能力边界有了比较清醒的认识。它擅长的是规则几何体的快速生成和批量变体比如板类零件、支架、连接件、简单外壳这些由基本形体组合而成的零件。这类零件占机械设计日常工作的很大比例自动化价值高。它不擅长的是自由曲面和高度艺术化的形状比如汽车外形、消费电子的流线型外壳、雕塑类模型。这些形状很难用文字精确描述即使描述了几何构建层也很难准确还原。这类需求还是得靠传统的曲面建模或者专门的生成式 3D 技术。它目前最现实的定位是设计助手而不是设计替代。它帮你把重复的、规则的部分快速搭出来把精力留给真正需要创造力和工程判断的部分。把它当成一个能听懂人话的建模加速器而不是一个能独立完成设计的 AI 设计师这个预期才是合理的。还有一个容易被忽视的点是可追溯性。text-to-cad 生成的模型最好能保留从文字描述到最终几何的完整链路包括解析出的结构化参数、生成的脚本、每一步的操作记录。这样当模型需要修改时可以回到链路中的任意一环调整而不是面对一个黑箱模型无从下手。我在项目里把这条链路存成一个 JSON 日志和模型文件一起保存实际用起来非常方便。最后分享一个实操心得不要追求一步到位生成完美模型。更高效的工作流是让 text-to-cad 生成一个八九不离十的初版然后人工在 CAD 软件里微调。追求全自动往往导致系统过度复杂、维护成本飙升而生成初版人工精修的组合在效率和可靠性之间取得了最好的平衡。我现在的用法就是这样生成初版大概能省掉百分之六七十的建模时间剩下的精修交给人的判断整体效率提升非常明显。

text-to-cad 实战：从自然语言到参数化 CAD 模型的完整落地链路

相关推荐

FFmpeg字幕嵌入GUI工具：批量硬编码SRT/ASS到MP4的生产级方案

iOS应用合规下架潮：开发者应对策略与技术方案

S7-1214C Modbus TCP通信实战：从组态到排错

更多资讯

科研必备：如何高效查找同一数据集的关联论文

STM32驱动AD7606的SPI时序协同与高精度采集实战

GESP 2024年12月武器强化题解｜枚举详细讲解

华为CANN SHMEM：跨设备内存通信优化分布式训练

名称、命名空间与符号冲突：从命名规范到工程落地

Kubernetes运维实战：5大核心问题解决方案

今日更新

基于YOLOv11的石油泄漏智能检测系统开发实践

AI行业变局：合规、Mod化与上下文管理的实战启示

计算机视觉与AI原生应用融合的技术实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

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

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

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

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