企业官网建设流程全解析

最近有个朋友找我救火：客户发来一个三通管的需求，要尽快出一个3D模型报价。他手头只有一段一百多字的文字描述，连个像样的草图都没有。要在过去，我肯定得打开CAD软件，从基准面开始画草图、加约束、拉伸、打孔，折腾大半天。这次我试了试用text-to-cad的思路，把那段文字直接丢给大模型，让它生成一段CadQuery脚本，再跑出实体模型。虽然中间改了几轮，但整体速度确实快了很多。这个经历让我意识到，text-to-cad已经从论文里的概念，逐渐变成了能实际干活的工具。

text-to-cad，一句话概括就是：用自然语言描述一个三维模型，让AI生成可编辑的CAD模型或能构建模型的脚本。它瞄准的不是"画图"这个动作，而是把设计意图翻译成几何操作的核心问题。无论你是机械工程师、产品设计师，还是偶尔需要做模型的创客，只要还在跟三维建模打交道，这个东西都有资格进入你的工具箱。这篇文章我会从技术原理、实操过程、踩坑经验和工程落地方案四个维度，把我这段时间折腾text-to-cad的真实记录完整分享出来。

1. 当"一句话需求"开始挑战传统建模流程

1.1 传统参数化建模的高门槛与低效率

我从SolidWorks入门，后来用了十几年Creo和FreeCAD，太清楚传统参数化建模的繁琐了。画一个带法兰的三通管，你需要先新建零件，选择基准面，画中心线，画旋转轮廓，再旋转切除内部空腔，然后拉伸法兰、画螺栓孔圆形阵列、倒角……每一步都依赖快捷键、菜单层级和对约束关系的理解。新手光是把"草图完全定义"这个概念搞明白，就得花几个星期。

更麻烦的是，客户的原始需求往往不是精确的尺寸表，而是"类似这种样子的三通，接口带法兰，孔位按标准来"这类模糊描述。工程师拿到这种需求，得先自己脑补一个模型，再动手画。整个过程的设计意图传递严重依赖人的经验和空间想象力，沟通成本极高。

1.2 text-to-cad的本质：设计意图到几何操作的自动翻译

text-to-cad真正要解决的不是"建模"本身，而是"读懂需求并拆解成建模操作"这个环节。它把自然语言描述中的实体（法兰、肋板、孔）、属性（厚度、直径、数量）和空间关系（平行、同轴、等距）抽取出来，映射成一系列CAD内核能执行的几何操作，比如拉伸、旋转、布尔运算、阵列。

理解这一点很重要，因为市面上的工具虽然都叫text-to-cad，但底层逻辑完全不同。有的生成一个网格文件（STL），有的生成参数化脚本，有的直接生成B-rep实体。它们的可编辑性、精度和工作流整合难度，天差地别。你如果只是想要个效果图，那么网格文件就够了；但如果要出工程图、做数控加工或者做装配分析，那必须拿到带参数和特征的实体模型。所以，选择哪种text-to-cad方案，本质上取决于你下游要用模型来干什么。

2. 拆开黑盒：三类主流技术路线和它们各自的脾气

2.1 代码生成派：让语言模型写脚本，CAD内核负责执行

这条路线的代表做法是把大语言模型和CadQuery、OpenSCAD这类程序化建模库绑定。大模型不直接生成几何体，而是生成一段Python脚本或OpenSCAD代码，再由解析器执行代码，调用CAD内核计算实体。

优点非常明显：输出结果天生是参数化的，尺寸、特征都写在脚本里，出一万个模型也能随时改。而且代码可以被版本管理工具追踪，适合团队协作。缺点是建模能力受限于脚本库的表达范围。CadQuery擅长机械零件、钣金、螺纹这类规则几何，但你要生成一个有机曲面、一个雕塑造型，它就无能为力了。

这个路线的提示词设计必须有"编程思维"。你不能只说"给我一个花瓶"，最好说"用旋转体命令，轮廓点由以下列表定义……"，否则大模型大概率会写出一段语法正确但几何错误的东西。我后面会详细说提示词怎么调。

2.2 原生生成派：直接预测B-rep或网格几何体

