企业官网建设流程全解析

text-to-cad 是最近 CAD 圈子里讨论得最凶的方向之一。说白了，就是输入一句类似“一个直径30mm、高50mm的圆柱，顶部掏一个直径10mm的通孔”的自然语言，系统直接给你吐出一个能下到 SolidWorks 里继续改的可编辑模型。这个方向看起来像“AI 画画”，但真正做过的人会告诉你，它比文生图难得多——因为 CAD 模型不是像素，它必须满足几何约束、拓扑闭合、可制造性，还得保留完整的特征历史。

这篇文章我想基于自己跑通 text-to-cad 全流程的经验，把这个方向从原理到落地拆开讲一遍。不搞玄学，只讲实际操作：为什么业界普遍选 CSG 或特征树做中间表示，训练数据到底怎么洗，LLM 抽参数和程序化建模怎么配合，以及我在实操中踩过的坑。适合机械工程师、3D 打印玩家、CAD 二次开发人员，以及那些想给公司内部做“文字建模型”工具的 LLM 应用工程师。

1. 整体设计思路：text-to-cad 到底在解决什么

1.1 传统建模的痛点与 AI 化机会

先聊一个最基础的问题：传统 CAD 建模为什么难？不是因为画线难，而是因为“想清楚怎么画”难。一个稍微正规一点的机械零件，建模步骤往往是先建基准面、画草图、加约束、拉伸、再倒角、再打孔、阵列……步骤一多，特征树就成了一棵逻辑树，哪个特征依赖哪个面、哪个尺寸由哪个公式驱动，全都要工程师在脑子里维护。

text-to-cad 想做的，是把这棵逻辑树从“工程师脑子里”搬到“自然语言里”。用户只需要说出最终要什么，系统负责把这棵特征树生成出来。这个思路本身并不新鲜，CAD 行业早就有一堆“宏录制 + 参数修改”的玩法，真正的新变量是大语言模型把自然语言到结构化参数的映射能力做到了可用程度。

所以我把 text-to-cad 理解成三个子问题：第一，怎么从文本里准确抽取出几何参数；第二，用什么中间格式表示一个可编辑的 CAD 模型；第三，怎么保证生成结果在几何上是合法、可继续编辑的。三个问题缺一个，系统就是玩具。

1.2 三条技术路线的选择与对比

我拆过市面上主流的几类实现方案，大致归成三条路线。第一类是 DeepCAD 那套做法，用 Seq2Seq 模型直接输出 CSG 操作序列，本质是让模型学会“画图的步骤”；第二类是最近很多工具在用的 LLM + 参数化 API 路线，先让大模型把文字抽成结构化 JSON，再交给 CadQuery、OpenSCAD 这类程序化建模库去执行；第三类是用 3D 扩散模型或者 NeRF 先出体素、点云，再逆向成 CAD 曲面。

三条路线的差异非常明显。CSG 序列适合训练，因为操作序列天然就是 token 序列，借鉴 NLP 那套训练方法很顺，但生成出来的模型往往是一坨“能看不能用”的布尔结果，特征树语义不明显，回到传统 CAD 里很难再编辑。LLM + API 路线可控性最强，参数、约束、命名全在掌握里，缺点是上限取决于 API 能表达的特征类型，复杂曲面基本没戏。扩散模型路线生成的几何自由度高，但转成 B-rep 特征树这一步目前没有稳定解法，工业落地还早。

我自己的判断是：短期内真正能落到生产环境的，必然是第二条路线。原因很简单——工程师要的不是“一个像螺栓的网格”，而是“一个我还能改直径的螺栓特征树”。这条路线虽然听起来没有端到端模型炫酷，但它把不擅长的部分（几何生成）交给经过验证的程序化方法，把擅长的部分（语义理解、参数抽取）交给 LLM，分工合理。

1.3 为什么“可编辑性”是 text-to-cad 的核心指标

我见过很多 demo 都犯一个毛病：只展示了“输入一句话，输出一个模型”，但那个模型是看着像，让你点开特征树就露馅——全是布尔合并，没有特征名称，没有草图约束。这种模型拿去做 3D 打印可能够用，但拿去出工程图、做有限元、上 CAM 加工，基本废了。

