企业官网建设流程全解析

写这篇文章之前，我先说个真实感受：去年第一次在CAD社区里看到“text-to-cad”这个词时，我第一反应是“又来个概念炒作”。但我自己上手跑通了一次从自然语言到可编辑参数化模型的完整流程后，想法完全变了。它并不是要取代谁，而是在实实在在改变工程师和设计师拿到一个“想法”时的起点——以前是从空白画布开始，现在是从一句话开始。

这些年我既用过传统CAD软件做结构设计，也折腾过编程式建模工具。text-to-cad给我的最大冲击是：它把“建模”这件事从“操作软件”重新拉回了“表达意图”。本文就把我在这条技术栈上踩过的坑、验证过的思路、以及真正能落地的实操流程一次性讲清楚。

1. 先用大白话搞懂：Text-to-CAD到底解决什么问题

1.1 它和“文生图”“文生3D模型”不是一回事

很多人第一次看到text-to-cad，会下意识拿它和Midjourney、Stable Diffusion这类文生图工具比较，或者和Point-E、MeshGPT这类文生3D模型归为一类。这个类比方便理解，但会误导你的预期。

文生图和文生3D模型，本质上是在“生成像素”或“生成网格”。你输入“一只坐在悬崖边抽烟的柴犬”，它给你一张图片或者一个粗糙的网格模型。这类输出的特点是：视觉很像，但不精确；你可以拿去做概念展示，却不能直接拿去加工。你没法对这张图说“把烟去掉，改成雪茄”，更没法指定某个圆柱体的直径是12.5毫米，中心孔公差是H7。

Text-to-CAD的目标完全相反。它追求的不是“看起来像”，而是“可编辑、可计算、可制造”。它生成的是一种结构化描述，通常是一段参数化建模代码、一个CSG构造树，或者一组带约束的草图与特征操作序列。当你输入“一个直径60毫米、高20毫米的圆柱，中心打一个直径12毫米的通孔”时，它不是在“画”这个零件，而是在“写”一段程序，程序执行后产生这个零件。

一句话总结：文生图给你一张照片，text-to-cad给你一张带完整尺寸标注的“图纸”。这个区别决定了后面所有技术路线、评估标准、使用方式的差异。如果你拿文生图的预期去用text-to-cad，大概率会觉得它“又笨又死板”；反过来，如果你拿CAD设计师的标准去要求文生图，那也全是漏洞。

1.2 什么人最需要它

我自己的使用场景偏机械结构验证，所以下面这些判断更多来自工程视角。但根据我在社区里观察到的反馈，真正把这工具用起来的主要是三类人：

第一类是机械工程师和产品结构设计师。他们最痛苦的不是不会建模，而是“想法到初稿”这个过程太慢。一个标准法兰盘，熟练的工程师用SolidWorks或Fusion 360画，可能需要10分钟；如果要做参数化，让尺寸能联动修改，还要再花更多时间整理约束。用text-to-cad，只要能把需求说清楚，往往几十秒就能拿到一个可编辑的初始版本，后续再进CAD里细化。

第二类是非专业建模人员，比如创客、硬件爱好者、电子工程师。他们经常需要一个外壳、一个支架、一个连接件，但不想为这个专门学一套完整CAD操作。对他们来说，text-to-cad大大降低了“把脑子里的东西变成实物”的门槛。

第三类是做CAD二次开发和自动化的人。这类人最关心的不是某个模型长什么样，而是“自然语言到特征树”这条链路的可靠性。他们想的是：如果我能让AI自动把需求解析成建模操作序列，那我就可以把它接进自动化设计流程，让客户提需求后直接出多个方案。这块目前还不够稳，但方向已经非常明确。

先说清楚一个边界：现阶段text-to-cad还不太适合做精细的自由曲面造型，比如汽车蒙皮、产品外观流线。原因是这类东西很难用几句参数化语言讲清楚，本来就不是“规则几何体”的堆叠。它真正擅长的是机械零件、连接件、外壳、箱体这类规则几何占主导的场景。

