企业官网建设流程全解析

从“把文字变成图”到“把文字变成能加工的真零件”，这两件事听起来只差一步，实际差了整整一个时代。前段时间我花了不少时间在“text-to-cad”这条线上折腾，也就是让大语言模型根据一段自然语言描述，直接生成可用于工程制造的三维CAD模型。今天这篇就把我踩过的坑、拆过的原理、试出来的可行路径，按一个能落地的顺序整理给你。

先说清楚它解决什么问题：CAD建模是个熟练工种，资深工程师用主流建模软件从零拉一个中等复杂度的零件，草图、拉伸、打孔、倒角一路做下来，半小时到一小时很正常。如果需求方给的描述还含糊，改两轮模型就半天没了。text-to-cad 想干的事，是把“输入自然语言描述”到“输出参数化CAD模型”之间的路尽量自动化，让设计早期阶段的方案探索、非工程人员的概念表达、标准件库的批量生成，都能从“人肉操作”变成“半自动生成”。

这件事现在处于什么阶段呢？非常早期，但已经有看得见的眉目。当前主流的方案不是让模型直接输出一个网格文件或者体素块，而是让模型输出一套“建模操作序列”，让CAD内核按这个序列一步步把模型重建出来。换句话说，它生成的不是一张“看起来像零件的图”，而是一段“能重新长出这个零件的DNA”。这听起来很绕，但恰恰是它区别于文生图、文生视频的关键。下文我按思路拆解、核心细节、实操流程、踩坑实录和落地场景五个部分展开，尽量让它在你的知识体系里从“一个热闹概念”变成“一套可拆解的技术方案”。

1. text-to-cad 的本质思路：从“画图”到“写建模脚本”

1.1 为什么不能直接输出网格文件

大多数人第一次听到 text-to-cad，第一反应是“这不就是3D版的文生图嘛”。这个类比大方向不错，但工程制造领域对“模型”的要求和图像完全是两码事。

文生图模型输出的是一张像素矩阵，图“像不像”取决于视觉观感，哪怕像素边缘糊一点、局部结构错乱一点，人眼也能自动脑补修正。但工程零件不是给人“看”的，是要拿去装配、仿真、加工的。一个靠视觉像模像样的网格模型，拿进CAD软件里根本没法编辑：你不能选中它的某个面改厚度，不能让它的某个孔从直径4改成直径6，更别说生成工程图或者走CAM编程。网格文件（比如STL）由一堆三角面片拼成，只有几何外壳，没有拓扑关系、没有特征树、没有参数约束，本质上是一块“数字黏土”。

所以在 text-to-cad 这条线上，早期尝试直接生成体素或点云的工作很快就被边缘化了。大家很快达成了一个共识：真正有用的输出格式，要么是参数化的特征建模历史，要么是B-rep边界表达模型——只有这样，生成的模型才可能被现有CAD生态直接消费。

1.2 把建模过程当成“程序生成”来做

现在主流的技术思路，是用“next-token prediction”的方式，让语言模型学会了“怎么写建模指令”。

你打开一款主流的参数化CAD软件，从零建一个简单的法兰盘，操作序列大概是这样的：新建草图、选择绘图平面、画出几个同心圆、标注半径尺寸、退出草图、选择拉伸命令、输入深度、做倒角……整个操作历史，Ansys/某主流CAD内核会把它记录成一个个带有参数的特征节点。如果把这个过程抽象成一个“由特征词、几何参数、顺序标记组成的序列”，你会发现——这不就是一种结构化的“程序语言”吗？

大语言模型最擅长的恰恰是处理这类结构化的符号序列。于是思路就清晰了：与其让模型直接算几何坐标，不如让模型生成一段“建模脚本”，脚本里的每一行对应CAD软件里的一个具体操作。模型只需要学会“这个零件的语义对应哪些特征、这些特征以什么顺序组合、各个参数大致是多少”，剩下的精确几何计算交给CAD内核去做。

这就是 text-to-cad 与文生图最本质的差别——模型不是在“画模型”，而是在“写建模程序”。程序写对了，CAD内核执行一遍，自然就能得出一个真正可编辑、带参数、符合工程语义的实体模型。

1.3 这条思路解决的核心痛点

站在一个实际从业者的角度看，这个方向真正解决的不是“建模速度快不快”的问题，而是“建模的门槛”和“设计的表达成本”问题。

