企业官网建设流程全解析

绘图窗口里密密麻麻的特征树、复制的草图、翻来覆去的约束报错，这是每个CAD使用者都绕不开的日常。尤其是做机械结构或者产品前期方案的时候，从脑海里一个模糊的想法到屏幕上出现一个能编辑、能出图的模型，中间隔着大量重复操作。所以当我第一次接触 text-to-cad 这个概念时，第一反应是：这玩意儿终于有人认真做了。

text-to-cad，直白说就是输入一段自然语言描述，让模型自动生成对应的CAD模型，或者更准确一点，自动生成一段能还原出这个模型的建模操作序列。它想解决的不是“画得快一点”的问题，而是把“设计意图从人脑传递到模型”这条链路直接压缩掉。这篇文章我会围绕这个方向，聊一聊它背后的技术难点、主流实现思路、我在实际复现中踩过的坑，以及我对后续落地形态的一些判断。如果你是做CAD二次开发、AIGC应用落地，或者单纯好奇“AI建模到底走到哪一步了”的工程师，这篇内容应该能给你一些参考。

1. 为什么 text-to-cad 值得花时间研究

1.1 建模的最后一公里不是工具问题，而是意图传输问题

我先说一个反直觉的观察：CAD软件本身的功能早就足够强大了，强大到很多用户只用了不到百分之十。真正的瓶颈在于，用户要把自己脑子里的三维结构“翻译”成软件能理解的操作步骤——画哪个平面、拉多长、切多深、倒多大的角。这个过程高度依赖经验，而且每一步操作都会固化到特征树里，改一处往往牵动全局。

text-to-cad 做的事情，本质上是把这段“翻译”交给模型来完成。人只需要说“一个直径40mm、高度60mm的圆柱体，顶部开一个直径10mm的贯穿孔，底部带一个宽度8mm的键槽”，模型拿到这句话之后，直接生成对应模型，或者生成一段参数化建模脚本。这就把建模门槛从“会操作软件”降到了“能描述清楚需求”。

这里要强调一下，它跟现在很火的文本生成3D模型完全不是一回事。文生3D模型追求的是视觉合理、风格匹配，多数产出是网格或者隐式场，拉进看可能一塌糊涂，更没法做工程修改。text-to-cad 的目标是生成边界表示（B-rep）或特征历史树，尺寸精确、约束完整、可以进CAM、可以出工程图，甚至可以直接拿去加工。

1.2 一句话需求背后的粒度差异

“帮我画一个杯子”和“直径85mm、壁厚4mm、高度120mm、底部圆角3mm的圆柱杯，杯口带一个向外翻边”这两句话，对模型来说难度天差地别。前者需要模型脑补大量信息，后者其实是把参数直接映射到特征上。当前 text-to-cad 方向更务实的做法，是先吃后一种偏结构化、带完整参数的描述，再逐步放开自由度。

另外还有一个容易被忽视的点：这个方向在不同行业里的“CAD”含义不一样。机械行业要的是参数化实体和特征树；建筑行业要的是楼层、墙厚、开间这些构件逻辑；电子行业更关心外壳、卡扣、散热孔这类薄壁结构。所以研究 text-to-cad 的时候，得先明确你在为哪个领域做，不同领域的描述词汇和建模习惯都有明显差异，通用模型听起来很美，实际效果往往两头不讨好。

2. 一条完整的技术路径是怎么设计出来的

2.1 直接生成几何的路子，适合快速出形但不适合工程落地

最早期的实现思路很直接：用类似文生图的技术框架，把文本编码成向量，再通过生成模型输出体素、点云或者网格。这样做的好处是技术栈成熟，拿现成的扩散模型改一改就能跑；坏处也很明显——生成的网格噪声大、拓扑不稳定，想要转成可编辑的B-rep模型，需要额外的曲面拟合和特征识别，精度损失严重。

我曾经试过用这类方案做一个简单支架，远看外形是对的，一旦放大检查，孔的位置偏差零点几毫米，面与面之间出现微小的间隙，根本过不了装配检查。所以我的结论是：直接生成几何的路线适合做概念预览、灵感草图，或者作为后续参数化重建的初始条件，但把它当成 text-to-cad 的终点，在工程上走不通。

2.2 把建模操作序列当语言来生成，是目前最接近实用的路线

