企业官网建设流程全解析

1. 这个方向为什么突然火了

先说结论：text-to-cad解决的核心问题，是“把脑海里的三维结构，直接变成可编辑、可制造的CAD模型”。不管是给你自己做个手机支架，还是给公司设计一个非标零件，以前都得老老实实打开SolidWorks或者Fusion 360，从草图开始一点点拉。

现在不一样了。你输入一段自然语言——比如“一个直径30毫米、厚度5毫米的圆盘，中心有一个直径8毫米的通孔”，系统直接输出对应的CAD文件。要么是生成一段参数化建模脚本，要么直接生成可编辑的三维实体文件。

这个方向之所以值得关注，是因为它把CAD的“使用门槛”和“生成效率”两个痛点同时打了一针。

传统的建模流程，本质上是人脑先构型，再通过软件把构型翻译成几何约束和特征树。一个熟练的工程师画上面那个圆盘，大概也要半分钟到一分钟。而text-to-cad这类工具，输入文字后几秒到几十秒出结果，而且输出的不是一张渲染图，是可以继续编辑、导出STL去3D打印、或者直接用来出工程图的三维模型。这对非机械专业出身的人，比如创客、工业设计师、电子工程师，是一个很实在的效率杠杆。

这篇文章的定位很清晰：如果你对AI辅助设计感兴趣，但不想只停留在“AI能生成模型”的概念层，而是想知道“它具体是怎么做到的、有哪些工具现在就能用、我在实操中会遇到什么坑”，那接下来的内容是为你准备的。我会从底层思路拆解、工具选型、完整实操流程到问题排查，全部过一遍，确保你看完能自己动手跑通一个最简单的text-to-cad流程。

我没有把这件事当成科幻来看，而是当成一个“终于有人把CAD的语法糖做出来了”的现实生产力工具来分享。原因很简单——这个领域的核心，不是AI从零创造几何，而是AI学会了“把自然语言翻译成CAD软件能懂的几何操作序列”，这几年在语言模型和程序合成两个方向的积累，让这件事真正到了可落地的阶段。

2. 内容整体设计与思路拆解

2.1 技术路径的三种流派

text-to-cad看起来只是“文字进、模型出”，但背后选了一条什么技术路线，直接决定了生成结果的质量、可编辑性和应用边界。市面上主流的有三条路线，我有必要把它们拆开讲清楚，否则你选错了方向，后面的体验会完全不一样。

第一条是直接生成体素或网格模型。这类方案通常用三维扩散模型，类似二维图像生成的Stable Diffusion的思路，只不过生成空间从像素变成了体素。输入文字描述，模型直接输出一个三维体素场，然后通过Marching Cubes之类的算法提取出网格。优点是非常直观，文字能描述到的形状基本都能“画”出来，适合做概念设计、造型探索、游戏资产。缺点也很致命：生成的网格质量差、拓扑混乱、有大量自交面，而且基本不具备参数化可编辑性。你拿着一个网格模型去改尺寸，只能整体缩放，改不了“把圆角从2毫米改成5毫米”这种操作。

第二条是生成CAD命令序列或程序代码。这是当前学术和工业界认为最有落地价值的一条路，Text2CAD、Zoo Text2CAD这些代表性项目都走这个方向。系统把“文字描述”通过大语言模型翻译成一串CAD操作指令，比如画草图、加约束、拉伸、打孔、倒角，本质上是在写一段“建模操作程序”。这样做的好处非常明显：生成的结果自带参数化结构、特征树完整，你可以回到CAD软件里去编辑任何一个步骤。缺点也有：因为输出的是程序化指令，遇到“雕塑感很强、曲面自由”的描述会比较吃力，那是细分曲面和参数化曲面的强项，不是参数化实体建模的长处。

第三条是检索式的方法。系统先从数据库里检索相似模型，再通过文本控制做局部变形，生成一个新模型。这类方案适合“我要一个类似XX但稍微不同的零件”的场景，缺点是数据库覆盖面决定上限，你的需求稍微偏一点，结果就开始“牛头不对马嘴”。

