企业官网建设流程全解析

上个月有位做机械设计的读者私信我，说他让AI从一段文字生成一个法兰盘模型，打开一看很像回事，结果导入SolidWorks一量，孔距差了0.4毫米，螺栓根本穿不过去。这个例子特别能说明今天的text-to-cad究竟发展到了什么程度：从"能生成"到"能交付"之间，还隔着一段需要人认真对待的距离。

这篇文章想聊聊我这两年在文本生成CAD这条路上反复试验的积累，包括它背后的技术原理、主流工具的真实水平、一条可以直接上手的完整实操流程，以及那些文档里不会写、但实际做项目一定会撞上的坑。适合正在评估AI辅助建模工具的设计师和工程师，也适合想搞清楚"文本到底怎么变成三维模型"的程序员。

1. 为什么"文本生CAD"能落地：先看清这条技术路线的本质

1.1 CAD模型本质上是一段"带约束的几何叙事"

很多人第一次接触text-to-cad时有个误解，觉得它是"让AI从一个描述生成一个3D模型文件"。这个理解不算错，但它会把你的预期带到沟里去。因为现实中CAD模型根本不是一堆三角形面片，而是一整套由参数、约束、特征、历史树组成的逻辑结构。

举一个最简单的例子：一块钢板上有一个直径10毫米的孔。在Mesh模型（比如STL）里，这个孔表现为几十个三角形围成的圆形凹陷，删掉任何一个顶点都可能破坏整个表面。但在真正的CAD模型里，这个孔储存的是"圆心坐标 + 直径 + 深度 + 通孔/盲孔"这几个参数，修改直径，孔就变大，整个特征树依然健康。

这种结构性和大语言模型擅长的"代码生成"天然同构。你可以把参数化CAD模型想象成一份菜谱，而Mesh模型是端上桌的那盘菜。菜谱记录了步骤、配比和火候，哪一步不对都能精确调整；而菜一旦盛盘，想改咸淡就只能从头再来。Text-to-CAD要做的事情，正是让AI学会写菜谱，而不是学着端盘子。

1.2 三条技术路线的真实状况：生成网格、生成代码、生成约束

目前行业内做文本到CAD，主流的大方向分成三类。我把它们的核心差异和现状整理成了一张表：

第一条路线最"性感"，因为扩散模型在图像生成上的成功可以直接迁移，网络上那些"文本生成三维模型"的Demo多数属于这一类。但问题也很直接：它能生成一个"看起来对的齿轮"，却生成不了一个"能啮合传动的齿轮"。网格模型的几何精度、流形合法性、特征语义都很难保证，用于数字孪生或视觉预览问题不大，往加工图里走就不行了。

第二条路线是目前落地的主力。它把问题从"生成三维数据"转化为"生成代码"，让LLM发挥它最擅长的能力。生成的CAD脚本交给内核执行，得到的是实打实的B-Rep实体模型，可以继续用传统CAD工具编辑、标注、导出工程图。这也是我日常用最多的方式。

第三条路线最符合CAD的底层逻辑，因为所有现代CAD的内核本质上都是"草图 + 约束求解器 + 特征历史树"。理论上，如果能直接生成草图约束序列，再加特征操作序列，产出的模型质量会远超脚本生成。但这条路对模型的推理能力、对工程语法的理解要求太高，目前只看到论文级别的尝试，离产品化还远。

1.3 为什么代码生成路线是当下最稳的"抄近路"

从工程化角度讲，代码生成路线有三个压倒性优势。

第一，大语言模型对代码的建模能力远超对三维几何的建模能力。你让GPT写一段Python排序算法，它写得又快又对；你让它直接预测三维空间里两万个顶点的坐标，它基本会在尺寸和拓扑上出问题。脚本生成把三维问题降维成了二维的字符序列问题，LLM的训练数据里又有海量的开源CAD脚本，互相之间配合得很好。

