从自然语言到CAD模型：text-to-cad技术原理与实战解析

最近几个月，text-to-cad这个方向在设计和制造圈子里热度涨得很快。简单说，就是你输入一句话，比如“一个带圆形散热孔的外壳，底部有四个M3安装孔”，AI帮你把对应的CAD模型直接生成出来，而不是传统的从零开始建模。不少做结构设计的朋友问我这东西到底靠不靠谱、能不能拿来干活。我前后捣鼓了几个月，跑了不少开源项目，也对比了几个商业化方案，今天干脆把整个理解、实测过程、踩过的坑一次性写清楚。

text-to-cad本质上是把自然语言变成参数化三维模型的一条技术路径，目前主流实现方式包括大语言模型直接生成建模脚本、多模态模型预测体素或隐式场、以及LLM配合3D引擎做迭代优化等。无论走哪条路线，核心目标都是降低建模门槛、缩短从想法到实物的时间。这篇文章适合结构设计、产品开发、机械工程、3D打印爱好者，以及做AI应用集成的开发者参考。我会把技术原理、工具选型、实操步骤和常见坑都梳理一遍，尽量做到既能让你看懂原理，也能照着一步步复现。

1. text-to-cad的核心价值与整体设计思路

1.1 一句话理解text-to-cad：从“动手画”到“说给机器听”

先说清楚这个概念。text-to-cad，字面看是“文本到CAD”，实际上完成的是从自然语言指令到参数化几何模型的转换。我之前理解这东西就是把CAD软件加个语音输入，后来实测了才发现完全不是一回事。

传统CAD建模的逻辑是“人操作软件”，无论是拉伸、旋转、扫描还是放样，每一步都是人通过鼠标键盘告诉软件“下一步做什么”。而text-to-cad的逻辑是“人告诉AI想要什么”，AI负责把需求拆解成具体的建模操作序列，再执行出来。两者最大的差异在于：后者把“把想法转成操作”这一层中间劳动拿掉了，设计者直接面对的是最终结果，不满意再让AI改。

举个例子。我要设计一个电机支架，传统做法是画轮廓、拉伸、开孔、倒角、加筋板，每一步都要自己操作，熟练工也要十几分钟。如果用text-to-cad，那就是一句话：“一个L型电机支架，长80mm，宽60mm，高40mm，厚度3mm，底部两个直径5mm安装孔，顶部一侧有半圆形散热槽。”AI生成脚本，渲染出来，你觉得孔位不对，再加一句“孔距改为50mm”，改完再看。整个过程可能五分钟不到，大部分时间花在确认和微调上。

这个转变不只是效率提升，更是建模方式的范式变化。以前设计一个零件，脑子里要先想好“我要分几步建模”；现在只需要想清楚“我要什么”。对于没有系统学过三维建模的人，这几乎是唯一一条快速上手做设计的路。

1.2 为什么text-to-cad现在才被广泛关注

这个方向其实不是今年才有的。早几年大家就在研究如何用文字控制建模，比如Autodesk很早就做过类似的demo，但当时效果非常差，只能识别极其简单的指令，比如“画一个盒子和一个圆柱”，生成的模型只能用“粗糙”形容。

现在突然火起来，我分析有三个推动力。

第一个是大语言模型能力的跃迁。ChatGPT这类模型天然擅长代码生成，而CAD建模脚本（比如OpenSCAD、CadQuery）本质上就是程序化描述几何体。模型把“长80mm宽60mm高40mm”转成对应的建模代码，这个活儿大模型做得相当不错。以前需要训练专门的神经网络来理解几何语义，现在一个预训练大模型直接就能干。

第二个是参数化建模脚本的成熟。OpenSCAD、CadQuery这些工具虽然出现多年，但一直偏小众，用的人不多。它们的特点是：模型完全由代码定义，这意味着AI生成的结果可以直接被版本管理、参数化修改、批量复用。text-to-cad接上这类工具后，生成的不只是一个“死模型”，而是一棵可编辑的建模树，这恰恰是工业设计最需要的。

第三个是3D打印和数字制造的普及。越来越多非专业人士拥有3D打印机，他们需要快速生成可打印的模型。花几周学三维建模对很多人来说门槛太高，但输入文字描述、拿到可打印模型，这个流程友好太多了。

不过说句大实话，现阶段text-to-cad距离“替代设计师”还很远。它的定位更像是一个“高理解能力的建模助手”，能加速从概念到初稿的过程，但精细设计、装配设计、工程分析这块还需要人来做。