传统CAD有个尴尬的地方：它是面向“过程”的软件，你得一步步告诉它怎么建模型，不能直接告诉它“我要什么”。比如你跟工程师说“我需要一个能装在80x80铝型材上的电机支架，电机法兰面距离型材面35毫米”，工程师脑子里想的是这个零件长什么样，但手在软件里干的是另一件事——选平面、画轮廓、约束、拉伸、阵列。文本到模型的转化发生在工程师脑子里，软件只是忠实的执行工具。

text-to-cad 把目标定为：跳过“人脑做几何拆解”这一步，让模型从需求描述直接生成对应的建模过程。这个能力一旦足够可靠，受益最大的不是熟练工程师（他们本身建模效率就高），而是两类人：一类是懂产品但不会CAD的机械设计师、采购、销售，他们能描述需求但画不出零件；另一类是需要做大量方案比对的工程师，生成几个候选外形花不了多少时间，可以快速排除明显不合适的方案，再精雕细琢。

2. 技术细节拆解：一个 text-to-cad 系统由哪些部分组成

2.1 文本编码与设计意图理解

整个系统的第一环，是如何把自然语言描述变成机器能用的语义向量。市面上主流的做法是直接用一个预训练的语言模型做编码器，把“一个L型支架，底板上有四个直径6的安装孔，竖板顶端有一个朝前的凸台”这样的句子，编码成一个语义向量序列。

这一环的难点不在“理解人话”上——大模型的语义理解能力已经足够强了，真正的难点在于语义对齐。同一个零件，不同人描述方式差很远：工程师会说“Q235钢板折弯，L型，两侧各两个沉头孔，表面发黑”，而一个外行可能只会说“一个金属拐角，上面有几个洞”。“金属拐角”在大模型看来和“L型折弯板”是同一个东西，但和具体建模特征（钣金折弯特征、沉头孔特征）之间的映射关系，是需要专门学过的。

所以这个环节在实操中要做的工作，往往不是调语言模型，而是准备高质量的指令-建模指令对，让模型见过足够多“人话”和“特征操作序列”之间的对应样例。

2.2 几何表示与序列生成

当模型理解了意图之后，接下来是生成环节的核心问题：用什么样的表示方式来描述几何。

目前能跑通的方案主要有两种，我在实践里都试过。一种是基于CSG（构造实体几何），把模型描述为一系列布尔运算的组合——“一个长方体加一个圆柱，减去一个小圆柱”。这种表示的优点是简单、稳定、生成出来的结果几乎不会出现扭曲的曲面，缺点是无法表达复杂轮廓，稍微带点自由曲面的零件就抓瞎了。

另一种是基于特征序列的方式，这也是我目前认为更接近实战的方向。特征序列里的每个token对应CAD软件中的一个特征操作，比如“草绘”“拉伸”“切除”“倒角”。这种方法生成的模型天然带特征树，导进CAD软件里可以直接点选每个特征去修改，非常符合工程师的使用习惯。难点也随之而来：特征序列的语法比CSG复杂得多，模型要学的东西也更多，训练难度和推理复杂度都上一个台阶。

我个人的倾向是：如果你只是做个Demo验证想法，CSG能省不少事；如果你真想做能落地的原型，就必须上特征序列。

2.3 约束与尺寸：最容易被忽视也最要命的环节

做 text-to-cad 的路上有太多看起来“微不足道”但实际决定生死的细节，尺寸约束绝对是排第一位的。

一个工程零件，光“形状对”是没用的。M6螺丝孔径你生成成8毫米，装配图上就过不了干涉检查；轴承安装孔的直径差了0.1毫米，公差配合就完全不对。但尺寸信息恰恰是语言模型最不擅长处理的东西——语言模型天生擅长处理离散的符号，而尺寸是连续的数值，生成连续数值恰恰是LLM最弱的一环。你让模型输出“直径4毫米”它大概率能输出4，但让它输出“直径4.90毫米”，它可能给你来一个4.88，然后一本正经地认为自己没错。

实操中解决尺寸问题的思路有几条，我逐一试过：

• 第一，在指令描述里把尺寸写得非常精确，让模型尽量走“检索”而不是“推理”的路子；
• 第二，后处理校验——生成完之后用几何内核去测量关键特征的尺寸，与语言描述里的参数做比对，偏差超过阈值就重新生成或者强制修正；
• 第三，也是最值得投入的：把尺寸参数外置。生成模型只管结构和形状类型，具体数值通过规则从文本里抽出来，直接注入到建模脚本里，不经过生成模型。这一步能极大提高尺寸准确率，代价是要写不少解析逻辑。

