企业官网建设流程全解析

做这行久了，你会发现一个很有意思的现象：凡是带"文生"两个字的AI工具，落地时基本都要打三折。文生图能出海报，但出不了印刷文件；文生视频能出氛围，但出不了成片。所以当"text-to-cad"这个词开始频繁出现时，我本来也以为它只是又一个演示级玩具——直到我把一句"我想要一个四孔定位底板，M6沉头孔，中心距40毫米"的提示词丢进去，几秒钟后拿回了一个能改参数、能出工程图、能直接丢进CAM软件做刀路的实体模型。那一刻我才意识到，text-to-cad和前面那些"文生"完全不在一个维度上：它生成的不只是形状，而是一套完整的、可编辑的几何构造过程。这篇文章我不聊概念，只聊实操，把我试过的几条技术路线、三次真实翻车现场、以及现在我自己在工程里真正在用的混合流程，全部摊开来讲。

1. 先把"生成的东西"拆清楚：text-to-cad不是文生图，也不是文生网格

1.1 它到底输出什么：B-rep、特征历史、可编辑参数

很多人第一次接触text-to-cad时，脑子里代入的是文生图的逻辑——说一句话，模型吐一张图，完事。但CAD领域的产出物根本不是"一个形状"，而是"一份几何定义"。这份定义里有边界表示法，也就是常说的B-rep，记录了每个面、每条边、每个顶点之间的拓扑关系；同时还有一条参数化历史，记录了这个零件是通过什么样的顺序一步步建出来的。用个不太严谨但好懂的生活化类比：文生图给的是打印好的照片，text-to-cad给的是PS源文件，里面图层、蒙版、调整图层全都在，你想改哪儿改哪儿。

这带来的直接后果是：判断一个text-to-cad工具好不好用，不能只看模型预览"像不像"，要看它导出的STEP文件能不能被主流CAD内核干净地读进去。我实测下来，很多开源项目生成的模型在自家浏览器预览器里看着非常像回事，一旦导入SolidWorks或者Fusion 360，就会出现破面、烂边、实体无法缝合的问题。原因很简单，预览器只显示了渲染外壳，但底层压根没有建立完整的B-rep数据。换句话说，它只是"画"了一个模型给你看，而不是"建"了一个模型给你用。

1.2 三个关键概念：草图、挤出、特征树

想让text-to-cad真正落地，必须搞清楚CAD建模里最基础的三板斧。第一是草图，也就是二维的线段、圆弧、圆、约束关系，它决定了零件的基础轮廓；第二是挤出、旋转、放样这类特征操作，它们把二维草图变成三维实体；第三是特征树，它把前面这些操作按照先后顺序记录下来。

目前大多数实用的text-to-cad工具，本质上就是在做"自然语言到草图加特征操作序列"的翻译。一个标准的生成流程大概是：模型先理解你的文字描述，拆出尺寸、位置、孔洞、倒角这些信息；然后生成带约束的二维草图；最后调用挤出、打孔、倒圆角这类特征指令，形成一个可以继续编辑的建模过程。注意，这里的关键词是"过程"，不是"结果"。一个只输出三角网格的text-to-cad工具，哪怕生成速度再快、效果再炫，也只能拿去3D打印看个样，无法进入真正的产品研发链路。

1.3 为什么说可编辑性才是核心指标

我见过不少团队评估text-to-cad工具时，首先看的是"生成得逼真不逼真"，这是一个方向性的错误。对工程师来说，一件事情的真正价值在于：拿到模型之后，能不能把板厚从2毫米改成2.5毫米，能不能把四个通孔的位置整体往右移5毫米，能不能在特征树里找到那个倒角并单独调整它的半径。如果不能，那这个模型就只是一个固定的几何体，它的价值和一个STL扫描模型没有本质区别。

可编辑性决定了这个模型是"设计资源"还是"一次性消费品"。目前市面上真正成熟的text-to-cad方案，都会在输出里保留参数化历史，最典型的是生成一个CAD程序或者特征指令列表，你拿到之后还能回头改参数。我在实际项目里，最看重的就是这一步：生成结果导入之后，我在CAD软件里能否双击特征、修改草图中的尺寸，并且整个模型能够自动跟随更新。能，说明工具进入了可用区间；不能，那它还在玩具区间，我会毫不留情地在评估表里打叉。

