企业官网建设流程全解析

做结构设计、机械加工或者产品开发的朋友，这两年大概率已经被“text-to-cad”这个词反复刷屏。它不是一个具体软件，而是一类工具的总称：你把“一个带四个M5安装孔的铝合金外壳底座，内腔深度22毫米，外轮廓120乘80乘30”这种自然语言描述丢进去，它替你生成对应的CAD模型，而且是带特征树、能继续编辑、能导成STEP供加工的那种，不是渲染一张效果图糊弄你。

这个方向最近热度很高，GitHub上相关的开源项目star涨得很快，论文也一篇接一篇。我自己的判断是，它正在改变“从想法到三维模型”这条链路里最耗人的那一环。这篇文章我不打算复述论文结论，而是从使用者和复现者的角度，把text-to-cad的原理、路线、实操步骤、踩坑记录完整梳理一遍。适合以下几类人：想评估这个技术能不能引入自己工作流的机械工程师，做AI产品想找落地场景的开发者，以及想用文本生成快速出方案的概念设计师。文章涉及的内容我会尽量讲透，尤其是那些论文里不会写的细节。

1. 先看懂 text-to-cad 要解决的真实痛点

1.1 传统 CAD 建模的隐性门槛

很多人觉得机械设计门槛在数学和力学，实际上工具本身才是普通人最先撞上的墙。以Fusion 360或者SolidWorks为例，你要做一个稍微像样的零件，得先掌握草图绘制、几何约束、尺寸标注、拉伸、旋转、阵列、倒角、抽壳这一整套操作，每个操作背后还有一堆快捷键和面板选项。这里面的学习成本不是一两天能过的，往往是三到六个月。

我见过不少工程师明明对加工工艺很熟，建模却要反复查教程。更要命的是，设计过程中有大量重复劳动：标准件底座换个孔位，法兰盘改个直径，这类活儿高度套路化，但每改一次都要重新操作一遍建模界面。text-to-cad想解决的，正是这个“想法到模型”过程中由工具操作带来的隐性成本——它把建模的意图表达从“操作软件”变成了“描述需求”。这个转变听起来简单，实际影响却不小：这意味着建模这件事，开始从“技能密集型”往“表达密集型”迁移。

1.2 为什么是现在：大模型能力拐点

文本生成图像早在2022年就已经火过一轮，但文本生成CAD始终慢半拍，原因并不复杂：图像是像素网格，错了顶多是画面难看；CAD模型是严格几何实体，差一个约束就可能导致布尔运算失败，或者加工出来废件。早期基于规则的方法根本撑不住自然语言那种含混表达，而传统机器学习又处理不了三维几何的结构化复杂性。

真正让text-to-cad迎来拐点的，是大语言模型和多模态模型带来的两个能力：一是对自然语言意图的理解能力强了很多，二是代码生成能力成熟到了可以直接输出CAD脚本。同时，开源的CAD数据集规模也到了可以用深度模型训练的程度。技术、数据、算力三条线凑到一起，才让“给我一个带孔的法兰”这种话真正能变成可编辑的三维模型。另外，OpenCASCADE这类开源几何内核的成熟也功不可没，它让“执行代码生成真实实体”这件最底层的事变成了免费可用的基础设施。

1.3 目标用户与实际落地场景

以我周围接触到的情况来看，text-to-cad最现实的落地场景集中在几个方向：

• 前期方案快速迭代：概念设计阶段一天要出十几个外形方案，用文本改描述比重新建模快得多。
• 非专业人员的定制化需求：采购、销售拿着客户描述想让结构工程师快速出一版示意模型，避免反复邮件沟通。
• 参数化标准件库的自动化扩充：把现有标准件用文本描述一遍，批量生成不同规格型号，省去手工建模的时间。
• 教育培训：让学生用自然语言先学会表达几何需求，再回头看建模软件怎么操作，学习曲线会平滑很多。

当然，这些场景能落地的前提是，生成结果必须是真正的CAD实体，能进工程软件继续编辑，而不是一个静态的三维网格。这正是text-to-cad和普通3D生成（比如生成STL网格模型）最本质的差别，也是后面所有技术难点的根源。如果只是要一张好看的效果图，现有方案早就够用了；要的是能生产、能编辑的实体模型，才需要专门研究这个方向。

2. 核心技术路线拆解

2.1 路线一：把 CAD 建模当作编程任务

我最早尝试的text-to-cad方案，其实不是那些听起来很前沿的生成模型，而是大语言模型加CadQuery脚本。思路很简单：CAD有成熟的脚本化接口，CadQuery、FreeCAD的Python API、OpenCASCADE底层内核，都能用代码描述几何操作。那么让大语言模型直接生成这一段Python代码，再在本地执行，就能产出CAD模型。

