企业官网建设流程全解析

1. Text-to-CAD解决的不只是"生成模型"，而是"从图像到参数化建模"的最后一公里

先说个真实场景。上个月我在做一个手机支架的原型，需要在支架底部加一个埋头孔来配合M3螺丝。传统流程是：打开CAD软件，画草图，拉伸，再画圆形阵列，倒角，改尺寸，再调整。整个过程十分钟能搞定，但问题在于——如果客户的需求文档只有一句话描述，比如"做一个左侧带卡扣、右侧带USB走线槽的支架"，CAD建模的时间成本依然很不可控。

Text-to-CAD这个概念，行业内已经把热度炒了大半年，但真正能用起来的工具少之又少。所谓Text-to-CAD，核心不是"根据文字生成一张渲染图"，因为那在LLM+扩散模型的时代太容易了。真正的难点在于：你能不能把一句自然语言描述，直接转换成一个带参数、能编辑、能出工程图、能直接丢给CNC或3D打印的CAD实体模型。一个网格（Mesh）文件不能算CAD，一个不能改参数的B-rep实体也不算可用的CAD。

这个方向之所以值得关注，是因为它直接击中了产品设计流程里效率最低的那一段。你去问任何一个用过3D打印的朋友，都会告诉你：设计一个简单的定制零件，用传统GUI建模，80%的时间花在重复性操作上。而Text-to-CAD的想象空间在于，未来设计师的输入不再是鼠标和工具栏，而是设计意图本身。AI负责把意图翻译成精确的几何约束和特征树——这才是这个技术真正让人兴奋的地方。

这篇内容我会从底层原理、主流工具、实际工作流、提示词技巧、踩坑记录五个维度展开，尽量把目前这个领域能落地的部分和仍然画饼的部分都讲清楚。适合的人包括：做机械结构设计的工程师、经常接触定制零件的创客、在研究AI辅助设计的同学，以及所有想搞清楚"Text-to-CAD到底能力边界在哪"的人。

2. 原理先行：为什么它生成的是CAD模型，而不是一张图片或塑料网格

要理解Text-to-CAD的难点，必须先理解"CAD模型"在计算机里到底是什么。

2.1 B-rep（边界表示）与Mesh的底层逻辑差异

很多做3D建模的朋友熟悉的是STL/OBJ这种Mesh网格格式。Mesh由三角形面片组成，描述的是"物体表面的近似采样"。它没有拓扑的概念，没有面与面之间的连接关系，更不存在"哪个面是圆柱面、哪个边是倒角边"这种语义信息。你可以把Mesh想象成一张用无数小纸条贴成的雕塑——远处看形状很对，但你不能直接对它执行"改变这张纸条的曲率参数"这样的操作。

而CAD软件内部用的是B-rep（Boundary Representation，边界表示）。B-rep存储的是几何体的拓扑结构：顶点、边、环、面，以及每个面背后的数学曲面定义。下拉一个拉伸特征，得到的是由平面构成的B-rep实体；做一个旋转体，得到的是包含圆柱面、圆锥面的B-rep实体。B-rep天然支持精确测量、布尔运算、删减特征、历史树回退——这正是工程图、CAM、CAE这些下游应用的前提。

Text-to-CAD要生成的是B-rep模型，而不是Mesh。这一点直接决定了它的技术路线与传统文生图、文生3D完全不同。

2.2 Text-to-CAD的主流实现路线：从语义到几何的映射

目前做Text-to-CAD的技术路线，我把它归纳为三类：

第一类：基于扩散模型生成B-rep（Autodesk路线）。这类方法参考文本-图像扩散模型的思路，但生成空间不是像素，而是CAD草图和拉伸操作序列。Autodesk实验室提出的Text-to-CAD就是这条路。它训练了一个条件扩散模型，输入文本嵌入（Text Embedding），输出的是参数化的CAD操作序列，例如"画一个50mm×30mm的矩形草图→拉伸20mm→在顶面上倒角2mm"。生成的不是一张图，而是一串可以被CAD内核（ACISM）执行的特征命令。