另一条路线是把三维几何生成当图像生成来做。学术界比较有代表性的工作，比如多模态大模型直接解码出体素、点云、隐式场或者网格。这类方法输入文本，输出常见的STL或OBJ文件。

优点是能生成任意形状，包括自由曲面、手办摆件、抽象雕塑，这是脚本参数化很难实现的。缺点是输出结果通常是非参数化的网格，缺少特征树和设计历史，想改一个孔的直径，基本等于重做。而且网格质量参差不齐，拓扑错误、破面、非流形边很常见，拿到CAD软件里经常直接崩溃或无法精确测量。

如果你只是做概念展示、3D打印摆件，这条路线的工具可以用。但如果你要做机械结构设计，原生生成派目前还只能当灵感来源——看一眼形状，然后自己在CAD里重画。在制造领域里，网格模型和B-rep模型的鸿沟，远比外行人想的要大。

2.3 混合派：语义解析加模板参数化组装

第三类路线介于前两者之间，可以理解为"用语义解析器从文本中抽取意图，再从预先定义的特征模板库里组装模型"。比如说，用户描述"带6个孔的圆形法兰"，系统就先识别出"法兰"这个语义概念，然后调用法兰模板，把直径、厚度、孔数、螺栓圆直径填进模板参数。

这种方式最接近人画图时的思维方式：先用标准件/常见结构打底，再往里填尺寸。优点是生成可靠、特征规范，不会出现拓扑错误；缺点是模板之外的内容没有创造力，遇到非标形状基本就干瞪眼了。

它在实际BIM和机械设计软件里用得比较多，很多软件商所说的"AI辅助建模"其实就是这个思路。对于用户来说，它的学习成本最低，但因为限制了特征范围，所以不适合所有场景。

不管哪条路线，现在都在快速进化。针对机械设计场景，代码生成派目前最靠谱，因为它保住了"可编辑"这条命根子；针对消费品、文创场景，原生生成派视觉效果更好；针对标准件、管道、建筑构件，模板混合派效率最高。所以，没有哪个绝对最好，只有哪个更适合你要干的事。

3. 一次真实的text-to-cad实操：从文字到法兰盘模型

3.1 环境准备：我选了哪条路线，为什么

为了写这篇文章，我专门搭了一个最小可复现的环境。我选择的是"代码生成派"：用一个大语言模型的API（这个很普遍，我可以直接通过官方接口调用），配合CadQuery作为几何引擎。为什么选这条路线，有三个原因。

第一，CadQuery生成的模型是带特征的实体，可以用FreeCAD直接打开，也能导出STEP文件，后续做装配和制造都没问题。第二，脚本可修改，我可以通过迭代提示词快速调整。第三，CadQuery在Python生态里安装简单，pip install cadquery就完事，不需要商业许可证。

环境清单大致如下：

• Python 3.11
• CadQuery 2.4
• 大模型API：我选用的是某在线大模型接口，支持联网工具调用，但text-to-cad这里不需要联网
• 可视化：直接用VTK或者把STEP拖进FreeCAD检查

需要提醒的是，大模型API有上下文长度限制，复杂零件描述太长会被截断。我的做法是把描述拆成"总体形状"和"特征列表"两部分，分批喂给模型，最后再让它合成完整脚本。

3.2 提示词工程：如何把模糊需求变成机器能懂的约束

第一次尝试时，我给模型的是这种提示词：

"创建一个法兰盘，外径100，内径50，厚度20，有6个螺栓孔。"

模型生成了一段看似合理的CadQuery代码，但运行后我傻眼了：螺栓孔直接在法兰端面上打穿，没有任何沉头；而且螺栓孔的圆周分布位置是默认从0度开始的，导致与我预想的孔位对不上。这暴露出一个核心问题：自然语言里的省略信息，模型会按照它自己的默认值脑补，而这些默认值往往不符合你的加工标准。

经过几轮尝试，我整理出了一套模板，大家可以直接抄作业：

以毫米为单位，创建名为flange的零件。 第一步：在XY平面上拉伸一个圆柱，外径100，内径50，高度20，拉伸方向为Z正方向。 第二步：在圆柱顶面创建6个通孔，直径10，分布在直径80的螺栓圆上，第一个孔位于X正方向，角度按逆时针均匀分布。 第三步：对所有锐边添加1mm倒角，排除螺栓孔内边。

