企业官网建设流程全解析

1. 从一句话到一块零件：text-to-cad到底在解决什么问题

先聊点实在的。过去十年，CAD圈子最大的变化不是某个命令多了新功能，而是“建模的入口”正在从鼠标键盘逐步转向自然语言。早期我们用命令行，后来用参数化草图和脚本，现在你直接敲一句“一个带四个安装孔、直径120mm的法兰盘，孔距85mm”，系统就能给你生成一个可编辑的CAD模型。这就是text-to-cad。

这个概念听起来像科幻，其实底层逻辑并不玄乎：把人类描述三维物体的语言，映射成CAD内核里的几何操作序列。它不是简单地从素材库“搜”一个模型出来，而是真正“生成”一个带完整特征树、参数可改、能进CAM流程的实体模型。这个区别非常关键——搜到的是别人的零件，生成的是你自己的零件。

这件事解决了什么痛点？我自己的体会是三个：

1. 把“脑子里想的”变成“图纸上有的”这一步，卡住了太多人。不是每个人都会熟练操作草图、拉伸、倒角，但几乎每个人都能说清楚“我要一个什么样的东西”。text-to-cad把“会说”变成了一种建模能力。

2. 重复性标准件设计效率极低。法兰、支架、外壳、卡扣，这些零件结构相似但尺寸各异，每次都得重新画一遍草图、重新约束、重新倒角。用自然语言描述尺寸和特征，生成一次，后续改参数就行。

3. 跨工种沟通成本高。结构工程师提需求，机械工程师建模，中间往往要反复确认。text-to-cad可以把“需求描述”直接转成“初步模型”，省掉一轮又一轮的“这里再大一点、那里再加个孔”的拉锯。

适合谁看？如果你刚开始接触CAD，想知道自然语言建模到底怎么落地；或者你已经在用SolidWorks、Fusion 360、FreeCAD这类工具，想试试新的工作流；再或者你纯粹好奇AI辅助设计能做到什么程度——这篇内容都值得你花几分钟读完。我会把原理、工具选型、实际跑通的流程、以及我踩过的坑都摊开讲。

2. text-to-cad的整体设计思路：它到底是怎么“懂”你的话的

2.1 一句话到模型的链路拆解

先给一个整体的架构认知，免得后面越看越乱。从我测试过的几套开源和商业方案来看，text-to-cad的系统链路大致是这么走的：

自然语言输入 -> 意图解析与参数抽取 -> 几何约束构建 -> 特征操作序列生成 -> CAD内核建模 -> 生成可编辑模型文件

用大白话讲就是四个步骤：

1. 听懂：把“我要一个直径50mm的圆柱体，高度80mm，顶部带一个直径10mm的通孔”拆成“圆柱体”“直径50”“高度80”“顶部通孔”“直径10”这些关键要素。这里用到的是大语言模型的基础能力，核心是实体抽取和关系识别。如果你用过ChatGPT，应该对这类“提取关键词”的能力不陌生。

2. 翻译：把上面抽出来的参数和关系，翻译成CAD建模的操作步骤。这一步最关键也最容易出错。比如“顶部带孔”是指孔的轴线与圆柱轴线重合？还是孔在圆柱顶面偏心？系统需要结合常识推断，或者直接向你确认。有的方案会生成中间代码，类似伪代码或者python脚本，方便你检查修改。

3. 执行：调用CAD内核的API，顺序执行这些操作。什么样的操作？建草图、加约束、拉伸、旋转切除、打孔、倒角，跟你在软件里手动点按钮做的事情是一模一样的，只不过变成了程序化的调用。

4. 产出：最终生成带参数化特征的模型文件，通常是STEP、IGES、或者FreeCAD/SolidWorks的源文件格式。这个文件不是“死”的网格模型，是活的特征树。

