企业官网建设流程全解析

很多人第一次听到 text-to-cad，第一反应多半是：又一个 AI 噱头。说实话，我一开始也这么觉得。直到我真正把一个自然语言描述的长句，比如“一块 100 毫米长、60 毫米宽、5 毫米厚的板，四个角上各有直径 5 毫米的通孔”，转换成一段可运行的代码，再导出成能直接交给加工厂的 STEP 文件时，才意识到文本转 CAD 这件事已经从一个研究 demo，走到了可以被普通工程师拿来当生产力工具的阶段。

text-to-cad 解决的核心痛点，是把 CAD 建模里最枯燥、最没有创造性的“从零搭几何”这一步解放出来。你不需要再在软件里一个个画草图、加约束、拉伸、切孔了，只要把设计意图用文字说清楚，剩下的几何构造和参数计算交给工具完成。这个能力对机械设计、3D 打印、产品结构设计、非标自动化方案前期评估的人帮助很大，甚至对完全不会用 SolidWorks、UG、中望CAD 产品的人来说，也能快速获得一个可修改、可编辑的真实三维模型，而不是一个只能看的渲染图。这篇文章我会把 text-to-cad 的原理链路、工具选型、真实可跑的实操流程和踩过的坑都写清楚，希望给准备入坑的人一条能复现的路。

1. 到底什么是 text-to-cad：从“画图”到“说图”的转变

1.1 我为什么开始关注这个方向

我是一个常年和机械加工、标准件选型打交道的工程师，平时最烦的就是客户的方案需求来得特别急。经常是上午刚开完会对需求，下午就要出方案图，留给你建模的时间可能只有两三个小时。这种需求下，大部分模型其实是重复劳动：一块底板、几个安装孔、几根柱子、一个法兰，结构不复杂，但手工建模也得一步步来，先画矩形，再拉伸，再定位孔，再阵列——没有半小时根本下不来。

后来我开始尝试用代码去描述模型，也就是参数化建模。最早玩的是 OpenSCAD，后来又用了 CadQuery、FreeCAD 的 Python API。这种方式的好处是模型可以被规格化、被复用，但问题也很直接：写代码本身就是一种门槛，而且代码的语法、坐标、布尔运算的写法都很挑剔，一不小心就是编译错误。正当我在想这个门槛能不能再低一点的时候，text-to-cad 这个概念出现了。

所谓 text-to-cad，就是一个把自然语言描述转化为 CAD 模型的技术。它不是一个单一的软件，而是一条由大语言模型、代码生成器、几何内核、参数化建模库组成的生产链路。用户输入的是“一个直径 40mm、高 25mm 的圆柱，顶部切一条深 5mm 的十字槽，槽宽 6mm”，输出的是一份可以编辑、可以导出、可以用于 3D 打印或者 CNC 加工的模型文件。

1.2 它适合谁，不适合谁

从我几个月的实测经验来看，text-to-cad 目前最合适的用户有三类。

第一类是机械设计工程师，他们需要快速建立方案阶段的粗略模型，用来做干涉检查、空间布局和方案汇报，对细节特征要求不高，但对速度要求极高。第二类是 3D 打印爱好者，他们经常需要一些小零件，比如一个 Raspberry Pi 外壳支架、一个带卡扣的盒子、一个灯罩，这类零件结构相对简单，用文字描述完全够用。第三类是相对缺乏建模经验的工程师或者产品经理，他们可能要用 CAD 文件去做渲染图、做专利附图，或作为和加工厂沟通的参考模型，自己上手建模的成本太高，而让 AI 生成一个基础模型再局部修改，是很现实的选择。

反过来说，哪些人不适合依赖它？如果你要建的是一个复杂的装配体，有齿轮啮合、运动副、配合公差、工程图标注，那 text-to-cad 现在还远不能胜任，甚至都会在细节处给你挖坑。另外，如果你从事的是高精度的模具设计、注塑件设计，对拔模斜度、分型线、缩水率等工艺细节要求很高，那 AI 生成的通用模型只能算一个起点，你还得老老实实用专业软件去精修。所以它更像一个“把草图画出来的助手”，而不是替你把所有设计都做好的工程师。

