企业官网建设流程全解析

上周接了个非标设备的小单，客户甩过来一句话：“80乘50的铝法兰板，厚8毫米，四角倒R8圆角，中心一个直径16通孔，四角各一个M6螺纹孔。”搁以前，我得打开SolidWorks建草图、拉特征、打孔阵列，运气好十分钟出第一版。这次我想试试另一条路：让这句话直接变成可编辑的三维模型。这就是我最近一直在折腾的text-to-cad方向——从自然语言直接生成CAD模型，不是渲染图，不是三角网格，而是能继续改尺寸、能导出STEP、能拿去加工的参数化实体。

text-to-cad这个名字听起来像是“文生图”的3D翻版，但实际做起来完全是另一套逻辑。它要解决的痛点很明确：传统CAD建模的瓶颈不在鼠标操作，而在“把设计意图翻译成特征序列”这件事本身。如果你的脑子和软件之间能直接对话，把重复性的基础建模工作交给AI，那设计效率的提升是量级的。这篇文章不聊论文里的花活，我就按实际工程视角，讲讲text-to-cad的技术路线、我实测跑通的一条完整链路，以及哪些场景值得率先落地。

1. text-to-cad到底是什么：它不是文生图，更不是文生3D网格

先说一个最容易混淆的点。你让AI画一张“法兰板”的图片，它能画出以假乱真的渲染图，但你没法把这图片塞进数控机床。你也可能见过生成3D网格的工具，比如输入“一把椅子”，输出一个带纹理的.obj或.glb文件，这种模型放到游戏引擎里没问题，可丢进SolidWorks里就是个没法编辑的“死模型”。text-to-cad的目标是第三层：输出真正的CAD实体——带几何拓扑、带参数约束、带建模历史的模型文件。

1.1 “从文字到三维”里的三道分水岭

我把现在市面上“从文字到三维”的技术分成三条路线，分水岭就是输出物的工程可用性。

第一条路线是文生图加多视图合成。典型做法是用扩散模型生成多视角图像，再通过神经辐射场或高斯泼溅重建出三维几何。这条路线视觉效果好，但输出是网格或者隐式表面，没有精确的几何尺寸，更别说参数化关系。它适合做概念展示、美宣图、游戏资产，但不适合做机械件、建筑构件。

第二条路线是文生网格模型。像点云生成、SDF重建这类方法，能直接输出三角网格。相比渲染图，它有了真正的空间几何，可以3D打印看外形，但问题在于网格是离散的，没有面、边、孔、螺纹这类工程语义。你没法对它做倒角修改，没法改一个参数让所有关联尺寸自动更新，更没法给CAM编程提供干净的B-rep面。这种模型在工程软件里基本属于“装饰品”。

第三条路线才是text-to-cad——生成参数化CAD模型。输出可以是带特征历史的B-rep模型，也可以是描述建模步骤的脚本或结构化序列。它保留了设计意图：这个面是拉伸出来的、那个孔是阵列得到的、圆角和孔之间有依赖关系。你拿到以后可以改参数，可以让模型重新生成，可以导出STEP或IGES给上下游。这个差异，决定了它是工程工具，而不是花瓶。

1.2 “可编辑”到底指什么：特征树、参数和约束

很多刚接触text-to-cad的人会问：我拿到的模型别人能编辑吗？这就要说到CAD模型的三个核心概念：特征树、参数、约束。

特征树记录了建模历史，比如“先建草图→拉伸成板→倒角→打孔”，每个节点就是一个特征。有特征树意味着你可以回到任意一步修改。参数是特征树的数值输入，比如拉伸深度、孔直径、倒角半径。约束则定义了特征之间或草图内部的关系，比如“四个孔关于中心对称”“孔的圆心到板边距离相等”。

用个生活化类比：三角网格模型就像用泥巴捏的雕塑，好看，但想拧个螺丝上去没门；CAD模型像乐高拼的机械结构，每个零件、每个连接点都清清楚楚，换一块砖头就知道整体变化。text-to-cad的核心目标，就是让AI生成的模型具乐高式可拆解性，而不是泥巴式外观。理解了这一点，你才能理解为什么技术路线选择比模型“像不像”更重要。

2. 让机器听懂CAD语言：文本指令如何变成建模步骤

