企业官网建设流程全解析

这几年 AI 生成图片、生成代码早就不新鲜了，但你要是跟搞机械、搞建筑、搞工业设计的朋友聊起来，会发现大家都在盯一个更硬核的方向：直接把一句大白话变成一张能用的 CAD 模型。这个方向，社区里习惯叫它text-to-cad。听起来像是把"给我画一个直径 20 的法兰盘"扔进软件，下一秒就自动建模了。实际做起来，远没有这么浪漫，但也正因为没那么简单，这件事才真正值得认真拆一回。我花了大概三周时间，从零搭了一个 text-to-cad 的模拟项目X，目标特别朴素：让用户输入一句话，自动生成可编辑的参数化三维模型，并导出为标准格式。整个过程踩了无数坑，也搞明白了很多原来只是"知道概念"的东西，这篇就完整记录一下我的实现思路、核心环节和排查心得。

1. 整体设计：为什么 text-to-cad 比想象中难，以及怎么拆解它

1.1 先想清楚"text-to-cad"到底在解决谁的什么问题

先说定位。text-to-cad 不是一个凭空造出来的玩具方向，它解决的是 CAD 建模里一个非常真实的效率痛点。

传统 CAD 建模流程，本质是"人用鼠标和键盘，把几何意图翻译成命令"。你要画一个轴承座，脑子里先有三维结构，再拆成拉伸、切除、倒角、打孔这一系列特征操作，每一步都要在软件界面里找命令、点坐标、填参数。这套流程最大的问题不是慢，而是意图和表达之间的鸿沟——你想的是"这里开四个均布的螺栓孔"，但软件听不懂这句话，你只能一步步告诉它：选面、建草图、画圆、定义阵列、指定数量、确定深度。

text-to-cad 尝试把这层鸿沟填平一部分：用户直接说"四个均布的螺栓孔"，系统自动把它转成对应的建模操作。这对谁最有用？两类人。第一类是 CAD 老手，他们在方案设计阶段需要快速验证多个结构想法，与其逐一建模，不如先自然语言出几个粗略模型比选；第二类是根本没系统学过 CAD 的工程师或产品经理，他们懂需求、懂结构逻辑，但卡在软件操作上，如果一句话就能出基础体量，后续再交给专业人员微调，整体协作效率能提升不少。

所以我在设计模拟项目X的时候，没有贪多求大，而是把目标收敛成三件事：文本里出现明确的结构类型，我能生成；出现明确的关键尺寸，我能正确使用；生成的模型可以反回软件编辑，而不是一堆不能参数化的死几何。这三点听起来不难，实现起来各有各的坑。

1.2 技术路线选型：为什么最终选了"文本到参数化特征树"而非"文本直接生成网格"

这里有个特别关键的路口，决定整个项目的走向：拿到文本之后，是让 AI 直接输出一个网格模型（mesh），还是输出一个参数化建模的操作序列？

我先说直接生成网格的思路。好处是省事，深度学习模型比如一些 3D 生成模型，可以吃文本描述，吐出体素或点云，再转成网格。坏处非常致命：生成结果不可编辑、不可参数化。CAD 行业的模型是要改的，孔径要改、板厚要调、特征要删，你给设计师一个定死的三角网格，他只能叹气。用我同事的话说："你这等于给我发了一张 JPG，我要的是 PSD。"这话糙理不糙，CAD 模型的灵魂是特征树，是参数，不是表面形状。

所以模拟项目X最终选了另一条路：文本解析 + 参数化模板映射 + 几何内核重建。系统先把自然语言拆解成语义结构，识别出"法兰盘""螺栓孔""直径""均布"这类实体和属性，然后映射到预先定义好的参数化模板上，最后调用 CAD 内核的 API 完成建模。AI 在这里扮演的角色是解析器，不是直接生成器。这样做有四个明显好处。