2. 目前行业的四种实现路线，我逐一对比过

2.1 端到端生成模型：用噪声预测操作序列

第一种路线是训练一个深度学习模型，直接学习从文本到CAD建模操作的映射。这条路线的代表作有Text2CAD、CAD-MLLM这些，底层通常基于扩散模型或者自回归Transformer，训练数据来自DeepCAD这类大型CAD数据集。DeepCAD里面的数据长什么样呢？它把Fusion 360或者SolidWorks里的模型扒下来，转成"草图加挤出"操作序列，每个模型对应一串离散的建模指令。

从原理上说，这种端到端模型做的事情很像"语音听写"：你说一句话，它把它翻译成一串建模动作。问题也出在这里，自动语音识别还有一个词汇表可以做约束，而CAD建模指令的组合空间几乎是无限的，模型很容易学着学着就开始"自由发挥"。我复现过其中一个开源项目，生成的模型在简单拉伸类零件上表现还不错，比如平板、阶梯块、法兰盘；一旦描述里出现多个不同方向的特征，或者有复杂的约束关系，输出的指令序列就开始变得不合逻辑，经常出现拉伸方向反了、草图没有完全约束导致后面特征跟着错位这类低级问题。这个路线的优势是自动化程度高、输入门槛低，劣势是通用性差、稳定性不够，目前更适合学术界继续往前推，生产环境里用它还是要慎之又慎。

2.2 大语言模型直接写建模语言：Zoo text2cad这条路

第二种路线是大语言模型直接写建模语言。代表就是Zoo的Text to CAD，底层思路是把CAD建模表达成一种结构化的DSL，让GPT这类大模型去生成这个DSL代码，再有专门的几何内核把它解释成实体模型。你可以把它理解成"让大模型代替你写建模脚本"，出来的不是一个裸模型，而是一段可以回放、可以改参数的建模程序。

这个路线的体验很有意思。你输入一句"一个带中心孔的圆形法兰，外径80毫米，内径25毫米，边缘均布4个M6通孔"，它不直接给你一个网格，而是返回一段描述建模过程的代码或者JSON结构；Zoo自己的查看器会解析这段结构，实时构建出模型。我实际用下来，它对几何描述的理解能力确实强，尤其是尺寸和数量这类信息，基本不会漏；但代价是，你得先把需求"说清楚"。越是工程师产品经理写需求文档式的大白话，它的表现越好；越是那种"帮我搞个好看的外壳"的模糊口语，它就越容易在无意义的地方自由发挥。对设计流程来说，这反而是可以接受的，因为工程师本来就要先把自己的需求量化成具体参数。

2.3 CAD二次开发脚本路线：门槛最低但最可控

第三条路线最朴素：直接用自然语言让大模型生成OpenSCAD、FreeCAD或AutoCAD的建模脚本。OpenSCAD本身就是用代码描述几何的工具，天然适合作为大模型的输出目标；AutoCAD有AutoLISP，Fusion 360有Python API，FreeCAD也有Python脚本接口。你把一个写好的CAD脚本模板喂给大模型，让它按你的描述去改参数、加特征，然后本地运行脚本，生成模型。

这条路线最稳，也最容易在小团队甚至个人项目里落地。因为大模型不直接操作几何内核，它只负责生成一段普通文本代码，任何语法错误、逻辑错误都能在脚本执行阶段暴露出来，不会出现"界面看着对、底层几何烂掉"的情况。我拿OpenSCAD做过一个验证性项目：让大模型生成一个带散热槽的外壳底板，输出.scad文件后本地打开，直接就能预览，还能通过参数调节槽的数量和宽度。整个过程可控，出了问题很好定位是代码的问题还是描述的问题，不会像端到端模型那样一翻车就完全黑盒。对大多数工程师来说，这条路线是理解text-to-cad成本最低的切入点。

