企业官网建设流程全解析

从去年开始，我陆陆续续尝试了好几个号称“你用一句话就能生成三维模型”的工具，体验最深的感受是：大部分产品要么只能出个“好看的图”，要么生成的模型根本没法进工程软件。直到我真正把 text-to-cad 这类工具放进设计流程里跑了一遍，才意识到这个方向真正要解决的并不是“生成一个模型”，而是“生成一个能用的、可编辑的、符合工程约束的CAD模型”。这篇文章我不讲那些浮于表面的功能介绍，直接把我拆解技术路线、跑通工作流、踩过坑的全过程整理出来，希望能给正在评估这个方向的工程师或者想入手的创客一些参考。

1. 项目概述：从“画图”到“说图”，text-to-cad到底改变了什么

1.1 一句话说清楚text-to-cad

text-to-cad，从字面理解就是“文本到CAD”，用自然语言描述直接生成CAD模型。你输入一句“一个带四个安装孔的矩形底板，长100毫米，宽60毫米，厚5毫米，四角倒圆角”，系统就能生成对应的三维模型，并且输出 STEP、IGES 这类标准CAD交换格式，或者直接生成参数化特征树，让你能在 SolidWorks、Fusion 360、FreeCAD 里继续编辑。

它和传统建模方式最大的区别，在于把“操作软件”变成了“表达意图”。过去你建一个零件，脑子里想的是“我要用拉伸、切除、阵列”，现在你只需要想“我要什么形状，什么尺寸，什么约束”，剩下的交给模型去推理。这个转变看起来只是交互方式变了，但底层其实是把几何推理、参数化建模、制造约束这些原本靠人脑完成的工作，一部分移交给了算法。

1.2 它到底解决了什么痛点

我先说一个实际场景。我手上有一批老设备的备件需要逆向建模，有些零件结构很简单，比如一个法兰盘、一个支架，但传统流程也得开CAD软件、建草图、拉伸、打孔，一个零件少说半小时。如果是标准件还好，直接调用库文件，但很多非标件每次都要从头画，重复劳动非常重。

text-to-cad 真正切中的就是这类“小零件、快交付”的痛点，它能把一个简单零件的建模时间从半小时压缩到几分钟。对于结构工程师做前期方案评审、机械加工厂快速出毛坯模型、创客做外壳原型，这类工具能明显缩短从“想法”到“模型”的路径。

另外一个价值被很多人忽略：它能降低三维建模的入门门槛。很多产品经理、工艺工程师、采购人员不需要深度掌握CAD软件，但他们对零部件结构是有判断力的。有了文本生成这层“翻译”，他们可以直接产出初步模型，再交给建模工程师优化，信息传递的损耗会小很多。

1.3 这个领域为什么值得关注

我把话放在这里：text-to-cad 不是个噱头，它是生成式AI在工程软件领域最有可能率先规模化落地的方向之一。原因很简单，机械零部件的几何结构相比科幻场景、游戏角色来说，规律性更强、约束更明确，尺寸、配合、公差、制造工艺都是可量化的硬约束，这些约束对生成模型反而是一种“锚点”，能让模型输出更稳定。

更关键的是，CAD数据的价值密度远高于一张图片或一段视频。一个STEP文件里包含的不只是几何形状，还有BOM信息、装配关系、制造特征，这些数据一旦能通过文本直接生成，对设计自动化、柔性制造、小批量定制都会有连锁影响。我个人的判断是，未来两到三年，会有越来越多的企业把 text-to-cad 集成到 PLM/PDM 流程里，作为前期概念设计的标准入口。

2. 核心技术路径：语言到CAD的底层逻辑拆解

2.1 四条技术路线对比

我调研了大量相关项目和论文，目前 text-to-cad 的主流实现思路可以归纳为四条路径。这里我直接放一张对比表，方便大家理解各自的定位。

从这张表能清楚看到，越是接近“能用”的路线，越倾向于让算法去生成“建模指令”而不是直接生成“几何形状”。这个逻辑其实不复杂：CAD软件的核心数据结构是边界表示（B-rep），它记录的是一个实体的面、边、顶点以及拓扑关系，而不是一堆三角形网格。要让生成结果能被工程师正常编辑、修改、装配，最好的方式不是让算法“猜”一个形状，而是让算法“写”一套建模过程。

2.2 为什么“程序化生成”最适合工程场景

我在测试多个方案后，最推荐关注的是“代码生成再执行”这条路径，也就是让语言模型直接生成 CadQuery、OpenSCAD 这类程序化建模脚本。CadQuery 本身就是一种“用代码描述建模过程”的 Python 库，它把拉伸、旋转、布尔运算、倒角这些操作封装成方法，执行脚本后能输出 STEP 文件。

