NVIDIA SoL-Pi 开源：Agent 重复 Token 开销的结构化复用方案
2026/10/27 7:55:46
1. 什么是text-to-cad：不是“文字生成图纸”的噱头，而是工程语义落地的临门一脚
“text-to-cad”这个词最近在工业软件、机器人仿真和智能制造圈里频繁冒头，但它绝不是把“画一个直径50mm的圆柱体，高80mm，带M6螺纹孔”这种自然语言直接扔给AutoCAD就能蹦出.dwg文件的魔法。我从2015年开始做机械结构设计自动化，后来带团队开发过三套面向产线的CAD辅助建模系统，实打实踩过所有坑——真正能跑通的text-to-cad，本质是工程语义解析 + 参数化建模引擎 + 标准格式桥接三位一体的闭环。它解决的不是“会不会画”，而是“能不能让非CAD专业人员（比如算法工程师、ROS开发者、产线工艺员）用最接近日常表达的方式，驱动专业级几何建模流程”。你看热搜词里反复出现的URDF、STEP、DXF，恰恰暴露了它的真实战场：不是替代设计师，而是打通从需求描述→仿真模型→制造数据的断点。比如机器人工程师写完URDF后想快速生成对应机械臂连杆的实体模型用于碰撞检测，或者工厂工艺员在MES系统里输入“冲压件：料厚1.2mm，材质SPCC，折弯R1.5，展开尺寸320×180”，系统自动生成可导入激光切割机的DXF——这才是text-to-cad正在啃的硬骨头。它不追求艺术性渲染，而死磕几何拓扑的严谨性、参数约束的可追溯性、以及输出格式（STEP/IGES/DXF/URDF）与下游工具链的零摩擦兼容。所以别被“text-to-image”带偏节奏：这里没有扩散模型的模糊美感，只有布尔运算的精确交并差、草图约束求解器的收敛判定、以及B-rep边界表示中面片法向量的一致性校验。
2. 核心技术栈拆解：为什么90%的开源项目卡在“能跑但不能用”
2.1 工程语义理解：远比NLP任务更苛刻的“领域语言翻译”
普通文本生成模型（如LLM）处理“画个杯子”没问题，但面对“Φ40H7孔，公差±0.012，表面粗糙度Ra1.6，沉头深度12mm，沉头直径Φ8.5”就彻底失灵。原因在于工程语言有三重嵌套结构：
- 语法层：必须识别尺寸标注（Φ40）、公差代号（H7）、表面处理（Ra1.6）等符号体系；
- 语义层：H7代表基孔制、上偏差+0.025/下偏差0，这需要查GB/T 1800标准表，而非简单词嵌入；
- 拓扑层：“沉头深度12mm”隐含与主孔轴线的垂直关系，“沉头直径Φ8.5”要求与主孔直径形成同心约束——这些空间关系必须转化为建模引擎可执行的几何约束。
我团队曾用BERT微调做初步实体识别，准确率卡在68%，失败根源在于训练数据匮乏：公开CAD图纸文本标注集（如CAD-1K）只标注“孔”“槽”“凸台”，不标注“H7”“Ra1.6”“沉头”等工艺属性。最终方案是放弃端到端，改用规则引擎+轻量级NER双轨制：先用正则匹配识别尺寸/公差/表面符号（如r'Φ\d+\.?\d*H[0-9]'），再用小模型判断上下文（如“沉头”必接“深度”“直径”“角度”）。实测下来，规则部分覆盖83%高频指令，模型补全剩余17%歧义场景（如“R2倒角”可能指圆角或倒角，需结合后续动词判断）。
2.2 参数化建模引擎：OpenCASCADE不是万能钥匙，FreeCAD才是务实选择
很多人一上来就想对接OpenCASCADE（OCC），觉得它底层扎实。但OCC的C++ API对Python生态极不友好，调试时崩溃堆栈像天书，且缺乏现成的特征建模封装（如拉伸、旋转、扫掠的高层接口）。我们对比测试过四种引擎：
- OCC原生API：几何精度最高，但开发效率极低，一个简单拉伸特征需手写200+行代码定义拓扑、曲面、参数；
- pythonOCC封装：简化了部分操作，但文档残缺，社区支持弱，遇到布尔运算失败只能靠猜；
- Blender Python API：建模自由度高，但NURBS曲面支持弱，导出STEP时丢失精度，不适合机械零件；
- FreeCAD Python API：真正破局者。它把参数化建模抽象为“对象+属性+依赖关系”，例如创建圆柱体只需：
import FreeCAD, Part cyl = Part.makeCylinder(25, 80) # 半径25mm，高80mm obj = doc.addObject("Part::Feature", "Cylinder") obj.Shape = cyl更关键的是，FreeCAD原生支持约束求解器（Sketcher）和装配体层级（A2P），能直接将文本解析出的“同轴”“垂直”“距离15mm”等关系映射为约束对象。我们实测：同样生成带螺纹孔的法兰盘，FreeCAD脚本耗时1.2秒，OCC原生实现需17秒且需手动修复拓扑错误。
2.3 格式桥接层：DXF/STEP/URDF不是简单导出，而是语义保真转换
热搜词里“urdf导入coppeliasim”“cad转pdf”暴露了痛点：格式转换常丢失关键信息。
- DXF问题：AutoCAD DXF的ACAD版本碎片化严重（R12/R2000/R2018），开源库ezdxf默认导出R2010，但老式数控机床只认R12的实体（ENTITIES）段，不支持ACAD_HEADER。我们被迫在导出前做降级处理：禁用图层、块引用、文字样式，仅保留LINE/CIRCLE/ARC实体，并用
dxf.write_file()强制指定version='AC1009'。 - STEP问题：FreeCAD导出STEP默认用AP203（几何为主），但下游CAE软件（如ANSYS）要求AP214（含材料、公差、装配关系）。解决方案是调用
Part.export([obj], 'part.stp', 'STEP')时传入write_shape=True参数，并预设obj.Material = 'Steel'属性。 - URDF问题：URDF本质是XML，但text-to-cad需反向生成——把几何体坐标系、惯性张量、关节类型填入模板。难点在于：FreeCAD的
Placement矩阵（位置+旋转）需转换为URDF的origin（xyz+rpy），而rpy欧拉角存在万向节死锁。我们采用四元数中间态转换：先获取obj.Placement.Rotation.Q，再用scipy.spatial.transform.Rotation.from_quat().as_euler('xyz')计算，实测避免99%的rpy跳变错误。
3. 实操全流程：从“画个支架”到生成可加工DXF的完整链路
3.1 输入解析：构建可扩展的指令语法树
我们定义text-to-cad的最小指令单元为：[动作] [对象] [参数] [约束]。例如：“创建长方体支架，长300mm宽200mm高50mm，顶部开Φ12通孔，孔中心距左边缘80mm距前边缘60mm”。解析步骤：
- 动作识别：用规则匹配“创建”“生成”“绘制”等动词，映射为
create_primitive函数； - 对象提取：“长方体支架”→
Box基类，“Φ12通孔”→Hole子类； - 参数抽取：正则
r'(\d+\.?\d*)\s*(mm|cm)'捕获数值，单位统一转mm； - 约束绑定：“距左边缘80mm”→ 孔中心X坐标=80，“距前边缘60mm”→ Y坐标=60。
关键技巧：用AST（抽象语法树）管理依赖关系。当指令含多个对象时（如“支架上安装L型连接板”），生成树节点：
Root ├─ Box (name: bracket, size: [300,200,50]) └─ Plate (name: l_plate, size: [100,60,8]) └─ Constraint: l_plate.Placement.Base.z = bracket.Placement.Base.z + 50这样后续建模时，FreeCAD可自动按依赖顺序创建对象，并在装配体中建立位置关联。
3.2 建模执行：FreeCAD脚本的避坑实录
以下是从解析结果生成FreeCAD模型的核心代码（已脱敏生产环境）：
# 1. 创建文档与主支架 doc = FreeCAD.newDocument("text2cad") bracket = doc.addObject("Part::Box", "Bracket") bracket.Length = 300.0 bracket.Width = 200.0 bracket.Height = 50.0 # 2. 创建孔特征（关键：必须用PartDesign工作台，否则无法布尔减） # 先建圆柱体，再与支架布尔运算 hole_cyl = doc.addObject("Part::Cylinder", "HoleCyl") hole_cyl.Radius = 6.0 # Φ12 → R6 hole_cyl.Height = 100.0 # 高于支架厚度，确保穿透 hole_cyl.Placement = FreeCAD.Placement( FreeCAD.Vector(80, 60, 0), # X,Y坐标按约束设置 FreeCAD.Rotation(FreeCAD.Vector(0,0,1), 0) # Z轴朝上 ) # 3. 执行布尔减（核心陷阱：顺序错误导致失败） # 必须用Part::Cut而非Part::Fuse，且支架在前、孔在后 cut = doc.addObject("Part::Cut", "BracketWithHole") cut.Base = bracket cut.Tool = hole_cyl # 4. 强制更新拓扑（FreeCAD常见bug：不刷新则导出为空） doc.recompute() # 5. 导出DXF（适配老设备的关键配置） import ezdxf dwg = ezdxf.new(dxfversion='AC1009') # 强制R12 msp = dwg.modelspace() # 提取切削后的外轮廓线（忽略内部孔线） for edge in cut.Shape.Edges: if hasattr(edge.Curve, 'toShape'): # 过滤非直线/圆弧 line = edge.Curve.toShape() if line.ShapeType == 'Line': msp.add_line((line.Vertexes[0].Point.x, line.Vertexes[0].Point.y), (line.Vertexes[1].Point.x, line.Vertexes[1].Point.y)) dwg.saveas("bracket_r12.dxf")提示：FreeCAD的
Part::Cut有时因拓扑不一致失败。我们的应急方案是：先用Part.makeBox()生成原始支架，再用Part.makeCylinder()生成孔，最后调用bracket_shape.cut(hole_shape)——绕过GUI对象，直操作Shape对象更稳定。
3.3 格式输出：针对不同下游工具的定制化导出策略
| 下游工具 | 格式 | 关键配置项 | 常见故障 |
|---|---|---|---|
| 激光切割机 | DXF | 版本AC1009，仅保留LINE/CIRCLE/ARC，关闭图层、文字、块引用 | 设备报“不支持实体类型” |
| SolidWorks | STEP | AP214协议，设置obj.Material='Aluminum'，导出前doc.recompute() | 导入后显示“几何体无效” |
| CoppeliaSim | URDF | <inertial>中<mass>设为1.0（仿真用），<visual>用STL而非DAE（兼容性好） | 关节运动时模型抖动 |
| 3D打印切片软件 | STL | 三角化精度meshdeviation=0.05，禁用smooth=False（避免曲面失真） | 切片后出现孔洞或面片翻转 |
实操心得：URDF导出必须分两步走。第一步用FreeCAD生成STL（Part.export([obj], 'part.stl')），第二步用Python脚本填充URDF XML模板。因为FreeCAD的URDF导出插件（如urdf_exporter）不支持自定义惯性参数，而仿真精度高度依赖<inertia>矩阵。我们模板中预留占位符：
<link name="${link_name}"> <inertial> <mass value="${mass}"/> <inertia ixx="${ixx}" iyy="${iyy}" izz="${izz}" ixy="${ixy}" ixz="${ixz}" iyz="${iyz}"/> </inertial> </link>质量参数通过obj.Shape.Volume * density计算，惯性矩阵用obj.Shape.MatrixOfInertia获取——这是FreeCAD隐藏的宝藏属性，官方文档几乎不提。
4. 真实场景复盘：三个典型应用案例的成败细节
4.1 案例一：机器人URDF快速原型（成功）
需求：ROS开发者需为新设计的六轴机械臂生成URDF，包含12个连杆、6个旋转关节、末端夹爪。
text-to-cad指令：
“生成机械臂URDF：基座尺寸300×300×50mm，连杆1长450mm直径60mm，连杆2长380mm直径50mm，...，所有连杆材质铝合金，关节类型revolute，轴线Z向，减速比1:100”
执行过程：
- 解析出12个
Cylinder对象，按长度/直径参数化创建； - 用
Placement设置每个连杆的相对位置（如连杆2的Base.z = 连杆1.Base.z + 450）； - 关节定义为
<joint type="revolute">，<axis xyz="0 0 1"/>； - 材质统一设为
Aluminum，密度2700kg/m³。
成果：生成URDF可在RViz中正确显示，CoppeliaSim中运动学仿真无抖动。
关键经验：URDF的<origin>必须严格对应FreeCAD中Placement.Base和Placement.Rotation。我们发现FreeCAD的Rotation.Q四元数与ROS的rpy存在π/2偏移，最终在转换脚本中加入修正项：rpy[2] += math.pi/2（绕Z轴补偿）。
4.2 案例二：钣金件DXF批量生成（踩坑）
需求：钣金厂需将ERP系统中的BOM清单（含料厚、折弯角度、展开尺寸）自动转为DXF供激光切割。
text-to-cad指令：
“生成钣金件：料厚1.5mm，材质SUS304，折弯R2.0，展开尺寸420×280mm，右上角开Φ8.5沉头孔，沉头深3.0mm，沉头直径Φ12.0”
故障现象：导出DXF后，数控机床报错“沉头孔轮廓不闭合”。
根因分析：
- FreeCAD的
Part::Cylinder生成的沉头孔是三维实体，但DXF只需二维投影轮廓； ezdxf提取cut.Shape.Edges时，沉头孔的倒角边被识别为多段LINE，首尾未闭合；- 老式机床DXF解析器要求所有轮廓必须是
POLYLINE（闭合多段线），而非独立LINE。
解决方案：
- 不用布尔运算，改用草图（Sketcher）绘制沉头孔二维轮廓：
sketch = doc.addObject('Sketcher::SketchObject', 'HoleSketch') sketch.addGeometry(Part.Circle(App.Vector(420-8.5, 280-8.5, 0), App.Vector(0,0,1), 4.25)) # Φ8.5 sketch.addGeometry(Part.Circle(App.Vector(420-8.5, 280-8.5, 0), App.Vector(0,0,1), 6.0)) # Φ12.0 sketch.solve() # 自动添加同心约束- 将草图投影到XY平面，导出为
POLYLINE：
polyline = sketch.Geometry[0].toShape() # 获取圆弧 msp.add_polyline2d([(v.x,v.y) for v in polyline.Vertexes]) # 强制闭合效果：机床一次通过，良品率100%。
4.3 案例三：建筑BIM构件参数化（半失败）
需求：建筑师输入“幕墙龙骨：截面矩形管200×100×6mm，长度6000mm，两端铣槽宽12mm深8mm”。
问题爆发点：
- “铣槽”在工程语境中是去除材料的特征，但text-to-cad系统误判为“添加槽体”；
- FreeCAD的
PartDesign工作台不支持沿路径的复杂槽特征（需用Part::Sweep，但语法超纲）； - 导出STEP后，BIM软件（Revit）无法识别槽特征，显示为完整矩形管。
临时对策： - 将“铣槽”降级为“开槽口”：用两个长方体布尔减模拟；
- 在STEP导出时启用
write_shape=True并手动添加obj.Label='MillingSlot'属性，供BIM插件二次解析。
教训：text-to-cad当前能力边界清晰——擅长规则几何体（箱体、回转体、孔槽）和标准特征（倒角、圆角、阵列），不擅长自由曲面、扫描路径、复杂布尔组合。遇到“铣槽”“滚花”“渐变厚度”等指令，必须预设fallback机制：返回人工干预提示，而非强行生成错误模型。
5. 常见问题速查表：那些让你加班到凌晨的致命细节
| 问题现象 | 根本原因 | 解决方案 |
|---|---|---|
FreeCAD脚本运行时报AttributeError: 'NoneType' object has no attribute 'Shape' | 对象未成功创建或recompute()未执行，Shape属性为空 | 在关键对象创建后插入if obj.Shape.isNull(): raise Exception("Shape not generated") |
| 导出STEP文件在SolidWorks中显示“空几何体” | FreeCAD文档未激活（App.activeDocument()返回None），或对象未加入文档 | 显式调用doc = FreeCAD.newDocument()，所有对象用doc.addObject()创建 |
| DXF导入AutoCAD后尺寸缩放100倍 | ezdxf默认单位为毫米，但AutoCAD视口按英寸解析（1英寸=25.4mm） | 在DXF头部添加$INSUNITS=4（毫米单位），或导出后用AutoCAD的SCALE命令校正 |
| URDF在Gazebo中模型悬浮不接地 | <inertial>中<origin>未设为质心，或<collision>几何体与<visual>不一致 | 用obj.Shape.CenterOfMass获取质心，设为<origin>；<collision>用简化STL |
| 多个孔特征布尔运算后模型消失 | 孔之间距离过近导致拓扑退化（如两孔相交处生成零厚度面） | 在孔创建前添加间距检查：min_distance > 2*max_radius，否则合并为单个复合孔 |
FreeCAD启动报ImportError: No module named 'PySide2' | 系统Python环境与FreeCAD内置Python冲突，或PySide2版本不匹配 | 使用FreeCAD自带Python解释器（/path/to/FreeCAD/FreeCADCmd），禁用系统pip安装 |
| text-to-cad生成的模型与原始CAD图纸公差不符 | 解析时忽略公差代号（如H7），仅取标称尺寸，未查表获取上下偏差 | 建立GB/T 1800公差表字典，h7_tolerance = {40: (0, 0.025)}，建模时用obj.Length = 40 + 0.025 |
注意：FreeCAD的
Part::Box默认以原点为中心创建，但工程图纸尺寸通常以左下角为基准。务必用obj.Placement.Base = FreeCAD.Vector(length/2, width/2, height/2)校正，否则所有相对定位全错。
6. 工具链选型建议：别被“最新技术”忽悠，稳才是生产力
6.1 不推荐的“炫技方案”
- 纯LLM端到端生成：用CodeLlama生成FreeCAD脚本，看似聪明，实则灾难。我们测试过：LLM生成的脚本有37%概率漏掉
doc.recompute()，28%写错Placement向量维度（如Vector(x,y)少写z），15%混淆Part::Box与Part.makeBox()——这些错误FreeCAD不报错，但导出模型为空。 - WebGL在线CAD引擎（如Three.js + OpenJSCAD）：适合展示，但几何引擎不支持STEP导出，且布尔运算精度不足（容差0.1mm vs 工业级0.001mm）。
- 商业API服务（如Onshape API）：调用方便，但每千次请求收费$20，且无法定制URDF导出逻辑，对产线部署不友好。
6.2 经验证的黄金组合
核心栈：
- 解析层：spaCy + 自定义规则（
regex+pandas查表） - 建模层：FreeCAD 0.21（Python 3.10兼容性最佳） +
pymeshlab（STL后处理） - 导出层：
ezdxf（DXF）、python-opencascade（STEP高级控制）、xml.etree.ElementTree（URDF模板）
部署要点：
- FreeCAD必须以
--console模式运行（无GUI），否则Linux服务器会因缺少X11崩溃； - 用
docker run -v $(pwd):/workspace -w /workspace freecad/freecad:0.21隔离环境； - 所有脚本开头强制
sys.path.append('/usr/lib/freecad/lib')，避免模块找不到。
实操心得：FreeCAD的
Part.show()在无头模式下会失败，必须用Part.export([obj], 'output.step')替代。我们曾为这行代码调试3小时——日志里只报Segmentation fault，最终发现是显卡驱动冲突，换成freecad/freecad:0.21镜像才解决。
7. 未来演进方向：text-to-cad不会取代CAD，但会重塑工作流
text-to-cad的终极形态不是让AI代替工程师画图，而是成为工程知识的操作系统。我们正在推进的三个方向：
- 语义校验前置：在用户输入指令时实时反馈可行性。例如输入“Φ12H7孔开在R5圆角上”，系统立刻提示“圆角半径5mm < 孔半径6mm，无法加工”，并建议“增大圆角至R8或减小孔径至Φ10”。这需要集成GD&T（几何尺寸与公差）规则引擎，目前用
geometric_constraints.py硬编码200+条规则。 - 多源数据融合：将ERP/BOM中的材料、工艺数据自动注入模型。如输入“支架”，系统查BOM得“材质Q235，表面镀锌”，自动设置
obj.Material='Q235'并添加<surface_treatment>Galvanized</surface_treatment>到URDF扩展字段。 - 逆向text-to-cad：从现有CAD图纸反推文本描述。用OpenCV识别DXF中的尺寸标注，OCR提取公差符号，再生成“长方体，300×200×50mm，四角R10，正面Φ12H7孔×4”——这能让老图纸快速数字化，我们已在某汽车配件厂落地，效率提升17倍。
我个人在实际使用中发现：text-to-cad的价值不在“从零生成”，而在“消除重复劳动”。一个机械工程师每天要画30个类似支架，其中28个只是尺寸微调。现在他只需说“复制上一个，长改320，宽改220”，系统1秒生成新模型。省下的时间，足够他去思考那个真正需要创新的2个特殊件。这或许就是技术该有的样子——不喧宾夺主，只默默托起人的创造力。