1.3 这个技术到底适合谁用

我在实际测试和社区交流中，把text-to-cad的适用人群分成了三类。

第一类是产品设计师和结构工程师，他们的价值在于快速做概念验证和方案对比。设计早期需要大量探索不同形态，用text-to-cad生成基础形态，再导入传统CAD软件细化，能明显压缩前期草图阶段的时间。

第二类是3D打印个人玩家和创客。他们往往有了一个明确的使用需求，比如“给遥控器做一个壁挂支架”或者“做一个能卡住桌沿的理线夹”，需要的是快速得到一个能打印的模型，而不是学习完整建模流程。

第三类是AI应用开发者和研究者。他们关注的是这个技术本身，比如如何设计更优的生成策略、如何构造数据集、如何把text-to-cad集成到自家产品里，这类人更关心技术栈和接口。

我自己测试下来的感受是：第一类用户收获最大，因为被text-to-cad省掉的恰恰是最重复的那部分操作；第三类用户需要耐心，因为目前的工具链还有不少毛边；第二类用户能不能玩转，很大程度上取决于提示词写得好不好，这个后面详细讲。

2. 核心细节解析与主流技术路径

2.1 技术路线一：大语言模型直接生成建模脚本

目前实用程度最高的路线，也是最容易上手理解的路线。核心逻辑是：把CAD模型用代码表示，让大语言模型去写这段代码。

建模脚本领域有两个主流工具，一个是OpenSCAD，语法类似C语言，用基础几何体做并集、差集、交集运算；另一个是CadQuery，基于Python，用类似CAD软件的“构建历史”思维来建模型，比如你画一个草图，然后拉伸到某个高度，再指定一个面打孔。

大语言模型为什么在这个场景里表现好？因为它不止理解几何，还理解语言和代码之间的映射关系。你说“圆柱体套在长方体上面形成蘑菇形状”，模型能推断出“把两个几何体做叠加”以及代码层面该怎么表达。实测下来，GPT-4级别及以上的模型写CadQuery代码的成功率已经比较高了，简单零件一次生成能跑通的概率在六成以上。

举个例子，我让模型生成一个“带通孔的立方体”，模型给出的CadQuery代码大概长这样：

import cadquery as cq result = ( cq.Workplane("XY") .box(50, 50, 10) .faces(">Z") .workplane() .hole(20) )

看到没，这就是“50x50x10的立方体，顶面上打一个直径20的通孔”的代码。如果让模型生成一个更复杂的零件，比如带阵列孔的法兰盘，它也能写，只不过出错率会上升，需要调优。

这条路线最大的优势是结果天然是参数化的。孔的位置、大小、板厚都可以通过修改代码里的数字来调整，非常适合需要反复修改的设计场景。缺点则是对模型能力要求高，且需要你对代码有一定的理解能力，否则模型生成的代码报错时，你根本不知道该从哪里下手。

2.2 技术路线二：多模态模型直接预测几何结构

这条路线的思路更“AI原生”：直接把文本描述和三维几何数据放在一起训练，让模型学会从文本直接输出一个三维模型，通常表示成体素网格、点云或者隐式符号距离场（SDF）。

典型代表是OpenAI早期的Point-E、Shap-E，以及后来的各种文本生成3D模型项目，比如Magic3D、DreamFusion这类。它们的输入是一句话，输出是一个网格模型文件，中间不需要任何代码或者CAD操作。

听上去很理想，对吧？实测下来，这类模型生成的模型有两个问题。

第一是几何精度差。生成的东西看起来像模像样，但仔细量尺寸、检查配合面，基本都不能直接用。因为这类模型本质上是“以图像方式理解三维”，它学到的更多是形状轮廓，而不是精确的尺寸约束和拓扑关系。比如你要求“两个直径完全相同的通孔，间距20mm”，它可能给你生成一个差不多形状但孔的大小不一致的东西。

第二是模型文件质量低。直接输出的网格模型往往有大量噪声、孔洞、非流形边，导入CAD软件后需要大量修复工作，更别提放到CNC或3D打印流程里。从工业角度来说，这个路线距离实用化还差得远。

不过，在一些对精度要求低的场景，比如游戏资产、概念展示、艺术设计，这个路线还是很有价值的。只能说“不是同一个赛道”。

