企业官网建设流程全解析

1. 先拆清楚：text-to-cad到底在解决什么问题

先说个直观的场景。机械设计群里经常有人发一句话求助："帮我画一个直径30mm、高度50mm、带M6螺纹孔的圆柱体。"以前这种需求要么靠人手把手教建模步骤，要么干脆甩一个教程链接让对方自己学。而现在，这句话可以作为一个设计意图输入，直接进入现代CAD流程并生成对应的三维实体模型。这就是text-to-cad这个方向在做的事情。

不过我得先泼一盆冷水：text-to-cad并不是你输入一句话，软件就自动给你蹦出一个完美零件。它解决的是"从模糊语言描述到明确几何表达"这一段转化问题，也就是把自然语言翻译成机器可以理解和执行的建模指令。至于这个模型做出来能不能加工、强度够不够、装配有没有干涉，那是另一个层面的工作。搞清楚这个边界，比急着上手更重要。

从技术演进角度看，text-to-cad其实站在两个大方向交汇点上：一个是大语言模型（LLM）对语义和上下文的深度理解，另一个是参数化建模和程序化建模的长期积累。早年CAD界就有过"宏录制""模板库"之类的半自动化尝试，但那些东西本质上还是人工预设规则，换个说法就失效了。LLM带来的变化是：你不需要预先写死规则，模型可以通过海量语料和代码训练，把"带法兰的圆管接头"这样一句描述，对应到一堆具体的建模函数调用和参数赋值上。这是过去十年里最根本的差别。

所以，这篇文章我想围绕几个实操层面展开：一是text-to-cad背后到底跑的是什么逻辑，二是目前有哪些真正可用的工具和接入方式，三是怎么把一句话变成真正可用于后续设计、修改、导出的CAD模型，四是那些让新手崩溃、让老手抓狂的失败案例和参数设置问题，最后是它的能力边界——知道它不能做什么，比知道它能做什么更重要。

适合看这篇文章的人，我默认是这几类：做机械设计、工业设计、非标自动化的人；做3D打印、手办原型、快速打样的创客；以及正在评估AI辅助设计工具、准备往团队工作流里引入这类能力的研发负责人。你可以没有深度编程背景，但至少要明白CAD软件里"特征""草图""约束"这些基本概念，不然后面聊到模型生成逻辑时会有点吃力。

2. 两条技术路线的底层逻辑：为什么有些工具"懂你"，有些工具只会"猜"

text-to-cad表面上看是一件事，但实际落到实现层面，目前市面上能跑通的东西基本都是两条路线之一。不搞清楚这一点，你选工具的时候会被各种宣传口径带偏。

2.1 路线一：代码生成型，用程序文本作为中间表达

这条路线最主流，核心逻辑是：LLM先把你的自然语言描述转换为一串程序化建模代码，然后由CAD内核执行这段代码，最终生成实体模型。典型的底层库是CadQuery、build123d这种以Python为基底参数化建模库，也有些工具走OpenSCAD的CSG（构造实体几何）语法。

为什么这条路线会成为主流？因为它在可编辑性和可追溯性上占了大便宜。生成的不是一堆无法修改的三角形网格，而是一段带参数关系的程序。用户改一个数字变量，整个模型的尺寸、位置、配合关系就能联动更新。这在工程场景里几乎是必备能力——一个零件如果改不了尺寸，那它就是个摆件，不是设计。

举个具体例子，你用CadQuery写一个带法兰的圆管，大致是这样的逻辑：

