企业官网建设流程全解析

最近被问得最多的一个词就是 text-to-cad，也就是用一句自然语言直接生成三维模型，听起来像是“一句话建模”的魔法时刻。实测下来，这个方向确实已经从论文里的概念变成了可以跑通的东西，但离“输入一句人话就直接出工程可用模型”还有相当一段距离。我前阵子刚好集中调研并复现了几条主流技术路线，从大模型生成脚本，到扩散模型出体素，再到直接预测特征树，都摸了一遍，过程中踩了不少坑，也理清了一些关键判断。这篇就按我自己的实操顺序，把技术原理、方案选型、完整流水线和避坑经验一次性讲透。

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

1.1 从一句话到三维模型的本质：不是翻译，是约束求解

很多人第一次接触 text-to-cad 时会有个错觉：这不就是把自然语言“翻译”成三维模型吗？语言模型负责理解句子，然后后端再把它变成几何体。但真正做过一次就会发现，问题远没有“翻译”这么简单。

二维到三维之间隔着一条巨大的鸿沟：语言是线性的、离散的符号序列，而三维模型是连续几何、拓扑关系、尺寸约束和特征历史的结构化综合体。同一个“盒子”，在自然语言里可能是“一个方形盒子”，但在 CAD 里必须明确：长宽高是多少、圆角半径多大、壁厚多少、孔在哪个面上、孔的直径公差是多少。换句话说，text-to-cad 的核心不是理解语义，而是把模糊的语义“映射”成一组完备且自洽的几何约束。这个映射过程更像是在做约束求解，而不是做翻译。

我自己的一个理解是：它可以类比成“你给装修师傅口头描述一个柜子，师傅一定会追问你柜子多高、多宽、用什么板材、要不要抽屉”。如果这些约束不确定，师傅没法开工。text-to-cad 也一样，模型要做的不仅是听清楚你在说什么，更重要的是在信息不足时做出合理推测，并且保证推测出来的几何是能真实加工、能编辑的实体模型，而不是一个看起来像模型但实际上没法用的壳。

1.2 传统 CAD 建模的痛点：为什么“说人话建模型”是个真需求

在说 text-to-cad 的价值之前，得先聊聊传统建模有多痛，才会明白这个方向为什么近几年突然被推到风口上。

传统 CAD 建模，不管是商业平台还是开源工具，本质都是一套严谨的参数化特征系统。用户要建模一个零件，脑子里得先规划清楚特征树：先画哪个草图、拉伸多少、在哪开孔、怎么倒角。每一个操作背后其实都是几何内核里的布尔运算和约束求解。对于老工程师来说这没什么，但对非专业人士来说，学习成本极高。我见过不少做结构设计的朋友，为了给散热器加几个螺丝孔，得先学半小时工具栏怎么用。

而更深层的痛点在于：设计意图的表达是被限制在软件交互框架里的。你想做一个“类似 A 但稍微大一点、孔位分布不同的版本”，在传统软件里你得找到特征树、修改草图和尺寸，每一步都可能引发约束连锁报错。text-to-cad 想解决的，正是把“设计意图”——注意，是意图，不是最终几何——直接用自然语言表达出来，让系统去处理后续的参数化和特征重建。这对概念设计、方案比选、快速原型验证这几个场景尤其有价值：你能在几分钟内把脑海里的想法变成可量化的三维模型，而不是花一晚上画草图。

另外一个被很多人忽视的真实需求是：制造业里有大量老旧零件需要“逆向建模”成参数化模型。老工程师看一眼实物，嘴里描述几句，新人再去 CAD 里重建。如果 text-to-cad 足够成熟，这一段“口头描述转模型”的环节就能被大幅压缩。所以它不只是一个 AI demo 方向，背后是有明确工业场景支撑的。

1.3 为什么是现在才火起来：语言模型、几何数据与算力三件事同时到齐

其实“用文字生成模型”的想象很早就有了。早年的自然语言建模系统可以追溯到上世纪八九十年代的语义建模研究，但当时受限于两个硬条件：自然语言理解能力太弱，三维几何数据的获取和标注成本太高。没有高质量的数据集，机器学习模型根本没法学到“语言到形状”之间的复杂映射。