第二，执行链路是可验证、可迭代的。AI生成代码跑挂了，编译错误会告诉你；渲染出来形状不对，你能直接在视觉上对比"想要的"和"生成的"差在哪里。然后基于报错信息让AI自我修复，这形成了一个天然的闭环。而端到端生成网格的方法，模型一旦生成，错了很难定位是哪里错的，更没法自动修。

第三，产出的模型符合工程习惯。CAD脚本能被参数化、能被版本管理、能进自动化流程。对一个工程团队来说，"AI生成的设计"必须能融入现有的PLM/PDM体系才有价值，纯图形化的输出很难做到这一点。这也是为什么我说，如果你想认真用text-to-cad做点事，而不是玩票，那就该把精力放在脚本化CAD这个点上。

2. 从论文到工具：现在的Text-to-CAD生态到底有哪些可用选项

2.1 最常见的架构：LLM + 参数化建模库

你可能会好奇，市场上那些号称"文本生成CAD"的工具，内部到底是怎么搭起来的？我拆过几个开源项目和商业工具的底层链路，发现绝大部分都跑不出下面这个架构：

自然语言提示词 → LLM（生成建模脚本） → 参数化建模库执行 → 三维实体模型 → 导出STEP/STL

这里的参数化建模库，常见的是CadQuery、build123d、OpenSCAD，以及部分用FreeCAD的Python API做后端的方案。我个人的主力组合是CadQuery和build123d，因为它们都是纯Python，API设计接近现代代码风格，和LLM的配合默契度很高。

OpenSCAD则是另一种风格，用函数式脚本描述几何体，语法像C语言，对生成齿轮、螺纹这类规则特征特别友好。Zoo早期推出的文本转OpenSCAD工具，就是让LLM直接生成OpenSCAD脚本，效果相当不错——因为OpenSCAD的语法高度结构化，LLM很难生成"语法上非法"的代码，十次里有八次能直接跑出形状。

2.2 学术界的铺垫：Text2CAD数据集为什么重要

2024年前后，MIT的研究者放出了Text2CAD这项工作，我当时专门花了一个周末认真读了一遍。它的核心贡献并不是"某个惊艳的Demo"，而是提供了一个大规模的高质量数据集：把CAD建模操作序列（从草图到拉伸、倒角、阵列）和对应的自然语言描述对齐起来。

这个数据集的价值怎么强调都不为过。因为在此之前，文本到CAD的研究最大瓶颈就是"没有配对的训练数据"。自然语言描述很容易找，CAD操作序列也不难找，但要把"在法兰盘边缘均匀分布六个螺栓孔"这句话和一段具体的CadQuery脚本一一对应，是极其昂贵的人工标注活。Text2CAD把这个问题初步解决了，后续不少商业工具的能力提升，很大程度上都建立在类似数据的支撑上。

尤其值得留意的是，这项工作把文本分成了"初学者级别"和"专家级别"两种描述方式。初学者描述是"在板上打几个孔"，专家描述是"以圆心为基准，在直径60毫米的螺栓圆上均布4个直径8毫米的孔"。这两者对模型能力的训练要求完全不同，也侧面印证了我在实操中的一个体会——同样一句话，表达精度不同，生成质量天差地别。

2.3 选工具之前，先想清楚要"模型"还是"图纸"

我在不少社群看到大家纠结"到底该用哪个AI建模工具"，但很少人先问自己：我拿生成结果去干什么？

这个问题的答案直接决定工具选型。如果你要的是做产品概念渲染、游戏资产、视觉预览，那端到端的网格生成工具效率更高，关键词丢进去几十秒就出模型，纹理和形状也很有表现力。但如果你要的是能加工的零件、能出工程图的模型、能进入装配体做干涉检查的实体，就必须走脚本化CAD路线。