2.3 技术路线三：LLM + 3D引擎的迭代优化闭环

这是目前包括我自己在内，觉得最有工业潜力的一条路。它不指望一次性生成完美的模型，而是让大语言模型通过多轮迭代逐步逼近目标。

具体流程是：用户输入描述，模型先根据描述生成一个初始模型（往往通过生成代码的方式），然后让这个模型进入一个“渲染-评估-改进”的闭环。比如用一个自动渲染器把模型渲染成多角度视图，再用视觉模型检查是否符合文本描述，如果不符合，就反馈给LLM，让LLM修改代码，再重新渲染，反复循环直到满足要求。

我在实测中遇到过一个典型案例——我让它生成“一个六边形法兰，中间一个大孔，周围六个小孔均匀分布”。第一次生成的代码里，六个小孔是直线排列而不是均匀分布在法兰面上。系统渲染后检测到“孔的位置分布不符合环形均匀”，反馈给模型，第二次就纠正成了正六边形分布。这就是闭环迭代的力量。

这个方案里，反馈机制的设计是核心。什么算“符合要求”？如果仅限于渲染图像层面的检查，那模型可能只学到了像素级相似，几何层面还是不对。目前业界在探索的方式包括：渲染成多视图后做2D视觉检查、直接对3D网格做拓扑分析、甚至用物理引擎做基础干涉检查。越接近后端检查，效果越扎实，但工程复杂度也越高。

这条路径最接近“AI自主设计”的形态，但当前落地难点在于：每一轮迭代都要消耗大量算力和API调用，成本不低；反馈机制设计不好，反而会越改越乱。

2.4 数据集：被大多数人低估的关键环节

不管哪条技术路线，都离不开数据。text-to-cad模型的训练数据非常关键，也很稀缺。

理想的训练数据是什么？是大量“自然语言描述 + 对应的参数化建模代码”的配对。问题是，工业界的CAD模型大多不是参数化脚本保存的，而是STEP、IGES这种几何交换文件，丢失了建模历史树。这意味着即使我们拿到海量工业模型，也无法直接从它们得到训练所需的目标代码。

目前主流的数据集和造数方式大概有几种。一是利用已有的开源CAD模型库（比如GitHub上大量OpenSCAD和CadQuery项目），提取代码和注释配对训练。二是用合成数据方式，先写脚本随机生成大量参数化模型，再反向生成文本描述。三是集合人工标注，雇佣设计师给模型写描述，成本高但质量最好。

我见过不少个人开发者和研究团队，最后都卡在数据这一环。模型结构可以抄，训练代码可以借鉴，但数据没法凭空变出来。这就是为什么好几个text-to-cad开源项目在发布demo之后，后续迭代变慢了——因为他们的标注数据用完了。

3. 实操全流程：从零完成一个text-to-cad项目

3.1 环境准备：工具链选型

说完了原理，聊聊实际操作。我假设读者是打算自己动手试一试。以当前生态最完整的开源方案来说，我推荐的基础工具链是：

• Python 3.10+：主流text-to-cad项目的运行环境
• CadQuery：生成参数化模型的核心库，用Python语法建模
• OpenSCAD：备选方案，适合喜欢C风格语法的朋友
• Jupyter Notebook：快速交互试错的编辑器
• 大模型API或本地部署的模型：比如GPT-4系列或开源的Llama 3系列
• MeshLab或FreeCAD：用于检查和修复生成的模型文件

我自己的跑通路径是先安装CadQuery。安装直接用pip：

pip install cadquery

如果遇到依赖问题，建议用conda创建虚拟环境：

conda create -n text2cad python=3.10 conda activate text2cad pip install cadquery

然后安装一个大模型的SDK，我用的主要是OpenAI的库。最低成本的做法是找一个支持代码生成的开放模型，用API调，避免本地部署耗费显存。

3.2 搭建一个最简单的text-to-cad调用链路

核心思路：用户输入自然语言 -> 调用LLM生成CadQuery代码 -> 执行代码生成模型 -> 渲染预览 -> 保存STEP/STL文件。

我写了一个非常精简的流水线，核心代码就几十行。第一步，构造一个prompt模板，要求LLM只输出可运行的CadQuery代码，不要多余解释：

prompt = f""" You are a CAD modeling assistant. Given a description, output CadQuery Python code that creates the model. Rules: 1. Only output the code block. 2. The code must assign the final result to a variable named `result`. 3. Use millimeters as the unit. Description: {user_description} """