这几年突然井喷，是因为三件事同时到位了。第一，大语言模型在指令理解、常识推理和代码生成上的能力大幅提升，这让“文本转参数化建模脚本”成为一条非常自然的技术路线。第二，开源社区积累了一批文本-形状对齐的数据集和千万级三维模型库，配合自动化的脚本生成与验证管线，标注成本显著下降。第三，算力尤其是 GPU 加速的几何处理框架越来越成熟，让大规模训练和实时推理变得可行。

这三点是相互促进的：LLM 提供了“文本理解”这个缺失已久的入口，数据集解决了“学什么”的问题，算力让“学得动”成为可能。所以 text-to-cad 的火不是凭空来的，它踩准了技术周期的交叉点。

2. 三条技术路线深度解析与选型决策

2.1 路线一：大模型直接生成 CAD 脚本，最务实、最容易落地

第一条路线是让大模型写代码，代码再驱动脚本化 CAD 内核建模。典型工具链就是大模型 + CadQuery、OpenSCAD 或 FreeCAD 的 Python API。用户输入“一个长 100 宽 60 高 30 的盒子，顶部倒圆角 10，中心有一个通孔”，模型输出一段 Python 脚本，脚本执行后得到实体模型。

这条路线的优势非常明显：它输出的不是一次性网格，而是带特征历史的参数化模型。这意味着用户可以回去改那个“倒角半径 10”，改完模型自动更新。工程上最看重的“可编辑性”天然满足。另外，脚本作为一种中间表示，是文本形式，人类可以读、可以调试、可以版本管理，这对接入现有 PLM/PDM 系统非常友好。

缺点同样明显。大模型生成的脚本经常有语法错误或语义偏差，直接执行会产生一堆废模型；而且它依赖一个相当“脆”的反馈机制：脚本报错，怎么改？得把错误信息再喂回模型。调试链条长，稳定性难保证。我实际跑下来，简单的长方体、圆柱、孔特征成功率在七八成以上，一旦描述带不对称特征、多实体联动、复杂曲面，失败率会显著上升。如果要在这条路线上做出可靠产品，必须要有一个“生成-执行-报错反馈-修正”的闭环，这对后端的执行沙箱和错误归因能力要求很高。

2.2 路线二：扩散模型生成隐式几何，视觉效果好但工程化困难

第二条路线是借用图像生成领域成熟的扩散模型思路，把三维形状当作体素场或隐式距离场来生成。模型输入文本描述，输出一个 128 或 256 分辨率的体素网格，再经过网格抽取（比如 Marching Cubes）变成表面模型。

这条路线生成的几何形态非常丰富，尤其适合自由曲面、有机形态这类传统参数化建模很难表达的造型。比如“一个像海豚一样弯曲的支架”，参数化特征几乎无法描述，但扩散模型可以生成一个合理形态。

但问题也很致命：生成的是网格（mesh）或隐式场，不是 B-rep 边界表示，更不是参数化特征。也就是说，用扩散模型出来的模型，没法直接在 CAD 软件里改尺寸、加倒角、做布尔运算，必须重新进行曲面拟合和特征重构。这一步目前非常依赖人工，甚至比从零建模更费劲。另外，体素分辨率限制会让细薄的壁、小孔、倒角等制造相关细节丢失，生成的网格要么过于平滑，要么出现空洞和自相交，距离“能加工”的标准还差得远。目前这条路线更适合做视觉概念、设计灵感探索和前期产品造型评估，不适合直接进工程流程。

2.3 路线三：直接预测参数化特征序列，最难的也是最理想的

第三条路线是绕过脚本语言，直接让模型输出一整套参数化特征序列，也就是预测一个 CSG（构造实体几何）树或者特征操作序列。就像教一个 AI 学会“建模师的操作步骤表”：第一步拉伸矩形草图，第二步切除圆柱，第三步倒圆角，每一步都带参数。

这条路线的理想状态是模型自动完成从语义到特征树的映射，不需要中间代码，也不会被语法错误卡住。推理时输出的就是一套结构化的特征描述，可以完美转换成 CAD 内核里的特征历史。理论上它的上限最高，因为它的输出本身就是工程意义上的参数化模型。