第二类：基于LLM生成代码（OpenSCAD/CadQuery路线）。这条路线更工程化。文本描述后，LLM直接生成对应OpenSCAD或CadQuery的Python脚本。CadQuery的优势是脚本本身就是参数化描述，改几个变量模型就跟着变。这种方案的优势是：生成的"模型"天然就是参数化的，可维护性极强；劣势是：LLM生成代码的正确率目前还不稳定，复杂几何容易写出语法对但逻辑错的脚本。

第三类：基于拓扑生成+后处理网格转CAD。先用文生3D模型生成Mesh模型，再做Mesh到B-rep的逆向转换（例如用逆向工程工具拟合曲面）。这条路存在一个本质问题：Mesh转B-rep后，模型往往承载着大量噪声曲面，历史特征树丢失，工程图可标注性差。说实话，这种方案更适合做"视觉原型"而不是"制造原型"。

三类路线里，目前我最推荐的还是第一类和第二类的组合应用：用Autodesk的现成工具做快速验证，用CadQuery/OpenSCAD的路线做需要复用的参数化零件。

2.3 为什么纯语言模型做不了"精确"

有人会问：既然LLM这么强，直接把描述丢给GPT-4，让它输出一个模型文件行不行？答案是不行，至少现在不行。原因在于：LLM擅长处理离散符号（文本、代码），但CAD建模是连续几何空间的操作，一个尺寸差0.5毫米，装配就可能干涉。LLM没有几何计算内核，让它凭空"画"一个精确模型，等于让一个诗人徒手画出工程图纸——描述得非常优美，测量不出来。

所以，所有真正可用的Text-to-CAD工具，背后一定绑定了某个几何内核（ACIS、Parasolid、OpenCASCADE），生成的是"可以被内核求值"的特征序列或脚本。这也是判断一个工具是否靠谱的关键：它有没有真正的几何引擎在托底。

3. 主流工具的选型对比：从Autodesk到开源方案

Text-to-CAD目前处于"预告即火爆、落地仍粗糙"的阶段。建议先用这几个工具把体验打通：Zoo.dev的Text-to-CAD、Autodesk Fusion 360的文本生成建模、以及CadQuery+AI辅助脚本方案。

3.1 Autodesk Text-to-CAD：从实验室到产品的最近一步

Autodesk在2024年推出了集成在Fusion 360里的Text-to-CAD功能，目前还是技术预览阶段。使用流程是：在Fusion 360里输入中文或英文的自然语言描述，等待云端推理，然后模型会以T-Spline（T样条）或B-rep的形式加载进来。

实际操作体验：

• 对简单零件，比如"按扣""U型槽""带圆角的矩形板"，生成的模型可用率很高；
• 对描述含糊的句子，例如"是一个支架"，模型会生成一个非常"通用"的支架，几乎没有细节；
• 对装配体级别的描述，比如"包含4个螺栓的支撑座"，目前还只能生成单体零件。

Autodesk的优势是工程生态完整，生成后可以直接利用Fusion的参数化树做改版；劣势是需要Fusion订阅，且云端推理排队时间不稳定。

3.2 Zoo.dev Text-to-CAD：开发者友好的API路线

Zoo.dev是面向开发者的AI CAD初创公司，它的Text-to-CAD以Web API形式提供。流程是：把自然语言描述POST给API，返回一个JSON文件，里面包含模型的线框、B-rep信息和特征参数。

这个方案最推荐给做自动化工具链的团队。举个例子：在PTC Onshape里做二次开发时，我可以直接调用Zoo的API，把客户在网页表单里填写的需求描述自动转成CAD模型，并同步到Onshape工作区。这在自动报价、非标设备快速出图这类场景里，效率提升非常明显。

3.3 CadQuery+LLM辅助：自己掌握核心命脉的开源组合

如果你不想依赖商业闭源服务，最稳的方案是：

1. 在电脑上安装CadQuery（基于OpenCASCADE的Python库）；
2. 把文本描述丢给LLM，让它生成CadQuery的Python代码；
3. 本地执行代码，直接得到可编辑的STEP文件。

