企业官网建设流程全解析

说实话，我第一次听说 text-to-cad 这个概念时，第一反应是：这怕不是又一个营销噱头。CAD 建模这么多年都是靠鼠标键盘一点点怼出来的，你跟我说输入一句"生成一个带四个安装孔的法兰盘"，模型就出来了？但后来自己动手试了几轮，发现这事确实不是概念炒作——虽然离"设计师下岗"还差得远，但它正在实打实地改变一些重复性建模工作的效率。

这篇文章我会尽量讲清楚三件事：text-to-cad 到底卡在哪些核心难点上、目前主流方案分别是什么、以及我自己实测下来一套可以照抄的最小复现流程。适合正在评估该不该在团队里引入 AI 辅助建模的工程师、做设计工具的产品经理，以及单纯想折腾一下的 CAD 玩家。

1. 设计师说一句话，CAD 就得给模型：text-to-cad 到底在解决什么问题

1.1 一个真实的痛点：建模时间被基础操作吃掉了

做过机械设计或者产品结构设计的朋友应该都有体会：真正花在"思考怎么设计"上的时间，其实远没有"把设计落实成模型"的时间多。比如一个典型的钣金支架，里面有底板、翻边、加强筋、安装孔、圆角，如果你熟练，可能二十分钟能建完，但这二十分钟里有十五分钟是在重复一些机械劳动——画草图、加约束、拉伸、打孔、倒角。

这些操作本身没有多少智力含量，但你又不能不做。更烦的是，方案评审阶段改了又改：支架长度从 80 改到 100，孔位从四个变六个，加强筋从一道变两道。每一次改动，你都得在特征树上找对应的步骤，重新编辑参数，再等模型重建。这套流程我做了十多年，熟练归熟练，但越来越觉得它消耗的是耐心和精力，而不是创造力。

text-to-cad 想解决的，正是这块"低价值高耗时"的部分。理想状态下，你只要把设计意图用自然语言描述清楚，比如"100 毫米长的 U 型槽钢，两端各有两个直径 8 的安装孔，槽内焊一块加强筋"，工具就能给你输出一个可编辑的参数化模型，甚至把特征树都替你建好。你拿到手的是"半成品模型"，而不是一张渲染图片，后面的细化、调整、装配验证仍然由你掌控。

1.2 text-to-cad 不是什么，先划清边界

很多人一听"文本生成 CAD"，下意识以为它是"文字转图片"的升级版——你说一句话，AI 给你出一张看起来像样的产品图。这个理解从一开始就跑偏了，而且会严重影响你对工具的评价。

text-to-cad 不是文本转图像，它转出来的是一个真正的、可以进 CAM 编程、可以做有限元分析、可以在装配体里跟其他零件配合的几何实体。它也不是自动出工程图，图纸上的尺寸标注、公差、表面粗糙度这些东西，目前没有任何 AI 能可靠地帮你完成。它更不是"以后不用学 CAD 了"的通行证——恰恰相反，你需要更懂 CAD，才能判断 AI 生成的东西到底能不能用。

我更愿意把 text-to-cad 理解为一种"设计意图翻译器"：把模糊的自然语言，翻译成 CAD 内核能够理解的精确几何操作序列。翻译质量好不好，决定了你能不能直接在翻译结果基础上继续工作。

2. 为什么这事比 AI 画图难十倍：几何精度与约束的本质差异

2.1 CAD 的 DNA：边界表示、特征树与参数约束

要理解 text-to-cad 的难度，首先得理解 CAD 模型和图像的根本区别。一张 AI 生成的图片，本质是像素矩阵，你放大看就是一个个色块，它没有"拓扑"的概念。而一个 CAD 模型，从底层看是边界表示（B-rep），也就是用面、边、顶点以及它们之间的连接关系来精确描述实体表面。这个描述是数学级别的严谨：两个面是相交还是相切、一条边是直线还是样条曲线，都有明确定义。

更关键的是，现代 CAD 软件里模型不只是几何，还有特征树。你回头看一个 SolidWorks 或 Fusion 360 文件，能看到"拉伸 1""阵列 2""倒圆角 3"这一串操作历史。这棵树本身就是设计意图的载体——改一个草图的尺寸，后面的特征自动重建；删掉某个特征，整个模型的拓扑都会跟着变。