你看，这三条路线没有一条是“银弹”，理解了它们的区别，你才能明白为什么这个领域目前最主流、工具链最成熟的方案是“文字→建模代码→CAD实体”这一条。它是唯一能做到“生成的模型真的能用、能改、能制造”的路径。

2.2 为什么“先生成代码”比“直接生成模型”更聪明

我最早接触text-to-cad时有个疑问：为什么不直接让AI输出一个STEP文件，非要让它先输出一段CadQuery或者OpenSCAD代码，然后再花时间执行和转换？这不是多此一举吗？

后来在实际用过的项目里，我才彻底想通这个问题。核心原因有三个，每个都很现实。

第一，代码是可验证的。CAD软件里的大多数操作，比如拉伸、旋转、布耳运算，对几何精度要求极高。如果让AI直接吐一个网格，你很难从“一堆三角形”里看出来它有没有做错。但如果输出的是代码，你可以一行一行地审，哪里错了改哪里，甚至可以让另一个AI来检查这段代码的语法和逻辑。也就是说，“代码”作为一个中间表达，给了整个系统一个中断、检查、修正的机会，这是端到端黑盒生成不具备的。

第二，代码是可编辑的。工业界的模型，不是生成出来就完事了。客户过来说“把这个槽宽改小2毫米”，AI生成的参数化代码可以直接改参数变量，重新执行一次就得到新模型，整个过程可能只需要几秒钟。你如果让AI直接生成网格，等着重新训模型或者手动雕刻吧。

第三，数据集是现成的。当前几乎所有公开的CAD数据集，比如ABC、Fusion 360 Gallery、Text2CAD数据集，都可以自动转成CAD操作序列。语言模型本身就是文本处理工具，让它学习“从自然语言到建模代码的翻译”，简直顺理成章。这也是为什么短短两三年，这个方向的模型能力突飞猛进，因为技术基座——LLM——本身就成熟了。

说人话就是：让AI写“怎么做模型”的说明书，再让CAD内核按说明书执行，比让AI直接凭空变出模型，靠谱得多。这也是为什么我下面所有实操内容，都围绕“文字→代码→实体”这条链路展开。

3. 工具选型与核心细节解析

3.1 现在能直接用的主流工具一览

table:

光看这张表可能没有太大感觉，我用实际的体感来传达一下。Zoo Text2CAD目前算是“最不折腾、最接近开箱即用”的一个，它面向的对象就是像我这样想快速验证流程的人。它的精度虽然不能和商业软件PK，但作为流程验证和原型生成，效果已经足够惊艳。

Text2CAD是真正把这个概念做成严格论文和多模态数据集的项目，模型的训练数据本身就是从大量CAD建模过程里提炼出来的“文字-操作对”。你看它的论文会发现，团队甚至专门做了“草图和特征融合”的编码器，让文字描述能和CAD特征一一对应起来。这个项目的意义不在那个demo能生成多复杂的模型，而在它给整个领域提供了标准和数据基础。

CAD-GPT这种方向就更“硬核”了，它不是简单生成CadQuery脚本，而是想直接预测一套包含约束求解的策略，再交给CAD内核去求解。这个路线的上限更高，但复杂度也明显更高，项目主要还是停留在研究和预印本阶段。

3.2 实操首选CadQuery的两个决定性理由

每个工具都有自己的建模语言，为什么我在实操里首选CadQuery而不是OpenSCAD？不是因为它一定更强，而是它的设计哲学跟“AI生成”这件事最匹配。

CadQuery是一个基于Python的CAD库，它的工作方式是用代码构建一个“实体序列”。你今天拉伸一个圆台，明天打个孔，每一步操作都作用在当前实体上，最后得到一个复合实体。这种链式调用方式，和语言模型逐字生成代码的思考方式几乎完美契合。