2.4 四条路线放在一起对比

需要泼一盆冷水的是：目前没有任何一条路线能做到"放之四海而皆准"。我在评估时一般不问"哪条路线最好"，而是问"我手头的场景适合哪条路线"。比如要给客户做概念方案对比，用LLM加建模语言最合适；要给老工程师做一个重复率高的制图辅助工具，CAD脚本生成反倒是性价比之王。

3. 实操笔记：我把一个零件从中文描述变成STEP文件的全过程

3.1 先用Zoo的Text to CAD跑通第一遍

为了验证text-to-cad在真实工作流里的表现，我挑了一个非常常见的零件：一个100毫米乘以60毫米的铝板支架，厚度2毫米，四角有R5的圆角，底部有四个直径6.5毫米的通孔，孔中心到边缘的距离是10毫米。我把这句描述输入Zoo的Text to CAD界面，等了几秒钟，系统返回了一个预览模型。

模型看起来没问题，但我不看这个，我只看两件事。第一，导出STEP文件是否成功；第二，把这个STEP文件导入Fusion 360后特征树长什么样。结果让我比较意外：它没有直接给我一个焊死的实体，而是给了可编辑的建模过程，里面有草图、有拉伸、有打孔，孔的参数也能改。我把一个孔的直径从6.5改成7，模型自动更新，没有报错。这种体验和几年前那些"文生3D模型"工具完全不一样，那些工具给的是网格文件，你只能在MeshMixer里像捏泥巴一样处理，而这个至少能进入标准CAD管线。

当然，它的缺点也很明显。整个交互必须用英文，对中文描述的支持还不完善，我后来用中文输入同样一句话，输出的模型出现了明显的特征错乱。另外，它对复杂装配体的描述支持有限，我试过描述一个"由底板、侧板和加强筋组成的U型焊接件"，它反馈说当前版本更适合单体零件，装配场景需要额外处理。总的来说，如果是简单机械零件，Zoo这条路已经具备在概念阶段试用的价值；但离替代工程师做详细设计还差得远。

3.2 用LLM加OpenSCAD做"穷人的text-to-cad"

由于商用text-to-cad服务有次数和数据安全限制，我另外搭了一套更可控的方案：让大模型输出OpenSCAD代码。OpenSCAD的语法简单到像写作文，它本来就是一个把几何描述写成代码的工具。我给模型的提示词也不复杂，就是一段带占位符的建模脚本模板，加上一句"根据以下描述修改参数并补全模型"。

第一次尝试我让它生成一个带有四个安装孔的L型角码。模型给出了完整的.scad代码，核心逻辑是：定义length、width、thickness这些变量，然后用linear_extrude把二维轮廓拉起来，再用cylinder加上通孔。我把代码保存成一个.scad文件，在OpenSCAD里按F5刷新，模型直接出来了。整个过程不到五分钟。更关键的是，OpenSCAD的语法错误会明确指出来，不会出现端到端模型那种"看起来对但内部烂掉"的情况，调试思路非常直观。如果你是个人开发者或者小团队，想在内部快速搭一套text-to-cad服务，我强烈推荐先从这个方案试起，成本低、透明、可控。

3.3 现阶段最稳的组合：LLM抽参数加参数化模板

跑完前面两个实验，我慢慢意识到，真正在生产环境里效率最高的方式，不是让AI从头到尾"自由发挥"，而是让AI做它最擅长的事情：把自然语言里的规格参数提取出来，填充进一个预先做好的参数化CAD模板里。这就好比做饺子，皮和馅都是现成的，AI只负责把一个个客人随口说的"韭菜猪肉、多放葱、咸一点"翻译成具体配比。

具体做法是：你先在CAD里搭好一个参数化模板，比如一款标准支架，把板厚、孔距、孔数、长度、宽度这些变量全部定义成参数；然后用大模型做一个简单的信息抽取，把用户描述里的尺寸和约束填到JSON里；最后用脚本读JSON，驱动CAD批量生成衍生模型。这套流程在稳定性上吊打"一句描述直接生成整个模型"，因为大模型不直接决定拓扑结构，它只填参数，填错顶多是尺寸不合理，不会造成几何崩溃。

