企业官网建设流程全解析

前一阵有朋友问我说，有没有可能用一句话就让电脑自己把零件模型画出来。我直接给他演示了一条 text-to-cad 的链路：输入“底板长120、宽80、厚10，四角各有一个直径8的沉头孔，孔距边缘10毫米”，几十秒后软件里出现了一个特征树完整的三维 CAD 模型，导出成 STEP 文件直接能进加工评估流程。朋友愣了半天，说这玩意儿要是早几年有，他当年画图工时至少能砍一半。

text-to-cad 这个方向，本质上是把“自然语言描述”转成“参数化、可编辑的三维 CAD 模型文件”，而不是生成一张图片或者一个三角网格。它处在 AI 辅助设计和传统几何建模的交汇点上，这两年因为大语言模型和多模态技术的成熟，热度一下子起来了。这篇文章我就结合自己实际跑通的经验，把它的核心思路、技术路线、实操链路和踩坑记录完整拆给你，想尝试的人可以直接照着走一遍。

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

1.1 同样是 AI 生成，为什么 CAD 比图片难这么多

很多人第一次听到 text-to-cad 会觉得，这不就是“文生图”换个输出格式吗？实际上完全不是一回事。文生图输出的是像素矩阵，稍微有点失真、边缘有点糊，人眼大部分时候看不出来；但 CAD 模型面对的是制造和装配场景，差 0.1 毫米可能就装不上，差一个约束关系的语义，特征树就崩了。所以 text-to-cad 生成的不是一个“看起来像”的形状，而是需要一套完整的、严格受控的建模过程记录。

传统的手工建模工作流里，一个中等复杂度的零件，从读需求到完成参数化建模，熟练工程师也得花半小时到数小时不等。而这其中的大量操作是重复性的：画草图、加约束、拉伸、打孔、倒角。text-to-cad 想做的是把这些重复劳动压缩掉，让人只需要描述“我要什么”，而不用操心“怎么一步一步画出来”。

1.2 它替换的不是设计师，而是建模过程中的“翻译层”

我个人的理解是，text-to-cad 并不是要替代设计师，它替代的是“从自然语言需求到 CAD 特征操作序列”之间的翻译过程。设计师依然需要判断这个设计合不合理、工艺能不能实现、成本高不高，但这些判断建立在一个快速生成的草模之上。以前拿到需求先对着空白画布发呆半天，现在可以先让模型出一个方案，然后你在这个方案上改，效率完全是两个量级。

这也是它比普通三维生成更值钱的地方：不是给你一个固定的、不能改的网格体，而是给一个带了完整特征树的参数化文档。你在软件里改一个尺寸，后面的孔位、倒角会跟着联动更新，这是传统生成式三维模型做不到的。

2. 四种主流技术路线，逐个拆给你看

2.1 路线一：把 CAD 建模过程当成程序序列来生成

这是目前学术界最主流的方向。思路其实很简洁：一个 CAD 模型本质上是由一系列建模指令构成的，比如“新建草图”“画矩形”“拉伸 30 毫米”“在面上打孔”“添加圆角”。如果把这些指令看成一种特殊的程序代码，那么 text-to-cad 就变成了一个“从文本到代码”的生成问题。

代表性的实现方式是训练一个序列到序列模型：输入是文本描述的向量表示，输出是离散的 CAD 操作序列。每个操作都带有参数，例如拉伸的高度、草图的几何坐标、布尔运算的类型。训练数据来自大规模 CAD 建模过程的数据集，把大量的历史建模操作录下来，让模型学着预测“下一步该做什么”。

这条路线的优点是生成结果天然可编辑，因为它输出的每一步都是符合建模软件逻辑的合法操作；缺点是序列长度一旦变长，错误就开始累积，经常出现“前半段很合理，后半段突然崩了”的情况。针对这个问题，目前业界的主流做法是引入“草图-拉伸-布尔”的层次化生成结构，先生成草图拓扑，再在上面叠加特征操作，相当于把一个长故事拆成几个短章节来写。