把一句话变成CAD模型，本质上是个“翻译”问题：把自然语言翻译成CAD系统的操作序列。这个翻译过程牵涉三个关键技术环节：意图解析、约束求解、几何序列化。

2.1 从自然语言到结构化建模脚本

第一步是让大语言模型理解设计意图。注意这里的“理解”不是泛泛的语义匹配，而是要抽取出可执行的参数结构。我用一个实际例子拆解，输入“80乘50的铝法兰板，厚8毫米，四角倒R8，中心一个直径16通孔，四角各一个M6螺纹孔”，LLM需要抽取的结构大致如下：

{ "主体": { "类型": "矩形板", "长": 80, "宽": 50, "高": 8, "材质": "铝" }, "圆角": { "目标": "四角", "半径": 8 }, "孔特征": [ { "位置": "中心", "类型": "通孔", "直径": 16 }, { "位置": "四角", "类型": "螺纹孔", "规格": "M6", "数量": 4, "布局": "均布" } ] }

这种结构化抽取比直接生成模型的成功率更高，因为它是“参数级”的映射，而不是“端到端”的猜测。把抽取结果转成建模脚本时，又有两条技术路线：一条是生成OpenSCAD或CadQuery这类代码脚本，另一条是直接生成CAD软件的历史记录文件。前者开源可控，适合快速验证；后者更接近工业软件原生数据格式，但实现难度高。

2.2 约束推理：模型不是“长得像”就行

CAD模型的灵魂不在尺寸数字，而在约束关系。人类设计师说“四角各一个孔”时，默认包含了均匀分布、相对中心对称、孔与板边缘有合理距离等隐含约束。LLM要能把这些“不言自明”的部分推理出来，并且用代码形式表达。

实际操作中，我通常会在提示词里明确要求模型输出五大类约束：几何约束（相切、垂直、平行）、尺寸约束（长度、角度）、位置约束（同心、对称、等距）、拓扑约束（孔必须穿透板厚、倒角不能切穿相邻孔），以及单位约束（默认毫米）。如果缺失约束推理，生成的模型容易出两类问题：一是孔的位置随机分布，看着在四角，实际不对称；二是倒角导致相邻孔边缘被切穿，加工直接报废。

约束求解是text-to-cad工程化的难点。生成的脚本在计算时，CAD引擎要判断约束是否一致、是否有解。比如你同时要求“板厚8毫米”和“倒角半径10毫米”，几何上就冲突了。好在现代CAD脚本库（如CadQuery、OpenCascade）在建模时会抛出几何异常，我们可以在代码层捕获并反馈给LLM做修正，形成“生成→验证→再生成”的闭环。

2.3 序列化草图：把几何变成token序列

如果想从数据驱动的角度训练一个专用text-to-cad模型，关键技术是如何把CAD建模过程表示成模型能处理的序列。这就像一个厨师写菜谱，建模过程就是一系列有序操作：画直线、画圆弧、加约束、拉伸、倒角、打孔。DeepCAD这类研究就是把这个操作序列token化，用Transformer训练生成模型，输入设计序列，让它学着“续写”出完整建模步骤。

Text-to-CAD模型在此基础上加了文本条件：用编码器把自然语言编码成向量，再引导CAD序列生成。这种思路的好处是，模型产出天然带有建模历史，可编辑性极强；坏处也很明显——领域数据稀缺，高质量的CAD序列数据不像互联网文本那样取之不尽。目前公开的CAD数据集规模都不大，这也是text-to-cad落地比文生代码难得多的原因之一。数据少、标注贵、验证难，这是所有在CAD方向做AI的人都要面对的现实。

我个人的判断是：在未来一两年的工程落地中，基于LLM生成脚本+规则验证的方案会走得比端到端生成更快。原因是这个方案对数据依赖小，能用现成大模型的语言能力快速搭建，而且每一步都可解释、可干预。等高质量CAD序列数据积累到一定规模，端到端方案才会体现出效率优势。

3. 实测一条完整链路：从一句话到可编辑的STEP模型

说了这么多理论和架构，接下来分享我最近在本地反复跑的一条可复现链路。这条链路不一定是最优解，但它打通了“文本→参数→脚本→STEP→CAD”的全过程，适合拿来作为你自己的验证起点。

