企业官网建设流程全解析

从自然语言直接生成CAD模型，这几年一直是CAD/AI交叉领域里最让人兴奋的方向之一。一提“text-to-cad”，很多人第一反应是“这不就是文生图换个赛道吗”，但真正动手试过就会发现，它和图像生成完全不是一回事。CAD模型要的不是一张“看起来像”的渲染图，而是带尺寸、带特征树、能进CAM、能上车床铣床的实体模型。这个门槛，决定了text-to-cad的技术路线和实现难度。

这篇文章我会从项目思路、核心模块、实操流程、常见坑点几个层面拆解一遍，把我自己在搭建文本到CAD管线时踩过的坑、验证过的方案、以及我认为值得投入的方向都整理出来。适合正在做AI辅助设计、想把自己的建模流程自动化，或者对生成式CAD感兴趣的工程师和设计师阅读。

1. 项目概述：text-to-cad到底在解决什么

1.1 为什么“文本生成CAD”比“文本生成图片”难得多

先说一个容易忽略的事实：文本生成图片，模型输出的是像素矩阵，哪怕某个细节画错了，整体观感仍然成立，人眼会自己补全。但文本生成CAD，模型输出的必须是一个严格封闭、满足尺寸约束、能进行布尔运算的实体模型。差一个毫米，零件装不进去；少一条约束，草图就无法拉伸；特征树里多一步打孔，下游制造路径可能全乱。

这就是text-to-cad最核心的难点：语义不确定性 vs 几何精确性之间的矛盾。一句话里的“差不多”“略大”“合适的位置”这类模糊表达，在自然语言里完全没问题，但CAD系统不接受模糊，所有几何都必须落成确定的数值、确定的特征操作和确定的空间关系。

所以text-to-cad本质上不是在“生成图片”，而是在做一件更接近“程序合成”的事情——把自然语言描述翻译成一段严格的建模脚本、一组特征操作序列，或是一棵CSG（构造实体几何）树。这也是当前所有可行的技术路线的共同基础。

1.2 项目定位与目标输出形态

在项目设计初期，必须先把“我们要生成什么样的CAD模型”定义清楚。这一步决定后面所有的数据处理、模型选型和评估方案。

目前常见的输出形态有三类：

• 网格模型（Mesh）：比如OBJ/STL格式。生成难度最低，但无法编辑、无法直接进入参数化工作流，只能当展示或3D打印粗模用。很多以扩散模型为基础的文生3D方案都停在这一层，严格来说它们不算CAD。
• BREP实体边界表示：比如STEP格式。能表达精确的曲面与实体边界，制造可行性高，但它丢失了建模过程，下游想改动某个圆角半径或某个孔的深度会很痛苦。
• 特征历史（Feature History / Construction History）：这是最理想的输出形态，模型本身“记住”了自己是怎么一步步被建模出来的。用户拿到模型后，可以像打开一个原生CAD文件一样，双击某个拉伸特征修改参数、拖动特征顺序。要做到这一步，本质上是让模型学会生成“建模操作序列”。

我在项目里最终确定的形态，正是第三种——让模型输出一个操作历史脚本。原因很简单：只有特征历史才能真正嵌入现有设计流程。如果你生成的东西没法被设计师二次修改，那它在工程场景里几乎不会被使用。

2. 核心技术拆解：管线设计与方案选型

2.1 整体管线架构

整个text-to-cad系统可以从功能上拆成两层：

第一层是语义理解层。输入一句自然语言描述，经过模型解析，输出结构化的中间表达。这个中间表达可以是JSON格式的约束图、带槽位的程序调用，也可以是CSG生成树的内部表示。这一层的核心任务是把“语言中的模糊意图”转化为“明确的几何指令”。

第二层是几何构建层。拿到上述指令后，由参数化几何内核完成具体的草绘、拉伸、打孔、倒角等操作，最终构建出实体模型。这一层不负责理解语义，只负责精确执行。