这个方案的核心优势在于可编辑性。脚本里的每个数字都是一个参数，比如“length = 100”“hole_diameter = 8”，你想改尺寸直接改参数重新执行就行，完全不需要重新输入一遍自然语言。这正好契合工程设计的迭代逻辑，设计师很少一次建模到位，通常要反复调尺寸、改结构，参数化脚本天然支持这种工作方式。

另外一个隐藏优势是可靠性。语言模型直接生成网格时，经常会出现面片相交、翻转法线、非流形边这些问题，但在代码生成这条路径里，建模操作是全确定的，拉伸就是拉伸，布尔运算就是布尔运算，只要脚本逻辑正确，几何一定正确。哪怕生成的脚本有语法错误，也只是报错，不会产出一个“看起来对但实际没法用的坏模型”。

2.3 几何表示与文件格式的底层逻辑

很多人会忽略一个关键问题：生成的结果应该用什么格式输出。这里我展开讲讲。

CAD 软件内部使用的 B-rep 和 3D 打印常用的网格格式之间存在本质差异。B-rep 记录的是一个精确的数学曲面边界，比如一个圆柱面，它记录的是轴线方向、半径和高度，而不是成千上万个三角形。网格格式则用离散三角形近似逼近曲面，精度取决于细分密度。

text-to-cad 工具如果输出 STEP 文件，意味着生成结果的底层是精确几何，可以被工程软件直接识别、装配、做干涉检查。如果只输出 STL 或 OBJ 网格文件，虽然能 3D 打印，但进入机械设计流程时几乎没法用，工程师还得重新建模。这个差异直接决定了工具是“玩具”还是“生产力工具”。

我判断一个 text-to-cad 方案值不值得用的第一标准，就三条：能不能输出标准STEP格式；生成的模型有没有参数化特征树；改一个尺寸需要重新生成还是直接改参数。三条全过的才值得纳入工作流。

3. 实操过程：跑通一个完整的text-to-cad工作流

3.1 环境和工具选型

我目前跑得比较顺的的组合是：本地部署的 CadQuery 环境 + 一个经过微调的大语言模型 API + FreeCAD 作为查看和后期编辑工具。这套组合的安装配置过程不复杂，明确分工：

• CadQuery 负责把脚本转换成三维实体。它是整个链路里最关键的执行器，相当于一个“从代码到几何”的编译器。
• 语言模型负责理解自然语言并生成 CadQuery 代码。我试过通用大模型直接调用，也试过专用模型，后者在生成 CadQuery 代码时的准确率明显更高，主要因为训练数据里包含了大量建模示例。
• FreeCAD 负责查看模型并进行手动修改。它的Python控制台可以直接调用 CadQuery 生成的 STEP 文件，也可以作为最终交付前的人工检查环节。

这套工具链的好处是完全开源，不需要额外购买商业软件许可。如果你在公司环境里使用，也建议优先确认 CadQuery 和 FreeCAD 的商业授权情况，避免法律风险。

3.2 提示词写作方法：把“需求”翻译成“约束”

text-to-cad 的提示词和写 ChatGPT 的提示词完全是两码事。日常对话你可以写“帮我设计个好看的支架”，但文本生成CAD你必须把约束说清楚。我总结了一套“五要素描述法”，在实际测试中效果非常稳定：

1. 形状类型：你描述的是板类、轴类、壳体、箱体还是法兰类零件。这决定建模的基本思路。例如“一个矩形安装底板”。
2. 关键尺寸：尽量给出具体的数值和单位，比如“长100毫米，宽60毫米，厚5毫米”。单位要写清楚，我遇到过一次默认单位不一致导致模型缩放了25.4倍的惨痛经历，后面细说。
3. 特征操作：明确哪些地方需要开孔、倒角、切除或阵列，比如“四角倒R10圆角”“中心开一个直径8毫米的通孔”。
4. 装配关系：如果这个零件要和其他零件配合，描述配合面、螺纹规格、定位方式。比如“四个安装孔中心距分别为80毫米和40毫米，孔径6.5毫米，用于M6螺栓穿过”。
5. 制造约束：说清楚后续加工方式。3D打印的件和CNC加工的件，在壁厚、圆角、拔模角上的要求完全不同。

举一个具体的示例提示词：

“生成一个矩形安装底板，长度100毫米，宽度60毫米，厚度5毫米。四角倒圆角，圆角半径10毫米。底板中心有一个直径8毫米的通孔。四角附近各有一个直径6.5毫米的安装通孔，孔心距边缘10毫米。材质为铝合金，用于3D打印原型。输出格式为STEP文件。”