关键点有三个：明确单位、明确基准（哪个平面、哪个方向）、明确特征的定位基准（螺栓圆直径和起始角度）。这跟给新来的设计助理交代任务是同一个逻辑，你说得越具体，他画出来就越接近你要的东西。

3.3 结果生成与验证：不能只看渲染图

跑脚本生成STEP文件后，我把它导入FreeCAD，做了三件事验证。

• 用测量工具核对最大外径，精确到小数点后三位，确认不是视觉上的"差不多"
• 检查特征树，确保每个孔都是独立特征，而不是一个合并的网格
• 做了一次截面检查，确认通孔从顶面贯穿到底面，没有内部残留

这步看起来基础，但特别容易被跳过。不少text-to-cad工具自带浏览器预览，那个预览用的WebGL渲染器对几何做了简化，有的甚至直接显示网格，你看着没问题，细看全是坑。所以我的习惯是：无论什么工具生成的模型，进入正式流程前必须经过原生CAD内核验证一遍。这个习惯在后续项目里帮我避开过不少返工。

4. 实操两周后，我总结的五个高频坑

4.1 单位混乱是最大的暗雷

大语言模型在单位上的表现非常不稳定。有时你说"厚度20"，它当成英寸，结果生成一个508毫米的巨型法兰；有时它用公制输入，但内部计算用英寸，输出就完全错乱。

解决的办法是在提示词里刻意强调，并且把关键尺寸写全，不要用"大约""左右"这类词。我还试过在脚本开头强制加一句UNITS = 'mm'的注释，并在每个尺寸参数后标注# mm，这样大幅降低了模型单位脑补的概率。如果你要跟客户对接模型，交付前一定要在CAD软件里用分析工具检查物理属性，尤其是体积、表面积和质心，如果这些数量级不对，十有八九是单位出问题了。

4.2 倒角和圆角的位置与顺序

倒角看起来是小事，但对加工影响很大。AI生成的倒角常常出现在它觉得"好看"的地方，而不是你需要的功能位置。比如法兰的密封面需要保留直角，结果AI给整个外轮廓倒了一圈圆角，导致密封面失效。

我的建议是，把倒角、圆角指令和主体特征分开放到提示词最后，并且明确"排除"哪些面。如果你用CadQuery，还可以在脚本里选定面集合，用faces筛选器精确控制。不要图省事让AI自己判断倒角范围，它判断不了你的装配工况。

4.3 草图平面和拉伸方向：AI对"上下左右"没有直觉

让大模型生成一个"L型支架"，它可能把第一段草图放在XY平面，拉伸方向沿Z轴正方向，但第二段本应在XY平面内弯折的草图，它可能也沿Z轴拉伸了，结果根本不是L型，而是一个阶梯柱。空间关系是自然语言里最难表达的维度。

应对套路有两个：第一种是在提示词里用"草图在XY平面，拉伸方向为Z正半轴"这种几何语言精确描述；第二种是接受首版结果的歪，然后用脚本修，反正参数化脚本改起来快。我反复修改了几次后，干脆总结了一句话："别让AI猜空间方位，你直接把方位喂给它。"

4.4 标准件和特征数据库的缺失

工业设计里，很多结构不是凭空画的，而是调用标准件库，比如GB/T螺栓、密封圈、轴用卡簧槽。text-to-cad模型没有这些标准库的概念，它理解"卡簧槽"就是"一个凹槽"，但具体槽宽、槽深、倒角半径这些国标参数，它并不会帮你自动套用。

我在测试时让它生成一个带O型圈槽的轴端，它给出的槽宽是5mm，实际根据GB/T 3452.1，内径80的轴用O型圈槽宽应该是3.55mm左右。这类问题的根源是训练数据里缺少标准手册的字段语义，模型只是学到了"凹槽+圆环"的形状关联，学不到精确的规格表。所以，text-to-cad适合做结构草图，但涉及标准件和装配公差时，最后仍需要工程师查表修正。这不是AI不够聪明，而是工程标准本身就游离在自然语言文本之外。