我比较推荐的分析视角是：把整个管线看成一个“超级编译器”。自然语言是高级语言，CSG树是中间表示，最终的BREP实体是目标机器码。语义理解层负责前端编译，几何构建层负责后端执行与优化。一个常见的框架是用代码生成模型输出针对某个参数化内核的脚本，经由内核求解器完成实体构建。

这种拆分的优势很直接：语义层和几何层可以独立优化。你可以在不改变几何内核的前提下，单独升级语言模型的指令遵循能力；也可以在语言模型不够强的时候，用规则引擎预先处理一部分结构化命令。对早期项目来说，这种灵活性等于保命。

2.2 命令序列生成：把建模当成程序合成

当前效果比较稳定、也容易工程化的一个路径，是把建模过程建模成“API调用序列的生成问题”。

随便打开一个参数化CAD软件，你做的每一个操作从本质上看都是一个函数调用。画一条直线，是create_line(start_point, end_point)；拉伸出实体，是extrude(profile, depth, direction)；打一个孔，是create_hole(face, center, diameter, depth)。整份设计图，本质就是这些调用的有序集合。

如果能生成正确顺序的调用序列，CAD内核执行完这些调用后，自然就得到了符合预期的实体模型。因此，text-to-cad可以转换成一个结构化的代码生成任务。模型输入自然语言描述，输出一段调用内核API的程序脚本。

这种路线有几个明显的优点：

• 可解释性强：每个生成的步骤都能回溯与验证，方便定位错误发生在哪一步。
• 天然支持参数化：脚本里保留的是带变量的特征参数，而不是烧成死的几何坐标。
• 数据可利用性好：CAD软件的历史记录、宏文件、API脚本都可以作为宝贵的监督数据。

训练端，常用Transformer架构的Decoder模型，输出按建模语义排序的token序列。在推理时，配合约束求解器做后期校验，保证最终生成的是一个工程上可用的实体。

我当时在做技术验证的时候，完全没有能力去从头训练一个几十亿参数的专用模型。最务实的方式是直接基于已有的代码能力模型做微调，或者在其输出后进行格式约束，配合一个参数化内核执行脚本并检查报错。事实证明，这种结合方案达到的效果远超预期，也让项目早期就能做出可演示的原型。

2.3 数据、标注与合成策略

text-to-cad在数据层面的难度不亚于模型本身训练：公开的“文本-CAD模型”配对数据极为稀缺。一个核心原因是，设计师在各平台分享图纸时，很少会附带自然语言的设计意图描述；就算有，描述也千奇百怪。

数据获取有几个可落地的来源：

• 程序化与参数化合成：定义一个基础模型模板（例如“带通孔的板子”“带倒角的轴类零件”），然后随机生成参数组合，再自动渲染出对应的几何体和参考CAD脚本。这种方式能在短时间内生产大量配对数据，是训练集的主要来源。
• CAD脚本库清洗挖掘：一些开源社区的模型库（如某些用代码建模的项目），天然就有脚本和结果文件。可以编写自动提取脚本建立配对关系，但需要做大量清洗工作，因为其中相当一部分脚本和注释并不对应文本意图。
• 人工标注（少量）：招募熟悉CAD软件的标注人员，按产品化标准撰写高质量的自然语言描述。这类数据很贵，但适合作为测试集和微调集。因为人工标注的描述往往比较接近真实文本的复杂句式（包含专业术语、序号引用、工艺注释），这在提升模型泛化能力上作用明显。

在数据合成方面重点提醒一下：合成数据虽然便宜，但也容易造成“同质化偏置”。如果你的合成模板永远只有“矩形板、腰型孔、四角倒角”，模型对旋钮、壳体、法兰之类变化就毫无能力。要在合成阶段刻意加入变化的语法结构、局部细节的复杂度，甚至用随机流程生成更丰富的空间拓扑关系，才能让模型不再“背模板”。