3.1 工具选型为什么是CadQuery，而不是OpenSCAD或FreeCAD

市面上的程序化建模工具有几个可选，我最终选了CadQuery，原因是它在“AI友好性”和“工程可用性”之间最平衡。

OpenSCAD上手简单，但你只能通过CSG布尔运算做几何，生成的模型在主流CAD软件里特征树信息全部丢失，基本是个“伪参数化”模型。FreeCAD的Python API功能强大，但API设计繁琐，AI生成的代码经常因为接口版本、坐标系差异报错，调试成本高。CadQuery封装了OpenCascade内核，提供了一套语义化的Python API，既能做草图、拉伸、倒角、布尔运算，又能导出STEP，更重要的是它的代码风格清晰，LLM很容易生成正确率较高的代码。

另一个实用理由是CadQuery社区活跃，文档和示例丰富，即使LLM生成的代码有问题，搜索引擎也能快速找到解决方案。对AI辅助建模来说，这种“可调试性”比单纯的功能齐全重要得多。

3.2 核心实现步骤与代码

环境准备很简单，Python 3.9以上环境，执行pip install cadquery即可。如果你只需要导出STEP格式，用CadQuery就够了。下面是法兰板案例的一个完整实现：

import cadquery as cq # 底板：80x50x8矩形板 base = ( cq.Workplane("XY") .box(80, 50, 8, centered=(True, True, False)) ) # 四角R8圆角 base = base.edges("|Z").fillet(8) # 中心直径16通孔 base = ( base.faces(">Z").workplane() .circle(8) .cutBlind(-8) ) # 四角M6螺纹孔（按法兰板实际位置：距边缘10mm） base = ( base.faces(">Z").workplane() .rect(60, 30, forConstruction=True) .vertices() .circle(3) .cutBlind(-8) ) cq.exporters.export(base, "flange_board.step")

这段代码里有两个工程细节值得注意。centered=(True, True, False)控制了底板的定位方式，让底面在Z=0平面，方便后续加工坐标系对齐；四角螺纹孔用了forConstruction=True的辅助矩形，它在建模时不产生实体，只用来定位四个顶点，这种写法LLM不一定会主动用，但它能显著提高孔位分布的准确性。

执行这个脚本后，你会得到flange_board.step文件。别急着完事，我还会让LLM输出一份参数化JSON，把80、50、8、R8、16、M6这些关键尺寸全部结构化保存。这样下次客户说“改成100乘60”，不用重新生成脚本，直接改JSON参数再跑一次就行。

3.3 如何保证生成结果可以继续编辑

CadQuery导出STEP之后，模型本身的特征树会丢失，因为STEP是只包含B-rep几何的交换格式。这个问题不解决，“可编辑”就成了一句空话。

我的做法是双轨保存：CadQuery脚本+参数JSON作为“源文件”，STEP作为“交付物”。进入传统CAD软件后，源文件可以随时修改再导出新STEP；而STEP文件则用于下游的CAM编程、出工程图或结构仿真。这其实也是参数化设计的标准流程，只是把“人工在CAD里改参数”变成了“AI生成脚本改参数”。

如果你想在SolidWorks或Fusion 360里直接打开带特征树的模型，那就不能只靠CadQuery。现阶段我会建议用FreeCAD的Python API重建历史记录，或者干脆接受“脚本即源文件”的协作模式——给设计团队配上Git工作流，每次改动留痕、对比、回滚，这种模式在软件团队很常见，但很多机械团队还不习惯。一旦适应，AI生成的代码模型在可维护性上反而优于传统参数化模型，因为每个改动点都对应一段可审查的代码。

4. 生成结果的评测与踩坑实录：别急着上产线

text-to-cad最坑的地方在于：模型看着没问题，工程上一用就废。所以要先把评测指标和踩坑经验摆出来，再讨论效率。

4.1 我从四个维度给生成结果打分

我给自己搭了一套简单的评分体系，四个维度，每个25分。

第一个维度是语义符合度。检查生成模型是否准确反映了文本里所有显式要求：尺寸对不对、孔位数量对不对、圆角半径对不对。这个维度的坑在于，LLM经常会把“四角各一个螺纹孔”理解成只生成一个孔，或者把“中心”理解成边界中心。我的经验是，让LLM先输出结构化JSON再做二次校验，漏项率能从30%降到5%以下。

