企业官网建设流程全解析

1. 从一句提示词到三维模型：Text-to-CAD 到底在做什么

第一次看到“文本生成CAD文件”这个说法，我的反应和很多做机械设计的朋友一样——觉得是标题党。毕竟CAD这行当，画一根轴、一个法兰、一套齿轮箱，靠的是尺寸链、公差配合、材料工艺，怎么可能一句话就出来？但把 Text-to-CAD 这类工具真正跑起来、把生成的 B-Rep 实体导进建模软件里量一量、改一改之后，我的判断变了：它不是来抢饭碗的，它是来把“从想法到第一版几何”的那段重复劳动压缩掉的。

先把概念说清楚。Text-to-CAD 指的是用自然语言描述一个零件或结构，由模型直接输出可用的 CAD 文件，通常是STEP、IGES、STL这类通用格式，而不是一张图片或者一段网格。这里的关键词是B-Rep（Boundary Representation，边界表示法）。B-Rep 用面、边、顶点以及它们之间的拓扑关系来描述实体，是绝大多数参数化建模内核（比如 Parasolid、ACIS、OpenCASCADE）的底层数据结构。只有输出 B-Rep，导出的 STEP 才是“真实体”，才能在 SolidWorks、中望CAD、Fusion 这些软件里继续倒角、打孔、做装配约束。如果只输出网格（mesh），那本质上是个雕塑，改一个孔位就得重来。

所以 Text-to-CAD 解决的第一个问题，是几何意图的翻译。设计师脑子里的“一个 80 毫米见方、中心有直径 30 通孔、四角 R5 圆角的安装板”，过去要打开软件、画草图、标注、拉伸、打孔、倒角，五六步操作；现在这句话可以直接变成一个可编辑的实体。第二个问题，是批量变体的生成。做系列化产品时，同一结构改几个尺寸就是新料号，这种活儿人做起来枯燥且容易错，交给文本驱动反而稳定。

它适合谁？我的判断是三类人最该关注：一是做非标自动化、工装夹具的工程师，零件结构重复度高、变体多；二是产品经理和结构新手，需要快速把概念可视化，拿去和工厂对需求；三是做二次开发的人，想在自己的系统里嵌一个“文字出图”的入口。至于高精度、强工艺约束的正式出图，现阶段还是得人来兜底，这个后面会细说。

2. 拆开看：Text-to-CAD 的技术链路与方案选型

2.1 为什么是 B-Rep 而不是网格

很多人第一次接触这类工具，会拿它和文生图对比，觉得“不就是把图片换成3D嘛”。这个类比会误导人。文生图输出的是像素，错了重画一张就行；CAD 输出的是工程语义，一个孔的直径错了，下游的装配、加工、成本全跟着错。这就是为什么必须走 B-Rep 路线。

网格模型（比如 STL）用三角面片逼近曲面，一个圆柱面会被切成几十上百个平面。这种模型能 3D 打印，但没法做精确的尺寸标注，也没法做布尔运算的稳定求交。B-Rep 则保留了“这是一个圆柱面，半径 15，轴线沿 Z”这样的解析信息。Text-to-CAD 工具如果底层用的是 OpenCASCADE 这类开源内核，或者商业内核的 API，它生成的每一步操作（拉伸、旋转、布尔）都是参数化的，导出的 STEP 里带着完整的几何定义。

提示：判断一个 Text-to-CAD 工具靠不靠谱，最直接的办法就是让它生成一个带孔的板，导出 STEP，再导进你的建模软件里测量孔径。如果量出来是 29.98 而不是 30，或者孔变成了多边形，那它大概率走的是网格转实体的路子，精度不可控。

2.2 文本到几何的三种实现路径

目前市面上能见到的方案，底层逻辑大致分三类，理解这三类，你就知道该怎么选工具、怎么提需求。

第一类是代码生成式。模型不直接吐几何，而是生成一段建模脚本，比如 OpenSCAD 的代码、CadQuery 的 Python 代码，或者某个内核的 API 调用序列。你拿到代码，自己跑一遍就得到实体。这种方案的好处是完全可复现、可版本管理，改一个参数重新跑就行，特别适合做参数化系列。缺点是生成的代码偶尔会有语法错误或者逻辑漏洞，需要人看一眼。

第二类是参数序列式。模型输出的是一个结构化的操作序列，比如 JSON 格式的{"op":"extrude","sketch":[...],"distance":10}，由后端解析后调用内核执行。它比代码生成更可控，因为操作类型是预先定义好的，模型只是在填空。适合嵌到自己的系统里做 API 服务。

第三类是直接几何预测式。模型直接预测 B-Rep 的面、边、顶点数据。这类方案最“端到端”，但训练难度大，目前生成复杂结构的稳定性一般，更适合做简单零件的快速原型。