我这里要特意强调一下“特征树”这个点。很多刚接触的同学以为生成一个STL网格就是成功了，其实在真正的工程流程里，没有特征树的模型基本等于废品——你没法改参数，没法重排特征顺序，没法接CAM。所以判断一个text-to-cad工具能不能用，第一个标准就是看它输出的是“参数化模型”还是“一张皮”。

2.2 为什么说“直接生成图片再转3D”是条弯路

网上很多demo是把text-to-cad理解为“AI画图生成3D模型”——你先让AI生一张图，再用工具从图片重建三维网格。这条路线在视觉上很炫酷，但工程上走不通。原因很简单：

• 从图片重建出来的模型是离散网格，没有几何拓扑关系，无法标注尺寸，无法加公差，无法直接上机床。
• 图片本身没有精确尺寸概念，AI画出来的“直径50mm”是像素意义上的，不是毫米意义上的。
• 下游工程软件不认网格，你得重新逆向建模，那还不如直接建模。

所以真正实用的text-to-cad方案，走的一定是“语言 -> 参数 -> 特征操作 -> 内核建模”这条路，而不是“语言 -> 图片 -> 网格”。这也是我在给团队做技术选型时候反复强调的一条经验：别被demo骗了，看它最终输出的文件格式和特征树完整性。

2.3 技术选型：我试过的几类方案对比

目前能实际跑通的方案大概分三类，我按亲测体验从重到轻排个序：

我个人的推荐是：如果你想把text-to-cad真正用进工作流，优先选基于CadQuery或FreeCAD的本地方案。为什么？因为只有本地方案你能看到生成的“中间代码”，能改，能调试，能融入你已有的项目管理流程。SaaS虽然快，但往往是个黑盒，出了问题你完全不知道它怎么“想”的。而且商业平台的数据合规问题，机械行业的朋友应该都懂——图纸往外传是大事，慎之又慎。

2.4 方案选型背后的“为什么”：为什么是CadQuery不是打字给SolidWorks

很多人会问：既然SolidWorks也有API，为什么不直接给SolidWorks写脚本？答案是SolidWorks的API学习成本太高了，而且它没有一个“中间语言”的概念。CadQuery不一样，它用的是Python，代码就是模型，模型就是代码，天生适合做大模型生成的载体。

CadQuery的核心思想是“用代码描述建模过程”，而不是“用代码控制软件界面”。你在CadQuery里写一个box，它直接用OCCT内核（和FreeCAD同一个内核）生成实体，不需要先打开软件、新建零件、进入草图、画矩形、拉伸——省掉了所有GUI层的开销，干净利落。

更重要的是，CadQuery生成的模型天然带有参数化能力。你把尺寸写成变量，改一个数字，整个模型跟着变。这点对text-to-cad来说简直是量身定做：大模型生成代码时只要把尺寸值输出为变量，后续就能做参数扫描、尺寸优化，甚至接进拓扑优化流程。

用个生活化的类比：传统CAD建模是你去餐馆点菜，跟服务员说半天，人家给你端一道菜；CadQuery是你直接拿到菜谱，自己照方抓药；text-to-cad + CadQuery是——你跟AI描述想吃啥，AI帮你把菜谱写出来，你再照着做。你看，主动权永远在你这儿。

3. 核心细节与实操要点：从零开始跑通text-to-cad

3.1 环境准备：别在这步翻车

先说环境，这步看似简单，实际翻车概率最高。我建议按下面的顺序装，别乱折腾。以下操作在Windows 11和Ubuntu 22.04上都验证过。

先装Python 3.10或3.11，别用3.12，有些库还没跟上。然后创建虚拟环境，别嫌麻烦，直接全局装库后面有你哭的时候。

python -m venv cad_env cd cad_env # Windows下激活 Scripts\activate # Linux/Mac下激活 source bin/activate

接下来安装核心依赖：

pip install cadquery pip install freecad pip install openai # 或其他大模型SDK

