企业官网建设流程全解析

从一句“给我一个M6螺纹孔的法兰盘”，到软件里真的出现一个能用的三维模型，这个听起来像科幻片的场景，就是text-to-CAD正在做的事。简单说，text-to-CAD就是用自然语言描述需求，让AI直接生成可编辑的CAD模型文件。这项技术不是拿关键词拼一个图片出来，而是生成真正的实体模型，可以是STEP、STL这类标准格式，也可以是一段参数化建模脚本。它适合机械工程师快速验证结构方案、创客做非标件、教育场景里帮助学生理解建模逻辑，也是目前AIGC从“出图”走向“出实物”最务实的路径之一。

我最早接触这个方向是在追AI生成3D模型的技术路线时发现的。当时看到text-to-image已经能画出以假乱真的图，text-to-video也开始有模有样，但设计师和工程师真正需要的是能放进SolidWorks、Fusion 360里继续编辑的实体模型。市面上很多AI生成3D的工具，输出的都是带纹理的网格模型，好看但没法加工。直到我试了几个面向CAD的生成工具，才发现这个方向已经悄悄把“生成”这件事从像素层面拉到了B-rep实体层面。这篇文章就围绕text-to-CAD展开，聊聊它背后有几条技术路线、实际跑通一个例子的完整流程、有哪些坑是文档里不会写的。

1. 整体设计与思路拆解

1.1 为什么text-to-CAD和AI生成3D模型不是一回事

很多人会把text-to-CAD和“AI生成3D模型”混为一谈，这是误解最大的地方。我试过用常见的text-to-3D工具生成一个“带孔的盒子”，输出确实是一个彩色渲染好的模型，网格细腻、纹理漂亮，但把它导入切片软件时直接报错，因为模型根本不是封闭实体。而text-to-CAD的目标从第一天起就是“能用的模型”，它关心的不是长得好不好看，而是拓扑正不正确、尺寸准不准、能不能倒角、能不能打螺纹孔。

另一个核心区别在于可编辑性。AI生成的传统3D网格，本质是一堆三角形片面的集合，没法改参数、没法回溯建模特征。而text-to-CAD要么直接生成参数化建模脚本（比如CadQuery、OpenSCAD代码），要么生成的是带语义特征的B-rep模型，用户拿到手后还能改尺寸、改位置、重新生成变体。这种“可编辑”属性决定了它不是一个玩具，而是能真正嵌入设计流程的实用工具。

再往深处看，text-to-CAD意味着建模方式从“人手动操作软件”变成了“人用语言描述意图+AI负责执行”。描述同样的零件，传统CAD里可能要新建草图、画圆、拉伸、打孔、倒角五步操作，而text-to-CAD只需要一句话：“直径50mm的圆盘，中心一个直径10mm的通孔，四周均匀分布4个M4螺纹孔”。这个转变的价值不仅仅在“快”，更在于把工程师从繁琐的菜单操作中解放出来，把更多时间留给方案构思和结构优化。

1.2 生成路径的主流选择与取舍

目前text-to-CAD的技术路线大致可以分成三类，各自有不同的适用场景和天花板。

第一类是代码生成路线。用大语言模型直接生成CadQuery、OpenSCAD或FreeCAD的Python脚本，执行脚本后得到实体模型。这个路线的优势是结果天然带参数化特征，一切修改都回到代码层面，可解释性强、可重复性好。缺点是依赖于语言模型对建模API的掌握程度，模型如果调用了不存在的函数，脚本就直接报错。

第二类是深度生成模型路线。比如用扩散模型直接在体素空间生成占用场，再通过Marching Cubes提取网格，或者直接回归SDF（符号距离场）。这条路线的优势是形式自由，适合生成复杂曲面、有机形态，比如花瓶、雕塑、人体工学手柄。缺点是输出通常是网格而非B-rep实体，加工前往往需要手动修复拓扑，可编辑性弱。

第三类是检索+参数化模板路线。先建一个标准零件库，按类别、特征、拓扑关系打标签，用户输入描述后先检索最相近的模板，再让AI调整参数形成新模型。这个方案可靠性最高，因为模板本身是经过验证的实体模型，AI只是调参数，不会乱编结构。缺点是只能覆盖库内已有的零件类型，创新形态生成能力有限。

从实际体验看，面向工程落地首选代码生成路线，因为生成的脚本可以直接复用、改参数后批量出变体。面向创意探索和前期概念视觉化，扩散模型路线更合适。模板检索路线适合标准化程度高的场景，比如法兰、支架、轴承座这类常用件的快速配置。

