企业官网建设流程全解析

把一句大白话变成能加工的三维零件——这是我对text-to-cad最简单粗暴的概括。我第一次在某个工具的输入框里随手敲了一句“一个80mm×50mm×6mm的底板，四角各开一个Ø6通孔”，几秒钟后拿到一个STEP文件时，说实话愣了几秒。这种事以前意味着打开CAD软件、新建草图、画中心线、标尺寸、拉伸、切除、倒角，一套流程下来至少二十分钟；现在它成了一个语言问题。

text-to-cad解决的核心问题，是把设计意图直接翻译成三维实体模型：你描述形状、尺寸和特征，模型负责把它转成可编辑、可导出、可做制造检查的实体几何。它和文生图、文生视频最大的区别在于，输出不是像素也不是三角形网格，而是带工程语义的B-Rep实体，这一条让它在机械设计、3D打印、工装夹具、概念验证这些场景里都有真实落点。

这篇文章我会按原理—实操—踩坑—边界的顺序展开，不堆术语，但底层逻辑会尽量说透。它适合三类人：想评估AI CAD工具是否值得引入的工程师，正在做AI+工业软件选型的技术负责人，以及想搞明白“一句话建模”到底是怎么做到的新手。

1. 先搞清楚text-to-cad到底在解决什么问题

1.1 从一句人话到一个实体零件的完整链路

打开一个text-to-cad产品，通常会看到一个大输入框，旁边写着类似“描述一个零件，例如：带四个安装孔的L形托架”。输入之后，后台链路按我对这类工具的通用理解，大致分四步：

1. 语义解析：把自然语言拆成设计意图，包括形状类型、关键尺寸、特征位置、布尔操作。
2. 生成建模指令：模型输出一段结构化的命令序列，对应草图、拉伸、切槽、倒角、阵列这些CAD操作。
3. 几何内核执行：指令交给内核（比如OpenCascade、Parasolid这类底层几何引擎）生成真正的B-Rep实体。
4. 导出预览：把实体转成STEP、STL、OBJ等格式，浏览器里预览并让用户下载。

用大白话解释：模型不是一个把文字变图像的画师，而是一个听口音行事的老排版师傅——你告诉他版心、行距、字号，他啪嗒啪嗒排出整版。text-to-cad的模型听的不是排版参数，而是草图、拉伸、切槽、倒角这些特征操作。

这也是text-to-cad和文生3D最根本的分岔路。文生3D在一个“长得像”的网格上停下来，但CAD要求的是精确、闭合、可被下游软件识别的实体。网格是一堆三角形“面片外包”，没有边长、孔径、厚度这种工程含义；B-Rep则是带着拓扑关系和几何曲面的实体描述，能直接进CAE、CAM、3D打印切片软件。

所以把text-to-cad看作“生成模型”是不够准确的，更准确的说法是：它在生成一个建模过程，而不仅仅是一个结果。这解释了为什么很多产品会附带“特征列表”或“建模历史”，也解释了为什么它天然适合做参数化改动——改一个数字，相当于改了过程里的一步，而不是推倒重来。

1.2 为什么现在才轮到CAD被“文本化”

文生图从2022年就爆发了，text-to-cad直到最近两年才被批量讨论。这个延迟不是偶然，而是三个硬门槛叠加的结果。

第一是数据。CAD模型不像图片，网上没有海量成对的“文字描述→建模指令”。开源领域虽然有Fusion 360 Gallery、ABC这类CAD数据集，但它们覆盖的特征类型、设计风格和“文字标注”质量参差不齐。要训练一个能稳定输出建模指令的模型，光有模型文件还不够，还得有对应的特征历史，甚至得有人把特征历史线性化成命令序列——这是很重的数据工程。

第二是精度。生成图片时“看起来不错”就能糊弄过去，生成CAD时差0.5毫米就是废件。模型输出的每一个坐标、半径、深度都必须落在几何内核能执行的范围内，容错率极低。

第三是验证。模型生成一段文字很容易，但要验证这段文字能不能被内核执行、执行后是不是一个闭合实体、能不能被下游软件正常打开，需要一套完整的校验链路。没有这条链路，AI生成的永远只是“看起来像设计说明书”的废话。

现在这批工具之所以能跑起来，是因为LLM编码能力、开源几何内核、云端API这三块拼图同时成熟了。这也解释了早期text-to-cad产品为什么只能稳定处理板、块、托架、法兰这类机械件——因为能被稳定验证、能拿到特征历史数据的对象，首先就是它们。这不是这代模型的上限，而是数据与验证链路当前的真实边界。

2. 核心原理拆解：语言模型到底在生成什么