4.5 参数化失效：生成的模型改不了尺寸

这是最坑的一个。很多宣称"text-to-cad"的在线工具，生成的就是一个三角网格，看起来能下载STEP，实际只是网格包裹。你拿回CAD想改个直径，会发现没有特征树，没有任何可编辑参数，只能退化成哑巴实体。甚至有些更狠，直接给你一个STL，CAD软件打开后连实体都不是。

我的预期管理是：能输出STEP且能被识别为实体模型，才算"可用的CAD模型"。如果你拿到的STL，那它就是设计参考，不是工程交付物。判断方法很简单，用FreeCAD或者任何专业CAD打开，点一下模型看能不能选中一个"面"并测量面积，如果能，至少还是实体；如果只能选到"网格面"，那就不能用在装配和CAM里。

5. 如何把text-to-cad塞进真实工作流，而不是供起来

5.1 它最适合的环节：概念设计、方案比选和快速验证

把text-to-cad当"正式建模工具"用，现阶段必然要骂娘。但把它当"概念设计加速器"，体验完全不一样。

比如接非标自动化设备的单子，客户需求经常是"我们需要一个带观察窗的防护罩，尺寸大概600x400x300，窗口200x150，材质亚克力"。传统做法是建一个公模草模，再拆分成钣金件。用text-to-cad，我让AI直接生成一个初步的六面体防护罩，带窗口切除和底座折弯，然后导进SolidWorks里细化钣金参数，整个过程压缩了大概四十分钟。做方案比选尤其占便宜：你先让AI生成三个不同形态的底座方案（A型、B型、C型），渲染图一摆，客户选哪个，你再在选中的那个基础上精细建模。这不叫抢设计师饭碗，这叫把前期试错的成本砸下来。

5.2 从"生成模型"到"生成制造方案"：还有几道坎

text-to-cad即使生成完美几何体，离制造仍然有距离。一是公差标注，CAD模型里的公差信息是语义级的，不是几何级的，AI生成STP时根本不会附带GD&T符号。二是表面粗糙度，模型里没有这个属性，需要工艺人员在图纸上补。三是工艺可行性，AI不知道你厂里的机床有多大行程，不知道你用的棒料直径是哪种规格，它生成的壁厚可能在强度上没问题，但加工出来会震刀。

所以我现在的工作流是把text-to-cad的输出定位为"带着设计意图的半成品"。几何结构有了，材料、公差、表面处理和工艺方案这些，必须由工程师补全。与其抱怨AI不生成这些，不如把它当两个月薪八千的新人画图员，画完草图你总得自己拿主意的。这样心态就平衡了，而且出活速度快很多。

5.3 人机分工的边界：哪些环节必须人来管

根据我这两个月的实测，有几件事建议永远不要交给AI，至少现阶段不要。

• 涉及安全法规和强制标准的零件结构（压力容器、承重连接件）不要直接使用生成结果，必须有持证工程师复核
• 与装配体强相关的配合尺寸不要用AI初值，必须基于配合件实际公差计算
• 需要仿真的模型不要从网格生成，必须重建为实体后再做有限元或CFD

反过来，适合AI做的是：快速生成包容空间、特征布局草图、通用钣金外壳、曲面造型的概念稿、以及标准化文档转参数化模板。这个分工我用了两周，最大的感受是不用再为了一个初步方案去死磕草图的完全定义了。把那些重复的、低认知的操作交给脚本和语言模型，把真正需要工程判断的部分留在自己手里，这比争论"AI能不能替代工程师"有意义得多。

最后再分享一个我实际用出来的小技巧：如果你经常用text-to-cad，建立一个属于你自己的"提示词-脚本对"库。每次生成出满意的脚本，就把提示词连脚本一起存成模板，下次遇到类似零件直接改参数，而不是重新让AI从头生成。我现在这个库里已经有法兰、支架、齿轮箱壳体、钣金折弯件、管接头等十几种常用模板。用一次提取一次，时间越久，你的text-to-cad就越来越像你的私人参数化零件库，而不是一个每次都要重新调教的陌生模型。这可能是目前这个阶段，把text-to-cad落地到工程实践里最实在的经验了。