企业官网建设流程全解析

"text-to-cad"这四个字，我盯了整整一个下午。起因是给一个学生实验台设计快速夹具，对方只丢来一句话："类似倒L型的夹持块，中间开腰形槽，底面四个角要留安装孔"。搁三年前，我得打开SolidWorks画草图、拉伸、切槽、倒角，半小时起步。那天我把同一句话丢进text-to-cad工具，两分钟后拿到一个能编辑的STEP文件——槽的位置偏了两毫米，修一下就能进CAM。这个体验让我确定：设计入口真的在变。

这篇文章就把这套东西说透：text-to-cad是什么、底层逻辑为什么能跑通、我自己实操的完整流程和踩过的坑，以及它现在到底适合什么场景、不适合什么场景。想说的读者很明确——机械设计、3D打印、创客，还有所有被"从草图到模型"折磨过的人。不管你用没用过AI辅助建模，看完你至少知道下一次遇到"一句话需求"时，该往哪个方向使劲。

1. 先搞清楚：text-to-cad 到底解决什么痛点

1.1 设计流程的入口变了：从"画图"到"说图"

传统CAD流程里，最大的时间黑洞从来不是那一步拉伸或者切除，而是"把脑子里的三维想法翻译成二维操作序列"。你要先想清楚主视图长什么样，再想拉伸方向，然后考虑草图约束有没有冲突——这本质上是一种"人肉编译"。

text-to-cad把这一层翻译省掉了。它接收自然语言，直接输出可编辑的实体模型文件。我经常打的一个比方是：以前你请一个制图员，你得把每个尺寸每个特征用手势比划清楚；现在你请的是一个听得懂人话的建模助理，你说"这里开个M6的通孔"，他知道去搜螺纹底孔直径、知道通孔该穿透哪几个面。

但这里有个容易被忽略的点：text-to-cad不是往里塞一个关键词就出模型。它更像是"口语需求文档"到"可执行程序"的转换器，输出的不是一张渲染图，而是一份带参数的几何描述。这意味着你对它说的越接近"工程语言"，它给你的结果就越接近"可制造"。

1.2 为什么偏偏是CAD，而不是"一句话生成3D模型"

很多人会问：不是早就有text-to-3D了吗？Stable Diffusion那种文生图、DreamFusion那种文生网格模型，不也能一句prompt出一个东西？

区别在两个字：精度，以及它俩背后完全不同的"几何观"。

文生3D模型走的是"隐式神经场"或者"扩散模型"路线，它擅长捏出一个好看的形状，但生成的是三角网格——一堆离散的小面片拼起来的皮。你拿它去3D打印一个摆件没问题，但拿去做配合件、做装配、做受力分析，就麻烦了：面不是平的、孔不是圆的、没有历史树、不能改参数。说白了，它给你的是"雕塑"，不是"图纸"。

text-to-cad走的是另一条路：它让AI直接去写参数化建模代码——OpenSCAD脚本、CadQuery脚本、或者直接生成B-rep（边界表示）的建模指令。输出的是正经的CAD内核数据：圆柱就是圆柱，平面就是平面，配合公差能算，布尔运算能做。这正是机械行业敢把它用在生产链上的根本原因。

2. 底层逻辑浅析：不直接捏几何，而是"写代码"

2.1 参数化建模才是CAD的根

要做机械设计，绕不开参数化建模这个概念。简单说，就是用"可变的参数"去驱动"几何形状"：你把长度设成变量L，板厚设成变量T，后续想改尺寸，改数字就行，模型会自己重新计算，所有关联特征跟着变。这跟雕塑完全两码事——雕塑是加法，参数化是"规则+输入"。

text-to-cad之所以能落地，核心突破口就在这里：它不尝试创造几何，而是学会使用几何规则。大语言模型最擅长的恰恰是"给定一个任务描述，生成一段符合语法的代码"。那么为什么不让它生成"一段生成几何的代码"呢？

于是Zoo Text-to-CAD这一类工具的做法就非常直白：prompt进、代码出、执行环境跑一遍，有问题再迭代。去年我第一次跑这个流程时，看到它输出的CadQuery脚本真有点恍惚——那个文件里清清楚楚写着"用两个平行平面拉伸40mm，然后布尔减掉一个直径8mm的通孔"这类逻辑，比我手写的还规整。

