企业官网建设流程全解析

大概去年年底，有个做设备集成的朋友甩给我一段话："一块80毫米乘50毫米的铝板，厚5毫米，四角倒圆角R3，上面均布四个直径4毫米的沉头孔。"他说想要个三维模型先看看装配效果。换作以前，我得打开CAD软件，建草图、标约束、做拉伸切除，少说五分钟起步。那次我直接用一条text-to-cad的调用链，十几秒就拿到了能出图的模型文件。

这就是text-to-cad最直观的价值：把"设计意图"到"几何模型"之间的翻译成本压到几乎为零。但话说回来，这种工具远没有网上吹得那么"万能"，真跑起来坑不少。这篇文章把我这几个月的实测心得整理出来，从技术原理、工具搭建到提示词设计、常见踩坑，一次性讲透。想了解或者已经在用text-to-cad的朋友，应该能从中省下不少试错时间。

1. 为什么"说人话"就能建模：text-to-cad到底在解决什么

1.1 传统CAD的门槛不在画图，而在"翻译"

很多没用过CAD软件的人以为难点在"画"，其实真正劝退新人的是"翻译"——把脑子里那个三维零件，翻译成软件能理解的一系列特征操作。比如"一个带孔的方块"，在软件里至少要拆解成：拉伸一个长方体、在顶面建立草图、画圆、添加约束、拉伸切除。每一步都有对应的命令和参数界面，这一整套流程需要长期训练才能形成肌肉记忆。

text-to-cad从根上改变了这个交互方式。它让用户用自然语言描述需求，由大模型负责完成"自然语言到建模操作"的翻译。还是刚才那个例子，对于大模型来说，"80乘50的板、5毫米厚、四角R3圆角、四个φ4沉头孔"这句话已经包含了完整的特征树信息，它只需要把这些信息映射成一段可执行的建模脚本，问题就解决了。

1.2 text-to-cad不等于"AI自动建模"，先摆正预期

这里我想先泼一盆冷水。很多人第一次听说text-to-cad，以为它能像ChatGPT写文案一样，输入"给我设计一个减速器"，直接吐出完整装配体——这个预期目前完全不现实。

我实测下来的感受是，它更擅长的是"参数化零件的快速生成"，而不是"创造性设计"。什么叫参数化零件？就是那些结构明确、尺寸清晰、特征规则的机械件：支架、法兰、盖板、壳体、导轨滑块之类。这类零件的共同点是，它们的几何构成完全可以用有限个参数描述清楚。而对于需要大量工程权衡的复杂设计，比如考虑应力分布的异形结构件，或者涉及多零件运动关系的装配体，text-to-cad目前给不了什么实质性帮助。

一句话总结：它是个优秀的"执行者"，还不是优秀的"设计师"。认清这一点，后面很多使用策略就清楚了。

2. 文本变模型的三条技术路线：代码生成、扩散生成与混合方案

2.1 路线一：让大模型直接编写参数化建模代码

目前落地最多、效果最稳定的一条路线，是让大语言模型生成参数化建模代码，再用对应的几何内核去执行。所谓"参数化建模代码"，通常指CadQuery、OpenSCAD这类脚本化建模工具的代码。CadQuery用Python语法写，OpenSCAD是类C语言的DSL，它们都能描述"从草图到特征再到布尔运算"的完整建模过程。

这条路线之所以稳定，是因为几何精度完全由代码里的数值决定。比如下面这段CadQuery代码：

import cadquery as cq result = ( cq.Workplane("XY") .box(80, 50, 5) .edges().fillet(3) .faces(">Z").workplane() .rect(60, 30, forConstruction=True) .vertices().cskHole(4, 6, 82) )

大模型的任务不是去"猜"几何，而是写出一段语法正确的代码。只要代码能跑通，生成模型的尺寸就百分百精确。这也是为什么我在实际项目里优先选这条路线：误差可控、便于参数调整、可无缝衔接下游工程。

2.2 路线二：文本直接驱动三维形状的扩散生成