这个方案的优点是完全开源、可二次开发；缺点是LLM生成的CadQuery代码需要人工把关，尤其复杂模型容易卡在布尔运算失败上。我的习惯是：让LLM分两步走——先让它生成模块化的函数（比如def base_plate()、def rib_support()），再在主函数里调用，这样出了错也能快速定位是哪一块。

3.4 我自己选型时的判断标准

综合对比这几个工具后，我给自己定了三个选择标准：

1. 输出格式能否用于制造。只要输出是STEP或原生B-rep，就胜出；只给STL就只能当可视化用；
2. 参数化可编辑性。生成结果能否直接修改尺寸参数，决定了我是否愿意二次加工它；
3. 是否尊重设计意图。描述中提到的关键特征（比如"倒角""加强筋""孔距30mm"）是否都被保留，而不是美观优先。

按这三个标准衡量，目前Autodesk和CadQuery表现最佳，Zoo在自动化方向上潜力很大，纯Mesh后处理类工具基本不用考虑。

4. 基于提示词的核心工作流：从一句描述到可编辑原型的完整路径

有了工具，下一步就是搭建属于你自己的Text-to-CAD工作流。我这里分享一条经过验证的路径，直接从想法到可编辑原型，大约20分钟内可以走完全程。

4.1 第一步：将需求拆解成"可翻译的设计意图清单"

万事开头难，但难的往往不是建模，而是"把你的需求说清楚"。我自己总结了一个模板，称它为"设计意图四要素"：

• 零件类型：一句话说清楚是什么（板、支架、轴套、壳体、卡扣）；
• 关键尺寸：长宽高或主直径，尽量给出数值，单位统一为毫米；
• 关键特征：孔、槽、倒角、加强筋、走线孔等，附上具体参数；
• 装配逻辑：与什么零件配合、配合间隙是多少、是否做齐平。

举个例子，我最近用Text-to-CAD生成一个树莓派外壳的底座：

"设计一个适配Raspberry Pi 5的底板，长85mm，宽56mm，厚度3mm，四个角落有直径3.2mm的安装孔，孔距遵循Pi官方PCB布局，侧边开一个15mm×10mm的HDMI端口方孔。"

把这句话递给工具，生成出来的模型配合度非常高。关键就在于：我没有说"树莓派外壳"，而是把抽象概念分解成了可计算的量化要素。

4.2 第二步：分而治之——复杂零件按特征拆解生成再组装

Text-to-CAD目前的"单次生成"能力还不足以处理复杂装配体。我的经验是：把一个复杂零件拆成三到四个"可单独描述"的子部件，分别生成，最后在CAD端用布尔运算或装配约束合并。

举个例子。一个桌面显示器支架，我会拆成三部分：

1. VESA转接板（关键参数：75mm×75mm孔距，外轮廓100mm×100mm，厚度3mm）；
2. 立柱主体（长度350mm，截面40mm×40mm，两侧预留线槽）；
3. 底座（宽度250mm，深度180mm，重心分布满足稳定性）。

三部分单独用Text-to-CAD生成后，导入到Fusion 360里做装配对齐和孔位微调。这样做的好处是：即使某一部件生成失败，也不需要整体推翻重来。

4.3 第三步：后处理才是重头戏——不要期待"一步到位"

就目前工具的能力而言，"生成即成品"是不现实的。我用Text-to-CAD做零件时，通常会把60%的时间花在"给AI擦屁股"上。常见的后处理动作包括：

1. 单位检查：生成的模型默认可能是英寸（Inch），必须统一改成毫米；
2. 特征树重排：合并多余的拉伸特征，调整生成顺序，让历史树更干净；
3. 倒角与脱模角补充：很多生成结果忽略了铸造/注塑所需的脱模斜度；
4. 孔位公差确认：AI根据描述生成的孔直径，未必满足配合公差需求，务必用尺寸标注复核。

4.4 第四步：验证可制造性