我在实际项目中用Fusion 360的API做过类似验证：一早上让AI处理了20条客户描述，生成了20个变体模型，其中只有2个因为描述里缺少孔距信息需要回头确认。要是靠纯手工建模，这批活儿起码要干三天。这个数字很能说明问题：text-to-cad的合理定位不是取代设计师，而是把重复性的参数化变体工作自动化。

4. 三个真实翻车案例，比任何宣传资料都有教育意义

4.1 翻车一：生成的实体看起来完整，实际上是一块"坏几何"

第一次用端到端模型生成一个带侧向安装槽的电机座时，预览器里模型非常漂亮，槽的位置和大小都对。我没多想，直接导出STEP，丢进另一个CAD软件准备加倒角，结果系统连续报错，说"无法将曲面缝合为实体""存在非法边"。检查之后发现，模型内部有几条边重叠交叉，面与面之间存在微小的自交。这种问题在预览器里根本看不见，因为渲染只是显示视觉表面，不会去做实体合法性校验。

这件事给我最大的教训是：从text-to-cad工具里导出的任何一个文件，在进入正式流程之前，必须用传统CAD内核做一次完整的"体检"。所谓体检就是导入后试着做实体操作，比如布尔运算、圆角、薄壳拉伸，只要任何一步报错，这个模型就要打回去重新生成。不能因为预览看起来没问题就直接发给供应商，供应商会把文件打回来的，而且打回来的时候往往已经是项目时间最紧张的时候。

4.2 翻车二：单位、公差和基准信息在描述里丢失

第二个翻车案例更隐蔽，发生在单位上。我给同一个工具分别输入了两句描述，一句话里写"直径12毫米的轴孔"，另一句话里写"直径12英寸的轴孔"。第一次输出的是一个直径12毫米的零件，第二次我本以为它会转换单位，结果它直接生成一个直径12单位的孔，而默认单位用的是毫米。这意味着第二句话被当成"12毫米"处理，英寸完全被忽略。更麻烦的是，有些工具对被描述为"通孔"的特征会默认加公差，有些则完全不加，生成出来的孔连间隙配合都做不到。

在机械设计里，单位、公差、基准面这些信息决定了零件能不能被制造出来。当前大多数text-to-cad工具对这些信息的敏感度非常低，它们更擅长处理"形状描述"，不擅长处理"工程语义"。所以我的建议是：任何对外形有精密配合需求的零件，不要把text-to-cad的输出当作最终结果，它只适合做方案阶段的参考，工程师需要在传统CAD环境里把公差、基准、表面粗糙度重新标注一遍。

4.3 翻车三：特征顺序乱了，倒角变成自交面

第三个翻车案例让我记忆深刻，因为它发生在最不该出问题的简单零件上。我给一个text-to-cad工具描述了一个带中心通孔的法兰盘，要求孔的两端做C1倒角。生成的模型在没有倒角的步骤前一切都正常，但最后一步倒角直接导致实体自交报错。我打开它生成的特征历史才发现，模型把倒角放在最后一次布尔运算之前，倒角的边界没有正确匹配上孔的轮廓，于是整个特征链崩了。

这个问题的本质在于，CAD里很多特征的先后顺序是有强约束的：倒角通常要放到最终形态之后，打孔之前还是之后也直接影响结果。端到端模型在生成操作序列时，往往缺少这种"特征顺序"的推理能力，它只知道"要做这些操作"，不知道"操作之间的依赖关系"。现在我再看到text-to-cad生成的模型，第一件事就是打开它的特征历史，检查每一个特征的父亲节点和先后顺序。顺序合理的模型，编辑起来才顺手；顺序乱的模型，就算形状对了，改起来也让人想砸电脑。

5. 如何把text-to-cad塞进自己的工程流程而不翻车

5.1 第一个最佳位置：概念阶段的批量变体