2.2 LLM在其中的角色：翻译员 + 编译器

把大模型放在CAD流程里，它的任务可以拆成两层。

第一层是"翻译"：把自然语言里的含糊描述，转成一组明确的建模意图。例如你说"一个扁平的支撑座"，它需要判断：扁平=高度小？支撑座=底部有安装耳朵？这层考验的是语言理解和对机械零件常识的掌握。

第二层是"编码"：把建模意图落成具体函数调用。比如在CadQuery里生成一个带圆角的矩形板，调用的是box()加edges().fillet()；在OpenSCAD里则是cube()加minkowski()或者hull()。这层考验的是对API的熟悉程度，以及能不能处理坐标系变换、布尔运算顺序这些细节。

有意思的是，当前主流方案是"LLM+规则引擎"混合的：LLM负责生成代码，传统CAD内核负责执行和报错，两者之间用agent循环串起来。LLM写错代码没关系，执行器扔回一个TypeError，LLM看着报错信息就能自己改。这个"自我纠错回路"是整个工具能用的关键，我后续在踩坑部分会详细说。

2.3 为什么不是"端到端神经网络直接输出STEP"

严格来说，现在也有学术团队在做端到端的B-rep生成——让神经网络直接输出面、边、顶点的拓扑关系。思路很性感，但目前工程化程度远不如"生成代码"这条路。原因很现实：CAD数据的合法性校验极其严苛，一条边稍微多点或少点拓扑信息，整个实体就"烂"了。

走代码生成路线有个巨大优势：可以用现成的CAD内核当裁判。脚本对不对，跑一遍就知道；几何合不合法，布尔运算一次就知道。这等于给AI装了一个"物理世界的考试系统"，回答不好就自动重考，而且是闭卷。相比之下，纯粹的数据驱动模型没有这种即时反馈，训练得再好也容易在罕见几何上翻车。

另外一个隐藏优势是可追溯性。AI生成的脚本是文本，能存进Git，能diff，能人工review。这在制造行业太重要了——你可以审计"这个圆角是哪条指令产生的"，出问题能追责。黑盒神经网络做不到这一点。

3. 实操：用text-to-cad跑通一个完整零件

3.1 环境准备：先把工具跑起来

我以Zoo的开源文本转CAD工具为例讲讲实际流程，其他同类工具的套路也差不多。第一步是拉取工具。它本身是个命令行程序，依赖Node或Python环境，具体安装方式建议以官方仓库文档为准，因为版本迭代很快，我半年前的安装命令现在已经不太一样了。

跑起来之后，最基本的用法是这样的：在终端输入一句话描述，工具会调用大模型接口生成脚本，然后在本地沙箱里执行，最终导出STEP或STL文件。

text-to-cad "a rectangular mounting plate 80mm by 50mm, 5mm thick, with 4 corner holes of 4.2mm diameter"

第一次跑的时候不要急，先给它一个极其简单的描述——比如"一个直径20mm、高10mm的圆柱"。目的是把整个链路调通：模型返回的代码能不能被执行，导出文件能不能被你的CAD软件打开。我这里说句经验之谈：很多新手一上来就试复杂的涡轮叶片或者齿轮箱，然后对着报错日志一脸懵。先把链路跑通，再谈复杂度。

3.2 写提示词的心法：把"想象"拆成"特征"

用text-to-cad最核心的技能不是会用命令行，而是会写提示词。我把它总结成四个字：特征拆解。

人的自然语言是"整体优先"的——你会说"一个好看的手机支架"。但CAD工具需要的是"特征优先"——底座是什么形状、支撑臂多厚、接触面有没有倒角。你写提示词，实际上是在当"产品经理"，把用户模糊的需求翻译成工程条目。

这里有个重要的经验：显式给尺寸、给单位、给参考系。你可以在提示词里写"用毫米为单位""top view是矩形"这类语句，它们就是在帮模型消除歧义。实测下来，加了尺寸和空间的明确约束之后，首轮生成的成功率能提高一大截。反过来，如果你写"一个中等大小的盒子，上面有些孔"，那模型就自由发挥了，出来的东西大概率是哪都不挨着。

