企业官网建设流程全解析

1. 一句话变成三维模型：text-to-cad到底在解决什么问题

我前阵子接了个活儿，客户发过来一段产品需求描述，就一句话：“一个直径40mm的圆形法兰盘，带4个均布安装孔，孔中心距30mm，厚度5mm。”放在以前，这句话我得在建模软件里拆成视图、草图、拉伸、打孔、阵列好几个步骤，折腾十分钟起步。而这次，我只是把这句话原样粘贴进工具里，一分钟后就拿到了一份可以继续编辑的STEP模型。这个工作流背后的技术方向，就是这两年设计圈讨论度极高的text-to-cad。

text-to-cad，字面意思就是“从文字到CAD模型”，属于人工智能生成设计（AI-Driven Generative Design）里最贴近工程落地的分支之一。它把自然语言作为输入，目标是自动输出可编辑、可加工、可仿真的参数化CAD模型，而不是一张示意图。这里的关键词是“CAD模型”，这意味着输出的东西不只是好看的三维网格，而是带特征树、带尺寸约束、能回到SolidWorks或Fusion 360里继续改的工程文件。这个区别非常重要，后面我会反复提到。

它能解决什么问题？最直接的一点是消灭“需求翻译损耗”。设计沟通里大量时间浪费在理解需求、确认尺寸、反复修改草图，text-to-cad把这段过程大幅压缩。另外，对于非专业建模人员，比如采购、销售、工艺工程师，他们能直接通过文字描述生成一个初步三维方案，极大地降低建模门槛。对于专业设计师，它更适合用来做前期概念比选和批量变体设计——同一句话改几个参数，瞬间生成一系列方案。

这套技术适合谁来参考？如果你是结构设计、产品开发、非标自动化相关从业者，或者正在做AI工具产品设计、设计自动化集成，这篇文章值得你花十分钟读完。我会从技术原理讲到实操落地，再到工具选型和我踩过的坑，尽量把“能用”和“好用”之间的距离讲透。

2. 技术路线拆解：文本到底是怎么变成三维模型的

2.1 两条技术主线：神经重建与程序化参数建模

目前text-to-cad的实现路线，业界基本分成两条大方向，理解清楚这两条路，你才能判断什么场景下该用什么工具。

第一条叫“神经重建”，代表项目是OpenAI开源的Shap-E和Point-E。它的思路是：把文字描述交给文本编码器，再通过扩散模型或隐式神经场（比如NeRF）直接生成三维几何，最后提取成网格导出。这条路的好处是“什么形状都能生成”，不局限于规则几何，用来做概念造型、游戏资产、快速可视化非常合适。代价是精度差、拓扑乱、没有参数化特征，导出的网格往往需要大量修复，几乎没法直接进工程流程——你见过哪个正经法兰盘的STEP文件里带着几十万三角面片的？

第二条叫“程序化参数建模”，也就是文本生成代码，由代码驱动CAD内核建模。这个思路更贴近工程师的思维方式：LLM负责理解需求、抽参数，然后生成一段CadQuery、OpenSCAD或Python脚本，脚本调用几何内核真正把模型建出来。这条路生成的模型天然带特征、带参数、带建模过程，导出的STEP文件干净漂亮，回到任何主流CAD软件里都能继续编辑。它的问题也很明显：自由度受限，适合规则几何和机械件，遇到自由曲面就抓瞎。

我个人的判断很明确：如果是制造业和机械设计场景，程序化参数建模是唯一靠谱的方向。神经重建适合“看一眼”的场景，参数建模适合“用起来”的场景。现在很多工具是两条路混着走，但内核逻辑必须分清楚，否则你在选型时很容易被宣传话术带偏。

2.2 LLM在中枢链路里扮演什么角色

不管走哪条技术路线，大语言模型都是整个text-to-cad链路的中枢。它的工作可以拆成三层理解。

