企业官网建设流程全解析

text-to-cad 这个方向，简单说就是：用一句自然语言描述，让程序自动生成可以直接导入 CAD 软件的三维模型文件。它不是渲染一张效果图，而是真的给你一个带尺寸、带特征、能继续编辑的实体模型，最常见的形式是 STEP、STL 或者参数化脚本。我最初听到这个概念时觉得挺玄乎，真正跑通一条管线之后发现，它比想象中成熟不少，也比想象中需要更多“把住质量”的手段。这篇文章就把它掰开聊聊：它到底解决了什么问题、主流的技术路线有哪几种、我验证下来最靠谱的一条完整链路长什么样，以及哪些坑你没踩过一定想不到。适合机械设计、3D 打印、产品造型方向的朋友，也适合想把这个能力集成到自己工作流里的开发者和工程师。

1. 项目定位：text-to-cad 到底解决的是哪种需求

1.1 传统“从文本到模型”的路径有多痛

先想想传统流程里，一个零件需求是怎么变成模型的。客户给一句“直径 80 的法兰盘，六个 M8 螺栓孔分布在直径 60 的圆上”，工程师先听明白这句话，再在脑子里换算成几何关系：外圆、中心孔、分度圆、阵列角度。然后打开建模软件，建草图、约束尺寸、拉伸、打孔、倒角，最后还得反复和需求方确认“这个圆角是 5 还是 8”“孔距是圆周均布还是直线分布”。整个过程里，最耗时的往往不是软件操作，而是“把语言翻译成参数”这件事。

text-to-cad 想压缩的正是这段翻译损耗。它把自然语言直接映射到带有明确尺寸的建模指令，让机器替人完成从语义到几何的转换。这里要特别强调“带尺寸”三个字，因为市场上很多文本生成 3D 的方案只能出一个“看起来像那么回事”的网格模型，拿不到加工厂，真正的工程场景需要的是能测量、能标注、能进入制造链路的实体模型。

1.2 先分清三种输出形态再谈精度

在聊技术路线之前，必须先分清 text-to-cad 的输出形态。否则很容易出现“拿着 STL 的评测去质疑 STEP 的精度”这种错位讨论。我一般把输出分成三档：

判断一条 text-to-cad 管线是否可靠，先要看它声明生成的是哪一种。如果目标只是快速验证造型，网格模型完全够用；但如果目标是出加工图、进 CAM 编程，那必须走参数化实体路线。把终点定错了，后面所有选型都会跟着错。

1.3 边界：text-to-cad 不擅长的事情

这个方向有很明确的边界，提前说清楚可以避免期望错位。第一，高度复杂的 A 级曲面，比如车身外板、家电圆润外壳这类对曲面连续性要求极高的形态，目前不是 text-to-cad 的强项，传统参数化曲面建模仍然更可靠。第二，包含公差等级、表面粗糙度、材料牌号、热处理要求等完整制造语义的图纸，现阶段生成能力只能覆盖很小一部分。第三，多零件装配关系、运动约束、焊接符号这类上层工程信息，只能做部分结构化输出，离真正“一句话生成整机”还有明显距离。

我自己的定位是把它当成“快速把语言翻译成可编辑初版模型”的生产力工具，而不是“一句话生成完整产品”的魔法。这个心态调整好了，才不会在第一次遇到翻车时直接放弃。

2. 方案选型：没有银弹，先分清要生成什么

2.1 路线 A：让大模型直接写程序化建模代码

第一条路线是让大语言模型生成程序化建模代码，典型媒介是 CadQuery、OpenSCAD 这类脚本化 CAD 库。原理很直接：这些库本质上是用代码描述参数化特征，而大语言模型最擅长的事情恰恰是生成代码，所以“自然语言到 CAD 脚本”的翻译，比“自然语言直接到几何体”要可控得多。