这里我给一个比较现实的建议：如果你所在的公司已经深度使用SolidWorks或NX这类重型CAD，不要指望text-to-cad直接取代它们，而应该把它定位为"前期方案生成器"。让AI快速产出几个特征合理的初始模型，再由工程师在专业软件里细化。这个定位下，你根本不太需要纠结"哪个工具最强"，只需选择那个能稳定导出STEP格式、能和现有软件顺畅配合的方案。

3. 从零跑通一个文本到CAD的完整流程

3.1 环境准备与提示词设计的底层逻辑

纸上谈兵再多，不如把一条流程真正跑通。先说环境。我默认你有一点Python基础，如果完全没接触过，花二十分钟装一下Anaconda，剩下的跟着做就行。

# 建议使用Python 3.10以上版本 pip install cadquery build123d

CadQuery的文档站有完整的安装指南，macOS、Windows、Linux都支持。装完之后，建议用cq-editor这个可视化工具做调试，它能实时预览生成的模型，旋转、缩放、查看特征树，比终端里干跑代码直观得多。

环境准备好之后，最关键的是提示词设计。很多人试了几次就下结论说"AI建模不行"，多半是死在提示词上。我总结了一个三层写法：

• 功能层：这个零件是干什么用的，使用场景是什么，有哪些配合关系。
• 几何层：主体形状怎么构成，有哪些孔、槽、凸台、圆角，空间位置关系如何。
• 约束层：关键尺寸、公差、表面处理、螺纹规格、加工工艺要求。

我强烈建议在提示词里尽量用"工程师的语言"，而不是"日常生活的语言"。你输入的文本，每一句都在影响最终的模型质量。

3.2 先跑一个最简单的例子：生成一块带沉头孔的安装板

我们用一个典型场景来实操：生成一块四角带安装孔、中间带沉头孔的矩形安装板。

先看提示词怎么组织。我的第一版提示词会这么写：

使用CadQuery生成一个矩形安装板： 1. 外形尺寸：长120毫米，宽80毫米，厚6毫米 2. 四个角上各有一个直径6.5毫米的通孔，孔心距边缘10毫米 3. 中心有一个直径20毫米的沉头孔，沉头直径30毫米，沉头深度3毫米 4. 所有锐边倒R2圆角 5. 以底面为定位基准，孔的轴线垂直于底面

这个提示词的特点是把尺寸、数量、位置、方向全部量化。你可以直接把它丢给Claude、GPT-4这类支持代码生成的大模型，得到类似这样的CadQuery代码：

