企业官网建设流程全解析

1. 新范式来了：从鼠标拖拽到一句需求“编译”出图纸

作为一个在机械设计行业摸爬滚打了十几年的老工程师，我第一次看到 Text-to-CAD 这个概念的时候，第一反应是“这玩意是不是又是AI生成个示意图糊弄人的”。但真正把几个项目跑通之后，我意识到这其实不是一个“画图工具”，而是把设计意图直接翻译成参数化几何模型的编译过程。它和那些“输入一句话生成一张图”的AIGC完全是两码事：生成式AI画图输出的是像素点阵，而 Text-to-CAD 输出的是经过边界表示（B-rep）描述的、带拓扑关系的实体模型。简单说，前者是给你一张照片，后者是给你一个可以被 CAM 软件直接拿去算刀路的实体文件。

这个方向如果做好了，解决的是制造企业里很要命的一个问题：从概念到三维模型之间的那一大段重复劳动。你想想，一个非标自动化项目的方案阶段，工程师要把客户的原始需求翻译成“大概是这么个形状、这么个尺寸”的模型，然后再手工细化。这个“翻译”过程往往要占掉整个设计周期三分之一的工时。Text-to-CAD 的定位就是把这段路用代码和算法过一遍，让设计人员把精力放在工况分析、材料选择、装配工艺这些真正需要人类判断的地方。这篇文章我不会去念产品手册，就从一个用过的工程师角度，聊聊它背后的技术逻辑、实际跑通的步骤，以及哪些坑是厂商演示视频里永远不会告诉你的。

2. 核心原理拆解：Text-to-CAD 到底在跑什么算法

2.1 从自然语言到参数化约束：设计意图的“转译层”

很多人以为 Text-to-CAD 最核心的技术在于“画几何体的算法”，这其实是个误解。如果你接触过任何一个 Text-to-CAD 系统，会发现整个流程的第一步是：如何把你那句“一个M6螺纹孔的安装底板，四角倒圆角R5”变成一组可以被几何内核理解的约束条件。

这个环节本质上是一个大语言模型在做语义解析，但它对比通用的 ChatGPT 类产品，难点在于需要输出结构化的约束树，而不是一段人话。比如当你说“带四个沉头孔的L型支架”时，模型不仅要知道“L型”是两个互相垂直的平板，还得知道“沉头孔”的口部直径、深度、底孔直径之间的标准对应关系（典型值如ISO 10642标准），以及四个孔的定位规则是“均布”还是“按边距等距分布”。如果这一层没有处理好，后面所有几何生成都是在沙滩上盖楼。

从实际体验看，目前比较好用的工具（比如一些结合了CAD内核API的插件级方案）在转译层大量引入了“设计规则引擎”。也就是说，它会用一些预设的机械设计规则去校验大语言模型解析出来的约束是否自洽。举个例子：你说“直径40的轴，配一个轴承位”，系统会自动去查常用滚动轴承的尺寸系列，然后提示你：“40直径的轴配合6208轴承时，建议轴肩高度为3.5毫米，倒角C1.5”。这种能力已经不单纯是“听懂人话”，而是具备了一定程度的机械设计常识推理能力。

2.2 为什么是 B-rep，而不是网格或者点云

再往内核层走，Text-to-CAD 生成的模型必须被制造业的上下游工具链所接受。这就决定了它不能像现在那些 3D AIGC 工具一样输出 OBJ 网格文件。网格模型（Mesh）在视觉上是完美的，但一旦进入 CAM 软件、有限元分析（FEA）、或者下游的二维工程图标注，就会暴露出致命问题：没有精确的几何拓扑关系、没有曲面连续性信息、公差标注无处附着。

所以在实际项目中，Text-to-CAD 工具的底层都是对接某个商用或开源的几何建模内核（如 Parasolid、ACIS、OpenCASCADE），生成的结果是 B-rep（Boundary Representation，边界表示）模型。这种模型的核心特征是一个实体由有限个面（Face）、边（Edge）和顶点（Vertex）构成，并且它们之间有严格的拓扑连接关系。你可以在 CAD 软件里对这个实体直接进行布尔运算、倒角、抽壳等操作，模型不会碎掉，拓扑始终保持有效。

这也解释了为什么“生成式AI画图”那一套泛化能力极强的扩散模型没办法直接用在 Text-to-CAD 上。扩散模型擅长生成像素级别的连续分布，但 B-rep 的表示是离散的、有严格结构约束的拓扑数据。强行用生成对抗网络或扩散模型去生成 B-rep，很容易出现“看着像法兰盘，但一拉伸就报错”的尴尬场面。所以现在主流路线是“大语言模型出语义和参数 + 传统几何内核出实体”，用代码把两端缝合起来。