这个提示词里包含了建模所需的90%以上信息，语言模型生成脚本时几乎不需要“自由发挥”，出错的概率自然大幅降低。如果只说“生成一个底板”，模型就只能猜尺寸、猜孔位、猜圆角，生成结果必然需要大量返工。

3.3 生成、检查与迭代的完整流程

实际执行时，我建议按以下流程操作，每一步都不要跳过：

先在 CadQuery 环境里搭建好基础代码框架，定义好单位（我的实践是用毫米），然后让语言模型根据提示词生成建模脚本。生成后不要立刻执行，先人工快速核对脚本里的关键参数，有没有明显的数字错误、单位错误、逻辑颠倒。

确认没问题后执行脚本，CadQuery 会输出 STEP 文件。接着用 FreeCAD 打开，第一件事不是看外观，而是检查模型树里有没有出现“实体”节点。如果只出现了“形状”或者“网格”，说明模型不是合法实体，得打回去重新生成。这个检查非常重要，很多生成脚本执行后模型看起来是“显示”出来了，但实际上是个空壳或者无法编辑的复合体。

如果模型正常，再做三件事：测量关键尺寸是否和设计值一致；检查特征数量是否齐全，比如该有四个安装孔就绝对不能少一个；检查可编辑性，尝试修改一个参数重新生成，看模型能否正确更新。

尺寸一致性检查我强烈建议用脚本去对比，不要肉眼估。CadQuery 提供了shape.val().length、shape.faces()这类接口，可以直接用代码验证关键尺寸。我在实际中就遇到过，模型渲染得挺好看，但长宽和设计要求的差了0.5毫米的情况，这种误差在概念阶段无所谓，但在需要配合的场合就致命了。

4. 常见问题与排查：我在实际使用中踩过的坑

4.1 几何精度与单位问题

最坑的一点就是单位。我的第一个测试任务是做一个直径50毫米的圆盘，生成结果在 FreeCAD 里打开，测出来却是50英寸。后来排查发现，底层建模内核默认单位是英寸，但语言模型生成的代码里没有显式声明单位，CadQuery 按默认单位执行，尺寸直接放大25.4倍。从那以后，我在所有生成脚本开头都会强制加一行import cadquery as cq; cq.Workplane("XY")并显式声明使用毫米单位，同时在提示词里再强调一遍“所有尺寸单位为毫米”。

另一个精度问题是圆整误差。语言模型生成的代码里有时会写diameter = 7.999而不是8，这种误差在单个特征上不明显，但如果这个尺寸参与装配配合，就可能出现公差冲突。排查方法很简单，用代码检查所有关键尺寸变量，确保没有出现奇怪的“非整数”数值。

4.2 拓扑正确性问题

所谓拓扑错误，指的是模型的点、线、面之间的连接关系不对。典型症状包括：模型看起来是实心的，但导出 STL 切片时出现破洞；模型能显示，但布尔运算时报错“无法计算”；装配时两个面明明贴合但干涉检查却报异常。

这类问题大多是脚本里的布尔运算顺序导致的。比如你先建了一个底板，又建了一个圆柱凸台，最后想把两者合并成一个实体，如果合并操作里用了union而不是newZ这些 CadQuery 特有的语义，或者两个实体的面恰好共面，内核就可能产生退化面。排查时我会把布尔运算的分步结果分别输出，逐个检查每个实体的边长和面数，定位到具体是哪一步融合出了问题。

再补充一个技巧：如果生成的模型拓扑总出错，尝试调整特征操作顺序。比如先做倒角再做孔，或者先合并再做切除，不同顺序对结果影响很大。我测试下来，CadQuery 里“先生成主轮廓，再叠加所有特征，最后合并”这个顺序的容错率最高。

4.3 生成结果不可编辑的困境

这类问题最让人头痛，模型的形状完全正确，但在 CAD 软件里打开后发现它是一整个“钉子户”形状块，没有特征树，没法改任何一个参数。凡是遇到这种情况，基本都是因为生成路径走的是“直接转网格再转回实体”的链路，而不是“脚本流程化建模”。

我判断能不能编辑有一个土办法：在 FreeCAD 里点击模型，如果左侧模型树显示的是多个步骤（比如“拉伸”“打孔”“倒角”），说明是可编辑的；如果只显示一个孤零零的“Shape”节点，那就基本废了。真正可用的 text-to-cad 工具，输出结果必然是一棵特征树。如果你遇到不可编辑的结果，别试图修复它，直接改提示词重新生成，效率反而更高。