第二个维度是几何合理度。看模型是否存在自相交、非流形边、壁厚过薄、倒角干涉等几何错误。CadQuery底层是OpenCascade内核，大部分几何异常会在建模时报错，但有些隐性问题不会报错，比如两个孔间距过近导致加工时薄壁破碎。这类问题要靠规则引擎做二次检查，例如最小壁厚阈值、孔间距阈值、倒角与孔径干涉检查。

第三个维度是可编辑性。评估模型是否保留了清晰的参数、约束和特征语义。对CadQuery方案来说，主要考察代码结构是否清晰——参数是否抽成变量、约束是否显式声明、特征是否有注释。LLM生成的代码如果写成一坨硬编码，乍一看能出模型，后期改尺寸就得全改，这是可编辑性的大忌。

第四个维度是鲁棒性。同一个提示词跑10次，看几何成功的比例和尺寸漂移情况。我实测下来，用过强一点的大模型作为基座，简单零件能做到8/10次一次成功；复杂零件（含多个特征、阵列、布尔运算）成功率会跌到4成以下。鲁棒性不足时，千万不要直接接进自动化流程，必须加校验环节。

4.2 高发的失败模式与排查方法

我整理了一个自己的踩坑清单，排名不分先后。

单位混用是最隐蔽的坑。大模型训练数据里英制和公制混着来，你输入“直径16”它老老实实给16毫米，但如果提示词出现“1 inch”，有时候就会生成25.4毫米，有时生成1毫米。我的对策是提示词里强制标注两遍“默认单位：毫米，所有数字均为毫米”，并在代码层做数值范围检查——如果某个尺寸的绝对值明显偏大或偏小，直接拦截。

孔位布局错误是第二高频问题。客户说“四角各一个孔”，如果只写“four holes at corners”，AI可能把四个孔挤在同一个角附近。正确做法是在提示词里补充“均匀分布在矩形板的四个角点附近，与相邻边缘距离相等”，并在JSON结构里显式给出辅助定位尺寸。有时候我还直接要求LLM先输出辅助定位点坐标列表，再据此生成孔特征。

第三个高频问题是倒角与孔干涉。比如中心孔径16毫米，四角倒角R8，如果倒角范围沿边缘延展，就可能切到孔壁。CAD内核在布尔运算时不一定报错，但加工出来就是废品。我的对策是加入干涉检查脚本，自动计算倒角面与孔边界的距离，低于安全阈值就报错并要求重新生成。

还有一类问题是布尔运算失败和拓扑错误。多特征复杂零件，特别是包含扫掠、放样、多布尔差集时，OpenCascade内核偶尔会生成非流形几何。这个阶段的信号往往是CadQuery导出的STEP文件在别的软件里打开缺面或报修复错误。我的经验是拆解特征顺序：先做主要实体，再逐一做布尔运算，每个布尔步骤单独try-except，失败时把中间结果写盘分析，而不是一股脑生成到底。

4.3 提示词调教的几个实操技巧

实测下来，提示词质量对生成成功率的影响，比模型选择还大。我现在基本固定了一套提示词模板思路，核心是四件事。

第一，开场就定义角色和输出格式。比如“你是一个资深机械设计工程师，请使用CadQuery建模，输出可直接运行的Python代码”。角色设定能显著降低AI输出“教学式废话代码”的概率，直接给干货。

第二，显式列出所有参数，不允许AI自己发挥。建议用结构化描述：

- 板长：80mm（X方向） - 板宽：50mm（Y方向） - 板厚：8mm（Z方向） - 四角圆角：R8mm - 中心通孔：直径16mm - 四角螺纹孔：M6，数量4个，均匀分布 - 所有单位为毫米，坐标基准为板底面Z=0

每个参数都有明确值和单位，AI没有自由发挥空间，生成结果的可控性大幅提升。

第三，限定建模策略。如果你没指定“先拉伸板材再打孔”，AI可能用一大堆复杂特征堆出结果，代码晦涩且容易错。我在提示词里会写“优先使用基础特征：拉伸、倒角、孔，避免放样和扫掠”。这个限制直接告诉AI“用最短路径完成”，相当于给它设了标准化作业规范。

