企业官网建设流程全解析

1. 我们真的做好准备，用一句话生成三维模型了吗

先不扯远景。2024年ZC建团队内部做了一个粗糙的尝试：把一张法兰盘的工程描述丢给当时市面上最主流的几个文生3D模型，让它们输出STEP格式的CAD模型。结果很有意思——法体外观确实接近法兰盘，圆盘、螺栓孔分布、中心孔径都有模有样，但一量尺寸，螺栓孔间距差了0.8毫米，配合面平面度完全失控，模型导入SolidWorks之后特征树是空的，这意味着后续根本无法做参数化修改。换句话说，它生成的是"看起来像法兰盘的三角网格"，不是能进产线的CAD模型。

这个矛盾贯穿了整个text-to-cad赛道：文本转自然语言描述容易，文本转可编辑、可制造、带约束的CAD模型难。难点不是"把文字变成模型"，而是"把文字变成符合工程语义的模型"。前者是生成问题，后者是表示问题——而表示形式决定了这个工具到底是个噱头，还是能真正嵌入研发流程的生产力工具。

在开始拆解技术方案之前，先给这篇文章定个锚点：我不会罗列所有所谓"一句话生成3D模型"的产品让你选型，而是把当前text-to-cad的主流技术路线拆开，讲清楚每一条路线背后的原理、能做什么、卡在哪里、以及作为工程师你能用它做什么。后面还会给一个可以本地跑通的最小实践案例，以及我从几十次失败测试里总结出的几条关键经验。

这篇文章适合三类人：正在评估text-to-cad工具能不能接入工作流的机械工程师和产品设计师；想搞清楚"大模型生成CAD"底层到底怎么回事的技术负责人；以及打算自己做点原型验证的开发者。如果你只是想看概念介绍，那可能浪费了这些字，因为问题的答案从来不在PPT里，在实测结果里。

2. 两条技术路线，一条通向"看起来像"，一条通向"用得起来"

2.1 生成式路线：从文本直接生成三维几何

先看最直观的一条路：用扩散模型或Transformer直接生成三维数据。这条路线继承了文生图的技术基因——CLIP文本编码器负责理解语义，扩散模型在潜空间里逐步去噪，最后解码成三维表示。

目前常见的输出表示有三种：体素（Voxel）、点云（Point Cloud）、神经隐式场（Neural Implicit Field， 常用SDF或Occupancy Field表示）。这三种各有明显缺陷。体素受限于分辨率，256³的体素网格看起来细腻，但转换为CAD实体时边界锯齿严重，圆角、倒角完全失真；点云只有离散点，没有拓扑关系，后续做曲面重构误差很大；神经隐式场是当前生成质量最高的选择，它的核心思路是用一个神经网络学习几何表面的符号距离函数，输出连续的距离场，可以做任意分辨率的Marching Cubes提取网格，但提取出来的仍是网格（Mesh），不是参数化实体（B-Rep，即Boundary Representation）。

这是生成式路线的天花板：它生成的是"数字雕塑"，不是"工程模型"。3D打印原型、游戏资产、影视道具，这类场景对尺寸精度要求低（视觉正确即可），生成式路线完全够用。但一旦进入机械设计领域，模型需要进CAM做刀路、进CAE做仿真、进BOM做物料管理，网格数据根本无法支撑这些下游环节。就像你描述一个杯子，AI给出的是一张杯子的高清照片，而不是一张标注了直径80mm、壁厚3mm、材质304不锈钢的工程图纸——前者能看，后者能用。

2.2 程序化路线：让大模型学会调用CAD内核

另一条路线走了完全不同的逻辑：不让模型直接生成几何，而是让模型生成一段程序，由CAD内核执行这段程序来构建模型。输入的自然语言经过LLM（大语言模型）的语义理解后，被翻译成CadQuery、OpenSCAD、SolidPython这类程序化建模脚本，再由脚本驱动内核完成建模。

这条路线本质上是把问题从"几何生成"变成了"代码生成"，它的核心优势是：程序里承载的每个尺寸、每个约束、每个特征都是参数化的，脚本执行完毕生成的是真正的B-Rep实体模型，带完整特征树和参数，后续修改、装配、分析全都顺理成章。

举个例子。输入"直径60mm、高30mm、开四个均匀分布的M6螺纹孔的圆柱底座"，程序化路线生成的CadQuery脚本大致逻辑是先创建圆柱体，再定位四个螺纹孔位，逐个添加螺纹特征。整个过程完全可追溯、可编辑。碰到尺寸不符，你只需要改脚本里的一个直径参数，重新执行即可，不需要重头再生成一遍。这是工程世界里最熟悉的那种"建模方式"。

