1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个词很多人脑子里浮现的画面大概是对着电脑说一句给我画个齿轮屏幕上就自动蹦出一个可以加工的三维模型。这个想象不算离谱但真正落地到工程实践里它要解决的问题比说一句话复杂得多也有意思得多。text-to-cad直译就是文本到计算机辅助设计。它的核心目标是把自然语言描述转换成结构化的、可编辑的、能被下游制造流程消费的三维几何数据。注意我这里用了三个限定词结构化、可编辑、可消费。这三个词决定了它和AI 画图完全是两码事。AI 画图生成的是像素好看就行text-to-cad 生成的是几何得能测量、能装配、能出工程图、能丢进数控机床或者 3D 打印机里跑出来。那它到底适合谁我梳理了一下大致是这几类人一是做机械设计、工业设计的工程师想用自然语言快速生成初步方案省掉从草图到参数化建模的重复劳动二是做增材制造、快速原型的小团队需要把客户一句模糊的需求快速变成可打印的模型三是做 CAD 二次开发、工业软件的技术人员想搞清楚这条技术链路里到底有哪些坑四是做 AI 应用的研究者关心大模型怎么和几何内核对接。如果你属于其中任何一类这篇内容应该都能给你一些能直接上手的东西。需要先说明一点text-to-cad 目前还不是一句话出成品的魔法。它更像一个高级翻译器——把人类模糊的语言翻译成机器能懂的几何指令中间必然有信息损失也必然需要人来兜底。理解这一点后面的所有技术选择就都顺了。2. 拆解 text-to-cad 的技术链路语言是怎么变成几何的2.1 为什么不能直接让大模型画出三维模型很多人第一反应是现在大模型这么强直接让它输出一个三维模型文件不就行了我一开始也这么想试过之后发现根本走不通。原因很实在大模型的输出本质是 token 序列它擅长的是文本这种一维、离散、有语法结构的东西。而三维几何是连续的、有拓扑关系的、带精确尺寸约束的。你让模型直接吐一个 STL 或者 STEP 文件它输出的顶点坐标大概率是看起来像那么回事但根本对不上的一堆乱码。更关键的是即便模型侥幸输出了一个能打开的模型它也是死的——没有参数、没有特征树、没有约束关系。你想把齿轮的齿数从 20 改成 24对不起改不了只能重新生成。这在工程场景里是致命的因为工程设计的本质就是反复迭代修改。所以正确的思路不是让模型直接画而是让模型生成画图的指令。这就是整条链路的核心思想。2.2 三段式链路语义解析、参数抽取、几何重建我把 text-to-cad 的完整链路拆成三段这个拆法是我在实际项目里反复验证后总结的比很多论文里的分法更贴近工程落地。第一段是语义解析。输入是一个直径 50 毫米、厚度 10 毫米、中间有个直径 10 毫米通孔的圆盘模型要做的第一件事是识别出这是一个圆盘实体而不是圆柱或者环。这一步靠的是意图识别和实体分类通常用一个微调过的语言模型来做输出一个结构化的意图标签比如{shape: disk, operation: create}。第二段是参数抽取。从同一句话里把直径 50厚度 10通孔直径 10这些数值和它们对应的几何特征抽出来形成{outer_diameter: 50, thickness: 10, hole_diameter: 10, hole_type: through}这样的键值对。这一步的难点在于单位识别和指代消解——用户可能说5 公分50mm五厘米得统一也可能说上面那个孔得结合上下文。第三段是几何重建。拿着结构化的参数调用几何内核比如 OpenCASCADE、CGAL 这类真正把模型建出来输出 STEP、STL 或者直接生成参数化脚本。这三段里前两段是 AI 的活第三段是传统 CAD 的活。很多人失败就失败在想用一段 AI 把三段全包了结果哪段都不扎实。2.3 中间表示格式的选择为什么我最终选了参数化脚本在第二段和第三段之间需要一个中间表示来传递信息。这个中间表示选什么直接决定了整个系统的灵活性和可维护性。我试过三种方案列个表对比一下。中间表示方案优点缺点适用场景直接输出 STEP 文件通用性强任何 CAD 都能打开不可参数化改一个尺寸要重生成一次性交付JSON 参数描述结构清晰易于校验表达能力有限复杂曲面难描述简单规则零件参数化脚本如 CadQuery、OpenSCAD可参数化、可版本控制、可复用需要模型懂脚本语法工程迭代场景实测下来参数化脚本是最优解。原因很简单脚本本身就是代码可以进 Git 做版本管理可以传参数批量生成可以嵌套调用组合出复杂装配体。而且脚本是活的改一个变量整个模型跟着变这才是工程设计需要的东西。代价是模型得学会写脚本。但这个问题可以通过少样本微调 语法约束解码来解决——给模型几十个脚本示例再在解码时强制它只能输出合法语法成功率能拉到 90% 以上。这个思路后面会详细讲。3. 语义解析与参数抽取的实操细节3.1 意图分类先搞清楚用户到底要造还是要改语义解析的第一步是意图分类。这里有个很容易被忽略的点用户的话里往往同时包含创建和修改两种意图。比如把刚才那个圆盘的厚度改成 15 毫米这既是修改意图又隐含了对已有模型的引用。我的做法是把意图分成四类用一个轻量分类头来处理create从零创建新模型modify修改已有模型的某个参数query查询模型信息比如这个零件多重compose组合多个已有模型比如把这两个零件装配起来分类头不需要太复杂一个基于预训练语言模型的分类层就够了。关键是训练数据要覆盖足够多的口语化表达。我收集了大概两千条真实用户指令做微调准确率能到 95% 左右。这里有个经验别用太书面化的语料训练用户真实说话是搞个方块弄个洞加粗一点跟教科书语言差很远。3.2 参数抽取中的单位陷阱与指代消解参数抽取看着简单实际坑最多。我踩过的最大的坑是单位。用户说直径 5这个 5 到底是毫米、厘米还是英寸如果系统默认毫米遇到一个习惯用英寸的用户整个模型尺寸就错了 25 倍。我的解决方案是三层兜底第一层如果用户明确带了单位5 毫米3 英寸直接采用第二层如果没带单位查用户历史偏好同一个用户之前用过什么单位就默认什么第三层如果都没有用行业默认值机械设计默认毫米同时在返回结果里显式标注已按毫米处理如需修改请说明。指代消解是另一个难点。用户说在它上面打个孔这个它指谁上面是哪个面我的做法是维护一个对话状态栈记录最近提到的实体和它们的特征面。当出现指代词时从栈顶往下找最近的匹配实体。这个逻辑不复杂但一定要做否则多轮对话根本没法用。3.3 用语法约束解码把胡说八道挡在门外大模型有个毛病它有时候会一本正经地输出语法错误的脚本。比如括号不匹配、变量没定义、调用了不存在的函数。如果直接执行轻则报错重则生成一个尺寸完全错误的模型。我的解法是语法约束解码。具体做法是在模型解码的每一步用一个语法解析器实时检查当前 token 序列是否是某个合法脚本的前缀。如果不是就把导致非法的 token 概率置零强制模型走合法路径。这个技术在一些推理框架里有现成实现核心思想就是只允许生成语法上说得通的内容。实测下来加了语法约束之后脚本的首次可执行率从 60% 出头提到了 92% 以上。剩下那 8% 主要是语义错误语法对但逻辑不对那部分只能靠人工复核或者加一层语义校验。提示语法约束解码会增加推理耗时大概多 20% 到 30%。如果对延迟敏感可以只在检测到复杂指令时才启用简单指令走快速通道。4. 几何重建把参数真正变成能用的模型4.1 几何内核选型OpenCASCADE 还是轻量方案几何重建这一步绕不开几何内核的选择。这是整个系统里最重的部分选错了后面全是麻烦。主流选择是OpenCASCADE简称 OCCT。它是开源的、功能全的 B-rep边界表示内核支持布尔运算、倒角、抽壳这些工程上必需的操作能导出 STEP、IGES 这些标准格式。缺点是学习曲线陡文档不算友好编译一次能耗掉半天。如果你的需求只是生成简单的、可以用网格表示的模型比如给 3D 打印用那CGAL或者直接用trimesh这类库就够了轻量、上手快。但一旦涉及精确的工程尺寸、装配配合、工程图输出还是得上 OCCT。我个人的建议是先用轻量方案把链路跑通验证 AI 部分没问题再换 OCCT 做精确重建。别一上来就啃 OCCT容易在环境配置上耗光热情。4.2 从参数到脚本一个圆盘零件的完整生成过程拿前面那个圆盘例子走一遍完整流程你能看得更清楚。用户输入一个直径 50 毫米、厚度 10 毫米、中间有个直径 10 毫米通孔的圆盘第一步语义解析输出{intent: create, shape: disk, features: [through_hole]}第二步参数抽取输出{outer_diameter: 50.0, thickness: 10.0, hole_diameter: 10.0, unit: mm}第三步几何重建生成 CadQuery 脚本import cadquery as cq outer_d 50.0 thickness 10.0 hole_d 10.0 result ( cq.Workplane(XY) .circle(outer_d / 2) .extrude(thickness) .faces(Z) .workplane() .hole(hole_d) ) cq.exporters.export(result, disk.step)这段脚本执行完你就得到一个精确的、可参数化的圆盘模型。改outer_d的值模型自动更新。这就是参数化脚本的威力。4.3 复杂特征的分解策略把一句话拆成一串操作简单零件好办复杂零件才是真正的考验。用户说一个带法兰的轴法兰上有四个均布螺栓孔这一句话里其实包含了拉伸、旋转、阵列、打孔好几个操作。我的策略是特征分解把一句话拆成一串有序的建模操作每个操作对应脚本里的一段。上面那句话拆出来大概是创建圆柱主体拉伸在端部创建法兰盘拉伸或旋转在法兰上创建单个螺栓孔打孔对螺栓孔做圆周阵列阵列数量 4这个分解过程可以交给模型做但一定要给它一个操作原语库作为约束——告诉它只能用这些基本操作来组合不能凭空发明。原语库大概包含二十来个操作拉伸、旋转、扫掠、放样、打孔、倒角、圆角、抽壳、阵列、镜像、布尔并交差等等。有了这个约束模型输出的脚本就可控多了。5. 实测中那些文档不会告诉你的坑5.1 模型对数量词和方位词的识别率低得离谱这是我在实测里最意外的发现。模型对直径 50这种明确数值识别得很好但对四个孔均布对称这类数量词和方位词识别率明显下降。尤其是均布这个词模型经常理解成随便放几个。后来我分析原因训练语料里带精确数值的样本多带空间关系描述的样本少。解决办法是专门构造一批空间关系语料做增强训练同时在参数抽取后加一层空间关系校验——如果检测到均布对称同心这类词就强制走对应的几何约束逻辑不依赖模型自由发挥。5.2 单位换算的精度损失别用浮点数硬算单位换算看着简单实际有精度陷阱。比如英寸转毫米1 英寸 25.4 毫米这个 25.4 是精确值但如果你用浮点数一路乘下去累积误差可能让最终尺寸差个零点几毫米。在精密零件上这是不能接受的。我的做法是所有内部计算统一用毫米且用高精度十进制类型比如 Python 的 Decimal只在最终输出时按需转换。另外换算系数要集中管理别散落在代码各处否则改一个地方漏一个地方。5.3 多轮对话里的状态管理模型会忘记前面说过什么多轮对话是 text-to-cad 真正好用的关键但也是最容易翻车的地方。用户第一轮说做个直径 50 的圆盘第二轮说厚度改成 15如果系统不记得第一轮的直径第二轮就无从改起。我的方案是维护一个显式的设计状态对象每轮对话结束后把最新的参数快照存进去。下一轮解析时把当前状态作为上下文一起喂给模型。这样即便模型本身没有记忆系统层面也有记忆。这个状态对象还能序列化存盘实现关掉再打开继续改。注意状态对象要做版本管理。用户可能改到一半想回退没有版本记录就只能重来。我一般保留最近 20 个版本够用了。5.4 生成模型的可制造性校验不能省这是最容易被忽略、但工程上最重要的一环。AI 生成的模型可能几何上没问题但制造上做不出来。比如壁厚太薄、孔太深钻头够不到、倒角角度不合理导致刀具干涉。我的做法是在几何重建之后加一道可制造性检查用规则引擎跑一遍常见约束最小壁厚、最小孔径、最大深径比、拔模角度等等。检查不通过就给出警告让用户确认或者自动调整。这一步能挡掉大量看着对但做不出来的模型省下的是真金白银的返工成本。6. 把 text-to-cad 用起来的几种现实路径6.1 个人开发者从最小可用链路起步如果你是一个人想玩这个方向别一上来就搞大而全。我的建议是先搭一条最小可用链路用一个现成的语言模型 API 做语义解析和参数抽取用 CadQuery 做几何重建中间用 JSON 传递。整个链路跑通可能就一两百行代码。跑通之后你会发现瓶颈在哪——通常是参数抽取的准确率。这时候再针对性地补语料、做微调。这种先跑通再优化的路径比一上来就纠结架构要高效得多。6.2 小团队把校验和版本管理做扎实小团队做这个重点不在生成能力而在可靠性。客户不会容忍一个时不时生成错误模型的工具。所以要把前面说的语法约束、可制造性校验、状态版本管理这几块做扎实。生成慢一点没关系生成错了才是灾难。另外小团队一定要做人工复核入口。AI 生成的模型在交付前必须有人过一眼这个流程不能省。等积累足够多的AI 生成 人工修正数据之后再考虑逐步减少人工介入。6.3 和现有 CAD 工作流的对接方式text-to-cad 不太可能完全替代传统 CAD更现实的定位是前端快速方案生成器。生成的参数化脚本可以导入到主流 CAD 软件里继续细化或者直接作为参数化模板复用。对接的关键是格式兼容。STEP 是通用格式但会丢失参数化信息脚本格式保留了参数化但需要目标软件支持。我的做法是双输出既给 STEP 方便查看又给脚本方便二次开发。用户各取所需。7. 关于这条链路我踩过之后最想说的几句做 text-to-cad 这段时间最大的体会是别把 AI 当成万能钥匙把它当成一个翻译官。它擅长的是理解人类模糊的语言不擅长的是精确的几何计算。把这两件事分清楚让 AI 做它擅长的让几何内核做它擅长的中间用结构化的中间表示连起来整条链路就顺了。另一个体会是参数化脚本这个中间表示是整个系统的灵魂。它既是 AI 的输出目标又是几何内核的输入还是版本管理和复用的载体。选对了它后面很多问题迎刃而解选错了处处掣肘。最后分享一个我常用的调试技巧当生成的模型不对时别急着调模型先把中间表示打印出来看。十有八九问题出在参数抽取那一步而不是几何重建。把中间表示看清楚问题定位能快一大半。这个习惯帮我省了无数个小时的瞎调。 
长河君 · 2026/10/25 3:12:36 · 阅读 1.2k text-to-cad 技术链路拆解：从自然语言到参数化三维模型
1. 从一句话到三维模型text-to-cad 到底在解决什么问题第一次听到 text-to-cad 这个词很多人脑子里浮现的画面大概是对着电脑说一句给我画个齿轮屏幕上就自动蹦出一个可以加工的三维模型。这个想象不算离谱但真正落地到工程实践里它要解决的问题比说一句话复杂得多也有意思得多。text-to-cad直译就是文本到计算机辅助设计。它的核心目标是把自然语言描述转换成结构化的、可编辑的、能被下游制造流程消费的三维几何数据。注意我这里用了三个限定词结构化、可编辑、可消费。这三个词决定了它和AI 画图完全是两码事。AI 画图生成的是像素好看就行text-to-cad 生成的是几何得能测量、能装配、能出工程图、能丢进数控机床或者 3D 打印机里跑出来。那它到底适合谁我梳理了一下大致是这几类人一是做机械设计、工业设计的工程师想用自然语言快速生成初步方案省掉从草图到参数化建模的重复劳动二是做增材制造、快速原型的小团队需要把客户一句模糊的需求快速变成可打印的模型三是做 CAD 二次开发、工业软件的技术人员想搞清楚这条技术链路里到底有哪些坑四是做 AI 应用的研究者关心大模型怎么和几何内核对接。如果你属于其中任何一类这篇内容应该都能给你一些能直接上手的东西。需要先说明一点text-to-cad 目前还不是一句话出成品的魔法。它更像一个高级翻译器——把人类模糊的语言翻译成机器能懂的几何指令中间必然有信息损失也必然需要人来兜底。理解这一点后面的所有技术选择就都顺了。2. 拆解 text-to-cad 的技术链路语言是怎么变成几何的2.1 为什么不能直接让大模型画出三维模型很多人第一反应是现在大模型这么强直接让它输出一个三维模型文件不就行了我一开始也这么想试过之后发现根本走不通。原因很实在大模型的输出本质是 token 序列它擅长的是文本这种一维、离散、有语法结构的东西。而三维几何是连续的、有拓扑关系的、带精确尺寸约束的。你让模型直接吐一个 STL 或者 STEP 文件它输出的顶点坐标大概率是看起来像那么回事但根本对不上的一堆乱码。更关键的是即便模型侥幸输出了一个能打开的模型它也是死的——没有参数、没有特征树、没有约束关系。你想把齿轮的齿数从 20 改成 24对不起改不了只能重新生成。这在工程场景里是致命的因为工程设计的本质就是反复迭代修改。所以正确的思路不是让模型直接画而是让模型生成画图的指令。这就是整条链路的核心思想。2.2 三段式链路语义解析、参数抽取、几何重建我把 text-to-cad 的完整链路拆成三段这个拆法是我在实际项目里反复验证后总结的比很多论文里的分法更贴近工程落地。第一段是语义解析。输入是一个直径 50 毫米、厚度 10 毫米、中间有个直径 10 毫米通孔的圆盘模型要做的第一件事是识别出这是一个圆盘实体而不是圆柱或者环。这一步靠的是意图识别和实体分类通常用一个微调过的语言模型来做输出一个结构化的意图标签比如{shape: disk, operation: create}。第二段是参数抽取。从同一句话里把直径 50厚度 10通孔直径 10这些数值和它们对应的几何特征抽出来形成{outer_diameter: 50, thickness: 10, hole_diameter: 10, hole_type: through}这样的键值对。这一步的难点在于单位识别和指代消解——用户可能说5 公分50mm五厘米得统一也可能说上面那个孔得结合上下文。第三段是几何重建。拿着结构化的参数调用几何内核比如 OpenCASCADE、CGAL 这类真正把模型建出来输出 STEP、STL 或者直接生成参数化脚本。这三段里前两段是 AI 的活第三段是传统 CAD 的活。很多人失败就失败在想用一段 AI 把三段全包了结果哪段都不扎实。2.3 中间表示格式的选择为什么我最终选了参数化脚本在第二段和第三段之间需要一个中间表示来传递信息。这个中间表示选什么直接决定了整个系统的灵活性和可维护性。我试过三种方案列个表对比一下。中间表示方案优点缺点适用场景直接输出 STEP 文件通用性强任何 CAD 都能打开不可参数化改一个尺寸要重生成一次性交付JSON 参数描述结构清晰易于校验表达能力有限复杂曲面难描述简单规则零件参数化脚本如 CadQuery、OpenSCAD可参数化、可版本控制、可复用需要模型懂脚本语法工程迭代场景实测下来参数化脚本是最优解。原因很简单脚本本身就是代码可以进 Git 做版本管理可以传参数批量生成可以嵌套调用组合出复杂装配体。而且脚本是活的改一个变量整个模型跟着变这才是工程设计需要的东西。代价是模型得学会写脚本。但这个问题可以通过少样本微调 语法约束解码来解决——给模型几十个脚本示例再在解码时强制它只能输出合法语法成功率能拉到 90% 以上。这个思路后面会详细讲。3. 语义解析与参数抽取的实操细节3.1 意图分类先搞清楚用户到底要造还是要改语义解析的第一步是意图分类。这里有个很容易被忽略的点用户的话里往往同时包含创建和修改两种意图。比如把刚才那个圆盘的厚度改成 15 毫米这既是修改意图又隐含了对已有模型的引用。我的做法是把意图分成四类用一个轻量分类头来处理create从零创建新模型modify修改已有模型的某个参数query查询模型信息比如这个零件多重compose组合多个已有模型比如把这两个零件装配起来分类头不需要太复杂一个基于预训练语言模型的分类层就够了。关键是训练数据要覆盖足够多的口语化表达。我收集了大概两千条真实用户指令做微调准确率能到 95% 左右。这里有个经验别用太书面化的语料训练用户真实说话是搞个方块弄个洞加粗一点跟教科书语言差很远。3.2 参数抽取中的单位陷阱与指代消解参数抽取看着简单实际坑最多。我踩过的最大的坑是单位。用户说直径 5这个 5 到底是毫米、厘米还是英寸如果系统默认毫米遇到一个习惯用英寸的用户整个模型尺寸就错了 25 倍。我的解决方案是三层兜底第一层如果用户明确带了单位5 毫米3 英寸直接采用第二层如果没带单位查用户历史偏好同一个用户之前用过什么单位就默认什么第三层如果都没有用行业默认值机械设计默认毫米同时在返回结果里显式标注已按毫米处理如需修改请说明。指代消解是另一个难点。用户说在它上面打个孔这个它指谁上面是哪个面我的做法是维护一个对话状态栈记录最近提到的实体和它们的特征面。当出现指代词时从栈顶往下找最近的匹配实体。这个逻辑不复杂但一定要做否则多轮对话根本没法用。3.3 用语法约束解码把胡说八道挡在门外大模型有个毛病它有时候会一本正经地输出语法错误的脚本。比如括号不匹配、变量没定义、调用了不存在的函数。如果直接执行轻则报错重则生成一个尺寸完全错误的模型。我的解法是语法约束解码。具体做法是在模型解码的每一步用一个语法解析器实时检查当前 token 序列是否是某个合法脚本的前缀。如果不是就把导致非法的 token 概率置零强制模型走合法路径。这个技术在一些推理框架里有现成实现核心思想就是只允许生成语法上说得通的内容。实测下来加了语法约束之后脚本的首次可执行率从 60% 出头提到了 92% 以上。剩下那 8% 主要是语义错误语法对但逻辑不对那部分只能靠人工复核或者加一层语义校验。提示语法约束解码会增加推理耗时大概多 20% 到 30%。如果对延迟敏感可以只在检测到复杂指令时才启用简单指令走快速通道。4. 几何重建把参数真正变成能用的模型4.1 几何内核选型OpenCASCADE 还是轻量方案几何重建这一步绕不开几何内核的选择。这是整个系统里最重的部分选错了后面全是麻烦。主流选择是OpenCASCADE简称 OCCT。它是开源的、功能全的 B-rep边界表示内核支持布尔运算、倒角、抽壳这些工程上必需的操作能导出 STEP、IGES 这些标准格式。缺点是学习曲线陡文档不算友好编译一次能耗掉半天。如果你的需求只是生成简单的、可以用网格表示的模型比如给 3D 打印用那CGAL或者直接用trimesh这类库就够了轻量、上手快。但一旦涉及精确的工程尺寸、装配配合、工程图输出还是得上 OCCT。我个人的建议是先用轻量方案把链路跑通验证 AI 部分没问题再换 OCCT 做精确重建。别一上来就啃 OCCT容易在环境配置上耗光热情。4.2 从参数到脚本一个圆盘零件的完整生成过程拿前面那个圆盘例子走一遍完整流程你能看得更清楚。用户输入一个直径 50 毫米、厚度 10 毫米、中间有个直径 10 毫米通孔的圆盘第一步语义解析输出{intent: create, shape: disk, features: [through_hole]}第二步参数抽取输出{outer_diameter: 50.0, thickness: 10.0, hole_diameter: 10.0, unit: mm}第三步几何重建生成 CadQuery 脚本import cadquery as cq outer_d 50.0 thickness 10.0 hole_d 10.0 result ( cq.Workplane(XY) .circle(outer_d / 2) .extrude(thickness) .faces(Z) .workplane() .hole(hole_d) ) cq.exporters.export(result, disk.step)这段脚本执行完你就得到一个精确的、可参数化的圆盘模型。改outer_d的值模型自动更新。这就是参数化脚本的威力。4.3 复杂特征的分解策略把一句话拆成一串操作简单零件好办复杂零件才是真正的考验。用户说一个带法兰的轴法兰上有四个均布螺栓孔这一句话里其实包含了拉伸、旋转、阵列、打孔好几个操作。我的策略是特征分解把一句话拆成一串有序的建模操作每个操作对应脚本里的一段。上面那句话拆出来大概是创建圆柱主体拉伸在端部创建法兰盘拉伸或旋转在法兰上创建单个螺栓孔打孔对螺栓孔做圆周阵列阵列数量 4这个分解过程可以交给模型做但一定要给它一个操作原语库作为约束——告诉它只能用这些基本操作来组合不能凭空发明。原语库大概包含二十来个操作拉伸、旋转、扫掠、放样、打孔、倒角、圆角、抽壳、阵列、镜像、布尔并交差等等。有了这个约束模型输出的脚本就可控多了。5. 实测中那些文档不会告诉你的坑5.1 模型对数量词和方位词的识别率低得离谱这是我在实测里最意外的发现。模型对直径 50这种明确数值识别得很好但对四个孔均布对称这类数量词和方位词识别率明显下降。尤其是均布这个词模型经常理解成随便放几个。后来我分析原因训练语料里带精确数值的样本多带空间关系描述的样本少。解决办法是专门构造一批空间关系语料做增强训练同时在参数抽取后加一层空间关系校验——如果检测到均布对称同心这类词就强制走对应的几何约束逻辑不依赖模型自由发挥。5.2 单位换算的精度损失别用浮点数硬算单位换算看着简单实际有精度陷阱。比如英寸转毫米1 英寸 25.4 毫米这个 25.4 是精确值但如果你用浮点数一路乘下去累积误差可能让最终尺寸差个零点几毫米。在精密零件上这是不能接受的。我的做法是所有内部计算统一用毫米且用高精度十进制类型比如 Python 的 Decimal只在最终输出时按需转换。另外换算系数要集中管理别散落在代码各处否则改一个地方漏一个地方。5.3 多轮对话里的状态管理模型会忘记前面说过什么多轮对话是 text-to-cad 真正好用的关键但也是最容易翻车的地方。用户第一轮说做个直径 50 的圆盘第二轮说厚度改成 15如果系统不记得第一轮的直径第二轮就无从改起。我的方案是维护一个显式的设计状态对象每轮对话结束后把最新的参数快照存进去。下一轮解析时把当前状态作为上下文一起喂给模型。这样即便模型本身没有记忆系统层面也有记忆。这个状态对象还能序列化存盘实现关掉再打开继续改。注意状态对象要做版本管理。用户可能改到一半想回退没有版本记录就只能重来。我一般保留最近 20 个版本够用了。5.4 生成模型的可制造性校验不能省这是最容易被忽略、但工程上最重要的一环。AI 生成的模型可能几何上没问题但制造上做不出来。比如壁厚太薄、孔太深钻头够不到、倒角角度不合理导致刀具干涉。我的做法是在几何重建之后加一道可制造性检查用规则引擎跑一遍常见约束最小壁厚、最小孔径、最大深径比、拔模角度等等。检查不通过就给出警告让用户确认或者自动调整。这一步能挡掉大量看着对但做不出来的模型省下的是真金白银的返工成本。6. 把 text-to-cad 用起来的几种现实路径6.1 个人开发者从最小可用链路起步如果你是一个人想玩这个方向别一上来就搞大而全。我的建议是先搭一条最小可用链路用一个现成的语言模型 API 做语义解析和参数抽取用 CadQuery 做几何重建中间用 JSON 传递。整个链路跑通可能就一两百行代码。跑通之后你会发现瓶颈在哪——通常是参数抽取的准确率。这时候再针对性地补语料、做微调。这种先跑通再优化的路径比一上来就纠结架构要高效得多。6.2 小团队把校验和版本管理做扎实小团队做这个重点不在生成能力而在可靠性。客户不会容忍一个时不时生成错误模型的工具。所以要把前面说的语法约束、可制造性校验、状态版本管理这几块做扎实。生成慢一点没关系生成错了才是灾难。另外小团队一定要做人工复核入口。AI 生成的模型在交付前必须有人过一眼这个流程不能省。等积累足够多的AI 生成 人工修正数据之后再考虑逐步减少人工介入。6.3 和现有 CAD 工作流的对接方式text-to-cad 不太可能完全替代传统 CAD更现实的定位是前端快速方案生成器。生成的参数化脚本可以导入到主流 CAD 软件里继续细化或者直接作为参数化模板复用。对接的关键是格式兼容。STEP 是通用格式但会丢失参数化信息脚本格式保留了参数化但需要目标软件支持。我的做法是双输出既给 STEP 方便查看又给脚本方便二次开发。用户各取所需。7. 关于这条链路我踩过之后最想说的几句做 text-to-cad 这段时间最大的体会是别把 AI 当成万能钥匙把它当成一个翻译官。它擅长的是理解人类模糊的语言不擅长的是精确的几何计算。把这两件事分清楚让 AI 做它擅长的让几何内核做它擅长的中间用结构化的中间表示连起来整条链路就顺了。另一个体会是参数化脚本这个中间表示是整个系统的灵魂。它既是 AI 的输出目标又是几何内核的输入还是版本管理和复用的载体。选对了它后面很多问题迎刃而解选错了处处掣肘。最后分享一个我常用的调试技巧当生成的模型不对时别急着调模型先把中间表示打印出来看。十有八九问题出在参数抽取那一步而不是几何重建。把中间表示看清楚问题定位能快一大半。这个习惯帮我省了无数个小时的瞎调。