企业官网建设流程全解析

第一次在电脑前把一句“给我一个带中心孔的圆盘，外径80毫米，厚10毫米，外圈倒角2毫米”变成真正的STEP文件时，我愣了一下。这不是玩笑，也不是那种只能看不能用的“文字转3D模型”玩具，而是text-to-cad——让自然语言直接驱动CAD建模——真正进入了我的工作流。这个方向最近在社区里热得发烫，但大多数讨论都停留在“演示很震撼”的层面，真正能讲清楚它背后有几条技术路线、哪些能落地、哪些是画大饼的内容反而很少。这篇文章我打算用自己的实测经历，把text-to-cad从原理到踩坑完整拆一遍，给想入坑的工程师、设计师，以及对AI辅助设计感兴趣的朋友一个尽量真实的参考。

1. 先搞清楚text-to-cad到底解决什么问题

1.1 从“画图”到“说图”的转变

传统CAD建模是个什么流程？拿着需求，打开软件，选草图平面，画轮廓，加约束，拉伸，减材料，倒角，再回到草图……一套动作下来，一个简单的零件也许十分钟，复杂的零件几小时甚至几天。这里面最耗时间的不是“想清楚”，而是把脑子里的想法一步步翻译成软件能理解的几何操作。

text-to-cad想干的，就是把这一层翻译直接干掉。你用自然语言描述需求，模型负责把它拆解成建模意图，再由CAD内核执行输出真正的CAD数据。注意我这里说的是CAD数据，不是美术模型。

具体发生的事情可以从三个层面来看：

• 在交互层，建模师不再需要点选按钮，而是描述需求；
• 在逻辑层，模型将文本中的实体（圆柱、孔、倒角）和对应操作（拉伸、切割、阵列）映射为参数化特征序列；
• 在数据层，输出的是STEP/IGES这类带精确几何信息的文件，可以直接进入下游装配、工程图和CAM加工。

这个转变的本质是：建模意图的传达方式变了。以前是人对着软件说“我要这样建”，现在是人对模型说“我要这个件”，模型去对着软件说。解放的是操作时间，压缩的是从“语言描述”到“3D几何”的转换成本。

1.2 和传统3D生成的根本区别：能编辑 vs 只能看

很多人一听到text-to-cad，第一反应是“这不就是AI生成3D模型吗”。还真不是。市面上常见的文本生成3D模型工具，比如喂一句话生成一个发光的房子、一只卡通猫，输出的是网格模型——OBJ、GLB这种。网格模型的好处是造型自由、渲染好看，但坏处也很致命：它是一个“死”的三角面片集合，你没法编辑参数，没法改厚度，没法进CAM加工，连倒角都得回到软件里重新修。

text-to-cad要看的是另一套东西：参数化特征和边界表示（B-rep）。CAD软件里面的每个圆柱、孔、倒角，背后都是一串特征历史和约束关系。text-to-cad要生成的就是这种“活的”模型——拉伸多长、孔直径多少、倒角半径多少，全部是可以改的数字。

判断一个AI辅助CAD系统是不是“真CAD”还是“假3D”，就一条标准：生成的结果能不能进入建模历史树里继续被编辑。能进历史树、能改参数、能导STEP的，才是真text-to-cad；只能导出一个不能编辑的STL网格的，再惊艳也停留在“预览”层面。

1.3 谁最需要它：我在实际工作中的观察

我这一年多在机械设计和工装夹具场景里实际试下来，text-to-cad的需求其实非常集中，主要在这么几类人身上。

第一类是非标自动化工程师。每天跟气缸座、垫块、传感器支架、联轴器打交道，零件形态高度重复，只是尺寸变来变去。对他们来说，text-to-cad要是能省掉“每次重新画一遍相似建模”的时间，效率直接翻倍。

第二类是结构仿真和热仿真工程师。他们常常需要快速搭建带有特定形状、孔位、散热齿的概念几何，并不关心内部的装配逻辑。语言生成参数化几何，对他们是刚需。

第三类是做采购、售前、报价的人。很多时候只需要一个“看起来差不多、尺寸能对上”的初版模型去做沟通，不需要精确到公差。这种粗稿需求，用text-to-cad生成比开完整CAD软件快得多。

我没提工业设计师和自由曲面造型师——不是不需要，而是在当前技术栈下，自由曲面这条路离可靠还有距离，后面会细说。

2. 拆开来看：业界常见的三条技术路线

2.1 路线一：大模型直接写CAD脚本（LLM + 程序化建模库）