但它也是目前最不成熟的路线。预测高维度结构化的特征序列是一个非常困难的序列决策问题，搜索空间极大。描述稍有变化，最优特征树就可能整个不同。训练数据方面，需要大量带标注特征历史的 CAD 模型作为监督信号，这种数据的获取成本远高于文本-网格对。所以目前这条路线大多还停留在论文和特定数据集上的评测阶段，离通用化产品化差距最大。不过我自己的判断是，未来成熟的 text-to-cad 最终形态大概率是这个方向，因为它的输出形式和工程世界最贴合。

2.4 三条路线怎么选：我给出的决策建议

如果你也想做个 text-to-cad 项目，选哪条路线得先想清楚使用场景。

如果目标是快速做出一个能用的工具，解决工程场景里的重复建模，选路线一（脚本生成）最划算。理由很简单：现有大模型的代码能力已经够用，CadQuery 这类库也成熟，中低复杂度的零件能跑通。把精力放在提示工程、模板库和后处理校验上，见效最快。

如果目标是做设计可视化、展览展示、概念造型探索，可以选路线二（扩散模型）。这条路线的视觉效果最容易打动非专业用户，也适合做交互式创意工具，但别指望它直接导出能在专业建模软件里流畅编辑的模型。

如果目标是做长期技术壁垒、切真正的高端制造场景，建议密切关注路线三，并且尽早积累带特征历史标注的数据。前两条路线解决的是“从无到有”，第三条路线解决的是“从有到正经可编辑”。

我个人的选择是：主力押注路线一，用模板库把成功率拉高；同时保留路线二做造型探索的入口；路线三先追踪，不急着投入。这个决策组合在公司资源有限的情况下最稳健。

3. 实操拆解：用 CadQuery 搭一套可复现的 text-to-cad 流水线

3.1 整体架构与模块划分

这一节我把自己的实操过程完整梳理一遍。整体架构大致分为四个模块：文本解析、参数提取、脚本生成、执行校验。很多人一上来就指望大模型直接输出成品，但其实把文本解析和参数提取独立出来，成功率会提高非常多。

核心思路是：不要指望大模型从零“创作”建模逻辑，而是让它做选择。先定义一套模板库，每种模板对应一类几何形态（盒子、圆柱体、带孔板、法兰等），每个模板都有明确的参数槽位。大模型的任务是从输入文本中抽取参数并选中匹配的模板，而不是自由发挥写代码。这相当于把一道开放式作文题变成了填空题，准确率自然高。

下面是一个模板示例的 JSON schema 设计：

{ "template": "box_with_hole", "params": { "length": {"value": 100, "unit": "mm"}, "width": {"value": 60, "unit": "mm"}, "height": {"value": 30, "unit": "mm"}, "hole_diameter": {"value": 16, "unit": "mm"}, "hole_position": {"x": 0, "y": 0}, "fillet_radius": {"value": 10, "unit": "mm"} } }

文本解析阶段，我用的是一个纯 LLM 的抽取链路：把模板 schema 放进系统提示词里，要求模型只输出 JSON，不输出任何解释。这样做有两个好处：一是后续可以直接反序列化进 Python，二是把模型的输出约束在结构化的空间里，降低自由文本带来的不确定性。

3.2 文本解析与参数提取：让模型做填空而不是写作文

文本解析这一步是整个流水线里最容易被低估的环节。我测试过直接让模型输出 CadQuery 脚本和让模型输出结构化参数两种方式，前者的端到端成功率大概在 60%，后者配合模板库能到 85% 以上。

具体做法是：在系统提示词里给出所有可用模板的名称、适用场景和参数列表，然后让模型根据用户描述完成 JSON 抽取。有几个细节值得注意：

必须要求模型输出默认值。用户说“一个盒子”，没说尺寸，模型必须填默认值，否则后续建模会因缺少参数而崩溃。默认值的设计要贴近真实使用习惯，比如长方体默认 100x60x30，壁厚默认 3，孔直径默认 8。这些默认值最好由有 CAD 经验的人来定，而不是让模型瞎猜。