第一层是意图理解。用户说“做一个安装支架”，模型得知道这是L型、U型还是钣金折弯件，得能补全描述里没说的隐含信息。这个环节非常考验模型的工程常识，通用模型和经过CAD语料微调的模型，在这层的表现差距巨大。第二层是参数抽取。模型要从自由文本里提取数值和关系：“直径40mm”“4个均布孔”“中心距30mm”这些关键信息一个都不能漏，还得处理单位换算、公差不明确等细节问题。第三层是约束推理。比如4个孔要均布，那角度间隔是90度；中心距30mm，那分布圆半径就是15mm。这些几何逻辑关系如果模型理解不到位，生成的代码就会算出错误的位置。

我测试过几个模型，发现一个规律：通用聊天大模型能写好“翻译型”任务，也就是把文字描述翻译成代码注释，但真正决定成败的是后面两步——参数抽取和约束推理。你可以让模型告诉你它打算怎么建模，通常头头是道，但只要有一个尺寸理解错位，整个模型就是废的。所以现在做得好的text-to-cad工具，不会只靠一个大模型裸奔，而是在LLM外面套了一层规则引擎或者校验环节，专门盯着参数和几何约束。

2.3 中间表示：为什么“文本→代码→几何”这条路最稳

想要理解text-to-cad的架构，关键要理解“中间表示”这个概念。自然语言不能直接变成几何体，中间必须有一个桥梁。神经重建路线的中间表示是隐函数或者点云，参数建模路线的中间表示是程序代码。代码这个中间表示有巨大的工程优势。

第一，代码可读。生成错了，打开代码一看就知道是哪一行尺寸写错了，而不是对着一个破损网格发呆。第二，代码可改。想要改厚度，直接改数字重新运行即可，不像网格模型得重新生成。第三，代码可复用。一个底座的建模函数改几个参数就能变成另一种规格，这正好是工程设计的核心诉求。第四，代码天然可审计。每一步用了什么操作、什么参数都记录在案，对于制造业的质量追溯来说，这个价值没法衡量。

所以我的建议很直接：如果你准备在自己的业务里引入text-to-cad，优先找“生成代码”方案，哪怕它看起来不如神经重建那种一键出模型炫酷。工程世界里，“能改”比“能生成”重要得多。

3. 实操流程：从零跑通一个text-to-cad建模任务

3.1 环境准备与工具选型

纸上谈兵没意思，我们直接动手。我推荐一套目前效率最高、成本最低、完全可落的实操组合：Python环境 + CadQuery库 + 任一可编程调用的LLM接口。CadQuery是基于Python的参数化CAD库，它不依赖图形界面，直接通过代码描述几何特征，能导出STEP、STL、DXF等主流格式，和SolidWorks的剖切、拉伸、打孔思路几乎一一对应，非常适合接在LLM后面当“建模执行器”。

环境安装很简单，国内网络环境下也能顺利装完：

pip install cadquery jupyter-cadquery

装完之后在终端输入jupyter notebook，新建一个Python3笔记本，CadQuery的3D预览能力是通过jupyter-cadquery插件实现的，运行代码块后可以直接在输出区域看到三维模型，支持旋转缩放，体验上已经接近轻量CAD软件了。

这里要提醒一句：CadQuery 2.x版本的API和旧版有一些差异，网上很多教程还是1.x的写法，直接复制容易报错。如果遇到Workplane相关报错，优先检查CadQuery版本，这个坑我在后面问题专题还会展开说。

3.2 写一段合格的文本描述并生成模型

现在我们来跑一个真实案例，就用开头那个法兰盘需求。首先，你需要把提示词组织好，这里有个小小的格式技巧：

生成CadQuery代码： - 形状：圆形法兰盘 - 直径：40mm - 厚度：5mm - 特征：4个均布安装孔，孔径8mm - 孔位置：中心距30mm，均布在圆周上 - 导出STEP格式

注意描述密度。太简陋了模型容易自由发挥，太冗长了又容易抓不住重点。核心是：几何形状、关键尺寸、特征位置关系、导出格式，这四类信息必须齐全。

我实测让一个主流大模型根据这段描述生成代码，它给出的核心建模代码长这样：