2.3 参数化与特征树的保留：能不能“改”比“生”更重要

还有一个容易被忽略但是实际上极其核心的环节，是参数化特征树的保留。如果你在一个成熟的 Text-to-CAD 工具里生成一个零件，你会发现它生成的模型不是“一坨定死的实体”，而是带有完整特征历史树的——拉伸特征（Extrude）、旋转特征（Revolve）、孔特征（Hole）都在树的节点里，每一个节点的参数都可以双击修改。

这个点有多重要？你可以拿它跟“用脚本直接写几何”做一个对比。以前我们用 Python 调 FreeCAD 或者用 DesignScript 写 Dynamo 节点，也能通过代码生成零件，但那个代码往往是过程性的、不可逆的：跑完生成实体，代码和实体之间的关联就断了。而 Text-to-CAD 试图保留下来的，是一个“活”的参数化模型。你生成之后改了孔距，下游的倒角、阵列跟着变。这意味着生成结果不是设计终点，而是设计起点。从企业落地的角度来说，这一点是决定要不要在生产环境里引入的关键指标。

3. 实操笔记：从项目立项到生成一张可用图纸

3.1 环境准备与工具选型：别迷信“全自动”，选型看三点

你在网上搜 Text-to-CAD，会看到一堆研究论文（比如 Text2CAD、CAD-GPT 这类），但真正能装到本地干活的主要是两类：一类是集成在主流 CAD 软件里的第三方插件，另一类是基于 OpenCASCADE 内核的开源工具链配合大模型 API。我个人建议，如果你是做标准机械产品的，直接上商业插件；如果你是搞自动化设备研发、需要频繁改结构的，先拿开源方案搭一个最小验证环境更稳妥。

选型主要看三个指标。第一个是“特征识别率”，你就拿公司最近做过的五个典型零件去测，看系统能不能把它们拆分成合法的特征树。别听厂商吹的“支持任意复杂形状”，大概率是拿一个多面体花瓶做演示，那种自由曲面根本没法上机床。第二个是“参数回改能力”，也就是生成之后，你能不能像平时画图一样双击尺寸改数，改完下游模型联动更新。第三个是“系统集成度”，尤其看看它能不能直接导出 STEP 或者 Parasolid，反正我们最后加工还是要走 CAM 的，导出一个破烂格式等于没做。

我自己搭的最小环境是这样的：Ubuntu 22.04 的机器上跑 OpenCASCADE 内核，通过 Python 脚本调用一个本地部署的代码生成模型（这年头本地跑7B模型都够用了），输出就是一段构造几何的 Python 代码，然后直接调 OCC 的 API 生成实体，最后导出 STEP。这套方案虽然原始，但每一步都看得见摸得着，出问题好查。

3.2 Prompt 写法：给“会说人话”的模型补上机械常识

很多人第一次用 Text-to-CAD 的时候，会像跟 ChatGPT 聊天一样随手敲一句：“给我做一个支架。”然后生成了一个完全没法用的奇怪形状，就得出“这玩意不行”的结论。实际上，Text-to-CAD 的输入虽然叫“自然语言”，但它对大模型的推理要求更高，你的描述越接近工程语言，生成的模型越可靠。

这里我总结了一套还算管用的 Prompt 结构，大概是四要素：零件名称+功能定位、关键尺寸与公差、加工工艺假设、设计约束。举一个实际跑通过例子，你说“一块 6061 铝合金底板，用于固定一个 60mm 导轨滑块，滑块孔距 40mm，用 M5 沉头螺钉固定”，比单纯说“做一个带孔的板”要好用不知道多少倍。因为“6061铝合金”会触发模型查材料库，“60mm导轨滑块”会触发标准的导轨安装面尺寸记忆，“M5沉头螺钉”会触发对应的过孔和沉孔设计参数。

另外有一点很关键：一定要在 Prompt 里说清楚“哪些地方是功能面，哪些地方是工艺面”。比如你告诉它“底面是安装面，表面粗糙度 Ra3.2”，模型就会尽量避免在底面做凸起特征，也会合理选择是否需要添加工艺凸台。这个信息对模型判断特征树层级很有帮助，生成结果的可用性能提升一大截。

3.3 生成后处理流程：别跳过“特征清理”三步走

我不管你用的是商业插件还是开源方案，生成完之后第一步永远不是去保存、转格式，而是做三件事：特征树审查、几何检查、干涉检查。

