企业官网建设流程全解析

上周加完班，朋友发来一句话：“帮我做一个L形支架，长边80毫米，短边60毫米，宽度50毫米，底部开两个对称的8毫米安装孔。” 我下意识打开CAD准备画草图，突然意识到已经不用这么干了——把这句需求原样扔给text-to-cad工具，几秒钟就能拿到一个可编辑的STEP文件。这个场景在两三年前还只能在论文demo里看到，现在已经能实实在在嵌入工作流了。

text-to-cad，顾名思义，就是把“自然语言描述”变成“CAD模型”的技术方向。核心是让大模型理解几何语义，把一句话里的形状、尺寸、位置关系、连接方式，翻译成机器可以执行的三维建模指令。这篇文章我会拆开聊三件事：这类工具背后的技术路线到底有哪几种、哪条路现在真正能落地、以及我自己实测下来的一套完整工作流和一堆踩坑记录。适合正在选型、想自己搭一套文本建模工具链的工程师，也适合刚接触这个方向、想知道“这玩意到底怎么work”的产品和技术同学。

1. text-to-cad到底在解决什么问题

1.1 从一句话到三维模型：需求拆解

先看一条典型的自然语言需求：“做一个底板，200长，150宽，10厚，四角各有一个M6通孔，孔心距边缘15毫米。” 人要理解这句话很容易，但要让程序理解，必须把它拆成结构化的几何约束。

拆解下来大概是这么几类：形状类型（底板）、总体尺寸（200×150×10）、特征数量（4个孔）、特征尺寸（M6）、特征位置（距离边缘15毫米）、位置关系（四角对称）。这正好对应传统CAD建模时的操作序列——先画草图拉伸成板，再在四个角上打孔。text-to-cad的工作本质，就是把这个“建模操作序列”自动生成出来。

这个拆解过程并不只是做关键词提取，难点在于空间关系推理。比如“孔心距边缘15毫米”意味着需要知道哪条边是“边缘”，需要知道孔落在哪个面上，需要处理“四角”这种隐式的对称关系。语言模型做这件事有一个天然优势：它在海量文本上见过类似的描述方式，能够在语义层面理解“四角各一个孔”等价于“4个孔沿中心对称分布”这种表述背后的几何意图。

1.2 为什么现在才火起来

其实“文本生成CAD”这个想法本身并不新。十几年前就有研究尝试用规则引擎解析自然语言，当时的目标是“让不会用CAD的人也能做设计”，但效果一直很差。原因是老方法靠的是有限的关键词库和手工编写的语法规则，稍微换一种说法就彻底失效，“在角落里打孔”和“在角落布置孔特征”在规则系统里是两条完全不同的逻辑路径。

真正翻开这一页的是大语言模型。它能够从语义上理解多样化表达，不需要你精确地说“创建草图-拉伸-去除材料”这种命令语言，直接用口语就能反向推理出建模步骤。加上2024年以来出现了一批专门针对CAD领域的数据集和基准测试，比如Text2CAD、CAD-Coder等方向，把“自然语言映射到程序化建模代码”这件事从概念验证推进到了可评估、可迭代的工程阶段。现在你能看到的text-to-cad工具，绝大多数背后都是语言模型在生成某种程序化建模代码，而不是像普通文生图那样直接生成像素点阵。

这背后的本质区别值得多说一句：文生图生成的是位图，像素错了肉眼未必看得出，但CAD失败会直接报错或产出烂几何。所以text-to-cad的工程路径天然更接近“让模型写一段CAD脚本”，而不是“让模型吐一个多边形网格”。

2. 底层逻辑：大模型不会画图，但它会写程序

2.1 技术路线的本质分歧

目前做text-to-cad，主流的实现方式可以粗暴分成三类：检索式、命令序列式、端到端生成式。这三类不是同一个问题的不同解法，而是完全不同的思路，落地难度和效果上限完全不一样。

有人可能会问：为什么不用类似文生图的扩散模型直接生成一个三维模型？这个问题问到点子上了。扩散模型生成点云或体素已经有了不少研究，但它只能给出一个网格表面，没法给出CAD意义上的几何内核——没有参数化的草图、拉伸、特征树、约束关系。对机械零件来说，没有特征树的模型等于一张死图片，改个孔位都要重新建模。所以端到端生成式目前只适合做外观造型，不适合做工程零部件。

2.2 路线一：检索式生成

检索式是三条路线里最“朴素”但也是最先商业化的路径。它的逻辑一句话就能讲清楚：把用户的文本需求编码成向量，到零件库里去搜索语义最接近的已有模型，返回结果并按用户的需求做有限的参数适配。