从实际可用性看，我建议优先考虑前两类。原因很简单：可编辑性。代码和参数序列都是人能读懂、能改的，生成的模型不是黑盒。你让模型生成一个支架，它给的代码里尺寸写错了，你改个数字就行，不用重新描述一遍。

2.3 机器学习在其中的角色

这里必须澄清一个常见误解。Text-to-CAD 里的“机器学习”不是让模型去学怎么画图，而是学语言描述和几何结构之间的对应关系。训练数据通常是大量的“文本-代码”对或者“文本-CAD模型”对，模型学的是“当人说‘带法兰的圆管’时，对应的建模操作序列长什么样”。

这跟大语言模型的训练逻辑是一脉相承的。你可以把它理解成一个专门针对 CAD 领域微调过的 LLM，它的输出不是聊天文字，而是结构化的建模指令。所以这类工具的能力边界，很大程度上取决于训练数据覆盖了多少种结构类型。法兰、支架、齿轮、外壳这些常见件它见得多，生成得就稳；冷门的、非标准的异形结构，它就容易胡编。

关键词里提到的API，在这里指的是调用入口。成熟的 Text-to-CAD 服务一般会提供 REST API，你传一段文本，它返回一个文件链接或者几何数据。这就意味着它可以被集成到 PLM 系统、报价系统、甚至电商的定制页面里。比如客户在网页上选“我要一个 200x100 的铝板，四角打孔”，后台调 API 直接出图报价，这个链路是通的。

3. 实操：从零跑通一次文本生成 CAD

3.1 环境准备与工具选择

要自己动手试，有两条路。一条是用现成的在线服务，注册后直接在网页输入框里描述，下载 STEP。另一条是本地部署开源方案，用 Python 调 CadQuery 或者 OpenSCAD，再配一个能生成代码的模型。

本地这条路我推荐用Python + CadQuery的组合。CadQuery 是基于 OpenCASCADE 的 Python 建模库，语法接近自然语言，生成的实体精度高，导出 STEP 干净。模型侧可以用任意一个支持代码生成的大模型 API，把系统提示词设定成“你是一个 CadQuery 专家，根据用户描述输出可运行的 Python 代码”。

环境准备大致是这样：

pip install cadquery pip install requests

CadQuery 的安装在某些系统上需要额外的依赖，如果pip装不上，用 conda 会更省心：

conda install -c conda-forge cadquery

装完之后跑一句import cadquery as cq不报错，环境就算通了。

3.2 提示词怎么写才出得来东西

这是整个流程里最容易被低估的环节。很多人写“给我画一个支架”，然后抱怨生成的东西不能用。问题不在工具，在描述。CAD 是精确的，你的描述也得往精确了靠。

我总结了一个描述模板，实测下来命中率最高：

零件类型 + 整体尺寸 + 关键特征（位置、尺寸）+ 圆角/倒角 + 材料或用途（可选）

举个例子，不要写“画一个安装板”，而要写：

“一个矩形安装板，长 120 毫米，宽 80 毫米，厚 6 毫米。板中心有一个直径 40 毫米的通孔。四个角各有直径 6 毫米的安装孔，孔中心距边缘 10 毫米。所有外角做 R5 圆角。”

这段话里，每个数字都是几何约束，模型不需要猜。生成出来的 CadQuery 代码大概长这样：

import cadquery as cq result = ( cq.Workplane("XY") .rect(120, 80) .extrude(6) .faces(">Z").workplane() .hole(40) .faces(">Z").workplane() .rect(100, 60, forConstruction=True) .vertices() .hole(6) .edges("|Z").fillet(5) ) cq.exporters.export(result, "mounting_plate.step")

这段代码跑完，当前目录下就有一个mounting_plate.step。用建模软件打开，量一下，尺寸对得上。

3.3 参数化变体的批量生成

Text-to-CAD 真正省事的地方在于批量。假设你要做一系列安装板，长度从 100 到 200，每 10 毫米一档。手工建模要改十几次，用代码就是循环。

import cadquery as cq for length in range(100, 210, 10): width = length * 2 / 3 result = ( cq.Workplane("XY") .rect(length, width) .extrude(6) .faces(">Z").workplane() .hole(40) .edges("|Z").fillet(5) ) cq.exporters.export(result, f"plate_{length}.step")

十几行代码，十个 STEP 文件就出来了。这种活儿如果让模型一句一句去生成，反而慢，正确的做法是让模型生成一次模板代码，你自己改参数循环。这也是我一直强调的：把 Text-to-CAD 当成代码生成器，而不是当成画图机器人，思路会顺很多。

3.4 生成结果的验证流程

生成完不能直接用，必须验证。我的验证清单有三步：

1. 尺寸核对：导进建模软件，用测量工具量关键尺寸，尤其是孔径、孔距、壁厚。
2. 拓扑检查：看实体是不是一个完整的闭合体，有没有多余的碎面、自相交。CadQuery 里可以用result.val().isValid()检查。
3. 可制造性初判：有没有薄到无法加工的壁，有没有刀具伸不进去的深腔。这一步机器替不了，得靠人。