这条路线本质上是用代码生成来代理几何生成，优势非常明显：模型不需要专门训练，直接用现成的代码大模型就能胜任；生成结果天然是参数化的，因为有Python代码在，后续改尺寸、改特征都方便；只要代码语法正确，OpenCASCADE内核会保证几何至少是合法的实体，不容易出现破面。我在内网环境里试用过7B级别的小模型来生成CadQuery代码，效果虽不如大模型稳定，但处理中等复杂度的规则零件已经够用，这对企业数据保密是个好消息。

缺点也很直接，大语言模型对三维几何的理解是“符号化”的，它并不真正知道一个扫掠路径在空间里怎么走，复杂曲面和复杂装配很容易生成出逻辑正确但几何错误的代码。所以这条路线适合轴套、法兰、支架、箱体这类规则机械零件，对自由曲面和复杂型面基本无能为力。我自己的评估标准是：凡是能用“二维草图+拉伸/旋转/打孔”三步描述出来的零件，这条路线都很稳。

2.2 路线二：序列生成与扩散模型生成

更贴近“生成模型”正统的是序列生成路线。这类方法的核心是把CAD建模过程编码成一系列离散的token，就像把一段话拆成词一样，把“画一个草图”“拉伸10毫米”“倒角”这些操作拆成token序列，然后用类似Transformer的模型自回归地生成整段建模操作序列，最后把生成的序列重放成CAD模型。

最典型的开源代表是Text2CAD（Zoo团队的工作）,以及DeepCAD系列。它们的训练数据来自Fusion 360的公开数据集，每个模型都被提取成“草图-拉伸-打孔”这样的操作记录序列。训练时，模型看到的是文本描述和对应的操作序列，学的是“从语义到操作”的条件映射。推理时模型先输出一整段操作序列，再用CAD内核重放，得到一个真正的参数化模型。

扩散模型路线则是另一类做法：把CAD操作序列映射到一个隐空间，用扩散模型在这个隐空间里做去噪生成，过程中用文本嵌入作为条件控制。相比自回归的逐token生成，扩散模型在生成整体形状一致性上往往更好，但控制精度和编辑性稍弱。这两条路线我实际跑下来的感觉是：序列生成的模型对“可编辑性”更友好，因为输出的操作序列本身就是特征树；扩散生成在形状多样性上有优势，但要把它变成能生产使用的模型，中间还得接一步参数化重构建，流程更长。

2.3 几何表示的选型：B-Rep、CSG 与网格

为什么text-to-cad不能直接复用Stable Diffusion那套？核心在于几何表示。图像模型处理的是像素网格，而CAD领域的主流表示是B-Rep（边界表示），也就是把实体描述成一组精确的表面、边和顶点的拓扑关系，并且带上曲面方程（Nurbs、平面、圆柱面等）。B-Rep的优势是数学精确、能直接用于CAM加工，缺点是没有统一的token化方式，模型很难直接输出。

另一类表示是CSG（构造实体几何），用布尔运算把基本体组合起来，表达简洁，但表达能力有限，多数机械零件并不适合纯CSG描述。网格表示（STL/OBJ）则是3D生成模型最常用的形式，也是text-to-cad在实际评估时踩过的坑：视觉上看起来像，但网格模型没法直接编辑、没法标注尺寸、更没法直接生成加工刀路。所以text-to-cad技术演进中一个很重要的努力方向，就是让模型直接输出CAD原生表示，或者至少保证输出结果能无痛转换回CAD。

从实际使用角度看，用户拿到手的如果是一个STL网格，基本只能看看外观；拿到STEP或者参数化特征树，才谈得上继续设计。这也是我评估一个text-to-cad方案好不好用的第一标准。顺便说一个容易忽略的点：即便是同一类表示，不同CAD软件之间的兼容性也有差异，所以生成结果最好统一用STEP中性格式交付，避免直接跨软件编辑原生文件带来的一堆兼容性麻烦。

2.4 数据集与训练细节

聊CV和NLP的人可能对数据集规模习以为常，但CAD领域的数据稀缺是真实痛点。目前用得最多的几个来源：DeepCAD数据集包含约17万个从Fusion 360社区采集的机械零件，每个零件都被拆解成一套“草图-拉伸”操作序列；ABC数据集有约100万个零件，覆盖面更广但注释质量参差；Text2CAD这类文本到CAD任务，还需要额外的文本描述，很多是用点云/三维模型的自动标注模型或大语言模型生成的合成描述。

我就遇到过一个数据相关的坑：模型在训练时把“圆孔”和“盲孔”混淆。查下来是数据集里这两种孔的描述标注高度相似，而且实际建模操作序列差异不大，导致模型学不到“到底要不要打穿”这种细节语义。这个问题直到后来用更细粒度的描述模板重新生成标注，再人工抽检校对，才明显缓解。数据质量对text-to-cad的影响，往往比模型结构本身更大，这点怎么强调都不过分。很多论文里展示的惊艳效果，背后其实是对数据做了大量清洗和标注工作，这部分在论文里通常只是一句话带过。