import cadquery as cq plate = ( cq.Workplane("XY") .box(120, 80, 6) .edges().fillet(2) .faces(">Z") .workplane() .pushPoints([(-45, -25), (45, -25), (-45, 25), (45, 25)]) .hole(6.5) .faces(">Z") .workplane() .hole(20, 3) # 先钻直径20的沉头孔，深3毫米 )

把这段代码保存成plate.py，用cq-editor打开，你会看到一块完整的安装板出现在预览窗口。然后加两行代码导出STEP文件：

cq.exporters.export(plate, "plate.step") cq.exporters.export(plate, "plate.stl")

走到这一步，你就已经完成了第一次完整的text-to-cad闭环：从自然语言到CAD实体模型，再到通用的三维交换文件。

3.3 从能生成到能用：一次典型迭代的全过程

上面这个例子一次就成功，看起来很简单，但真实项目里几乎不可能这么顺利。我拿一个真实的迭代过程给你做参考。

有一次我需要一个带轮毂的皮带轮，提示词写的是"生成一个直径150毫米的V带轮，轮毂直径40毫米，中心孔径20毫米，带轮槽宽12毫米，深度10毫米"。结果模型生成之后，三个明显的问题：

问题一：槽的方向反了。我预想的V带槽应该在轮缘外圆周上，AI生成的槽却开在了一个端面上。排查过程是：先检查代码里工作面（workplane）的选择，发现AI用了默认的端面作为草图平面，而正确做法是先circle(75)拉伸出一个圆柱，再faces(">Z")选择顶面创建槽的草图路径。修正的方法是给提示词补充"槽位于外圆周的中间位置，绕圆周旋转一圈"。

问题二：中心孔的深度没有贯穿。AI默认生成盲孔，而工程上这个孔必须是通孔。这个问题的修复很典型，就是把hole(20)改成hole(20, None)，让孔贯穿整个轮毂。我在提示词里特意补了"贯穿"两个字，后续生成就不再有这个问题。

问题三：没有考虑加工圆角。第一个版本在轮毂和辐板的连接处形成了尖角，这个特征在铸造件里是不合理的，容易产生应力集中。我让AI在连接处添加R3的过渡圆角，代码层面是在相应边缘上应用fillet(3)。

整整经历了三轮迭代，这个皮带轮才算达到"能进加工厂"的状态。你把这个过程代入日常的建模工作就会发现，跟传统手动建模的迭代方式完全一样，只是每轮迭代的成本从"重新画一遍图"变成了"改几句提示词再生成一次"，这个效率差距非常可观。

4. 实际使用中踩过的坑：这些细节没人写进文档

4.1 单位与精度：一个"理所当然"造成的废件

谈CadQuery和文本生CAD，必须聊单位问题。CadQuery默认使用毫米，这本身没问题，但当你的下游软件默认使用英寸时，问题就来了。我第一次把一个AI生成的支架模型导入Fusion 360，尺寸整体大了25.4倍，所有配合全部失效。

这个坑的特点是：它不报错，只会静默地产生错误结果。你看到模型形状完全正常，甚至渲染效果都无可挑剔，直到拿去对接其他设备才发现尺寸全错了。

我的经验是，在提示词里明确写出"所有尺寸均以毫米为单位"，并在导出后立刻做一次尺寸验证。最简单的方法是用cadquery查询边界框：

bb = plate.val().BoundingBox() print(f"长: {bb.xlen} 宽: {bb.ylen} 高: {bb.zlen}")

确认数值和你预期一致再往下走。这个习惯能帮你省掉后面所有的对接灾难。

4.2 提示词里的"语义颗粒度"决定成败

我见过太多人把提示词写成"生成一个好看的齿轮""做一个加强筋多一些的支架"。这种描述充满了"语义颗粒度"过粗的问题。AI不是猜不到你的意思，而是工程世界里"好看"和"能加工"之间的距离太远了。

同样描述一个孔，"打一个孔"和"在坐标(30, 20)的位置打一个直径8毫米的通孔"在生成效果上是两种完全不同的东西。前者AI可能默认给你一个5毫米的盲孔，位置还可能随缘；后者则能一步到位。越是需要精确控制的特征，越要用数字说话，而不是用形容词。这在提示词工程里叫"可测量约束"。

另外注意一个很有意思的现象：同一句话在描述"目标"和描述"非目标"时，效果也完全不一样。比如"不要有尖角"，AI经常忽略"不要"；但如果你改写为"所有可见边缘倒圆角R1"，它执行得异常精确。在LLM的世界里，正面指令的执行力远高于负面指令。

4.3 文件格式与下游工具的兼容性

文本生成CAD最后一步是导出模型给下游用，格式选错就前功尽弃。我从实际使用角度把常见格式的适配场景列一下：

我踩过的最典型的一个坑是：AI生成的CadQuery STEP文件在导入某些老版本CAD软件时破面，显示为"非流形边"或"实体无效"。原因往往是模型里存在极小间隙或退化面，虽然数值上小于0.001毫米，肉眼完全看不见，但内核之间容差处理不同，导入时就会炸开。这类问题没有百分百的解决方法，但提前在CadQuery里对模型执行fix()或使用cq.occ_utils.cleanup做几何清理，能大幅减少导入失败的几率。

4.4 LLM的"幻觉"与几何合法性

这是目前最难防的一个坑，也最需要警惕。大模型为了"迎合"你，有可能生成一份看似完整的代码，但其中某一步生成了自相交几何、零厚度的面、或者根本不可实体化的拓扑。尤其在复杂零件上，例如一个包含多个放样、扫掠特征的模型，AI很容易在某个步骤上偷懒，生成一个概念上成立、几何上非法的结果。

排查的方法并不复杂，核心是让CAD内核自己对模型做一次"体检"——检查模型是否为有效实体（isValid()）、边界表示是否闭合（isClosed()）、体积是否为正数。任何一项亮红灯，直接返回提示词里要求重做。我在实际项目里通常会在提示词里附加一句："生成后必须调用validate()检查模型，如果无效请自行修复并重新生成。"这句话能显著减少睁眼瞎式交付。

5. 这套流程的边界在哪：我对后续方向的一些判断

5.1 当前工具的适用边界

坦诚说，text-to-cad目前还远不是万能的。以我自己的使用体验，它对以下几类任务已经足够好用：

• 规则机械零件：法兰、支架、安装板、轴套、齿轮，这类特征清晰、尺寸明确、规律性强的零件，AI生成质量和效率远超从头手绘。
• 标准件变体：基于已有的参数化模板，让AI帮你调整尺寸、增加孔位、改变倒角，这属于"锦上添花"的用法，效果非常稳定。
• 早期概念验证：产品还没定型时，快速生成若干个结构方案供讨论，速度比手动建模快一到两个数量级。

但以下这些场景，目前还是要谨慎：

• 复杂曲面造型：汽车A级曲面、消费电子外壳那种需要高光顺滑度的曲面，AI生成的几何很难达到工业级质量。
• 大型装配体：单零件生成已经比较成熟，但一个包含几十上百个零件、带配合约束和运动关系的装配体，目前还没有任何工具能一键生成。
• 高精度配合结构：涉及微米级公差、特殊表面处理的零件，AI生成后仍然需要人工仔细调整。

5.2 从"生成一个零件"到"生成一个装配体"的难点

如果说接下来半年到一年，这个领域最值得期待的技术突破是什么，我认为是装配体级别的生成。为什么难？因为它要求AI在生成每个零件时，脑子里得装着一整张"零件关系网"——这个孔是给哪个螺栓留的，这个凸台和对面哪个凹槽配合，这里的间隙要给到多少。

目前的大模型在处理多零件协作时，经常会犯一种典型错误：单看A零件没问题，单看B零件也没问题，但A和B装配到一起，干涉了0.5毫米。这种"局部正确、全局错误"的情况，恰恰反映了模型缺乏空间关系和工程配合的训练数据。我个人的判断是，至少在文本驱动的产品成熟之前，人工校验装配关系这个环节无法被替代。

5.3 我的个人工作流配置，供你参考

说了这么多，最后分享一套我目前正在用的配置，不一定适合所有人，但应该能帮你避开一些初期探索的弯路。

• 建模库：主力用CadQuery，遇到复杂曲面时会切到build123d，它支持B-Rep操作更灵活，文档也更新。
• LLM：日常用Claude和GPT-4交替跑，代码生成质量都在线。提示词框架保持一致，谁效果好就用谁。
• 执行和验证：本地建了一个Python脚本管线，输入提示词，自动调LLM生成代码、执行、跑合法性检查、导出STEP/STL，全程不用打开图形界面。有问题时再打开cq-editor做可视化调试。
• 模板沉淀：每个跑通的零件类型，我会把提示词模板存下来。下次遇到类似的零件，只需要改尺寸参数，生成成功率明显高于完全从零写提示词。这一点强烈建议你也试试——你积累的不是"AI技巧"，而是可复用的工程资产。

最后再给一条小技巧：如果你打算把text-to-cad纳入日常工具链，不妨从自己手头最简单的一个五金件开始，一步步把提示词打磨到"零修改即可生成正确模型"的程度。这个过程会逼你理解参数化建模的本质，也会让你更清楚AI擅长什么、不擅长什么。真到了那天，你这套流程的含金量，会比任何网上的评测都高得多。