这条路线最大的优势是结果天然具备参数化能力。脚本里的每一个尺寸都是变量，改一个数字重新执行，新的模型就出来了。代码还可以做版本管理、回归测试、自动化校验，这对工程场景来说非常有价值。缺点是受脚本库的表达能力限制，复杂自由曲面很难用代码描述。你不太可能用 CadQuery 写出一张流线型跑车引擎盖，但做法兰盘、支架、外壳、齿轮这类机械零件绰绰有余。

2.2 路线 B：扩散模型直接生成几何

第二条路线是扩散模型直接生成几何，原理类似于文本生成图像，模型学习海量三维样本后，从文本条件直接输出体素、点云或者隐式距离场，再提取成网格。这条路线在概念设计阶段很好用，因为它对曲面形态没有拘束，可以生成非常自由、非常有想象力的造型。

它的短板在于结果进入制造链路非常困难。网格模型没有特征树，没有参数尺寸，不能改一个孔径就自动更新整个模型。就算在软件里做了一次网格转实体，得到的基本上是“死模型”，后续编辑成本极高。所以这条路线更适合游戏资产、3D 打印预览、产品形态初期探索，而不是机械加工。如果团队的数据积累和算力资源都很充足，可以把它作为前段创意生成器，配合后段人工重建模。

2.3 路线 C：结构化参数驱动 CAD 内核重建

第三条路线是让大模型输出结构化参数，再由本地 CAD 内核程序化重建特征树。具体做法是定义一套中间表示，比如“拉伸体+孔特征+倒角特征+尺寸约束”，大模型只负责从自然语言中抽取枚举值和数值，然后我们把这些参数喂给 CAD 内核，内核按照预设规则重建模型。

这条路线的好处是兼容性最好，输出的结果可以直接进入主流的参数化 CAD 环境，保留特征树，后续修改方式符合工程师习惯。代价是需要自己设计中间语法，并且要严格控制大模型的输出范围，否则很容易生成非法参数。前期工程量比较大，适合团队级玩家。如果只是个人想快速验证 text-to-cad 的能力，我一般建议先从路线 A 入手，原因很朴素：一个晚上就能跑通，试错成本最低。

2.4 我推荐的管线组合

结合我自己的实操经验，最务实的组合是“大模型 + CadQuery + 自动化校验”。大模型负责把自然语言翻译成 CadQuery 代码，CadQuery 负责把代码变成实体模型，自动化校验负责判断实体模型是否合理。这套管线最大的好处是每个环节都可以独立替换：今天用这个模型，明天换更强的模型，CadQuery 部分不用动；想换成其他程序化建模库，只要改一个执行层，校验逻辑完全保留。管线解耦之后，出问题特别容易定位，是提示词的问题、代码执行的问题，还是几何本身的问题，一查就知道。

3. 核心实操：以“文本 → CadQuery 脚本 → STEP 模型”为例

3.1 环境准备：先把 CadQuery 跑通

实操第一步是准备环境。我强烈建议在独立的 Python 虚拟环境里安装 CadQuery，因为它底层依赖一个比较重的几何内核，不同项目之间版本冲突的概率很高，全局安装容易“下次启动项目时突然崩给你看”。安装方式直接走包管理工具即可。

pip install cadquery

装完之后做一次冒烟测试，能成功 import 就算过了：

python -c "import cadquery; print('ok')"

如果这一步就报错，大概率是当前 Python 版本和底层依赖不匹配，换一个受支持的版本再装，比硬着头皮修依赖要快得多。我第一次装的时候图省事用了系统自带 Python，结果编译底层库折腾了快一个小时，后来换到干净环境一分钟解决。

3.2 提示词模板：给 LLM 立规矩

很多人上来就写“帮我生成一个法兰盘”，然后抱怨生成结果不稳定。问题往往不在模型能力，而在提示词没有约束。我实测下来，下面这个模板风格效果很稳：

