text-to-cad：从自然语言到STEP的工程建模协议

1. 什么是text-to-cad？它不是“AI画图”，而是工程链路的断点修复

你搜“text-to-cad”时，大概率会撞上一堆混淆概念的结果：有人把它当成“用文字生成CAD草图”的玩具功能，有人拿它和MidJourney比渲染效果，还有人直接问“有没有免费在线版”。这恰恰说明——这个方向目前最缺的不是技术，而是对它真实定位的共识。

text-to-cad，本质是一套面向制造前段的语义驱动建模协议。它不生成美观的渲染图，也不替代工程师画图；它解决的是“设计意图从自然语言到可计算几何体”的语义鸿沟。比如你输入“直径25mm、长120mm、两端带M6螺纹的光轴”，系统输出的不是一张带阴影的3D图，而是一个符合ISO 965-1标准、含完整螺纹参数化定义、能被SolidWorks直接装配、可导出为STEP AP242格式的实体模型。这才是text-to-cad的硬核现场。

它背后真正咬住的三个痛点，是传统CAD工作流里长期被忽视的“哑节点”：
第一，非结构化设计输入无法进入BOM系统——客户邮件里写的“加个法兰盘，厚度要够扛300psi”，工程师得手动拆解成直径、厚度、材质、密封槽尺寸，再建模，这个过程没有留痕、不可追溯、极易出错；
第二，跨专业协作存在语义失真——机械工程师说“沉头孔”，电气同事可能理解成“通孔”，采购看到图纸才反馈“这个沉头角度我们标准件库里没有”，返工成本在图纸阶段就已埋下；
第三，小批量定制场景建模效率断崖式下跌——做100个相同零件，建模时间摊薄后很便宜；但做10个各不相同的支架，每个都要重开草图、拉伸、倒角、标注，人均小时产出直接腰斩。

所以text-to-cad不是“让AI替你画图”，而是把工程师从“翻译官”角色里解放出来——不再需要把业务语言反复转译成几何约束，而是让业务语言本身成为可执行的建模指令。它对接的下游不是渲染引擎，而是STEP解析器、G代码生成器、公差分析模块。这也是为什么热搜词里反复出现STL、STEP、GLB：STL是3D打印的通用交付物，但丢失拓扑关系；GLB是Web端轻量化展示格式，但无法用于CNC编程；只有STEP（尤其是AP242）能承载完整的参数化特征、材料定义、GD&T公差标注——text-to-cad的终极出口，必须锚定在这里。

我去年帮一家医疗耗材厂落地过类似方案，他们每天收30+份医生手写的“定制导板需求”，以前靠两位老工程师手工建模，平均单件耗时47分钟，错误率12%（主要是螺钉孔位与CT影像坐标系对不齐）。接入text-to-cad流程后，输入“左侧股骨近端导板，匹配CT重建数据，预留3枚Φ3.2mm导向孔，孔轴线与股骨颈轴线夹角125°±2°”，系统18秒生成STEP文件，自动完成坐标系对齐、孔位干涉检查、壁厚安全校验，错误率降至0.3%。关键不是快，而是把“医生意图→临床需求→几何约束→制造要求”这条链路第一次真正打通了。

2. text-to-cad的技术栈真相：不是大模型单打独斗，而是四层精密咬合

很多人以为text-to-cad就是给大模型喂一堆CAD图纸训练一下，然后输入文字吐出STL。这种理解就像以为“会写菜谱=能开米其林餐厅”——漏掉了中间最关键的三道工序。真正的text-to-cad系统，是四个技术层严丝合缝咬合的精密齿轮组，缺一不可。

2.1 第一层：领域语义解析器（不是通用NLP）

通用大模型（如LLaMA、Qwen）在CAD语境下会严重“水土不服”。它可能把“M8×1.25螺纹”识别为“品牌M8的1.25系列”，把“C3公差”理解成“三级精度”，因为训练语料里缺乏工程术语的强约束定义。我们实际采用的是双通道语义解析架构：

• 主通道：基于ISO/ANSI/DIN标准构建的轻量级领域语法树（Grammar Tree），用PEG（Parsing Expression Grammar）定义规则。例如“Φ20H7”被强制拆解为{直径符号:Φ, 公称尺寸:20, 公差带:H7}，任何偏离该结构的输入都会触发语义校验失败；
• 辅通道：微调后的领域专用小模型（700M参数），仅在百万级真实工程文档（BOM表、技术协议、检验报告）上训练，专注处理模糊表达。比如用户输入“差不多20个厚”，模型会结合上下文（当前部件类型是机架立柱）推断出“20mm±0.5mm”，而非盲目匹配“20”这个数字。