这是我目前用得最多、也最容易落地的一条路线。思路很简单：用一个或多个大语言模型理解自然语言，把描述翻译成一段定义好的CAD脚本代码（比如CadQuery或OpenSCAD），然后由系统的建模引擎执行这段代码，生成精确的CAD模型。

直观的流程是：

1. 用户输入：“一个直径30mm、高45mm的圆柱，顶部带一个半径5mm的圆角。”
2. 大模型判断这是“圆柱-拉伸-倒角”的组合，生成CadQuery代码；
3. CadQuery内核执行代码，在内存中构建出B-rep；
4. 导出成STEP，进入正常CAD流程。

这条路线最吸引人的地方是：它复用了现有的工程级CAD内核。CadQuery底层是OpenCascade，这可是造飞机、造机床都用过的几何内核，能保证几何精度。大模型只负责“翻译”需求，不负责“计算”几何，因此只要代码正确，产出的模型就是精确的、可编辑的。

2.2 路线二：端到端几何生成（扩散模型/序列生成）

这是学术界和论文里最热闹的一条线，也是被很多公司拿来演示“未来感”的技术。它不通过代码中转，而是训练深度学习模型直接生成CAD原生的几何表示，常见两种形态：

• 把CAD建模过程看作“特征操作序列”，模型学习输出“草图轮廓 → 拉伸 → 打孔 → 布尔”这样的序列标记，然后驱动内核重建；
• 用扩散模型生成点云或体素，再用NURBS/B-rep拟合后处理成CAD格式。

这条路线理论上上限最高——它可以生成极其复杂的自由形态几何，不再受限于“脚本能描述到的规则形状”。但它的痛点也很明显：

• 训练数据极难获取：工业级带历史树的CAD模型不是互联网上有多少就有多少的，企业模型都加密且带版权；
• 生成结果拓扑不稳定：容易出来自相交曲面、非流形几何，放到CAD里就是纯废品；
• 可编辑性弱：生成的是“结果”，不是“过程”，修改一个尺寸往往得从头生成。

按我看到的公开工作（比如一些Text2CAD方向的研究论文），目前大多数成果还停留在“能生成简单拉伸件的视觉几何”阶段，离工程使用有距离。但它指明了方向，值得关注。

2.3 路线三：检索拼装（自然语言驱动组件复用）

还有一条容易被忽略但落地性极强的路子——检索拼装。它不需要模型去“凭空创造”几何，而是让大模型理解用户的语言描述，从企业已有的标准件库、历史模型库中检索出最匹配的零件，进行装配或变体驱动。

这和RAG（检索增强生成）的思路一模一样：把模型库里的每个零件做向量化检索，用户的描述作为query，匹配到合适的模型后再用参数化驱动它修改尺寸。

一个很常见的落地场景是：企业有一整套法兰库，从DN15到DN200各种规格都有，text-to-cad的调用方式就是让大模型从描述“我要一个DN100的带颈平焊法兰，螺栓孔按GB标准”中抽出关键参数，去模型库里调出对应模板，驱动尺寸生成新实例。

这条路线常常被“自由生成”的光环掩盖，但它恰恰是现阶段投入产出比最高的方向——因为它根本不需要模型“硬造”几何，只需要一个靠谱的参数化模板库加一个能做意图解析的模型。

2.4 三条路线怎么选：我的对照表

为了不让选择显得玄学，我把自己在项目里判断路线的维度整理成一个表：

我的判断是：短期内想产出实际价值的，走一和三；长期想突破自由形态的，关注二。三条路线未来大概率会融合成一个混合架构，而不是相互取代。

3. 最小验证：亲手搭一个text-to-cad跑通流程

3.1 环境准备：CadQuery与LLM的组合

说再多不如自己动手跑一个。我用的最小组合是：CadQuery + 一个通用代码能力够用的大模型。选CadQuery不是因为它完美，而是因为它有三个其它库短期比不了的优势：首先是Python原生，大模型对Python的掌握程度远超对CAD软件宏语言的掌握；其次是它有明确的建模历史，适合做“翻译”和“修改”；最后是它底层是OpenCascade，导出的STEP能直接进主流CAD和CAM。

步骤很简单：

1. 安装CadQuery环境，推荐用conda创建干净环境，避免依赖冲突；
2. 装上cq-editor进行可视化调试（不一定必需，但强烈推荐）；
3. 选一个大模型，我用下来通用大模型（GPT-4/Claude类）和代码专精的本地模型（如Qwen2.5-Coder）在“简单零件翻译”这个任务上差距不大，本地模型的好处是可以离线、数据不出内网，工厂环境里这点特别重要。