第二步，把LLM返回的代码取出来，用exec执行，然后导出模型：

import cadquery as cq code = llm_response_code namespace = {} exec(code, {"cq": cq}, namespace) result = namespace["result"] cq.exporters.export(result, "output.step")

执行环境里注意要传入cq模块，否则生成的代码无法引用CadQuery。导出格式建议优先STEP，因为STEP比STL保留了更多几何拓扑信息，后续还能在FreeCAD里继续编辑。

跑通基础链路后，你会发现大多数问题都出在模型的代码生成质量上。接下来就是要针对性地调prompt。

3.3 提示词工程：文字转CAD的命门

在text-to-cad里，提示词的质量直接决定模型生成的质量，这一点怎么强调都不为过。同一个模型，用烂提示词可能啥也生成不出来，用好提示词可以稳定输出可用模型。

我在对比实验里积累了几条经验。第一，明确尺寸和单位。不要只说“一个盒子”，要说“一个长80mm、宽60mm、高40mm的矩形盒体”。因为模型默认的猜测很可能和你心里的预期完全不一样。

第二，说清楚几何关系。比如“在顶面中心打一个直径10mm的通孔”，比“顶面有个孔”要可靠得多。涉及多个特征时，明确它们之间的相对位置关系，比如“四个安装孔分别位于四个角，距边缘5mm”。

第三，用参数名和常量。让模型把关键尺寸写成变量，比如“length=80, width=60, thickness=3”，而不是直接硬编码多个地方。这样做的好处是，后续你要改动尺寸，只需要找到代码顶部的变量定义改一处即可。

我整理了一个对比示例：

• 反面例子：“design a bracket with holes”
• 正面例子：“create an L-shaped bracket, vertical arm height 60mm, horizontal arm length 80mm, width 50mm, thickness 4mm, two holes of diameter 6mm on the horizontal arm, spaced 30mm apart, centered.”

正面例子里，方向、尺寸、位置、数量、形状全部明确，模型几乎不会跑偏。

3.4 一个完整示例：从“描述一个U型槽零件”到获得STEP文件

拿一个稍复杂的例子完整走一遍。需求：一个U型槽零件，槽宽50mm，壁厚5mm，外高30mm，长度100mm，底部有一个直径8mm的排水孔。

我给LLM的描述是：“Create a U-shaped channel part. Outer width 60mm, outer height 30mm, length 100mm, wall thickness 5mm. The inner slot width is 50mm. Add a through hole of diameter 8mm at the center of the bottom face.”

模型生成的CadQuery代码大致长这样：

import cadquery as cq result = ( cq.Workplane("XY") .box(60, 100, 30) .edges("|Z") .chamfer(5) )

等等，这个明显不对，不能直接跑通。实际测试中，模型第一次生成可能直接给一个实心块，根本没有掏空成U型。这时候就需要闭环迭代或者人工干预。

我通常的做法是给prompt追加一条指令：先创建一个槽型截面，再拉伸。重新生成的代码才正确：

import cadquery as cq result = ( cq.Workplane("XY") .rect(60, 5) .center(-25, 0) .rect(50, 30) .close() .extrude(100) )

这个代码的意思是：先把U型截面的轮廓画出来（外面一个60宽5高的矩形，减去下方一个50宽30高的矩形，形成U型），然后拉伸100mm形成槽体。之后再加排水孔：

result = ( result.faces("<Y") .workplane() .hole(8) )

导出检查后，模型正确。整个过程里，模型的质量高度依赖你对细节的描述。如果你一开始就写“做个U型槽，带个排水孔”，模型十有八九会给你一个实心的或者槽壁厚度不对的东西。

3.5 工具链进阶：把迭代反馈做成自动化

如果你计划把text-to-cad集成到产品里，人工检查这一步最好能自动化。我在原型阶段实现过一个简单的评估器，思路是：对生成的模型用CadQuery自带的API提取关键特征，然后和文本描述中的约束做比对。

比如描述中明确要求“四个孔，直径6mm”，评估器就可以遍历模型的所有孔特征，统计孔的数量和直径，直接判断是否满足。如果描述中包含“轴对称”这类约束，评估器也可以从模型几何信息中提取对称性。

for face in result.faces().vals(): # 检查是否为圆形面，记录半径 if face.geomType() == "CIRCLE": circles.append(face.radius())