2. 技术链路拆解：AI 不是“画图”，而是在“写程序”

很多对 CAD 不太熟的人以为 text-to-cad 是 AI 直接“画”出一个三维模型，这个理解容易误导。其实现在主流的、效果稳定的 text-to-cad 实现，本质上是让 AI 做“程序合成”，也就是把自然语言翻译成一段参数化建模脚本，然后再由 CAD 内核把脚本计算成实体。

2.1 从自然语言到结构化意图

整个流程的第一步是自然语言理解。这一层要完成的事情就是把模棱两可的话变成计算机能执行的结构化意图。举个例子，你说“一个底座，四角带孔”，这句话拆解下来其实是：

• 基础特征：底座，形状大概率是一个长方体或者圆角长方体
• 特征数量：四个孔
• 特征位置：四角
• 孔的属性：直径未指定，默认可设为一个合理范围

大语言模型的优势在于，它可以结合上下文推断这些潜台词。你说“M5 安装孔”，它就懂这代表直径 5mm 的孔；你说“沉头孔”，它就能生成相应的锥形外形或者加注释。这部分能力和模型本身对机械加工语言的语料理解有很大关系，英文数据的质量普遍高于中文，所以我强烈建议你就算用中文提问，也要把关键尺寸和参数用数字明确出来，别指望它去猜。

2.2 为什么主流方案都选择代码生成而非直接生成网格

你可能会疑惑，现在 AI 生成 3D 模型不是挺成熟了吗？像文本生成点云、文本生成网格的论文一大把，为什么做 CAD 偏偏要走代码这条路？这是我们实际使用中对比下来最关键的取舍。

直接生成网格（Mesh，比如 STL 格式）的好处是视觉效果很直观，适合做游戏模型、动画资产。但工程上这是个灾难：网格是三角形的集合，没有圆角半径、没有孔径这样的特征参数，也没有修剪过的历史特征，你很难在 CAD 软件里编辑它，更别说做精确的装配和有限元分析了。CAD 模型要求的核心是 B-rep（边界表示），也就是用面、边、顶点和拓扑关系来定义实体，这种表示才能支撑圆角、倒角、布尔运算、参数驱动等操作。

所以目前最成熟的技术路线是让大语言模型生成 CadQuery、OpenSCAD 或者 FreeCAD 宏这类参数化建模代码。代码本身就是参数化模型，你可以随时改一个数字重新生成；代码也能被审查——AI 生成错了，人看一眼代码就能定位问题；代码还可以复用——十个相似零件改改参数就全出来了。这个选择在工程上才是理性的。

2.3 最终执行：CAD 内核如何把代码变成实体

代码写出来不等于模型出来了。CadQuery 这类库是通过 Open CASCADE（OCC）这个开源几何内核来执行计算的。OCC 负责做曲面的解析计算、拉伸扫描、倒圆角、布尔并集差集、以及最终的 STEP、STL 文件输出。

这个过程有点像一个机器人厨师：大语言模型是菜谱作者，它写清楚“用什么料、按照什么顺序、切成多大”，而 OCC 内核是那个执行命令的厨师，它按照代码一步一个计算，最终摆盘出一道菜。如果菜谱写错了，厨师不会帮你改，只会报错或者端上来一个形状怪异的玩意儿。所以你会发现 text-to-cad 生成的内容质量上限，一方面取决于 LLM 对建模代码的熟悉程度，另一方面取决于你给出的描述是否没有歧义。

3. 工具选型：从在线玩具到本地生产流水线

text-to-cad 这个方向虽然新，但能上手的工具已经比大部分人想象的多。我整理了自己实测过的几类方案，给它们按工程可用度排了个序。

3.1 主流方案横向对比

在线工具最适合让你快速验证一下 text-to-cad 到底是什么感觉，输入两句话，等十几秒，下载一个 STEP 文件，在任意 CAD 软件里打开看看。但它的局限也很明显：你没法控制它内部生成的建模逻辑，描述里稍微深一点的约束它就做不到，下载下来的文件基本是一锤子买卖。

