企业官网建设流程全解析

1. 从一句话到三维模型：text-to-cad 到底在解决什么问题

第一次听到 text-to-cad 这个词，很多人脑子里浮现的画面大概是：对着电脑敲一句“给我画一个带法兰的六角螺栓”，然后屏幕上就自动出现一个可以旋转、可以导出、可以拿去加工的实体模型。这个画面放在五年前还属于科幻范畴，但放到今天，它已经是一条被反复验证过的技术路径。text-to-cad 的核心命题非常直白——把自然语言描述转换成计算机辅助设计系统能够识别和处理的几何数据。这里的“CAD”不是单指某个软件，而是一整套几何表达体系，包括参数化草图、实体建模、装配约束，以及最终交付给下游的 STEP、URDF、G-code 等格式。

我之所以对这个方向持续关注，是因为它切中的是一个真实且长期存在的痛点。传统 CAD 工作流里，从需求到模型之间隔着一层厚厚的“翻译”工作：产品经理说“要一个能承重 50 公斤的支架”，结构工程师得先把这句话拆解成尺寸、约束、材料、受力路径，再在软件里一步步画草图、拉伸、倒角、打孔。这个过程高度依赖人的经验，而且大量重复性建模任务——比如标准件、常见结构、批量变体——占用了工程师大量时间。text-to-cad 想做的，就是把这层翻译工作部分自动化，让语言直接驱动几何生成。

适合关注这个方向的人其实比想象中广。做机械设计的工程师可以把它当成快速原型工具，输入大致描述先出一个可编辑的毛坯模型，再手动精修；做机器人仿真的朋友会关心它能不能直接吐出 URDF，省去手工搭建连杆和关节的麻烦；做数控加工的人则盯着 G-code 输出，希望从描述直接跳到刀路。甚至做建筑、做钣金、做电气布线的从业者，也能从这个思路里找到自己场景的映射。当然，现阶段它远没到“一句话替代工程师”的程度，但作为辅助生成和快速迭代的手段，已经足够让人认真对待。

我在这篇文章里会拆开讲清楚几件事：text-to-cad 的技术链路是怎么搭起来的，为什么中间要经过 STEP、URDF、G-code 这些格式，实际动手时有哪些坑，以及我自己在折腾过程中总结出来的一些经验。不会堆砌论文式的术语，尽量用从业者之间聊天的口吻，把能直接抄作业的部分写明白。

2. 技术链路拆解：从文本到几何到底经历了什么

2.1 自然语言理解层：把“人话”变成结构化意图

text-to-cad 的第一步，也是最容易被低估的一步，是让机器真正“读懂”那句描述。很多人以为随便接一个大语言模型就能搞定，实际远没那么简单。自然语言里充满了模糊、省略和隐含约束。比如“一个 100 毫米长的轴，两端各有一个轴承位”，这句话里至少隐含了这些信息：轴是圆柱体，总长 100mm，轴承位通常是直径略小于轴身的圆柱段，两端意味着对称或至少两个特征，轴承位需要标注公差配合。一个未经专门训练的模型很可能只提取出“轴”“100mm”“轴承”这几个词，然后生成一个光秃秃的圆柱，完全忽略轴承位的台阶结构。

所以实际系统里，语言理解层通常要做几件事。第一是实体识别与关系抽取，把描述里的零件、特征、尺寸、位置关系、材料、工艺要求分别打标签。第二是意图分类，判断用户是要生成新模型、修改已有模型，还是查询某个参数。第三是约束补全，根据领域常识把省略的信息填上，比如“螺栓”默认带螺纹和头部，“支架”默认有安装孔。这一步的产出不是几何，而是一份结构化的中间表示，通常用 JSON 或类似 schema 来描述，里面明确列出每个特征的类别、尺寸、位置和相互关系。

我试过用纯提示词让通用模型直接输出建模脚本，结果很不稳定。同样的描述，十次里能有三四次生成出结构合理的模型就算不错。后来改成先让模型输出结构化 JSON，再用规则引擎把 JSON 翻译成建模指令，成功率明显提升。这个经验说明，语言理解层和几何生成层最好解耦，中间那层结构化表示才是整个系统的骨架。

2.2 几何生成层：参数化建模与程序化建模的取舍