import cadquery as cq result = ( cq.Workplane("XY") .circle(40 / 2) .extrude(5) .faces(">Z") .workplane() .pushPoints([(15, 0), (0, 15), (-15, 0), (0, -15)]) .hole(8) ) cq.exporters.export(result, "flange.step")

这段代码逻辑非常清晰：在XY平面画一个半径20的圆，拉伸5mm；然后把工作平面移到顶面，在(15,0)、(0,15)、(-15,0)、(0,-15)四个位置打直径8mm的孔。4个孔到圆心的距离都是15mm，也就是中心距30mm的分布圆半径，完全符合需求。

如果你要的是沿圆周均匀分布的孔——比如6个或者8个——让模型生成pushPoints坐标列表就不太优雅了。更聪明的做法是让模型用极坐标循环计算，像我下面这样：

import cadquery as cq import math hole_radius = 15 # 分布圆半径 num_holes = 6 hole_dia = 8 points = [ (hole_radius * math.cos(math.radians(360 / num_holes * i)), hole_radius * math.sin(math.radians(360 / num_holes * i))) for i in range(num_holes) ] result = ( cq.Workplane("XY") .circle(40 / 2) .extrude(5) .faces(">Z") .workplane() .pushPoints(points) .hole(hole_dia) ) cq.exporters.export(result, "flange_6holes.step")

这个例子想说明的是：当你看LLM生成的代码时，不要只看结果对不对，还要看它的实现思路是否可扩展。能循环就不手写坐标，能用参数就不写死数值，这是判断生成代码质量的重要标准。

3.3 从代码到可交付模型：导出与后处理

模型生成之后，导出环节也有一些讲究。CadQuery支持多种导出格式，选哪种取决于交付对象：

如果文档要求“导出STEP格式”，是因为STEP文件携带完整的几何拓扑和边界表示信息，几乎所有主流CAD软件（SolidWorks、Creo、NX、Fusion 360）都能无损打开，适合进入正式的工程流程。如果你要拿去3D打印，应该导出STL格式——STL是三角形网格，打印切片软件只认这个。但要注意，CadQuery导出STL时可以设置线性公差，也就是弦高误差。我通常设成0.01mm，模型表面足够光滑，文件体积也不至于爆炸。导出命令长这样：

cq.exporters.export(result, "flange.stl", tolerance=0.01, angularTolerance=0.1)

另外还有一个容易被忽略的点：单位。CadQuery默认使用毫米，但很多进口软件和3D打印切片器默认使用英寸或厘米。导出给外部协作方之前，一定确认对方使用的单位制，否则尺寸差25.4倍，图纸直接报废。别问我怎么知道的，问就是加工厂打过电话来骂过。

4. 工具横向对比与选型建议

4.1 开源工具和研究项目：哪几个值得真正上手

text-to-cad赛道上项目更新很快，我按实际可用程度分个档。

第一梯队是CadQuery和OpenSCAD这类参数化建模库，配合任意LLM使用。它们不是开箱即用的text-to-cad产品，但作为“建模执行器”极其稳定，可控性和可扩展性最强，适合工程师自己搭建工作流。

第二梯队是开箱即用的生成项目。OpenAI的Shap-E可以从文本直接生成三维网格，安装简单，效果直观，社区反馈也活跃，但正如我前面说的，它生成的是网格，不带参数化特征，适合做概念可视化，不适合进生产流程。Point-E生成的是点云，需要额外做曲面重建，工程可用度更低一些。学术界还有一些工作，比如Text2CAD（通过LLM生成CAD命令序列）和CAD-GPT（多模态CAD生成方案），这些项目在论文里展示了很好的方向感，但代码成熟度和社区维护水平参差不齐。如果你想尝鲜，可以跑通官方示例感受一下技术趋势；如果你要用于生产，建议再等等。

4.2 商用CAD软件里的AI辅助功能到底能不能打