如果你真的想把它用到工作中，我的建议是走“大模型 + CadQuery”路线。原因很简单：CadQuery 的代码表达的是真实设计参数，它和加工需求的对应关系非常直接，改代码就是改零件，代码还能进版本管理。而且 CadQuery 导出的 STEP 文件能被主流 CAD 软件无损打开，这一点在工程交付里太重要了。

3.2 我推荐的起步组合

如果你现在想试又不确定怎么下手，我给你一个稳妥的组合：用你顺手的中文或英文大模型对话工具，加上本地的 CadQuery Python 环境。大模型负责把自然语言描述转成 CadQuery 代码，你负责审查和改代码，CadQuery 负责执行生成模型。这一套组合的启动成本很低，一台普通办公电脑就能跑，不需要独立显卡，不需要训练模型。

我之前还试过让大模型直接给 FreeCAD 写脚本，能在 FreeCAD 里直接打开看到实体，也很方便。但 FreeCAD 的 API 比 CadQuery 啰嗦，大模型犯错的概率明显更高，写一行 CadQuery 解决的问题，在 FreeCAD 里可能要写五六行。除非你后面一定要在 FreeCAD 图形界面里做装配，否则我建议先在 CadQuery 里出模型，再转成 STEP 去其他软件里做装配。

4. 实操实录：用 CadQuery 把一句中文变成 STEP 文件

理论说了一堆，接下来进入实战。这一节我会完整展示从写提示词、生成代码、检查代码到导出模型的流程，你完全可以照着操作。

4.1 环境准备

先安装 CadQuery。最省事的方式是用 conda：

conda install -c conda-forge cadquery

如果你用的是纯 Python 环境，也可以直接：

pip install cadquery

但注意，CadQuery 依赖 OCC 这个大体积的 C++ 库，pip 安装的成功率在 Windows 上偶尔会有小问题。如果装失败，最简单的办法就是把 conda 环境管理好，不要自己在系统 Python 里硬装。装完之后验证一下：

import cadquery as cq print(cq.__version__)

能打印出版本号就说明环境没问题。这一步听起来基础，但我见过太多人是死在环境安装上的，CadQuery 和别的不一样，它不是一个小脚本能带动的库，千万不要在自己不熟悉的 Python 环境里暴力安装。

4.2 提示词怎么写才不容易翻车

有了环境，真正决定模型质量的是你的自然语言描述。我实测下来，写提示词有四个原则：

第一，把尺寸参数全部说死，不要留模糊空间。不要写“一块比较大的板”，要写“长 120mm、宽 80mm、厚 8mm”。第二，明确特征的位置基准。你说“四个角打孔”，AI 可能会把孔放在角上，也可能放在距边 5mm 处，你得写清楚“孔中心距边缘 10mm”。

第三，指定通孔还是盲孔、圆角还是倒角、贯穿还是不贯穿。这是加工里最容易出错的地方，AI 默认有时候会做出你没想到的形状。第四，如果对某个地方有工艺要求，单独强调。比如“所有孔都要贯穿”，而且要让 AI 在处理圆角时考虑到孔的边界距离。

我经常用的一个提示词模板大概是这个样子：

请写一段 CadQuery 代码，实现： 一块矩形底板，长 100mm，宽 60mm，厚 5mm，底板底部不居中，底面贴在 Z=0 平面。 在顶面四个角处分别打一个直径 5mm 的通孔，四个孔中心距相邻边缘均为 10mm。 顶面周边倒圆角半径为 2mm。 单位使用毫米。 只输出完整可运行的 Python 代码，不要解释。

你把这个提示词发给一个大模型，它返回的代码往往已经能跑了。但你千万别直接就去生成模型，先花半分钟读一遍代码，对照需求检查尺寸和坐标，这个习惯能帮你避开 70% 的翻车。

4.3 从代码到模型的完整示例

为了让这篇博文不依赖任何在线服务，我直接给一段我验证过的 CadQuery 代码，对应上面那句描述。你可以先跑这个，再尝试让 AI 自己生成其他变体。