2.2 路线二：让大语言模型直接写参数化脚本

这条路线更接地气，也是我最快跑通的方案。思路是绕过专门的 CAD 序列模型，直接把任务交给大语言模型：给它一个需求描述，让它输出一段可以执行的三维建模脚本，比如 FreeCAD 的 Python API 脚本、OpenSCAD 代码，或者某个内核的建模命令流。

大语言模型的优势在于语义理解能力强，能处理“带法兰的圆管接头”“四角有安装孔的长方形底板”这种模糊表达；劣势在于它生成的代码经常有语法错误、逻辑不完整、引用不存在的对象。我的实测经验是，一次生成就能直接跑通的概率大概只有四到六成，其余时候需要“生成-报错-修正-重跑”的循环。

但这条路线的天花板并不低。因为大语言模型本身不是不能写代码，而是缺少“用建模工具正确表达意图”的专门训练。现在已经有项目在收集“文本描述 + 对应脚本”的指令微调数据，微调之后的模型在生成 OpenSCAD 和 FreeCAD 脚本上的稳定性明显提升。对我来说，这是当前普通人最容易上手 text-to-cad 的入口。

2.3 路线三：端到端三维生成，再做边界表达重建

还有一类方案是完全不经过“建模操作序列”这条路，直接用扩散模型或隐式场从文本生成三维几何，再把生成结果转换成 CAD 可编辑的边界表达（B-rep）。这条路生成的几何表面质量通常最好，能表达复杂的自由曲面，但难点出在“转换”这一步。

从网格到 B-rep 的重建，本质上是一个逆向工程过程：要把三角形网格拟合成平面、圆柱面、球面，再求出它们的交线、裁剪和缝合关系。这个过程对数值稳定性要求极高，稍微有点噪声就会导致面片错位或者开放边界。我试过几次，用到实际工程场景中还得大量手工修复。

这条路目前最适合的概念是“提供灵感造型”，也就是先由文本生成一个粗略的形状，再由人去手动重新建模。但对大多数工程需求来说，“能出图”和“能修改”之间的鸿沟还比较明显，不一定比直接画草模快。

2.4 路线四：混合范式，用大模型做任务分解再加约束求解器

最近我试过最稳的方案是混合范式：大语言模型不做具体的几何计算，而是把需求拆解成“用哪些特征、按什么顺序、大致尺寸多少”，然后交给前端的参数化模板和约束求解器去完成精确建模。

打个比方，这就像让一个项目经理排任务，再把任务分发给熟练的师傅去做。大模型负责全局规划和语义理解，求解器负责精度和约束。比如你能直接告诉模型“生成一个 M8 螺栓的六角头”，模型先判断这是一个旋转体加六棱柱布尔求交的过程，然后调用预制好的参数化模板，填入 M8 的标准尺寸，最后由几何内核完成精确求解。

这类方案的好处是避开长序列生成的不稳定性，同时保证几何精度；短处是需要为不同品类的零件准备高质量的模板库，覆盖面有限。我个人的判断是，短中期内这种混合方案最有可能落地到实际工程流程里，因为它把大模型的“聪明”和几何内核的“严谨”分开了。

3. 实操记录：从环境搭建到跑通最小流程

3.1 环境准备阶段

不管选哪条路线，环境准备逃不掉。我以“序列生成 + 后处理验证”的组合为例，给你一份能照抄的清单：

• 操作系统：Ubuntu 22.04，用 Windows 的也能跑但编译依赖时坑更多；
• Python 3.10 及以上版本；
• CAD 工具箱：用于加载和处理建模操作序列数据，安装时注意它依赖的 numpy 版本不能太新，否则会出现数据类型兼容问题；
• 预训练权重：直接从开源社区下载，不用自己训练；
• FreeCAD：用于后处理和导出 STEP 文件，选 0.20 以上版本；
• CUDA 环境：如果有 NVIDIA 显卡建议配好，没有显卡用 CPU 也能推理，只是慢一些。