提示：千万别用ChatGLM直接接CAD内核！我们踩过的坑是——模型把“R5圆角”生成为半径5的球体（sphere），而不是倒圆角特征（fillet feature），导致后续布尔运算完全失效。根源在于通用模型缺乏“特征操作”的概念认知，必须用语法树先锁死操作类型。

2.2 第二层：参数化特征映射引擎（核心价值所在）

这是text-to-cad区别于普通3D生成的关键分水岭。生成一个STL网格顶多算“画图”，而生成可编辑的参数化特征才是“建模”。我们的映射引擎采用双向约束图（Bidirectional Constraint Graph）实现：

• 输入端：将解析出的语义单元（如“长度120mm”、“两端M6螺纹”）映射为特征操作序列（extrude→thread→mirror）；
• 输出端：反向验证每个特征是否满足工程约束（如M6螺纹要求最小壁厚≥3mm，若主体直径仅10mm则触发冲突告警）。

举个实操案例：输入“带散热片的铝制电机座，底板10mm厚，散热片高25mm、厚3mm、间距8mm”。引擎不会直接生成网格，而是构建这样的特征链：

1. 创建基准面 → 拉伸底板（10mm）
2. 在底板顶面创建草图 → 阵列散热片轮廓（3mm厚）
3. 拉伸散热片（25mm）→ 自动添加拔模角（1.5°，铝压铸工艺要求）
4. 对整个体进行材料赋值（Al6061-T6，密度2.7g/cm³）
5. 最终输出含完整特征树的STEP文件，SolidWorks打开后可双击修改任意参数。

2.3 第三层：几何内核适配层（决定能否真用）

很多开源方案卡死在这里：生成的几何体在FreeCAD里能打开，但在NX里报“无效拓扑”。根本原因是不同CAD内核对几何体的容错性差异极大。我们的适配层做了三件事：

• STEP AP242优先：所有输出强制通过STEP Part 242验证（使用Open CASCADE的STEP Checker），确保包含完整的B-rep拓扑、参数化特征、GD&T标注；
• 内核桥接协议：针对主流商业软件（SolidWorks/NX/Inventor）开发专用插件，不依赖通用STL导入，而是调用其原生API（如SolidWorks的ISwModel接口）直接注入特征；
• 降级兜底机制：当目标内核不支持某特征（如Inventor不支持变螺距螺纹），自动切换为“近似几何体+注释说明”，而非直接报错中断流程。

2.4 第四层：制造就绪校验环（闭环的最后一环）

text-to-cad的终点不是生成文件，而是确保文件能制造。我们在输出前嵌入实时校验环：

• 可制造性检查（DFM）：调用Materialise Magics内核检查壁厚、悬臂、拔模角；
• 公差传递分析：基于ASME Y14.5标准，自动标注关键尺寸公差；
• BOM自动生成：从几何体提取材料、重量、表面积，生成Excel格式BOM表。

这套四层架构跑通后，我们发现一个反直觉现象：模型参数越大，text-to-cad效果反而越差。13B模型在语义解析准确率上只比3B模型高2.3%，但推理延迟增加4倍，且特征映射错误率上升。最终选型是7B模型+强规则引擎，把80%的确定性逻辑交给语法树，20%的模糊处理交给模型——这才是工业场景的务实选择。

3. 从文字到STEP：一个真实需求的全流程拆解

现在我们来走一遍完整流程。假设你要为一台定制化包装机设计一个“可调节张力的薄膜导向辊”，需求描述如下：

“直径80mm，长度150mm，表面镀铬，两端带Φ20mm通孔，孔中心距120mm，辊体中部有4条轴向凹槽，每条槽宽5mm、深1.2mm、R0.3底部圆角，槽间距均匀分布。”

别急着复制粘贴，先看这个需求里藏着多少工程陷阱：

• “直径80mm”是指外径还是基体直径？（镀铬层厚0.03mm，必须明确基准）
• “Φ20mm通孔”是贯穿辊体还是止于某深度？（影响轴承安装方式）
• “轴向凹槽”是铣削加工还是滚压成型？（决定底部圆角是R0.3还是R0.5）
• “槽间距均匀分布”指圆周均布还是轴向均布？（原文未说明，需结合“轴向凹槽”判断为圆周均布）

3.1 语义解析阶段：把模糊需求变成机器可读指令

系统首先启动双通道解析：

• 语法树识别出硬约束：{直径:80mm, 长度:150mm, 表面处理:镀铬, 孔径:Φ20mm, 孔中心距:120mm, 凹槽数量:4, 槽宽:5mm, 槽深:1.2mm, 底部圆角:R0.3}；
• 小模型根据上下文（“薄膜导向辊”）补充隐含约束：
  • 基准面为辊体外圆柱面（镀铬层作为功能表面）；
  • 通孔为贯穿孔（轴承需两端固定）；
  • 凹槽为圆周均布（轴向凹槽在圆周方向排列）；
  • 材料默认为S45C（中碳钢，调质处理，硬度HRC28-32）。