4.4 文本描述与模型理解偏差

语言模型理解自然语言时，经常会忽略一些工程师认为“理所当然”的隐含约束。比如你说“安装孔”，工程师会默认孔是通孔、是圆柱形、轴线垂直于安装面，但模型可能生成一个盲孔，或者孔轴歪了。所以提示词里凡是涉及孔、槽、凸台这类特征，都建议明确加上“通孔”“圆柱形”“垂直于表面”“完全贯穿”这类限定词，不要怕啰嗦。

我测试时验证过，同一个零件描述，补充完这些限定词后，一次通过率从不到50%提升到了80%以上。所以提示词不是越短越好，而是该有的限定必须有。

5. 使用场景与工具盘点：哪些领域能先吃到红利

5.1 最值得优先尝试的五个场景

机械设计领域，标准件、常用件的快速生成是最直接的应用。法兰盘、轴承座、支架、安装板、防护罩这类结构规则、参数明确的零件，几乎就是为 text-to-cad 量身定做的。我实测下来，这类零件用文本生成要比从零建模快3到5倍。

3D打印领域，创客做外壳、夹具、传感器支架时，用 text-to-cad 生成初稿再修整，能省掉大量“从草图开始”的时间。这里的优势是3D打印对壁厚的宽容度高，即使生成的模型有一些小瑕疵，切片软件也能处理。

非标自动化领域，项目前期做方案概念设计时，需要快速验证结构可行性，如果每个零件都建模，时间成本太高。用文本生成快速搭一个粗略装配体，用来评审布局和干涉情况，效率和精度都足够用。

消费品设计领域，比如手机壳、音箱外壳、灯具底座，这类产品外形相对规则，text-to-cad 可以快速探索多种形态变体，然后导入工业设计软件细化。它最大的价值在于批量生成变体，而不是单个精修。

教学培训领域，机构教学生理解“参数化建模”思维时，可以用 text-to-cad 让学生直接观察不同参数对模型的影响，对建立“参数驱动设计”的概念非常直观，比手把手教拉伸和切除更快。

5.2 当前值得关注的开源项目与商业产品

工具层面我关注到，已经有开源社区在尝试把大语言模型和 CadQuery 或类似库集成，做成了“文本输入-脚本输出”的 Web 界面，这类项目的思路很清晰，直接把生成代码暴露给用户看，透明度高。商业方面，已有公司发布过面向工程师的文本建模工具，提供基于浏览器的界面和标准格式导出。

选择时我建议重点考察三点：是否支持 STEP 输出；是否支持参数化编辑；是否开放脚本查看和修改。三条都满足的，不管开源还是商业，都可以深度试用。至于那些只能输出 STL 网格的“三分钟建模神器”，我的建议是玩玩可以，别放进正式工作流。

5.3 这套技术带来的设计流程变革

我从最开始的好奇到现在的深度使用，最大的感受是整个设计流程的“入口”变了。以前一个设计任务从需求到模型，中间隔着建模软件的学习成本和操作门槛；现在用文本生成，需求本身就是起点，模型是需求的直接投影。这带来的变化是，项目前期可以更快地验证更多结构方案，而不是因为建模时间太长而只做一两个方案。

另外，text-to-cad 让“非设计师”参与设计过程变得容易了。工艺工程师能直接生成自己需要的焊缝定位板，装配工程师能快速生成检具模型。这种从“专业分工”到“需求驱动”的转变，我觉得才是它最值得期待的地方。

6. 写在最后：从项目实践中学到的两件事

第一次完整跑通 text-to-cad 流程时，我只是觉得“挺方便”，并没有太当回事。直到后来我把它用在一个真实交付项目里，用文本生成了一套12个零件的工装模型，才真正意识到这个工具链的价值——那套件从需求到初审模型只花了一下午，换传统方式至少两天。但我必须诚实地说，它目前还替代不了工程师的最终把关。生成模型在细节上仍然需要大量人工修正，尤其在公差标注、表面处理、材料选择这些制造层面的信息上，语言模型的理解还非常浅。

我个人在实际操作中发现，真正好用的工作流是把 text-to-cad 当作“方案加速器”而不是“设计替代品”：先用文本快速搭出方案骨架，再在 CAD 里细化优化。如果后续能把它和自动化尺寸标注、BOM生成、DFM分析这些下游环节打通，那这套流程的效能就不是提升一点半点，而是直接改写机械设计的协作模式。未来如果看到更多企业基于这个思路做内部工具，我一点都不意外。