企业官网建设流程全解析

这几年只要聊到AI辅助设计，我十有八九会被人拦住追问同一个问题：能不能让AI直接按我的描述把三维模型建出来？以前的标准答案是“能，但只能建个大概”，而现在这个方向终于有了一个正式的名字——text-to-CAD。简单说，它就是让计算机读懂一句自然语言描述，把它翻译成可编辑、可仿真、可制造的CAD模型。我在自己的工作流里已经试跑了快一年，踩过不少坑，也积累了一些真正能落地的经验。这篇就把它拆开讲明白：text-to-CAD的技术路线有哪些、怎么样用最低成本搭一套可用的流程、实操中哪些问题最容易翻车，以及什么场景下千万别对它抱有幻想。

1. text-to-CAD到底改变了什么：从“画图”到“说图”

1.1 传统建模流程的断点在哪里

传统CAD建模的痛点，其实不在“画线”这一步，而在“意图传递”。一个工程师在拿到需求时，脑子里往往已经有了清晰的功能逻辑：这里要开一个M6的螺纹孔、这里要做一个带2°拔模角的卡扣、这两个面之间要有0.1毫米的过盈配合。但把这些逻辑落到CAD里，需要拆解成一段极长的操作序列——建基准面、画草图、标约束、拉伸、倒角、再回头改参数。

麻烦的地方在于，草图约束和 feature tree（特征树）本身是一种非常反直觉的“语言”。你脑子里想的是“一个40×25的长圆安装孔”，到了软件里却要变成“在草图上画两个R12.5的圆，给圆心加水平约束，再画两条切线，裁剪，拉伸切除”。这一步占据了整个设计流程中大量的时间，却又没有多少创造性可言。

text-to-CAD要干掉的就是这个断点。它尝试把“人脑中的功能描述”直接映射成“CAD内核里的参数化特征”，让工程师把精力留在“设计什么”上，而不是“怎么画出来”上。这不是简单的效率提升，而是把设计环节的交互方式整体往前推了一大步。

1.2 text-to-CAD与“文生图”的本质区别

我第一次看到这个名词的时候，第一反应是“这不就是ChatGPT版的文生图嘛，只不过生成的是3D”。后来实际操作下来才发现，这个理解错得离谱。

文生图输出的是一张像素图，本质是二维颜色分布；而text-to-CAD输出的必须是一个真正的几何实体（B-Rep，即边界表示），里面包含面、边、顶点、拓扑关系，甚至可能还带特征树、约束和参数历史。一张图看错了顶多觉得丑，一个CAD模型如果拓扑错了，后面就没法做有限元分析，没法出工程图，更没法进CAM加工。

所以text-to-CAD的技术难度比文生图高一个量级。它不仅要理解自然语言里的空间关系、尺寸单位和公差语义，还要保证生成结果的几何闭合性、可制造性和参数可编辑性。换句话说，它生成的不只是一张“看起来像零件”的图，而是一个“真正能用”的数字化零件。

搞明白这个区别之后，我才意识到：评估text-to-CAD系统好不好，不能只看渲染截图，必须放到真实建模环境里验证。这也是我后面花了很多时间搭验证闭环的原因。

2. 三条技术路线的底层逻辑，以及为什么我选了编程这条路

2.1 路线A：让大模型直接写程序化建模代码

这是目前工程上最接近落地的一条路线。核心思路简单粗暴：既然大语言模型最擅长的是生成代码，那就让它生成参数化建模代码，再由程序化建模库去解析执行，最终在CAD内核中生成实体。

程序员圈子里流行的程序化建模方式，是把几何操作写成Python脚本或专门的脚本语言：定义变量、构建草图、拉伸、打孔、圆角。整个模型就是一个函数，输入参数输出实体。这种模式天然适合大语言模型去写，因为它的语法严格、结构明确、可验证性高——代码错了能报错，实体缺了能检查。

我把这类底层库统称为“CADGen”类工具（市面上常见的程序化CAD库都属于这个思路）。它的最大优势是：生成结果天然是参数化的，所有尺寸都来自变量，模型随时可以改。这对设计迭代来说太重要了。

2.2 路线B：端到端生成隐式几何场

第二条路线走的是深度学习的路子：训练一个扩散模型或者条件生成模型，直接输出体素场、有向距离场（SDF）或者占用场，然后通过Marching Cubes之类的算法提取网格。