CadQuery安装好后，验证一下能不能在Python里正常导入并且能导出STEP。这一步非常关键，因为后面所有LLM生成的代码都依赖这个环境，环境不对会浪费大量调试时间。

3.2 提示词工程的几个关键约束

text-to-cad里的提示词，和写文案的提示词完全是两码事。它本质上是在给大模型定义一个“翻译规则”，规则不清晰，输出就会乱。我最常踩到的坑是“让模型自由发挥”。所以我现在的提示词模板固定包含四类约束：

• 角色设定：明确告诉模型它是“CadQuery专家”，并且只输出Python代码，不输出解释；
• 单位与坐标约定：明确所有尺寸单位是毫米，草图平面默认在XY平面，挤出默认沿Z轴正方向，避免模型自己发挥；
• 特征语义：要求模型先识别并列出目标的特征清单（比如“外圆柱、中心孔、顶部倒角”），再为每个特征写对应操作；
• 出错处理：在每段代码后注释清楚该代码基于的CadQuery API习惯，或者反过来要求代码必须有可导入的依赖。

一个我反复验证有效的提示词例子：

你是一名CadQuery专家。请根据下面的自然语言需求，生成一段可运行的CadQuery Python代码。 规则： 1. 所有长度单位默认为mm； 2. 草图默认在XY平面，默认沿+Z方向挤出； 3. 零件需求会描述多个特征，请先用一行注释列出特征清单，再逐一实现； 4. 只输出Python代码，不要包含任何解释段落。 需求：一个外径80mm、内径20mm、厚度10mm的中心孔圆盘，外圆顶部边缘倒角2mm。

这个提示词跑出来的结果，稳定性比“帮我画个圆盘”这种模糊指令高一个数量级。

3.3 一个能跑通的示例：从中文描述到STEP文件

下面是我验证过的一段CadQuery代码，对应上面需求。如果你在自己环境里跑，应该能直接导出STEP：