主流CAD厂商近几年都在往AI辅助方向发力。Autodesk Fusion 360有生成式设计模块，但它更偏向拓扑优化——给定载荷和约束条件自动找最优材料分布，而不是从文字直接生成模型，使用逻辑和text-to-cad完全不同。SolidWorks推出了基于云平台的3D Creator，配合3D Creator里的AI辅助功能，可以通过文字描述辅助创建部分特征。PTC Creo也在持续迭代Creo+里的AI能力。不过说实话，这些商业化功能的自然语言建模能力目前还处于辅助定位，你可以在软件里跟它说“在这面打四个直径8mm的孔”，但你不能把整份设计需求甩给它让它全自动交付。

选型建议很直白：如果你在商业CAD生态里，先用软件内置的AI功能做辅助，没必要另外搭一套系统；如果你有批量生成、自动化流程的需求，比如要做几百个变体模型，那开源工具+LLM接口自建方案灵活度高出好几个量级。两者的关系不是替代，而是分工——商业软件负责精修和审签，自建流程负责批量和探索。

4.3 选型决策参考：按需求场景匹配工具

表格里没有绝对的好与坏，关键看你的交付物是什么。交付模型让别人继续画的，选参数化路线；交付效果图给领导汇报的，神经重建出图更快。这个道理就像选交通工具：去楼下便利店你开什么卡车呢。

5. 实战中绕不开的坑与排查技巧

5.1 描述含糊导致特征丢失或错误

我遇到过最典型的场景：用户说“做一个带孔的板子”，结果模型生成了一个平板加一个孔。听起来没毛病，但拿到工程上一看，问题一堆——孔的直径多少？板子多厚？孔是通孔还是盲孔？位置在哪里？这类问题的根源在于描述阶段的信息缺失，LLM只能从训练数据里猜最可能的意思，而“最可能”不等于“你想要的”。

解决思路有两个方向。第一是提示词结构化，让用户按照固定模板提供信息，就像我前面给的法兰盘例子。第二是在系统层做参数补全检查，对缺失的必填参数给出默认值并明示给用户确认。比如板厚没写，默认5mm，同时弹窗提醒“板厚未指定，已按5mm处理，是否需要修改”。这种机制能显著降低模型自由发挥的副作用。

5.2 尺寸精度不够：英寸毫米单位错乱和几何计算错误

尺寸问题是text-to-cad落地中最致命也最常见的问题。错一个数量级，模型尺寸差10倍，直接报废。单位错乱是重灾区，LLM的训练语料里英文内容占大头，很多工程数据使用英制单位，模型很容易在metric（公制）和imperial（英制）之间反复横跳。我的规避办法是：在提示词里强制声明“所有尺寸单位为毫米”，并且在提示词末尾加一句“请再次检查所有尺寸是否符合毫米单位”。除此之外，建议在系统层加一道校验，对生成代码里的关键数值做大数检查——直径40mm变成了400mm，一眼就能看出来不合理。

还有一类几何计算错误更有迷惑性。比如“在圆周上均布4个孔”，模型给出的坐标点x=20, y=0，x=0, y=20，x=-20, y=0，x=0, y=-20——乍一看均布没问题，但如果分布圆直径要求是30，这批点的位置就全错了。这类错误靠人肉检查效率太低，理想的做法是让LLM在生成代码的同时输出一份“建模参数表”，把几何关系列清楚，然后由程序自动校验参数表里的数值是否符合输入需求，不符合就重新生成。

5.3 模型破面、法线翻转和拓扑错误怎么处理

走神经重建路线的工具，导出的网格模型经常有法线翻转、封闭性差、破面等问题。处理这类问题有个常用的修复流程：先用网格修复库（比如trimesh）检查网格是否封闭，然后统一法线方向，再执行简化和平滑。代码思路大致是这样：

import trimesh mesh = trimesh.load("output.stl") print("水密性检查:", mesh.is_watertight) print("当前面数:", len(mesh.faces)) # 简化到目标面数 simplified = mesh.simplify_quadric_decimation(face_count=10000) # 统一法线方向 simplified.fix_normals() simplified.export("output_fixed.stl")