这条路线的效果看起来很惊艳，模型描述得越具体，生成的三维形状越逼真。但它有一个致命问题：输出的是网格或隐式场，不是CAD实体。网格模型可以拿去3D打印看个样，但没法编辑特征、没法重建约束、没法在CAM里生成刀路。如果你只是想快速验证一个形态概念，那没问题；但如果你想把它纳入严谨的工程设计流程，这一步就断了。

我试过把这类模型生成的网格导入专业CAD环境再逆向重建特征，工程量比从头画还大。所以这条路线在纯设计探索场景值得关注，在工程生产场景里暂时还用不上。

2.3 路线C：预测参数化特征树

第三条路线是目前学术圈研究最热的方向，思路是：不去生成代码，也不去生成网格，而是训练模型直接预测一个零件的完整特征序列——先画什么草图、用什么截面、做拉伸还是旋转、哪个面倒角多少。

这条路线如果走通了，体验会是三条里最自然的，因为生成结果就是标准CAD特征树，可以像手工建模一样任意编辑。代价是训练数据极其难搞。它需要大量带有完整设计历史的CAD文件，而真实工业界的设计历史往往混乱不堪，或者干脆在导出时丢失了。

目前这条路线还停留在小规模验证阶段，能用，但泛化能力有限。我评估过现有开源方案的输出，面对稍微复杂一点的零件就容易出现特征顺序错乱、参考关系缺失的情况。

2.4 三者的关键对比与选型结论

我的选择很明确：现阶段就押注路线A。原因很简单——它能和现有工程流程无缝衔接，而且大模型写代码的能力每天都在变强，这条路线的天花板还远远没到。

3. 从零搭建text-to-CAD工作流：架构、提示词与闭环验证

3.1 整体架构与核心决策点

我搭的这套工作流，核心就三个模块：大语言模型接口、程序化建模执行器和自动化校验器。用户输入自然语言描述，大模型把描述翻译成CADGen脚本，执行器跑脚本生成B-Rep实体，校验器再检查实体的体积、表面积、边界框等指标，把结果反馈给模型决定要不要修改。

关键决策点在两个地方：第一，大模型只负责“写代码”，不负责“想结构”，所有几何细节必须由用户在提示词里显式给出；第二，校验器必须能自动判断“生成的实体是否满足描述”，否则整个流程就退化成了“人工审查AI代码”，那就失去意义了。

我在实际跑通之前踩过一个弯路：一上来就期望大模型能自己理解“一个可以容纳两个轴承的支架”这种模糊需求，然后直接生成正确的模型。事实证明这是不可能的，大模型会把轴承直径猜错、把安装孔位置乱排。所以架构上我必须加入“约束预填写”环节，让用户补充关键参数。

3.2 环境准备与依赖项

搭建这套工作流的环境不复杂，一台普通工作站就够。操作系统我用的Linux，Python环境建议3.10以上。核心依赖就两类：一类是调用大语言模型接口的客户端库，另一类是CADGen这类程序化建模库及其附带的CAD内核依赖。

安装完成后一定要跑一个最小用例验证环境：让建模库创建一个简单的立方体零件，然后导出STEP文件，再用校验器读回。这一步能排除九成以上的环境问题——缺库、版本冲突、内核授权之类的问题都会在这个最小用例里暴露出来。

我强烈建议把整个过程容器化，因为不同项目的依赖版本经常打架。我一开始直接在宿主机上装，后来某个依赖升级后，之前能跑的脚本突然全部报错，排查了两天才发现是版本兼容问题。把环境锁进镜像之后，同类问题再也没出现过。

3.3 提示词模板：把“人话”翻译成“建模约束”

提示词模板是我这套工作流里收益最大、也最容易被忽略的部分。同一个大模型，用自由对话的方式描述需求，和用结构化模板描述需求，生成的成功率天差地别。

我用的模板经过了好几轮迭代，核心要求是：必须把尺寸、单位、坐标系、精度要求写清楚，并且强制模型“先列参数、再写代码”。一个典型的模板长这样：

你是一名资深机械设计师。请根据以下需求生成CADGen脚本： 需求描述：{用户描述} 必须遵循的规则： - 单位：毫米（mm） - 坐标系：右手系，Z轴向上 - 所有尺寸必须显式写出，不允许使用比例估算 - 草图中的尺寸必须标注，不允许遗漏 - 特征必须使用参数化变量，便于后续修改 - 输出要求：只输出CADGen代码，不要解释，不要输出代码块标记 - 代码要求：必须保证几何闭合，布尔运算后必须检查实体有效性