第二代思路发生了一个关键转变：不再生成模型本身，而是生成“建模过程”。每一段CAD建模都可以表示成一系列操作——新建草图、画线、标注尺寸、拉伸、切除、倒角、阵列。这些操作天然带有参数和先后顺序，很像一种结构化语言。于是 text-to-cad 就变成了一个序列生成问题：输入文本，输出建模指令序列，再由CAD内核按顺序执行。

这个路线的核心是基于Transformer的序列模型。输入侧是自然语言描述，输出侧是操作token序列。为了让模型学会这个映射，需要大量“文本-建模操作序列”配对数据。数据来源通常是把现有模型库中的每个模型逆向解析成特征树，再通过规则或人工方式生成对应的文本描述。训练完成后，模型在推理时会逐步预测下一个操作token，就像写代码一样把整个建模流程“写”出来。

这种方案最大的优点是可解释性和可编辑性。输出的每个操作都能对应到特征树里的一个节点，用户不满意可以直接改参数，或者删掉某一步重新生成，而不是面对一个不可拆解的网格。我几乎可以断言，未来两三年内能真正落地的 text-to-cad 产品，大概率是这种形态。

2.3 大语言模型做规划，几何内核做执行，组合拳更省力

在第二种路线之上，还有一条更取巧的路径：让大语言模型充当“建模规划师”，负责把用户文本拆解成建模步骤，然后调用CAD内核的API或脚本接口来执行。这里的LLM不直接生成token化的操作序列，而是生成一段带参数的建模代码，比如调用内核接口创建草图、添加约束、执行拉伸。

这条路的好处在于可以利用LLM强大的代码生成和常识推理能力。模型不需要从零学习“拉伸是什么”，因为它会写代码调用现成函数。实际上我在复现时就采用了这种思路，用LLM把一个描述结构化为中间表示，再翻译成几何内核的Python脚本。效果比从零训练专用模型稳定得多，尤其适合快速验证想法。

难点也有：LLM经常生成“看起来合理但参数对不上”的代码，比如把拉伸方向搞反，或者引用了一个不存在的草图平面。所以必须在外围加一层校验逻辑——每次执行后检查结果是否满足尺寸约束，不满足就带着错误信息让模型重新生成。这个“生成-检查-重试”的闭环，是工程化落地中最关键的一环。

2.4 数据和评估指标决定模型的上限

无论走哪条路线，数据都是最大的成本项。建模操作序列的数据不像图片文本那样满大街都是，必须从现有模型库中解析特征历史来构造。这里有一个现实问题：很多模型导入导出时会丢失特征树，只剩一个光秃秃的B-rep实体，无法反推操作顺序。所以做这个方向，第一步往往是先解决“如何从几何反推特征历史”的问题，这个前置工作比训练模型本身还花时间。

评估指标也是个老大难。BLEU之类的文本指标只能衡量“生成的序列和参考序列有多像”，但同一句话完全可以对应多种建模顺序，序列不同、模型却可能同样正确。更合理的做法是执行生成的序列得到实体模型，再去比较实体形状和文本描述的语义匹配度，比如尺寸是否符合、拓扑是否一致、关键特征是否齐全。我在自己的项目里同时保留了网格距离和特征级指标两套评估体系，前者看形状，后者看工程正确性，两个都要过才算合格。

3. 我实际跑通的最小复现方案，以及每个环节卡在哪

3.1 意图解析不是通用NLP，是“实体识别加动作映射”

很多第一次做这个方向的人会直接上一个预训练语言模型去“理解”文本，结果效果一塌糊涂。原因在于，建模文本里的关键信息是高度结构化的槽位，比如“直径40mm”是尺寸，“顶部开孔”是位置和特征类型，“贯穿”是成型方式。通用语言模型擅长语义理解，但做不到稳定抽出这些精确参数。

我自己跑通的做法是先做一层规则加模型的混合解析：先用正则表达式和命名实体识别把数值、单位、特征关键词都抽出来，再通过一个小的文本分类模型判断这句话属于“回转体”“拉伸体”“板类件”里的哪一类，最后填充到一个预设的结构化模板里。模板长这样：

{ "feature_type": "hole", "position": ["top_face", "center"], "diameter": 10.0, "depth": "through_all", "pattern": null }