更实际的意义有两个。第一，CadQuery天然支持参数化。你定义一个变量d=30，后面所有用到直径30毫米的地方都引用这个变量，改一处全图更新。这对AI生成的代码来说是刚需，因为AI不可能每次都准确得像人类一样心里的数一点不错，参数化给了你“事后调整”的容错空间。第二，CadQuery背后是OpenCASCADE几何内核，这是工业级的内核，导出的STEP、STL文件质量远不是普通网格工具能比的。

当然，OpenSCAD也不差，它尤其在“CSG布尔运算”和“纯数学建模”的场景下很简洁，代码更像数学表达式。但它的生态和Python生态的距离比较远，AI生成的代码在CadQuery里报错了，你还能用标准的Python调试工具去查；在OpenSCAD里就不太好查了。

一句话总结：如果你想认真玩text-to-cad这条链路，选CadQuery做建模后端，是当前综合体验和踩坑率最低的选择。下面的实操部分，我也会全程用它。

4. 实操过程与核心环节实现

4.1 环境准备：30分钟搭好一个可运行的text-to-cad实验台

别急着先下载大模型，我建议的路径是先把推理环境跑通，再处理数据。为什么要先跑通推理？因为电脑上只有“模型真的能跑起来”，你后面调试提示词、调参才有真实反馈，否则你在网上看的那些示例永远跟你没关系。

我用的是一台配备RTX 4090显卡的机器，显存24GB，推理Zoo Text2CAD默认量化版本完全没压力。如果你的显卡弱一些也没关系，可以把模型量化为4bit或8bit，显存占用能降到8GB左右。

第一步：创建独立的Python虚拟环境，避免把系统Python搞乱。

conda create -n text2cad python=3.11 conda activate text2cad

第二步：克隆Zoo Text2CAD的仓库并安装依赖。

git clone https://github.com/zoo-group/zoo-text2cad.git cd zoo-text2cad pip install -r requirements.txt

第三步：下载模型权重。这一步很关键，仓库里提供了多个档位的模型，我实际用的是“Llama-3.1-8B-Instruct-text2cad-v1”这个基于微调的版本，文件名里一般会带有“8B”字样。放到本地目录后，需要改一下推理脚本里的模型路径，具体每个人目录结构不同，但我建议在配置里用一个绝对路径，不要用相对路径，省得到后面发疯不知道模型在哪。

第四步：验证环境。跑一个仓库自带的demo提示词，比如“a flat head screwdriver”，正常情况下的输出应该是CadQuery代码，而不是报错信息。如果这段代码能成功执行，你就获得了最基本的“从文字到CAD模型”的能力。

4.2 写提示词的三个层次：从能出结果到出好结果

“写个手机支架”这种提示词，任何模型都会懵。不是说它不知道手机支架长啥样，而是它不确定你要多宽的手机、多大的倾斜角、是否需要充电口开槽。这个领域对提示词的要求，远比写文案生成要高，因为你描述的是精确的几何和空间关系。

根据我的经验，提示词可以拆成三层递进结构。

第一层是主体形状描述。锁定大方向：它是一个平板？一个圆筒？一个L形支架?需要说清楚“是什么形状的什么物体”。

第二层是尺寸约束。这是model能不能用的关键。建议优先使用“直径、高度、厚度、壁厚、中心距”这种标准工程词汇，并且单位明确。比如可以直接这样写：A cylinder with a diameter of 40 mm and a height of 60 mm。

第三层是特征操作描述。也就是你要在上面加什么或减什么：中心开一个直径10毫米的孔，底部加一个厚度2毫米的底座，外沿倒角1毫米。这些描述对应到CadQuery里，就是一个个具体的operation，模型能不能准确翻译出来，也跟你的描述颗粒度有关。

我来给你看一个我实际跑通的提示词，这是一个可用性极高的压缩机阀片简化模型提示词：