这里有个细节需要注意：cadquery和freecad同时装，可能会让你脑袋冒烟——两边都用OCCT内核，但版本可能不同，一冲突就报一堆莫名其妙的内存错误。我踩过这个坑，解决方案是分开装两个环境，一个专门跑CadQuery，一个专门跑FreeCAD，中间用STEP文件交换。说白了，就像厨房里切菜板和砧板分开，避免串味。

如果你要用本地大模型（后面细说），还需要装Ollama或者LM Studio。我个人推荐Ollama，轻量、命令简单、模型管理省心。

pip install ollama ollama pull qwen2.5-coder:7b # 看情况选模型

关于模型选择，我多聊两句。做text-to-cad，核心任务是生成结构化代码，不是写散文。所以选模型要选代码能力强的，而不是“聊天感觉好的”。实测下来，Qwen2.5-Coder系列在中文自然语言转CadQuery代码这件事上，表现相当不错；CodeLlama也能凑合，但中文理解稍弱；GPT-4级别的模型当然更省心，但很多场景不允许传数据。还有个折中方案：用本地小模型做初筛和参数抽取，再用云端API做代码生成，兼顾安全性和效果。

3.2 输入输出格式设计：让模型“稳定发挥”的关键

很多人第一次跑text-to-cad，觉得“丢一句话给大模型，它就能输出代码”。想法美好，现实骨感。直接丢自然语言给模型，输出不是格式混乱，就是参数缺失，甚至拿幻觉代码糊弄你。这里的关键是你得在输入和输出两端做约束。

输入端：给模型一个“需求模板”

我的做法是让用户（或我自己）先填一个结构化描述，再拼接成prompt。比如：

你是一个专业的机械设计工程师，负责根据自然语言描述编写CadQuery Python代码。 请提取以下信息： - 基础几何：形状类型/主体结构 - 尺寸参数：长宽高/直径/厚度等 - 特征操作：孔/倒角/切除/阵列 - 位置关系：特征的相对位置 - 单位：默认毫米 自然语言描述： {用户输入}

这样做的原因很简单：让大模型从“自由发挥”变成“模板填表”，它的稳定性会大幅提升。你越给它自由，它越给你惊喜（负面意义上的）。

输出端：要求严格的代码格式

在prompt里还要加一段输出格式约束：

请以以下格式输出，不要输出多余解释： ```python # 生成的CadQuery模型代码 import cadquery as cq ... cq.exporters.export(result, "output.step")

实测下来，加了这段约束以后，代码可用率从四成直接提到八成以上。一句话总结：**给大模型画好跑道，它才跑得直。** ### 3.3 核心代码走读：看懂生成的模型代码在干什么 下面展示一段我实际跑通的示例。需求很简单：“一块长100mm、宽60mm、厚10mm的铝合金安装板，四角各一个直径8mm的安装孔，孔中心距长边边缘10mm。” 这是我配置好的text-to-cad系统生成的结果（经过我少量微调）： ```python import cadquery as cq # 定义参数，方便后续修改 length = 100.0 width = 60.0 thickness = 10.0 hole_dia = 8.0 hole_margin = 10.0 hole_radius = hole_dia / 2 # 创建基础板 result = ( cq.Workplane("XY") .box(length, width, thickness) .edges("|Z") .fillet(3.0) # 给四条竖边倒个小圆角，安全 ) # 在四个角打安装孔 for sign_x in (-1, 1): for sign_y in (-1, 1): x = sign_x * (length / 2 - hole_margin) y = sign_y * (width / 2 - hole_margin) result = ( result .faces(">Z") .workplane() .center(x, y) .hole(hole_dia) ) # 导出STEP文件 cq.exporters.export(result, "mounting_plate.step") # 也可以导出为SVG预览图 cq.exporters.export(result, "mounting_plate.svg")

这段代码看起来很简洁，但信息量不小。我拆开讲几个关键点：