3. 实操过程与关键环节实现

3.1 第一步：最小可行系统的搭建

不需要一上来就训练模型。我强烈建议，先用现有的代码生成模型加一个几何内核，挤出几天时间搭一个最小可行的端到端demo，验证“自然语言—建模脚本—CAD实体”的路径是否跑得通。

具体的工程选择方面，我把设计说明放在这里：

• 几何内核：选择一个可脚本化、提供API接口的参数化建模环境，例如以脚本方式定义实体。
• 模型语言：选用一个对代码生成较擅长、支持指令跟随的预训练模型，优先考虑能处理较长文本和复杂调用的版本。
• 中间格式：让模型直接输出目标内核所支持的脚本语言，而不是自创一种中间格式，减少一次转换损耗。

一个关键实操细节：不要拒绝为模型提供“API文档片段”。很多时候，通用模型对特定内核的API函数名称和参数顺序并不熟悉，我们只需要在System Prompt里注入一份精简版的API手册，效果通常立刻会有显著提升。这与给模型更多参考上下文是同一个道理，成本几乎为零。

3.2 一个具体示例：从文本到脚本的转化

为了更直观地说明模型在做什么，我举个例子。假设输入文本是：

“创建一个50毫米×30毫米的矩形板，厚度5毫米，在四个角各打一个直径6毫米的贯穿孔，孔中心距边10毫米。”

这条指令在我们的系统里会被处理为类似下面的脚本（我简化了内核函数名来演示思路）：

# 初始化零件 begin_part("Plate") # 进入草图环境，选择XY平面 set_sketch_plane("XY") # 创建矩形轮廓，左下角在原点，宽50、高30 create_rectangle(0, 0, 50, 30) # 退出草图 finish_sketch() # 拉伸实体，深度为5毫米 extrude(5, direction="+Z") # 在顶面创建孔特征 begin_holes() create_hole(center=(10, 10), diameter=6, depth=5, through=True) create_hole(center=(10, 20), diameter=6, depth=5, through=True) create_hole(center=(40, 10), diameter=6, depth=5, through=True) create_hole(center=(40, 20), diameter=6, depth=5, through=True) finish_holes() # 保存模型 save_part("plate_with_holes.step")

执行完这段脚本，内核就会生成一个正确的实体模型，并保留完整的特征历史。之后设计师也可以直接在建模环境里打开这个文件，修改孔的位置和大小，随时重新生成。

我在项目里曾专门设计过一个错误触发用例来检验系统可靠性：当文本描述中只给出“四角各打一个孔”，但没有写孔径时，模型如何推断合理的默认值？在提示词里显式加入“默认孔径按板厚的30％估算，并给出用户可调整的可配置参数”之后，模型生成的脚本不仅带默认值，还在参数顶部自动以类似参数表的形式作了标注。这种设计方案会让最终的生成结果远优于单纯死板的模板匹配。

3.3 参数选择与推理调优

模型推理阶段有几个参数值得格外在意，特别是当你用的解码参数不可调时：

• 温度（Temperature）：CAD脚本生成不能有太多的随机性。推荐把温度设置得偏低（如0.2以下），必要时关闭采样开启贪心解码。因为CAD脚本是一种语法严格的语言，哪怕多一个空格、少一个标点，内核都可能直接拒绝执行。
• 最大生成长度：脚本通常会比较长，尤其是复杂的零件，可能有上百行调用。需要给模型充足的输出空间，否则容易被截断在半句话里，导致语法不完整。
• Top-P 与重复惩罚：适度调低Top-P（如0.8左右）可以有效过滤低概率的语法错误分支。但重复惩罚不要开太高，否则模型可能会为了回避重复而选择不常见但不合理的API调用。

我自己的经验是：先跑通最小用例，记录生成脚本的成功率基线，再逐步放开参数寻找上限。千万不要上来就追求“模型想象力”，在代码生成场景里，稳定性和可预测性才是第一位的。