2. 核心原理拆解：为什么选择“生成代码”而不是“生成网格”

2.1 CSG与参数化建模：一句话背后的一棵树

要理解text-to-cad的生成逻辑，得先理解它输出的数据结构。目前主流实现都围绕两个核心里面转：CSG（Constructive Solid Geometry，构造实体几何）和B-rep（Boundary Representation，边界表示）。两者经常配合使用。

CSG的思想很直白：任何复杂的实体都可以由基本几何体（立方体、圆柱、球、圆锥等）通过布尔运算（并集、差集、交集）组合而成。你可以把基本几何体想象成乐高积木，布尔运算就是“粘到一起”“挖掉一块”“留下相交的部分”这三种操作。我之前做过一个支架，需求是“一块底板加两个侧壁，侧壁上各打两个螺丝孔”，如果用CSG表达，就是两三次“并”和“减”的组合。

这里我做了一个简化示意图来说明思路：

最终零件 = 实体1（底板） ∪ 实体2（左壁） ∪ 实体3（右壁） - 孔1 - 孔2 - 孔3 - 孔4

实际生成时，模型不是靠“想象”把它变成网格，而是通过一个解析器把自然语言拆成语义标签，再映射到一组建模原语上。比如“直径”“厚度”“打孔”“均匀分布”，这些词会绑定到构造函数、尺寸参数、布尔操作类型上。最终产出一段可以执行的代码，这段代码调用的库就是CadQuery、OpenSCAD、PythonOCC这类程序化建模内核。

B-rep则是另一种表示方式，它直接描述实体的边界：哪些面、哪些边、哪些顶点，以及它们之间的拓扑关系。专业CAD系统内部主要用B-rep，因为它能精确表达圆角、倒角、复杂曲面。Text-to-CAD系统生成代码后，通常要交给一个构建内核去计算和验证，这个内核最终会把CSG树转换成B-rep，这样才能在主流CAD软件里无缝打开。

这解释了一个常见困惑：“为什么text-to-cad给我的不是.obj文件，而是一段代码？”因为如果给的是网格，你就失去了编辑能力；给的是一段代码，你就能改参数、删特征、重算。这是建模和“捏泥巴”的本质区别。

2.2 程序化输出带来的三大优势

为什么主流text-to-cad方案都押注“输出程序化代码”而不是“输出网格”？三个优势非常明显。

第一个优势是可编辑性。网格模型是一堆三角形面片的集合，你很难对它做“把直径从60改成80”这种操作——除非重新生成。而程序化生成的模型，所有尺寸都是参数，改一个数字重新执行就好了。我在实操中经常对生成结果不满意，直接改代码里的数值，几秒钟就能得到新版本，这在传统CAD里至少要重新画一遍特征。

第二个优势是可验证性。代码可以被静态检查，可以被编译执行。执行成功不代表模型正确，但至少说明这个操作序列在几何上是合法的。如果布尔运算失败，代码会报错，你能定位到是哪一个操作出了问题，而不是拿到一个破损网格还浑然不觉。这在批量生成、无人值守的场景里尤其重要。

第三个优势是可追溯性。你拿到的不只是一个模型，还有它的完整“建模史”。这段历史可以用在所有基于特征的设计系统里。团队协作时，同事拿到你的生成代码，能清楚地看到这个零件是怎么一步步搭起来的，也能修改某一步而不影响其他步骤。这种透明性是纯AI生成网格完全给不了的。

2.3 主流实现路径与工具

现在能跑通的text-to-cad实现，基本可以分成三条路线。

第一条是“大语言模型加专用库”。这是我最推荐也最容易上手的一条。做法是让训练过的语言模型直接输出CadQuery或OpenSCAD代码，然后在本地执行代码生成模型。代表性的开源项目有CadQuery本身作为后端，配合各种LLM微调版本。我记得社区里有一套流程是：把自然语言提示词发给模型，模型返回CadQuery脚本，脚本在Jupyter Notebook里运行渲染3D预览，确认后导出STEP或STL。全程20分钟以内能跑通。