拿到结构化意图之后，下一步是真正生成几何。这里有两条主流路线：参数化建模和程序化建模。参数化建模走的是传统 CAD 的路子，用草图、约束、特征操作来构建模型，典型代表是通过脚本驱动 FreeCAD、SolidWorks 或中望 CAD 这类软件。程序化建模则是用代码直接构造几何体，比如用 CadQuery、OpenSCAD 或者直接操作 OpenCASCADE 内核。

两条路线各有优劣。参数化建模的好处是生成的模型天然带有特征树，后续修改方便，工程师打开软件就能看到每一步操作，符合传统工作习惯。缺点是依赖具体软件的 API，跨平台性差，而且脚本执行速度慢，批量生成时容易卡顿。程序化建模的好处是轻量、快速、可批量，适合云端部署和自动化流水线，但生成的模型往往是一堆几何体的布尔运算结果，没有特征历史，后续手动编辑不友好。

我的建议是根据使用场景选。如果是给工程师做辅助设计，希望他们能在生成结果上继续改，那就走参数化路线，把模型导出成 STEP 再导入目标软件。如果是做批量生成、仿真前处理或者数据增强，那就走程序化路线，直接用 CadQuery 这类库，速度快且容易集成到 Python 流水线里。实际项目中我倾向于混合使用：先用程序化方式快速生成候选模型，筛选后再用参数化方式重建关键零件，兼顾效率和可编辑性。

2.3 格式转换层：STEP、URDF、G-code 各自扮演什么角色

模型生成出来只是半成品，真正让它产生价值的是导出成下游能用的格式。text-to-cad 场景里最常被提到的三种格式是 STEP、URDF 和 G-code，它们分别对应不同的下游需求。

STEP 是中性几何交换格式，几乎所有的 CAD 软件都能读写。它的优势是保留精确的边界表示（B-rep），曲面和实体信息完整，适合做跨软件协作和后续加工。text-to-cad 生成模型后导出 STEP，基本是默认操作。需要注意的是，STEP 有 AP203、AP214、AP242 等不同协议版本，AP242 支持颜色、图层和产品制造信息，如果下游要做装配或标注，优先选 AP242。

URDF 是机器人描述格式，用 XML 描述连杆、关节、惯性矩阵和碰撞体。text-to-cad 如果面向机器人仿真，输出 URDF 就非常关键。很多人不知道的是，URDF 里的几何通常用基本形状（立方体、圆柱、球）或网格文件表示，直接从 CAD 实体转 URDF 需要做简化，否则仿真会非常慢。我一般会先用 text-to-cad 生成实体，再写脚本把实体近似成基本形状或低面数网格，最后组装成 URDF。导入 CoppeliaSim 这类仿真器时，还要注意关节轴方向和坐标系对齐，否则机器人会以奇怪的姿态散架。

G-code 是数控加工指令，描述刀具路径。从 text-to-cad 直接生成 G-code 的难度比前两者高一个量级，因为加工涉及刀具选择、切削参数、装夹方式、材料特性等大量工艺知识。目前比较现实的做法是 text-to-cad 生成 STEP，再导入 CAM 软件生成刀路，而不是一步到位。如果非要端到端，那通常只适用于非常简单的 2.5 轴铣削或激光切割场景，比如从描述生成一个带孔的平板，直接输出轮廓切割路径。

3. 动手搭建一条最小可用流水线

3.1 环境准备与工具选型

要自己跑通 text-to-cad，不需要一上来就搞大系统。我建议从一条最小流水线开始：语言模型负责解析描述，Python 脚本负责生成几何，最后导出 STEP。这套组合足够验证想法，后续再按需扩展。

工具方面，几何生成我首选 CadQuery，它基于 OpenCASCADE，API 设计比较 Pythonic，文档也还算友好。安装直接用 pip 就行：

pip install cadquery

如果要用参数化路线驱动 FreeCAD，那就需要安装 FreeCAD 并确保它的 Python 环境可用。FreeCAD 的安装在不同系统上差异较大，Windows 下建议用官方安装包，Linux 下可以用 AppImage 或包管理器。安装完成后，可以通过freecadcmd命令行执行脚本。这里有个常见问题：FreeCAD 自带的 Python 版本可能和你系统里的不一致，导致 pip 安装的库无法导入。我的做法是直接用 FreeCAD 内置的 Python 解释器来跑脚本，避免版本冲突。