3. 实操复现：从文本到可编辑 CAD 模型

3.1 方案选型与环境准备

如果你现在想自己跑通一个text-to-cad流程，我会推荐先走“大语言模型 + CadQuery”这条最务实的路线，等理解了整个链路，再去看Text2CAD这类专门训练的生成模型。选这条路线有几个理由：依赖少、不需要GPU训练、结果可控性好、调试方便。更重要的是，这条路线走通一次之后，你会对“自然语言怎么变成几何操作”建立直觉，再去看那些论文里的模型架构会轻松很多。

环境准备上，推荐用Python 3.10以上版本，核心依赖就三个：CadQuery（负责几何建模）、FreeCAD的Python接口（用于兼容性检查和显示）、以及OpenCASCADE内核（CadQuery底层自带）。安装非常简单，一条命令搞定CadQuery：

pip install cadquery

FreeCAD按官方安装包装好后，在Python里配置一下路径即可。我自己是在Windows环境跑通的，Linux和macOS也没有本质差异。这里有个经验：CadQuery的版本尽量选2.x以上，API稳定性和文档完善度都好了很多。如果只是想快速出模型，不涉及复杂装配，CadQuery一个库就够了；如果后续要和加工软件联动，还是建议同时装上FreeCAD做格式转换，FreeCAD的STEP导入导出更可靠，尤其是批量处理文件的时候。

3.2 完整生成流程演示

下面演示一个最简单的流程：生成一个带中心通孔的法兰盘。先定义需求描述文本，然后让大语言模型生成CadQuery代码。以“外径60毫米，内径25毫米，厚度10毫米，中心通孔外带四个均布M6螺纹孔”这样的描述为例。

大语言模型给出的CadQuery代码大致长这样：

import cadquery as cq result = ( cq.Workplane("XY") .circle(60 / 2) .extrude(10) .faces(">Z") .workplane() .rect(45, 45, forConstruction=True) .vertices() .hole(6) .faces(">Z") .workplane() .circle(25 / 2) .cutBlind(-10) ) cq.exporters.export(result, "flange.step")

这段代码的逻辑是：在XY平面画直径60的圆，拉伸10毫米形成圆柱底板；在上表面建立新的工作平面，画一个45乘45的构造矩形，在四个顶点位置打6毫米的孔；最后在中心挖一个直径25的通孔。代码执行的产物是一个合法的STEP实体文件，直接用FreeCAD或者Fusion 360打开就能看到并继续编辑。

我特别想强调“工作平面”这个概念，这是CadQuery的灵魂。很多新手第一次生成的模型看起来莫名其妙，就是因为在错误的工作平面上做了操作。记得先理解每个操作是在哪个平面、哪个基准上发生的——大语言模型生成的代码，自己跑之前务必人工检查一遍坐标关系，尤其是第一次用的时候。

3.3 提示词调优实战

自然语言到CAD，提示词的质量直接决定结果质量，这一点和AI绘画类似，但约束更严格。我的经验可以总结成几条：

• 尺寸和单位必须明确。写“直径25”不如写“直径25毫米”，写“厚度10”会让模型在英寸和毫米之间乱猜。
• 关键特征要显式列出。想打通孔就写“通孔”，只写“孔”它可能给你盲孔，也可能给你螺纹孔。
• 几何关系用操作语言描述。“在顶面中心挖一个直径20的沉孔，深度5，然后在沉孔底面打一个直径10的通孔”比“上面有个台阶孔”可靠得多。
• 特征数量控制在合理范围，太复杂的描述生成代码时容易丢特征。一条描述建议聚焦一个主要形状加两三个次要特征，复杂零件拆成多次生成再装配。

实测过一个案例：同样是“法兰盘”这个描述，什么都不带生成出来的是一个简单的盘体；加上“外径60毫米、内径25毫米、厚度10毫米、四个均布孔直径6毫米”，生成结果的几何完全符合预期，差异就是这么大。我建议每条提示词都按“主体形状+关键尺寸+特征位置+孔洞细节”四段式来组织，这样模型不容易漏信息，出问题也方便定位是哪个环节理解偏了。

4. 避坑指南：常见问题与排查

4.1 生成结果形状不符合描述

这是我遇到频率最高的问题。原因通常不是模型能力不够，而是描述和代码之间存在理解的gap。排查时先把自己当作审核者，按顺序核对：轮廓对不对、尺寸对不对、特征位置对不对、打孔是否穿透。如果发现尺寸对但位置乱，多半是工作平面选错了；如果轮廓对但深度不对，多半是拉伸方向理解偏了。