这一步看起来不性感，但它是整个链路上最影响最终成功率的一环。我踩过的坑是：文本里出现“直径10mm的孔”和“10mm通孔”两种表达，前者包含了特征类型，后者隐藏了“孔”这个语义。所以解析模块里必须维护一张同义表达表，并且对缺失槽位设置默认值，而不是让模型自己猜。

3.2 草图轮廓生成与约束求解，是返工最多的地方

拿到结构化意图之后，下一步是在目标平面上生成草图轮廓。这个过程远比想象中复杂，因为很多特征并不是简单的矩形或圆，而是需要计算轮廓相交、圆角过渡、局部切除等操作。我的做法是先把轮廓看成参数化几何图元集合——圆、直线、圆弧——逐个计算出来，再交给约束求解器去加尺寸和几何约束。

这里最容易翻车的是约束冲突。比如你既指定了直径40mm，又指定了圆心到边界的距离为30mm，而实际草图宽度只有55mm时，约束就会过定义导致求解失败。后来我在约束求解前加了一步可行性预检：先算一遍所有约束的数值区间，发现冲突就自动放宽次要约束，而不是直接把错误抛给用户。这个预检模块帮我省掉了至少一半的重试次数。

还有一个细节：草图平面的选取不能只靠“顶部”这种语义词。同一个圆柱，顶部可能是平面，也可能带倒角或者台阶。我的方案是先做面类型分类，挑出所有平面，再按法向量和面积排序，把最符合描述的那个面作为草图平面。如果描述里没明确位置，就默认取最大平面，这个规则在大多数简单零件上够用。

3.3 特征构建和特征树组织，决定模型能不能“改得动”

同样一个零件，特征的拆分粒度不同，后续的可编辑性天差地别。我习惯把一次文本生成对应建模操作拆成三段：基础体特征、减材特征、修饰特征。基础体负责先长出一块大形；减材负责孔、槽、腔这些掏空部分；修饰负责倒角、圆角、阵列这些细节。每段内部再按依赖顺序排好。

实际执行中我遇到一个棘手问题：阵列特征的顺序。如果你先做孔再阵列，特征树里是一个孔特征加一个阵列特征；如果你先生成多个孔再分别倒角，特征树会变得非常臃肿。最合理的做法是在生成序列时就把“阵列”作为一个高阶操作下发给内核，而不是循环执行多次单孔建模。这样生成的模型，用户想在阵列里改数量、改间距时，只需要动一个参数。

3.4 模型验证不能只看“生成了没有”，要看“能不能用”

生成完模型，别急着欢呼，我这边的经验是至少做三类验证。第一类是几何验证：检查体是否存在、有没有零厚度面、有没有干涉；第二类是参数验证：关键尺寸跟文本描述对比，偏差在0.01mm以内算过；第三类是特征验证：特征树里是否有用户后续可能要改的关键特征节点，比如通孔是不是真的贯穿、倒角是不是加在了正确棱边上。

我把这些验证打包成了一个自动化脚本，每轮生成之后自动跑一遍，输出一份包含尺寸偏差、拓扑检查、特征完整度的报告。这一步投入不大，但可以说是整个链路里性价比最高的一环。没有这套验证，你就永远只能靠肉眼在屏幕前转来转去，效率极低，而且很容易漏掉细微但致命的问题。

4. 实测里翻车的高发点，我列成一份排错清单

4.1 文本歧义比想象中更普遍

“在底部开个孔”这句话，你以为是朝下打孔，模型可能理解成在底面所在平面上画个草图再拉伸切除；更麻烦的是“底部”到底指底面外表面还是底面内侧。这类位置歧义在机械描述里随处都是。我的处理方式是强制在中间表示里把空间位置显式化——包括基准面、放置面法向、偏移方向、深度类型。宁可多问一句“这个孔是从下表面往内打，还是贯穿到底面”，也不要让模型瞎猜。

4.2 坐标系和放置面错位

这是我最开始复现时翻车最狠的地方。模型的输出坐标是基于自身姿态预估的，但实际CAD内核里，同一个零件旋转一下，所有面编号和法向量全变了。后来我学乖了：绝对不在模型输出里直接用全局坐标，而是全部换成“相对当前实体的面引用”——先选中某个面，再基于这个面的本地坐标系做后续操作。这相当于把坐标系的锚点从世界系改成实体系，鲁棒性一下子提高了很多。