第一，.edges("|Z")这个选择器表示“平行于Z轴的边”，也就是那四条竖直棱边。加fillet是为了去毛刺，工程上很常见，但也说明模型“理解”了这是一个实际加工的零件，而不是一个几何玩具。

第二，faces(">Z")表示Z轴正方向的顶面。在顶面上用.workplane()创建一个新的工作平面，再用.center(x, y)把工作平面的原点移到孔的位置，最后.hole(hole_dia)打孔。这就是CadQuery的“工作平面”思想——每一步都是在一个平面上做二维操作，然后应用三维特征，跟你在SolidWorks里选面、建草图、拉伸切除是完全相同的逻辑。

第三，四角打孔用了一个双重循环。这里如果直接用CAD的“草图阵列”功能当然也行，但用代码的好处是——下次你想改成六个孔、八个孔，甚至非对称分布，只需要改循环逻辑，不需要在GUI里重新编辑草图阵列参数。这就是代码建模的可维护性优势。

你可能会问：这跟“直接手写代码建模”有什么区别？区别在于——代码是AI帮你写出来的。你只需要描述需求，AI负责把这个需求翻译成上面这段逻辑清晰、参数明确的代码。这对于不熟悉CadQuery API的工程师来说，省去了查文档、试错的大量时间。

3.4 参数化模型的精髓：一个变量改变整个设计

前面那段代码，最有价值的其实是顶部那六个变量。一旦你写明了这些变量，就相当于给这个模型装上了“调节旋钮”。

比如客户说“厚度改到12mm”，你只需要改thickness = 12.0，重新跑一遍脚本，新的STEP文件就出来了。再比如“孔改到10mm”，改hole_dia = 10.0就行。整个过程不需要打开任何CAD软件，不需要重新约束草图，不需要检查有没有过定义。这是text-to-cad + CadQuery组合最爽的时刻。

更进一步，你可以把这段代码封装成一个函数，批量生成不同尺寸的零件。比如做一个货架上的层板，长度有五种规格、宽度有三种规格，直接用双层循环生成15个模型文件，几十秒搞定。这在传统CAD里简直不敢想。

def generate_plate(length, width, thickness, hole_dia=8.0): # ... 上面那段逻辑 return result for L in [80, 100, 120, 140, 160]: for W in [40, 50, 60]: plate = generate_plate(L, W, 12.0) cq.exporters.export(plate, f"plate_{L}x{W}.step")

这就是我常跟朋友说的“参数化思维”：把几何变成公式，把模型变成函数。text-to-cad让你更快地走到这一步，因为你连“写代码”这件事都被AI代劳了一大部分。

4. 实操过程与核心环节实现：一个完整案例的全记录

4.1 案例需求与设计拆解

光说不练假把式，我把一个我真实做过的案子完整走一遍。需求是做一个“小型电机安装支架”，是我给朋友一个小设备设计的。

自然语言描述如下：

需要一个电机安装支架，用于固定一个直径80mm的圆形电机法兰。支架主体是一块L型钢板，立面板和底板厚度都是8mm。立面板高度120mm，宽度100mm，中心有一个直径80mm的圆形通孔，周围均布四个直径6.5mm的螺钉孔，孔中心距圆心半径55mm。底板长度120mm，宽度100mm，底板上有两个长圆槽，用于安装时调整前后位置，槽宽8mm，长度40mm，两个槽中心距60mm。

如果按传统CAD流程，这个零件在SolidWorks里大概要画三四个草图、做两三个拉伸切除、再打若干孔，熟练工也得十几分钟。用text-to-cad的思路，我们先把这段话交给大模型解析，拿到下面的结构化参数：

光这一步，就已经体现出text-to-cad的威力：原本需要人边看图边从脑内转译的信息，现在被显式地列成了表格，检查起来一目了然。大模型在这里的角色不是“凭空设计”，而是“翻译整理”，所以准确性大幅提高。