语言模型这块，如果只是本地实验，可以用开源模型配合提示词工程；如果要稳定输出结构化 JSON，建议用支持函数调用或 JSON 模式的大模型 API。关键是要设计好输出 schema，让模型严格按照字段填值，而不是自由发挥。

3.2 描述解析与结构化 JSON 设计

结构化 JSON 的设计直接决定后续几何生成的难易。我的经验是字段不要太多，但每个字段都要有明确的几何含义。以一个简单的“带孔平板”为例，可以设计成这样：

{ "part_type": "plate", "length": 100, "width": 60, "thickness": 5, "holes": [ {"diameter": 6, "x": 10, "y": 10}, {"diameter": 6, "x": 90, "y": 10}, {"diameter": 6, "x": 10, "y": 50}, {"diameter": 6, "x": 90, "y": 50} ], "unit": "mm" }

这个 schema 里，part_type决定用哪个生成函数，尺寸字段直接对应几何参数，holes数组描述孔的位置和大小。模型的任务就是把“一块 100 乘 60 的板，厚 5 毫米，四角各打一个直径 6 的孔，孔中心距边 10 毫米”这样的描述填进这个结构。实际测试下来，只要 schema 清晰，模型填值的准确率相当高。

对于更复杂的零件，比如带台阶的轴，schema 可以设计成特征列表：

{ "part_type": "shaft", "segments": [ {"diameter": 20, "length": 30}, {"diameter": 30, "length": 10}, {"diameter": 20, "length": 30} ], "unit": "mm" }

这种“特征列表”式的设计扩展性好，新增特征类型时只需增加对应的生成函数，不用改整体结构。

3.3 用 CadQuery 生成几何并导出 STEP

拿到 JSON 之后，生成几何就是写对应的 Python 函数。以带孔平板为例：

import cadquery as cq import json def build_plate(params): plate = cq.Workplane("XY").box( params["length"], params["width"], params["thickness"] ) for hole in params["holes"]: plate = ( plate.faces(">Z") .workplane() .center( hole["x"] - params["length"] / 2, hole["y"] - params["width"] / 2 ) .hole(hole["diameter"]) ) return plate with open("part.json") as f: params = json.load(f) result = build_plate(params) cq.exporters.export(result, "plate.step")

这段代码里有个细节值得说：CadQuery 的box是以原点为中心的，而 JSON 里的孔坐标通常以左下角为基准，所以要做一次坐标平移。这个偏移量如果搞错，孔就会打偏。我一开始就踩过这个坑，生成的模型孔位整体偏移了半个板宽，后来统一约定 JSON 里用中心坐标系，才避免混乱。

导出 STEP 时，CadQuery 默认用的是 AP214 协议，如果需要 AP242，可以在导出时指定。实测下来，大多数 CAD 软件对 AP214 的兼容性已经足够好，除非下游明确要求，否则不用刻意改。

3.4 从 STEP 到 URDF 的转换要点

如果目标是机器人仿真，STEP 只是中间产物，最终要转成 URDF。这个转换不是简单的格式另存，而是要做几何简化和坐标系重建。我的做法是：先用 CadQuery 或 FreeCAD 读取 STEP，提取每个连杆的包围盒和主要尺寸，然后用基本形状近似，最后写 URDF 的 XML。

举个例子，一个简单的两连杆机械臂，text-to-cad 生成的是两个带复杂倒角的实体。转 URDF 时，我会把每个连杆近似成一个长方体加一个圆柱关节座，惯性矩阵用长方体公式估算。这样仿真速度快，而且视觉上不会太失真。如果非要保留精确外形，可以把 STEP 转成 STL 网格，在 URDF 里用 mesh 引用，但要注意网格面数不能太高，否则 CoppeliaSim 加载会很慢。

坐标系对齐是另一个大坑。URDF 里每个连杆都有自己的坐标系，关节轴方向决定了运动方式。从 CAD 实体转过来时，实体的原点可能在几何中心，也可能在某个角点，而 URDF 要求关节原点在旋转轴上。我一般会在 CAD 里先把每个连杆的坐标系调整到关节位置，再导出，这样转 URDF 时省事很多。

4. 实操中绕不开的坑与排查经验

4.1 几何生成失败的常见原因

text-to-cad 最让人抓狂的就是模型生成失败，而且报错信息往往很模糊。我总结下来，失败原因主要集中在几类。第一类是尺寸不合理，比如孔径大于板厚，或者台阶直径小于前一段直径，导致布尔运算无法进行。第二类是特征顺序错误，比如先倒角再打孔，倒角把孔的边缘切掉了。第三类是坐标系混乱，多个特征用了不同的参考平面，结果位置全错。

