企业官网建设流程全解析

我不太确定你有没有遇到过这种场景：结构工程师扔过来一句“帮我画一个轴套，外径40，内径25，长度60，一端带六个均布螺栓孔”，然后你打开CAD软件，建草图、标约束、做拉伸、再阵列打孔，半小时就没了。如果运气不好，中途改一版尺寸，所有关联特征还得重新捋一遍。text-to-cad这个方向，就是想把这件“听着简单做起来烦”的事，用自然语言直接驱动三维参数化建模。它不是你输入一句话就给你导出一个破烂mesh，而是生成一整套可编辑、可重用的建模过程，类似软件里的“设计树”。这篇东西我会把text-to-cad的技术链路、主流实现思路、实操复现步骤和典型坑位一次性讲清楚，写给搞三维视觉、CAD二次开发、以及想做AIGC工业化落地的朋友。

先说几句定位。text-to-cad目前还没有一个统一的技术标准，它更像是“自然语言处理+程序化CAD生成”的交叉地带。你要明白它和text-to-3D（如生成mesh或者神经辐射场）有本质区别：mesh生成出来是死的，不能改参数，不能进装配，更没法直接下加工；text-to-cad生成的是活的，是特征序列、约束关系和建模指令，能在原生CAD环境里继续编辑。所以它的应用价值不在“做个好看的模型摆在那”，而在“把重复的建模劳动变成自动化流水线”。

1. text-to-cad到底在解决什么问题

1.1 传统三维建模的“反直觉”成本

我最早接触CAD的时候一直有个困惑：为什么画个零件这么别扭？后来想明白了，CAD软件本质上是“约束求解器+历史记录器”，它要求用户用非常精确、极其反自然语言的方式描述意图。你说“这里有个孔”，软件不理解“这里”是哪里，你必须给出圆心坐标、直径、深度、是否贯通、是否与某个面垂直——少一个信息，模型就报错。

这个过程的隐性成本非常高。一个零件从构思到出图，真正花在“想怎么设计”上的时间可能只占两成，剩下八成都在“让软件理解我的设计意图”。更麻烦的是，一旦设计变更，比如轴套长度从60改成90，你期望后续所有特征自动跟着变。理论上是这样，但前提是你建特征时约束关系维护得足够好。实际项目里，很多人建模都是“拉出来再说”，最后改尺寸时约束崩成一团，只能删了重画。

text-to-cad切入的正是这个痛点。它尝试把“设计意图”和“参数化特征序列”解耦：你只需要用自然语言描述意图，模型负责翻译成一连串合法的CAD操作。这个翻译过程如果做得好，生成结果天然就是参数化的、可编辑的。这也是它比AI生成mesh更适合工业场景的根本原因。

1.2 从“看得像”到“能用”的鸿沟

做图形学的人都知道，生成一个“看起来像”的零件不难，难的是生成一个“能用”的零件。什么叫能用？放到CAD软件里，它必须满足几个硬指标：几何没有自相交、所有草图完全约束、特征执行顺序合法、修改参数后拓扑不变，最好还能直接导出STEP/IGES给下游CAM做加工。

这就引出了text-to-cad最核心的难点——它不是一个单纯的生成问题，而是一个带约束的序列决策问题。模型每预测一个建模命令，都必须保证当前状态是可求解的，下一个命令在这个状态下是合法的。比如你先拉伸了一个长方体，然后说“在顶面打四个孔”，那模型必须知道顶面在哪、孔的位置如何用参考边约束住、深度会不会超过拉伸厚度。这些知识，光靠“看图学特征”是学不来的，必须让模型理解CAD建模的底层规则。

另一个难点是语言本身的高度歧义。同一个词，在不同工程师嘴里含义完全不同。“把这个边倒个角”，有人想要C1，有人想要C2，还有人只是想让边不那么刮手。text-to-cad系统如果只做关键词匹配，必然翻车。所以现在的方案普遍走向“多模态对齐+规则约束”的路子：语言模型负责把自然语言映射成结构化意图，CAD求解器负责保证几何可行性，中间再加一层约束校验。

2. 关键思路：把CAD建模拆解成可学习的序列

2.1 参数化建模到底“参数化”在哪里

要做好text-to-cad，必须先理解传统CAD系统里的模型是怎么组织的。拿SolidWorks或者FreeCAD举例，一个零件的本质不是一个三角网格，而是一棵“特征树”。树根是基准面，往下依次是草图、拉伸、切除、倒角、阵列等特征。每个特征节点都带有参数，比如拉伸距离50mm、草图里某条线水平约束、孔直径8mm阵列6个。