第一，输出的模型天然是参数化的，用户拿到手可以改任何一个尺寸，特征树干净可读。第二，因为几何是由模板驱动的，尺寸精度有保障，不会出现"20mm 的孔实际是 19.83mm"这种魔幻问题。第三，模板可以不断增加，每新增一种结构类型，系统能力就扩展一块，可维护性比端到端黑盒强得多。第四，也是我后来才体会到的，这种架构让错误排查变得容易——文本解析错了、参数提取错了、建模失败，各层都是独立的，直接定位就行。

这个选型思路我建议每个做类似项目的人都认真想一遍。端到端生成看着酷，但在 CAD 这种对精度、可编辑性要求极高的领域，"可解释 + 可干预"远比"一次生成"重要。

1.3 系统架构概览：一条从"一句话"到"一个模型"的生产线

整个系统可以拆成五个模块，链路非常清晰：

• 输入与预处理模块：接收用户输入的自然语言文本，做长度限制、语言检测、术语标准化。比如用户写"直径20mm"和"直径20毫米"，在这里统一成内部标准单位表示。
• 核心语义解析模块：这是脑，负责从文本里抽取结构化信息——对象类型、主尺寸、辅助特征、约束关系。我基于规则 + 轻量模型混合实现，后面细讲。
• 参数与约束构建模块：把解析结果整理成参数列表，并做完整性检查。比如"均布孔"没有给数量，会在这里标记为待补默认值。
• 建模执行模块：调用几何内核 API，按参数顺序执行建模操作，生成带特征树的模型实体。
• 导出与校验模块：把模型导出为 STEP/DXF/STL 等格式，同时做体积、尺寸等物理量校验，确认生成结果和输入描述一致。

这五个模块串起来，就像一条流水线：文本进来，先洗，再拆，再装配，最后质检出场。任何一个环节出问题，终端用户看到的都是"生成的模型不对"，但只有分模块排查，才知道问题出在"没听懂话"还是"建模时参数错了"。这个分层思维贯穿了整个项目，也是我最想分享的架构经验。

2. 核心细节解析：让机器听懂"人话里的几何"

2.1 语义解析：别急着上大模型，先做好规则和词典

我做语义解析时犯的最大错误，就是一开始就想直接用大语言模型把文本转成 JSON。想法很直接：让模型输出{"type": "flange", "diameter": 50, "holes": 4}不就行了？试了以后才发现，在工程场景下，大模型输出的 JSON 结构不稳定，字段命名经常漂移，尺寸单位偶尔会把厘米当毫米，更头疼的是它会把"法兰"和"法兰盘"当成两种东西。

后来我把方案改成了词典 + 规则 + 轻量模型兜底的三层结构。

第一层是术语词典。我把机械设计和建筑里常见的结构词、特征词、尺寸词全部手工整理了一遍，分门别类：形状名词（法兰、轴承座、支架、箱体）、特征动词（拉伸、切除、倒角、打孔）、修饰形容词（均布、对称、通孔、盲孔）、尺寸单位（mm、cm、m、inch）。解析时先做词表匹配，这一步能覆盖大概六成常见句式。

第二层是句法规则。比如识别到"直径/直径是/直径大小"这类触发词，就会向后寻找数值量词；识别到"均布"这个修饰词，就会继续寻找它修饰的孔特征和数量。规则不是正则表达式硬匹配那种脆弱的东西，而是基于依存关系做的轻量模式匹配，具体工具不限制，思路就是优先保证高频句式的稳定解析。

第三层才是轻量模型兜底。当词典和规则都覆盖不了，比如用户说"一个带四角安装孔的方形底座"，这种自由度很高的表达，就用模型来做意图分类和槽位填充。我拿了几百条真实用户话术做了标注，微调了一个很小的序列标注模型，效果可以接受。

这里最想强调的是：语义解析环节，稳定压倒一切。宁可让系统老实承认"这句话我没听懂"，也比猜一个错误参数生成一个错误模型好得多。所以我在解析层加了一个置信度阈值，低于阈值的直接转人工兜底话术，绝不让错误解析结果流到建模环节。

2.2 参数提取：单位、精度和默认值的"魔鬼细节"