3.4 部署与内核执行环节

模型只是无数环节里的一环。在工程化部署方面，最初踩过不少坑，主要集中在请求超时、资源占用和任务调度上。

• 模型服务与内核分离：模型推理和几何内核执行是两种截然不同的资源需求。模型需要GPU，内核计算主要是CPU密集任务。把它们混在一台机器上，遇到复杂零件时，往往会互相拖垮性能。尽量拆成两个独立的微服务，各自弹性伸缩。
• 异步执行与超时控制：生成一个复杂零件脚本可能不快，执行脚本更可能因为约束求解失败而长时间卡死。需要有超时控制机制，例如超过15秒就终止并返回重试，避免某个坏请求占住整个进程。
• 格式转换层：下游使用场景五花八门。做结构分析可能要STEP，做3D打印可能要STL，做平面下料可能要DXF。建议在系统内部统一输出带特征历史的原生格式，再在各个出口挂自动转换器，而不是针对不同的下游需求生成不同的模型变体。

部署时还要注意文件存储的版本管理。每次生成脚本、执行结果、用户反馈形成一条完整的数据链路，最好能完整记录下来。这些数据后续会成为模型微调和评估的重要资源，比事后再去翻日志要可靠得多。

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

4.1 模型理解正确，但脚本执行报错

最常遇到的错误类型如下：

• API名称和参数序列输出错误：相当多的错误源于模型对API函数具体签名不够熟悉。解决方法是：在提示词中加入当前支持的函数清单及其使用示例，并明确约定“只能调用清单内的API”。这本质上相当于给模型布置约束，能显著压低幻觉概率。
• 浮点精度与坐标极小偏差：例如本应在同一平面上的两个点，因为浮点精度误差产生了一个微小的缝隙，导致最终实体无法闭合。解决办法是：在生成脚本中加入坐标“取整到指定精度”的后处理规则，或在内核执行时进行容差合并预处理。
• 草图轮廓未闭合或自相交：当模型生成的轮廓有多条曲线时，容易出现线段超差或互相交叉。代码质检模块需要专门对草图进行扫描，发现不闭合就自动截断报错重试。

排查这些问题的通用办法其实也很简单：让模型看到报错信息并自我修正。执行内核报错后，把错误日志附带回给模型，让它根据日志修正脚本再跑一次。这个“执行—报错—修正”循环，往往成功率高得惊人，算是系统里的“外挂兜底”。

4.2 文本与几何不匹配，模型“听不见数字”

语言模型对数字和空间关系词的处理能力，和图像模型一样，并不完全可靠。“四个孔”被生成成“三个”、“直径6毫米”变成“直径60毫米”这类问题，我在实测里遇过不止一次。低温和结构化约束能缓解，但单靠提高模型能力手段是有限的。

一个有效对策是引入结构化字段校验器。不用等模型生成完整的自由文本脚本，而是先让模型按照JSON Schema填槽，把关键参数（数量、直径、位置、拉伸深度）分别提取出来，经过校验模确认完全符合用户指令后，再交给脚本构造器。这相当于在语义层和几何层之间加了一层强制检测，把偏差消灭在早期。

实现上并不复杂，就是多一次模型调用，让它输出一个固定结构的JSON对象，随后写一个几行代码的校验器，检查数值范围、枚举合法性、数量约束。这些逻辑加起来不超过一百行Python，带来的稳定性提升几乎立竿见影。

4.3 生成的模型可编辑性差

如果不专门约束，模型倾向于生成“一次性实体”，把各种特征操作直接合并成最终的几何结果。这样的好处是简单，坏处是让用户没法修改直径、倒角等参数。

解决这个问题需要从数据层面改变监督习惯：

• 在训练数据中标注强制保留的特征参数（比如孔径、板厚、拉伸深度）。
• 在评估指标中引入“特征可编辑率”：把生成的模型交给设计师修改一个尺寸，看是否能成功、修改过程耗时多久，作为核心指标之一。
• 输出层面限制”合并布尔运算“类操作，强制保留特征树的原始结构。