安装依赖时我踩过一个最典型的坑：直接用最新版的 PyTorch，结果因为版本兼容问题导致算子崩了。后来把 PyTorch 固定到与预训练权重官方文档一致的版本才跑通。建议所有人拿到项目后先看官方的 requirements 文件，锁定版本，不要图新。

3.2 文本到模型的完整推理流程

我整理了一套比较稳定的最小流程，分五步走：

第一步，写描述。最稳的写法是“句式完整 + 数字明确 + 类别先行”。比如“一个 M8 六角头螺栓，头部对边宽度 13 毫米，头部高度 5.3 毫米，螺纹长度 20 毫米，总长 40 毫米”，模型出结果的准确率明显高于只写“一个螺栓”。

第二步，把文本喂给文本编码器，得到语义向量。这里要注意：文本编码器和序列生成模型的维度必须对齐，如果你换了编码器，后面的生成器基本等于白搭。

第三步，模型自回归生成 CAD 操作序列。这一步是整个流程中最慢也是最有风险的一环。我跑的模型生成一条大约 30 步的操作序列需要几十秒到几分钟，取决于序列长度和显卡性能。

第四步，把操作序列编译成参数化文档。这一步看起来不起眼，其实是决定成败的环节。序列里每一步的参数必须是合法的，比如不能拉伸一个不存在的草图、不能对空面打孔。一旦有一处不合法，整个文档就会重建失败。

第五步，把参数化文档导入 FreeCAD，检查特征树、测量关键尺寸，最后导出 STEP 文件。

下面是一段简化过的流程示意（为了方便理解，去掉了大量数据结构细节）：

解析文本：提取实体类型、关键尺寸、特征数量。 生成序列：按条件采样得到建模操作步骤。 封装文档：为每个步骤配置参数和依赖关系。 重建校验：用 CAD 内核尝试重建，失败则记录错误位置。 导出成果：成功重建后，导出为 STEP 或 STL 格式。

3.3 从序列到 STEP 文件的格式流转

很多第一次接触的人会问，为什么搞这么复杂，直接输出一个文件不就行了吗？关键在于，CAD 文件本身不是“一张图”，而是一棵特征树。特征树里保存着每一步的操作顺序和参数关系，后续任何一步的修改都会影响下游特征。所以生成过程要保留这个逻辑结构，才能实现“改一个值，整个模型跟着变”。

我实际操作时，在模型输出指令序列之后，会做一步“合法性检查”：把每一指令的参数映射到具体的几何对象上，提前发现引用不存在对象的问题。这样能避免把一堆没法重建的指令直接丢进 CAD 内核导致崩溃。

在实际项目里，我通常还会加一层“规格约束”：比如生成紧固件时，直接查标准件参数表，把要求匹配到标准规格上。这样生成的模型更接近工程实际，而不是一个凭空的长螺栓。

4. 关键参数、度量指标与调优心得

4.1 生成质量和稳定性的核心参数

text-to-cad 模型的采样参数和普通语言模型非常像，但调整手感差别很大。我给几个实测过的经验值：

温度参数，控制在 0.2 到 0.5 之间。温度太高会生成天马行空的草图，比如拉伸一个不闭合的线段；温度太低又容易反复生成最常见的几何体，比如所有东西都变成一个长方体。我用 0.3 作为默认值。

最大序列长度，不要设得太小。很多模型失败的原因不是能力不够，而是生成到一半被截断了。设成目标长度的 1.5 倍比较合理；但也不是越长越好，太长等于给了模型更多犯错空间。

束搜索宽度，在精度优先场景可以开到 5；在探索设计方案的阶段反而用随机采样会带来更多惊喜。

重复惩罚系数适当加一点，因为 CAD 序列里如果有重复的倒角操作，不仅浪费参数，还会导致几何内核重建失败。

4.2 怎么评估一个 text-to-cad 模型好不好