加了这套模板之后，成功率大概翻了一倍。核心逻辑很简单：大模型的“想象力”是需要边界的，你给它的约束越清晰，它越不容易自由发挥。

3.4 生成-执行-校验的闭环代码

我把整个闭环写成了一段Python脚本，核心逻辑足够简洁：

import cadgen # 程序化CAD库 def text_to_cad(user_description, llm_client): prompt = build_prompt(user_description) script = llm_client.generate(prompt) # 执行脚本，生成实体 entity = cadgen.run(script) # 自动校验 report = validate(entity, user_description) if not report.is_valid: # 把错误信息反馈给模型，要求重新生成 fixed_script = llm_client.generate( prompt + "\n上一次生成的模型存在以下问题：\n" + report.errors ) entity = cadgen.run(fixed_script) return entity

这里的validate函数是灵魂。我至少检查这几项：实体是否为空、边界框是否合理、体积是否异常、面数是否为闭合流形、关键尺寸是否符合描述。

校验失败后把错误信息拼回提示词，让模型自己改，这个循环我最多允许三轮。超过三轮就说明描述本身有问题，需要人工介入。这个机制帮我挡掉了很多无效生成，也省下了大量token费用。

4. 实测中的四次翻车和排查思路

4.1 生成的实体“隐身”了：显示范围与尺寸悬殊

第一次跑通全流程时，模型很听话地生成了一段代码，执行器也没报错，但我在视图里怎么都找不到零件。折腾了半天才发现，零件确实生成了，只是尺寸小得离谱——我描述里写的是“长度80毫米”，模型生成的代码里却写成了0.08，因为它在某个内部转换里把毫米当成了米。

这种“实体隐身”问题很有迷惑性，因为程序完全不报错，实体也合法，只是坐标系里根本看不到。后来我在校验器里加了边界框自动检查：如果边界框任意维度小于1毫米或大于10米，直接判定异常，让模型重新生成。这个规则简单但极其有效。

这个坑给我的教训是：尺寸单位不能只写在文档里，必须在代码层强制。我在模板里加了一条“所有长度值必须在变量命名中包含单位后缀”，比如length_mm = 80，这样就算模型写错，人眼检查代码时也能第一时间发现。

4.2 单位混乱：毫米、英寸与一次丑陋的配合

单位问题不只是显示层面的事，它会直接毁掉装配。有次我让系统生成一个外壳和与之配合的盖子，两段代码是分开生成的。外壳用了毫米，盖子模型在生成时被模型“聪明地”转成了英寸——因为它在训练数据里见过太多混合单位场景。结果单独看每个零件都正确，放到装配体里配合尺寸差得离谱。

排查过程让我印象很深：先怀疑坐标变换，再怀疑装配约束，最后才想到去查两个STEP文件里的单位元数据，一看一个用毫米一个用英寸。从那以后，我在执行器前面加了一个“单位归一化层”，任何脚本执行完都强制转成毫米，所有几何数据只在毫米基准下交互。

同时我在提示词里也加了肯定式指令：“不要使用英寸、英尺，不要做任何单位换算，所有数字都代表毫米。”把“不要”说清楚，和大模型沟通的效果远好于指望它自己理解常规逻辑。

4.3 特征失败的连锁反应：过约束与参考面丢失

程序化生成代码还有一个高频翻车点：特征之间的参考关系极易断裂。比如先拉伸一个主体，再在主体顶面上打孔，如果前一步实体因为某个操作产生了不同的面编号，后面的打孔参考就会指向错误的面或根本不存在的面。

我遇到过一次特别隐蔽的情况：模型先生成了一个带圆角的底座，然后在底座上表面创建草图。由于圆角操作把顶面切成了多段曲面，上表面不再是一个完整平面，草图参考报错，整个生成流程崩掉。代码单看每一段都合理，但组合起来就是“水土不服”。

解决这个问题的思路有两个方向。一是在提示词里强制要求“避免在圆角后创建新草图”，让模型调整特征顺序；二是在执行器里加自动修复逻辑，当某个特征失败时尝试重建参考面。后者实现起来复杂得多，我目前主要靠前者。

4.4 长描述被截断：上下文窗口的应对办法

text-to-CAD的描述越来越复杂之后，另一个矛盾浮出水面：大模型的上下文窗口是有限的，而一个复杂零件的描述加上提示词模板、历史纠错信息，很容易把窗口撑爆。