2.1 两条主流路线：写代码和写建模指令

text-to-cad的实现路线大致分两类，理解它们对选型很有帮助。

一条是“代码生成路线”。让通用LLM直接写CadQuery、OpenSCAD、FreeCAD Python这类脚本，再由脚本调用内核生成模型。这条路的好处是起步门槛低——通用大模型的代码能力已经很强，不需要专门准备CAD训练集。坏处是代码容易出错，模型可能写出坐标系越界、参数类型错误、特征链碰撞的脚本，只有真正执行时才会暴露。而且通用模型对某个CAD库的API细节理解有限，经常写出“看起来很正确但一跑就报错”的代码。

另一条是“专用建模指令路线”。用一个在CAD指令语料上微调过的模型，直接输出一套定制DSL，比如plane('XY')、circle(center=(40,25), r=3)、extrude(6, cut=True)这种命令，再由自研或封装好的几何内核解析执行。Zoo的text-to-cad、若干研究论文里的Text2CAD方案都朝这个方向走。优点是执行更可控、可以做合法性校验，坏处是要自己造数据集、自己写DSL和内核适配，工程量大得多。

我把两条路线的差异整理成一张表，方便直接对照：

两条路最后都要落在一个能产出B-Rep的几何内核上。模型只负责出“施工图”，内核才是“施工队”。这也是为什么很多text-to-cad公司最后都自己写了或封装了内核——没有内核，AI生成的文字永远只是文字。

2.2 训练数据与几何语义对齐

训练一个text-to-cad模型，核心资产是成对的“自然语言→CAD指令序列”数据。构造这类数据通常有三种手段。

一是从开源CAD数据集里抽取特征历史，把一棵包含草图、约束、布尔运算的特征树线性化成一条指令序列。Fusion 360 Gallery里大量参数化模型就是这么用的，模型的历史记录天然就是一套带顺序的建模步骤。

二是用LLM给三维模型写文本描述，也就是反过来做caption。模型文件已经有了，指令序列也有了，缺的只是“人话版描述”，这一步现在可以用通用LLM批量完成。效果看运气，质量高的描述能给出尺寸和相对位置，质量低的就只是一句“一个带孔的板”。

三是人工清洗和增强。把指令序列里不符合工程习惯的部分修正掉，补充同义表达，增加多轮对话里的增量修改样本——比如“把厚度从5mm改成8mm”这种后续指令。

你会发现一个有趣的闭环：最早的text-to-cad数据，一部分恰恰是靠通用LLM生成的。所以训练集里出现大量“一个带台阶的轴”“一个带孔的板”这类模板化对象，不是巧合——因为这些最适合自动化批量标注，也最能被几何内核稳定复现。

这里所说的“几何语义对齐”，本质上就是模型要学会把“四角各开一个Ø6通孔”映射到“在四个坐标点画圆并执行布尔差”这个操作序列。文本是稀疏的，指令是稠密的，模型要补全的信息比它看到的文字多得多。

2.3 “合法实体”不等于“有设计意图”

这是评估text-to-cad产品时最容易被忽视的一点。同样一个STEP文件，可能是参数化特征树导出的，也可能是把空壳倒出来的“死”实体。

参数化模型里有历史记录，有命名参数，后续可以改一个孔径，整个特征树自动重算；静态B-Rep则只是一块实心的几何外壳，想改尺寸只能整个重新生成。text-to-cad产品里两类都存在，有的产品甚至同一批结果里既有参数化的也有静态的，取决于模型当时走了哪条推断路径。

我在实际评估工具时会第一时间确认一件事：生成结果能不能在本地CAD里编辑特征，还是只能当作一个固定模型引用。这个差距直接影响工作流——如果只是想做概念预览，静态B-Rep完全够用；如果要接进产品研发，参数化能力就是硬指标，否则一个小改动会变成一次新的AI生成循环。

3. 实操：五分钟跑通一个零件生成

3.1 工具选型：按场景选入口

text-to-cad的入口现在大致有三类，我把各自的适用情况列一下。

第一类是在线Playground，比如Zoo的text-to-cad页面。适合快速验证想法、演示给同事看，不需要安装任何环境，输入一段话就能下载文件。缺点是交互和批处理能力有限，不适合串进正式设计流程。

第二类是云端API，适合产品集成。企业内部工具或自动化流水线可以把文本生成CAD做成一个后端接口，传入设计参数、返回STEP文件。这种玩法对并发、成本、失败重试都要做工程兜底。

第三类是本地开源方案，用CadQuery或OpenSCAD配合通用LLM自己搭一条最小链路。适合开发者自己实验，也适合学习原理。下面3.3节给的就是这个路子的完整示例。