只靠眼睛看“像不像”肯定不够。我一般从四个维度来衡量：

第一是序列合法性，即生成的每一步在 CAD 建模规则里是否合法，这是最基础的底线指标。第二是几何合理性，重建出来的模型体积是否合理、有没有自相交、有没有零厚度的薄片。第三是尺寸准确性，关键尺寸与文本描述的偏差要控制在可接受范围内，工程场景一般要求不超过 5%。第四是可编辑性，导出到软件里之后，特征树是否完整、改一个尺寸是否影响全局。

说实话，如果只能选一个维度，我一定选序列合法性。因为一个序列不合法的模型连打开都做不到，后面一切免谈。

4.3 提示词对结果影响的实际对比

我跑了一批实验，对比不同表达对结果的影响。同样是生成一个带孔的方块，效果差异非常明显：

写法一“一个方块上有四个孔”，模型倾向于生成一个正方形加四个圆柱布尔差集，但孔的位置和大小随机。

写法二“一个边长为 50 的立方体，中心有一个直径 10 的通孔”，模型能比较稳定地生成一个居中的圆柱孔，尺寸基本准确。

写法三“一个边长为 50 的立方体，顶面四角距边缘 8 毫米处各有直径 6 毫米的沉头孔，沉孔深度 3 毫米”，序列长度明显变长，但依然能生成，只是偶尔出现沉孔深度和总厚度冲突的情况。

这个对比说明，文本语义必须和 CAD 特征语义对齐。你说“四个孔”，模型不知道孔是用来定位的还是过螺栓的，是通孔还是盲孔；你得把空间关系和功能描述补全，模型才能输出符合预期的操作序列。

5. 常见问题与排查实录

5.1 提示“序列不合法”或“重建失败”

这是出现频率最高的问题，几乎每个跑 text-to-cad 的人都躲不过。我的排查路径基本是固定的：

先看失败栈信息里的具体位置，判断是草图错误还是特征引用错误。如果发生在草图阶段，大概率是生成了不闭合的曲线，或者坐标系定义越界；如果发生在特征阶段，多半是引用了不存在的几何对象。

处理方式一般是先把模型输出序列打印出来，逐条检查，发现是哪一步导致的失败，再决定是修正参数还是重新采样。直接重新采样一次的成功率往往不高，因为温度随机性带来的问题会换个位置再出现。我的技巧是，把失败序列的前半段当成条件，让模型只续写后半段，这样能保住已经合理的部分。

5.2 尺寸不对、单位错乱

不同模型对单位的默认值不完全一样，有的模型内部用毫米，有的用英寸。一旦没做归一化，生成的结果可能整体大了或小了 25.4 倍。这个坑极其隐蔽，因为只看形状完全看不出来。

建议在解析文本时先做一次单位归一化，把所有尺寸换算到同一个单位体系，生成完成后再根据目标单位换算回去。我习惯在项目里的文本预处理阶段统一为毫米，内部表示全部用浮点数。

另外提示词里的“高度 5.3 毫米”和“高 5.3”对模型的影响也有细微差异。标准单位名称尽量带上，模型对省略单位时的默认推断并不总是你想要的。

5.3 图元欠约束或过约束

约束求解失败是比较头疼的问题。欠约束会导致草图自动变形，过约束会导致求解器报冗余约束。

这个问题的根源在于模型的“草图自由度”概念并不可靠，它虽然能生成很像样的几何线段，但不理解哪些约束是必要的、哪些是多余的。解决思路有两个：一是后处理时用算法自动补全约束，把共线、垂直、对称关系检测出来；二是在模型训练阶段引入约束求解器作为可微模块，让模型在生成时就朝着“可求解”的方向优化。后者难度大，但效果明显更好。

5.4 长序列生成到一半开始逻辑漂移

这个问题在序列超过三十步时非常明显。模型一开始还认真画底板，画着画着突然在侧面生成了一个无关的圆柱，再往后又开始做圆角，整体逻辑已经乱了。