import cadquery as cq # 底板：长100mm，宽60mm，厚5mm，底面位于Z=0 base = ( cq.Workplane("XY") .box(100, 60, 5, centered=(True, True, False)) ) # 在顶面四个角打孔，孔心距边缘10mm plate = ( base.faces(">Z") .workplane() .pushPoints([(-40, -20), (40, -20), (-40, 20), (40, 20)]) .hole(5) ) # 顶面周边倒圆角半径2mm（注意这不是孔倒角） plate = plate.edges(">Z").fillet(2) # 导出 STEP cq.exporters.export(plate, "plate_with_holes.step") # 顺便看一眼体积，用于校验 print(plate.val().Volume())

这段代码里有两个容易被忽略的细节。第一，centered=(True, True, False)表示底板在 X、Y 方向居中，但 Z 方向不居中，底边贴着 Z=0，这样所有的孔位置都是以底面为基准算出来的，符合真实加工习惯。第二，pushPoints里的坐标算的是孔中心的绝对坐标，这里-40和-20是相对中心点的偏移：底板长 100，孔中心距离边缘 10，所以中心距离底板中线的 X 偏移是100/2 - 10 = 40；Y 方向同理，60/2 - 10 = 20。

跑完代码后，你会得到一个plate_with_holes.step文件，以及一个体积数值。这个体积可以用来快速检查模型是否合理：底板的毛坯体积是 100×60×5 = 30000 立方毫米，四个孔各去掉约 π×2.5²×5 ≈ 98.17 立方毫米，四孔合计约 392.7 立方毫米，所以预期体积约为 29607.3 立方毫米。如果打印出来的数值和这个差很多，那说明某个特征生成出了问题，需要回头检查代码。

4.4 参数与单位：最容易踩的坑

CadQuery 默认的单位是毫米。如果你的描述里用了英寸、厘米，而 AI 没有及时转换，那生成出来的零件尺寸会完全离谱。我唯一一次生成出一个“一米长的电路板支架”，就是因为我写的需求用了英寸单位，而大模型没有统一换算。所以我的习惯是，每条提示词最后都强调一句“单位使用毫米”。

另外一个坑是坐标基准。机械设计里经常用到的是“顶面定位”“底面定位”“侧面定位”，而这些在 CadQuery 里对应的是不同的面选择语法，比如faces(">Z")代表 Z 轴正方向的面，>X代表右侧面，<Y代表前面的面。AI 模型很容易在这类面上犯糊涂，你检查代码时也要重点看面选择是否和你的意图一致。

5. 实战问题排查与避坑速查

text-to-cad 用多了，你会慢慢总结出一些规律。AI 生成模型出错的方式其实就那么几类，这里我把高频问题和排查办法整理成一张速查表，方便你在翻车时快速定位。

5.1 高频问题与解决速查表

这里面最值得单独提一下的是导出格式的问题。很多人辛辛苦苦生成了模型，然后发现导出的 STEP 在 SolidWorks 里能打开、能测量，但没法像原生文件一样在左侧特征树里改参数。这个不是 text-to-cad 的 bug，而是 CAD 数据格式的天然限制——STEP 是用于不同软件之间交换几何用的，它本来就不保存建模历史。如果你需要的是可编辑的原生模型，那 CadQuery 的源码本身就是你的“特征树”，改代码就是改模型，比单纯改 STEP 方便得多。

5.2 几个只在实际使用中才发现的细节

第一件我要强调的事：别让 AI 一次生成太复杂的模型。我试过让它一次做一个带导轨、卡扣、线槽、散热孔的外壳，结果代码超过了两百行，中间任何一个布尔运算出错，整个模型就没了。后来我把需求拆成五个小零件，分别生成，再在 CAD 软件里装配，成功率立刻高了很多。AI 生成代码的能力是强，但它对长上下文里的几何关系维护能力有限，你让它一口气做太多，它就会顾此失彼。