再补一句：一次只描述一个特征的边界，不要试图在一个句子里塞十件事。比如"倒L型底座+腰形槽+四个安装孔+底部凸台"这种描述，模型会在取舍时乱掉。更好的写法是分步：先生成主体，再追加特征。工具一般支持在一个会话里连续追加描述，这就是你"雕刻"的过程。

3.3 迭代策略：从粗到细，从单体到装配

我的完整实操流程，基本固定在四步。

第一步是"粗胚"：只描述零件的大致轮廓和整体比例关系。不看细节，只判断外形对不对。第二步是"精修"：追加孔位、槽形、倒角这类特征，一条一条加，每加一条就导出一次看图。第三步是"参数化"：改代码里的关键变量，反复试验不同尺寸组合，让模型逐步逼近需求。第四步才是"手工收尾"：把STEP文件拉到正式CAD软件里做最后的圆角半径、公差标注。

这套流程看起来有点笨，但我后来想明白了它的合理性——text-to-cad本质上是个"编程过程"，哪有程序员一次性写出完美代码的呢？都是先搭框架、再补细节、然后重构。你把迭代思维带进来，工具立刻会好用很多。

我还试过多零件场景。那次要做的是一个简单的铰链，需要两个扣件加一根销轴。我没有让它一次生成整个装配，而是分别生成三个零件文件，再在CAD软件里装配。text-to-cad对"多个零件之间的配合关系"理解还比较吃力，所以你最好自己兜底做装配约束。这也提醒我：它目前的强项是单零件建模，而不是整机设计。

3.4 输出格式的选择：STEP还是STL

工具通常支持多种导出格式，常见的是STEP、STL，有些还支持OpenSCAD、CadQuery源码。选格式要看你下游用场：

我自己默认导出STEP，除非急出样件才转STL。原因很简单：STEP文件进了SolidWorks或者FreeCAD之后还能编辑，还能基于它生成工程图；STL进去只能当成"个整体"缩放，动不了特征。做设计的应该都有这个执念——留一份可编辑的源文件，比留十个好看的结果都有用。

4. 踩坑实录与排查心法

4.1 提示词含混导致的"尺寸灾难"

第一个大坑，是模型会"脑补尺寸"。你说"一个手掌大小的外壳"，它可能生成一个90mm的，也可能生成一个180mm的——因为"手掌大小"在你脑子里有上下文，在模型眼里就是个模糊区间。这个问题我有一段时间频繁碰到，甚至出现在比较紧急的样件任务上。

排查思路很简单：凡是涉及关键配合的尺寸，一律在提示词里给数字，不给形容词。板上开孔要不要跟M5螺丝配，你就直接写"5.2mm通孔"而不是"适合M5螺丝的孔"。我整理过一套"禁词表"：不要用"差不多""适中""略大""宽一点"，全部换成具体数值或明确的比较关系，比如"宽度是高度的1.5倍"。

4.2 代码能跑，但几何明显不对

比报错更难受的是"没报错但错了"。模型生成了一段语法完全正确的脚本，执行也成功了，但出来的几何跟描述南辕北辙——我说的是左侧凸台，它长在了右侧。这种问题特别难排查，因为工具不会主动告诉你它理解错了。

我的经验是：不要只依赖对话，要依赖中间产物。把生成的脚本源码打开来看，检查坐标系方向、特征施加的顺序、布尔运算的语义。有一次我让它在底板上"切一个槽"，结果模型用的是addBox而不是cutBox——这就是"语义理解错位"。看到这里你就明白为什么输出源码格式这么重要了：没有源码，你连错在哪都不知道，就得凭感觉重新生成。

另外注意检查单位。CAD领域最大的"宇宙级"坑就是单位混乱：有的内核默认毫米，有的默认英寸。如果生成的文件里尺寸突然大了25.4倍，那大概率是单位系统被搞混了，跟模型能力没关系，纯粹是Prompt里没写清楚。

4.3 复杂的模型，不要想着"一次问完"

我犯过的最大错误，是想让模型直接生成一个包含十几个特征的中等复杂零件。结果它生成的代码又长又绕，执行时间翻倍，最后几何还是错的。