2.4 从“理论上对”到“实际能加工”：验证与后处理管线

就算模型生成的脚本语法完全正确、特征顺序合理、尺寸也都对，也不代表这件它就真的能用了。工程软件里还有一堆“文科生不会想到”的问题在等你。

第一个坑是特征间的依赖冲突。模型可能会生成一个“先倒角再切除”的顺序，但在这个具体几何上，切除操作会把倒角面整个切掉，导致倒角特征失效。这种问题模型的训练数据里如果没覆盖到，它自己是意识不到的，必须用CAD内核实际执行一遍，检查特征树上有没有报错的特征。

第二个坑是几何退化。拉伸特征的草图闭合了但内部有自相交环，或者两个特征形成零厚度的薄片，这些在网格层面看不出来，但在实体造型里就是核心里解算不过去的错误。做后处理的时候需要用几何内核的布尔运算和拓扑检查工具过一遍，出问题就标记为失败案例。

所以我一直建议每一个做 text-to-cad 的朋友，不要只停留在“生成一个STL文件看一眼”的阶段，一定要有一个基于几何内核的验证环节。那个你用来执行建模脚本的引擎，本身就是一个绝佳的裁判。

3. 实操复现：从头搭一个最小可用的 text-to-cad 流程

3.1 确定方案边界与工具选型

下面这部分，是我建议每一个想上手试的人先照做的流程。目标不是一步到位做出生产级系统，而是用最低的成本跑通一个“文字输入→参数化模型输出→CAD软件可编辑”的完整闭环。

方案选型上我给一个不会出错的组合：用某个开源的代码生成模型作为基座，把建模脚本的语法定义为结构化的函数调用序列，用CAD内核作为执行引擎。具体来说，建模脚本用类似“调用函数、传入参数”的形式组织，一层层描述每个特征，执行环境用支持脚本化建模的CAD内核，最终导出为标准交换格式。

这套组合的优势在于：每个环节都是成熟工具，你不用从零训练一个模型，也不用自己写几何内核，所有精力可以集中在“数据准备”和“指令调优”这两个真正决定成败的地方。

3.2 数据准备：从CAD模型库反推训练样本

text-to-cad 和很多AI方向一样，最大的瓶颈不在模型结构，而在数据。训练一个“文本到建模脚本”的模型，需要海量的“零件描述→建模脚本”配对。现成的数据不会凭空掉下来，但有一个绕不开的笨办法：找一套CAD模型库，用内核把每个模型重放一遍，把建模历史导出成脚本化表示，再搭配一个自动化的标注过程生成描述文本。

实际操作时，这个过程可以拆成三步。第一步，从模型库中筛出特征树结构合理、参数化程度较高、特征数量适中的零件，过滤掉那些由导入网格转成的“哑实体”。第二步，对每个模型导出其特征序列，并从中抽取关键参数——长度、直径、孔数、倒角半径等等。第三步，写一个模板化的描述生成器，把抽取出来的参数组织成自然语言描述。

这种生成出来的文本难免会比较“机械”，比如“一个长100宽50高20的矩形底座，四角有四个直径6的通孔”。但它作为冷启动的训练数据完全够用，之后想提升语言的多样性，再用大模型做改写扩充也不迟。

3.3 模型微调与推理：指令跟随是核心

数据准备好之后，下一步就是对基座模型做指令微调。我的建议是不要从一个随机的语言模型开始训练，而是直接用某个开源的代码模型作为底座——它已经具备良好的序列生成能力和结构化输出能力，你要做的只是让它学会“建模脚本的方言”。

微调阶段有几个加速收敛的细节值得注意。一是要把所有建模脚本的token统一缩放到一个合理的词汇表内，特征名、参数名尽量固定化，减少模型的记忆负担。二是要对脚本做语法校验，把大量“语法错误”的样本直接从训练集里剔除，避免模型学会生成垃圾序列。三是在损失函数上对数值token稍微加权，这能缓解一部分前面提到的“尺寸不可靠”问题，虽然不是根治，但确实会有改善。

推理阶段我习惯用较低的采样温度和较高的重复惩罚。建模脚本和自然语言不一样，它不允许“换个花样再说一遍”这种事。同一个特征重复写两遍在文本里可能只是个语气问题，在建模脚本里就会导致重叠实体的布尔运算报错。

3.4 执行与导出：让模型输出真正“落地”

推理完成之后，模型手里拿着的是一份“建模脚本草稿”。接下来要做的不是拿它当结果，而是把它喂给CAD内核去执行。