原型生成后，我建议立刻做三件事：

• 快速干涉检查：如果零件需要配合装配，在CAD内做静态干涉检查；
• 壁厚均匀性检查：用截面试探功能检查壳体类模型是否出现倒扣或过薄断面；
• 导出STEP试跑CAM/切片：经验原则是，能够正常切片或生成刀路的模型，才是真正"可用的模型"。

我个人倾向把STEP格式作为所有下游流程的唯一输入。STL只用于快速预览，不用来生产。

5. 提示词工程的实操宝藏：怎么写才能让模型"懂你"

Text-to-CAD在现阶段，拼得不是谁的显卡好，而是谁更会写提示词。很多人抱怨生成结果"像儿童积木"，问题通常出在描述太抽象，或者用了大量与几何无关的形容词。

5.1 避免"形容词黑洞"，只说可测量的词

来看一组对比：

反面案例：

"设计一个漂亮、现代、简约的桌边收纳盒，放在办公室里很优雅。"

这句话里的"漂亮""现代""简约""优雅"全是不可测量的主观词汇。AI只能随机给一个"它认为漂亮"的形状，结果通常是带圆角的长方体，毫无工程细节。

正面案例：

"设计一个桌面收纳盒，外形为长方体，长度180mm，宽度120mm，高度60mm，壁厚3mm，顶部开口无盖，正面底部有一条宽10mm的走线槽，槽深2mm。"

每一个参数都是可执行的几何约束。生成结果即便不完全准确，你也会获得一个"接近预期"的基础模型，再手动加圆角也好，改槽位也好，都有方向。

5.2 用"层级描述法"让模型关注优先级

当模型对描述中的多个特征难以取舍时，我的做法是给特征排优先级，在提示词里用"必须""其次""若可行"分层描述：

• 必须（Must-have）：总外形尺寸、配合孔径——决定模型是否能装得上；
• 其次（Should-have）：如走线槽、倒角、壁厚——影响功能性但允许近似生成；
• 若可行（Nice-to-have）：如外观圆润度、分模线位置等——即使生成偏差也不影响整体使用。

目前Text-to-CAD工具普遍对"Must-have"层级的遵从度更高。这个现象背后的逻辑是：模型对数字敏感度远高于形容词，因为数字直接对应采样空间的特征，而形容词对应的是模糊分布。

5.3 单位永远写进提示词

我发现一个非常有价值的细节：每个提到尺寸的词后面都要带单位。不要只写"直径10"而要写"直径10mm"。因为很多训练数据里英寸和毫米混存，AI在没有明确单位提示时会随机抽选，导致生成出来的模型是实际尺寸的25.4倍或1/25.4——如果你做的是装配件，这种误差是灾难性的。

5.4 一次生成不理想？用"增益式迭代"而非推翻重来

实际使用Text-to-CAD时，第一次就完全满意的概率不高。错误做法是反复修改整个提示词，期望AI"顿悟"。我的正确套路是：

1. 保留上一轮中满意的部分描述，将措辞原封不动保留；
2. 只对不满意的部分追加修正描述，例如"将散热孔数量从4个调整为9个，孔间距保持8mm，孔径改为2.5mm"；
3. 新一轮生成时，将上一轮生成的模型文件路径作为参考上下文传入（部分工具支持），在不脱离原模型的基础上做增量修改。

这种方法本质上利用了扩散模型/代码生成模型对上下文连续性的敏感性，比"推倒重来"的成功率高得多。

6. 实测踩坑：模型拓扑、单位尺度与可制造性的三座大山

任何一个工具，只有真用起来才会暴露问题。我调过各种Text-to-CAD方案，总结出三个高发踩坑点，都是为了让读者少走弯路。

6.1 坑一：模型拓扑错误——曲面方向与法向翻转

有一段时间我频繁遇到一个现象：模型看得到但无法切片，或CAM生成刀路时报"几何体无效"。排查后发现，是生成模型的曲面法线出现了局部翻转（也就是说，同一个几何面被重复建模或闭环方向混乱），导致CAD内核在做体识别时判定为"非流形几何"。