特征树审查，就是看系统生成的特征是否可以被“常规操作”复现。比如它如果生成了一个“多截面放样”特征，而实际上用两次拉伸加一次布尔并集就能做出来，那你最好改成后者。为什么？因为下游做 CAM 编程的同事拿到“放样特征”，刀路规划会有很多麻烦，反而没有“拉伸+布尔”来得直观。我干过的最蠢的一件事，就是拿到一个生成零件直接转 STEP 发给加工厂，结果对方打电话来问“这个特征的工艺基准在哪”，我对着特征树看了半天回答不上来。从那以后我养成了习惯：生成完先用软件自带的特征识别工具把特征树“清洗”一遍，能合并的合并，能简化到标准特征的坚决不保留花活。

几何检查就更简单粗暴了，直接用 CAD 内核的“修复”功能批处理一遍：检查面是否存在细微裂缝、边是否有自相交、有没有零厚度的退化几何。OpenCASCADE 环境里可以用 BRepCheck 逐个 face 检查；商业 CAD 里，直接运行“检查实体”工具就行。别看这个步骤土，实际生成失败的案例里，有一大半都是这种拓扑瑕疵导致的后续报错。

干涉检查主要是针对装配体场景。Text-to-CAD 单零件生成一般没问题，但一旦涉及多个零件配合，比如生成一个轴和一个带孔的法兰，系统很容易出现轴径等于孔径的零间隙配合情况，这在真实制造里是不可能存在的，因为必须有配合公差。所以每次生成一对配合件，我都会手动检查并留出间隙值。相关参数的选取没有统一标准，根据你选的配合制来定，我常用的是基孔制 H7/g6 这种间隙配合，具体数值查机械设计手册就行。

4. 实操环节的完整实现与效果评估

4.1 一个完整案例：关键词驱动的法兰支架生成

这里用我之前做的一个自动化设备上的传感器安装支架作为测试样例，完整走一遍流程，也给你看看实际生成的参数化代码长什么样。需求很简单：固定一个光电传感器，传感器上有两个直径 3.2mm 的安装孔，孔距 25mm，需要把支架固定在一根 40mm 方形铝型材上。

我先写好 Prompt，包含的信息基本是上面总结的四要素：名称是“C型传感器安装支架”，功能是“将光电传感器固定于4040型材”，关键尺寸是“两孔间距25mm，孔径3.2mm，C型开口宽度适配40mm型材”，加工方式是“铝合金，建议线切割下料加铣削”。模型生成的代码经过整理后，核心部分大概长这样：

# 生成 C 型传感器安装支架的简化示意代码 import cadquery as cq # 定义主体尺寸参数 height = 80.0 # 支架总高 width = 40.0 # 适配40型材槽口 thickness = 5.0 # 板厚 # 创建 C 型主体 result = (cq.Workplane("XY") .box(height, width, thickness, centered=(True, True, False)) .edges("|Z").fillet(2.0) # 外侧边缘倒圆角R2 .faces(">Z").workplane() .center(-20.0, 0.0) .rect(20.0, thickness, centered=(True, True)) .extrude(20.0) # C 型下翼缘 .faces(">Z").workplane() .center(20.0, 0.0) .rect(20.0, thickness, centered=(True, True)) .extrude(20.0) # C 型上翼缘 ) # 在安装面上打两个传感器固定孔 result = (result.faces("<Y").workplane() .center(0.0, 20.0) .pushPoints([(-12.5, 0.0), (12.5, 0.0)]) .hole(3.2))

这代码本质上是模型根据我的语义描述自动重构出的 CAD 建模过程，不是人写的。生成完之后，我做了两件事。第一，把支架构型里的倒角 R2 改成了 R3，因为 C 型开口根部有尖角应力集中的风险，这是基于受力分析的经验调整。第二，给安装孔增加了沉孔特征，因为传感器原厂推荐用 M3 沉头螺钉进行齐平安装。改完特征树之后，更新模型、导出 STEP，整个过程不到十五分钟，如果是从空白手工画，我大概要四十分钟到一个小时。

4.2 与手工建模的效率对比：别把账算错了

现在各大厂商很喜欢给你晒“效率提升十倍”这种数字，但我劝你算账的时候分情况看。如果是这一类规则清晰、标准件特征明显的零件，Text-to-CAD 确实有巨大优势，我自己实测下来，类似上述支架这样结构的零件，从需求确认到模型完成，时间大约只有传统方式的 30%。但如果是高度定制化的曲面造型零件，比如风机叶轮、复杂外壳，目前的 Text-to-CAD 工具表现并不稳定，甚至不如直接用曲面建模来的快。