A circular valve plate with a diameter of 50 mm and a thickness of 3 mm, featuring five holes of 6 mm diameter arranged in a circular pattern with a pitch circle diameter of 34 mm, and a center hole of 8 mm diameter.

这段英文提示词看起来比较长，但没有一个词是浪费的。它把“是什么形状（圆盘）、尺寸（50mm直径、3mm厚）、特征数量（5孔）、位置（PCD直径34mm均匀分布）、中心孔大小（直径8mm）”全部交代清楚了。

实际生成的代码是这样的（这是Zoo Text2CAD输出的简化版，逻辑完全一致）：

import cadquery as cq diameter = 50 thickness = 3 pcd = 34 hole_diameter = 6 center_hole = 8 result = ( cq.Workplane("XY") .circle(diameter / 2) .extrude(thickness) .faces(">Z") .workplane() .center(0, 0) .circle(center_hole / 2) .cutBlind(-thickness) )

注意，模型生成的可能不是完整代码，而是片段或伪代码，这很正常。你需要自己补全CadQuery语法。但这恰恰是text-to-cad目前最实用的使用场景：AI不是直接给你成品，而是给你一个高完成度的草稿，你负责补全和验收。整个过程，从一个空白的Fusion 360界面开始画画，到这里拿到可编译的代码，总时间通常不超过两分钟。

4.3 从代码到实体：把CadQuery脚本转成STL或STEP

拿到代码之后，下一件事就是把它变成真实的三维模型文件。这一步我强烈建议直接在CadQuery的脚本环境里做，不要复制到在线CAD里随便跑，因为离线执行会给你更多调试和查看的自由度。

将以下代码存成一个valve_plate.py，然后运行：

import cadquery as cq diameter = 50 thickness = 3 pcd = 34 hole_diameter = 6 center_hole = 8 valve_plate = ( cq.Workplane("XY") .circle(diameter / 2) .extrude(thickness) .faces(">Z") .workplane() .center(0, 0) .circle(center_hole / 2) .cutBlind(-thickness) ) for i in range(5): angle_rad = math.radians(360 / 5 * i) x = pcd / 2 * math.cos(angle_rad) y = pcd / 2 * math.sin(angle_rad) valve_plate = ( valve_plate.faces(">Z") .workplane() .center(x, y) .circle(hole_diameter / 2) .cutBlind(-thickness) ) cq.exporters.export(valve_plate, "valve_plate.stl") cq.exporters.export(valve_plate, "valve_plate.step")

运行后，你会得到两个文件：STL格式用来3D打印或渲染渲染预览，STEP格式用来导入SolidWorks、Fusion 360、FreeCAD等主流工具做进一步编辑。到这一步，一个“从文字描述到可制造模型”的完整闭环已经跑通了。

有一点值得提一下：实际跑通之后，你会发现AI生成代码的“一次通过率”可能只有五六成。最常见的问题是import漏了、某个变量没有定义、布尔运算时选的面不对。这些错误都不是致命伤，用标准的Python调试思路逐行查就好了。真正麻烦的是下面这节要讲的几类“看起来没报错，但结果不对”的隐性坑。

5. 常见问题与排查技巧实录

5.1 最坑的不是报错，而是“运行成功了但模型明显不对”

我接触text-to-cad一年多，最头疼的问题从来不是“代码运行报错”，而是“CAD渲染出来一个奇形怪状的玩意儿，但它不报错也不警告”。这种项目里最经典的现象包括：

第一，坐标系理解偏差。语言模型对英文的“top face”“side face”理解通常是语义级的，但CAD里的面是有严格方向和法向的。提示词里说“在顶部打孔”，模型可能在“>Z”面上打完孔之后，又用同样的坐标去给底面剪了个盲孔，看上去代码逻辑完整，但实际模型多了一个你根本不需要的特征。