第二条是“针对CAD数据微调的专业模型”。这种路线直接对参数化CAD数据做监督微调，不依赖通用LLM的代码能力。它会专门学习“直径”“孔距”“阵列”这类CAD术语和对应操作的映射。好处是准确率明显高，坏处是数据难搞，训练语料需要大量带标注的CAD模型和描述文本，数据清洗工作量相当惊人。

第三条是“把LLM接入CAD软件的API层”。像Autodesk Fusion 360的自动化API、FreeCAD的Python接口，都可以作为LLM的执行后端。模型不直接生成几何代码，而是生成一系列API调用，从而在真实CAD软件里操作特征树。这种路线离生产环境最近，但依赖厂商API的完整性，目前更像是一种“高级自动化探索”。

我实际使用下来，第一条路线最平衡。既能快速验证想法，又能避免被某个商业软件API绑定。CadQuery的社区活跃度足够高，文档里也有大量可供模型参考的范例。

注意：不管选哪条路线，都不要把text-to-cad当成“一个开箱即用的黑盒”。现在的真实情况是：生成一个能看的基础模型不难，生成一个符合全部尺寸和公差要求的模型，需要人机配合。

3. 实操记录：从一句中文到可3D打印的法兰盘

3.1 环境准备与工具链

我用的是“自然语言 + CadQuery + Jupyter Notebook”这套组合，全部本地运行。环境准备很简单，几句话就能说清。

需要准备Python 3.9以上版本，然后安装CadQuery。我建议把CadQuery装进一个专门的conda环境或虚拟环境，避免和系统Python环境冲突。安装命令大致如下：

conda create -n cad_env python=3.9 conda activate cad_env pip install cadquery

如果还需要在Jupyter里做三维预览，可以加装一个jupyter-cadquery扩展，这样能直接在Notebook里旋转查看生成的模型，体验比导出后看文件舒服很多。另外建议装一个numpy，因为后面如果要做阵列复制、坐标计算，用numpy可以少写很多循环。

关于语言模型的选择，如果你纯粹想验证流程，用现成的通用大模型API就能跑通；如果想要更好的CAD术语理解，可以考虑在GitHub上找针对CadQuery微调的开源权重。我自己的做法是：先用通用大模型快速试提示词，确认思路无误后再切到专用模型做批量生成。这样能在前期快速迭代提示词，避免每次试错都等专用模型的慢速推理。

完整流程的骨架是：

1. 用自然语言描述零件需求 2. 交给LLM生成CadQuery代码 3. 在Jupyter中执行并渲染 4. 检查尺寸和拓扑，不符合就改代码或改提示词 5. 导出STEP/STL，进入CAD或切片软件做最终处理

3.2 提示词怎么写才“不翻车”

这个环节我认为比模型本身更关键。同一句话，换个说法，生成成功率可能相差好几倍。我总结了一套写提示词的模板，不敢说万能，但实测下来非常管用。

模板是六个要素：零件是什么、整体尺寸、各个特征的相对位置和尺寸、特征之间怎么组合（挖空、凸起、阵列）、单位、对称性或数量要求。你把这些信息结构化地给模型，它返回的结果就稳定得多。

以一个法兰盘为例，我推荐这么写：

请用CadQuery生成一个圆形法兰盘： - 外径60毫米，厚度10毫米 - 中心有一个直径12毫米的通孔 - 在半径为20毫米的分布圆上，均匀分布4个直径6毫米的通孔 - 所有尺寸单位是毫米 - 使用布尔运算，从主圆柱体中减去所有孔

对比一下漫无边际的写法：“帮我画一个法兰盘，中间有个洞，边上还有几个洞。”后者丢给模型，它可能猜分布圆半径、猜孔的数量、猜法兰厚度，出来的东西往往不是你想要的。问题是模型的“默认猜测”经常不符合你的预期，而你不会意识到它猜了什么。

这里有个关键逻辑：text-to-cad本质上是一个“意图对齐”过程，模型在你没说清楚的地方一定会做补全。所以提示词里老老实实写清楚“没说的地方按什么默认值来”，比如“未指定公差时按标准间隙配合处理”，可以有效减少意外。