还有一个隐藏成本要考虑：Prompt 调试的时间。你用几次会慢慢发现，每次换新结构类型，头一两次生成总是会有各种各样的问题，得来回修改描述。这个“调试 Prompt”的时间往往不在产品宣传材料的统计口径里。所以我的建议是，先从你过往案例里挑出那些“重复性高、结构标准化”的零件建立 Prompt 模板库，把调试成本一次性付清，后面再遇到类似需求直接套用，这时候才能真正吃到效率红利。

4.3 模型质量评估：除了“像不像”，还要看“能不能造”

我见过很多人在评测 Text-to-CAD 生成结果时，只看“渲染图像不像”或者“尺寸对不对”，这太外行了。在制造业里，一个模型算不算合格，至少得过三关：可制造性、可装配性、可分析性。

可制造性简单说就是：这模型能不能用现有的加工工艺做出来。比如你生成一个深腔薄壁件，壁厚只有 0.5mm，光看模型挺精美，但实际 CNC 加工一碰就颤刀，压铸也根本填不满。正规的工具一般会在生成的时候附带一个 DFM（面向制造的设计）提示，比如“壁厚过小，建议增加至 1.5mm 以上”。如果系统没这个功能，你就得自己凭经验判断了。可装配性主要看公差配合是否合理、有没有考虑到螺栓扳手空间。可分析性则意味着模型拿到 CAE 软件里能不能正常划分网格、施加边界条件不报错。我们团队现在有一套内部评估表单，每次测试生成模型都按这三个维度打分，低于一定分数就直接弃用，不浪费时间修补。

5. 常见问题与排查技巧实录

5.1 生成的模型特征树里全是“哑特征”，怎么破

所谓“哑特征”，就是生成出来的特征没有参数化关联，改一个值，其他值不会联动更新。这种情况在早期工具里特别常见，它像是把一个实体的最终状态“拍快照”了下来，而不是把建模过程“录下来”。遇到这种情况，我一般先尝试“特征识别”功能重新解析——大多数主流 CAD 都能对导入的实体做特征识别，把拉伸、孔、阵列这些特征重新提取出来。如果识别失败，那就只能手工重建特征树了。

这里有一个技巧，你先手动新建一个空零件，然后把这个实体的某个面作为基准面，用它生成第一个拉伸特征，紧接着系统会让你自动捕捉草图轮廓。把这套流程走完，软件就会把其他特征也挨个识别出来。虽然费点时间，但是处理完之后模型就“活”了，后续改尺寸方便很多。千万不要拿一个“哑实体”直接往 CAM 里丢，万一工艺要调整，你就等着重新画吧。

5.2 布尔运算报错“实体不封闭”，不是模型算法的锅

经常有人跑 Text-to-CAD 生成轴类零件或箱体零件时，最后一步合并实体报错“Shell is not closed”或者“B-Rep operation failed”。排查第一先检查是不是单位不一致导致的。很多开源工具链默认按毫米处理，但大语言模型对尺寸数字的理解有可能会把 10mm 输成 10cm，内部一换算几何就出现了缝隙。解决方法非常简单，生成完第一步检查一遍关键尺寸的单位量级是否合理。

另一个高发原因是临近面之间存在极小的间隙或重叠几何，肉眼看不出来，但内核在拓扑层面认为它们是分离的。遇到这种情况，条件允许就调大公差重新生成；不行的话，把报错的那两个特征单独提取出来，用“延伸面-裁剪-缝合”三步修复法手动处理一遍。我踩过最深的一个坑是用默认公差跑对合面，B-rep 缝合后模型外观没问题，但一导成 STEP 文件进 CAM 就崩。后来统一把缝合公差改成了 0.001mm，问题消失。

5.3 生成结果“尺寸对，特征错位”，排查语义歧义

我这里有一个真实的失败案例。我在 Prompt 里写“滑块安装面为顶面”，结果系统把安装孔打在了侧面，圆角也全加在了底面。问题出在哪？在机械设计语境里，“顶面”通常指设备正常摆放时的上表面，但模型在计算的时候默认把坐标系的 Z 轴方向当成了“顶”。这种“语义歧义”在 Text-to-CAD 里非常常见。

怎么排查？第一，每次生成前在 Prompt 中明确坐标基准，比如“该零件设计坐标系中，+Z 方向开口，+Y 方向为安装配合面”；第二，生成后第一步旋转模型，从六个视角快速扫一遍，确认特征方向是否符合设计意图；第三，养成“用装配环境验证”的习惯，把生成的零件丢进总装图里，和相邻零件做一次快速干涉检查，很多错位一眼就能看出来。这个流程走顺了，能避免至少一半的返工。

5.4 常见问题速查表