注意：模型生成的圆角半径如果大于相邻壁厚的一半，布尔运算可能失败或者产生畸形面。遇到这种情况，先把圆角去掉，生成主体后再手动加。

4. 踩过的坑：常见问题与排查实录

4.1 生成失败与几何无效

最常见的问题是布尔运算失败，报错类似BRep_API: command not done。原因通常是两个特征在边界上刚好相切，或者圆角半径过大导致面退化。排查思路是把复杂操作拆开：先只做拉伸，确认主体没问题，再加孔，最后加圆角。哪一步失败，问题就在哪。

另一个高频问题是孔打在了错误的面。CadQuery 里用.faces(">Z")选面，如果模型有多个朝上的面，它可能选错。解决办法是用.faces(cq.selectors.NearestToPointSelector((x, y, z)))精确定位，或者干脆在草图阶段就把孔的位置画好，一次拉伸带出来。

4.2 尺寸理解偏差

模型对“中心”“边缘”“间距”这些词的理解经常出岔子。你说“孔距边缘 10 毫米”，它可能理解成孔中心到边缘 10，也可能理解成孔边到边缘 10。差的就是一个半径。我的做法是永远用坐标描述：“孔中心位于 (10, 10)”，不给它模糊空间。

还有单位问题。有的模型默认毫米，有的默认米。生成完先看尺寸数量级，如果一块板量出来是 0.12 而不是 120，那就是单位错了，在代码里乘个 1000 或者改导出设置。

4.3 常见问题速查表

4.4 几个只有实操才知道的技巧

第一个技巧：先让模型输出代码，不要直接输出模型。代码你能看、能改、能存版本，模型文件是个二进制黑盒。哪怕工具支持直接下载 STEP，我也建议走代码这条路。

第二个技巧：把常用结构做成模板。法兰、支架、外壳这些，你调好一次提示词，把生成的代码存下来，下次改参数就行，不用重新描述。这比每次跟模型“沟通”高效得多。

第三个技巧：圆角最后加。所有主体特征、孔、槽都做完，确认无误了，再加圆角。因为圆角一旦加上，后续的布尔运算就容易出问题，而且改起来麻烦。

第四个技巧：保留中间版本。批量生成时，每改一次参数就存一个文件，别覆盖。出了问题能回退，也能对比。

5. 这东西的边界在哪，以及怎么用它提效

5.1 它做不了什么

必须说清楚，Text-to-CAD 目前做不了工艺级出图。它给不了公差、粗糙度、形位公差、材料热处理要求。这些信息不在几何里，在工程经验里。你让它生成一个轴，它能给你直径和长度，但给不了配合公差是 H7 还是 g6，也给不了倒角是 0.5x45 还是 1x45。

它也做不了复杂曲面。涡轮叶片、流线型外壳这种自由曲面，文本描述很难精确传达，模型也生成不好。这类活儿还是得靠专业的曲面建模。

还有装配体。目前大多数工具聚焦在单零件生成，多零件的装配约束、干涉检查，还是得人来做。

5.2 真正提效的用法

我的用法是把它当成第一版几何生成器。接到一个新需求，先用文本描述生成一个大概的实体，导进建模软件，在这个基础上改。比起从空白草图开始，改一个已有的实体要快得多，尤其是结构复杂的零件。

另一个用法是做方案对比。同一个功能，三种结构方案，手工建模要画三遍。用文本生成，改几个词就是三个版本，快速评估哪个更合理，再深入细化。

对于做二次开发的人，把 Text-to-CAD 的 API 接进自己的系统，让客户自助生成简单件，后台自动报价，这个链路已经能跑通了。关键词里的“开店分析 API”“拼多多 API”其实指向的就是这类集成场景——把几何生成能力嵌到业务流程里。

5.3 对设计师意味着什么

回到标题那个问题。我的判断是，Text-to-CAD 淘汰的不是设计师，淘汰的是只会重复建模操作的人。当第一版几何可以自动生成，人的价值就转移到更靠前和更靠后的环节：靠前是需求理解和方案设计，靠后是工艺校核和制造对接。

会用这类工具的设计师，效率会明显拉开差距。同样一个非标件，别人还在画草图，你已经生成了三个方案在对比了。这不是危言耸听，是我自己用下来的真实感受。

最后分享一个我常用的提示词结构，直接抄就行：

“生成一个 [零件类型]，整体尺寸 [长x宽x高]。主要特征：[特征1 位置+尺寸]、[特征2 位置+尺寸]。所有 [某类边] 做 [R值] 圆角。输出 CadQuery 代码。”

这个结构覆盖了 80% 的常见零件，剩下的 20% 靠你在代码里补。工具是死的，描述是活的，把几何意图翻译准确，它就能替你干不少活。