排查思路：

1. 在CAD软件里开启"检查几何体"工具（Fusion的Inspect > Check，Onshape的Mass properties）；
2. 查看是否存在无效面、零长度边；
3. 如果无法自动修复，我的应急方案是：导出STEP后使用Open Cascade的开源工具OCCT做一次几何愈合处理，再重新导入。多数法向问题可以在这步被矫正。

这里也延伸一个选择观：生成工具越倾向于"曲线自由造型"，拓扑出错概率越高；越倾向于"规则特征（拉伸/旋转/倒角）"，出错率越低。这也是我极力推荐"从规则特征入手生成"的原因。

6.2 坑二：单位制混乱导致的比例灾难

这个坑我上面提过，但要专门拿出来说。一次我按55mm×35mm×3mm描述生成一个电路板支架，结果导入Fusion后零件尺寸变成了55英寸×35英寸×3英寸的"巨型雕塑"。排查链路如下：

1. 先检查提示词——确认已写"55mm×35mm×3mm"；
2. 再检查生成结果的文件属性——发现模型内部默认单位是英寸（inch），而我导入时选择了"不转换单位"；
3. 最后在Fusion里通过Units and Display > Change Units统一成毫米，并顺便检查关键孔位尺寸是否保持合理。

经验教训：模型单位取决于生成端的默认设置，而不取决于提示词。生成后第一件事永远是清点预期尺寸，检查实际批量尺寸是否匹配，不要傻乎乎地直接进入后处理。

6.3 坑三：可制造性缺失——AI不懂脱模斜度与加工余量

Text-to-CAD生成的模型，从几何角度看是"正确"的——但一旦进入制造阶段就开始出问题。最常见的三类制造性问题：

1. 注塑件没有拔模斜度。AI不知道塑胶件成型需要1~3度的脱模斜角，生成的是90度直壁。对策：在CAD中对垂直壁面补一个Draft操作，或者提示词里提前写"所有侧壁带1.5度拔模角"；
2. 机加工件没有预留精加工余量。直接按成品公差生成模型，会导致实际加工超差。对策：在提示词中标注"外轮廓单边预留0.5mm余量"；
3. 孔洞位置过度理想化。例如生成的安装孔恰好在加强筋的正上方，实际钻孔时会打穿筋条。对策：提示词中明确"孔位中心距离加强筋边缘最小3mm"。

制造问题很难通过AI自行消化，因为它们依赖的是DFM（面向制造的设计）知识库，而不是几何描述。工程人员必须留出人工校核环节，尤其是涉及装配公差和模具结构的零件，生成结果只能当草稿看。

6.4 辅助验证自己的生成质量

我给自己定了一个"三查"流程，推荐给大家：

三道检查都过，才把模型定为"可交付状态"。

7. 下一步：文本语义与设计意图的深度对齐

Text-to-CAD给我最大的感受是：它把"AI辅助设计"从玄学变成了可操作的工具。但对于想靠它在生产环境里立足的人来说，现阶段必须做好两件事：一是把"人类工程师的设计判断"嵌入到生成结果的验证环节；二是建立一套"描述→生成→校验→修正→复用"的闭环工作流，而不是把AI当结果终端。

我自己亲测后最大的心得是：Text-to-CAD目前解决的是"从无到有"的粗模草稿问题，而不是"从粗到精"的工程设计问题。它适合当作灵感和起点的爆发点，但不要指望用它来替代结构工程师的受力分析、公差分配和工艺决策。把它放在你的工作流上游——把它当作一个随叫随到的3D草图员——应该是它目前最合理的定位。

如果你准备试试这个方向，建议先从CadQuery+LLM方案入手。免费、可控、能感知OpenCASCADE的几何内核如何工作，踩过一轮坑之后再迁移到商业平台，你的理解会深刻得多。等工具完成从"生成美观"到"生成准确"的跨越，那一天的到来，等的不只是模型们，还有你早已武装到牙齿的工作流。