我自己的流程是这样：先做一层脚本级校验——检查括号配平、函数调用是否匹配、参数数量和类型是否正确；通过之后交给内核执行；执行过程中捕获异常，如果某个特征失败，就把整个生成案例标记为“失败”，退回重采样；执行成功之后，再做一轮几何检查——用内核自带的工具确认模型是实体而非曲面片、体积为正、没有自由边。

全部通过之后再导出为标准的STEP格式，然后拿到CAD软件里打开。这一步是最有成就感的时刻：你能在特征树里看到“拉伸1”“切除2”“倒角3”这些熟悉的名字，能双击尺寸去修改，整个模型和手建的没有任何区别。到这一步才算真正打通了从文字到可编辑CAD模型的闭环。

4. 踩过的坑与排查实录

4.1 生成结果“坍缩”：所有输出都长得一样

我遇到的第一个大坑是模型的输出多样性几乎为零。无论输入怎么变，生成出来的零件都是“一个方块上面打个孔”，要不就是“一个方块下面挖个槽”。

检查下来，问题出在训练数据分布上。我最初准备的数据里，简单零件占了绝大多数，模型很快就学会了一个“最保险”的输出模式，因为这种输出在训练集里对应的概率权重最高。语言模型在建模脚本这种低容错场景下，会表现出极强的“保守主义”。

解决方法是重新平衡数据集：把简单零件控制在40%以内，增加中等复杂度和带较多特征交互的样本比例。同时，在推理阶段增大采样温度范围，让模型有机会跳出概率最高的那个“安全区”。

4.2 尺寸信息抖动

这个问题前面提到过，这里说一个具体的排查经历。某个模型输入描述里明确写了“孔径6.2毫米”，模型生成的脚本里这个参数写成了6.02。

这类错误特别阴险，因为肉眼根本看不出来，要实际进装配环境里和标准件配合才会暴露。我后来在排查中发现，尺寸错误的分布也不是均匀的——出现在“描述文本后部”的尺寸参数错误率明显更高，模型的上下文注意力在长文本末尾会衰减。

应对措施从三方面下手：一是在训练数据里做尺寸数值的多样性增强，同一个零件在描述里用多种写法表达同一个尺寸，比如“6.2毫米”“直径六点二”“约6.2”，让模型学会对具体数值更敏感；二是后处理时对数值型参数做模式校验和范围检查，超出合理工程区间的直接拦截；三是把关键尺寸改为从文本中显式抽取，绕过生成模型。第三点效果立竿见影，强烈推荐做。

4.3 拓扑错误：实体变成了“一堆面”

有一阵子我拿到的生成结果是“看起来正常但无法导出的模型”。外壳完整，体积为正，但就是导不出STEP——内核报错说存在非流形边。

排查后发现典型成因是：模型生成了两个尺寸完全相同但位置略微重叠的特征。视觉上你根本看不到任何问题，因为重叠区域完全被外壳包住了，但在实体建模的拓扑逻辑里，这个模型内部产生了自交面，属于非流形实体。

解决思路是建立一条“重叠特征检测”的规则：序列执行过程中，如果某个新特征与已有实体的包围盒在三个轴向上都有交集，触发自动检查。虽然这会牺牲一点计算速度，但能拦住大多数拓扑问题。

4.4 提示词工程在 text-to-cad 里作用有限

不少朋友拿着大模型的提示词技巧来套 text-to-cad：加“请仔细思考”、给几个示例、要求模型“逐步推理”。实测下来，加了这些之后生成质量有一些提升，但幅度远不如文生图那边明显。

原因是建模脚本基本没有“模糊地带”，它不像写文章可以换一种措辞表达同一个意思。你让模型“再想想”，它想不出什么新的，因为它缺乏对几何的实时校验能力——它不知道自己写的“拉伸20毫米”在转成实体之后看起来是什么样的。

真正有效的提升手段只有一个：在推理时对多轮采样结果做几何校验，选“能通过核验”的那一个。让模型多采样几个候选，对每个候选跑一遍完整的“脚本校验+内核执行+几何检查”管线，最后把通过的那个拿出来。这个“最佳-of-N”策略在 text-to-cad 上带来的提升，比我试过的任何提示词技巧都大。

4.5 评估指标选错，等于白忙

初期的评估走了弯路：我用“生成脚本与参考脚本的token级相似度”来打分。跑出来的分数高达90分，模型却一塌糊涂——几乎每个模型都在中间某一步用了不同的特征组合方式，token序列差异巨大，但几何结果确实是对的。