如果模型基于通用代码模型，不方便调整输出模式，还有一个变通方案：在脚本生成后跑一遍规则化的“特征树重排程序”，把最后几步布尔合并操作切分成保留参数的可编辑特征节点。这虽然不能完全替代端到端学习，但对大部分制造场景已经足够。

4.4 常见问题速查表

5. 从项目到产品：一些可复盘的思路与插件化落地

5.1 实操中的几个关键体会

走过一轮完整开发，我最大的体会是：管线成熟度远比模型单点能力重要。一次成功的生成，往往是模型能力、结构约束、报错修正、数据校验各个环节共同作用的结果。把精力全都押在提高模型参数量上，而忽视周围闭环建设，项目看起来很“潮”，但走到交付环节会处处受阻。

第二点体会是，数据合成阶段的“多样性”措辞需要认真研究。简单地生成几千个“矩形板+孔”的样本，模型几乎只会一种拓扑模式；但如果在合成时变换零件类型、孔位分布方式、加入不同的参考基准和工艺注释，哪怕数据总量没有变化，模型泛化能力的提升也会非常明显。所以，我觉得在项目初期就应该把数据生成器做成一个独立的可扩展组件，而不是草草地拼凑几个模板就完事。

第三点，别神话文本本身。在很多真实使用场景里，用户对“文本描述”需求的实际表达往往非常简略，只有诸如“做个定位块”“能装M6螺钉”这类短语。要对这类口语化、模糊化的描述做有效兜底，光靠模型还不够，要补充可维护的“常见需求库”，把高频使用场景的意图模板做结构化处理。这也让我意识到，text-to-cad并非只靠生成模型单独工作，优秀的产品体验更多来自意图理解、参数默认值策略以及合理的收敛规则。

5.2 当前值得投入的拓展方向

• 装配体生成：现在做单零件生成的比较多，而实际产品设计多数是装配体。让模型理解“零件A插进零件B的孔内并保留配合关系”，涉及的约束逻辑比单零件复杂很多，但商业价值也大得多。
• 从文本到仿真分析的联动：既然已经生成这里的参数化模型，可以直接接到有限元分析或者运动仿真环境。整套“自然语言描述—CAD几何—仿真条件—分析结果”的自动化链路一旦跑通，对设计早期方案验证的增量会很显著。
• 设计意图的逆向解析：很多企业有大量存量三维模型，但是文档缺失、特征树被压平。如果把“模型理解”反过来做，训练一个模型读取STEP文件中的特征操作并恢复出设计历程（或者配合文本描述做增量修改），也是很有价值的方向。
• 参数化草图与自由形态互补：以二维草图和参数化特征为主的常规机械零件是有明确规则的，但消费电子产品常见的自由曲面造型，规则就少得多。在做完规则模型之后，主动补上自由曲面混合建模能力，覆盖范围会更广。

最后再分享一个小技巧：系统上线后，一定要保留一个“使用日志-人工修正-定期回流”的通道。也就是把用户修改失败案例、用户对生成结果的调整操作拍成离线的矫正数据集，定期回灌到微调更新流程里。text-to-cad这种偏专业垂直的领域，通用公开数据是有限的，但你在真实使用中积累的用户行为数据，几乎是不可替代的稀缺资源。养成每天分析几十条生成失败样本的习惯，胜过盲目追求更大规模的通用训练集。

我在项目实践里反复验证过一句话：自然语言加参数化建模，始终要解决的问题是“怎样把人类模糊的意图锁定成机器可执行的精确描述”。这条路没有捷径，但每打通一个环节，后面的所有环节都会跟着顺畅起来。如果你正在或者打算进入这个方向的探索，希望这篇分享里的管线拆解和避坑经验能给你一张值得参考的施工图。