这三类不是互相替代的关系。我个人的建议是：学习原理用本地方案，验证效果用Playground，真正要落地再考虑API或内部集成。

3.2 提示词写法：让模型听懂工程“黑话”

text-to-cad的提示词和普通对话完全不是一回事。普通对话要的是语义丰富、上下文连贯；text-to-cad要的是参数明确、特征无歧义。我试过很多种写法，真正能一次生成成功的提示词有几个共同点：有数字、有单位、有明确的操作词。

先看两个反例。写“做一个结实的支架”，模型只能猜；写“支架上挖几个孔”，它不知道是通孔还是盲孔、孔心在哪、挖多深。正确姿势应该是这样。

还有一个很实用的技巧：先出主体，再叠加特征。别试图一口气描述完整个零件，优先让模型先生成一个干净的毛坯，然后用多轮对话逐步加孔、加槽、加倒角。这样即使中间某个特征失败，你也能定位到是哪一个环节出了问题，而不是整段推倒。

描述相对位置时一定要给参照物——“孔心距边缘8mm”比“靠近角落”好用得多。对称特征直接说阵列：“四个角各开一个Ø6通孔，呈2×2阵列”，模型对这类指令的处理成功率远高于列出一长串绝对坐标。

3.3 本地跑一个最小验证：CadQuery加通用LLM

用一个文本到STEP的最小链路来理解原理，是我反复向新手推荐的做法：让一个通用LLM去写CadQuery脚本，由CadQuery调用OpenCascade内核生成STEP。下面是我实际跑过的一个例子。

提示词大致是：“用CadQuery生成一个80mm×50mm×6mm的底板，四条竖直棱边倒R2圆角，顶面距离每条边8mm的位置放四个Ø6通孔，呈长方形排列。”

一个可用的CadQuery脚本长这样：