我遇到最尴尬的情况是：模型为了不截断描述，擅自删掉了我写的一个关键公差要求，然后生成出来的孔全部没有公差标注。如果不仔细看生成代码，这个错误根本发现不了，而到了加工阶段就会出大问题。

应对策略是拆分描述：把一个复杂零件拆成多个子需求，分多次调模型，先生成主体，再生成特征，最后用一个总脚本把子结果组合起来。这本质上是在用模块化对抗上下文限制。虽然多了几步调用，但每一段描述都能被完整处理，正确率反而更高。

5. text-to-CAD的现实边界：装配、生态与不适用场景

5.1 装配约束是另一个维度的难题

单个零件的text-to-CAD已经很不容易了，但装配体是另一个维度的难题。零件可以用尺寸和形状来描述，装配关系却涉及自由度、约束类型、运动副，这些东西用自然语言描述极易产生歧义。

举个例子，“轴和孔配合”这句话里，到底是间隙配合还是过盈配合？公差等级多少？配合长度多少？这些信息如果不在描述里写清楚，任何模型都没法猜。即使写清了，把多个零件放进一个装配坐标系里，对齐约束的生成也是极高的概率会出错。

我目前的方案是：把装配拆成“零件生成+装配约束人工指定”两步走。让模型干它擅长的事——生成单个零件，然后由人在装配环境里添加重合、同轴、相切等约束。这样虽然没完全自动化，但已经比全部手工建模节省了大量时间。

5.2 接入现有设计流程的三个可行位置

text-to-CAD想真正产生价值，得找到它在现有流程里的位置。我总结了三个最可行的接入点：

第一，方案概念阶段的快速验证。设计师用几句话描述需求，快速生成多个版本的结构方案，再从中挑选最合理的细化。这个场景对精度要求低，对速度要求高，正好是text-to-CAD的优势区。

第二，标准件和简单零件的批量生成。像垫片、支架、法兰、安装板这类结构简单但数量庞大的零件，手工建模费时费力，让AI按参数描述批量生成，效率提升非常明显。

第三，设计文档到模型的前期转换。把我手里积压的大量旧设计文档用自然语言描述出来，让AI重建出参数化模型，再由工程师检查修正。这比完全从零开始建模还是要快。

5.3 我建议直接放弃text-to-CAD的三类场景

不是所有场景都适合这条路。我吃过亏之后，总结了三类建议直接放弃的场景。

第一，高精度公差的精密零件。任何涉及公差带小于0.01毫米的配合，我都不敢让AI自由定义尺寸，必须在后续花大量精力校核修正，不如手画来得可靠。

第二，复杂曲面造型。比如汽车A柱、消费电子外壳这类自由曲面，程序化建模本身就不擅长，让AI生成更是难上加难。这类设计属于细分曲面建模软件的领地，不是text-to-CAD的菜。

第三，需要严格遵循企业标准或行业规范的设计。每个公司都有自己的模板、图框、标准件库和命名规则，AI生成的模型很难在第一次就完全符合这些隐性要求，落地的成本反而更高。

6. 跑通这条路之后，我留下的几条个人经验

折腾了一年，我留下的最朴素的体会是：text-to-CAD现阶段不是用来取代设计师的，它是用来取代“重复劳动”的。凡是信息能完整量化、逻辑能被规则描述的设计，AI都能干得又快又好；凡是依赖人的直觉、审美和隐性经验的领域，AI还差得很远。

如果你想试这条路，我的第一条建议是：从一个“只有单一特征”的零件开始。别一上来就挑战多特征装配体。我见过太多人第一步就跑复杂案例，失败后直接下结论说text-to-CAD不行，其实只是没有控制变量。

第二条建议是：把提示词模板当成核心资产去迭代。你每调优一次模板，全流程的正确率就会上一个台阶。我甚至会把表现好的描述和生成结果存档，建立自己的“描述-代码”对照库，这比任何现成的提示词工程指南都管用。

第三条建议是：永远保留人工审核的环节。AI生成的代码再漂亮，实体再完美，也必须有人对关键尺寸、公差、材料做最终确认。这不是不信任AI，而是工程的基本素养。

最后再分享一个很实用的小技巧：生成的脚本里，每个特征的变量名都用带语义的英文单词，不要用feature1、feature2这种名字。当时觉得无所谓，后来要回看修改的时候，才体会到这些名字省下来的时间有多值。至少对我来说，这套工作流已经成了日常设计里离不开的一个环节——它不会替我思考，但确实替我扛下了大量“画出来”的辛苦活。