2. 核心细节解析与实操要点

2.1 关键一步：把自然语言“翻译”成CAD指令

text-to-CAD整个链条里最关键的环节，不是CAD本身，而是“把用户的模糊意图转成精确的建模指令”。用户说“一个底板，四个角有孔”，这句话里“底板”是什么尺寸、“角”离边缘多远、“孔”直径多大，全是隐含信息。工程师之间的沟通靠图样和尺寸标注来解决歧义，AI没有这个条件，所以它对语言的理解能力直接决定了生成质量。

实际处理中，我发现提示词的质量比模型本身更能影响最终结果。试过把需求描述成“直径40mm圆盘，厚度8mm，圆心有一个直径12mm的沉头孔，沉头直径20mm，深度4mm，圆盘边缘均匀分布6个直径6mm的通孔”，生成结果几乎一次成功。而换一个含糊的“做个有很多孔的圆盘”，输出就五花八门。所以，如果你要在自己的工作流里用text-to-CAD，第一步永远是训练自己把需求拆解成“尺寸+特征+位置+类型”的精确描述。

还有一个容易被忽略的细节：AI对单位极其敏感。除非明确声明“所有尺寸单位是毫米”，很多模型会默认使用英制单位或干脆不指定单位，生成出来尺寸数值差2.54倍。我在生成的脚本里看到过0.5英寸的孔，导进SolidWorks里变成12.7mm，和需求完全对不上。因此描述里务必写清楚单位，并且检查生成的代码里单位换算是否正确。

2.2 生成脚本的执行环境与依赖管理

如果走代码生成路线，脚本落地需要一个可控的执行环境。以CadQuery为例，标准环境是Python 3.8以上版本，安装cadquery和cq-editor作为可视化预览工具。生成代码依赖的核心库版本必须固定，否则语言模型训练时基于的API和本地库版本不一致，经常出现代码调用了旧版本里不存在的新方法这类“半真半假”的幻觉。

我见过最典型的错误是模型生成了一段看似合理的代码，里面对workplane()、hole()、extrude()的调用方式完全正确，但中间混入了一个fillet()和chamfer()顺序颠倒的问题，在CadQuery里倒角和圆角必须在对应边上执行，顺序错一步就会报错。还有模型喜欢在代码里加一些不存在的函数，比如array_rect()这种看似合理但其实API里根本没有的函数。所以每次生成后先做好三件事：检查是否存在未定义函数、确认单位是否正确、预览渲染结果是否与描述一致。

执行脚本建议在独立的项目目录里操作，不要直接放在系统Python全局环境里。我用venv建一个虚拟环境，装好cadquery后把生成代码统一放在scripts/目录下，输出模型放在models/目录，避免不同项目的依赖互相干扰。

2.3 对生成结果的质量检验标准

拿到AI生成的CAD模型，别急着夸它好看，先过一遍“实体三要素”：

• 封闭性：模型必须是封闭实体，不能有开口面，否则后续3D打印切片或有限元分析都会失败。
• 可编辑性：检查模型的建模树（Feature Tree）是否完整，能不能通过改参数生成新变体。代码生成路线天然具备，网格生成路线通常不具备。
• 尺寸准确性：抽检关键尺寸，比如孔径、中心距、厚度，对照需求描述逐项核对。

我习惯用一个简单脚本自动检查模型是不是封闭实体，算一下体积是否为正值，再用analyze.Volume()打出一个数值，和理论计算值对比，误差超过2%就打回重新生成。这个方法不花哨，但能快速筛掉一批废模型，省下大量手工检查时间。

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

3.1 一个完整可跑的text-to-CAD工作流

下面用一条项目实操的全流程来演示text-to-CAD怎么落地。环境是Windows 11 + Python 3.10 + CadQuery 2.4，我用Zoo的Text-to-CAD在线版和本地CadQuery两段式完成。

先看需求描述写法。我的目标是一个电机安装支架，描述写成：

“一块矩形底板，长120mm，宽80mm，厚10mm。底板四个角各有一个直径8mm的通孔，孔圆心离边缘12mm。底板中间竖起一块高60mm的垂直板，厚8mm，宽60mm，与底板长边方向垂直。垂直板顶部有一个直径30mm的半圆缺口，朝上开口。”

这段描述里每一个数字都有明确指向，生成后的模型基本就是按图施工。然后把描述输入在线工具，生成CadQuery代码。原始代码有语法问题，但我确认“改参数就能出模型”这个核心成立。