import cadquery as cq result = ( cq.Workplane("XY") .box(80, 50, 6) # 底板主体 .edges("|Z") # 选中所有竖直棱边 .fillet(2) # 统一倒R2圆角 .faces(">Z") # 选中顶面 .workplane() # 在顶面建立工作平面 .rect(60, 30, forConstruction=True) # 辅助矩形，用来定位孔 .vertices() # 取矩形四个角点 .circle(3) # 每个角点放一个Ø6圆 .cutBlind(-6) # 向下切穿6mm ) result.export("bracket.step")

把这个脚本丢进任何一个带CadQuery的Python环境，运行完就是一个可用的STEP文件。这个实验的核心价值不是得到零件，而是让你直观看到text-to-cad背后的本质：模型输出的是“建模步骤”，而不是“最终形状”。你可以试着改box的第一个参数，从80改成100，整个零件会跟着变——这就是参数化的意义。

我跑这个过程踩过的坑集中在两处。一是模型的CadQuery API版本可能和你本地的不同，生成代码里经常混入旧版函数名；二是.fillet()这类操作很挑几何链，棱边选错或半径过大都会中断。简单做法是让模型生成时明确指定“按CadQuery 2.x语法”，并且生成后先在cq-editor里预览，再导出STEP。

3.4 拿到文件之后：验证、后处理、导出

生成的STEP不是终点。我的固定动作是三件事：核对尺寸、检查特征、按用途导出。

核对尺寸用FreeCAD的Measure或Fusion的Inspect都行，关键是要确认关键孔径、壁厚、孔距和提示词一致。检查特征则要看模型能不能在你本地软件里编辑参数——如果打开之后只有一个静态实体，说明这条路走的是“死”模型路线，后续修改需要回到text-to-cad里重新生成。

导出格式取决于下游用途。3D打印用STL，但要注意网格密度；机加或仿真用STEP；如果只是想拿给同事看一眼，直接在线预览图就够。另外，云端内核和本地内核版本不同，偶尔会有“云端生成成功、本地打开报错”的情况。遇到这个，先用工具自带的在线预览确认几何没问题，再换IGES等中间格式试试，通常能绕过内核版本兼容问题。

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

4.1 尺寸差得离谱：先查单位

“尺寸巨大/微小”是我见过出现频率最高的问题。排查逻辑很简单：先确认单位。text-to-cad产品默认大多数是毫米，但很多模型训练语料里混了英寸，或者你的描述里混用了in和mm。

一个可靠的检查方法是看比例：如果结果比预期大25.4倍或小25.4倍，基本就是英寸和毫米的换算问题。处理方式是在提示词里显式写上“所有尺寸单位均为mm”，并在关键尺寸后面重复一遍单位，比如“板厚6mm，孔径Ø6mm，单位mm”。

还有一种尺寸问题是参照物错位。你说“孔心距边缘8mm”，模型可能理解为距每条边的垂直投影投影线，而不是实际三维距离。这种时候把孔位描述成“以底板左下角为原点，孔心坐标(8,8)、(72,8)、(8,42)、(72,42)”这种绝对坐标，更可靠。

4.2 孔没打通、倒角没生成：关键词没给到位

“一个孔”在CAD里天然有两种状态：通孔和盲孔。如果提示词没有明确“贯穿”，很多模型会倾向生成盲孔或沉孔。我在实际测试里遇到过不止一次“看着像孔、剖面一看是盲孔”的情况。

处理办法是把布尔语义说死：要通孔就写“through-hole，贯穿整个板厚”；要盲孔就写“盲孔，深度8mm”；要沉孔就写“沉头孔，沉头直径12mm、深度2mm”。不要省这几个字，省掉的往往就是返工的半天。

倒角缺失则是另一类问题。模型不是不想做，而是倒角对几何拓扑很敏感——如果前一步的拉伸和切除让某些棱边变成了多条断线，统一倒角就会失败。我的习惯是：主体生成完了先不急着倒角，先确认布尔操作正确，再单独发一轮“给所有竖直棱边加R2圆角”的指令。成功率会高很多。

4.3 文件打不开或显示异常：先分清是哪一层的问题

生成的STEP拿到本地打不开，原因通常不在模型，而在导出链路。云端内核导出的STEP版本、单位制、曲面表示跟你本地软件不兼容都有可能。

排查顺序是：先在浏览器里用工具自带的预览器看文件是否正常；再用FreeCAD这类免费软件打开；最后才考虑是不是要换格式。我遇到过一次云端生成的STEP在专业软件里报“无法识别实体”，但IGES版本能正常打开——这不是几何错了，是STEP写出的拓扑结构不被当前内核接受。

下面是一张我整理的速查表，浓缩了上面所有经验：

这些排查技巧不复杂，但都属于“常规文档里不会写”的部分。我建议你在自己的评估阶段就把这几条记下来，能省掉相当多调试时间。

5. 现阶段的能力边界与我实际使用的方式

5.1 目前真正能落地的场景

我给项目做技术选型时，不会一上来就问“它能不能替代工程师”，而是问“它能替哪个环节”。现阶段text-to-cad稳定可靠的使用场景，我总结为四个。

第一是概念设计早期。需要快速给结构方案“搭个样子”的时候，用自然语言生成几个候选模型，远比在CAD里从零画快。第二是标准件和简单结构件，比如支架、底板、法兰、罩壳这类以拉伸、旋转、阵列为主的特征，text-to-cad已经处理得很好。第三是3D打印验证，生成后直接转STL，配合切片软件做快速原型，省去人工建模环节。第四是非CAD背景人员的沟通工具——产品经理、工艺人员可以把想法用一句话表达成可视化模型，再交工程师细化。

这些场景的共同点是：零件结构相对简单、功能语义清晰、对“完美参数历史”的容忍度高。

5.2 我踩过之后不再指望它做的事

另一方面，有几类工作我现在基本不会用text-to-cad来碰。一是复杂自由曲面，比如汽车A面、消费电子外壳那种需要大量曲率连续控制的形态，这类模型的训练数据本身就稀缺，生成结果很难达到工程可用度。二是大型装配与约束网络，多零件配合、运动副、干涉检查这些逻辑不是一句话能说清的，超出当前技术的能力半径。三是精确钣金展开，折弯系数、展开扣除、回弹补偿这些制造知识藏在工艺参数里，不是几何模型能凭空生成的。四是GD&T制造语义，形位公差、表面粗糙度、基准标注这些信息要附着在几何特征上，目前多数输出还只是“裸几何”。

说到底，问题不在“AI能力上限”，而在于“数据集和验证手段还没到位”。我不会因为这些边界就否定它的价值，但我会在项目里把期望值摆正：它能加速设计表达，不能替代工程判断。

最后分享一个我现在的使用习惯。真正做项目时，我不会把text-to-cad当建模工具，而是当“草稿工具加沟通工具”。我会先花几十秒生成几个候选结构，挑一个顺眼的导入Fusion，在原有基础上继续加约束、改参数。这个习惯的直接体会是：AI不是替我做设计，而是替我把CAD表层的体力活剥掉，让我把注意力放到“这零件到底该怎么受力、怎么装配、怎么出模”这些真正值钱的问题上。如果你也打算试水text-to-cad，我建议第一件事不是研究模型细节，而是拿一个自己做过的小零件，从“复现它”开始——踩过这一次坑，你对这个工具的边界理解会比看十篇评测都管用。