排查这类问题，我的习惯是先把 JSON 打印出来，逐字段核对数值和单位。单位错误特别常见，模型可能默认用米，而描述里是毫米，结果生成一个巨大或极小的模型。CadQuery 默认单位是毫米，但如果你从其他库导入几何，单位可能不一致。另一个技巧是分步生成，先只生成主体，确认无误后再加孔、加倒角，这样能快速定位是哪一步出的问题。

提示：每次生成后都用cq.exporters.export导出一份 STL，用网格查看器快速看一眼形状，比在代码里调试快得多。

4.2 STEP 导入导出中的兼容性问题

STEP 虽然号称中性格式，但不同软件实现差异不小。我遇到过 CadQuery 导出的 STEP 在某个国产 CAD 里打开后圆角变成直角，也遇到过 FreeCAD 导出的装配体在另一个软件里零件位置全乱。这些问题的根源通常是协议版本和单位设置不一致。

解决办法有几个。第一，导出时明确指定协议版本和单位，不要依赖默认值。第二，尽量用 AP214 或 AP242，避免用太老的 AP203。第三，如果下游软件对 STEP 支持不好，可以先用中间软件转一道，比如先导入 FreeCAD 再导出，往往能修复一些兼容性问题。第四，装配体导出时，确保每个零件的坐标系和装配关系正确，否则导入后可能重叠或散开。

还有一个容易被忽略的点：文件名和路径不要包含中文或特殊字符。有些 CAD 软件对非 ASCII 路径支持不好，会导致导入失败或乱码。我一般用纯英文加下划线的命名方式，省去很多麻烦。

4.3 URDF 导入 CoppeliaSim 的典型故障

把 URDF 导入 CoppeliaSim 是机器人仿真里的高频操作，也是故障高发区。最常见的现象是机器人导入后散架，连杆各自飞开。这通常是因为关节的父子关系和坐标系定义不对。URDF 里每个关节都要明确 parent 和 child，以及 origin 的 xyz 和 rpy。如果 origin 写错，连杆就会错位。

另一个常见问题是关节类型不匹配。URDF 支持 revolute、prismatic、continuous、fixed 等类型，如果该用旋转关节的地方写成了固定关节，机器人就不会动。还有惯性矩阵，如果质量或转动惯量设为零或负数，仿真器可能直接报错或行为异常。我一般会给每个连杆设一个合理的质量和惯量，哪怕是用简化公式估算的。

导入后如果模型显示为白色或没有纹理，那通常是 mesh 路径问题。URDF 里的 mesh 文件名是相对路径，导入时要确保工作目录正确，或者用绝对路径。CoppeliaSim 对 STL 和 OBJ 支持较好，DAE 格式有时会有材质丢失的问题。

4.4 G-code 生成的现实边界

前面提到，从 text-to-cad 直接生成 G-code 难度很大。我实际尝试过用描述生成简单的激光切割路径，流程是：text-to-cad 生成平板 STEP，提取外轮廓和孔轮廓，用 Python 生成 G-code 的 G01/G02 指令。对于纯轮廓切割，这套流程能跑通，但一旦涉及铣削、钻孔、攻丝，就力不从心了。

主要瓶颈在于工艺参数。同样一个孔，用不同直径的钻头、不同的转速和进给，G-code 完全不同。而这些参数取决于材料、刀具、机床刚性，很难从一句自然语言描述里推断出来。所以我的建议是，text-to-cad 在加工场景里定位为“生成几何毛坯”，把 STEP 交给 CAM 软件或工艺工程师去生成最终 G-code。如果非要自动化，那就把工艺参数做成可配置的模板，针对特定材料和刀具预设好几套方案，而不是让模型自由发挥。

注意：G-code 直接驱动机床，任何错误都可能导致撞刀或工件报废。在真机上跑之前，务必用仿真软件验证刀路，并且先空跑一遍。

5. 几个值得关注的扩展方向与个人体会

5.1 批量生成与参数化变体

text-to-cad 真正体现效率优势的场景，不是生成单个零件，而是批量生成参数化变体。比如一系列不同长度和孔径的支架，或者一组不同减速比的齿轮。用传统 CAD，每个变体都要手动改参数、重建、导出，费时费力。用 text-to-cad 加脚本，可以一次性生成几十上百个模型，自动命名、自动导出，甚至自动生成对应的 URDF 或工程图。