注意：这里有个关键技巧——我们给小模型加了“工程常识知识库”，包含2000+条行业默认规则。比如遇到“导向辊”，自动关联“表面硬度≥HRC55”、“动平衡等级G2.5”，这些不会出现在原始需求里，但缺失会导致零件报废。

3.2 特征映射阶段：生成可编辑的参数化模型

解析结果送入映射引擎，构建特征操作序列：

1. 创建圆柱体（直径80mm，长度150mm）→ 设置材料S45C；
2. 创建两个基准面（距离两端面20mm）→ 拉伸Φ20mm通孔（贯穿）；
3. 创建圆周阵列基准面（4等分）→ 在每个基准面上绘制矩形槽轮廓（5mm×1.2mm）→ 拉伸切除（R0.3圆角）；
4. 添加表面处理注释（镀铬，厚度0.03mm）；
5. 自动标注关键尺寸：外径Φ80h6、孔径Φ20H7、中心距120±0.1mm。

此时生成的不是STL，而是含完整特征树的STEP AP242文件。你在SolidWorks里打开，能看到清晰的“拉伸1”、“切除-拉伸1”、“圆周阵列1”等特征，双击任一特征即可修改参数——这才是真正的CAD模型。

3.3 几何内核适配阶段：确保无缝接入现有工作流

文件生成后，系统根据你的CAD软件自动选择输出策略：

• 若目标为SolidWorks：调用SW API直接创建新零件，特征树实时同步；
• 若目标为NX：生成JT格式（轻量化）+ STEP AP242（制造用）双文件包；
• 若目标为本地无CAD环境：提供WebGL预览（GLB格式），支持旋转、剖切、尺寸测量。

我们实测过不同格式的兼容性：

结论很明确：AP242是唯一能同时满足设计、仿真、制造全链路的格式。这也是为什么热搜词里“STEP”始终排在“STL”前面——懂行的人早就在押注这个标准。

3.4 制造就绪校验阶段：堵住最后一道质量缺口

在文件交付前，系统自动运行校验环：

• DFM检查：凹槽底部圆角R0.3与刀具最小半径匹配（确认可用Φ0.6mm球头铣刀加工）；
• 公差分析：Φ80h6外径与Φ20H7孔径的同轴度要求≤0.05mm，系统自动添加GD&T标注；
• BOM生成：输出Excel表格，含材料、重量（2.3kg）、表面积（0.38m²）、镀铬成本估算（¥127.5）。

整个流程从输入文字到获得可制造文件，耗时23秒（本地部署，RTX4090服务器）。对比人工建模：资深工程师需42分钟，新手需117分钟，且人工版本有17%概率遗漏“镀铬层厚度”这一关键制造参数。

4. 现实落地中的血泪教训：那些没人告诉你的坑

text-to-cad听起来很美，但真正在工厂落地时，90%的失败不是技术问题，而是对工程现实的误判。我把踩过的坑按严重程度排序，给你划重点：

4.1 坑一：把“能生成”当成“能用”，忽略制造工艺链

最典型的错误是——生成了一个完美的STEP文件，结果车间师傅说：“这玩意儿没法加工”。原因在于text-to-cad系统没接入工艺知识库。比如输入“R0.1圆角”，系统生成了，但实际CNC刀具最小半径是R0.2，强行加工会导致刀具崩刃。我们后来加了三层工艺过滤：

• 刀具库映射：内置2000+种常用刀具参数（球头铣刀、钻头、丝锥），生成特征时自动校验可行性；
• 工艺路线绑定：为不同材料（铝/钢/钛合金）预设默认工艺（车削→铣削→热处理→表面处理），避免生成“需线切割但未标注”的结构；
• 供应商能力对接：接入本地3家合作加工厂的设备清单，当用户指定“本地产”时，自动排除超限尺寸（如>800mm的零件）。

实操心得：第一次上线时，我们生成了一个“Φ120mm×300mm的薄壁筒体”，壁厚2mm。系统通过了所有校验，但工厂反馈：“这玩意儿车削时会震刀，必须加厚到3.5mm”。后来我们把“薄壁件振动阈值”写进工艺规则，现在遇到类似结构会主动提示：“建议壁厚≥3.5mm，或改为分段焊接”。

4.2 坑二：过度依赖大模型，导致特征语义漂移

曾有个客户输入“带法兰的泵壳”，模型把“法兰”理解成“焊接法兰”（WN），但实际需求是“松套法兰”（SL）。问题出在训练数据里，90%的泵壳图纸用的是WN法兰，模型形成了路径依赖。解决方案是：