但这条路也有它的难处：LLM生成代码的准确率不够稳定——如果模型对CAD库API掌握不牢，生成的脚本会有函数签名错误、逻辑缺失；如果涉及复杂的拓扑操作（比如多个特征之间的布尔运算顺序错了），生成的模型就会出现"应该圆角的地方尖角，该打通的孔没打通"这种低级错误。实测下来，简单零件（几何体+基本特征）这类小任务的成功率能到七八成，但再往上的中等复杂度零件，成功率会断崖式下跌。

两条路线对比一下就很清楚：生成式路线下限高上限低，适合看过就行的视觉场景；程序化路线下限低上限高，一旦跑通就是端到端可用的工程模型。目前真正在CAD领域做落地的项目，绝大多数押注的是第二条路。

2.3 混合方案：两条腿走路的现实选择

现实中更多产品采用的是混合方案：先用生成式模型快速给出一个视觉草案，让用户确认"大方向对不对"；确认后再切到程序化路线重新生成参数化模型，或者用一个专门的模块把网格模型反向转换成B-Rep。

这个流程很符合人的工作习惯——先草图后细化。但要注意，网格转B-Rep（逆向建模）这一步目前仍然没有完美解，尤其是包含自由曲面（比如产品外壳）时，转换出来的曲面质量和原始设计意图很难保证。如果产品是规则几何体占主导（机加工件、钣金件、结构件），混合方案的可靠性会高很多；如果是复杂曲面造型（消费电子外壳、汽车内饰），那还是需要正向建模软件里的曲面工具兜底。

3. 从"能看"到"能用"，还缺什么：实测了几个代表性项目

3.1 一个开源方案的完整跑通流程

纯讲原理容易虚，我拿一个代码仓库实际跑一遍，用最直接的方式展示程序化路线的工作流。这里选的是一个开源项目，核心思路是让LLM生成CadQuery脚本，间接实现text-to-cad。工程上它属于"源于真实需求的简化版"，但胜在完全透明，能看清每个环节发生了什么。

环境准备是这样的：需要Python 3.10以上版本，安装CadQuery库，以及一个可用的LLM推理入口。我用的是本地部署的小模型，如果你有云端的API Key，也是一样的逻辑。

先看一段输入。我给的指令是：

create a mounting bracket, 80mm wide, 60mm tall, with two 6mm holes on the horizontal face and a 30mm slot in the center

LLM经过推理后，生成的CadQuery脚本大致像下面这样（我做了一个简化版展示核心逻辑）：

import cadquery as cq # 主体板：80宽 x 60高 x 5厚 bracket = ( cq.Workplane("XY") .box(80, 60, 5) .edges("|Z") .fillet(2) # 给棱边倒圆角 ) # 中心开一个30mm宽的槽 bracket = ( bracket.faces(">Z") .workplane() .slot2D(30, 10) .cutBlind(-5) ) # 水平面上开两个直径6mm的孔 bracket = ( bracket.faces(">Z") .workplane() .center(-20, 0) .hole(6) ) bracket = ( bracket.faces(">Z") .workplane() .center(20, 0) .hole(6) ) # 导出STEP格式（装配、后续加工都要用这个格式） cq.exporters.export(bracket, "bracket.step")

执行这段脚本，CadQuery内核会完成构建实体、布尔运算、倒角等操作，最终输出一个带完整B-Rep拓扑的STEP文件。把它拖进FreeCAD或者SolidWorks，你能看到完整的特征树，板是板、槽是槽、孔是孔，每个特征都能单独编辑。这就是程序化路线相对生成式路线的核心价值：模型不是一坨"死几何"，而是活的参数化特征树。

3.2 实测暴露出的三个典型问题

跑通了流程，问题也随之而来。我用同样的方法连续测试了几十个零件描述，把高频的失败样本做了分类，基本可以归成三类。

第一类：API调用错误。模型记住了CadQuery的类名，但对个别方法的参数签名理解错误，比如hole()方法传入的是直径还是半径搞反了，或者slot2D()的长度参数顺序错误。这个根源是模型训练数据里CadQuery代码的占比太低，它对API不够"熟"。

第二类：逻辑遗漏。描述里要求"四个角各有一个安装孔"，模型只生成了两个孔。这种问题的本质是LLM在从自然语言到代码的转换过程中丢失了约束——它在语义理解层面知道有四个孔，但代码生成时遗漏了循环或数组。

第三类：几何拓扑错误。这一点更隐蔽，生成的脚本语法完全正确，CAD内核也能执行，但结果是错误的几何体——比如一个应该挖穿的槽，因为工作平面（workplane）选错，变成了只切了一半的盲槽；或者两个特征相交的部分布尔运算结果不符合预期。这类错误在语法层面完全看不出来，必须进入三维环境里做几何检查。

