1. 从一句话到一块零件text-to-cad到底在解决什么问题先聊点实在的。过去十年CAD圈子最大的变化不是某个命令多了新功能而是“建模的入口”正在从鼠标键盘逐步转向自然语言。早期我们用命令行后来用参数化草图和脚本现在你直接敲一句“一个带四个安装孔、直径120mm的法兰盘孔距85mm”系统就能给你生成一个可编辑的CAD模型。这就是text-to-cad。这个概念听起来像科幻其实底层逻辑并不玄乎把人类描述三维物体的语言映射成CAD内核里的几何操作序列。它不是简单地从素材库“搜”一个模型出来而是真正“生成”一个带完整特征树、参数可改、能进CAM流程的实体模型。这个区别非常关键——搜到的是别人的零件生成的是你自己的零件。这件事解决了什么痛点我自己的体会是三个把“脑子里想的”变成“图纸上有的”这一步卡住了太多人。不是每个人都会熟练操作草图、拉伸、倒角但几乎每个人都能说清楚“我要一个什么样的东西”。text-to-cad把“会说”变成了一种建模能力。重复性标准件设计效率极低。法兰、支架、外壳、卡扣这些零件结构相似但尺寸各异每次都得重新画一遍草图、重新约束、重新倒角。用自然语言描述尺寸和特征生成一次后续改参数就行。跨工种沟通成本高。结构工程师提需求机械工程师建模中间往往要反复确认。text-to-cad可以把“需求描述”直接转成“初步模型”省掉一轮又一轮的“这里再大一点、那里再加个孔”的拉锯。适合谁看如果你刚开始接触CAD想知道自然语言建模到底怎么落地或者你已经在用SolidWorks、Fusion 360、FreeCAD这类工具想试试新的工作流再或者你纯粹好奇AI辅助设计能做到什么程度——这篇内容都值得你花几分钟读完。我会把原理、工具选型、实际跑通的流程、以及我踩过的坑都摊开讲。2. text-to-cad的整体设计思路它到底是怎么“懂”你的话的2.1 一句话到模型的链路拆解先给一个整体的架构认知免得后面越看越乱。从我测试过的几套开源和商业方案来看text-to-cad的系统链路大致是这么走的自然语言输入 - 意图解析与参数抽取 - 几何约束构建 - 特征操作序列生成 - CAD内核建模 - 生成可编辑模型文件用大白话讲就是四个步骤听懂把“我要一个直径50mm的圆柱体高度80mm顶部带一个直径10mm的通孔”拆成“圆柱体”“直径50”“高度80”“顶部通孔”“直径10”这些关键要素。这里用到的是大语言模型的基础能力核心是实体抽取和关系识别。如果你用过ChatGPT应该对这类“提取关键词”的能力不陌生。翻译把上面抽出来的参数和关系翻译成CAD建模的操作步骤。这一步最关键也最容易出错。比如“顶部带孔”是指孔的轴线与圆柱轴线重合还是孔在圆柱顶面偏心系统需要结合常识推断或者直接向你确认。有的方案会生成中间代码类似伪代码或者python脚本方便你检查修改。执行调用CAD内核的API顺序执行这些操作。什么样的操作建草图、加约束、拉伸、旋转切除、打孔、倒角跟你在软件里手动点按钮做的事情是一模一样的只不过变成了程序化的调用。产出最终生成带参数化特征的模型文件通常是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 技术选型我试过的几类方案对比目前能实际跑通的方案大概分三类我按亲测体验从重到轻排个序方案输出类型可编辑性部署难度适合场景FreeCAD 本地大模型 脚本引擎参数化FCStd文件好完整特征树高需要配置环境专业设计、需要深度定制的场景商业SaaS的text-to-cad接口参数化文件或云端模型中等偏上取决于平台低开箱即用快速出初稿、跨工具协作云端API OpenSCAD/CadQuery代码生成代码定义的参数化模型好本质是源码中需要懂代码程序员友好的建模场景我个人的推荐是如果你想把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-cad3.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_dia8.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, fplate_{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的思路我们先把这段话交给大模型解析拿到下面的结构化参数参数组参数名值立板高度120mm立板宽度100mm立板厚度8mm电机孔直径80mm螺钉孔直径6.5mm螺钉孔分布半径55mm螺钉孔数量4个底板长120mm底板宽100mm底板厚8mm长圆槽宽8mm长圆槽长40mm长圆槽中心距60mm光这一步就已经体现出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 常见问题速查表问题典型症状快速处理单位错误模型尺寸整体异常小/大检查数值量级prompt强制声明毫米单位布尔运算颠倒孔变成凸台、实体多出一块检查union/cut是否对应增材/减材要求模型逐条核对面选择错误特征出现在错误的面或方向利用faces选择器的方向语义先生成预览SVG观察模型不完整只出现部分特征拆分子任务先主体后特征生成超时长时间无响应设置超时上限拆解需求换更小模型代码语法错误Python报错检查库版本确认cadquery已安装且环境正确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{...})时可以指定视角方向。如果你发现生成模型的孔位分布看不清试试把投影方向从俯视图改成等轴测视图问题往往一眼就暴露。这个小功能帮我在检查复杂零件时省掉了大量来回切换视角的时间。