第二条路线借鉴了图像生成领域成熟的扩散模型思路，输入文本描述，输出三维体素、点云或网格。它的优点是对于有机形状、自由曲面有很强的表现力，适合做概念外形设计，比如茶杯、雕塑、玩具外壳。

但问题也很致命：扩散模型生成的几何是"网格"，不是"参数化实体"。网格转CAD面临一条巨大的鸿沟——网格本质上是一堆三角形面的集合，而CAD需要的是带约束关系、特征历史的B-rep实体模型。哪怕外形看着对了，一旦要修改某个孔的直径，或者想提取工程图上需要的中心线、参考面，网格模型就完全无能为力了。

我个人的判断是：这条路线短期内更适合做视觉参考和方案探索，离真正的工程落地还有相当距离。

2.3 路线三：从粗到细的两阶段混合方案

混合路线试图取前两者之长。第一阶段先用扩散模型生成一个粗略的参考网格，解决"大致形状对不对"的问题；第二阶段把网格交给一个程序化生成模型，识别其中的平面、圆柱面、孔洞特征，重新构建带参数约束的CAD特征树。这两年在学术界出现的部分text-to-cad工作就是走这个方向，比如基于DeepCAD数据集训练的方法，会输出特征序列再重建为STEP文件。

实际效果怎么说呢？对于特征比较规范的工业零件效果尚可，一旦遇到复杂曲面或者网格质量不佳，第二阶段重建的特征树会"碎"掉，得到一堆互相矛盾的约束。到目前为止，混合路线的稳定性还远不如纯代码生成路线。我建议普通用户暂时不用太关注这个方向，知道有这么回事就行。

我把三条路线的差异整理成一张表，方便对比：

3. 动手搭一个最小可用系统：CadQuery加大模型API

3.1 环境准备与选型理由

我自己的主力方案是CadQuery加一个大模型API。选CadQuery而不是OpenSCAD，主要是因为它的Python API设计更接近现代编程习惯，面向对象的链式调用让代码可读性好，而且它在布尔运算、倒角、孔特征方面的能力比OpenSCAD完整得多。OpenSCAD当然也可以，但做复杂一点的零件时，它的CSG语法写起来相当痛苦。

环境搭建很简单，基本就是Python环境加上CadQuery库：

pip install cadquery pip install openai # 或者其他大模型API的SDK

顺便说一句，CadQuery默认使用mm单位，这点和绝大多数机械图纸一致，省去了单位换算的麻烦。它内置的几何内核是OpenCASCADE，和FreeCAD同款，这意味着导出STEP、STL之类的标准格式时兼容性很好，下游用SolidWorks、Inventor打开都顺畅。

3.2 让大模型输出结构化建模代码的调用设计

拿到大模型API之后，关键不是"问它要代码"，而是要用合理的系统提示词约束它的输出格式。我踩过的坑是：如果只是简单说"生成一个CadQuery脚本"，模型经常会在代码里混入解释性文字、无关的空行，甚至给出多个可选方案，导致后续解析脚本时很麻烦。

我的做法是要求模型输出严格的JSON结构，把代码和说明分离。一次请求的格式大概是这样的：

{ "think": "这里填写建模思路，便于人工检查", "code": "这里填写完整的CadQuery代码", "params": {"长度": 80, "宽度": 50, "厚度": 5} }

在系统提示词里明确要求"只输出JSON，不要输出任何其他文字，code字段内必须是可直接执行的Python代码，不得包含注释以外的markdown标记"。这样返回结果就能用json.loads直接解析，然后exec执行code字段里的代码，拿到模型对象。

3.3 自动校验与导出：不能拿到模型就算完

代码能跑通，不代表模型就是对的。我通常在生成后做三项自动校验：第一，检查模型是否为空，常见原因是某一步布尔运算把实体裁没了；第二，检查边界框尺寸，和提示词要求的关键尺寸对比，偏差超过0.1mm就要重新生成；第三，检查体量，如果同样尺寸下体积异常，多半是某个特征没有生效。

校验通过的模型，直接导出成STEP格式和STL格式。STEP用于后续工程改造，STL用于3D打印预览。CadQuery导出就两行代码：