我自己还有一个习惯：不要在一个提示词里同时要求太多东西。一次生成里如果有超过五六个独立特征，产生冲突的概率会大幅上升。宁可先让模型生成基础主体，然后再追加修改——比如先生成带中心孔的法兰主体，再让它“在半径20毫米的分布圆上打4个直径6毫米的孔”。分阶段生成、逐步约束，成功率比“一句话全包”高出不少。

3.3 生成、检查与二次修改全流程

下面用一次真实生成过程来展示完整流程。我把前面那段法兰盘提示词丢给模型，它返回了一段类似这样的CadQuery代码：

import cadquery as cq main_cyl = cq.Workplane("XY").circle(60 / 2).extrude(10) center_hole = ( cq.Workplane("XY") .circle(12 / 2) .extrude(10) ) flange = main_cyl.cut(center_hole) bolt_circle_radius = 20 bolt_hole_radius = 6 / 2 for angle in range(0, 360, 90): x = bolt_circle_radius * math.cos(math.radians(angle)) y = bolt_circle_radius * math.sin(math.radians(angle)) bolt_hole = ( cq.Workplane("XY") .center(x, y) .circle(bolt_hole_radius) .extrude(10) ) flange = flange.cut(bolt_hole) show_object(flange)

这段代码执行后，确实生成了一个法兰盘：外径60、厚度10、中心孔12、四个6毫米孔均匀分布在半径20的圆上。尺寸和预期完全一致，整个过程几十秒就完成了。这就是text-to-cad“从文字到模型”的标准路径。

但这不是故事的全部。我第一次生成的不是法兰盘，而是一个带开口卡槽的外壳。模型生成后，卡槽宽度和深度跟我的需求完全对不上。我当时是直接在generated代码里找到对应的.slot2D()参数，手动改掉了宽度和深度数值。改完后重新执行，模型就对了。这个修改过程，恰好体现了程序化输出“可编辑”的价值——如果模型给我的是一个网格，我只能重画，或者用CAD软件里笨拙地改网格顶点。

整个流程走完后，我会做三件事：第一，用CadQuery的.val().Volume()验证体积，估算零件重量；第二，导出STL后丢进切片软件里检查是否有破面；第三，如果需要后续加工，再导出STEP格式，放进Fusion 360里补充螺纹、圆角和公差标注。你不用把text-to-cad当成终极工具，它是你整个设计流程里的第一个且非常重要的“初稿生成器”。

4. 把模型质量逼到合格线的几个关键细节

4.1 单位与公差：最容易踩的坑

CAD软件有个特性，叫“单位敏感性”。CadQuery默认用的单位是毫米，但有些模型环境默认是英寸。我曾经把AI生成的一段Pipe类代码放进另一个环境执行，结果管子直径变成了2.5英寸而不是2.5毫米，直接报废了一批打印测试件。

所以无论你用哪个工具，第一件事就是明确单位。我建议在CadQuery代码里显式写一个单位常量，比如：

MM = 1.0 INCH = 25.4

后续所有尺寸都乘以这个常量。这样即使模型输出了奇怪的数值，你也能快速定位是单位问题，而不是几何问题。

公差是另一个隐性坑。我接触过很多从AI建模转到数控加工的人，他们习惯性地以为“模型里标12毫米，加工出来就是12毫米”。但实际加工有公差，挤出件的收缩、CNC的刀具半径补偿、3D打印的热缩，都会让实际尺寸偏离名义尺寸。text-to-cad可以帮你快速生成名义尺寸的模型，但公差和配合一定要回到CAD里手工标注。这不是AI的局限，是制造工艺本身的客观规律。

4.2 布尔运算失败与拓扑修复

生成代码后执行报错，最常见的情况就是布尔运算失败。这通常不是模型“理解错了”，而是几何内核层面根本没法完成求交、求差。比如两个面刚好共面，或者圆柱面和平面相切，在浮点精度下会出现退化边。