另一个细节是单位的处理。用户可能说“做一个两英寸的法兰”，模型需要把英寸转换成毫米。为了保证转换正确，我明确要求模型内部先转成毫米再填入 JSON，同时保留原始描述里的单位痕迹以便复查。实测中，这种“显式转换”的指令能让单位错误率下降很多。

还有一个细节是对“数量语义”的识别。比如“四个角上各打一个孔”，这句话里有复数语义和位置语义，模型很容易漏掉“四个”或者只生成一个孔。我的处理方式是在 schema 里增加一个repetition字段，把这类信息单独抽取出来，生成阶段再用循环处理，而不是让建模逻辑里偷偷塞进多个孔特征。

3.3 模板库的设计：参数化建模的核心资产

模板库是这个流水线里真正的核心资产，它的质量直接决定系统能覆盖的几何形态上限。每个模板本质上是一段封装好的 CadQuery 函数，接收参数字典，返回一个实体模型。

以box_with_hole模板为例，核心代码长这样：

import cadquery as cq def build_box_with_hole(params): length = params["length"]["value"] width = params["width"]["value"] height = params["height"]["value"] hole_d = params["hole_diameter"]["value"] pos_x = params["hole_position"]["x"] pos_y = params["hole_position"]["y"] fillet_r = params["fillet_radius"]["value"] result = ( cq.Workplane("XY") .box(length, width, height) .edges("|Z") .fillet(fillet_r) .faces(">Z") .workplane() .hole(hole_d) ) # 让孔的位置可调 if abs(pos_x) > 0.001 or abs(pos_y) > 0.001: # 重新定位孔：先画孔中心点再挖槽 result = build_with_offset_hole(result, length, width, height, pos_x, pos_y, hole_d) return result

模板设计有几个重要原则：参数要少而精，不要追求一个模板覆盖所有情况；特征顺序要稳定，先主体后细节；每个模板都要有对应的“失败回退策略”，比如某个参数组合导致布尔运算失败，就自动用简化几何替代，保证系统不会直接崩掉。

从工程角度看，模板库不只是代码，更是一套领域知识库。每个模板背后其实对应一种加工特征习惯，比如“法兰盘”模板包含的同心孔、沉头孔特征，都是机械设计里高频出现的。你把越多的领域特征固化进模板，大模型需要“发挥”的空间就越小，系统就越稳。这个思路也适合小团队起步：先覆盖你最熟悉的那 20 类零件，不要一上来就想做全品类通用建模。

3.4 脚本生成、执行与校验：端到端的闭环流程

模板参数抽取完成后，流水线会进入脚本生成与执行阶段。这里的脚本不是让大模型写的，而是由模板代码拼接出来的。我维护了一个模板注册表，键是模板名，值是一个生成函数。根据解析阶段选中的模板名，系统动态调用对应函数并传入参数 JSON。

执行环境我建议使用沙箱。模型代码来自外部输入，虽然模板代码是自研的，但生成的参数值可能包含异常数据（比如负数尺寸、超大圆角），所以构造一个受限的执行环境很有必要。用 Docker 容器跑 CadQuery 执行，限制 CPU 配额和内存上限，超时就杀死进程，这是最稳妥的做法。

执行完成后要自动化校验。我设了三个指标：实体是否非空、体积是否为正、是否有自相交面。CadQuery 的val().isValid()方法可以检查实体有效性；体积可以通过result.val().Volume()获取。低于预设阈值就直接标记为失败，进入重试或降级流程。降级流程就是走回退策略：把圆角去掉、把孔位归零，重新生成，确保至少给用户一个“近似可用”的模型，而不是干等报错。

最后是格式导出。CadQuery 支持直接导出 STEP 和 STL：

cq.exporters.export(result, "output.step")

STEP 是工程领域最通用的中性格式，几乎所有主流 CAD 软件都能打开并保留实体信息；STL 则用于 3D 打印和可视化预览。两个文件都导出是个好习惯，能覆盖更多下游场景。

3.5 模型校验与格式导出的经验补充