解析出结构类型只是第一步，真正让人头疼的是参数提取。CAD 模型是精确的，参数错一个小数点，模型就废了。这个环节我总结出四个必须处理的魔鬼细节。

第一是单位统一。用户可能说 20mm、两厘米、0.02m、甚至"一寸"，系统内部必须全部转成标准单位（我是统一转成毫米）。单位搞错是灾难级的，一个把厘米当毫米的孔，直接让整个零件大了十倍，安装时才发现就晚了。我的做法是解析时就把量词标准化，并在最终校验阶段重新核对原始文本里的数字和生成模型里的尺寸是否一致。

第二是数值稳定性。用户写"30405"表示长宽高，或者"直径∅25"，这些特殊表达都要覆盖。我用了一套专门的数值抽取逻辑，不只是抓数字，还会往前看有没有乘号、直径符号、孔径标识。

第三是默认值处理。不是所有用户都会把参数说全。比如只说"给我一个法兰盘"，没说直径，没说孔数，怎么办？我的策略是每个模板都有工业上合理的默认参数表，缺省字段用默认值填充，同时在生成报告里明确标出"哪些参数是默认值，请确认"。这比报错强，也比瞎猜强。

第四是参数合法性校验。直径不能是负数，板厚不能大于外径，孔数必须是整数。这一步放在建模之前做，能拦截掉大量无意义的建模失败。我做了一张参数约束表，每个模板都自带校验规则，比如diameter > 0、thickness < diameter、hole_count in [0, 4, 6, 8]这种。

2.3 参数化模板：把"几何知识"变成"可复用代码"

如果说语义解析是理解层，参数化模板就是生成层的核心资产。我把它理解成"把几何知识变成代码"。

什么是参数化模板？拿法兰盘举例，它的几何结构是：一个中心圆柱体，中心开孔，圆周上均布若干螺栓孔。这个结构不会因为尺寸变化而改变，变的只是数值。所以我可以把它写成一个函数，输入是外径、内径、厚度、孔数、孔径，输出是建模 API 的调用序列。

模板建立的过程，本质是解构一个专业零件的几何生成逻辑。我需要把一个法兰盘拆解成"圆柱基体 - 中心打孔 - 圆周阵列螺栓孔"三个操作步骤，再给每个步骤定义好输入输出关系。这需要一点 CAD 建模经验，但也算不上高深，关键是拆解的粒度要合适——太粗（整个法兰盘一步生成）会导致灵活性下降，太细（每个微小倒角都是独立参数）会让用户输入负担过重。

我第一批做了五个模板：法兰盘、带孔方形底板、U 型支架、阶梯轴、轴承座。选这些不是因为简单，而是它们覆盖了几种最常见的建模操作类型——拉伸、旋转、打孔、阵列、布尔运算。五个模板跑通之后，我对整个系统的信心就建立起来了，因为建模执行层是通用的，换模板只是换参数和操作序列，不需要改框架。

2.4 约束与几何逻辑：为什么"间距均布"不能靠除法解决

做参数化模板时，有个概念必须认真对待：几何约束。这不是 CAD 术语里那个复杂的"约束求解器"，而是建模逻辑上的一些潜在关系。

举个具体例子："四个孔均布在直径 100 的圆周上"。这句话拆解出来的信息是：孔数量=4、分度圆直径=100、布局方式=均布。要生成正确的模型，需要调用阵列函数，让系统自动计算 4 个孔在 360° 圆周上的间隔角度。如果你自己用除法算 360/4=90°，然后逐个画孔，问题来了：如果用户后续把孔数改成 6，你就得手动重新算角度，模型就"死"了。正确做法是创建阵列特征，把数量和圆周绑定为参数，让 CAD 内核自己去算。这就是我强调"可编辑参数化模型"时的实现基础——该用特征就用特征，绝不落到死坐标上。

再比如"中心孔"这种描述，隐含的约束是孔的轴线和圆柱基体的轴线重合。建模时要捕捉到这种轴线对齐关系，而不是靠计算坐标硬摆上去。这种隐含几何逻辑的识别是 text-to-cad 和简单文本转数字最大的区别——文字里一个"中心"，背后是一整套约束关系。我建了一个关系映射表，把常见方位词、布局词映射到对应的几何约束类型，解析出"中心"就绑定同轴约束，解析出"均布"就绑定圆周阵列关系。