真正的 CAD 工作流要求模型必须能回溯：你要把孔直径从 10mm 改成 12mm，不能让工程师从头再画一遍。这意味着 text-to-cad 的输出必须携带完整的建模过程，而不是最终几何。CSG 树和 B-rep 特征树都能携带这个过程，但特征树更接近工业标准，因为它对应的是拉伸、旋转、倒角这些真实 CAD 特征，而不是抽象几何布尔运算。

这个认知会影响整个系统设计。如果你认准了“可编辑”是核心，那么你在做中间表示、训练数据、模型评估时，都会优先考虑特征语义完整性，而不是几何相似度。你评估一个生成结果好不好，不应该只看 IoU 或者 Chamfer Distance，而应该看特征树回放是否成功、参数覆盖率有多高。

2. 核心技术拆解：文本到模型的关键环节

2.1 文本理解：尺寸抽取是第一个拦路虎

很多刚接触 text-to-cad 的人以为最难的是几何生成，实际跑起来才发现，文本理解这块的坑一点不少。自然语言里描述尺寸的方式五花八门：“直径30”、“外径30内径20”、“厚5个毫米”、“比前面那个粗一点”、“螺栓孔距中心40”。前几种是绝对尺寸，模型抽起来相对容易，后面两种是相对关系，需要结合上下文才能确定。

我自己的做法是给 LLM 设计一套严格的输出 Schema，要求它把文本里的信息拆成主题、尺寸、相对约束三个字段。比如“一个直径30mm、高50mm的圆柱，顶部带一个直径10mm的通孔”，模型要输出一个 JSON，里面包括主体尺寸、孔的位置（顶部中心）、孔轴线方向（与圆柱同轴）。这中间最关键的坑是单位——LLM 容易“自由发挥”，你让它输出尺寸数值，它可能不按文本单位走，直接给你输出英制或者无单位数。

所以我在 prompt 里显式加了规则：所有尺寸统一转成毫米，且必须落在合理区间内。比如小于 0.1mm 或大于 1000mm 的尺寸一律标记为异常，交给后续校验模块处理。另外一个技巧是让模型输出“尺寸来源”，也就是把原句里的尺寸文本一起带出来，方便出问题时排查是哪一步抽取错了。

2.2 中间表示：为什么大家都选 CSG 和特征树

中间表示是整个 text-to-cad 系统的命门。拿 CSG（构造实体几何）来说，它的核心思想是用布尔运算把简单几何体组合成复杂形状，比如“圆柱 A 和方块 B 合并，再减去圆柱 C”。CSG 的好处是表达极其简洁，一个模型就是一个表达式树，序列化之后就是 token 序列，非常适合用语言模型来生成。

DeepCAD 数据集就是这么干的。他们把模型转成 CSG 操作序列，每个操作是一个 token，整棵树拍平成一个句子，然后用类似机器翻译的模型去训练。这个思路的优点是把三维几何生成变成了文本生成，训练框架完全是现成的 NLP 框架，缺点也很明显：模型倾向于生成“几何好看但参数不可解释”的序列，而且 CSG 表达范围和真实 CAD 特征之间存在鸿沟。

更贴近工程的是 B-rep 特征树，也就是真实 CAD 软件里的特征历史。特征树的节点是拉伸、旋转、倒角、阵列这些语义化特征，每条边上带参数和引用关系。用特征树做中间表示，下游可编辑性最好，但表示复杂度明显上升，训练序列也长得多。目前工业界的折中方案是：用 LLM 做高层规划——决定先生哪个基体、再挖哪个孔、最后怎么倒角，然后把具体参数填入模板特征树。这样既保住了灵活性，又把“特征级合法性”交给代码去保证。

2.3 训练数据准备：干净比多更重要

很多做 text-to-cad 的团队一开始都卡在数据上。市面上可用的公开数据集，主流是 DeepCAD 的 10 万级模型、Fusion 360 Gallery 的带特征历史模型、以及 ABC 数据集。但直接用原始数据训练，效果会非常糟糕。原因是我踩过的坑：数据里混了一堆退化模型——零体积实体、缝隙重叠、法向翻转、布尔失败的残留面片。