请生成一个 CadQuery 脚本，用于建模以下零件： 【零件说明】直径 80mm 的法兰盘，厚度 8mm，中心孔直径 16mm，六个 M8 螺栓孔，分布在直径 60mm 的圆上。 【几何约束】所有尺寸单位为毫米；只能使用 CadQuery 标准方法；起始平面为 XY 平面；最终变量命名为 result。 【输出要求】只输出 Python 代码，不要输出任何解释文字。

重点在于三件事。第一，单位必须明说，否则模型可能默认英寸。第二，最终变量名要固定，这样后面自动化校验才能稳定取到结果。第三，明确要求“只输出代码”，因为大模型经常好心在代码前后加一段说明，或者用 Markdown 代码块包裹，解析成本立刻上来。加了这个约束，脚本可以直接落盘、直接执行。

还有一个经验：不要给太长的自然语言需求描述，而是拆成结构化分点。模型对“要点列表”的遵循度，远高于对“一段散文”的提炼准确度。如果需求里缺失某个尺寸，我会在提示词里补一句“缺失尺寸按常见标准值处理，并在注释中标明”，这样既避免脚本卡死，又保留可追溯性。

3.3 自动校验：生成不等于可用

LLM 生成的脚本，一次通过率远没有想象中那么高。我见过的问题包括：语法错误、变量名不一致、尺寸为零、实体缺失、甚至生成出来的对象是个空洞的壳。所以在执行脚本之后，必须加一段自动化校验，把明显不合理的结果拦截在进入 CAD 之前。

import ast import cadquery as cq src = open("part.py", encoding="utf-8").read() # 第一步：语法检查 ast.parse(src) # 第二步：执行检查 scope = {} exec(src, scope) result = scope["result"] # 第三步：几何检查 solids = result.val().Solids() assert len(solids) > 0, "没有生成实体" for s in solids: assert s.Volume() > 0, "实体体积异常"

这段代码干的活很简单：先确认脚本语法没问题，再确认执行后有一个叫 result 的对象，最后确认它确实包含体积为正的实体。语法能跑、运行不报错、实体存在，这三关全过，才说明生成结果值得进一步检查。我还习惯再加一个包围盒判断，比如最长边不能超过 1000mm，用来拦截那种“参数漂移”到离谱场景的结果。

3.4 后处理与格式导出

校验通过之后，就可以导出了。CadQuery 的导出接口很统一，我一般直接这样写：

from cadquery import exporters exporters.export(result, "flange.step") exporters.export(result, "flange.stl")

它会根据文件后缀自动判断导出格式。STEP 格式留给后续制造和装配，STL 格式拿去快速 3D 打印或者做展示。我还会额外导出一张 SVG 预览图：

exporters.export(result, "preview.svg", opt={"width": 400, "height": 400})

先看图，再进大软件，能省掉很多来回打开关闭的等待时间。这个习惯我建议必须养成，因为模型文件一多，靠文件名回忆内容根本不现实。

3.5 一个完整示例：带六孔的法兰盘

用一个真实需求串起整条链路。需求描述是：“直径 80mm 的法兰盘，厚度 8mm，中心孔直径 16mm，六个 M8 螺栓孔，分布在直径 60mm 的圆上”。先做参数换算：

• 外圆半径 = 80 / 2 = 40mm
• 中心孔半径 = 16 / 2 = 8mm
• 螺栓孔分度圆半径 = 60 / 2 = 30mm
• 六个孔的角度间隔 = 360 / 6 = 60°
• M8 通孔取 8.5mm，留约 0.5mm 装配间隙（工程上更严格的间隙等级请查配合表）

CadQuery 脚本核心可以这样写：

import math import cadquery as cq # 外圆拉伸成圆柱 disk = cq.Workplane("XY").circle(40).extrude(8) # 中心孔 disk = disk.faces(">Z").hole(16) # 六个螺栓孔，圆周均布 bolt_points = [] for deg in range(0, 360, 60): rad = math.radians(deg) bolt_points.append((30 * math.cos(rad), 30 * math.sin(rad))) disk = disk.faces(">Z").workplane().pushPoints(bolt_points).hole(8.5) result = disk