第二件是关于“中文和英文混用”的体验。我曾经让大模型用纯中文生成 CadQuery 代码，结果它把变量名都写成了拼音，比如dikuan（底宽）、kongjing（孔径），代码虽然能跑，但完全不能维护。后来我改成让代码里的变量、注释都用英文，自然语言描述用中文，这样生成的代码质量高很多，后续维护也方便。

第三件是我个人特别受用的一个技巧：让 AI 先生成代码，在重要的位置加上print语句输出特征信息，比如体积、孔的数量、台体高度。这样你跑完代码就能在控制台看到这个模型的关键参数，不用每一次都去软件里测量。AI 第一次给你的代码里大概率不会有这些调试输出，你得自己要求它加，但这件事非常值。

6. 除建模外，还能给日常 CAD 工作带来什么

聊到这里，其实你也能感受到，text-to-cad 的价值不止于“把一句话变成模型”这个炫酷动作。它真正持久的地方在于和现有工作流结合，把重复劳动降下来。

6.1 批量生成标准件与参数化模板

机械设计里最烦的工作之一就是搭标准件库。法兰、支座、支架、底板，规格几百种，长得都差不多，就是尺寸不同。传统做法是建一个三维模型，然后用配置和方程式驱动，但搭一套驱动关系也挺费劲。现在有 text-to-cad 之后，我可以让 AI 按照规格表批量生成 CadQuery 脚本，每个脚本的变量对应规格表里的长、宽、高、孔径，然后写个小循环把这些脚本跑一遍，瞬间得到几百个 STEP 文件。

我做过的实际案例是帮朋友生成一组设备法兰。规格表里有一百多个不同尺寸，要是人工建模，一星期都未必做完了。而我写了五十行 Python，让大模型生成 CadQuery 模板代码，再用循环批量改参数运行，十分钟就把全部 STEP 文件导出完毕。当然，这不完全是 text-to-cad 的功劳，但 AI 确实让模板代码的编写门槛降到了只要会描述设计意图就行。

6.2 它和传统 CAD 痛点之间的关系要拎清

现在网上关于 CAD 的讨论很多集中在安装卸载、字体缺失、图纸合并这些问题上。我理解这些确实是日常痛点，但坦白讲，text-to-cad 目前解决不了这些，它不是一个 CAD 管理工具，也没有能力解决 shx 字体、激活脚本、软件卸载残留这类问题。它的核心边界是“从无到有地生成模型”，至于生成完之后怎么管理、怎么处理图纸、怎么修字体、怎么合并布局，那是另一个层次的事，不能指望一句话生成模型就把整个 CAD 生态的问题都解决掉。

我在实际工作中总结的准则是：把 text-to-cad 当作一个“设计意图翻译机”，它负责把口语化的需求变成参数化、可加工、可交付的模型基线。一旦基线建立，后续的工程分析、出图、调整，都是你作为工程师的价值所在。这一点想明白了，你就不会对这个技术产生不切实际的期待，反而能把它用得更好。

7. 一点我自己的使用体会

最后分享一条真实的心得。text-to-cad 目前还不够聪明，它经常会犯“看着合理但仔细想又不对”的错误。比如它会自动给你的孔加一个装饰性的沉台，结果你要的是通孔；它会默认底板居中对齐，但实际加工你更希望一角对齐。这些细节没有一个共同规律能帮你全部避免，唯一的方法是养成“审代码”的习惯。不要只盯着最终的 STEP 模型看，要回到代码层面检查坐标、检查特征顺序、检查单位。代码就是 AI 的“思考过程”，你能看见思考过程，就等于拥有对模型的完全控制权。

我用这个流程跑了几个月之后，最明显的感受不是建模变快了，而是方案阶段的试错成本变低了。以前改一个孔的位置，至少要进软件里编辑草图、更新约束，现在只需要改代码里的一个坐标参数，重新运行，几秒钟就拿到新版模型。这种“用代码驱动设计、用文字描述意图”的工作方式，我认为才是 text-to-cad 给这个行业带来的真正改变。只要你有耐心把每个提示词写清楚、把每次生成结果认真审一遍，它会是一个比你想象中可靠得多的队友。