第四，要求自检输出。提示词里加上“生成后请检查：1) 所有孔是否穿透板厚；2) 圆角是否与孔干涉；3) 尺寸是否符合输入参数”。LLM虽然不能真正执行几何计算，但让它进行“意识上的自检”能显著降低低级错误。

5. 落地的正确姿势：哪些场景先用，哪些先别碰

text-to-cad的技术成熟度，目前处在“可用但需要人看着”的阶段。我在多个场景里试用了半年，最深的体会是：选对场景，它是提效利器；选错场景，它就是个坑。

5.1 适合优先落地的四类场景

第一类是标准件和常用件库的自动生成。螺栓、垫片、法兰、支架这类特征固定、参数可变的零件，text-to-cad几乎是天选解决方案。你只需要维护一套提示词模板和参数JSON，就能批量生成几十种规格的模型，效率比人工建模高一个量级。

第二类是客户报价阶段的快速概念模型。销售拿着需求清单找你要初步模型，以前你得停下手头的活加班建模。现在可以让AI先生成一版粗略模型，你审核修改后发给客户确认。这里的关键是“快”而不是“准”，先让客户看到三维形态，后续再细化。

第三类是批量变体设计。比如一个钣金件要出五个尺寸系列，人工操作是重复劳动，用AI生成参数化脚本后，改参数重新生成即可，比传统CAD的配置功能还灵活。

第四类是老旧二维图纸的模型重建。很多老图纸只有二维图没有三维模型，人工重建费时费力。如果图纸标注完整，把技术要求、尺寸标注喂给text-to-cad，AI可以快速生成初始模型，再由设计师修正，能省不少事。

5.2 融入现有工作流的三种姿势

落地方式我建议按“介入深度”分成三种，不要一上来就做全自动化。

第一种是离线辅助模式。设计师在CadQuery或FreeCAD里使用AI生成的脚本，拿到STEP后手动导入主流CAD软件继续工作。这个模式风险最低，适合团队首次引入text-to-cad。

第二种是插件集成模式。把LLM调用封装成CAD软件插件，用户在软件对话栏里输入需求，插件自动生成模型并插入当前文档。这个模式要求对CAD的API比较熟，适合结构标准化程度高的团队。

第三种是API批处理模式。通过后端服务批量接收文字需求，自动生成STEP并将结果推送到PLM系统。这是效率最高的模式，但需要完整的校验链路和失败告警机制，不然一次错误批量生成会造成全线返工。

这三种模式的共同前提是保留人工审核环节。我现在的实践准则是：AI负责生成候选模型，工程师负责审批和修正。AI生成十分钟，工程师审批两分钟，这个时间比例是可以接受的。如果工程师审批也要一小时，说明场景选错了或者提示词没有打磨好。

5.3 一点个人判断：它会取代设计师吗

经常有人问我，text-to-cad成熟了是不是就不需要设计师了。我的答案是：它替代的是“建模体力活”，而不是“设计脑力活”。设计工作里有大量时间消耗在重复建模、参数调整、模型清理上，这部分被AI替代是好事，设计者能腾出更多时间去做方案构思、结构分析和制造工艺优化。

但它没法替代的，是和客户确认需求的能力、材料与工艺的判断力、以及那些没法被自然语言表达的隐性经验。比如你告诉AI“这里感觉强度不够”，AI不知道该怎么改；而经验丰富的工程师知道该加加强筋、换材料还是调整结构布局。这类经验判断，是设计师真正的护城河。

从实操来看，我建议团队从最不起眼的标准件开始试用，不要一上来就挑战复杂装配体。先让团队在一个低风险场景里熟悉“人审AI生成模型”的协作节奏，再逐步扩展到更多品类。我自己就是这么做的，从法兰板到支架，再到钣金件，每一步都积累提示词模板和校验规则。现在这套规则已经成了团队内部的标准化资产，新成员来了直接套用，效率提升非常明显。

如果你也想试试，我的建议是：不要追求一步到位的智能。先搭一条“文本→参数→脚本→STEP”的管道，哪怕生成结果只有七成可用，也值得跑起来。七成自动化的价值，远大于百分之百完美但迟迟不上线的方案。