我做过一个实验：用一份 JSON 模板描述一个带孔平板，然后写循环改变长宽和孔位，批量生成 50 个 STEP 文件。整个过程不到两分钟，包括导出和重命名。如果手动做，至少要大半天。这个效率差距在需要大量模型做仿真训练或设计探索时，价值非常明显。

批量生成时要注意文件命名和目录组织。我一般用“零件类型_参数1_参数2”的格式命名，比如plate_100x60_h6.step，这样一眼就能看出关键参数。同时把生成用的 JSON 和脚本一起存档，方便复现和修改。

5.2 与现有 CAD 工作流的衔接

text-to-cad 生成的东西，最终还是要回到工程师熟悉的 CAD 环境里。衔接得好不好，直接影响它能不能真正用起来。我的经验是，不要试图替代现有软件，而是做它的“前置生成器”。工程师用自然语言描述需求，text-to-cad 生成一个可编辑的毛坯模型，导出 STEP，工程师导入自己常用的 CAD 软件，在此基础上精修和出图。

这样做的好处是，工程师不用改变原有工作习惯，只是省去了从零建模的重复劳动。而且生成的模型带有基本特征，后续修改也方便。如果生成的是纯网格或布尔运算结果，编辑起来就麻烦很多。所以我在选择生成方式时，会优先考虑输出带特征历史的模型，哪怕生成速度慢一点。

另外，text-to-cad 也可以和 PDM/PLM 系统结合，把生成记录、参数、版本都管理起来。不过这就属于更工程化的范畴了，小团队先用好本地脚本和文件夹管理，已经能解决大部分问题。

5.3 我踩过的几个印象深刻的坑

第一个坑是单位。早期我没在 JSON 里明确单位，模型有时按毫米理解，有时按米理解，生成出来的零件尺寸差了三个数量级。后来强制在每个 JSON 里加"unit": "mm"字段，并且在生成函数里做断言检查，才彻底解决。

第二个坑是布尔运算的顺序。有一次生成一个带凹槽的零件，我先做了倒角再切凹槽，结果倒角面被切掉一块，模型出现破面。后来调整顺序，先做主要切除特征，最后统一倒角，问题消失。这个经验让我养成了一个习惯：把倒角、圆角这类修饰性特征放在最后做。

第三个坑是 URDF 的惯性矩阵。我一开始偷懒，把所有连杆的惯量都设成很小的值，结果仿真时机器人抖动严重，关节像得了帕金森。后来老老实实用长方体公式估算惯量，仿真立刻稳定了。惯量不能随便设，它直接影响动力学行为。

第四个坑是 STEP 导入 CoppeliaSim。CoppeliaSim 对 STEP 的支持有限，直接导入经常失败或丢失几何。后来我改成先转 STL 再导入，虽然损失了精确曲面，但仿真够用，而且稳定得多。这个取舍在仿真场景里很常见：精度让位于速度和稳定性。

5.4 给刚入门的朋友几条实在建议

如果你刚接触 text-to-cad，我建议不要一上来就追求端到端全自动。先从一个小场景切入，比如“生成带孔平板并导出 STEP”，把这条链路跑通，再逐步加复杂度。工具选择上，CadQuery 加 Python 是最容易上手的组合，文档和社区也相对活跃。

提示词工程方面，与其让模型自由发挥，不如把 JSON schema 设计好，让模型填槽位。schema 越明确，输出越稳定。同时准备一些典型示例放在提示词里，模型会模仿示例的格式和粒度。

最后，保持对生成结果的怀疑。text-to-cad 目前还不是可靠的生产工具，它生成的东西必须经过人工检查。尺寸对不对、特征全不全、能不能加工，这些都要工程师把关。把它当成一个不知疲倦但经验不足的助手，而不是替代者，心态会好很多。

我在实际使用中最大的体会是，text-to-cad 的价值不在于“一句话出模型”这个噱头，而在于它把重复性建模的门槛降低了。那些画标准件、改参数、导格式的琐碎时间被省下来，工程师可以专注在真正需要判断力的地方。这个方向还在快速演进，今天需要写脚本补的部分，明天可能就被模型直接搞定了。但不管工具怎么变，对几何和工艺的理解，始终是做出好东西的前提。