cq.exporters.export(result, "bracket.step") cq.exporters.export(result, "bracket.stl")

到这里，一个"文本到CAD文件"的最小闭环就算打通了。整个流程从发请求到拿到文件，通常不超过20秒。

4. 提示词才是真正的控制面：把"看得懂"变成"造得出"

4.1 模糊提示词的一次失败实录

我最初做测试的时候，用的提示词是"帮我做一个L型支架"。结果生成出来的东西，外形确实是个L，但尺寸完全不可控——支架壁厚只有0.2毫米，立板和底板的孔位互相干涉，倒角大得离谱。这种模型别说加工，连看都没法看。

问题出在哪？出在我给的描述只有形状，没有约束。这就像你跟一个工程师说"帮我设计个支架"，他能给你一百种方案。大模型没有你的装配上下文，不知道这个支架放哪、受什么力、怎么固定，它只能凭语料里的平均印象瞎猜。

4.2 结构化提示词模板：把工程约束拆开喂给模型

经过反复试错，我总结了一个四段式提示词模板，每一次请求都按照这个结构来写。因为对于规则机械件，需要明确的信息就是形状、尺寸、材料和避让规则三类。

以一个电机固定支架为例，完整提示词长这样：

目标: 设计一个用于固定60mm步进电机的L形支架 形状: L形，竖直板与水平板垂直连接，外侧圆角过渡 关键尺寸: 竖直板高度 80mm, 宽度 60mm, 厚度 6mm 水平板长度 100mm, 宽度 60mm, 厚度 6mm 竖直板上4个直径4.5mm通孔，孔距 40mm x 30mm，中心距板边10mm 水平板上4个直径6.5mm通孔，孔距 80mm x 40mm，孔中心距边缘10mm 制造约束: 所有锐边倒角R1.5，避免应力集中 最小壁厚不小于3mm

注意这里的写法：目标、形状、关键尺寸、制造约束四部分各司其职。目标告诉模型这是干什么的，帮助它判断哪些结构是合理的；形状定义拓扑关系；关键尺寸给数值；制造约束排除掉不切实际的设计。写清楚这四段之后，生成成功率从原先的不到一半，提升到九成以上。

4.3 约束冲突时的优先级处理：告诉模型什么不能妥协

还有一个很容易踩的坑，就是约束冲突。比如你要求支架总高80mm，但底板的厚度加上立板的高度已经超过85mm，这种几何上必然打架的条件，大模型不会主动指出冲突，而是随便挑一个满足、另一个悄悄忽略。

我的应对办法是：在提示词末尾明确写上冲突时的裁决规则。例如"如果尺寸无法同时满足，优先保证安装孔距正确，其次保证总高度，壁厚可以在3mm上下浮动0.5mm"。这相当于给了模型一个"约束优先级排序表"。有了这个，模型就不会自作主张乱选。我觉得这种用法，本质上和给工程师提需求时写"关键特性清单"是一个道理。

5. 实测踩坑记录：从乱码几何到非法代码

5.1 单位、坐标系与方向：最容易出错且最难发现的坑

CadQuery默认单位是mm，这本身没毛病。但大模型在训练数据里见过大量英制单位的内容，它生成的代码里偶尔会出现英制数值，比如把厚度写成0.5而不是12.7。这个错误在视觉上极难发现——一块大面板和一块薄片，在屏幕上不仔细看真的差不多。我现在要求模型在代码里必须用"长度数字 + 单位标注"的方式给出参数表，人工抽查时先看参数表有没有异常的整数。

坐标系也是个隐蔽问题。CadQuery的默认草图平面是XY面，法向沿Z轴。但在3D打印和很多机加工场景，Z轴朝上只是习惯，并不代表每个图纸都这么摆。模型生成的代码如果默认平面选错，会导致整个零件转了一个方向，装配时会出大问题。我通常在提示词里显式要求"使用XY平面作为主安装基准面"，避免模型凭感觉选面。

5.2 布尔运算与圆角顺序：特征顺序就是公差