4.2 生成CadQuery代码并逐步执行

解析完成之后，大模型给出第一版代码。我实际测试时，它不是一次就写对的，但整体结构基本靠谱。我把它整理后贴在下面，方便你复现。

import cadquery as cq # 参数定义 t = 8.0 # 板厚 height = 120.0 # 立板高度 width = 100.0 # 立板宽度 base_length = 120.0 # 底板长度 base_width = 100.0 # 底板宽度 motor_hole_d = 80.0 screw_hole_d = 6.5 screw_pitch_r = 55.0 slot_w = 8.0 slot_len = 40.0 slot_spacing = 60.0 # 创建L型支架主体 # 方法：先创建立板，再叠加底板，最后合并 mounting_plate = cq.Workplane("XY").box(width, base_width, t) # 底板 vertical_plate = ( cq.Workplane("XZ") .center(-width / 2, 0) .box(width, height, t) ) # 平移到正确位置，让立板立在底板上 vertical_plate = vertical_plate.translate((0, base_width / 2 - t / 2, height / 2)) # 合并成一个实体 bracket = mounting_plate.union(vertical_plate)

看到这里不知道你有没有察觉一个细节：我在构造L型支架时，用了“创建两个板 -> 合并”的方式，而不是“一次草图拉伸L型截面”。这两种方式都能得到结果，但在参数化修改时差异巨大——分别建板再合并，改底板宽度不会影响立板高度，逻辑更解耦；一步草图拉伸则比较适合截面形状固定的情况。这个取舍属于工程经验，不是大模型能“悟”出来的，需要你来把握。

接下来做立板上的孔：

# 在立板上打电机孔 bracket = ( bracket .faces(">Z") # 立板的正面,因为立板经translate后Z正方向朝外 .workplane() .hole(motor_hole_d) ) # 四颗螺钉孔，均布在半径55mm的圆上 import math for angle in [45, 135, 225, 315]: rad = math.radians(angle) x = screw_pitch_r * math.cos(rad) y = screw_pitch_r * math.sin(rad) bracket = ( bracket .faces(">Z") .workplane() .center(x, y) .hole(screw_hole_d) )

这里有个容易搞错的地方：我们选择faces(">Z")来定位立板表面，是因为立板经过平移后Z方向朝向变成了朝外。如果你不熟悉这个选择器的方向语义，很容易把孔打到板侧面去。我的经验是：每次调用.faces()之后，先用.val().Center()打印一下面的中心点坐标，确认位置对了再做特征。debugging的成本比瞎猜低多了。

然后是底板上的长圆槽：

# 在底板上开两条长圆槽 for offset_x in (-slot_spacing / 2, slot_spacing / 2): slot_center_x = offset_x # 长圆槽本质 = 两端半圆 + 中间矩形 slot = ( cq.Workplane("XY") .center(slot_center_x, 0) .slot2D(slot_len, slot_w) # CadQuery自带长圆孔2D方法 .extrude(t) ) bracket = bracket.cut(slot)

CadQuery内置了.slot2D()方法，专门生成椭圆形长槽轮廓，再简单拉伸一下，用于cut减去实体就能得到腰形孔。这个API设计得相当贴心，否则你得自己用“两半圆弧加两条直线”凑轮廓，麻烦得多。这就是为什么我推荐CadQuery而不是纯手撸OCCT——好的库就是让你少写一半代码。

最后导出：

cq.exporters.export(bracket, "motor_mount.step") cq.exporters.export(bracket, "motor_mount.svg")

4.3 执行结果检查：尺寸对不对、特征对不对

代码跑完后，千万别急着上机床，先做两道检查。

第一道是看文件能不能被FreeCAD或你的主力CAD软件正常打开。STEP文件被打开后，先看特征树，确认是实体而不是网格；再量几个关键尺寸，比如立板厚度、孔直径，确保和设计值一致。