数据清洗至少要过三关。第一关是几何合法性检查，用 OCCT 或者 CadQuery 的检查函数把模型重新生成一遍，凡是失败的直接删掉；第二关是参数合理性检查，尺寸太小、太大、比例过于夸张的模型对训练没有帮助，反而会教坏模型；第三关是相似去重，不然模型会死记训练集里的“标准零件”，泛化能力极差。

数据增强也有讲究。三维模型可以旋转、平移、缩放，但不能随便镜像——镜像会改变螺纹旋向、孔位左手右手规则，很多机械零件是对称敏感型的。我自己实测下来，最有效的数据增强不是几何变换，而是“描述增强”：同一个模型，写 5 种不同的文字描述，让模型学会处理同义表达，这个对 text-to-cad 语义理解能力的提升比几何变换明显得多。

2.4 几何验证：生成完必须过一遍合法性检查

我见过不少人训练完模型直接输出结果，不做任何几何校验，然后对着 3D 预览夸效果。这是大忌。CAD 模型不像图片，像素多点少点没关系，几何模型一旦有破面、反转法向、非流形边，后续任何一步——切片、网格、出工程图——都会崩给你看。

所以我在系统里固定加了一个几何验证网关，所有生成的模型在交付前必须通过三项检查：体量检查（模型必须是闭合实体，体积大于阈值）、边界检查（所有面是流形边界的子集，无非流形边）、布尔合法性检查（如果结果里有布尔操作，必须保证操作对象有正确的相交/相离关系）。这些检查用 CadQuery 的is_valid()或者 OCCT 底层 API 都能做，不需要自己造轮子。

3. 实操过程：5 分钟搭一个能跑的简化版 text-to-cad

3.1 技术选型与系统骨架

如果你也想自己搭一个简化版，我建议不要一上来就训练模型，先做一个“LLM + CadQuery”的压缩版闭环，把整个流程跑通，再谈优化。技术栈我选的是 Python + CadQuery + 任意一个支持 function calling 的 LLM API。CadQuery 是 OpenCASCADE 的 Python 封装，能创建带特征树语义的 STEP 文件，完全符合我们前面说的“可编辑性”原则。

系统骨架一共四层：输入层接自然语言文本，解析层用 LLM 把文本转成结构化 JSON，执行层用 CadQuery 按 JSON 参数建模，校验层做几何合法性检查。这个架构看起来很朴素，但跑通以后，你想把中间某层换成模型生成的 CSG 序列甚至扩散模型，都不用动其他层。

3.2 LLM Prompt 模板与参数抽取

解析层是整个链路里最需要调的部分。我试过直接让 LLM 输出 CadQuery 代码，效果很差——模型会生成不存在的 API 参数、忘记单位转换、偶尔自己加一些“设计意图”。后来改成让模型先输出 JSON 再程序化执行，稳定性上来了一个量级。

我的 prompt 里会包含四件事：任务说明（把描述转成建模参数）、输出 Schema（用 JSON Schema 严格定义字段）、约束规则（单位统一、尺寸范围、布尔操作的对象关系）、示例（few-shot 给 2~3 个典型例子）。示例尤其重要，我用过没有示例的版本，模型经常把“顶部带孔”理解成“侧面带孔”，给一个示例后这类错误基本消失。

3.3 CadQuery 执行与 STEP 导出

拿到结构化 JSON 之后，执行层就是一个累加过程。我们以“直径 30mm、高 50mm 的圆柱，顶部带一个直径 10mm 通孔”为例，CadQuery 代码非常直观。先建圆柱基体，再在顶面中心打垂直通孔，最后导出 STEP 给下游工具用。这个过程不需要任何“生成式模型”参与，参数是对的，结果天然合法。

整个链路跑起来以后，我发现实测效果最不稳定的环节反而不是建模，而是 LLM 输出的 JSON 偶尔带额外字段、嵌套层级对不上 Schema。后来我加了个兜底：用 JSON Schema 校验器先验一遍，不合格就带着校验错误返回给 LLM 让它重新生成，实测成功率明显提升。