以我目前的实践来看，text-to-cad最适合放在概念设计阶段，尤其是需要大量变体比对的场景。客户说想要一款"更小、更轻、安装方式不变"的支架，传统做法是CAD工程师花一下午改尺寸出三稿；现在我可以把客户的原话扔进去，让它一口气生成六八个参数不同的变体，快速筛出两个靠谱方向，再让工程师在传统CAD里精修。这个阶段出错成本低，就算模型生成得不好，也只需要重新描述一次，不会造成实际损失。

批量变体还有一个额外的好处：它能倒逼团队明确需求边界。因为提示词写得不清楚，AI生成的结果就一定乱七八糟，这反而逼着产品经理把"更小、更轻"翻译成"长度减少20%，重量不超过200克"。这个过程本身就是对团队需求管理能力的一次提升。

5.2 我固定保存的质检清单

在把AI生成模型纳入正式流程之前，我给自己定了一个固定的质检流程，每一步都不能跳过：

• 导入主CAD软件，确认系统识别为实体而不是曲面，能选中内部体积。
• 尝试进行一次实体布尔运算，比如切割一个孔，检查是否会报错。
• 打开特征历史，确认每个特征都有明确父节点，顺序符合B-rep建模规范。
• 修改一个关键参数，比如板厚或孔距，确认模型自动更新且不崩。
• 用测量工具校准几个关键尺寸，和原始描述做比对。
• 如果涉及装配，把STEP文件放进整机装配体，检查干涉和配合面。

这套清单看起来简单，但它能拦住我上面说的绝大多数翻车。我用它筛掉了差不多三分之一生成模型，其余三分之二才敢继续往下走。

5.3 数据安全、许可与边界判断

最后提醒一句，用text-to-cad服务时，数据安全往往是被低估的问题。我见过不少公司直接把内部图纸描述复制粘贴到在线工具里，生成结果确实方便，但描述文本里往往藏着产品结构、尺寸链、材质选型这些核心信息。对外部的在线服务，我的原则是：敏感设计一律不传，最多用它验证思路；真正要用于内部流程的数据，必须走私有化部署或者上面说的本地脚本方案。这也是为什么OpenSCAD那套"穷人的text-to-cad"在工业环境里更受青睐，数据不离开内网，比任何功能点都重要。

6. 我现在实际使用的"人机分工"方法

6.1 分工原则：模型做结构，人类做决策

磨合了半年多，我自己对text-to-cad的使用原则已经非常明确：AI负责结构性重复的活，人类负责判断和决策。凡是"照着描述把参数填进既有模板"这类事，全部让AI干；凡是"这个设计是否合理、这个配合是否可靠、这个工艺能否实现"这类事，坚决自己拍板。这个分工让我的效率提升了不止一个档次，同时也守住了设计质量的下限。

我目前的工作流非常固定：先用LLM加参数化模板批量生成变体，再用CAD质检清单筛选，最后把合格的模型交给工程师做详细工艺评估。整个过程里，text-to-cad不是一个"替代者"，而是一个极其高效的"解析器"——它把语言转换成模型的脏活累活都接过去了，留下来的核心决策依然在人手里。

6.2 给刚接触text-to-cad的人三句话

如果你现在刚准备尝试text-to-cad，我给三句实在的建议。第一，不要迷信预览器，把文件导入传统CAD软件里做一次真刀真枪的编辑，这比任何演示都有说服力。第二，从OpenSCAD或参数化模板这种"半自动"方案起步，稳定的可控性比炫酷的端到端更重要。第三，把每一次失败案例记录下来，整理成自己的提示词手册，里面写清楚"什么描述能生成稳定结果，什么描述会翻车"，这份手册的参考价值比任何官方文档都高。

我自己的体会是，text-to-cad真正开始变得有用，不是从它能"一次生成完美模型"那一刻开始的，而是从我承认它"生成不了完美模型"那一刻开始的。承认它的边界，把它放在对的位置上，它立刻就从玩具变成了生产力工具。以后你再听到"一句话生成CAD模型"的宣传，不妨先问一句：能改参数吗？特征树能编辑吗？能过实体校验吗？这三个问题，能帮你省下大量试错时间。