这段代码的思路很直白：先画一个圆截面拉伸成圆柱，再在顶面打中心孔，然后计算六个螺栓孔的位置，批量打孔。这里有两个操作值得解释一下。pushPoints是 CadQuery 里非常典型的批量打孔手段，一次性传入多个点位，后续的hole会自动作用于每一个点，比手写六个重复的hole()调用清晰太多。faces(">Z")是先选中顶面，再基于它创建新的工作平面，确保打孔方向明确朝上，不会出现孔的方向歪掉这种低级问题。

跑完这个脚本，得到一个带全部特征的法兰盘 STEP 模型，直接拖进商业 CAD 软件进行测量、标注、出图，整个过程从文本到模型基本可以压缩在一分钟内。

4. 工程化关键：不只要“能画出来”，还要“能造出来”

4.1 尺寸与包围盒校验

生成一个好看的模型很容易，生成一个能加工的模型很难。我跑了大量案例之后最大的感受是：校验维度不能只看“有没有实体”，还要看“尺寸是否符合预期”。所以我习惯在自动校验阶段把关键尺寸也提取出来，和需求值做比对。

最常用的三个指标是外接包围盒、总质量和体积。比如需求厚度是 8mm，结果脚本执行出来包围盒 Z 方向是 80mm，那大概率是尺寸单位或者参数解析出了问题。再比如一个“薄壁支架”，实体体积却大得离谱，通常意味着拉伸方向反了，把空腔填成了实心。这类问题通过包围盒和体积比对，一眼就能识别，根本不需要打开模型肉眼看。

4.2 把脚本当作“源文件”来管理

这是一个特别重要的工程认知。很多人以为生成 STEP 文件之后就一劳永逸了，但 STEP 格式主要保存的是边界表示几何，参数化特征树通常不会完整保留。换句话说，你拿 STEP 进商业 CAD，看到的是一个“死模型”，想改一个孔的位置，没法直接双击尺寸来改。

所以我的建议是：脚本即源文件。所有生成模型的 CadQuery 脚本都要纳入版本管理，需要改设计就改脚本参数，然后重新生成、重新导出。这样看起来多了一道流程，实际上把“可追溯性”彻底解决了——任何时候回头，都能从文字需求一路追到最终模型，中间每一步都是可复现的。

4.3 与现有 CAD 工作流的衔接

生成模型进入现有工作流时，要注意一个现实问题：商业 CAD 打开 STEP 后，大概率以无特征导入体的形式呈现。这意味着工程师不能直接在特征树上改尺寸，但依然可以做测量、标注、装配、出工程图这些下游操作。如果确实需要在 CAD 里保持完整参数化能力，通常有两种处理方式：一种是在导入后用软件自带的特征识别工具，手动重建关键特征；另一种就是回到第 4.2 条的思路，改脚本再重新导入。

这里没有银弹。我自己的习惯是：前期概念探索阶段，用生成模型快速评审，结论基本确定后，再由工程师在 CAD 里重新建模一次，把参数结构理清楚。text-to-cad 的价值不在于消灭工程师的建模工作，而在于把“试探性建模”这种大量重复劳动压缩掉，让工程师把时间花在真正需要判断力的地方。

5. 踩坑实录与排查技巧

5.1 LLM 生成脚本一次通过率低怎么办

这是所有人都会遇到的第一道坎。LLM 生成的 CadQuery 脚本，经常会出现方法名写错、把其他库的用法嫁接到 CadQuery 上、链式调用断掉这类问题。处理办法有三层。

第一层是前置约束。在提示词里限制只能使用 CadQuery 标准方法，并且给出一个简短的可用方法清单，能显著提高命中率。第二层是语法和运行校验，也就是前面写的三步校验法，把报错信息清晰暴露出来。第三层是对执行环境做白名单限制，因为生成的脚本本质上是可执行代码，在正式使用前一定要检查它不会调用文件删除、网络请求这类危险操作。