如果是在用Text2CAD这类专用模型，症状会更明显：尺寸基本对不上，比例失调。这些模型在语义层面学得还可以，但数值精确度并不好，因为它们的目标函数是形状相似度，不是尺寸误差。产品设计阶段可以接受“大概像个法兰”，但要出图纸就完全不行。所以专用生成模型的输出，我的建议是永远当作“概念草图”对待，进入工程阶段前还是要参数化重建一次。这点说起来简单，实际做的时候很多人会偷懒直接拿去加工，结果废件率感人。

4.2 模型无效或不可编辑

CadQuery/OpenCASCADE路线里最常见的坑是“模型看起来对，但布尔运算报错”或者“导出的STEP在其他软件里显示为破面”。这类问题的根源多数是布尔操作对象之间出现了零厚度间隙、重合面或者退化边。调试技巧是：先简化特征，把倒角、螺纹这类后处理特征去掉，验证基础实体是否合法；再逐个加特征，定位到具体出错的操作。这个过程虽然枯燥，但非常有效。

另外一个典型问题是“不可编辑”。Text2CAD生成的模型如果是以网格形式交付，那就基本告别参数化编辑了。就算是以操作序列生成的模型，很多模型输出的特征树也非常混乱，草图约束缺失，改一个尺寸可能连锁报错。我自己的习惯是：收到生成的模型后，先检查特征树是否干净，有没有大量“布尔差集”和“固定位置基准面”这类不可维护操作，如果有，宁可重新生成一次或者手动重建，也别在垃圾特征树上硬改。经验告诉我，留着问题特征树继续改，最后的时间成本往往比重建还高。

4.3 精度与工程可用性差距

必须坦诚讲一句：目前所有text-to-cad方案，距离直接进机加工车间都还有距离。原因不在于生成模型让零件“好看不好看”，而在于工程图需要的公差、表面粗糙度、螺纹规格、热处理要求这些制造语义，文本生成模型基本不会主动处理。我们现在能做到的极限，是“概念设计和快速示意”层面零障碍，以及“标准件参数化生成”层面比较可靠。

尺寸精度方面，LLM加代码生成的方案误差反而更小，因为代码里写多少毫米就是多少毫米，只要代码正确；专用生成模型则容易在毫米级甚至百分之几的比例上出错。这也是我在实际项目里更倾向“LLM生成代码、代码驱动建模”方案的原因，对制造环节更友好。如果你只是拿来做渲染图或者手板示意，那专用模型的多样性更有价值；但凡是后面要出工程图，代码生成路线的优势会越往后越明显。

4.4 部署与性能调优记录

在实际部署使用中，环境与性能问题同样值得说几句。如果用的开源大模型在本地跑，显存占用会非常高，建议优先考虑API方式调用，或者使用量化后的本地小模型。如果是在企业内部用，还要考虑数据保密，私有化部署一个小尺寸代码模型（7B或14B级别）其实够用，因为CadQuery代码生成任务的复杂度远低于通用编程，小模型完全能顶住。我在内网部署过一个7B模型，推理速度明显比调用云端大模型API慢，但单条文本生成一段代码通常也在几秒内，完全在可接受范围。

性能调优上最简单的收益点是控制输出长度：提示词里明确“只输出Python代码，不要解释”，可以省掉大量无用的token，不仅加快推理，还减少格式解析报错，实测推理速度能提升两到三成。另一个是批量生成时把重复的库导入语句和导出语句写在模板里，让模型每次只生成核心几何操作段，效果很显著。这种小技巧不算什么高深技术，但能实打实影响你在生产环境里的使用体验。

最后分享一个我自己正在做的扩展尝试：把text-to-cad和参数化族表结合。思路是先让LLM根据文本描述生成一个基准模型和一组参数方程，再让同一个对话上下文批量生成规格变形。比如“法兰盘，外径随压力等级变化，螺栓孔数随外径变化”，LLM先给出参数关系，再按系列生成十几个STEP文件。实测下来效率比手工建模高一到两个数量级，但前提是在第一阶段就把参数规则约束清楚，否则后期调整很痛苦。

另外一个小技巧：生成的STEP文件，建议必做一次“导入-导出”循环再发给加工方。也就是用FreeCAD或者CAD软件打开，什么都不改，再重新导出一次STEP。这样能清理掉生成器留下的一些非标准结构，很多CAM软件对这类文件的兼容性会好很多。这个习惯帮我避免过多次加工端报错。说句实在话，text-to-cad现在已经是够用的起步工具，但真正要让它好用，靠的还是你自己在工程环节加的约束和检查。多试几个方案，找到适合你业务的那条链路，比纠结“哪个模型最强”重要得多。