这棵特征树有几个关键特性。第一，它有严格的时序依赖，后面的特征依赖前面的几何结果，改了中间某一步，后面全部重建。第二，它有明确的参数空间，每个特征可以表达成一组数值和枚举值，比如“拉伸{深度:50, 方向:正向, 布尔:新增}”。第三，它的状态是可验证的，给定一个特征序列，CAD内核可以直接求解，成功就得到实体，失败就报错。

正因为有这些特性，CAD建模过程才能被“序列化”。你完全可以把一个零件建模过程写成一份JSON或者程序脚本，按顺序执行就能重建整个实体。DeepCAD和Text2CAD这些项目走的就是这条路：把建模范式从“鼠标点击”转换成“程序指令序列”，然后用序列生成模型去学习。这比我之前接触的“直接生成点云/隐函数”路线要务实得多，因为输出的每一步都能被CAD内核验证，错的命令大概率直接报错，不会生成一个看似光鲜实则无法加工的实体。

2.2 三条主流技术路线对比

现在做text-to-cad，大家基本沿着三条路线在走，各有取舍。

第一条是“检索+参数调整”路线。系统先分析自然语言，提取关键实体和参数，然后去零件库里检索最接近的模板，最后把差异部分通过参数更新实现。这条路线最简单，工程上最容易落地，适合标准件变体这种场景。缺点也很明显：面对没见过的新颖结构就抓瞎，检索不到就是零输出。

第二条是“特征序列生成”路线，也是目前paper主力。模型把CAD建模命令序列当作一种特殊语言来生成，类似BERT/Transformer做代码生成。输入是文本描述，输出是一个接一个的建模指令token。DeepCAD是最早把大量CAD命令序列收集成数据集并用Transformer建模的，Text2CAD则在它基础上加了文本-几何模态对齐。这条路线上限高，能生成没见过的新结构，但训练难度也最大，命令序列长、搜索空间巨大，很容易出现“前半段合理、后半段崩坏”的情况。

第三条是“扩散/流模型直接生成约束图”路线。它不直接生成命令序列，而是生成一个“几何约束图”，节点是面、边、孔等特征，边是距离、角度、共面等约束，最后交给约束求解器去实例化。这条路线比较新，好处是约束图天然可编辑，坏处是前后端衔接复杂，目前还不太成熟，更多是研究性质。

我自己实际体验下来，现阶段最靠谱的还是第二条路线。它和语言模型生态天然契合，也有一批开源数据集和预训练权重可以直接拿来用，适合先在本地跑通一个完整demo，再逐步迭代。

3. 动手跑通一个最小可用的text-to-cad流程

3.1 数据集和指令设计从哪来

想自己搭一个text-to-cad，第一关不是模型，是数据。模型再强，没有“文本-建模序列”的配对数据就是无米之炊。目前公开可用的数据集主要是从CAD模型库反推得来的：把大量STEP/FCStd文件解析成特征序列，再给它们配文本描述。Text2CAD项目组开源的数据集大概就是这个路子，里面包含了包含文本描述的机械零件建模序列，你可以在HuggingFace上找到。

如果你的业务是垂直领域，比如只做精密五金件，纯靠公开数据集肯定不够。我的做法是两条腿走路：一方面用公开做预训练，另一方面基于内部历史图纸做“二次标注”。具体操作是，把历史建模过程导出成命令宏，然后请几位工程师用两到三句话描述“这个零件是干嘛的、关键尺寸是哪些、有几个什么特征”。这个标注成本其实没想象中高，因为只需要文字标注，不需要画图。磨合一段时间后，模型在垂直场景的文本对齐明显比裸用公开数据准得多。

指令设计上有个小经验：不要把整段零件描述一股脑丢进去。我试过把“带法兰的轴套，外径40，内径25，长度60，六个均匀分布的孔”当成一句话输入，效果一般。后来改成结构化的“主特征+辅助特征+关键参数”模板，比如：“machined part: 主要实体是轴套；外径40；内径25；长度60；辅助特征：端面法兰，直径80，厚度8；六个均匀分布孔，直径6，分布在端面法兰上，中心圆直径65”。模型的理解准确率会好很多。这个现象说明，语言模型确实需要结构化输入，而不是纯粹的“人话”。

3.2 模型结构怎么选：编码器-解码器只是起点

做这个任务，最直接的是用标准Transformer编码器-解码器。输入侧放文本描述，输出侧放CAD命令序列。但直接照搬机器翻译的结构，效果不会太好。原因在于CAD命令序列有很强的层级结构：外层是特征顺序，内层是每个特征的参数块。普通Transformer的自回归模式很难记住“前面开了一个草图，写到这里还没close”这种上下文。