5.2 生成的 STEP 文件导入 CAD 报错

有时候脚本执行成功，几何体看着也正常，但导出的 STEP 文件一进商业 CAD 就报“面破损”或者“无效实体”。这种情况多半是模型存在自相交面或者重复边。解决办法是先让脚本强制做一次布尔合并，换句话说，把多个分散体统一成一个 Solid，再做导出。如果还是报错，就用网格修复工具或者备用的开源内核重新导出一次，相当于给几何体做一次“清洗”。

我后来学到的经验是：批量导出之前，先写一个巡检脚本，把目录下所有 STEP 都导入一遍做几何验证，全部通过再进发布流程。这个验证步骤不能省，否则现场演示时导入失败，非常被动。

5.3 提示词太简单导致几何关系错误

一个非常典型的问题：需求说“一个圆柱体，中心有一个方孔”，如果不指定方位和坐标系，生成结果可能把方孔放在侧面，或者方孔偏在边上。原因是大模型对“中心”的理解缺少几何语义锚点。

解决方法是把提示词里的方位词写死。比如“沿 Z 轴方向的圆柱体”“在顶部平面中心开一个边长 10mm 的正方形通孔”“孔的方向与圆柱轴线平行”。这些约束看起来啰嗦，但恰恰是消除歧义的关键。另外一个实用技巧是：在提示词里要求“依次列出你理解的几何关系清单”，让模型先输出它的理解，再生成代码，这样一旦结果不对，你立刻能看出来是理解错了还是代码错了。

5.4 常见问题速查表

这张表是我日常排查的标准动作，基本覆盖了 80% 的问题。剩下 20% 通常来自底层版本兼容性，直接换干净环境重装就能解决。

6. 影响范围与后续拓展

6.1 对设计流程的影响

text-to-cad 真正影响的不是“画图”这个动作，而是设计前期的需求对齐方式。以前需求方描述一个零件，工程师凭经验理解，理解错了要等到模型出来才发现。现在文本直接变成初版模型，需求方第一时间就能看到结果，分歧立刻暴露，沟通成本大幅下降。这个价值在跨部门协作和外包对接场景里尤其明显。

6.2 教育场景的价值

另一个我很看好的场景是 CAD 教学。初学者最难理解的往往是“草图和特征”这套抽象逻辑：为什么同样是画一条线，拉伸、旋转、扫掠出来的结果完全不同。text-to-cad 把每一步文本意图对应到建模特征上，学生可以看到“说了一句话，程序做了什么操作”，反过来更直观地理解特征树的含义。这不是用来让学生抄作业的，而是用来让他们理解隐藏在自然语言背后的几何逻辑。

6.3 可以往哪些方向扩展

这个方向后续能做的事很多，我列几个我实际在琢磨的方向。第一个是装配体级生成，从“生成一个零件”扩展到“生成一组带装配约束的零件”，难点在于约束关系的表达和校验。第二个是和拓扑优化联动，先用文本生成初版模型，再自动做受力分析和材料去除，返回一个优化后的版本。第三个是自动出图，生成模型后直接输出带标注的工程图，这一步能把链路延伸到更接近交付的状态。

第四个方向其实是最容易被忽视的——反向链路。把已有的 STEP 模型转成“几何描述文本”再喂给模型，相当于让模型学会看懂别人的模型，这在知识复用、草图检索、老图纸数字化方面都有想象空间。

最后再分享一个我实际用下来的体会。text-to-cad 现在最适合做的事情，是快速把语言描述变成可评审、可修改的初版模型，而不是替代成熟的建模过程。真正省时间的地方，不是画图那一步，而是省去了和需求方的反复确认：模型一出来，分歧立刻暴露，沟通成本大幅下降。再补一个小技巧：把口径统一的提示词模板保存下来，每次只改动“零件说明”那一段，生成稳定性会好很多。这个习惯让我在大量重复验证中少走了不少弯路。