举一个实际产品例子：某标准件平台的“语音搜零件”功能，你输入“内六角圆柱头螺钉 M6×20”，系统不是现场建模，而是把这句话和库里的零件元数据做语义匹配，直接返回对应的三维模型。这就是检索式text-to-cad。

这种路线的优点是几乎不会产生“烂模型”，因为返回的都是库里真实存在、已经过验证的零件。但它的天花板也非常明显：库里没有的东西，再搜也搜不出来。你要找一个特定形状的非标支架，检索式基本无能为力，它只能给你“最接近的那个”，而你在工程上往往不需要“最接近”，你需要“正好”。

2.3 路线二：命令序列生成

命令序列式是目前最被看好的路线，也是大部分真正“能用”的text-to-cad工具选择的方案。它的思路是：不直接生成几何体，而是生成一段可以被CAD内核执行的建模代码或命令流。

具体来说，常见的输出目标有三种：一是CadQuery、OpenSCAD这种程序化建模库的代码；二是FreeCAD、SolidWorks等软件的API调用脚本；三是某种中间表示（比如CAD命令序列）。模型像一个会写代码的助手，你告诉它需求，它写出程序，程序跑出来一个模型。

这里有一个关键洞察：语言模型在训练时并没有专门学过CAD，但它见过大量的代码，包括CadQuery的示例、OpenSCAD的手册、甚至论坛里的Python建模脚本。当它生成代码时，实际是在模仿这些分布。所以你会发现，越流行的程序化建模框架，模型生成的效果越好——因为网上相关语料越多。

2.4 路线三：端到端生成与网格重建

端到端生成走的是“生成式AI通用套路”：用扩散模型或自回归模型直接生成三维表示（体素、点云、隐式场），再通过移动立方体等算法重建出网格。这条路看起来最“AI”，但实际工程问题最多。

首先是精度问题。重建网格的精度远远达不到机械加工的需求，一个声称“直径8毫米的孔”，重建出来可能是7.8毫米且截面不圆。其次是可编辑性问题。CAD工具对模型的操作是建立在参数化特征之上的，网格模型没法直接改特征参数，只能当作STL小面片使用，这在工程上意味着它只能用于3D打印预览，进不了正式的机械设计流程。

目前比较靠谱的应用场合是概念设计阶段的外观探索——比如说“做一个类似水滴形态的壳体”，端到端的生成结果可以给你灵感，然后你再人工用曲面工具重新建模。把它当作一个快速草图工具可以，把它当作CAD替代品，还差得很远。

3. 目前最靠谱的落地路径

3.1 路线对比：选哪条路取决于你的场景

我不建议一上来就追最热的技术路线，先看你要解决的到底是哪一类问题。三条路线的适用场景差异非常大，选错了等于拿扳手拧螺丝刀，工具再好也白搭。

我推荐大多数工程师把精力花在“命令序列式”上，也就是让语言模型写CadQuery或OpenSCAD代码。这不仅是技术上最现实的路线，而且对工程师来说有个额外好处：生成的代码本身就是一份建模过程文档，你可以审查每一步，出了问题能定位到具体行，这和黑盒生成一个STL的体验完全不一样。

3.2 方案A：语言模型 + CadQuery脚本

CadQuery是一个基于Python的程序化建模库，它对机械零件建模的友好程度很高。和OpenSCAD的纯CSG思路不同，CadQuery的API非常接近传统CAD的工作方式：你可以在一个工作平面上画草图、拉伸、开孔、倒角、圆角。

用语言模型驱动CadQuery的流程大概是这样的：先让模型理解需求，生成Python代码，然后用CadQuery执行代码生成实体，最后导出STEP或STL。我实测下来，对于板类、框架类、带孔带槽的零件，模型的成功率最高，因为这些零件的建模逻辑相对固定——拉伸出主体，布尔运算减出孔槽。

要注意一个细节：CadQuery的版本兼容性问题。不同版本的API命名有细微差异，比如旧版本用box()，新版本可能推荐用box()但参数变了。模型训练时学到的可能不是最新版API，生成代码偶尔会报错。我的习惯是在提示词里强制指定“按CadQuery 2.4版本语法”，并且把常用的几行import语句模板直接塞进提示词里，能省掉很多报错。

3.3 方案B：语言模型 + OpenSCAD

OpenSCAD走的是纯代码建模路线，没有交互式界面，所有几何体都是通过代码里的CSG操作（并集、差集、交集）组合出来的。它的编程模型更简单直接，非常适合语言模型推理。

举个例子，让模型生成一个L形支架，OpenSCAD代码可能是这样：