text-to-cad 如果只生成"一个长得差不多的几何体"，那是不够的。它得生成一棵可以被后续编辑的特征树，每个特征的参数要合理、依赖关系要清楚。这就不是简单的模式识别问题了，而是让大模型理解一个"带状态的操作序列"。

2.2 差 0.1mm 就装不上：天然不容错的输出

AI 绘画领域有一个很微妙的宽容度：Stable Diffusion 画的人手五根手指偶尔变六根，大家笑一笑就过去了；Midjourney 生成的建筑窗户数量不对，也没几个人较真。但 CAD 没有这个运气。一个安装孔的位置偏了 0.5mm，螺栓就可能穿不过去；一个配合面的公差没给对，装配体里就出现干涉；一个钣金折弯半径算错，加工出来直接裂。

这意味着 text-to-cad 的输出容错率极低。我可以接受生成结果里有圆角漏倒、小众特征缺失这类小瑕疵，但我不能接受尺寸整体错乱。而偏偏，尺寸是自然语言里最难精确传达的部分——人说话的时候天然会省略信息，我说"一个大的底板"，鬼知道你心里想的"大"是 200mm 还是 500mm。

2.3 创意模糊与工程精确的拉扯

这里有个本质矛盾：自然语言是连续、模糊、有语境的，而 CAD 是离散、精确、无歧义的。打个比方，你跟朋友说"晚上一起吃饭"，对方能理解你的意图可能是"下午六点半，楼下那家川菜馆"，但如果你让一个 CAD 程序去执行这句话，它连"吃饭"对应的几何原语是什么都不知道。

text-to-cad 要做的，就是在模糊和精确之间架一座桥。有些团队选择让用户不断补充约束——对话式生成，说一句不够就追问；有些团队选择用模板限定范围——只针对某个零件族做生成，把自由度锁死。无论哪条路，本质都是把模糊的意图逐步收窄成精确的指令。这个过程做得好不好，直接决定了一个 text-to-cad 工具是"能用"还是"噱头"。

3. 四条技术路线对比：从代码生成到扩散模型，谁在真正落地

3.1 路线一：让大模型写参数化脚本（CadQuery、OpenSCAD 路线）

这个路线理解起来最直观：既然 CAD 模型可以用代码描述，那让大语言模型直接写这段代码不就行了？OpenSCAD 本身就是编程式建模，CadQuery 是 Python 库，FreeCAD 也支持 Python 脚本。这些工具的共同点是：一切几何操作都对应一段明确的代码和参数。

大模型写代码的能力已经有目共睹，所以这条路线的前期投入最小，我一个人半天就能搭出闭环：调用一个 GPT 类接口 → 提示它生成 CadQuery 脚本 → 本地执行脚本 → 用 CQ-editor 或 FreeCAD 查看结果。

这条路线的优点是：输出天然是参数化、可编辑的——脚本本身就是特征树；只要代码能跑，几何就是精确的，不存在"看起来差不多"。缺点是：大模型在复杂逻辑面前容易翻车，特征多了代码就出现变量作用域错误、布尔运算顺序错误；而且它需要使用者懂一点代码，对纯鼠标党不友好。

3.2 路线二：LLM 编排建模原生 API（Autodesk Zoo、Fusion 这类）

这是大厂更认可的路线。Autodesk 研究实验室一直在推进的项目（对外叫 Zoo，前身是 Project Bernini），思路不是让 LLM 生成脚本字符串，而是让它调用 CAD 内核提供的建模 API。每个 API 是一组封装好的操作：新建草图、加约束、拉伸、打孔、阵列。LLM 的任务是规划这些 API 的调用顺序和参数，相当于让一个懂 CAD 的实习生替你操作软件。

这条路线高质量、原生，输出的是真正基于内核的模型，后续编辑和团队协作都没有障碍。但问题也很现实：API 生态掌握在厂商手里，你很难绕过商业软件单独使用；而且当前阶段它对网络和云端服务的依赖很强，格式和兼容性都是隐患。

3.3 路线三：端到端深度生成（Text2CAD 论文、B-rep 生成方向）

