1. 从一句"帮我画个零件"到可编辑模型：text-to-cad 到底在解决什么
先聊聊这个方向为什么会出现。之前做机械设计相关的自动化工作，遇到的第一个瓶颈不是软件不好用，而是"设计意图"转成"模型操作"的过程太慢。脑海里想的是一个带安装孔、带加强筋、外沿要倒角的钣金支架，手里干的是打开 SolidWorks、选基准面、画草图、拉伸、切除、再打一排孔。如果需求又改了三个版本，那前面这些操作基本白干。text-to-cad 这类工具的野心就是把这中间的"操作层"压缩掉：你直接在输入框里写 "a 120mm x 80mm mounting plate with 4 holes at corners, 8mm diameter, 3mm thickness"，它给你生成一个可继续编辑的 CAD 模型，而不是一张 PNG 图片。这个区别很关键——渲染图、AI 生成的网格模型都不算真正的 CAD，因为没法改特征、没法进装配体、没法直接导出加工代码。
从实现路径上看，目前主流做法大致能分成三条线。第一条是把自然语言翻译成 CAD 软件的脚本语言，比如 FreeCAD 的 Python API、SolidWorks 的 VBA 宏、或者 OpenSCAD 的代码；第二条是先在背后生成参数化的特征树，再拿这个特征树去驱动模型构建；第三条是走"语义到几何"的路线，直接训练模型从文本生成 BREP 或 CSG 表示的实体。三条路线各有利弊，脚本翻译这条最务实，因为它不碰核心几何内核，只是把"语言到代码"的问题交给了大模型，几何正确性仍然由原生的 CAD 内核保证。
还有一个容易被忽略的点：text-to-cad 并不是让人完全脱离建模，它的价值是让"从零起步"和"方案草拟"这两个环节提速。换句话说，它更像是一个配了快速录入员的参数化草稿助手，而不是一个能独立思考的设计师。我的实际体会是，它最适合用在前期方案对比、标准件族生成、以及给非 CAD 专业的同事一个"先看轮廓"的入口。真正落实到出图、公差、装配约束的时候，还是要回到建模软件里做二次调整。想用好这个工具，首先要接受它的能力边界。
2. 底层逻辑拆解：自然语言、特征约束与几何内核之间的三角关系
2.1 大模型在中间扮演的角色不是"画图"，而是"写操作序列"
很多人第一次接触 text-to-cad，下意识会以为这是个扩散模型，跟文生图一样是逐像素或逐体素生成几何。实际落地效果比较好的方案大多不是这个思路。真正稳定的是让大语言模型去生成"建模指令序列"——比如"创建草图，在原点画中心矩形，宽 100，高 50，退出草图，拉伸 20 毫米"——然后由 CAD 软件逐条执行。这样做的直接好处是，每一步都有明确的几何意义，出了问题你能直接定位到是哪一步的参数错了，而不用怀疑整个几何形状是"幻觉"出来的。
我测试过不少本地跑的模型和在线服务，一个很明显的规律是：参数越明确，成功率越高。"A wall bracket with two slots"这种模糊描述，十次有八次会生成一个"看起来像但尺寸随缘"的模型；改成 "a 60mm x 40mm vertical plate, thickness 5mm, with two 10mm x 6mm horizontal slots centered at y=20mm and y=40mm"，生成结果几乎不会跑偏。这不是玄学，是因为明确的尺寸和位置给了大模型清晰的 token 上下文，它能更快对齐到对应的 API 参数。反过来，你在自然语言里没写清楚的部分，模型只能靠猜，而 CAD 里 "猜" 出来的几何往往都不太能用。
2.2 特征树才是 text-to-cad 的核心资产
你可以把 CAD 模型想象成一道菜的菜谱加成品：特征树是菜谱，BREP 实体是成品。真正能修改、能调整、能复用的是菜谱，不是最终那个实体形状。所以一个值得用的 text-to-cad 工具，必须把生成过程的"特征树"暴露给你，而不是丢给你一个"死掉"的实体。
举一个实际案例。我让工具生成一个带法兰的轴套，第一次跑出来的模型在视觉上没什么问题，法兰的厚度、内孔直径、外径都在合理范围。但我打开特征树一看，法兰和轴套本体是一个"整体拉伸"造出来的，没有单独的特征节点，我想把法兰厚度从 8 改成 12，只能重新生成整个零件，做不到直接把那个法兰特征改掉。这种模型就是"看起来能用、改起来要命"。好的生成结果应该是这样的：轴套本体是一个拉伸特征，法兰是第二个拉伸特征，内孔是第三个切除特征。后面想改任何一个参数，右键编辑特征就行，操作跟你自己手搓的模型没有任何区别。
所以在评估工具的时候，不要只看它生成的模型漂亮不漂亮，你真正应该问的是：特征树是参数化的吗？特征是独立可编辑的吗？修改其中一个尺寸，关联位置会不会自动更新？这三个问题决定了这个工具是玩具还是生产力。
2.3 几何内核在背后的兜底作用
无论前面的自然语言理解做得有多好，最终所有指令都要落到几何内核上。开源的 FreeCAD、商业的 Parasolid 和 ACIS、云端的 ShapeDiver 这类后端，各家的容错和表现差异很大。最典型的区别是布尔运算和倒角。有些内核在"拉伸-切除-再打孔"这套标准操作上非常稳定，但一旦涉及"两个面重合时做圆角""多实体相交后做抽壳"，就可能因为拓扑判断的问题直接报错。
这也带出一个实操经验：把 text-to-cad 生成的模型当成"半成品"对待，别当成"成品"直接拿去做有限元或者出加工单。我习惯的流程是，先让工具生成一个接近需求的草稿模型，然后把特征树里可疑的部分重新用干净的操作做一遍，尤其在圆角、拔模斜度、螺纹孔这些位置，手工重建反而比修修补补更快。这不是说工具不行，而是说几何内核的容错边界本来就摆在那里，谁用都不可能绕过。
3. 实战测试：我用三种典型场景检验 text-to-cad 工具的真实水平
3.1 标准零件族生成：法兰盘的批量参数化
第一个测试场景是法兰盘。我给的描述是："DN50 PN16 flat face flange, outer diameter 165mm, inner bore 61mm, thickness 18mm, 4 bolt holes of 18mm diameter on a 125mm bolt circle, chamfer 1.5mm on outer edge"。这个描述几乎包含了所有关键参数，没有任何含糊空间。
结果让我比较意外的是，工具对 "bolt circle" 这个概念的理解比我想象中好。大部分模型都能正确计算四个螺栓孔的坐标位置，也就是以 (62.5, 0)、 (0, 62.5)、 (-62.5, 0)、 (0, -62.5) 为圆心打孔。但有几款模型在"倒角"这个操作上处理得不够干净，有的把外缘倒角做成了全周圆角，有的干脆忽略。另一个高频 bug 是螺栓孔变成"盲孔"——看起来有孔，但底部还留着 0.1mm 的薄层，这在实际加工中是灾难。我猜测是模型生成切除特征时对"完全贯穿"这个选项理解有偏差，或者背后脚本默认用了给定深度而不是 Through All。
这个场景给我的结论是：参数越标准化、描述越贴近 CAD 操作术语，成功率越高。但生成之后必须自己检查一遍特征树里的"贯穿/盲孔"类型，以及倒角特征到底加在了哪个边上。
3.2 自由造型：从文字到异形支架，翻车点在哪里
第二个场景我故意给了模糊需求："A lightweight L-shaped bracket with triangular gussets, optimized for 3D printing, with minimal material usage"。这简直就是故意为难工具。结果是，六款工具里只有两款给出了"可接受的"结果，剩下的要么把 L 形做成了一块方板加一根斜撑，要么生成了完全不考虑打印方向、悬垂一塌糊涂的造型。
其中一款让我印象很深，它真的理解了"minimal material usage"，把整个支架内部做成了蜂窝结构。想法很好，但问题是这个蜂窝结构的单元尺寸是 8mm，打印壁厚只有 1.2mm，而且蜂窝方向和打印层方向完全平行，等于一打印就塌。这就是典型的"语义理解了但工程没理解"。它知道蜂窝可以减重，但不知道蜂窝孔的方向要跟着主受力方向走，更不知道 3D 打印的悬垂极限是多少。
这类自由造型场景目前还不成熟，原因在于：文本能表达的语义空间非常有限，"轻量""美观""适合打印"这些抽象概念没法在特征树上形成一组合法的参数约束。就算大模型有很强的联想能力，它也只能在"它见过的 CAD 操作"里做组合，而真正优秀的拓扑优化结果是靠仿真迭代解出来的，不是靠语言模型推出来的。
3.3 装配体协同：一个零件的生成很简单，一整套夹具才见真章
第三个场景我让工具生成一套"含底座、立柱、压板、两个 M8 螺丝孔的简易手动压紧夹具"。这个场景的难点在于零件之间的配合关系：底座上的螺丝孔必须和压板上的长槽对齐，立柱的高度必须刚好让压板压到工作台上的工件。
结果很清醒：单零件生成基本都能过关，但一进入"装配约束"层面，工具就暴露出最大的短板——它不知道零件之间应该怎么配合。底座生成得很好，压板也生成得很好，但压板的安装孔位和底座立柱的轴心位置差了 3.5mm，两个零件根本装不到一起去。原因也不难理解：大多数 text-to-cad 工具是"每个零件独立生成"的，没有输入"这套夹具的装配逻辑"这一层信息。
我不能怪工具，因为我确实没在提示词里写"bolt holes on the base must match slot on the clamp plate"。但这恰恰说明，这个工具的交互范式还是"单零件、单 prompt"，而实际设计工作的核心恰恰是"多零件、约束关系"。想让 text-to-cad 真正进入工作流，必须把"装配意图"也结构化成文字描述的一部分，比如明确写清基准点、对称约束、配合关系。这需要使用者有比较强的"翻译能力"。
4. 绕过幻觉：让 text-to-cad 输出稳定可用的关键提示词技巧
4.1 结构化提示词的写法，我踩了一周坑后的模板
先说结论：不要把 text-to-cad 的提示词当成日常聊天。你写得越接近"工程设计说明书"，它输出越稳定。我整理了一个通用模板，实测可以把一次生成成功率从三成拉到七成左右。模板分四段：
- 零件名称和用途：比如"外壳上盖，用于容纳 60mm x 40mm 的 PCB 板"
- 关键尺寸和位置：每个尺寸都要带单位，"中心距"要写清是从哪个基准开始算
- 制造方式和材料：注塑件要加拔模角、3D 打印件要写清最小壁厚，CNC 加工件要考虑刀具半径
- 禁忌和边界条件：比如"不要贯穿孔""外圆角半径不小于 2mm""所有孔位相对于原点的对称"。
实际填一个例子：
"Electrical junction box lid, rectangular flat cover, width 120mm, depth 80mm, thickness 3mm. Four M4 screw holes, positioned symmetrically at 10mm from each corner, hole depth must not penetrate through the lid. Material is ABS plastic, injection molded, so add 1.5mm draft angle on outer vertical edges. No penetrations in the central 90mm x 50mm area to leave room for a label."
这种写法有两个好处。第一，大模型在生成代码时可以直接把每个参数映射到对应 API，减少猜测；第二，即使某个参数它实现不了，报错也是明确的，你能看出是哪一段描述出了问题。我踩过最大的坑是"写单位"——用 "hole of 8mm" 和 "hole of 8" 的成功率差了不是一点半点，带上单位之后模型反而更不容易在单位制之间摇摆。
4.2 "先验证尺寸，再验证形状"的双保险策略
无论工具输出得多漂亮，我强烈建议你养成的习惯是：先拉尺寸，再看形状。所谓"拉尺寸"，就是在 CAD 里用测量工具把所有关键尺寸量一遍，尤其是孔距、壁厚、外形轮廓。做这一步不是因为不信任工具，而是因为大模型生成代码和参数的时候，偶尔会把不同属性的数值串位——比如理论上 8mm 厚的壁厚变成 80mm，120mm 的外形变成 12mm。这种错误在屏幕上看不出来，但你一测量就立刻暴露。
等尺寸都对了，再去关注形状细节。这里有个高频问题：倒角和圆角经常被搞混。提示词里写"chamfer"，生成出来的是"fillet"；写"round the edge"，结果整个棱边都被"倒"成圆弧。原因是自然语言里这两个词经常被当成同义词用，但 CAD 内核里它们是两个完全不同的操作。你要是某个倒角特别关键，请在提示词里同时给出方向和数值，比如"chamfer 1mm x 45deg on top outer edge"。
4.3 如何用"后置修正提示词"进行迭代
text-to-cad 的交互通常不是一次成功的。与其反复从零开始生成新模型，不如学会在同一特征树上做增量修改。我常用的做法是：第一轮只求"形状大概对"，第二轮针对具体问题发修正指令。比如 "Change the hole spacing from 40mm to 45mm"、"Add a 3mm radius fillet to the inner corner"、"Extrude the base by another 5mm"。这样做的好处是，你保留了原来的特征结构和约束关系，只改目标参数，迭代次数少，而且不容易把原来已经对的部分弄坏。
这里要特别提醒一句：如果你用的是云端工具，每轮对话都可能触发"重新生成整套特征树"，前一轮的修改可能不会保留。所以在开始对话之前，先把头一个"基本成型"的模型保存为本地副本，当每一次迭代的基线。没有这个基线，你后面所有的修改都会像在流沙上盖楼。
5. 工具选型与本地部署：没有银弹，只有取舍
5.1 云端方案和本地方案的实测感受
我用过的 text-to-cad 服务，大致分成三类。第一类是商业在线平台，界面友好、上手快，背后可能接的是 GPT-4 级别的大模型加自家几何内核，对常见零件类别的支持最成熟。缺点是隐私性差——你上传的设计数据等于交给了第三方，对于很多公司来说这是不能碰的红线。第二类是 SDK 接入型，比如让你在一个插件面板里输入文字，生成结果直接出现在当前打开的 CAD 工程里。这种体验最顺滑，但它依赖你使用的 CAD 软件版本和插件兼容性。第三类是纯本地部署，典型的做法是拿开源的 CodeLlama、DeepSeek-Coder 这类基座模型接 FreeCAD 的 Python API，完全离线，数据不出内网，但初始配置成本高，生成质量也弱于商业大模型。
给一个我的选型判断标准：如果你只在概念设计阶段用、数据不敏感，优先选商业在线平台；如果数据保密要求高，那就必须本地部署；如果你的目标是"把 text-to-cad 嵌入到公司已有的设计流程里"，那 SDK 集成方案几乎是唯一合理的选择，因为模型生成完之后，下一步动作一般是"进装配体"或者"出工程图"，这些操作只有 CAD 插件才能无缝衔接。
5.2 一个最省事的本地方案：FreeCAD + 本地大模型 + Python 脚本
如果你的技术要求是"离线、免费、可复现"，我实测的一个组合路径可以给你参考：本地跑一个大语言模型（我一直在用 14B 级别的量化模型），通过 Ollama 暴露一个 OpenAI 兼容的接口；中间加一层转换脚本，把用户输入的文字拼装成 FreeCAD 的 Python 建模脚本；最后让 FreeCAD 执行这段脚本并生成实体。这套方案完全走开源路线，不依赖任何外部服务。
具体流程是这个样子的。用户输入一句自然语言描述，我先在转换脚本里做一个"关键词到参数槽位"的抽取，抽出长度、宽度、高度、孔数、孔径、壁厚这些常见字段；抽不出来的部分，交给大模型用自由文本去生成 FreeCAD 脚本。为了让生成质量稳定，我在提示词里塞了 FreeCAD 的 API 使用规范，并要求模型只输出 Python 代码块。代码生成后，先做一个简单的 AST 安全检查，再丢给 FreeCAD 的 Python 解释器执行，最后把结果文件保存为 FCStd 格式。
这套流程的问题也很明显：本地模型对复杂几何操作的理解能力远不如云端商业模型，尤其在"扫描、放样、多实体布尔加减"这些高级操作上，经常出现"语法全对、几何全错"的情况。而且调试成本高，一次生成脚本报错，你得同时看模型输出、Python 语法、FreeCAD 内核报错三层信息。对我来说，这个方案最大的价值不是替代商业工具，而是在"数据不出内网"这个前提下保留了一个可用的能力基线。
5.3 收到 STL 文件不等于收到 CAD，别混淆了概念
市面上有一些打着"text-to-3D"旗号的服务，输入文字直接吐出一个 STL 网格文件，或者一个 GLB 格式的三维模型。这个跟 text-to-cad 完全是两回事。STL 是"三角形面片"的集合，它没有特征树、没有参数、没法改尺寸、没法做装配约束。对一个做逆向工程或者给游戏预览用的人，STL 够了；但你要出加工、出工程图、做装配，STL 就是一条死路。
我在项目里遇到过的场景是：一个同事用 AI 工具生成了一个看起来非常精致的产品外壳模型，拿到手一看是网格文件，想改壁厚却发现无从下手——没有参数可调，只能重新生成。最后他把网格文件导进逆向软件，用曲面拟合重新造了一遍参数化模型，花了比手工建模更多的时间。这个教训值得写在这里：选工具之前，先想清楚你最终要拿到什么，是"看起来像的参数化实体"，还是"可以直接改的可编辑 CAD 文档"。前者也许文生图就能满足，后者才需要真正的 text-to-cad。
6. text-to-cad 实际落地时的几个坑，我替你踩过了
6.1 尺寸单位带来的十倍误差
单位问题是 text-to-cad 场景里最诡异也最容易被忽视的坑。同样是 "thickness 3" ，模型可能生成 3mm，也可能生成 3 英寸。如果你的工作流是毫米制，生成结果里的一个 3 英寸壁厚就是 76.2mm，这个问题不一定是模型"不懂单位"，而可能是它默认了米制，但你的 CAD 工程模板是英制，两边就吵起来了。
我吃过一次亏：让工具生成一个 "50mm mounting plate"，它在脚本里生成了 50，但 FreeCAD 工程默认单位是毫米，生成结果本身没毛病；可当我把它导入到装配体里，装配体模板是英寸制，这一块板瞬间变成将近两米大，整个装配比例全乱了。现在我的规则是：在提示词里强制写明单位，同时在生成完成后立即用测量工具确认外形尺寸与预期偏差不超过 1%—— 超过这个范围直接判失败，别给它找台阶。
6.2 草图约束的缺失会让后续修改变成灾难
大模型生成 FreeCAD 脚本时，为了效率和成功率，经常偷懒，用"裸坐标"画草图，而不是给几何元素加上约束。比如一个矩形，它可能就是四个坐标点连起来的，没有给矩形加"水平约束"和"长度约束"。这种模型当时看着没问题，但只要你后续改其中一个尺寸，整个草图就散架，因为缺少约束关系来维持几何形状。
这是我在多个工具上反复遇到的共同毛病。一个真正合格的 text-to-cad 生成，应该在草图里包含必要的尺寸约束和几何约束，比如"这条线与那条线等长""这个圆与这条边相切""两个孔中心水平对齐"。判断一个工具是否专业，你不妨生成一个带阵列孔的板，然后回到草图里试着改一下第一个孔的位置，看其他孔是不是跟着联动。能联动说明约束建立了，不能联动说明是裸坐标，后面有你受的。
6.3 命名和特征序的"可读性"直接决定协作效率
生成的特征树如果全是"Pad""Pad001""Pad002"这种无意义命名，单机自己玩还行，一旦模型要交给同事复审或者后续维护，基本就废了。我记得有一个协作项目，甲方要求我们把所有关键特征加上规范命名，比如"base_plate_3mm" "hole_m4_align_top" "rib_side_left" 之类。而 text-to-cad 工具默认生成的命名基本都是"Feature1""Feature2"这种流水号，到了出 BOM 表时根本对不上号，只能一个个手动重命名，那叫一个痛苦。
所以在用任何工具之前，先检查一下它的命名策略。有的商业工具做得比较聪明，会按几何体类型自动命名，比如"Sketch_Flange" "Pocket_holes_4x_m8"；有的就完全不管。后者建议你在 prompt 里添加一句 "use descriptive feature names in the tree"。我不确定大模型会不会每次都遵守，但加了这一句，成功率明显比不加高。
6.4 复杂布尔运算的"自相交"问题
自相交是布尔运算里一个非常经典的错误：两个实体在做加或减时，由于曲面自交，几何内核无法判断哪部分是内侧、哪部分是外侧，直接抛错。text-to-cad 生成多实体场景时触发这个问题的概率不低。我碰到过一次：文字描述是"实心圆柱，直径 50，高 30，中心挖一个六角沉孔"，理论上就是"圆柱减去六棱柱"，非常简单。但生成脚本里把六棱柱写成了"六条线框拉伸"而不是"闭合六边形拉伸"，FreeCAD 在做布尔减的时候直接报"BRep_API: command not done"。
面对这种情况，不要浪费时间试图修复出错的特征，直接检查草图是不是闭合、有没有交叉点、有没有重复线。布尔出错 90% 的原因都能在源头草图上找到。这也再次说明，text-to-cad 生成结果之后，第一步永远是"看草图、看特征树"，而不是看屏幕上的三维预览。
7. 关于"语义到约束"的坑：为什么有时候模型能听懂，但做不到
在使用 text-to-cad 的过程中，你会经常遇到一个看起来像是"玄学"的现象：模型完全理解了你说的每一句话，甚至能在回复里复述你的尺寸要求，但生成出来的模型就是不对。比如你说"内孔要与外圆同心"，它生成的模型从渲染图上看确实像是同心的，但一测量，内孔圆心和外圆圆心的距离差了 0.02mm。0.02mm 的偏差放在渲染里根本看不出，但对配合件来说就是过盈配合变成间隙配合的区别。
其根源在于大模型对"同心"这种约束的理解，往往是"看到过的图形里长那样"，而不是"圆心坐标完全相等"这个数学事实。它可能生成草图时，外圆圆心在 (50, 50)，内孔圆心用的是浮点运算后的 (50.0001, 50.0001)，然后跟你解释"这是同心圆"。你说它错了吧，语义上确实努力了；你说它对了吧，工程上又不过关。所以我在实际使用中慢慢养成了一个动作：凡是涉及同心、相切、对称、平行这些"位置关系"的描述，生成完第一件事就是给对应草图加显式约束，或者干脆直接锁定坐标值。
这个经验也影响了我对 text-to-cad 的定位：它更适合做"几何轮廓的快速探索"，而不是"精确约束的最终落笔"。在设计流程里，它可以帮你快速排出"形状可能长这样"的方案，然后真正进入细节设计时，还是要靠你重新梳理草图约束、标注关键配合尺寸。这并不是说这类工具没有价值，而是说它的价值在"从无到有"的过程，不在"从有到精"的过程。
8. 我目前在用的 prompt 框架和日常消化学到的改进思路
我不太喜欢把 prompt 看作"咒语"，它更像是一种结构化的工程描述。下面这个框架是我经过几十次测试后慢慢优化出来的，你可以直接拿去改：
[Part name] — a [part function] [Overall envelope] — overall width x depth x height, preferred unit: mm [Key features] — list of holes / slots / bosses / ribs, each with size and position [Manufacturing intent] — process (CNC / injection molding / 3D printing), material, min wall thickness, draft angle if any [Constraints] — symmetry references, hole patterns, forbidden zones, required chamfer/fillet values [Additional notes] — anything that cannot be captured by the above, such as "the rib should be coplanar with the top face of the base" or "all internal corners must have a radius of at least 2mm"这个框架并不复杂，但它把"自然语言"硬生生压成了"参数表"，大模型处理起来就会轻松得多。你甚至可以把它直接用 Markdown 表格写出来，模型对这种结构敏感度很高。我测试过同样一段描述，写成"一句话长句"和写成"分段参数表"的效果差距非常大，后者往往在第一次生成时的几何正确率就高不少。
另外，我也逐渐在加入一种"长尾修正"的用法：第一次生成后，我不再重新描述整个零件，而是直接说"keep the current base geometry, only change X to Y"这种指代式修改。能不能高效地做这种增量编辑，目前是划分工具好坏的一个重要分水岭。商业平台里有些做得不错的，可以在特征树上精准定位并修改，而本地部署方案普遍还没有这个能力——这也符合预期，毕竟增量编辑需要更强的关系理解能力。
9. 下一步值得关注的方向和我的个人预期
text-to-cad 的演进速度很快，但离"人人都会 CAD"还有比较长的路。目前真实落地比较成熟的方向，我个人认为有这么几个：第一，面向固定零件族（法兰、支架、安装板、外壳、盖板）的领域化生成，这类零件形状规律、参数清晰，是最容易实用化的；第二，和仿真结合的"描述目标性能，直接生成初始几何"，比如写"承受 500N 侧向力、重量控制在 80g 以下"，由系统给出一个拓扑初值，再让工程师精修；第三，逆向的 "CAD-to-text"，把已有模型的特征树转成自然语言描述，用于检索和知识管理。这个方向看似冷门，但对企业积累设计资产特别有用。
我的预期是，未来十八个月内，text-to-cad 会在"标准机械零件"这个垂直领域取得非常明显的实用化突破，因为这块数据量大、参数规范、价值明确。而真正面向自由曲面、复杂装配、跨领域设计的通用 text-to-cad 还会继续拉锯，原因不在模型能力，而在"把语言转化成带着公差、装配关系的可制造模型"这件事，复杂度远超一次几何生成。
我自己目前的使用定位依然很保守：用它在方案前期快速做出 5 到 6 个候选外形，挑出两个继续细化；绝不直接拿生成结果下厂加工。你只需要让它帮你跑出"设计空间"的轮廓，剩下的细化工作，亲自动手反而更快。这才是我在多个项目和几百次生成测试里最真实的一个感受：好工具不会取代你，它只是在你不该花时间的地方帮你省时间。