module l_bracket(length, width, height, thickness) { // 长边 cube([length, thickness, height]); // 短边 translate([0, width - thickness, 0]) cube([thickness, width - thickness, height]); }

这种代码的推理成本比CadQuery低，因为OpenSCAD的概念更简单——基本几何体、坐标变换、布尔运算。语言模型在这类代码上的“幻觉”概率会小很多。代价是OpenSCAD对于复杂建模（比如扫描、放样、变半径圆角）支持较弱，所以它更适合快速原型、外壳、支架这类零件。

如果你只是想快速验证一个想法，OpenSCAD的方案上手最快：装个OpenSCAD，往模型引擎里输入需求，得到的代码直接在OpenSCAD里打开就能实时看到结果。但如果你需要交付STEP格式给下游配合，CadQuery方案更稳，因为它直接支持标准的STEP交换。

3.4 方案C：语言模型 + 参数化零件库调用

这是我认为工程落地潜力最大、但容易被忽视的一条路。思路是：不指望模型自己从零生成几何，而是让它学会选择和调用你公司已有的参数化零件库。

打个比方，模型不是建造师，而是仓库管理员。你说“我要一个M8的六角头法兰螺栓，杆长30毫米”，模型不生成螺栓的几何，而是调用零件库里预制的螺栓生成函数，传入对应参数。

这种做法的优势非常明显：所有几何都是由经过验证的参数化模板生成的，形状完全可控，公差体系、材质属性、甚至加工工艺信息都可以跟着模板一起带出来。本质上，语言模型只是充当自然语言和参数化API之间的翻译器。

实现上无非是给模型提供一份“工具说明”，告诉它有哪些零件函数、每个函数接受什么参数。我见过一些自动化设备公司已经在内部这么干了——把标准件库包装成API，让技术员直接用自然语言查料号、出模型，准确率能做到九成以上。这个方向对中小企业尤其有吸引力，因为它不需要训练自己的模型，只需要梳理好现有的零件库和文档。

4. 搭建一个能用的text-to-cad工作流

4.1 工具链推荐

以最通用的方案A为例，我给你一份可以直接照抄的工具链。整体结构不复杂：语言模型负责“理解需求并写代码”，本地环境负责“执行代码并产出模型”，中间记得加一层校验。

• 语言模型接口：建议用支持函数调用或代码生成能力较好的模型。你直接调用API也行，用本地部署的开源模型也行，取决于你的数据保密要求。工程建议：保留一个“生成-重试”的循环，模型第一次生成的代码错误率高是常态。
• 代码执行环境：本地安装CadQuery即可，它是pip包，pip install cadquery就完事。注意Python版本要匹配，CadQuery目前对Python 3.10以上支持比较完善。
• 可视化调试：CadQuery官方有CQ-editor，一个带视图的IDE，能把生成的代码实时渲染成三维模型。强烈建议用它做中间检查，别直接跳到导出STEP。
• 文件输出：CadQuery支持直接导出STEP、STL、SVG等格式。给下游制造或仿真时用STEP，给3D打印用STL。

4.2 一份我实测好用的提示词模板

提示词是text-to-cad里决定性的一环。模型能不能生成对的代码，很大程度取决于你怎么描述需求。我踩过无数坑之后，总结出一套提示词结构：先给角色和规则，再给需求描述，最后锁死输出格式。

你是CadQuery建模专家。你的任务是把用户描述的三维零件需求，转换成可直接运行的CadQuery Python代码。规则： 1. 只使用CadQuery 2.x版本的API。 2. 所有尺寸默认单位是毫米。 3. 只输出完整Python代码，不解释、不添加注释之外的内容。 4. 如果需求信息不足，在代码开头用TODO注释标出缺失参数，不要猜测。 需求：{用户的自然语言描述} 输出代码：

这个模板看起来简单，但每句话都有用。第2条锁死单位，避免模型上次用毫米这次用英寸。第3条锁死输出格式，不然模型会在代码前后夹带一堆解释文字，解析起来很蛋疼。第4条特别关键——模型在信息不足时倾向于“猜一个数”，这在CAD里是致命的，宁可让它标注TODO也不能让它瞎填。

另外一个小技巧：对复杂零件，别指望一条提示词一步到位。分成两步来，第一步先让模型输出“约束清单”，把自然语言里的尺寸、位置关系梳理成结构化表格；第二步再把约束清单扔回去，让它生成代码。这样能显著降低漏尺寸、错位置的概率。

4.3 后处理与验证闭环

text-to-cad的产出不能直接当最终交付物，必须加一层自动化校验。我推荐至少做下面三项检查，每一项都有具体的工具支撑。

第一项是几何合法性检查。最简单的方法是检查模型是否水密、有没有自相交面。CadQuery生成的实体本身通常不会自相交，但当你做布尔运算组合多特征时，偶尔会翻车。可以写几行Python检查体积是否为负、边界是否闭合。

第二项是尺寸抽检。把生成成品的实际尺寸和你需求里的关键尺寸做对比。这里可以用CadQuery内置的boundingBox()方法，检查外轮廓尺寸是否符合预期，比如需求是200毫米长，结果代码执行完出来一个208毫米的实体，说明某个参数推断错了。

第三项是人工目检。在CQ-editor里打开模型，旋转视角看一遍，重点关注孔的位置、倒角的朝向、特征的相对关系。这一步虽然在AI时代显得有点土，但依然是发现问题的最高效手段——人的视觉系统对几何异常非常敏感，很多代码逻辑完全正确但结果就是“看起来不对劲”的问题，只有这一步能兜住。

整个流程走完，再把验证过程中发现的问题反馈回提示词，形成一个小的迭代闭环。我现在的习惯是：第一轮生成后不急着从头改，而是把验证代码输出给我的模型，让它自己分析哪里偏离了需求，再自动修正。这样跑两三轮，大多数零件都能收敛。

5. 实测场景与翻车记录

5.1 典型实测案例

我自己拿一个真实场景测过：做一个电机安装支架，需求是“底板120×80×8，四角通孔M5，中心凸台直径40高度12，凸台正中有一个直径22的沉孔深8”。这是一个非常典型的机械零件，有板、有凸台、有通孔、有沉孔，逻辑不复杂但仍需要建模者正确推导特征顺序。

用CadQuery方案，一次生成成功率大概在六成左右。第一次跑出来的代码通常能建出底板和四角孔，但凸台下方的沉孔经常被写成贯穿孔，因为模型对“沉孔深8”理解成了“切除深度8”，却忽略了一个重要前提——这个沉孔不是开在底板上，而是开在凸台上，位置不一样，深度基准也不一样。

这个例子很有代表性：模型不是不理解“尺寸”，而是搞不清特征的“依附关系”。它知道要做一个直径22的孔，也知道深度是8，但判断不了这个孔的起始面在哪。解决办法是在需求描述里加显式的空间锚点——不说“有一个直径22的沉孔深8”，而是说“在凸台的顶面向上偏移x毫米处，做一个直径22、深度8的沉孔”。描述得越像建模工序，模型的成功率越高。

5.2 高频问题速查表

列一个我实测遇到最多的问题清单，每一类都给出症状和解决方向。

关于最后一行多说几句，这是最隐蔽的问题。模型生成一个能跑的代码，形状也说得通，但跟你想要的根本不是一回事。比如你想要一个“卡扣”，模型生成的是一个“加强筋”。这种错误在自动校验阶段根本发现不了，因为它不是一个“错误”，而是一个“有逻辑的不同方案”。我唯一有效的手段是在提示词里描述功能场景——“用来卡住直径10的圆管”，而不是只描述形状“半圆环”。功能描述才能约束模型的想象力。

5.3 目前的能力边界

text-to-cad不能干什么，我帮大家画一条清晰的红线。

第一，高精度配合面做不了。模型的输出精度普遍在0.1毫米这个水平，真要到配合公差（比如H7/g6），必须靠人工精修或者直接不用这条路。第二，装配体级别的建模做不了。它擅长单个零件的建模，但“做一个由5个零件组成的铰链机构，并定义它们的装配关系”——这种任务目前基本只能生成零件，装配关系还是要自己拖。第三，复杂曲面和自由造型做不了。你让它生成“一个符合空气动力学曲线的前脸外壳”，它生成的会是一个“由糊涂曲面拼起来的什么东西”，离可用的工业曲面十万八千里。

认清边界之后，反而更好用——把时间花在它擅长的场景：板类零件、支架、外壳、基础机械特征、标准件调用、概念验证模型。这些场景下它能帮你省下一半以上的建模时间，这就已经非常有价值了。

6. 我的一点实操体会

最近用下来最大的感受是，text-to-cad不是一个“不用学CAD”的解决方案，而是一个“CAD建模效率倍增器”。它把从“想法到模型”之间的机械劳动压缩掉了，但前提是你得懂建模、懂工艺，才知道怎么跟它描述需求、怎么判断它生成的对不对。

我的常规操作现在是这样的：先在纸上画一个最粗糙的草图，理清这个零件的核心拓扑关系，然后写一句非常具体的自然语言需求塞给模型，让它给约束清单，确认无误后再让它生成代码，最后用自动校验加人工目检收尾。整个流程走完，快的时候几分钟能出一个可用零件，慢的时候也就是多一轮迭代的事。

如果你是想在团队里引入这套工作流，我建议从“标准件库+语言模型”这个方向起步，先让采购和技术员用自然语言出标准件模型，见效快、风险低。等大家用顺手了，再逐步扩展到非标零件生成。工具迭代迭代很快，但思路和方法是通用的——先拆需求，再翻译成建模步骤，最后用校验闭环兜住底线。这套逻辑不管底层模型怎么换，都不会过时。