后来我把零件拆成了四个子部件，每个单独用text-to-cad生成，最后手工拼装。效率反而高了很多。这背后的道理很朴素：语言模型在生成长代码时，注意力会随着长度衰减，错误率不是线性上升，是接近指数上升。你让它一次写200行CAD代码，不如让它写四个50行的小脚本，每个脚本对应一个清晰的功能模块。

这个经验想明白了之后，我连提示词都开始"模块化"：每个特征一条指令、每个尺寸一个变量。看起来啰嗦，实际上是在帮模型降低认知负担，也是在帮自己做错误隔离。

4.4 常见问题速查

5. 方案选型与适用边界

5.1 现在市面上几类方案的横向对比

text-to-cad不是唯一的选择，我按"输出物"把现在的AI生成建模方案分成了三类，方便你判断该用哪个。

第一类是"文生网格"（text-to-3D），像早期的Point-E、DreamFusion这些。输出是三角网格，适合概念展示、游戏资产、快速灵感验证，但不适合制造。第二类是"文生程序"（text-to-code-for-CAD），也就是本篇文章讲的主体。输出是脚本+参数化模型，适合需要精确尺寸和可编辑性的场景。第三类是"文生图像+图像建模"，先用AI出设计草图，再人工照着建模或者用工具提取轮廓。适合外形设计阶段，但还没法和后端制造直接打通。

这三类不是替代关系，而是不同精度等级的工具。我的建议是：看你的下游是"给人看"还是"给机器加工"。给人看，可以用随意一点的生成工具；给机器加工，老老实实上"文生程序"这条路。

5.2 它能胜任和暂时干不了的活

我用了半年多，体会到text-to-cad目前最趁手的场景有这么几个：

• 标准件和简单结构件：法兰盘、安装板、支架、外壳、卡扣——这类特征清晰、边界明确的零件，生成成功率很高。
• 快速概念验证：甲方或者导师说"先做个样子看看"，用它出初版，比手绘草图还能说明问题。
• 参数化族设计：同一拓扑结构换尺寸出多种变体，改提示词里的数字就行，比手动改参数快。

但也有一些场合我劝你暂时别指望它：

• 精密配合件：需要形位公差、表面粗糙度配合的零件，AI生成的几何只能达到"样子对"，公差链得你自己在后端处理。
• 复杂曲面造型：汽车外观覆盖件、复杂流道这类自由曲面，目前生成式方案还远不如手工曲面建模和逆向工程。
• 大型装配体：几十上百个零件的配合、约束、干涉检查，它还不具备这种系统级规划能力。

还有一个很现实的限制：生成结果的"可解释性"和"可复现性"还不稳定。同样的提示词，不同时间跑结果可能不一样。所以凡是正式项目，我拿到模型后第一件事不是直接用，而是Review一遍特征树，确认它跟我预期一致，然后立即保存一份带版本的源文件。

6. 一点个人体会

经常有人问我：text-to-cad会不会让CAD设计师失业？我的答案始终是：它干掉的是"重复翻译"的活，不是"判断"的活。你说"这里开个槽"，它能开；但开在哪、多深、槽宽跟壁厚有没有干涉、受力后会不会断裂——这些判断还是要人来拍板。

我实际用下来最舒服的状态是：把它当成一个不用睡觉的建模实习生。我负责定方案、审结果、补精度，它负责吭哧吭哧地把我的口头描述变成第一版模型。这个分工省掉了我大量"操作层面的时间"，同时逼着我更清楚自己想要什么——因为你没法对一个说不清楚需求的人生成出好模型。

最后分享一个实用小技巧，是我踩过几次坑后沉淀下来的：在正式干活前，先用一句话描述你零件时，在末尾固定加上"以毫米为单位，坐标系原点设在底面中心，报告关键尺寸"。这三个约定能让输出的模型顺滑非常多。它就像给合作方发开工通知单一样，先对齐基准，再谈细节。

这个领域还在快速迭代，眼下这些工具确实有边界，但我也见到社区里已经有人在用它生成可以实际装配的机电外壳了。保持关注值得，但更重要的是把它当成一个流程工具，融入你自己惯用的设计链路里——工具会过时，你对"需求到模型的翻译能力"的理解不会过时。