3. 实操过程与核心环节实现：跑通一个完整的"一句话建模"

3.1 文本预处理：把用户的话"洗"成规范输入

在真正开始解析之前，文本预处理的质量直接决定后续所有环节。我的预处理管线有四个步骤。

第一，统一大小写和全半角。用户可能在手机输入法里打了全角的"３０"，这是真实会发生的事。第二，处理多语言混杂。中文环境里用户经常中英混打："diameter是30的flange"，我把常见英文术语映射到中文标准词典上。第三，归一化数字表达。"三十""30.0""3e1"统一转成浮点数。第四，术语标准化。"法兰""法兰盘""flange"统一映射到同一个内部 ID 上。

这一步看起来不产直接价值，但它极大降低了后续解析的复杂度。我大概花了 20% 的精力写了这些预处理规则，却避免了 80% 的"解析器明明看到数字了却没有正确处理"的 bug。在 NLP 项目里，最贵的往往不是模型，是数据清洗和归一化。

3.2 从文本到结构化数据：一个完整例子走一遍

我用一个具体例子把解析流程串起来。

输入文本："生成一个法兰盘，外径 50，内径 25，厚度 8，均布 4 个直径 6 的螺栓孔。"

预处理之后，文本被清洗成标准表达。进入词典匹配后，命中对象"法兰盘"（映射到模板flange_template），命中特征"外径"、"内径"、"厚度"，命中布局词"均布"，命中数量"4"，命中孔径"6"。

规则接着做槽位填充。外径 50、内径 25、厚度 8 分别填进主参数表。这里有个值得注意的细节：用户没说单位，我们按默认单位有毫米处理，这个默认单位策略需要提前定好，并在界面上向用户展示"默认单位为毫米"。

"均布 4 个直径 6 的螺栓孔"被解析成一个子特征表：{feature: bolts, count: 4, diameter: 6, layout: circular, bolt_circle_diameter: null}。注意，这里分度圆直径（bolt circle diameter）是缺失的。我们的规则做了智能推断：在法兰盘模板里，如果用户没说分度圆直径，默认取主外径和中心孔径的中点，即 37.5。这个值既符合常见工程比例，也在合法性校验范围内。最后生成的结构化数据大概是这样的：

{ "object": "flange", "params": {"outer_diameter": 50.0, "inner_diameter": 25.0, "thickness": 8.0}, "features": [ {"type": "circular_hole_array", "count": 4, "hole_diameter": 6.0, "pcd": 37.5, "layout": "evenly"} ] }

这套数据传到建模执行层，调用法兰模板函数，20 毫秒内生成一个带完整特征树的参数化模型。整个链路在这里第一次跑通的时候，说实话还挺有成就感的，因为它证明了"文本 -> 结构化语义 -> 参数化几何"这条路是走得通的。

3.3 几何内核建模：按操作序列生成特征树

结构化数据出来了，建模本身反而相对"枯燥"，因为它就是把几何操作一条条执行下去。以刚才的法兰盘为例，操作序列是：

1. 创建一个圆柱体基体，直径=外径 50，高度=厚度 8。
2. 在基体中心创建一个贯通孔，直径=内径 25，并使用同轴约束。
3. 创建一个草图圆，直径=分度圆直径 37.5，然后在该圆上定义 4 个孔的位置。
4. 执行圆周阵列，数量=4，角度=360/4，均布生成 4 个直径 6 的通孔。
5. 把阵列结果从基体中布尔减除。

每一步都调用内核 API，并确保返回的特征对象被记录。值得强调的是第 2 步和第 4 步：不要通过计算坐标的方式硬生成孔的位置，而要通过阵列特征和约束来定义。这样用户后续双击模型，能直接看到"这个孔阵列的数量是 4，角度是 90°"，修改数量为 8，模型会自动重新生成。这就是"参数化灵魂"所在。用生活类比解释就是：你给邻居指路，可以直接告诉他"走到第三个红绿灯右转"，也可以说"沿着这条路的第 3.7 公里处右转"。后者虽然也能到，但路修了、重新标里程之后就废了。CAD 建模同理，用特征和约束建模，模型才"活"。