这个阶段不需要做多复杂的事情，先把“尺寸对不对、数量对不对”这类硬约束检查好，效果就已经比单纯靠肉眼判断强很多。等到流程更成熟了，再考虑引入图像渲染和多视角比对。

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

4.1 模型生成报错：代码能跑但结果空壳

这是我遇到频率最高的问题。LLM生成了一段CadQuery代码，语法没错，执行后也有输出，但导出的模型是个空壳，或者缺少某些特征。

排查思路很简单：不要直接看最终渲染，要看模型的构件历史。CadQuery的一个重要特点是每个操作都会记录在建模历史里，你可以逐步检查。

result = ( cq.Workplane("XY") .box(50, 50, 10) ) # 检查体积 print(result.val().Volume())

如果体积是0或者远小于预期，那说明模型可能被布尔操作减掉了。常见原因是差集操作的顺序写反了，把主体剪没了。比如想要“在板上打孔”，正确写法是先建板，再用hole操作；如果你用“板 - 圆柱”这种命令式布尔差集，往往结果正常，但如果你错误地把主体当成了要减去的部分，就会留一个空壳。

强烈建议在每次生成后都加一个体积断言，小于某个阈值就视为失败，直接触发重新生成。

4.2 单位不一致：一寸和一毫米的灾难

CAD领域的老话题，在text-to-cad场景里被无限放大。LLM训练数据里混合了英制和公制尺寸，它很可能在一个模型里混用。有一次我让它生成一个“3英寸x1英寸的固定片”，它生成出来的尺寸成了3mm x 1mm。更离谱的一次是，模型把“半径10mm”理解成了“直径10mm”，成品尺寸直接翻倍。

我的对策是：在prompt末尾强制加上unit声明，且在生成代码里要求模型用变量定义所有尺寸，方便我检查。最稳妥的做法是训练一个尺寸校验函数，读取关键参数后在服务端校验。比如我要求孔距50mm，从模型里抽出来是50英寸，那就是稀烂，直接让模型重新生成。

4.3 拓扑错误：非流形边和自相交面

这个坑主要出现在直接使用多模态生成网格模型的时候。CAD实体建模其实对拓扑一致性要求很高，必须是流形几何才能导入CAM软件做加工路径规划。如果生成的文件是非流形的，轻则开槽失败，重则直接崩溃。

遇到这种情况，我的建议是不要试图在CAD软件里手动修复——那真的花时间。直接回到生成环节，改用CadQuery这类参数化建模方式生成，因为程序化建模天然生成的实体都是流形的。如果一定要用网格模型，那就用MeshLab的修复功能自动清理一下，质量不高但能用。

4.4 语义歧义：模型理解的“上面”和你的“上面”不一样

text-to-cad最让人抓狂的问题之一，是语义理解的歧义。“上面”是相对哪个方向？“上加一个突出的圆柱”里的“上”，到底是模型的Z轴正方向，还是用户视角里的上方？“对称”是以哪个平面为对称面？“相邻”是指贴在一起还是有一定距离？

我跟不同模型测试了几十次，发现它们对方向词的理解普遍不稳定，有时候用“顶部面（top face）”这种几何语言明确指定。例如“在顶面（法线方向为Z轴正方向的面）中心加一个圆柱”，比“在上面加圆柱”的成功率高得多。

另一个好用的技巧是在prompt里引入建模坐标系的概念。写清楚“使用XY平面为底面，Z轴向上”，模型就能很好地消除方向歧义。这个方法实测非常管用，强烈推荐。

4.5 常见问题速查表

我把这段时间遇到的典型问题汇总了一下，方便你对照排查。

表格里的这些坑，基本覆盖了新手从零到能做出第一个可用模型的全部障碍。很多问题不是模型能力不够，而是你的输入信息不足。把描述写清楚，比换一个更强的模型更有效。

5. 应用场景、影响范围与下一步趋势

5.1 产品设计：从概念筛选到结构细化的加速器

text-to-cad带给产品设计最大的变化，是概念阶段的效率跃迁。以前做方案评审，需要设计团队先把几种形状的模型建出来，快则半天，慢则两天。现在用text-to-cad，团队可以第一时间把想表达的形态转化为Draft模型，即使精度不够、改起来复杂，至少能看到大致轮廓，给方案决策提供参考。