这些问题单个看都能修，但累加起来就决定了这条路线的可用性边界。我的实测结论是：简单零件（2~5个特征）成功率大约在60%~75%，中等复杂度零件（包含阵列、多工作平面、复杂布尔运算）成功率会掉到30%以下。这个数字，距离生产可用还有明显差距，但已经足够说明"程序化路线是可收敛的"——因为错误模式是可以枚举、可以修复的，而不像生成式路线那样存在天花板级别的表示鸿沟。

3.3 为什么 选TypeScript而非纯Python

再补一个选型话题。部分工程视角的实现会用到TypeScript，也就是微软那套TypeChat方案。它的设计逻辑其实很有启发：不依赖结构化输出约束，而是给LLM一个类型定义做引导，让它在自然语言和强类型类型之间做自动翻译。你可以把类型定义当成给模型的一张"答题卡"，它必须在已有的格子里填答案，这样从自然语言到接口调用的转换会受到明确约束，错误的概率大幅下降。

选TypeScript而不用Python做推理链路，主要有几个原因：类型系统带来的语法约束能力在Python里非常弱，而TypeScript的interface天然就是一类约束模板；另外整个前端生态和引擎生态跟JS/TS的衔接更顺滑，你可以在一个网页里完成从文本输入到三维预览的全链路。当然，最终生成脚本仍然会是CadQuery或OpenSCAD这类Python系工具，因为CAD运行时生态目前还是Python更完整——"推理用TS，建模用Python"这种混搭架构在实际项目里很常见。

4. 当理想照进生产：工程化落地里的那些"脏活"

4.1 生成后校验是不能省的环节

如果你只是做原型验证，LLM生成脚本、你看一眼顺眼、导出STL去3D打印，那校验环节可以省略。但一旦要进入生产环境，校验必须自动化，不能靠人眼。这是我踩过最深的一个坑——有次我生成的支架模型整体看起来完全正常，尺寸也对，结果后面的装配仿真怎么都过不去。排查下来才发现，模型里有两处极小的非流形边（non-manifold edge），肉眼根本看不出来，但下游CAE求解器一碰到非流形几何就直接崩溃。

实用的校验手段分三层。第一层是语法校验：脚本能不能被执行，这一步靠CadQuery自身的解析器就能完成。第二层是几何校验：检查生成实体的体积是否大于零、边界表示是否闭合、是否存在非流形边，这个可以用开源几何内核的检测工具来做，或者直接用FreeCAD的Part模块跑一遍checkGeometry()。第三层是工程约束校验：关键尺寸是否落在公差范围内、孔距是否符合标准、壁厚是否满足最小加工要求——这一层是机械设计特有的，没有任何通用工具，你得基于业务把自己的设计规范固化成校验脚本。三层全过，模型才算合格。

4.2 约束注入：让模型学会"工程语义"

只给LLM一句"生成一个法兰盘"，它生成的模型大概率不符合任何设计规范——螺栓孔数量可能是5个（法兰标准里通用的是4、8、12等），壁厚可能完全没考虑材料强度。要解决这个问题，光靠"提示词"是不够的，你需要把约束注入到系统里。

目前实践中比较好用的方式，是约束模板化。把常见零件的设计规范整理成结构化约束描述，比如"法兰盘螺栓孔数量必须是4的倍数""两孔中心距不得小于2倍孔径""最小壁厚不得小于3mm"，然后把这些约束拼接到输入提示词中，让LLM在生成代码时时刻带着这些"紧箍咒"。这其实是一种工程语义的注入方式——模型本身不懂机械设计标准，但你把这些标准翻译成自然语言喂给它，它就能在生成过程中遵守大部分约束。

更进一步的做法是"约束后置校验+循环修正"：生成完模型后，自动跑一套尺寸和拓扑校验脚本，发现违规就让LLM基于错误信息重新生成。这个循环设计得好，能把最终成功率大幅提上去。我实测从循环修正前的60%左右提到80%以上，是投入产出比最高的一项改造。

4.3 人机协作：把"全自动"改成"半自动"

我需要说一句可能不太讨喜的话：在可预见的未来，text-to-cad不太可能取代设计师，它最现实的定位是"设计助理"。全自动流程在简单标准件上有机会跑通，但到了复杂产品设计阶段，设计意图的传递远远超过一句自然语言能承载的信息量——重量目标、成本约束、装配顺序、制造工艺、维修便利性，这些东西没法用一句话表达。

更好的方式是重新设计交互流程：设计师给出初步描述，LLM生成"设计草案"，设计师在CAD里对其中的关键特征做直接操作（拖拽尺寸、调整截面、增删特征），操作完之后系统把改动反馈给管线，再继续生成下游内容。这里的关键不是让AI全包，而是让AI承担从"意图到草案"这一大步，把设计师从"从零开始的建模"里解放出来，把精力放到真正需要经验和判断的部分。这也是我在团队内部推动的方向。