对于参数化路线（CadQuery生成）来说，破面发生概率低很多，拓扑也干净，因为几何内核天然保证实体闭合。但要注意特征建模顺序对结果的影响。先打孔再倒角和先倒角再打孔，最终几何可能不同——工程上的默认逻辑是先打孔后倒角，让倒角自然作用到孔口边缘。如果生成代码里顺序反了，轻则结果不符预期，重则布尔运算失败直接报错。这个细节设计师心里都有数，但LLM不一定，需要人工校对或规则检查。

5.4 常见问题速查表

这些坑没有一个是理论推演，全是实操中反复撞过的墙。我现在的习惯是建立一套固定的检查清单：尺寸范围检查、单位检查、孔位分布检查、格式检查，每条对应一个自动化校验函数。宁可校验脚本多写半小时，也不要让错误模型流到下游工序。

6. 场景落地与后续扩展

6.1 最值得优先落地的三个场景

第一个是概念方案快速比选。产品经理提需求，设计师先出三维概念，这个过程用text-to-cad可以把单个方案的生成时间从小时级压缩到分钟级。改需求也不再是噩梦，重新描述一遍就行。第二个是非标自动化设备的定制件生成。非标件种类多、数量少，每次都要从头搭模型，text-to-cad最适合这种“定义清楚但建模繁琐”的活。第三个是参数化族库的扩充。很多企业有标准件库，但扩充一个新系列要建一堆变体，把文本模板和参数表输入系统，批量生成几十个规格的STEP文件，效率提升非常明显。

注意这些场景有一个共同特点：任务边界清晰，可验证，下游有正式流程承接。text-to-cad适合嵌入这些流程，而不是取代整个设计业务。

6.2 与其他数字化系统组合出来的新玩法

text-to-cad的价值还可以通过组合放大。比较成熟的一个方向是NL2BOM——自然语言直接生成物料清单加三维模型，模型一出来，BOM同步生成，直接对接企业的ERP系统，采购和工艺同步启动。另一个方向是嵌入PLM审批流，AI生成的模型统一打上“AI生成-待人工审核”的标签，审核通过才入库，既享受效率又不牺牲质量管控。

我自己最近在做的一个尝试是把text-to-cad和拓扑优化串起来：先用自然语言生成一个初始结构，导入仿真软件做受力分析，把分析结果反馈给LLM，调整尺寸和形状后重新生成模型。这个闭环跑通之后，一个简单支架的设计优化周期从两天压缩到了半天。虽然目前还要人工盯每一步的合理性，但方向上已经很明确——自然语言只是入口，真正的价值在“描述—生成—仿真—优化—再生成”这个循环里。

6.3 后续可能的技术演进方向

坦白说，现在的text-to-cad还远没有成熟。我看好的下一个突破点是装配体级生成。目前绝大多数方案只能生成单零件，但真实工程里几乎没有单零件交付这回事——一个部件总成里几十个零件，还有配合关系、公差链、标准件选型，这些复杂信息目前的模型还处理不了。另一个方向是多模态输入融合，文字配合草图甚至手势，描述不清楚的地方用一张草图画出来，可能比纯靠嘴说效率高得多。还有知识库增强方向，让模型能查询企业内部的材料库、标准件库、工艺规范，再决定怎么建模——这才是真正能落进企业流程的形态。

这些方向都没有产品级的成熟方案。但对从业者来说，这恰恰是机会——先搞懂技术原理，再结合自己行业的痛点，用现成的开源工具拼出第一版，哪怕丑一点，也比等一个通用大而全的工具靠谱。

最后分享一点个人的体会。我用text-to-cad有一年多时间，感受最深的不是它取代了哪个环节，而是它把设计师从重复的参数化建模琐事里解放出来了。以前一个法兰盘要从头建模，现在只需要说清楚需求、校对结果；省下来的时间，可以去想结构怎么优化、工艺怎么简化。工具再聪明，最后做判断的还是人。所以别担心被替代，多花点时间在提示词设计、结果校验和工程判断上，这些能力只会越来越值钱。