实际运行中还需要补一步：把AI生成的代码放进cq-editor里可视化预览。这个过程就像在Fusion 360里看建模步骤回放，能看到底板的拉伸、打孔、竖板成型、半圆缺口的切割顺序。看到没有报错、模型形态符合预期，再导出STEP文件。

导出STEP文件后，流程并没有结束。STEP文件导入SolidWorks验证B-rep质量，检查有没有破面、干涉、最小厚度不足之类的问题。我试过AI生成的模型在视觉上一切正常，但导入SolidWorks后报“不能识别特征”，原因在于生成的KP（几何拓扑）里有些边线重复，手动修复后才恢复实体状态。

3.2 尺寸标注策略与倒角顺序的经验

CAD建模里有一类问题是生成代码最容易踩的：特征执行的先后顺序。倒角、圆角这类操作必须放在切削特征之后、阵列之后、镜像之后。如果AI生成的代码先把所有边都倒了圆角，再做阵列，那么阵列出来的新实例不会继承圆角特征，或者直接报错。

解决办法是修改代码顺序：先做基础体（拉伸、旋转）、再做特征操作（打孔、开槽、切除）、最后做过渡操作（倒角、圆角、螺纹修饰）。这个顺序是人类工程师的直觉建模顺序，也是CadQuery代码能稳定执行的最小约束。

尺寸标注策略上，建议不要用“薄板”“中等大小”这类定性词，全部换成精确数值。AI生成代码时，你给的数值越具体，它生成的参数就越有依据。如果没有明确指定，它默认的数值往往来自训练数据里的常见尺寸，比如“支架”默认10mm厚，“法兰”默认4个孔，“轴承座”默认孔径10mm，这些默认值不一定符合你的需求。

3.3 从脚本到实物的导出与格式选择

生成模型最终要做的事情无外乎两件：加工或者仿真。这两个方向对导出格式的要求不同。

如果目标是3D打印，导出STL格式即可。切片软件接受的是三角网格，CadQuery内部先把B-rep实体网格化，再导出STL。注意网格精度设置，导出时弦高误差（tolerance）设置得太大会出现表面台阶，设置得太小会导致文件巨大，切片还卡顿。一般机械零件0.05mm的弦高误差足够，外观曲面件建议0.01mm。

如果目标是CNC加工或模具设计，导出STEP格式。STEP是B-rep实体模型，保留精确几何和拓扑，CAM软件可以直接选面、选边、定义加工策略。如果目标是仿真分析，建议保留CadQuery代码生成IGES或STEP，导入ANSYS、Abaqus时不会丢几何特征。

还有一个格式选择很容易被忽略：导出的文件名最好体现版本和参数。工作经验越久越明白文件管理的重要性，我习惯命名成motor_mount_v1_120x80x10.step，这样即使生成多次版本，也能快速找到想要的参数组合，不用每次打开模型看属性。

3.4 用本地脚本批量生成系列化零件

text-to-CAD真正发挥威力的场景，是批量生成系列化变体。同样一个支架，底板长度从80mm到200mm，每次间隔20mm，手动建模要建七个模型，字段参数化工程里也要逐个更新。用AI生成模板，只需要改Prompt里的三个数字。

我写过一个脚本，定义了支架的参数化模板，然后用循环生成一系列STEP文件。尺寸从80×60到200×120，孔位、板厚跟着合理缩放，全部十几个文件几分钟生成完。这个方法在非标设备设计里特别实用，用于前期方案比选，机械结构做多方案对比时可以节省大量重复劳动。

Batch生成的代码结构大致是这样：

import cadquery as cq def bracket(length, width, height, thickness=10, hole_d=8): base = ( cq.Workplane("XY") .box(length, width, thickness) ) # 在四角生成通孔 for x_sign in (-1, 1): for y_sign in (-1, 1): base = base.faces(">Z").workplane().center( x_sign * (length/2-12), y_sign * (width/2-12) ).hole(hole_d) vertical = ( cq.Workplane("XZ") .center(0, thickness/2) .box(60, height, 8) ) return base.union(vertical) for w in [80, 100, 120, 140, 160]: result = bracket(w, 80, 60) cq.exporters.export(result, f"bracket_{w}x80.step")

这段代码只需改循环里的w值，就能生成不同宽度的支架，而且每个生成结果都自动保持四角孔位、板厚和竖板尺寸的相对关系。这样生成的模型，设计变更之后的逻辑一致性比手工建模强得多。

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