在实际跑通之后，我补充了 PNG 渲染预览这一步。CadQuery 本身不带渲染功能，但可以通过导出 STEP 之后用配套的可视化模块生成一张三视图缩略图。这样用户不用打开 CAD 软件就能快速判断生成结果是否合理。

这里有个值得注意的坑：STEP 文件本身不记录单位信息，如果生成端用毫米，消费端如果是英寸，尺寸会差 25.4 倍。所以导出的时候一定要在文件名或者辅助的元数据 JSON 里把单位标注清楚。我在实际对接过程中遇到过因为单位不匹配导致整套夹具设计返工的情况，这种问题在管线里非常隐蔽，因为打开软件看视觉形态好像差不多，一旦用测量工具一比，全都对不上。

另外，对生成的模型我建议做一个参数合法性校验，比如所有尺寸必须大于 0、孔径要小于对应面的宽度、圆角半径不能超过边长的一半。这些规则看起来是常识，但大模型抽取参数时不会自动遵守，所以必须用代码硬校验。违反规则时，要么修正参数（比如把负值改成默认值），要么直接拒绝生成并给出修改提示，绝不能带着非法参数进入几何内核，否则内核会吐出一堆难以排查的诡异错误。

4. 常见问题与排查实录：我在实操中踩过的坑

4.1 文本歧义：同一句话，十种理解

最困扰我的问题就是文本歧义。“在一个圆角矩形的底板上放四个柱子”，这句话我让不同模型解析，得到过四种不同结果：四个柱子分别是圆柱还是方柱？底板的圆角半径多大？柱子均匀排列还是靠边放？模型需要脑补大量判断。

我的解决方案是“交互式澄清”，把关键歧义点做成选择题，让用户手动确认一次。比如“四个柱子等距排列还是按给定坐标放置？”这个交互只需要用户点一下，但能极大地减少后续返工。更好的做法是在管线里内置“置信度”概念：模型对抽取的参数没有把握时，不要硬填，而是标记为“待确认”，在生成前弹一个快速的参数校验面板。这个设计方案让端到端体验提升了不少。

也可以从提示词层面规避：在系统提示词里明确要求“如果描述中有数字，必须使用；如果没有数字，必须使用模板默认值”，同时把模板默认值打印出来让用户提前知道。这样用户得到的结果至少是可预期的。

4.2 约束冲突：尺寸与几何打架

模板参数之间是有隐含约束关系的。比如“长方体 100x60x30，顶面圆角 25”，这个圆角半径超过了侧面短边的一半，几何内核就会报错，因为多个圆角相交后拓扑失效。这类问题一旦出现，生成的实体往往是空的或者自相交的，校验阶段会直接标记失败。

排查这类问题的常用手段是逐步简化：先关掉所有圆角，生成基础形状；再逐个加上特征，定位是哪个参数出了问题。我写了一个特征二分调试脚本，自动把模板特征数组切开生成多组候选，快速定位问题特征。这个脚本虽然简单，但帮我节省了大量手动排查的时间。

更治本的办法是给模板加了参数校验器，在进入 CadQuery 之前做几何合理性判断。比如圆角半径必须小于 min(长,宽)/2，孔直径必须小于所在面的最小边长。校验规则一开始只写了 5 条，后来随着测试集扩大加到了 30 多条，几乎每个模板都有一组专属约束。这也侧面说明了模板库真正落地需要长期的领域积累。

4.3 执行环境的不确定性：依赖与版本

CadQuery 本身依赖一个几何内核库，这个内核库的版本差异会导致同一个脚本在不同环境下生成不同的结果。最典型的是布尔运算的容差处理：在老版本内核上能成功的“相交面切除”，在新版本上可能因为容差偏严而失败。这种问题最隐蔽的地方在于，它不会显式报错，而是静默生成一个不正确的结果。

处理办法是锁版本加容器化。我在 Dockerfile 里把内核库版本和 CadQuery 版本都固定下来，并在 CI 里跑每日回归测试，确保基础模板库的生成结果不会因为环境变化漂移。这套实践不仅适用于 text-to-cad，任何依赖几何内核的自动化建模系统都应该这么做。