3.4 导出与校验：生成完不算完，得过了质检才能交付

很多初做这类系统的人，生成一个模型就宣布成功。实际上，校验环节才是我这类项目最花时间的部分之一。

我做了两种校验。第一是参数回读验证：从生成的模型特征树里读回关键尺寸，与输入文本里的数值逐一对比。外径是不是 50？内径是不是 25？孔数是不是 4？这一步能捕获到语义解析正确但建模执行错误的场景，比如按钮孔阵列误用了直角阵列而不是圆周阵列。

第二是几何属性验证：计算模型体积、包围盒尺寸、质心位置，和理论值对比。法兰盘体积可以由圆柱体积公式估算，如果实际体积偏差超过 1%，说明有几何重叠或残留体，需要检查布尔操作是否干净。这个验证法很朴素，但每次都能力挽狂澜，曾经就靠它发现了一个阵列参数没更新的 bug——修改孔数后体积没变，属性校验立刻报警。

校验通过后，模型统一导出为 STEP 和 STL 两种格式。STEP 用于高级 CAD 软件打开，保留特征树和参数信息；STL 用于 3D 打印和可视化预览。同时我还会生成一份 HTML 格式的"建模摘要"，列出用户原文、解析出的所有参数、被默认填充的字段，以及模型的物理属性。这份摘要特别受欢迎，因为用户能直观看到系统到底"理解"了哪些内容，哪部分理解错了也一目了然。

4. 常见问题与排查技巧实录：那些让我加班到深夜的坑

4.1 语义误解比模型生成失败更隐蔽

做这个项目，我发现最可怕的错误不是建模失败，而是系统以为理解对了、其实理解错了。举例：用户说"在板上打一个孔"，系统如果把"孔"解析成"圆角矩形"，生成的模型外观差不多，但参数完全错位。这种错误在建模阶段不会报错，只有到后续装配环节才会暴露，而那时排查的代价已经很高了。

我的解决方案有两个。第一，解析结果可视化。把结构化 JSON 转换成人能读懂的自然语言概要，反馈给用户确认，比如"识别为：法兰盘，外径 50mm，内径 25mm，均布 4 孔，直径 6mm。请确认。"用户点确认再建模。这个环节看着多了一步交互，但实际体验提升非常明显，因为它把"系统可能猜错"这个不确定性显式暴露给用户了。第二，设置歧义探测规则。像"孔"这种过于宽泛的表达，如果后续没有足够上下文限定，就主动向用户提问"您要的是什么类型的孔？通孔、盲孔还是螺纹孔？"绝不瞎猜。

4.2 尺寸单位与量纲的"幽灵问题"

单位错误是我排查过最多、也最容易反复出现的问题。有个特别典型的场景：用户输入"架子长 2m，宽 1m，高 0.5m"，系统如果当时没识别到"m"为单位，全部按毫米处理，生成的架子尺寸差了 1000 倍。模型倒是"生成成功"了，但完全不能用。

后来我在解析层增加了双重校验机制：数字抽取器在返回数值的同时返回原始文本片段，参数校验阶段重新用正则扫描原始片段，确认单位换算因子被正确应用。两步对照，从机制上防止了单位漏判。另外还在输出摘要里专门显示"换算结果：2m -> 2000mm"，让用户一眼看到系统有没有理解对单位。

4.3 默认参数的隐藏风险：让用户为系统的不确定买单

默认值是双刃剑。用好了，能让输入门槛降低；用不好，会让用户拿到"看似可用实则错误"的模型。我踩过最狼狈的一次坑是：用户想生成一个支架，没说明是否是左右对称件，系统默认生成了不对称结构。用户拿模型去加工，做出来一对左右手件，直接废了两个零件。