token相似度这个指标在 text-to-cad 里基本没有参考价值。同样一个零件，建模方法有无数种：先拉伸再切除，或者用旋转特征一步做出回旋体，结果实体是同一个，但token序列天差地别。

后来我改成了一套更务实的评估组合：三维几何相似度指标算外形贴合程度；关键尺寸误差直接度量标注尺寸与模型实测的偏差；特征树有效性用来判断生成模型在CAD软件里是否可用；还有通过率指标看100次采样里有多少能完整跑通内核执行。这四项结合起来，才能比较客观地反映一个生成系統的真实水平。

5. 落地场景与现实边界

5.1 最可能先落地的场景：概念设计阶段

我认为 text-to-cad 最先赢得的不会是生产制造环节，而是概念设计阶段。

工程师做方案设计时的一个常态是：脑子里有好几个结构方案，但每个方案都建一个完整的三维模型成本太高。多数人会在纸上画草图，或者直接用简单的几何体拼一个“意思对了”的示意模型。text-to-cad 在这个环节能发挥空间很大——把方案的模糊描述丢进去，快速产出几个不同的三维示意模型，形状对、特征表达清楚、能转视角看空间关系，就达到目的了。后续精修依旧是工程师的事，但省掉的是“为方案比对而建模”的大量时间。

5.2 另一个高价值场景：跨角色沟通

制造业里有一个长期存在的效率黑洞——非技术角色与技术人员之间的需求沟通。一个采购人员拿到供应商的样品，想告诉工程师“我需要一个跟这个差不多但安装孔距大一号的支架”，他大概率会拍张照片发给工程师，然后花二十分钟在微信里用文字描述“大一号是多大”。

这类场景恰恰是 text-to-cad 最擅长的：不要求描述完全精确，只需要大致表达清楚“是什么零件、关键位置在哪里、主要尺寸是多少”，就能生成一个可供讨论的三维模型。准确的尺寸仍需确认，但沟通效率的提升是实实在在的。我甚至设想，如果将来这类能力嵌入到即时通讯工具里，制造业上下游的沟通方式可能会发生不小的变化。

5.3 现实边界和冷静预期

该泼的冷水也得泼。以我目前实测的水平来看，text-to-cad 距离“取代CAD工程师”还有非常长的路——它连中等复杂度的装配体都处理不了，更不用说那些依赖大量工程经验的铸造圆角、拔模斜度、公差标注和加工工艺性设计。

目前的系统本质上还“只会做填空题”——你给它足够明确的描述、足够标准的特征组合，它能给你一个合格结果；一旦涉及需要实际工程判断的地方，比如“这个位置壁厚太薄，应该加一条加强筋”“这里应该用钣金折弯而不是实体拉伸”，它就完全无能为力了。

但反过来看，如果只是把预期设定在“辅助早期设计”和“降低沟通成本”这两个目标上，它是完全有资格进入实用化的。一个系统只要能稳定地把“我要一个带四个安装孔的连接板”变成“一个带四个沉头安装孔的参数化连接板模型”，它就已经有价值了——哪怕它完全不懂柔性和强度，也不影响这个价值成立。

6. 写在后面的个人体会

text-to-cad 是我近几年接触过的最“拧巴”的AI方向——它既要模型懂自然语言，又要模型懂工程语义，还要模型输出的几何严格满足可制造性约束，三个目标之间随时打架。也正是这种“拧巴”，让这个方向比单纯追求视觉效果的生成任务更有意思，水也更深。

如果你正准备入坑，我给三个最实在的建议：第一，一定把CAD内核的执行校验作为你系统的中心枢纽，所有生成结果都要经过它，围绕它来迭代，而不是拿模型当裁判；第二，数据上宁缺毋滥，几百个干净的带特征历史的模型，比几万个网格转换来的哑模型有用得多；第三，从最小场景出发，先只做一类零件、一种钣金工艺、一套固定的特征组合，跑通一个窄范围的闭环，再逐步放开自由度。

最后分享一个我实操中的小技巧：把指令里的尺寸分成“关键尺寸”和“非关键尺寸”两类处理。关键尺寸强制走解析抽取，不经过生成模型；非关键尺寸放开让模型自由发挥。这样，整个系统的尺寸可靠性会远高于把所有参数都交给模型生成的做法。这个改动在我自己的项目里，把关键尺寸的误差率降低了超过一半，而实现成本只需要多写几十行解析代码。很值。