3.4 从单个零件到简单装配体的扩充

跑通单个零件之后，很自然会想支持装配体。这个坑我建议你谨慎踩：单个零件里，各个特征共享同一个坐标系，位置关系天然一致；装配体里每个零件有自己的坐标系，LLM 必须正确处理“在另一个零件侧面打孔”这种跨零件引用，参数抽取复杂度直接翻倍。

我的经验是先做“零件库 + 放置规则”方案，而不是让模型直接生成装配结构。预先建模一批标准件（板、轴、座、法兰），让模型抽取“放哪个、放哪、怎么对齐”的规则，再用代码完成装配约束。这样做的好处是生成结果稳定可控，坏处是表达范围有限，但作为工具完全够用。

4. 常见问题与排查技巧实录

4.1 几何生成类问题

布尔运算失败是我遇到最多的一个问题，典型场景是“圆柱和方块相交，想挖出圆孔”结果报错。原因是两个体只是表面相切或者相交深度为 0，OCCT 在这种边界条件下布尔运算经常不稳定。解决办法是在关键相交区域加 0.01mm 的余量，让布尔操作对象有明确实体内核。这个技巧一开始看起来不优雅，但在工程里非常常用。

离散步长也是常见问题。CadQuery 默认的圆面离散精度比较低，导出 STEP 后转到 SolidWorks 里看圆都不够圆。这不是错误，是把 CAM 和仿真前要先处理一下。我一般会统一设置分段数参数，保证所有圆弧面在 1mm 弧长下有至少 32 段拟合，这样后续加工不会出问题。

4.2 LLM 抽取类问题

尺寸混淆和幻觉是 LLM 的通病，尤其当文本里含有“大约”“左右”这类模糊词时，模型会把“50 左右”直接输出成 50，丢了不确定性。我后来在 Schema 里加了一个tolerance字段，要求模型对模糊尺寸显式输出公差范围，没有歧义的输出 0，后续建出来的模型质量好很多。

另外发现一个规律：LLM 在长描述里倾向于“过度设计”。用户只说“一个带孔的板”，模型会自作主张开 4 个孔、加倒角、加螺纹。我加了一条 prompt 规则——只生成文本里明确提到的特征，未提及的默认不添加。加了这条之后，用户预期管理和模型可控性都好了不少，这也是我强烈建议你加的一条规则。

4.3 数据与验证类问题

如果你走到训练模型那一步，还有一个隐藏坑：训练序列长度。CSG 展开后的 token 序列动辄几百上千个，普通 seq2seq 模型在这个长度上效果衰减严重，而且训练时间猛增。我当时的做法是把模型按“基体生成”和“特征添加”两段处理，先预测先做什么，再逐步添加后续特征，把长序列切成短序列，效果和数据效率都更好。

几何校验阶段的另一个经验是：不要相信模型自己输出的“valid=True”字段。模型永远不知道自己几何上是不是对的，它只是从分布里采样了一个序列。所有合法性判断必须交给独立几何内核去验证，这是我踩过几次坑之后得到的硬教训。

4.4 一些提效小技巧

最后分享几个让我效率提升明显的小技巧。第一，给 LLM 喂 2~3 个同类型零件示例作为 few-shot，比单独调 prompt 有用得多，如果你有“历史上建过的零件是对的”这种数据，一定用起来。第二，CAD 参数 Schema 要和工程规范绑定，螺纹、孔位、倒角尽量引用标准件库，防止模型输出一个“非标螺纹规格”让你没法加工。第三，生成结果不要直接覆盖源文件，我习惯把所有模型导出成带元数据的 STEP 文件，原始文本和参数 JSON 作为用户属性嵌入进去，以后追溯问题时非常方便。

text-to-cad 这个方向，现在远没到成熟期，但它的路子已经很清楚——把语义理解交给大模型，把几何生成交给程序化内核，把合法性校验交给几何引擎，各干各的脏活。按照这条路走下来，哪怕是个简化版本，也已经可以实打实地帮人省时间；拿它去替代传统建模工作流还早，但作为草稿生成器，它已经够好用了。