import cadquery as cq result = ( cq.Workplane("XY") .circle(20) # 外径40mm的圆 .extrude(60) # 拉伸60mm形成主管 .faces(">Z") .workplane() .circle(35) .extrude(5) # 顶端加一个法兰盘 .faces(">Z") .workplane() .rect(50, 50) .circle(6) .cutBlind(-5) # 法兰上挖四个安装孔 .edges() .fillet(1.5) )

你让text-to-cad生成模型，它做的就是把你的话转成这串代码，或者类似的等价代码，再去调内核执行。所以这类工具出模型的质量上限，很大程度上取决于它对CadQuery这类API的掌握程度，而不是它"理解了"你的话。

2.2 路线二：端到端生成型，直接输出网格点云

另一条路线更接近大众认知里的"AI画画"：给文本，直接输出一份网格模型或点云数据，格式通常是STL、OBJ这类几何描述文件。这类工具在学术界和一些云端demo里很常见，用户输入"一把符合人体工学的椅子"或者"一个造型优雅的花瓶"，系统通过扩散模型或生成对抗网络直接输出三角网格。

它的优点很直观：上手门槛极低，适合外观探索、概念造型、快速可视化。但它的问题也很致命：输出不是参数化实体，不能直接进装配体做配合，也难以进行后续的特征编辑。你用这个流程生成的"法兰圆管"，如果想要调整壁厚或者改孔位，基本只能重新生成，或者丢进Mesh-to-BRep（网格转实体）的工具里做逆向转换，而那个转换过程的精度损失和拓扑修复工作量，足矣消磨掉你省下来的所有时间。

我个人的结论很直接：如果目的是做机械结构或任何要拿去加工的零件，优先选代码生成型工具。如果目的是外观概念、快速可视化、3D打印摆件，端到端生成型完全够用。这两种工具的使用逻辑完全不同，选错方向后面每一步都会别扭。

3. 主流工具横向实测：从云端Demo到本地工作流

这两三年里text-to-cad相关工具冒出来不少，有的是初创公司的在线产品，有的是开源社区的实验项目，还有的是传统CAD大厂内置的AI助手。我把自己实测下来印象比较深的几个工具整理成了一张对比表，方便你建立初步印象。

这张表里我特别想展开讲讲Zoo.dev，因为它是目前社区里口碑比较稳的一个，且能直接接入主流工作流。它的前端交互做得比开源项目友好，免费额度对个人学习基本够用，更重要的是它输出的不仅仅是模型，还有一份你可以拿走继续改的代码。这就意味着你可以在它的基础上二次开发，把常用的几个零件模板沉淀成自己的组件库。

3.1 自建方案的不可忽视优势

如果你所在的企业有数据合规要求，比如图纸内容不能出内网，那云端工具再香也白搭。自建方案其实没想象中复杂：

• 本地或私有云部署一个大模型，推荐参数规模在7B到14B之间，兼顾效果和显存；
• 虚拟环境里装好CadQuery和必要的Python包；
• 预置一份精心编写的CadQuery使用手册和示例库，放进模型上下文做参考（RAG或Few-shot）；
• 自己写一个脚本把模型输出的代码抓出来、做语法检查、执行渲染预览。

这套下来预算不高，一台带24G显存的机器就够跑得很舒服。我自己测试过7B的模型配合Few-shot示例，在标准机械零件上的生成成功率能到70%以上——这个数字在工程场景里已经有了实际应用价值，尤其是把人工校验环节再压一压的话。

4. 端到端实操：从一段文字到一个可以修改的STEP文件

好，工具选定了，接下来我们走一遍完整流程。我以Zoo.dev + CadQuery路线为例，目标是生成一个"带四个安装孔的法兰底座"，这个零件简单但具备典型性，能覆盖拉伸、打孔、倒角、阵列这些最常见的建模操作。

4.1 第一步：写一条"可被机器理解"的需求描述

这一步是整个流程里最容易被低估的。很多人随便丢一句"做个法兰"就等着出图，结果模型出来完全没法用，然后得出"text-to-cad是人工智障"的结论。实际上，问题大多出在描述侧。

有效的描述应该包含这四个维度：

1. 定位基准：法兰在哪个平面上生长？默认是XY平面，但如果你不写，模型很可能给出一个坐标轴上歪斜的结果。
2. 外形轮廓和关键尺寸：直径多少、厚度多少、圆角多少。别只给一个"大""小"这种定性词，机器对形容词的理解远不如对数字的把握。
3. 孔系布置和规格：孔的数量、分布圆直径、孔径大小，这几个信息必须明确。
4. 特征操作类型：是通孔还是盲孔？要螺纹还是光孔？要倒角还是倒圆角？

所以我推荐的输入长这样：

生成一个法兰底座。基准面为XY平面，中心在原点。底座为直径80mm、厚度10mm的圆柱体，中心有一个直径25mm的通孔。在直径为60mm的分布圆上，均匀布置4个直径6.5mm的通孔。底座外缘倒圆角R3，顶面边缘倒角C1。

这条描述里包含了几乎每个特征的具体参数。你不需要一次性写完美，但信息越完整，生成结果质量越高。实测下来，结构化描述的成功率往往是模糊描述的3倍以上。

4.2 第二步：生成、预览、检查

输入描述后，工具会先返回一段CadQuery代码和模型预览。这里我要强调的是：拿到预览图别急着点头或摇头，先旋转视角检查几个最容易出错的地方。

最容易出错的有三处：

• 孔是不是真的通了。很多生成的代码里，孔是用圆拉伸再切割实现的，切割深度如果和板厚差0.0001mm，显示上看着通了，导出STEP拿去加工就会出问题。
• 阵列的个数和分布圆直径是否匹配。4个孔分布在直径60mm的圆上，它们之间的夹角是90度，但如果模型在语义解析时"4"和"60"这两个数字配对错了，出来的就会是3个孔或者分布在错误直径上。
• 倒角/倒圆发生在哪个面。CadQuery里chamfer和fillet的调用对象是Edge而不是Face，选错边导致的几何错误在预览里非常隐蔽。

这个阶段强烈建议直接看生成的代码，不要只看渲染结果。代码比图形诚实。

4.3 第三步：修正与导出

实测下来，一次生成就完美的概率并不高，多数情况下需要你针对性问题做少量修正。比如上面那段描述生成的代码里，孔没完全穿透、圆角选错边——这些是小问题，直接在生成的代码里修改对应行的参数就行，不需要重新写描述。

比如这段修正逻辑：

# 错误：只切了5mm深，没穿透10mm厚的底座 .cutBlind(-5) # 修正：改为穿透切割 .cutBlind(-12)

改完代码，重新执行，得到预览确认无误后，就可以导出为STEP文件。这个STEP文件是实体模型格式，可以直接丢进FreeCAD、Fusion 360、SolidWorks里做后续设计，也可以转成STL切片用于3D打印。

我强烈建议你养成"每生成一次就导出一个STEP并做版本标记"的习惯。因为text-to-cad的生成过程有一定随机性，你这次得到的结果即使同样代码也可能有微小差异，保留版本才方便回溯。

4.4 常见场景的实操参数速查表

为了让你少走弯路，我把做机械零件时最常用的设计意图和对应的CadQuery操作整理成一张速查表：

这张表是我的经验总结，不是官方文档，建议你收藏起来，实际用的时候对照着来，能规避掉大量莫名其妙的失败。

5. 那些让新手崩溃的失败模式：完整排查链路复盘

text-to-cad的坑，很多是工具本身之外的语言障碍。我把自己踩过的坑按"现象→根因→解决路径"的顺序梳理一遍，这个思路也可以复制到其他类似的AI生成任务里。

5.1 失败模式一：生成模型巨大或微小到看不见

现象描述：输出预览区域一片空白，或者出现一个比预期大几千倍的实体，视角缩放也救不回来。

根因分析：这类问题九成出在单位换算缺失上。不同代码生成库的默认单位不一样，CadQuery默认毫米，OpenSCAD默认毫米但部分云端实现会换算成英寸，而你描述里的"50"到底是毫米还是厘米没有体现，模型就会按自己的默认单位来。

修复路径：在描述中明确写出单位，不要只写数字。比如"直径50mm"而不要只写"直径50"。如果生成的代码里出现0.05、5000这类极端数值，直接检查单位换算逻辑，给长度参数乘上一个修正系数（如25.4或1/25.4）。

自查清单：

• 描述里是否所有关键尺寸都标注了单位？
• 生成代码里的数值量级是否符合直觉？
• 多个尺寸之间的比例关系是否合理？

5.2 失败模式二：草图轮廓自相交或无法闭合

现象描述：执行时报错，像"face could not be created"或"wire not closed"，或者生成了形状但表面出现肉眼可见的扭曲。

根因分析：这个问题的核心在于你描述的轮廓看起来没问题，但几何上不自洽。比如你要一个"正方形带一个圆角缺口"，不同工具对这两个特征的布尔运算顺序理解不同，会导致自相交。

修复路径：别先怀疑工具，把描述简化。把带缺口、带切角这类复合轮廓拆解成"先画基础形状，再执行布尔运算"两段式描述。代码生成模型对于单步操作的成功率远高于复合操作。

实战复盘：我之前做过一个"带方形观察窗的圆柱壳体"，按照完整描述去生成，连续四次失败。后来改成两步：先生成圆柱壳体，再单独生成方形窗口特征并执行cut布尔减，一次成功。经验就是，复杂形状要拆步骤，不要指望一句话搞定。

5.3 失败模式三：生成结果永远"差一点点"

现象描述：模型大体上是对的，但某些细节和想象中的不一样——孔位偏了、圆角缺失、某个面没有倒角。

根因分析：一次给太多指令，模型在长序列操作里出现"注意力漂移"。实验数据表明，当指令包含5个以上独立特征时，小模型的完成率会从70%骤降到40%上下。

修复路径：采用"全局描述 + 局部追加"的方式。第一次只描述基础外形和主要特征，生成并通过检查后，再追加次要特征描述，比如"在刚才的底座上，继续添加一个通孔，位置在X方向偏45mm处"。这样模型每次处理的复杂度维持在一个合理水平。

失败案例统计：我实际统计过自己在不同指令数量下的生成效果，单一特征描述的成功率约为85%，5个特征混合描述的降低到50%左右，8个特征以上基本只能当参考稿再手改。

6. 影响出图质量的四个关键参数：给文本做一次"语义工程"

在text-to-cad里，文本就是原料，原料质量直接决定成品质量。下面这四个维度，我每次写描述时会刻意检查。

6.1 方位与参考基准的显式化

大部分失败的根因是方位描述缺失。人脑默认"上面"，模型默认"副法线方向"，CAD软件默认"全局坐标系"——三者经常不一致。所以描述里要明确写上"基准面为XY平面""沿Z轴正方向拉伸""孔的朝向为朝上"，把参考基准显式化。

还有一个实操习惯：描述每一个新增特征时，先重述它的父特征。比如"在圆柱体顶面（>Z方向所在面）上打孔"，远比"在顶部打孔"可靠。这种写作方式对人工读可能冗余，但对LLM是必要的定位信息。

6.2 尺寸标注的密度与冗余

在设计文本时我会遵循一个原则：能加数字的地方都加数字，数字边上配上单位，必要时用"约"来标记非关键公差。

比如：

• 差描述：底座厚度适中
• 好描述：底座厚度10mm，允许±0.1mm

这样做的本质是给模型减少自由度。LLM本质上是概率预测器，在模糊表述上它确实"自由发挥"，而这个自由度在工程里就是不可控变量。你钉得越死，生成越稳。

6.3 特征类型的精确命名

很多新手用生活语言描述特征，结果模型执行了错误的建模操作。比如"挖一条槽"和"创建一条凹槽"在代码生成模型里可能指向完全不同的操作序列。"槽"在制造语境里是"圆形铣刀走过的形状"（Slot），"凹槽"是"在面上做的凹陷"（Groove/Recess），两者的CadQuery实现完全不同。

解决办法：把你想要的特征翻译成CAD术语再输入。哪怕你不记得精确术语，也尽量用"拉伸切除""旋转切除""扫掠"这类操作型词汇，而不是"开个口""挖个孔"这类生活化词汇。

6.4 约束关系的逻辑链条

在有配合关系的零部件描述里，这一点是最值钱的。比如"法兰上四个孔，分布在直径60mm的圆上，等间距"，这串描述里其实隐含了一个非常关键的约束：孔与孔之间的角间距是90度。模型需要自己推导出等分角，一个常用技巧是显式写出"相邻孔夹角90度"。

工程零件的装配和配合关系，应该在描述里以另一种结构化方式呈现：体积配合（孔与轴间隙）、位置配合（中心对齐）、公差配合（H7/h6这类加工配合代号）。text-to-cad模型不会主动知道这些细节，你不写，它就默认不做。

7. 背后的工程价值：恰好解决"从意向到草图"这一步的浪费

把text-to-cad放进更大场景里看，会发现一个很有价值的点。传统设计流程里，方案讨论阶段的很多意向没法快速变成可视化草模，一个零件如果只是简单地板状壳体，可能完全不值得投入一小时的建模时间；但如果画了一小时才发现方向错了，那个时间就白白浪费了。text-to-cad的出现恰好能填补这段空白。

举个例子，我之前做一个非标自动化项目，需要在装配方案会上快速评估几个不同规格的电机安装板。参数无非是底板尺寸、安装孔位置、中心高度这三组数。用传统方式，每个规格画一遍至少15到20分钟，三个规格就是将近一小时。而用text-to-cad流程，把同一段模板描述改几个数字，每个版本三分钟出STEP，直接拉到装配体里做干涉检查。这在提案阶段的价值是巨大的。

同样地，逆向工程里也会用。客户给一张模糊的草图照片和几句话的尺寸要求，以前要重新建模猜意图，现在先把关键尺寸和连接关系列出来，直接生成几个候选模型给客户确认，让客户在半成品上提意见，而不是对着空气讨论。

但也要清醒：text-to-cad不能替代结构计算和强度校核。它能帮你快速把几何形状做出来，但应力分析、疲劳寿命、运动仿真这些重活，还是得依赖传统分析工具。所以更准确地说，这个技术的落点是把"设计意图到初步几何"之间的死重解掉，让人的精力集中在真正需要工程判断的地方。

8. 自建text-to-cad工作流时的几个接地气建议

如果看完上面的实测，你动了自建一套的念头，我最后再给你几个接地气的建议。

第一个建议是不要一开始就追求大模型。很多人问"你要部署就是至少要70B的模型吧"，其实不是。在text-to-cad这类任务里，7B到14B的模型配合精心设计的Few-shot提示词，效果已经相当能打，而且推理速度快，吃显存少。真正决定效果上限的，是你预置的CadQuery示例代码够不够贴切、说明文档够不够清晰。模型只是个翻译器，翻译得准不准，取决于参考语料好不好。

第二个建议是把输出的代码纳入代码审查流程。就像团队里别人提交的代码要review一样，text-to-cad生成的代码也应该被审查后再投入使用。这也意味着你团队里至少要有一个懂CadQuery或build123d的人，这个人不需要是AI专家，但需要能在关键时刻判断代码是"能跑"还是"跑对了"。实测下来，"能跑但结构逻辑有问题"的代码占比不低，靠人工审查能把这类问题在进入CAD内核前拦下来。

第三个建议是不要只把text-to-cad当生成器，要当模板库。当你某次生成了一版结构非常漂亮的代码，保存下来，清洗变量名，写清楚注释，沉淀进你的私有组件库。下一次遇到类似需求时，直接复用那套代码结构，只需改几个参数。这个"从AI生成到人工沉淀再到AI复用"的闭环，才是这个技术最大的价值。我的个人经验是，持续沉淀三个月之后，我可以处理的需求范围会大幅扩大，因为我的组件库越来越丰富，新需求的描述可以精确地指到已有的代码结构上。

最后一个建议是务必设立"人工确认"环节。AI生成的模型必须有人在发布或加工前做最终确认，这是工程伦理，也是职业保护。不要因为工具输出得快就放松把关，加工一个报废件的成本远比手动建模高得多。你要把text-to-cad当成一个"手脚特别快的实习生"，而不是"免检的设计师"。

text-to-cad这个方向还处在快速迭代期，每几个月就有新的模型、新的接口、新的实践出现在社区里。我先说句实在话：目前它在精密机械结构上还替代不了有经验的建模工程师，但在概念快速验证、标准化零件出图、跨部门沟通可视化这些环节，它已经开始实打实地提升效率了。如果你手头正好有一个参数明确的简单零件需求，我建议你今晚就拿它试一次text-to-cad——试完你大概就能理解我把这个流程比作"给AI配了一把CAD的钥匙"是什么意思了。