我认识一位做钣金件设计的工程师，他测试了一周后给出的评价是：“对前期形态探索帮助极大，但真正到出工程图阶段还得自己来。”我觉得这个定位很准确。text-to-cad不是让你完全失业的工具，它是把你从重复劳动里解放出来的工具，把省下来的时间投到更需要创造力的地方。

5.2 3D打印与数字制造：面向大众的设计民主化

text-to-cad对3D打印圈子的影响，可能比工业圈更深远。原因是3D打印用户的建模需求往往是一次性的、个性化的，比如“给电钻做一个桌面支架”“做一个能固定手机壳的夹具”，这些需求如果用传统建模软件学起来成本高，社交平台上大量人干脆直接求模型而不是自己建。

text-to-cad在这方面几乎是杀手级应用：你说个需求，它给你个可打印模型，你再根据自己打印机的尺寸和公差微调。我测试过在提示词里加上“考虑FDM打印公差，预留0.2mm间隙”，生成的模型确实打印后装配顺滑，这点让我非常惊喜。

要注意的是，当前模型还不擅长处理“悬垂结构”“支撑优化”等打印相关的工艺知识，所以挂载打印前建议先用切片软件预览一遍，避免生成一堆打印不出来的悬空面。

5.3 教育与学习：让建模不再卡在第一道门槛上

我自己带过几个刚入门的建模学习者，发现他们放弃的原因高度一致：界面太复杂，记不住命令位置，操作跟脑子里想的不一样。text-to-cad改变了这个入口过程。初学者可以先只学“怎么描述一个形状”，看着AI生成代码和模型，再慢慢对照学习代码和CAD操作之间的对应关系。

在学校的工程图学课程里，text-to-cad也可以作为概念演示工具，帮学生快速建立三维空间想象力——不过老实说，我不建议初学者完全依赖它，因为CAD的基本功（尺寸约束、公差、装配逻辑）还是需要亲自动手去理解。

5.4 对设计师工作流的影响：从画图到审图的转变

随着text-to-cad的成熟，一个明显趋势是设计师的工作重心在从“建模”转向“审模”。过去你的核心技能是熟练操作软件，未来你的核心能力变成了准确表达需求和判断AI输出的质量。这个转变会给行业带来一种新的能力分层。

表达能力强、空间想象力好的人，用text-to-cad的效率会远高于不擅长表达的人。相应地，传统意义上“软件操作速度”的竞争力会被削弱。对于职业设计师来说，我的建议是趁早把“需求结构化表达能力”训练起来，这将是未来最重要的专业能力之一。

5.5 技术局限与未来趋势预判

说完了优势，必须泼一盆冷水。text-to-cad目前的局限非常明显：复杂装配体生成完全不可用；形位公差、表面粗糙度等工程语义无法表达；生成结果无法对齐到已有产品坐标系；CAD生态中最核心的装配约束、运动仿真等能力，AI还远没掌握。

但我也观察到几个积极趋势。一是多模态融合的进步，图像输入、文字描述、3D草图约束的组合可以显著提升生成准确性；二是专业垂直模型的兴起，针对CAD领域微调的模型远比通用大模型理解“倒角”“圆角”“筋板”这类术语；三是CAD软件厂商正在深度集成AI能力，未来的text-to-cad很可能会内嵌在软件里，而不是现在这种“生成再导入”的外挂式流程。

从更深层的角度看，text-to-cad真正改变的其实是“设计门槛”这个概念。过去设计一个零件需要掌握软件操作、了解建模思维、熟悉工程规范，现在前面两项的门槛正在被大幅拉低，人只需要把注意力放在“想清楚要什么”和“判断结果对不对”这两件事上。这对整个制造业的人才结构、设计流程、甚至产品创新的速度都会带来连锁影响。

我个人在实际体验里最深的感受是，text-to-cad最打动我的不是它能生成多复杂的模型，而是它让“想法到实物”这条路变得前所未有的短。以前我半夜突然有一个结构灵感，得憋着明天到工作室操作软件；现在穿上拖鞋打开电脑，一句话先出个大概，再追几轮细节，提交打印，第二天实体已经在手边了。这个满足感是纯粹的技术体验无法替代的。

最后再分享一个小技巧：不管你用哪个平台、哪个模型，先在prompt层面把“尺寸、单位、坐标系、几何关系”四个维度写完整，再考虑怎么调代码。这四个维度只要写清楚了，text-to-cad的生成质量能直接提升一大截。技术还在快速迭代，但把文字功夫练好这件事，什么时候都不会过时。