6. 实际影响范围与选型建议

6.1 谁能最先吃到红利：标准件、非标件、焊接件三个领域差异巨大

关于 Text-to-CAD 的影响范围，我的判断可能和大部分人的直觉不太一样：最先受益的不是做复杂产品设计的，而是标准件和非标自动化设备领域的工程师。为什么？因为这两个领域里“需求描述”和“三维模型”之间的映射关系高度模板化。你告诉别人“需要一个伺服电机安装座，适配 80 法兰，输出轴径 14mm”，任何一个有经验的工程师脑子里都能瞬间勾勒出大致结构。这种强规则场景，正是 Text-to-CAD 模型的舒适区。

焊接件领域则是另一个极端。焊接件的结构往往取决于型材切割、焊接顺序和应力变形控制，这些信息光靠一句自然语言描述很难完整表达。但它在“从加工参数生成模型”这个反向路径上很有潜力。也就是说，你给它输入“方管40x40x3，切成45度斜角，长度 500mm”，系统帮你把焊接模型直接搭好。这是目前很多工具还没做太好的方向，但一旦打通，对钣金和焊接行业的影响会非常大。

6.2 对设计师岗位的影响：不会淘汰人，但会分化技能

很多人担心这玩意会让机械设计师失业。我自己用了这段时间之后的看法是：短期内不会大面积失业，但岗位技能结构会发生明显变化。你可以把 Text-to-CAD 理解为“翻译器”：它把客观需求高效地转成几何模型，但它不了解你现场工况里的那些“潜规则”——比如某个位置之所以留凸台，是为了方便工人用内六角扳手拧紧螺钉；某个孔之所以公差严，是因为装配时需要对中调整。

这种隐性知识是模型短期内很难学会的，但对“只用 T 型命令画方块”的初级绘图员来说，冲击确实存在。以前需要三个初级工程师干一天的重复改图工作，未来一个懂行的工程师带着 Text-to-CAD 工具半天就能干完。所以我的建议是，与其焦虑，不如主动把精力放到“设计意图拆解”和“规则库建设”上：你去梳理公司里出现过哪些典型结构、对应的设计标准是什么，把这些沉淀成 Prompt 模板和规则库，反而是未来设计师最值钱的能力。

6.3 落地时的企业级建议：从小规则库开始，先跑通闭环

如果你的团队准备引入 Text-to-CAD，我给你的建议很朴素：不要一上来就想直接打通 ERP、PDM，那是个天坑。先找一个最小的、重复工作量最大的零件类别，建一个小规则库，测试“需求描述—模型生成—特征清理—导出加工”这条闭环。这个过程治两个病：一是让你的团队熟悉工具的脾气，知道哪些描述方式输出稳定；二是教会你们摸清工具的边界，别在它不擅长的领域硬刚。

我们当时选的是“各类底板和安装支架”，建完规则库之后，新项目里大概 80% 的此类零件可以直接从需求描述生成初稿，再由设计人员修改确认。这个比例听起来没那么夸张，但每个零件节省的 20 到 40 分钟累积起来非常可观。更关键的是，工程变更时不用再一个个特征去改，直接在文本描述上改参数重新生成开始点，比传统模式的返工效率好太多。

7. 从零搭建最小 Text-to-CAD 验证环境的替代思路

如果你的公司预算有限，上不起商业插件，你可以用一套完全开源的方案做最小验证。这里我把我的实践路线写一下，给想试水的朋友们参考。

思路就是“大语言模型做命令编排、开源 CAD 内核做几何执行”。最常见的组合是：本地部署一个代码生成模型（参数规模不需要很大，7B 到 13B 的量化模型就够用），模型的输出端接 CadQuery 或者 build123d 这类“用代码写 CAD”的 Python 库，最后再通过 CadQuery 内置的导出功能输出 STEP。说白了，就是让大模型去写 CadQuery 代码，而不是直接生成几何数据。这个方案在早期几乎是我认为最“健康”的落地路径，因为每一步骤的错误都可调试，不依赖黑盒几何生成。

具体配置时，要注意三个点：第一，模型选型别追求能力最强的，而是要选“代码生成稳定”的，因为几何代码一个括号错位你就得排查半天；第二，Prompt 必须约束输出格式，比如强制要求只输出 CadQuery 代码、禁止解释性文字，否则解析器会崩；第三，要有“重试机制”，模型第一次生成的代码可能报错，自动把错误信息回传给模型，让它自我修正一次或者两次，成功率会大幅提升。我实测在小样本情况下，简单的板类零件，自动化生成加自动修复的成功率能做到一半以上，这个效率作为前期验证项目已经相当能打了。