4.1 生成代码执行报错的排查路线

text-to-CAD生成代码最让人头疼的问题就是“跑不起来”。我把踩过的坑整理成一套排查顺序，新项目遇到报错，按顺序走一遍基本都解决。

第一查依赖版本。确认本地CadQuery版本和模型训练时一致或接近，否则新API调用旧库直接报AttributeError。解决方法是固定库版本，或写一个版本探测脚本检查核心方法是否存在。

第二查函数调用。检查代码里是否调用了nothing()、extrudeTo()这类不存在的方法，这是大模型的典型幻觉。删除或替换为正确方法名，比如用extrude()替代。用静态搜索方式直接定位所有疑似未定义函数。

第三查对象类型。CadQuery里很多操作依赖Workplane对象和Face对象的正确衔接。AI代码偶尔会直接对Solid调用faces()，而正确做法是先通过workplane()获取平面再操作。这类问题从报错信息里看是AttributeError，本质上就是类型不匹配。

第四查参数类型。比如hole(8)要的是数字，AI可能生成字符串"8"，代码不崩但尺寸不对。养成生成后抽取几个关键数值打印出来看一眼的习惯。

4.2 模型生成出来“像”但“不能用”的典型场景

还有一类问题更隐蔽：模型长得对，但用不了。遇到过三次这种坑，现在总结出三类高频问题。

第一类是实体不封闭。代码生成的模型看起来有厚度的壳体，但实际上是一堆面的组合，没有形成Volume。检查方法用CadQuery把模型的Volume()打出来，如果是0就说明没封闭。这类问题往往出现在AI尝试用多个面拼合生成实体的时候，没有执行最终的combine()或union()操作。

第二类是模型单位错误。全部尺寸用了默认的inch，STEP导入加工软件后整套尺寸被放大25.4倍。这个得在Prompt声明单位，并在导出前检查生成代码的单位相关参数。

第三类是隐藏干涉。模型单独看没毛病，但装配到其他零件里会发生干涉。AI在生成零件时不会考虑装配关系，它在真空里设计。所以生成零件务必导入完整装配体里做干涉分析，不要信任单件视觉检视。

4.3 提示词写法的常见误区与修正对照

给AI写CAD描述和跟工程师沟通一样，要素齐全、无歧义。下面是我改过的几个典型错误写法：

在此基础上再补一句约束条件，比如“孔是通孔不是盲孔”“倒角半径1mm”“所有尺寸单位默认为毫米”。这些细节直接决定生成结果能不能直接用。

4.4 本地化部署与算力经验

在线版text-to-CAD用起来方便，但要嵌入企业内部流程，本地化部署迟早要考虑。代码生成类模型，硬件要求并不夸张，一个消费级的RTX 4080都能跑混合精度推理。深度生成类模型（特别是扩散模型系列的）则更吃显存，推荐至少24GB显存起步，32GB以上会更从容。

部署上建议用Ollama或vLLM这类工具做推理服务封装，再写一个调度层负责“接收文本→调用模型→返回脚本→执行脚本→输出模型”。整个链路并不复杂，真正花时间的是模型调优，针对特定类型零件微调Prompt模板、专用的LoRA权重，效果会明显优于开箱即用的通用模型。

我的实操体会是，本地部署的文本生成质量受Prompt影响极大，建议在系统层面建立一个Prompt模板库。常见的“法兰盘”“轴承座”“导轨支架”分别固化模板，把尺寸替换成变量。这样即使接入新的模型，模板复用也能保证生成质量基本稳定。

5. 一些想说的经验心得

text-to-CAD现在走到什么程度，一句话总结：做概念设计、非标件快速建模、结构方案比选，已经够用了；做精密模具、批量生产的最终零件，还有很长的路要走。它最大的价值不是“替代工程师”，而是把低创造性的重复劳动压缩到极限，让人的精力真正集中在“这个零件要干什么”上，而不是“怎么画出这个零件”。

从我实际跑的几十个例子里看，代码生成路线的成功率比纯网格生成高出一大截，原因是它能用参数精确控制尺寸，生成出来就是可编辑的B-rep实体。这也让我对未来的方向越来越确定：text-to-CAD不会取代传统CAD软件，但它会让CAD软件的使用门槛大幅降低——就像拍照手机没有取代单反，却让所有人都能随时记录画面一样。以后设计软件里那个命令行，可能真的是用来聊天的。