我的经验是至少加两个结构性改进。第一个是给命令token引入“类型嵌入”。每个token不仅表示命令类型（比如Circle还是Extrude），还额外编码它属于第几个特征、是特征的开头还是结尾。这样模型相当于获得了“设计树层级”的先验，生成长序列时不容易迷失。第二个是在解码端引入几何一致性校验。每预测完一个特征，就用一个轻量级CAD内核实时执行一遍，如果非法就直接给这个序列打低分，让它去找备选token。有了这个“执行反馈”，模型生成的有效率明显提高。

参数规模上，我建议从中小规模开始试。大概100M到300M的参数，已经足够学到简单的拉伸、切除、阵列操作。不要一上来就堆几十亿参数，数据和算力都吃不消。我在8张V100上训一个200M左右的模型，大概两天就能见到还不错的输出；50亿以上的模型，光调并行策略就够喝一壶的，收益未必成正比。

3.3 训练和推理阶段的关键细节

训练阶段有几个细节值得单独拎出来说。首先是序列长度与批次的取舍。CAD命令序列动辄几百上千个token，如果把整个序列都塞进batch，显存马上爆炸。我用的折中方案是“特征级截断+全局上下文压缩”：序列按特征切分，每批最多装载若干个完整特征，但给模型额外传一个“全局摘要token”，这个token是从开头到当前位置的简化向量，相当于给模型提个醒：你现在做的是第几个特征、零件大致是什么形状。这样既控制显存，又保留全局信息。

推理阶段比训练更容易踩坑。我用贪心解码和beam search对比过，贪心经常会卡在一个循环里反复预测同一个特征。换成beam search后好很多，但beam width开太大会导致输出特别保守，翻来覆去就是几个常见特征组合。我的经验是把beam width设在4到8之间，同时加一个“重复惩罚”，让同样特征不要连续出现超过两次。另外强烈建议在做final selection之前，把beam里的所有候选序列都跑一遍CAD内核，直接丢弃执行失败的，再在成功序列里按“几何体积误差”和“特征耗时”综合打分。这一步能显著提升最终可用率。

注意：训练数据的归一化也很关键。不同软件导出的命令序列，单位、原点、坐标系朝向都不一样。我踩过一个大坑：混用不同来源的训练数据，模型学到了“拉伸方向绝大多数是Z轴正方向”，结果输出一堆朝向奇怪的零件。后来统一把所有数据归一化到固定坐标系，并让模型以“局部坐标系”输出，问题才消失。

3.4 后端渲染与交互怎么接

模型输出的命令序列还只是中间产物。如果不想让用户只看到命令行，你需要一个可视化前端。最省事的方案是直接对接FreeCAD的Python API。把命令序列解释成一系列Part模块调用，生成实体后在FreeCAD窗口里展示。之前我对FreeCAD的评估是“性能一般，但脚本化能力强”，在这个场景下反而比商用软件更合适，因为你可以完全绕过交互操作，直接在后台跑脚本，然后把渲染结果回传。

如果团队前端是Web技术栈，可以走CAD内核的JS版本，比如用基于OpenCascade的WebAssembly方案。输出STEP文件后，在前端解析并渲染出特征树和三维视图。这块工作量大一些，但实际演示效果非常好，用户可以一边看三维模型一边看生成的设计树，甚至直接改某个参数触发重新生成。我在一个内部demo里就是这么做的前端，整体体验已经比较接近“AI辅助设计”的想象了。

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

4.1 模型输出了非法命令怎么办

这是text-to-cad复现时最容易碰到的第一座大山。你训练完模型，满怀期待输入“生成一个带凸台的底板”，结果输出的命令序列里，第二个特征就引用了一个不存在的面。这类问题靠调模型本身很难根除，因为几何合法性本质上不是纯语言问题。

我的处理方式是“三层防线”。第一层是规则预过滤：在数据进模型之前，就把明显非法的命令组合剔除，比如没有草图的拉伸、没有面的倒角。第二层是在推理时接一个CAD内核求解器，每生成一步就执行一步，非法命令直接打回。第三层是后处理修复：对于少数执行到一半报错的序列，如果只是某个参数越界，我会自动把参数“钳制”到合法区间再重试。这三层叠加下来，最终成功率能达到85%以上，单纯靠模型生成可能只有四成。

4.2 生成结果几何质量差：孔不圆、面扭曲

还有一个高频问题：明明命令全部执行成功，但是模型生成的几何非常粗糙，比如圆孔变成多边形，拉伸面出现扭曲。这种情况我排查过几次，基本都出在“参数精度”上。模型输出的是离散token，如果token粒度不够细，圆孔半径只能取到几个离散档位，自然组合不出精确的几何。