4.3 约束失效导致整个特征静默失败

CAD里有一种很隐蔽的错误：某个约束求解失败时，内核不一定报错，它可能只是把这个特征标记为“悬空”，然后在视图里不显示。生成结束一看，零件缺了一块，但整个流程完全没有报错提示。排查了半天才发现是之前某个尺寸约束因为参数更新失联了。现在我在生成流程里加了一道强制检查——每完成一个特征，立刻查询特征树的激活状态，发现悬空特征就回滚到上一步重新生成，绝不往后走。

4.4 对称和重复特征被重复建模

描述“六个均布螺栓孔”时，有些模型真的会循环生成六个孔特征而不是一个阵列。这在视觉上没问题，但工程上就是灾难：用户要改螺栓孔直径，得手动改六次。我在后处理里专门做一个模式识别：检测相同参数、规则分布的多个同类型特征，自动合并成阵列。这一步对提升模型实用性帮助巨大，也是从“能看”到“能用”的一个关键分水岭。

4.5 评估指标自欺欺人的陷阱

如果你只用一个整体形状相似度指标来评估生成结果，很容易被骗。比如“缸体”和“实心圆柱”的整体距离偏差可能很小，但对一个需要安装活塞的缸体来说，中间那个孔没打通就是废品。所以我的评估表里每一项都必须能追溯到具体功能语义：直径对不对、深度对不对、位置对不对、有没有这个特征。宁可评估严格一点导致通过率偏低，也不能用一个模糊的“整体相似度”糊弄自己。下表是我实际用的精简版评估维度：

5. 后续要怎么演进，我的一点判断

5.1 多轮交互式建模会比一次性生成更早落地

一次性给一段话生成完整模型，听起来很酷，但用户真实的建模过程从来不是一锤子买卖——先定轮廓，再改尺寸，然后加特征，不满意再推翻其中两步。所以我认为 text-to-cad 的实用形态不会是“文本进、模型出”，而是“边聊边改”。用户先说“做一个底座”，模型给个初版，用户再说“高度改成30mm”“把四个角切掉”，模型在原有特征树上增量修改。这个交互闭环对模型的要求比一次性生成更高，因为它需要随时感知当前模型状态，但对用户的实用价值也大得多。从工程角度看，这也才真正配得上“参数化设计”这四个字。

5.2 草图加文本的多模态输入会更早成熟

纯文本描述几何细节其实很吃力。你说“中间凸起一圈”，我到底怎么理解这个“圈”的宽度、高度和截面形状？但如果配一张手绘草图，把轮廓画出来，再用文字补充尺寸和位置，信息就完整多了。我试过用“文本结构槽位加草图轮廓”的组合输入方式，效果对比纯文本有明显提升，尤其在异形轮廓和复杂曲线这些纯语言很难表达清楚的场景里。这不需要等什么新技术，现有的视觉语言模型加轮廓提取就能搭出来。

5.3 从“能生成”到“能交付”，缺的是约束体系和回归测试

很多人会忽略一个事实：CAD建模里最值钱的不是“生成了模型”，而是“这个模型可以被稳定地修改和复用”。一个生成出来的支架，如果用户改了一处尺寸，整个模型就因为约束断裂而崩溃，那它仍然不可用。所以接下来这个方向真正的护城河，不是生成模型本身的参数量，而是你沉淀了多少建模规则、约束模板和回归测试用例。我自己的做法是每处理一类新零件，就把它固化成一套测试集，跑通之后纳入日常回归，防止模型迭代后把以前能做的又搞坏。这套东西虽然不起眼，但时间越长价值越大。

从实际体验来看，text-to-cad 这个方向给我的最大感受是：它不像文生图那样追求“惊艳”，而是追求“可交付”。每一次输出都必须能放进工程流程里去检验，这逼迫你把注意力从花哨的模型结构转移到数据质量、约束鲁棒性和验证体系上。如果你也想在这个方向动手试试，我建议从小而具体的零件类别起步，先打通“文本解析-特征生成-几何验证”这条最小闭环，再慢慢扩展零件类型。先把一个类型的成功率做到百分之九十以上，比做一个“什么都会但都差一点”的通用模型有价值得多。