第二道是把SVG预览图打开看一眼。SVG是平面投影，但足以发现孔位是否偏了、L型方向是否正确。我那次测试，第一版生成的孔位其实偏了一个角度，原因是我用math.cos/sin计算孔位时角度基数不同——这属于典型的“上下文误解”。大模型默认45度是相对圆心的，但实际我想要的均布孔第一颗应该在正上方。这种问题用预览图一眼就能发现。

检查完毕后，再把这个STEP文件导入到FreeCAD里做标注和出图，流程就闭环了。从输入需求到拿到可标注的模型，我实测整个流程大约三分钟，其中大部分时间是在检查修正，真正的“生成”只需几秒。作为对比，手动在SolidWorks里建这个支架，加上草图和工程图，至少半小时起步。这就是text-to-cad目前最实在的价值：把前期的框定和初稿阶段压缩到分钟级。

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

5.1 尺寸单位混乱：你以为是毫米，它以为是英寸

最经典的问题。大模型生成的代码里，如果没有显式标注单位，它可能会默认英制单位。你要求“板厚8mm”，它生成一个t = 0.315（英寸），STEP文件打开一看，整个零件小得可怜。

排查方法：生成代码后立刻检查数值量级，凡是“长度值出现在1到100之间且没有小数点”的，大概率是毫米量级没问题；如果出现0.1、0.01这种值，就得怀疑单位出了问题。

解决办法：在prompt里强制加一句“所有尺寸均以毫米为单位，长度大于0.5且小于2000”。实测下来，这句话能显著降低单位错误的概率。

5.2 特征选择错误：孔打到了对面或侧面

我们在前文已经说过faces(">Z")这个选择器的方向语义问题。这个问题在初次使用text-to-cad时几乎没有例外地会出现一次。症状五花八门：孔穿透了不该穿透的面、倒角出现在了不该倒角的边、拉伸的方向反了。

排查方法：用SVG输出加FreeCAD检查双重判断。SVG让你快速看到平面分布，FreeCAD让你看三维走向。关键词是“快速”——不要一上来就转到SolidWorks细看，那个启动就够你喝一壶的。

预防策略：如果你发现系统生成的孔位常常打偏，就在prompt里要求“孔的位置必须基于某个已有面或基准，请先输出面选择的逻辑”，让大模型把“选哪个面”这一步显式写出来，而不是藏在代码里。

5.3 代码能跑但几何不对：有些错误不报异常

这种情况最阴险——程序不报错，模型也能导出，但几何形状和意图完全对不上。比如“带孔的法兰盘”生成出来是一个实心圆柱加一个细细的圆环，看起来像飞碟。原因是模型把“打孔”理解成了“加一个环形凸台”。

这种问题的根源在于大模型对“布尔运算”的理解不够扎实。它知道union（合并）和cut（减去）这两个词，但有时候会搞反。我在调试时遇到过它用.union()代替.cut()的案例，模型直接从“体内挖洞”变成了“长出蘑菇”。

排查办法：把生成的模型切一刀，看剖面图。剖面图是检查内部结构的利器，孔有没有贯穿、有没有多余材料，一目了然。CadQuery里可以用.section()方法配合SVG导出查看截面。

建议：在prompt里加一条“如果描述中出现孔/槽/腔等减材特征，必须使用cut操作；如果出现凸台/加强筋/筋板等增材特征，必须使用union操作。请逐一核对。”

5.4 更大的模型不代表更好的结果

这一条我反复跟朋友强调。很多人一上来就堆参数，用70B的本地模型，或者直接上最强云端API，觉得模型越强生成越准。实测下来，对于“自然语言转结构化CAD代码”这个特定任务，中等级别的模型已经够用，关键是prompt够不够结构化。