解决办法有两个方向。一个是在tokenizer里对数值参数做“残差回归”，也就是除了预测离散的粗粒度token之外，再加一个小的数值回归头，输出精确的浮点偏移量。这相当于“先定档位，再微调”。另一个方向是引入障碍函数，让模型在预测参数时受到内部几何约束的软惩罚，比如孔直径必须小于法兰宽度、孔位必须落在实体内部。第二个方向需要在训练时就把约束通过loss注入，实现起来麻烦些，但效果更稳定。

4.3 提示词怎么写才能让模型稳定输出

很多第一次接触text-to-cad的人会问：提示词工程在CAD任务里有没有用？答案是：有用，但不是让你像写“魔法咒语”一样堆关键词。CAD任务更吃“结构化的约束描述”而非“形容词修饰”。你写“一个高精度的、坚固的、工业级法兰盘”，对模型毫无帮助；你写“法兰盘，外径120，内径50，厚度12，六个M8孔均布于直径90的圆上，孔深10”，模型才能稳定复现。

我建议把提示词固定成一个四段式：“部件类别+主体尺寸+特征列表+参数表”。部件类别让模型确定基本拓扑；主体尺寸确定整体比例；特征列表确定有哪些加工步骤；参数表给出具体数值。用这个模板去套，哪怕换不同的模型架构，生成质量都相对可控。反之，如果你让模型自由发挥，它会倾向于生成训练集里最常见的“方盒子打几个孔”，而不是你真正想要的东西。

4.4 常见问题速查

这里把我实际遇到的高频问题整理成一个速查表，供各位参考，省得你们一个个去踩坑：

5. text-to-cad能用在哪些真实场景

5.1 结构化工业件的自动化建模

text-to-cad最成熟的落地场景是结构化工业件，尤其是那些“看着复杂但规律性强”的零件。举个例子，很多非标自动化设备里的支架、底座、法兰、轴承座，本质上就是“一个主体+若干孔+若干凸台+些许倒角”。这类零件设计没什么创造性，但每个月要出几百上千个变体，每次都要人工建模，极其枯燥。把它们交给text-to-cad去做，工程师只需要用自然语言描述“底板长宽高、安装孔位置、避让槽深度”，模型就能生成一版带特征树的模型，工程师检查后微调一下就能投图。这个场景下，哪怕生成成功率只有六七成，只要错误能被快速修正，整体效率提升都是巨大的。

5.2 面向设计师的“语义化建模”辅助工具

再往外延展一点，text-to-cad还能做“语义化建模”的交互入口。现在很多三维建模软件的菜单层级非常深，一个简单的打孔操作要连按好几次鼠标。如果有了text-to-cad这层翻译，用户完全可以一边口述“把这个边倒角，然后给底面加四个支撑筋”，一边看着软件自动执行。它不会完全取代精细的手工建模操作，但当“快速原型”阶段，能极大降低软件操作门槛。我甚至看到有团队把语音识别和text-to-cad接在一起，工程师戴着AR眼镜直接“说”零件，模型就在后台生成特征序列并在眼镜里实时预览。说到底，CAD工具早晚会从“命令驱动”走向“意图驱动”，text-to-cad就是这条路上的一个关键转换层。

5.3 数据增强与逆向工程里的暗藏价值

text-to-cad还有一个很容易被忽略的用途：数据增强。在做三维视觉、机械臂抓取、装配仿真这些任务时，我们需要海量带标注的三维模型，但真实模型数据的获取成本极高。text-to-cad模型可以像“编故事”一样批量生成大量合理零件——先随机一个文本描述，再让模型生成对应模型。因为这个过程是参数化生成，每个模型还自带完整特征树和参数表，正好作为下游任务的ground truth。这一点对于做合成数据的朋友来说，可能比“直接生成零件”本身更有吸引力。

6. 一些个人的实际体会

从第一次看到DeepCAD的论文，到亲手跑通一个能用的text-to-cad小系统，前后也折腾了好几个月。我的一个深刻感受是：这个方向真正的难点不在“生成模型”，而在“几何约束的闭环”。如果你只是做一个离线生成demo，那难度不大；但只要你想让它产出能用的模型，就必须把“语言生成”和“CAD求解”捆绑在一起，让模型在每一步都感知到几何状态。很多做深度学习的人一上来就追求模型更大、数据更多，反而忽略了这件事。我坦白说，现阶段离“输入一句话就出完美零件”还很远，但在垂直领域做“半自动辅助建模助手”是完全可行的，关键是选好数据和场景边界——把自由度收窄到某个零件族，成功率一下子就上来了。

最后再分享一个小技巧。如果你打算跑开源项目入门，优先去跑那些提供了“预训练权重+完整数据管线”的项目，不要自己从头整理数据。先把人家的模型跑通，再试着替换成你自己的领域数据，这样你很快就能找到“模型失效”的真正边界在哪里。等边界清晰了，你自然就知道该在数据、模型结构还是后校验上投力气了。