这次之后，我定了一条原则：涉及方向、镜像、阵列数量和材料厚度这类影响重大的参数，不设置默认值，必须显式确认。用户没说，系统就提问；用户说了，系统就忠实执行。虽然多了一步交互，但避免了一个零件废掉的重成本。辅助性参数（比如倒角半径、默认单位）可以用默认值，关键结构参数必须显式。这条经验的价值，远超我教条式写的所有代码。

4.4 建模失败的奇奇怪怪原因与排查路径

建模阶段最常见的报错有这么几类：布尔运算失败、阵列生成异常、草图约束冲突。布尔运算失败多发生在孔和基体边缘相切时，比如螺栓孔分度圆直径等于法兰外径减去孔径一半，导致孔突破了外边界。阵列生成异常则常见于数量为 0、负数或过大。草图约束冲突则是因为模板内存在冗余约束，比如既手动定义了圆心坐标，又定义了同心约束。

排查这类问题，我的习惯是给建模执行模块加一层"断点日志"。每步操作执行前记录输入参数，执行后记录输出结果，失败时把当前的参数上下文完整 dump 出来。这套日志帮我快速定位了至少 70% 的建模失败问题。具体排查路径是：先看是哪一步操作失败，再看失败时参数值是否合法，最后确认模板内约束是否冲突。三步走完，绝大多数问题都能找到根因。

5. 常见问题速查表：可以抄作业的清单

为了让大家排查起来方便一点，我把这段时间积累的典型问题整理成了一张表，按环节归类、按严重度排序，基本能覆盖 text-to-cad 项目里 80% 以上的常见故障。

这张表建议大家直接抄走，做成项目里的问题日志模板。新版出了问题先查表，查不到再新增记录，用一两周时间就能沉淀出属于自己的排查手册。

6. 实操心得：如果让我重新做一遍，这三件事会先做

项目做完以后，回头总结，有几条心得我觉得比任何技术细节都有价值。

第一，先把验收动作定义清楚，再动工写代码。我们一开始花了太多时间在"解析更准的模型"上，后来才发现用户真正在意的是"生成的模型能不能直接进软件改尺寸"。方向如果错了，解析准确率再高也没用。正确的顺序是先确定你要交付哪种模型、哪种精度、哪种可编辑性，再倒推需要什么解析能力。这就好比你做饭，先想清楚要端出什么菜，再决定调料比例，而不是先纠结酱油用哪种。

第二，积累一个"失败表达"库远比优化模型参数重要。用户说话的方式千奇百怪，"打四个眼儿"这种口语表达，词典和规则都覆盖不到。后来我把所有未能正确解析的输入都记录下来，整理成失败样本库，每周迭代一次。这个库让系统的真实可用性每周都有肉眼可见的提升，比调整内部词向量维度有效得多。

第三，交互设计绝不是锦上添花，而是刚需。text-to-cad 天然有不确定性，"系统确认理解正确"这个环节不能省。哪怕只是一个简单的摘要回显 + 确认按钮，也能把最终交付的错误率降低一个数量级。我测过在解析后立即建模、不做确认，和解析后先回显确认再建模，这两种流程下用户对结果的满意度有很大差别。多做一次确认，只是多点一下的事，却换来完全不同的信任度。

我自己最深的体会是：text-to-cad 真正考验的不是 AI 能力，而是对领域逻辑的拆解能力和对产品交互的把握。AI 负责理解语言，但理解完语言之后，如何组织参数、如何生成可编辑的几何、如何让用户信任系统的输出，这些才是决定项目成败的地方。

如果你也想做类似的方向，我的建议是别急着找最花哨的模型。找一个你熟悉的零件，把它拆成参数化模板，用最朴素的解析方式跑通一条链路——从文本到参数到建模到校验——你从这个过程中收获的对"自然语言与 CAD 结合"的理解，比任何现成方案都扎实。等这条链路跑通了，再逐步扩充模板库、提升解析覆盖率，你会发现这个系统的天花板一直在往上抬，而你每抬一次，都对 CAD 和 AI 的关系多一分理解。