我在Qwen2.5-Coder-7B上跑通了很多次，而有些人用GPT-4还经常翻车，原因不是模型不行，而是他们直接丢一句话然后期望完美输出。所以我的建议是：先把prompt工程做好，再去升级模型。结构化prompt + 7B模型 = 可用；随意prompt + 70B模型 = 碰运气。性价比永远是前一条路划算。

5.5 性能问题：代码能跑但特别慢

当模型变大、场景变复杂，生成速度会从秒级退到分钟级，容易让人以为死机了。实际上是大模型在做“长链推理”——它得想清楚整个建模步骤再一次性输出。这在复杂零件设计时是正常的。

我的经验是设置一个超时上限（比如4分钟）。如果超时了，基本证明这个任务对大模型来说太复杂了，不要傻等。正确的做法是把需求拆成两步：先让模型生成“零件主体”，再单独生成“孔特征”，最后手动合并。别小看这一步，很多看似无从下手的复杂零件，拆成简单几何之后，text-to-cad的稳定性会回来一大截。

5.6 常见问题速查表

6. 经验心得与下一步扩展建议

6.1 实测后的一些真实感受

先把话说清楚：现在text-to-cad还不能完全替代传统CAD建模，但它在“方案初稿”这个环节的价值已经被我充分验证。我在设计某些非标支架、过渡板、外壳开孔这类零件时，已经形成了“自然语言描述 -> 生成代码 -> 检查修改 -> 导出工程图”的固定工作流。整个链条中，最耗时的环节已经从前期的“建模”转移到了“需求梳理”和“检查修正”——这其实是好事，因为这两个环节本来就是人该做的，机器做不了的。

另外一个感受是：text-to-cad用起来有点像一个“实习生”。你给的需求越清晰，它的表现就越稳定；你丢给它一个模糊的说法，它就给你一个让你哭笑不得的结果。所以与其说这是AI的能力边界，不如说这是对工程师“表达能力”的筛选。能把需求说清楚的人，用起来事半功倍。

6.2 给刚上手的人三个实用建议

第一，别追求一步到位。刚开始先让它生成简单的box加hole，跑通整个链路；再逐步加倒角、阵列、凹凸特征；最后再挑战L型支架这种多实体组合的零件。每次只改一个变量，出了错也知道是哪里改出来的。

第二，模板先行。给自己准备一套工程化的prompt模板，封装好输入输出格式。不要每次临时写prompt，那样你会被模型的随机性折磨到崩溃。固定格式、固定要求、固定检查项，把“玄学”变成“流程”。

第三，保存优秀案例。text-to-cad模型虽然每次都从零生成，但你可以攒一批“代码模板库”，把生成得好的CadQuery代码保存下来。以后遇到同类需求，直接改参数，连跑大模型这一步都省了。大概攒二十个常用模板之后，我就不怎么依赖大模型了，因为常见零件早就覆盖完了。

6.3 这个方向后续还能怎么玩

我个人觉得，text-to-cad下一步最值得挖掘的方向是“倒过来用”：从现有CAD模型的反向工程中提取参数化逻辑，然后生成自然语言描述。这样就能建立一个“双向翻译”的闭环——你可以问“这个法兰盘孔距是多少”“这个支架能不能承重50kg”，系统先从模型里读懂几何，再用语言回答你。这个能力对图纸管理、零件检索、跨团队沟通都有非常大的价值。

另一个有意思的方向是把text-to-cad和仿真联动。既然模型是参数化的，就能批量改尺寸看应力变化；如果生成代码时顺带生成边界条件，理论上可以自动做一轮轻量化的结构优化。这个想法我还在探索中，但已经摸到一些门道，等做成型了再来细聊。

最后再分享一个小技巧：在CadQuery里加.export("preview.svg", opt={...})时，可以指定视角方向。如果你发现生成模型的孔位分布看不清，试试把投影方向从俯视图改成等轴测视图，问题往往一眼就暴露。这个小功能帮我在检查复杂零件时省掉了大量来回切换视角的时间。