import cadquery as cq result = ( cq.Workplane("XY") .circle(40) # 外圆半径40mm，外径80 .extrude(10) # 厚度10mm，沿+Z .faces(">Z") .workplane() .hole(20) # 中心孔，直径20mm .edges("|Z") .fillet(2) # 外圆竖直边倒角2mm ) cq.exporters.export(result, "flange_demo.step")

这段代码的执行逻辑是：在XY平面画一个半径40的圆，拉伸10mm得到圆盘；选择顶面并在其上创建新工作平面；使用hole函数在顶面钻一个直径20的通孔（CadQuery的hole传的是直径参数）；最后选中所有与Z轴平行的边做2mm的倒角。

导入到FreeCAD里打开STEP，可以测量确认外径80、内孔20、厚度10、倒角2，完全符合输入要求。

3.4 模型生成结果怎么验证

验证是text-to-cad流程里绝不能省的一步。我见过很多人第一步跑了模型生成，看到“看起来对”的几何就以为成功了，结果拿去加工发现孔位置偏了0.5mm。我的验证分三层：

• 语法层：代码能否无报错执行？报错信息直接回传给大模型让它修复，这个闭环很关键；
• 几何层：用CadQuery或者解析STEP文件，检查关键尺寸是否落在需求公差范围内。比如孔直径是否真的是20mm、外径是否80mm；
• 特征层：检查建模历史树是否保留了应有的特征。比如孔是“打出来的”还是“用布尔减出来的”，倒角是否真的以特征形式存在——这决定了下游修改的灵活度。

做到第三层，才算真正完成了一个text-to-cad的闭环验证。目前很多公开demo只做前两层，这也是为什么它们能“展示”但不能“生产”的原因。

4. 实测里躲不开的坑：从“代码能跑”到“模型能用”

4.1 最典型的翻车：代码看起来对，实际上错

跑通上面的demo，你可能会产生“这玩意儿已经很好用了”的错觉。等你把需求从“圆盘”换成“带四个均布孔的法兰盘”，大模型生成代码的执行结果往往会给你当头一棒。

我遇到的最典型的翻车是：模型生成的代码语法完全正确、运行完全无报错，但结果明显不对——比如它把圆环外径算成内径的一半，把四个均布孔生成成了中心一个孔，把倒角做在了内孔边缘而不是外圆。

这种错误的狡猾之处在于：它不报错，所以如果你只看日志不看几何，根本发现不了。根因是大模型对CAD几何语义的“常识”目前还是偏弱的：它知道“螺栓孔”是孔，但对“均布4个孔在分度圆上”如何转换成CadQuery的极坐标阵列，经常给出看似合理实则错位的代码。

所以我的经验是：不要相信模型的“自检”。必须在流程里加入一个独立的几何校验步骤，无论模型说自己多确定，都要让程序去测量关键尺寸。

4.2 草图平面和挤出方向：最容易埋雷的地方

CadQuery的建模顺序是“选平面 → 画草图 → 挤出/切割”。这一套里有两个地方模型经常搞混。

第一个是草图平面选择。CadQuery默认是“XY”，但在多层建模时模型容易在各种workplane中间绕晕。比如它想在侧壁上打孔，本应选择“>X”或“>Y”面，结果写成了“>Z”，生成的孔就横着穿到了另一侧。

第二个是挤出方向。CadQuery的extrude默认向草图平面的法线方向，但如果你在非默认平面上操作，方向判断就容易出错。模型生成“反着挤”的代码，实际模型整个偏移，特别隐蔽。

我的规避办法是：在提示词里强制规定“所有新的工作平面都用faces().workplane()方式显式声明”，并且“所有挤出必须写明方向参数，挤出高度值只允许正值”。这样可以从源头上压缩模型犯错的概率。

4.3 单位与图纸习惯：一个低级但致命的坑

CAD行业内最大的“单位暗坑”之一，就是模型生成单位和实际生产单位不一致。CadQuery默认是毫米，这个没问题，但当你把导出的STEP文件放到不同CAD、不同国家的工厂里，图纸上标的单位可能是英寸。

很多大模型训练数据里混着英制单位代码，它在生成参数时可能把“25.4”和“1”混用。我真实遇到过：让模型生成一个“1英寸厚的支架”，它按英寸理解了但CadQuery按毫米执行，结果模型只有1mm厚，导出的STEP没法用。

所以提示词里应该把单位这一项固定死。并且如果你需要英制，最好的办法是全部按毫米输入，在最后落图阶段用工具统一换算，不要依赖大模型自己做单位转换——它做转换的误差率目前没有代码里的硬编码可靠。

4.4 为什么你需要一张自己的评测集

如果你打算把text-to-cad用在正经项目上，我强烈建议你花半天时间建一个“最小评测集”。做法不复杂：

• 整理20~30条你真实工作中会用到的零件描述，从简单到复杂排列；
• 每条描述写清需要的最终尺寸，关键尺寸单独标注；
• 跑一遍你的text-to-cad流程，记录四个指标：代码通过率、几何正确率、特征保留率、生成耗时；
• 每次换模型、换提示词、换系统组件，都把这份评测集重跑一遍。

这个评测集的价值非常大。因为大模型迭代速度快，今天好用的模型换一版可能就不行了，你没有评测集就没法客观比较“升级”到底是不是“升级”。我自己的评测集现在积累了60多条，每次外部模型升级后跑一遍，基本30分钟就能判断要不要切换，省去了大量脑补的时间。

5. 工具链怎么选：库、模型、生产边界

5.1 脚本化建模库横向对比：CadQuery / OpenSCAD / build123d

既然LLM写脚本是主路线，那么“把语言翻译成哪套脚本”就直接决定了系统的上限。我用了三个主流库，结论如下：

• CadQuery：Python原生，建模历史清晰，底层OpenCascade，适合直接进入工程流程。缺点是API对新手不算直观，很多操作需要理解“workplane”和“selectors”，而大模型并不总理解。
• OpenSCAD：语法极简，很多大模型对它掌握得非常好，因为它本质上就是CSG布尔运算的多面体操作，规则简单。“圆柱+挖孔+差集”这种基础操作生成成功率很高。缺点是可编程能力弱，复杂装配和参数化约束处理吃力。
• build123d：CadQuery的“继任者”，API更贴近人的直觉（比如直接用Box、Cylinder对象），支持位置、旋转表达更自然，自由度更高。文档相对新，大模型训练语料少，生成失败率目前偏高，但趋势看好。

用一句话总结我的选型思路：想要最稳，CadQuery；想要最快出效果，OpenSCAD；想要极致灵活，build123d。

5.2 大模型怎么选：通用大模型 vs 本地代码模型 vs 专用微调

模型选择直接决定翻译质量。我实测的经验有三个阶段。

第一个阶段，直接用通用大模型，比如GPT-4、Claude这类。优点是对自然语言的理解极强、也能写出像样的CadQuery代码，缺点是API成本高、数据要出网（很多工厂不能接受）。

第二个阶段，换成本地代码模型，比如Qwen2.5-Coder这类32B以下能在单卡上跑的。优点是数据不出内网、一次买断式部署、隐私无忧；缺点是代码能力在某些复杂场景下明显弱于通用大模型，需要靠提示词和上下文做补偿。

第三个阶段，如果团队有预算和算力，可以做专用微调——用企业自己的CAD脚本数据微调一个专用模型。实测下来，只要你手里有几百条“自然语言到CAD脚本”的高质量数据，再配合一个代码基座模型，效果通常出奇地好。但数据清洗成本的量级可能超过你的预期，不适合小团队。

我的稳妥建议是：先通用大模型跑通流程，确认业务价值后上本地模型，数据积累到一定量再考虑微调。顺序反了很容易白花钱。

5.3 生产环境里，什么时候能信它、什么时候不能

这是文章里我特别想展开的一段。text-to-cad在目前的工程环境里，边界非常清晰：

能信的场景是：标准化程度高的参数化零件。法兰、轴承座、支架、垫块、齿轮坯、管接头，这些零件的形态在库里有模板、在行业里有标准、在模型训练里有大量语料，生成结果基本可靠。

不能信的场景是：自由曲面和复杂装配。比如一个带复杂流道的泵体、一个要满足大量GD&T公差的机加工件、一个涉及到多个零件相互配合咬合的装配体——这些靠文本生成，目前即便偶有惊艳案例，也无法通过评审。

我的实操建议是用“三七原则”分配精力：七成精力放在把标准件模板脚本化、把企业知识库结构化，三成精力去试自由几何。这样既能看到眼前效率提升，又不会因为整天跟“高级别的失败”较劲而丧失信心。

6. 接下来值得尝试的方向：我的判断和实验

6.1 和参数化模板库结合的“填参模式”

我目前最看好的落地玩法是“text-to-cad + 企业参数化模板”。把企业常用的零件做成CadQuery/FreeCAD脚本模板，每个模板有明确的参数接口（如直径、高度、孔数、壁厚），然后让大模型只做两件事：理解用户描述、抽取参数并判断该调用哪个模板。

这两个任务都是大模型的强项——抽取参数比凭空造几何可靠得多。这套架构的成功率实测可以到90%以上，因为生成的核心逻辑不是模型写的，而是工程师预先验证过的。

我现在做的一个内部工具就是这种模式：用户说“我要一个DN50的带颈法兰，按HG/T 20592标准”，系统解析出来是“HG/T 20592 DN50”+“带颈法兰”模板，然后自动填参并导出可编辑的STEP。整个链路非常稳，因为模板是工程师写的，大模型只做语义路由。

6.2 多模态方向：语言 + 图像 + 点云的混合输入

文本最大的短板是“说不清楚复杂形状”。纯语言描述一个叶轮，你得先说几十句，还容易歧义。所以我认为很快会进化成混合输入：用户上传一张参考图或一个扫描点云，再加上一句“照着这个形状，把材料改成不锈钢，壁厚加到5mm”，系统完成多模态理解并输出CAD。

这条路的难度在于把图像/点云的几何信息与CAD特征历史对齐——但正是这种“图像找相似、文本定参数”的分工，很可能比纯文本生成更早达到工程可用。我已经在关注一些用视觉编码器辅助语义检索的项目，把它接到现有模板库上，效果已经在内部demo里体现出来了。

6.3 我对text-to-cad走向工程化的三个判断

最后说三个我比较有把握的判断，给关注这个方向的人做个参考。

第一，纯端到端生成在可预见的两年内很难进生产。数据的稀缺和拓扑的不可控是硬伤，但它在概念设计阶段的价值会越来越大。

第二，LLM + 程序化建模 + 企业参数化模板的混合架构，会是未来三到五年最主流的工程落地形态。它吃掉的不是“设计”，而是“重复劳动”——这恰好是制造业里最贵的东西。

第三，嵌入主流CAD的原生助手会逐步成为标配。等你习惯了在SolidWorks或Fusion里用自然语言驱动参数化建模，再回到纯手工草图的建模方式，会感觉像在回到没有“自动保存”的年代。

把text-to-cad从“演示”变成“工作流”，我最大的体会就是一句话：别指望模型替你创造，让它帮你压缩重复。我在实际项目里最受益的是把法兰、支架、垫块这些“长年重复却又没人愿意优化”的建模流程脚本化后，接到大模型上做语义路由。这比追求“AI凭空设计一台机器”靠谱得多，也冷启动最快。如果你要入坑，我的建议是从一个最简单的零件模板开始，跑通文本到STEP的闭环，再加上评测集一步步磨。等哪天你的基础零件库能通过自然语言驱动了，你再回头去看这个方向的论文和新闻，会发现理解完全不一样。