遇到这种情况，我的通用排查顺序是这样的：第一步，把Bool操作拆开，分别执行，看是哪一步出的问题；第二步，给其中一个参与布尔运算的体加一个微小偏置，比如0.001毫米，打破共面或相切状态；第三步，检查是否有无效几何，比如厚度为零的片体或自相交的面。

cq.Workplane对象在运算过程中允许你做“水密性检查”。我写过一个很糙的检查脚本，大致逻辑是检查生成后的实体体积是否大于零、每个面是否闭合。这一步可以拦截掉大部分“模型看着对，但切片软件报错”的问题。

4.3 从STL到可制造：切片软件视角的检查

当模型要被3D打印时，STL的质量直接决定了成败。CadQuery导出STL后，我习惯先丢进切片软件做“过山车式”检查：查看层高切片是否连续，有没有飞出的杂面，有没有厚度过小的薄壁，模型是不是完全闭合。

有一个常见问题是“非流形边”。表现为切片后某些层缺失或出现不连续轮廓。这种问题在视觉预览里往往看不出，只有在切片剖面里才会暴露。如果遇到，我一般会回到CadQuery里，用.fix()方法尝试修复，或者手动重建出问题的特征。

我也总结了一张表，给刚开始用text-to-cad做制造件的人参考：

这套检查流程不依赖具体工具，核心思路是：AI生成的模型只是数字世界的“半成品”，把它变成物理世界合格的零件，还需要一个工程师视角的过滤层。

5. 常见问题与排查心得

5.1 常见问题速查表

下面这些问题，都是我从社区反馈和自己使用中总结的高频问题。如果你在实操过程中卡住，可以先对照这张表自查，比到处搜帖子效率高得多。

5.2 几条独家经验

第一，永远给模型“留后路”。不要指望一次性生成完美模型。我在所有工作流里都保留一个“代码修正”阶段。模型生成的代码是文本，你可以像改普通代码一样修改它。你在提示词里说“中心有一个孔”，结果模型把孔打偏了2毫米，就算你重新生成也不一定正好修对，但直接改代码里的center坐标却非常精准。

第二，用“特征顺序”控制稳定性。同样的零件，按不同顺序建模，成功率差别很大。我的经验是：先做主体，再打孔，最后做阵列。如果一开始就做复杂的阵列复制，模型往往会在坐标计算上出错。让模型先生成一个基础实体，然后再在实体上追加特征，比让它一步到位生成完整装配结构稳定得多。

第三，给自己建一个“提示词模板库”。我给自己建了一个小的提示词模板集，把常见零件类型(size box、mount plate、flange、bracket)的提示词结构固定下来，每次只需要改尺寸和孔位数。这个习惯让我的生成效率提高了不止一倍，也减少了重复调参的心智负担。

第四，注意“自然语言的模糊地带”。比如“横着放”，模型怎么理解“横”？“中间”，是整个部件的中心，还是某个局部坐标的中心？这种模糊词越多，结果越不可预测。我的应对方式是：把模糊描述全部替换为数值或明确参照。比如“沿着X轴方向放置”“底面对齐到Y=0平面”。宁可提示词啰嗦一点，也不要让模型去猜。

最后分享一小段真实体验

Text-to-CAD这波技术，真正触动我的不是它“多智能”，而是它改变了我和工具之间的关系。以前我用CAD软件，大部分时间花在“告诉软件怎么做”：点这里、拉这个面、选这个约束、输入这个数值。现在我说的是“我想要什么”，软件负责“怎么做到”。这个转变对老手的意义，不亚于从命令行转向图形界面——只是这次，方向反过来了。

这波技术迟早会进入主流CAD软件，成为像参数化草图和特征树一样默认存在的功能。到那时候，建模能力的内卷会进一步加剧：会用AI建模的人并不是没有门槛，门槛变成了“你能不能把需求说清楚”。练好表达，把几何直觉和工程判断留给人类自己，剩下的交给工具去执行，这大概就是未来几年设计师和工程师最值得掌握的新基本功。