第二，单位不一致。模型有时候会默认你在用英寸，但我们的CadQuery脚本默认是毫米。一个直径2.0的圆柱，你以为生成2毫米直径的小销钉，结果模型给它解释成2英寸然后换算成50.8毫米的大圆盘。这类问题排查起来非常费劲，因为你从代码上看不出任何毛病，只有把视图放大到合适比例才恍然大悟。

第三，布尔运算顺序错误。CadQuery里先后顺序很重要。你是先画一个圆盘再打孔，还是先画一个圆环再拉伸，得到的结果完全不一样。前者会产生一个带孔的实体，后者可能产生一个“悬浮”的圆环。AI生成的代码经常会在布尔运算的链路上出现这类问题，而且极难从文本角度发现。

我自己的排查习惯是：拿到AI生成的代码后，不要急着转STL。先在CadQuery的查看器里用“逐步执行”的方式，把每一步生成的中间几何结果都输出一遍，看到底哪一步异化了。这一步多花两分钟，能省下后面半小时的徒劳调试。

5.2 快速排查表：给你的text-to-cad项目备一份

table:

这张表看起来是问题清单，但它背后其实有一个共同的方向：别把AI生成的CDA模型当成不可质疑的“成品”，把它当成一个需要验收的“毛坯方料”。这个意识一旦建立，你的排查效率会大幅提升。

5.3 实用小结

跑通一遍之后你会发现，现在text-to-cad真正的瓶颈不再是“生成能力”，而是“可控性”。你让模型生成一个龙头把手，它带你三个风格各异的方案；但你让它把按钮直径做成25毫米，它可能会把25毫米理解成半径然后给你做成一朵“向日葵”。

所以我的建议很直接：用这个技术，要克制一点。它不是用来替代严谨的机械设计的，而是用来快速产出原型、探索造型、生成思路草稿的。一个极佳的使用场景是“我给客户出了三个方案，用text-to-cad在两小时里弄出了六个方向”，而不是“这个核心承力件，我让AI直接写代码开模”。

另外，如果你打算长期用这个工作流，我建议把常用提示词模板沉淀下来。我是用一份简单的笔记维护的，里面存着“圆盘类零件”“轴类零件”“法兰类零件”等常见基础形状的标准提示词模板，用的时候直接改数字就行。这份提示词资产，某种意义上比模型权重更值钱——因为模型一直在更新，而你对业务需求的描述方式，才是真正属于你的竞争力。

6. 写在最后

聊到这里，text-to-cad在我心里的定位已经很明确了：它不是一个“取代CAD工程师”的威胁者，而是一个“把工程师从重复劳动里解放出来”的杠杆。说句大实话，我刚开始接触Zoo Text2CAD时，心里也有“这靠谱吗”的怀疑。直到我连续跑通了十几个零件，从磁性手机支架到散热风扇外壳，确认它能在几分钟内给出一个能编辑、能出图、能打印的基础实体时，才真正意识到这个工作流已经远不是玩具。

这篇文章里的所有步骤，我都按“从零到一”的顺序走了一遍，你照着做，大概率能在一个晚上以内，构建出属于你自己的“文字到CAD模型”流水线。哪怕你只是一个业余的3D打印爱好者，从这段经验里映射出的能力，也足够让你的创意从文案直接跨进车间。

我个人实际操作中的体会是：这个工具的爽点不在“它能做出来的那个最终模型”，而在“它让你敢于去描述、去构型那些以前根本不敢碰的东西”。你不再需要精通每一个拉伸、旋转、扫掠的按钮顺序，你只需要知道你想要什么。这种“意图驱动创作”的感觉，是我用这个工作流之后最大的收获。

最后分享一个小技巧：先学会给AI“打草稿”，而不是一开始就追求完美成品。你每一次让AI生成的模型，本质上都是在给你的“文字描述能力”做标注训练——描述得越准确、越工程化，下一位AI同学给你的模型就越靠谱。把这当成一种技能来练习，你会发现text-to-cad的价值会随着时间的推移不断放大。