这条路线最科幻。学术圈已经在做完全不依赖 CAD 内核的端到端方案：你输入一句话，模型直接输出一个 B-rep 表示的几何体。比较有代表性的是 2024 年前后的 Text2CAD 系列工作，以及用扩散模型生成 B-rep 结构的 BrepGen 这类研究。原理上，它们是把 B-rep 结构离散化成序列或者图，然后训练模型学习"文本 → 几何结构"的映射。

我个人的评价是：很惊艳，但离工程可用还有明显距离。学术 demo 里生成的模型，大多是简单几何体或者小型机械零件；一旦涉及多特征、精细圆角、装配关系的复杂模型，生成结果的拓扑正确性和参数可编辑性都撑不住。而且，它生成的是"结果几何"而不是"建模过程"，没有特征树，工业上几乎无法使用。

3.4 路线四：检索-改造组合方案

这是最容易被忽略但实际最靠谱的一条路。它的思路很简单：先通过语义检索在模型库里找到最接近的现有模型，然后让 LLM 按新需求去修改参数和特征。比如你描述"需要一根 600mm 长的 4040 铝型材"，系统先定位到标准铝型材模型，再调整长度和安装孔位置。

优点是精度高、速度快、可靠性强，因为底子是人工验证过的模型，AI 只做局部修改。缺点是适用范围窄——检索库里没有的东西它就无能为力了。但对于标准件、常用零件族、企业历史模型复用这些场景，这个方案是当前性价比最高的。

3.5 一张表看明白四条路线的取舍

如果让我给一个直观的结论：要真想在生产里用起来，第一条路和第四条路最容易落地；第二条路值得盯着，厂商一旦开放成熟，体验会很强；第三条路适合看热闹和跟踪学术进展，短期内别指望它干活。

4. 一套最小可复现的 text-to-cad 流程（附 prompt 与后处理）

4.1 选型思路：为什么我推荐从 CadQuery 入手

如果你想不花一分钱、用一下午时间就体验完整的 text-to-cad 流程，我强烈建议选 CadQuery，理由有三。

第一，它是 Python 生态，大模型对 Python 的掌握程度远高于 OpenSCAD 的专用语言，生成结果的正确率明显更高。第二，CadQuery 的建模逻辑是"在平面上画草图 → 拉伸/切除 → 选面继续操作"，这个思路和主流 CAD 软件一致，AI 生成的代码你能看懂、能改。第三，它可以一键导出 STEP 格式，STEP 是几乎所有主流 CAD 工具都认的中性格式，后续导入 SolidWorks、FreeCAD、Fusion 都没有障碍。

4.2 把自然语言翻译成"特征操作序列"

很多人用 text-to-cad 翻车，不是因为 AI 不行，而是因为输入太偷懒。你把一句"给我做个支架"扔给模型，它只能回你一句"请提供更多细节"。正确做法是：先在脑子里把模型拆解成特征操作序列，然后用自然语言把关键约束喂给模型。

比如做一个"带四孔底板和一块立板的 L 型支架"，我会按下面的顺序描述：底板的平面是基准 → 底板长宽厚 → 立板从哪里长出、方向是哪个轴 → 立板的宽高厚 → 安装孔直径和位置 → 圆角半径。这个顺序其实就是特征树建立的顺序，模型理解了顺序，生成的脚本逻辑会清晰很多。

4.3 一个可直接抄的 prompt 模板

我自己的 prompt 模板经过好几轮调整，核心是：角色设定、目标描述、约束显式化、单位声明、输出要求。下面这个版本可以直接拿去用（我这里以 CadQuery 为例）：

你是一个 CadQuery 建模专家。请根据下面的需求生成可直接运行的 Python 代码： 1. 模型目标：一个 L 型支架。 2. 底板尺寸：长 80mm、宽 60mm、厚 10mm，底板以 XY 平面为基准。 3. 立板尺寸：高 80mm、宽 60mm、厚 10mm，立板立在底板长边（Y方向=60mm）的上方，垂直于底板。 4. 立板与底板相交处，在立板背面加一块三角形加强筋，筋板厚 5mm。 5. 底板四角各有一个直径 6mm 的通孔，孔心距底板相邻边缘 10mm。 6. 所有圆角统一为 R3（底板立板相交外棱除外）。 7. 所有尺寸单位是毫米。不要省略任何特征。不要使用未定义的变量。输出完整代码。