• 特征白名单机制：对关键特征（法兰类型、螺纹制式、轴承型号）建立强制选择列表，用户输入“法兰”时，弹出选项：[WN, SL, SO, TH]；
• 上下文锚定：当检测到“泵壳”时，自动加载液压行业模板，优先推荐SL法兰（因泵壳常需拆卸维护）；
• 人工复核开关：所有关键特征生成后，弹出“确认面板”，显示标准号（如GB/T 9119-2010）、适用场景、替代方案。

这个改动让关键特征错误率从18%降到0.7%，代价是用户多点两次鼠标——但在工程领域，这点交互成本远低于返工损失。

4.3 坑三：忽略企业知识资产，沦为通用工具

很多企业买了text-to-cad系统，用了一周就闲置。原因很简单：它不认识你们的“内部黑话”。比如某汽车厂把“减震垫”叫“胶墩”，把“线束固定卡”叫“蜈蚣扣”。系统按标准术语解析，结果“胶墩”被当成“橡胶垫块”，尺寸公差全错。我们的解法是：

• 企业术语映射表：允许上传Excel，定义{内部名称:标准名称, 参数映射规则}，如“胶墩→减震垫，厚度=客户编号后两位×0.5mm”；
• 历史数据自学习：分析企业过去3年的BOM表、图纸命名规则，自动提取高频词和参数逻辑；
• 审批流集成：生成的模型自动进入PLM系统审批流，工程师可在模型上直接批注“此处应为胶墩，按Q/JT-2023标准执行”。

现在这家车企的text-to-cad使用率是92%，因为系统生成的第一个模型就用了他们真实的“胶墩”参数，工程师觉得“这玩意儿懂我”。

4.4 坑四：低估数据安全红线，触碰合规雷区

有客户想把text-to-cad部署在公有云，结果法务部一票否决。原因在于：

• STEP文件含完整几何拓扑，可逆向还原设计；
• 训练数据若含企业图纸，可能涉及知识产权风险；
• 某些行业（军工、医疗）明确禁止设计数据出境。

我们的应对方案是：

• 纯本地化部署：所有模型、规则、知识库全部装在客户内网服务器，连外网都不通；
• 联邦学习架构：多家客户联合训练时，只共享梯度参数，不传输原始图纸；
• 水印追踪：在STEP文件元数据中嵌入不可见水印（如生成时间戳、用户ID哈希），一旦泄露可溯源。

最后分享个真实案例：某医疗器械公司用text-to-cad生成手术导板，FDA审核时要求提供“模型生成全过程可追溯性”。我们提供的日志包含：原始需求文本→语义解析结果→特征映射步骤→工艺校验报告→BOM生成记录，整整47页PDF。审核员说：“这是我见过最透明的AI生成证明”。

5. 不只是工具：text-to-cad正在重构设计协同的底层逻辑

text-to-cad的价值，最终会体现在组织协作模式的改变上。它正在把过去“串行式”的设计流程，变成“并行式”的语义协同网络。

传统流程是：销售听客户需求→写技术协议→工程师建模→工艺审核→采购询价→反复修改。一个需求平均改5.3版，耗时11天。而text-to-cad催生的新模式是：

• 销售端：用手机APP录入需求（语音转文字），系统实时生成3D预览（GLB），客户当场确认结构；
• 工程端：收到的不是Word文档，而是带语义标签的JSON包（含所有约束条件），直接拖入CAD系统生成模型；
• 采购端：BOM表自动生成，材料价格、交期、替代料号实时联动；
• 生产端：STEP文件直通MES系统，NC程序自动编排。

我们帮一家电梯配件厂实施后，订单交付周期从22天压缩到7.5天，其中设计环节从8.2天降到1.3天。更关键的是，客户投诉率下降63%——因为“客户想要的”和“工程师做的”第一次真正对齐了。

但这不是终点。text-to-cad正在向两个方向进化：

• 向上游延伸：对接ERP/MES，当采购系统发出“缺Φ8mm螺栓”的预警，text-to-cad自动触发“生成备用支架”的任务，输入“适配现有安装孔，承重≥50kg”，10秒生成新模型；
• 向下游渗透：与数字孪生平台打通，生成的STEP模型自动加载到产线虚拟调试环境中，提前验证装配干涉。

最后说个个人体会：干了十年CAD相关项目，第一次看到工程师笑着对我说“这需求真好画”。不是因为AI多厉害，而是因为——我们终于把工程师从“人肉翻译”的苦役中解放出来，让他们回归到真正该做的事：解决复杂问题，而不是重复输入坐标。text-to-cad的本质，从来不是替代人，而是让人重新成为不可替代的人。