CadQuery的建模本质是连续做布尔运算，而布尔运算非常依赖实体间的精确贴合。我碰到过一次情况：先给立板做圆角，再在圆角面上打孔，结果孔位始终偏了0.01mm。原因就是圆角曲面导致的拓扑变化，让后续的草图平面定位产生了偏差。

正确的做法是先完成所有孔洞和切除操作，最后统一做圆角。这和机加工工艺顺序其实完全一致——先钻孔，后倒角。这类"特征顺序即工艺顺序"的经验，我建议初学者在写提示词时就直接写进去，比如"代码中圆角操作必须放在所有切割特征之后"。这句话能避免掉一大半布尔运算的报错。

5.3 LLM幻觉代码与兜底策略：让模型自己改错

大模型生成代码，免不了产生幻觉——调用一个CadQuery里根本不存在的API，或者把方法名拼错。我遇到过一次模型生成了.chamfer()但参数写成字符串的情况，程序直接崩溃。

我的兜底策略很简单，但很有效：捕获异常之后，把完整的错误堆栈回填给大模型，让它基于报错信息修改代码。这相当于人类程序员对着报错日志改bug，只是改码的人换成了AI。实际跑下来，一次修正的成功率在60%左右，两次修正后能到85%以上。我把这个重试逻辑封装成一个循环，最多自动重试三次，三次都不行就标记为失败，进入人工处理队列。

下面是我遇到的典型问题与对应的解决方式：

6. 从"玩具"到"工具"：text-to-cad的现实边界与入坑建议

6.1 它已经能做好的场景，以及适合谁

按我当前的使用强度，text-to-cad在三个场景里完全够用：第一，快速方案评估，客户或同事给个粗略需求，我先用text-to-cad生成一个参考模型，放进装配体里看干涉、看空间布局，十分钟内心里就有数了；第二，自动化设计变体，同一种零件需要改几个尺寸出不同规格，直接改提示词里的参数批量生成，比手工改模型快一个数量级；第三，教学和演示，给新人讲参数化概念时，让他们用自己的语言描述需求、再对照生成的代码理解特征树，比对着教科书讲效率高太多。

如果你是机械设计、自动化设备、3D打印爱好者，或者做非标设计的工程师，text-to-cad现在就可以用起来。不需要深度学习背景，会写提示词就行。

6.2 它暂时做不好的场景：别在这些地方浪费时间

坦率地说，有几个场景我用下来体验很差。一个是复杂曲面外壳，比如鼠标、手柄这类需要人体工学曲线的产品，代码生成路线的参数化模型在曲面表现力上远不如手工建模和网格建模；另一个是大型装配体，text-to-cad生成的单个零件还好，要协调几十个零件的装配约束和运动关系，靠自然语言描述既不直观也容易漏约束；还有一个是注塑件设计，拔模角度、壁厚均匀性、装配卡扣这些跟工艺强相关的细节，模型经常生成得不合理，需要大量人工修正。

所以我的建议是：把text-to-cad定位成"设计流水线里的加速器"，而不是"代替设计者的大脑"。复杂产品设计该用传统CAD流程还是老老实实用，别搭上太多时间去调提示词。

6.3 想入坑的人，我建议从这三步开始

如果看完这篇文章你想试试，我建议不要一上来就搭复杂的API流程。先做三件事：第一步，装一个CadQuery，跑通官方示例里的几个基础模型，理解Core API是怎么工作的；第二步，用现成的大模型网页版，把CadQuery官方文档的代码风格喂给它，反复让它改你的提示词，直到能稳定生成简单零件；第三步，再考虑脚本化和API接入，把校验、重试、导出这一套自动化管线搭起来。

这样从简到繁逐步推进，遇到问题也知道是哪一环出的问题。我自己就是按这个路径走的，前两步花了两个晚上，第三步用了差不多一周。这套管线跑通之后，后面省下来的时间相当可观。

我在实际使用中还有一个小经验：给同一个需求多跑几次生成，把每次代码和结果都存档。因为大模型生成有随机性，同一段提示词每次都可能有微小差异，某一次可能特别贴合需求。存档多了，哪天需要类似零件时直接改参数复用，比重新提问快得多。这也算是把text-to-cad用出"私有零件库"的感觉了。