这里有两个容易被忽略的细节：一是"以 XY 平面为基准"这种话，相当于画草图时选了基准面，能避免 AI 把立板方向搞反；二是"不要省略任何特征"这句很关键，因为模型经常偷懒，会把加强筋或者孔位忘掉。

4.4 生成、渲染、导出的完整闭环

生成完代码后，我一般走三步验证。第一步，把代码放到本地 Python 环境跑一遍（用到 cadquery 库），能跑通不代表对，但起码排除语法错误。第二步，用 CadQuery 自带的 CQ-editor 查看模型方向、孔位、厚度是否合理。第三步，用 cq.exporters.export 导出 STEP 文件，再导入 FreeCAD 做一次装配级检查。

下面是一段经过验证的 CadQuery 代码，对应的就是上面 prompt 描述的 L 型支架（简化版，重点看结构）：

import cadquery as cq # 底板：80x60x10 base = ( cq.Workplane("XY") .box(80, 60, 10) .edges("|Z") .fillet(3) ) # 立板：80x60x10，立在底板长边，高度沿 +Z plate = ( cq.Workplane("XZ") .center(0, 35) .box(80, 80, 10) .translate((0, -30, 35)) ) # 合并 result = base.union(plate) # 底板四角打孔（孔径6，距边10） result = ( result.faces(">Z") .workplane() .rect(60, 40, forConstruction=True) .vertices() .hole(6) ) # 导出 STEP cq.exporters.export(result, "l_bracket.step")

这段代码在我的环境里跑通了，但要注意：AI 生成的代码每次可能略有不同，我给你的作用是让你对"输出长什么样"心里有数。实际用的时候，拿 prompt 去让模型生成，再按上面三步走闭环就行。

5. 实测踩坑清单：尺寸幻觉、单位错乱与特征树丢失

5.1 尺寸幻觉：说的 50mm 变成 50cm

这是我最常踩的坑。你明明在 prompt 里写"长度 50mm"，模型生成的代码里很可能变成box(50, 20, 5)，但如果你不留意单位注释，或者模型内部换算时把 5cm 当成默认值，输出模型的尺寸就完全不对了。更隐蔽的是，有些模型会"自作聪明"地把 50 理解成 50.0，但坐标系单位默认是米——CadQuery 默认用毫米？不一定，和内核设置有关。

我的经验是：在 prompt 里重复强调"单位是毫米"，同时在后处理时第一件事就是测量模型包围盒尺寸。如果包围盒和预期差了一个数量级，基本就是单位串了。

5.2 公制和英制的混战

有次我让模型生成一个 1/4-20 螺纹孔座，它倒是生了，但旁边的底板尺寸全变成了 0.125、0.5 这类英寸写法。我 Prompt 里确实没说清楚"螺纹部分可以英制，其他部分保持公制"，这怪我。更麻烦的是，模型生成的代码里如果混用了英制值，你很难一眼看出来，特别是那些不常见的 0.07874 这种英寸换算成毫米的怪数。

我现在的做法是：涉及任何英制标准件（UNC、UNF 螺纹、英寸管径），在 prompt 里单独列一节"仅螺纹孔使用英制，几何体一律公制"，然后生成后逐个核对关键尺寸。

5.3 语法对语义错：脚本能跑，几何完全不对

这是最坑的一类问题：代码没有任何语法错误，CadQuery 完美执行，但生成结果跟你的需求八竿子打不着。典型例子是：拉伸方向反了、阵列实例数少了一个、本意是切除结果用了 union、加强筋位置偏移了半个身位。脚本不报错，意味着所有自动化检查都失效，只能靠人眼。

我的解决办法有两个。第一，在 prompt 里明确要求"每一步操作必须注释说明你在做什么，注释里写清楚方向和坐标"。第二，在本地快速渲染多个视角（等轴测、前视、右视）逐一对照。这一步不能省，别以为代码能跑就完事了。

5.4 特征树丢失：一次性几何 vs 可编辑模型