5. 常见的坑和反模式，别踩

5.1 把"能生成模型"等同于"能替代建模软件"

这句话是很多项目翻车的根源。模型生成只是前端一步，真正的设计工作流涉及特征编辑、装配约束、运动仿真、工程出图等一连串环节。一个text-to-cad工具，哪怕生成质量再高，如果输出模型不能顺畅地被下游工具链消费，它的价值就是打折的。评估一个工具，不要只看它生成的模型长什么样，要看它能不能导出带特征树的B-Rep、能不能在主流CAD里流畅编辑、能不能支持后续的CAM/CAE流程。

5.2 对LLM的"尺寸困惑"掉以轻心

你可能觉得奇怪，LLM理解"直径60mm"这种明确参数能出什么错？我在实测中遇到的错误包括：将直径直接当半径建模、公制英制混用（描述里写英寸模型里用了毫米）、大量使用整数而忽略小数精度。这类问题不致命，但如果不加修正，批量使用时累积的错误会消耗大量校对时间。解决方式很简单：在提示词模板里强制标注参数命名规范，并在后置校验脚本里逐项核对关键尺寸。

5.3 忽略非几何信息

CAD模型不只是几何。材料、公差、表面处理、热处理状态、标准件编号，这些是生产制造不可或缺的信息。但目前的text-to-cad专注于几何生成，对非几何信息的表达能力几乎为零。输入"制造一个45号钢、表面发黑处理、关键配合面公差H7的底座"，生成模型里根本不存在这些属性。如果你需要的是面向制造的完整交付物（比如MBD模型），现阶段还是得在CAD系统里手工补充属性信息。

5.4 任务复杂度评估缺失

不少团队立项的时候喜欢拿最复杂的零件做目标，结果demo演示翻车之后整个方向被打上"不可行"的标签。我的建议是先从占企业零件总数六七成的简单件切入——轴套、垫片、支架、法兰、盖板这类规则几何体占主导的零件，成功率已经足够支撑"半自动批量建模"的落地场景。一上来就搞涡轮叶片、腔体类零件，那不是不行，而是当前的模型能力和工程校验体系还撑不起来。分阶段迭代，先把高重复度、低复杂度的建模任务自动化，再逐步往复杂件推进，这比一开始就all-in复杂场景稳健得多。

6. 下一步往哪走：我的一些看法和实操建议

这个领域还在快速演进，我没办法给你一个"三年后一定这样"的预言，但基于目前的进展，有几个方向值得关注。

第一是LLM与CAD内核的接口标准化。现在每个方案都自己定义一套提示词模板和API映射逻辑，互相之间完全不通。如果未来能形成一个类似"CAD领域的SQL"的标准化中间表示，让LLM生成统一的建模指令集，再翻译到不同CAD内核（CadQuery、OpenSCAD、商用CAD的API），整个生态的繁荣程度会完全不同。这个工作量大，但价值极大。

第二是模型微调方向的转移。现在大家用的都是通用LLM，对CAD专业知识的覆盖严重不足。更有效的做法是基于通用模型做领域微调，喂入大量"自然语言描述-CAD脚本"配对数据，让模型对CAD API和常见设计模式的掌握变得很熟练。这比在提示词工程上死磕更根治。从数据生成的角度来说，现在有很多开源零件库可以自动化生成配对数据，这条路我自己已经在尝试了。

第三是几何推理能力的独立。有些错误不是语言理解的问题，而是几何推理的问题——"这个槽该从哪个面开始切""这两个特征会不会自相交""倒角的顺序对不对"，这些需要三维空间直觉。未来的模型如果能把几何推理能力从语言模型里剥离出来，变成一个独立的模块，或者用神经符号方法增强，text-to-cad的可靠性和复杂度边界都会有明显提升。

最后给想动手试的人三点建议。先跑通一个最简单的端到端demo，零件复杂度控制在"三五个特征以内"，把管线里的每一步看仔细；花时间建一个自己团队的设计规范校验库，这个比调模型本身更有长期价值；不要期待单次生成的完美准确率，把"生成-校验-修正"的循环当成系统的核心设计理念，而不是生成完了就完事。

我自己踩了一圈坑之后最深的感受是：text-to-cad在未来几年内会和当年的参数化建模普及初期很像——从"看起来很神奇"到"难用得想砸键盘"再到"日常设计的一部分"，中间隔的不是模型参数的大幅提升，而是工程化、校验体系、交互设计这些"脏活"被一个个填平。说得好听叫生成式设计，说得务实点，它就是构建在自然语言之上的批量建模自动化。如果你能接受这个定位，它能帮你省下的时间，会比你预想的多得多。