我的应对方案是分阶段生成：先生成基础主体特征，固定住，再在这个基础上追加附加特征，而不是一次性让模型生成完整序列。如果能在模型层面加一个“特征类型切换”的控制信号，效果会更好，相当于让模型知道“主体已经完成，现在进入打孔阶段”。

5.5 生成速度太慢，如何优化

直接用台式机的 CPU 推理，一个中等复杂度的模型可能要等上十分钟，体验非常差。如果不想升级显卡，有几个可行的优化手段：

一是尽量缩短输入文本长度，文本编码器消耗的时间比想象中多。二是开启批次推理，把多个需求一起发，比单条请求逐条跑要快得多。三是降低最大序列长度，因为自回归生成的耗时几乎和序列长度成正比。

说实话，在真正高效的低成本推理方案普及之前，生产环境大规模部署 text-to-cad 还有距离；但个人试玩和原型验证已经绰绰有余。

6. 一些更深入的思考

6.1 数据质量决定了这个方向的天花板

文本到 CAD 的模型训练，依赖的是“自然语言描述”和“建模操作序列”的配对数据。但目前公开数据集的规模相比语言模型的数据量还是太小，而且描述文本大量是通过脚本自动生成的模板化文本，缺乏人类工程师真实的表达习惯。

我做实验时发现，同一个模型，在人工书写的描述上效果明显比模板描述差。这说明模型并没有真正理解文本和模型之间的映射关系，更多是在背模板。未来如果有大规模的真实设计需求日志作为训练数据，效果会有质的提升。

6.2 可编辑性比“像不像”更重要

一个很容易被忽略的点是，text-to-cad 领域里“生成一个好看的模型”不是目标，因为好看的网格可以在渲染器里瞬间生成几十个，但一个能改尺寸、能换材质、能进加工流程的参数化模型才是工程需要的。

这也是为什么我反复强调“特征树完整性”和“约束完备性”。模型生成的零件也许外观上跟需求一致，但如果你打开特征树看到一堆没有逻辑的乱操作，改一个尺寸就会导致整个模型崩塌，那这个生成结果就是不可用的。

6.3 短期能落地的场景在哪里

以目前的成熟度，我判断 text-to-cad 短期内最有可能落地的是三个场景：

第一个是需求评审和方案比选阶段，设计人员根据口头描述快速生成多个候选草模，用来讨论和筛选方向，成本低、速度快，对精度要求不高。

第二个是标准件库的智能检索与匹配，用户描述一个零件的功能需求，系统返回合适的标准件模型。

第三个是教育和培训场景，学生通过自然语言描述来理解建模思路，看到一句话如何一步步变成特征树，这对理解 CAD 建模逻辑很有帮助。

至于直接对着最终加工件做生产级建模，目前还不行，但每年都在进步。

7. 写在最后的实操心得

text-to-cad 我前前后后折腾了不短的时间，最深的体会是：这个方向的门槛不在“会用模型”，而在“理解 CAD 数据本身的逻辑”。模型输出的是一个操作序列，但这个序列必须符合几何内核的规则，必须满足工程语义的预期，必须能被人后续修改。这三层要求叠加在一起，难度远超一般的文本生成任务。

如果让我给刚接触的人一个建议，那就是不要一上来就追求端到端生成最终零件。先从最简单的方案入手：用大语言模型生成 FreeCAD 脚本，跑通一个“矩形底板 + 四个安装孔”的流程，把环境、格式流转、参数检查这些基本功练熟，再逐步往上叠加复杂度。这个过程本身就是对 CAD 数据逻辑最好的学习。

对我个人来说，text-to-cad 最迷人的地方在于它让“模糊的想法”和“精确的模型”之间第一次有了一个自动化的桥梁。虽然这个桥梁目前还有点晃，但方向已经非常明确了。后面如果有机会，我会接着分享从文本直接生成装配体和带公差标注模型的实践，那又是一个全新的坑。