有类终南捷径式的方案会直接把几何转成 mesh 或者直接生成 B-rep，模型是能做出来，但你拿到的是一坨"死几何"——没有特征树，没有参数，想在 SolidWorks 里改一个孔位，得整个模型当作导入实体重新建模。这在纯 3D 打印场景下问题不大，但一旦涉及后续修改和装配，就非常痛苦。

所以我在选技术路线时，一直坚持"代码生成"优先，原因就在这里：脚本就是特征树，改一个数字重新跑一遍，就是改参数重建模型。你让扩散模型画个凳子还行，让它生成"可编辑的柴油机缸盖"，它连特征树的边都摸不到。

5.5 我的三层校验习惯

踩了无数次坑以后，我养成了一个固定习惯，每次拿到 text-to-cad 输出，按三层来校验：

• 第一层：脚本能跑，无语法错误，导出不失败。
• 第二层：模型尺寸与 prompt 里的关键数值逐一核对，特别是毫米、英寸换算、孔距、壁厚。
• 第三层：把人眼检查作为最后防线，看方向、看拓扑、看特征是否完整。

这三层做完，我才敢把模型往装配体里放。我承认这不轻松，但在当前阶段，"人机协同校验"就是 text-to-cad 落地成本的一部分。

6. 什么场景该用它，什么场景别硬上

6.1 值得投入的场景：方案比选、标准件变体、3D 打印快速验证

我自己最常用的场景有三个。一是方案比选阶段：甲方说"给我看几个不同比例的外壳造型"，我可以让 AI 出五个变体，我来选那个最顺眼的，再手工细化细节。二是标准件变体：同样的传感器支架，宽度从 80 改成 100、120，孔距跟随变化，这类参数化变体用 text-to-cad 生成得飞快。三是 3D 打印前的快速验证：不需要高精度的概念模型，打出来看个手感、比划一下空间关系，AI 生成的模型完全够用。

这三个场景的共同点：低精度要求、低复用要求、快速试错优先。在这些场景里，text-to-cad 的效率优势是碾压式的。

6.2 别硬上的场景：精密配合件、A 级曲面、认证写死的零部件

反过来，有几种场景我劝你别浪费时间。一是精密配合件：轴承位、齿轮啮合、线切割模具，这些零件的公差是按微米算的，AI 现在连"0.05mm 间隙"这种概念都理解不稳，更别提给你把配合算明白。二是 A 级曲面：汽车外饰、消费电子外观面，这些曲面需要严格的曲率连续和光顺性，目前 text-to-cad 生成的曲线质量远达不到要求。三是安全认证件：压力容器、承重结构、医疗植入物，这些零件不仅外形要求高，材料、热处理、应力报告都跟着走，AI 生成的模型哪怕几何没问题，也没人敢负这个责任。

在这些领域硬上 text-to-cad，不是效率问题，是风险问题。真出了事故，AI 不会替你背锅。

6.3 一个务实的定位：text-to-cad 是"创意加速器"，不是"建模替代器"

我逐渐想明白了一个类比：text-to-cad 现在的角色，有点像搜索引擎刚出现时对论文写作的作用。它不会替你写论文，但能帮你快速找到素材、理清思路。同样，text-to-cad 不会替你完成工程设计，但它能把"从想法到第一个可触摸的模型"这个过程从半天压缩到半小时。

真正高效的工作流，应该是让 AI 先出一版"可讨论的模型"，然后由工程师在这个基础上做专业修改和验证。你的设计直觉、工程判断、加工经验，仍然是整个流程里不可替代的一环。我的体会是，用了 text-to-cad 之后，我的工作效率确实变高了——不是我建模变快了，而是我把省下来的时间花在了真正需要动脑子的地方，比如材料选型、结构优化、装配干涉分析。

最后再分享一个小技巧：无论你用的是哪家方案，记得把你验证通过的 prompt 模板和对应代码保存下来。我存了一个"支架类零件""外壳类零件""法兰类零件"的私有模板库，后面再遇到类似需求，直接套模板微调，一分钟就能出模型。这大概就是现阶段 text-to-cad 最靠谱的打开方式——让 AI 干它擅长的初稿生成，把专业判断牢牢握在自己手里。