还遇到过一个小坑：CadQuery 的多线程执行并不完全安全，几何内核的并发写保护不算完善。所以我用进程池替代线程池，每个进程独立加载 CadQuery，避免共享内核状态的竞争。虽然多开进程会吃更多内存，但稳定性是第一位。

4.4 质量评估：怎么衡量“生成对了”

要评估 text-to-cad 的效果，不能只看“能不能生成一个模型”。我在测试集上标注了三档结果：完全符合、部分符合、完全不符合。完全符合要求是几何形态、关键尺寸、特征数量全部正确；部分符合是形态大体对但尺寸偏差明显；完全不符合就是出现废模型。

光用人的主观判断不够，还需要客观量化。我从三个维度算分：几何相似度，通过采样点云算 Chamfer Distance；参数正确率，对比生成参数和标注参数在关键尺寸上的误差；特征完整性，检查应有的孔、倒角、槽等特征是否存在。这三个维度合起来能比较好地反映一个生成系统的真实水平。

一个值得留意的现象是：通用评估指标和工程可用性之间的相关性其实不高。有些系统在指标上拿高分，Chamfer Distance 很好看，但生成的模型带有非常薄的碎面，根本没法加工。所以我后来增加了“加工可行性”的人工抽查项，找几位机械设计师盲评，分数的说服力比任何自动指标都强。这也提醒我，不要被指标迷惑，最终要以人的工程判断为锚。

4.5 避坑速查表

我整理了一张速查表，基本覆盖了复现这个流水线最常踩的坑：

这张表是我后期维护最频繁的文档之一，每次遇到新问题都会往里补充。做这类系统，经验沉淀比新颖算法更重要。

5. 从 demo 到可用系统：进阶方向与个人经验

5.1 几个比“直接生成”更现实的应用方向

在把直接生成的 demo 跑到一定成功率后，我意识到一个现实：与其执着于“一句话生成最终零件”，不如把 text-to-cad 能力拆开，嵌入更多实际工作流里。

第一个方向是“参数化变体生成”。给定一个基础模型的模板，用户用自然语言描述想改哪些尺寸或者加哪些特征，系统基于模板做参数修改。比如“把底板加长 20，孔距改成 50，再加四个安装脚”。这种做法把问题从一个“全量生成”退化成“增量编辑”，难度大大降低，而工程需求恰恰大量集中在这个场景。

第二个方向是“检索式模板匹配”。输入文本后，先在已有的模型库或模板库里检索最接近的候选，然后把文本中提到的差异参数应用到候选模型上。这个思路很接近“以文搜模型再自动调整”，比从零生成的成功率和可控性都强得多。

第三个方向是“草图转模型配合”。用户先用自然语言描述整体意图，再用简易草图标注比例和位置，系统结合文字和草图信息完成建模。视觉信息极大地消除了文本歧义，这个融合方案我认为是更接近产品化的路径。

这些方向的核心共同点是：降低生成难度，增加人为控制，把 AI 放在辅助位置而不是完全取代设计师。当前技术水平下，这才是 text-to-cad 真正能创造价值的姿势。

5.2 我对这套技术的一个核心体会

实际做下来，我对 text-to-cad 整体判断是乐观的，但对实现路径有了更现实的认识。它本质上不是一个纯语言问题，也不是纯几何问题，而是一个“如何把模糊需求变成严谨约束”的工程系统问题。指望一个大模型单枪匹马搞定所有环节，目前不现实。

真正让系统落地靠谱的，是我前面反复提到的模板库、校验器、沙箱和交互确认闭环。这些工程组件看起来不性感，但正是它们把成功率从 60% 拉到 85% 以上。如果你也想复现类似的系统，我建议先把模板库做小做扎实，再逐步扩充覆盖范围。

最后分享一个我一直在用的判断标准：任何 text-to-cad 输出，必须能导出 STEP 并被人修改参数后重新生成，才算“真正生成了一个 CAD 模型”。如果只是给了一堆三角形网格，那它更接近“三维图片”而不是 CAD。抓住这个核心标准，不管技术路线怎么演进，你的方向都不会跑偏。