1. 从一句话到三维模型text-to-cad 到底在解决什么问题“text-to-cad”这个词最近在工程圈和开发圈里被提得越来越多但很多人第一次听到时的反应是用文字直接生成CAD模型这靠谱吗我一开始也这么想。直到自己动手把一条自然语言描述跑通成STEP文件再导入到仿真环境里验证尺寸才意识到这件事的价值不在于“替代工程师”而在于把重复性的建模劳动压缩掉。先说清楚它是什么。text-to-cad 本质上是一套把自然语言文本映射为参数化几何模型的流程。你输入“一个长80毫米、宽40毫米、厚5毫米的矩形板四角各有一个直径4毫米的圆孔孔中心距边缘8毫米”系统输出一个可以被CAD软件读取的实体模型文件常见格式包括STEP、DXF、URDF等。它解决的核心问题是大量标准化、参数化的零件建模工作其实不需要人手动在界面里点几十次草图约束完全可以用文本描述加脚本生成。适合谁来参考三类人最受益。第一类是机械设计工程师尤其是经常做系列化零件、标准件库的用文本驱动能省掉大量重复劳动。第二类是机器人方向的开发者URDF文件描述机器人连杆几何时手写XML很容易出错用文本生成几何再导出URDF会稳很多。第三类是做CAD二次开发的程序员Python批量修改CAD图纸、DXF脚本源码这类需求本质上和text-to-cad是同一套技术栈。但这里有个前提必须说清楚text-to-cad 目前擅长的是规则明确、参数可枚举的几何体比如板、轴、法兰、支架、简单装配体。对于自由曲面、复杂有机形状、需要大量审美判断的外观件它还不现实。所以别指望一句话生成一个汽车外壳但让它生成一百个不同规格的安装板它比人快得多。我实测下来的感受是这套流程的瓶颈往往不在“文本理解”那一步而在几何内核的稳定性和格式转换的兼容性上。下面我会把整个链路拆开从文本解析、几何构建、格式导出到仿真验证把每一步的坑和技巧都讲透。2. 文本描述怎么变成几何参数解析层的设计取舍2.1 为什么不能直接让大模型输出CAD命令很多人第一反应是让语言模型直接生成CAD软件的脚本命令比如AutoCAD的LISP或者FreeCAD的Python API调用。我试过这条路结论是能跑但极不稳定。原因在于语言模型对数值的精确控制很差你让它生成“直径4毫米的孔”它可能给你写成4.0、4、4.00甚至偶尔写成3.9。对于几何建模来说0.1毫米的偏差就可能导致装配失败。更合理的做法是把任务拆成两层第一层用语言模型做“语义解析”把自然语言转成结构化的参数字典第二层用确定性的几何内核代码根据参数字典生成模型。这样语言模型只负责理解意图不负责精确数值稳定性会高一个数量级。具体来说解析层的输出应该是一个JSON结构类似这样{ shape_type: plate, length: 80.0, width: 40.0, thickness: 5.0, holes: [ {diameter: 4.0, x: 8.0, y: 8.0}, {diameter: 4.0, x: 72.0, y: 8.0}, {diameter: 4.0, x: 8.0, y: 32.0}, {diameter: 4.0, x: 72.0, y: 32.0} ], units: mm }这个结构的好处是每一个字段都是可校验的。长度不能为负孔径不能大于板宽孔的位置不能超出边界。校验通过之后再进入几何构建出错概率大幅降低。2.2 单位问题是最容易被忽略的坑我踩过的第一个大坑就是单位。文本里说“长80”到底是毫米还是厘米如果解析层默认按毫米处理但用户心里想的是厘米生成出来的模型就差了十倍。更麻烦的是STEP文件本身是带单位信息的但DXF文件默认是无单位的导入到不同软件里可能被解释成英寸。我的处理方案是在解析层强制要求单位如果文本里没写就在输出前追问一次或者在参数字典里标记units: unknown并触发人工确认。对于批量生成场景我会在系统提示里明确要求用户必须带单位否则拒绝生成。这个策略听起来很笨但比生成一堆错误尺寸的模型再返工要高效得多。另外URDF文件对单位更敏感它默认使用米。如果你从STEP导出URDF中间要做一次毫米到米的换算这个换算如果漏掉导入CoppeliaSim之后机器人连杆会大一千倍整个场景直接没法看。2.3 孔位描述的歧义处理“四角各有一个孔孔中心距边缘8毫米”这句话不同的人理解可能不同。有人理解为孔中心到两条边的距离都是8毫米有人理解为孔中心到最近边的距离是8毫米。对于矩形板来说这两种理解结果一样但对于异形板就不一样了。我在解析层里会尽量把位置描述归一化成绝对坐标。如果用户给的是相对描述我会根据形状的包围盒计算出绝对坐标然后在参数字典里同时保留原始描述和计算后的坐标。这样一旦生成结果不对可以快速定位是解析理解错了还是几何计算错了。还有一个常见歧义是“均布”这个词。四个孔均布在板上到底是按边长均分还是按面积均分我的做法是默认按边长均分同时在文档里写清楚这个约定。如果用户有特殊需求必须显式说明。3. 几何内核选型为什么我最终选了Python加OpenCASCADE3.1 几种常见方案的对比做text-to-cad几何内核的选择直接决定了你能生成什么形状、导出什么格式、跑得多快。我前后试过四种方案下面这张表是我自己的实测对比方案优势劣势适合场景FreeCAD Python API免费功能全支持STEP/DXF启动慢依赖重偶尔崩溃单件生成交互式使用OpenCASCADE (pythonocc)内核稳定精度高速度快学习曲线陡文档少批量生成服务端部署CadQuery语法简洁基于OCCT复杂形状表达受限快速原型参数化零件直接生成DXF轻量无需内核只有二维无实体二维图纸切割路径我最终选择的是OpenCASCADE的Python绑定也就是pythonocc-core。原因有三点第一它是工业级内核STEP导出质量最稳第二它不依赖图形界面可以在服务器上跑第三它的布尔运算和倒角处理比CadQuery更可控。CadQuery其实也很好语法更友好但它在处理复杂装配体和自定义坐标系时抽象层太厚出了问题不好调试。对于text-to-cad这种需要精确控制的场景我宁愿多写几行代码也要把每一步都握在手里。3.2 从参数字典到实体的构建流程拿到解析后的参数字典构建流程大致分四步。第一步是创建基础形状比如用BRepPrimAPI_MakeBox生成一个长方体。第二步是创建特征比如用BRepPrimAPI_MakeCylinder生成圆柱体作为孔的刀具。第三步是布尔运算用BRepAlgoAPI_Cut从基础形状里挖掉孔。第四步是导出用STEPControl_Writer写STEP文件。这里有个细节值得说布尔运算的顺序会影响结果。如果你先挖孔再倒角倒角可能会因为孔的存在而失败。正确的顺序通常是先做主体形状再做倒角最后挖孔。但如果孔离边缘太近倒角又会和孔干涉。我的经验是对于孔中心距边缘小于孔径的场景先挖孔再倒角并且倒角半径要小于孔边到板边的距离。from OCC.Core.BRepPrimAPI import BRepPrimAPI_MakeBox, BRepPrimAPI_MakeCylinder from OCC.Core.BRepAlgoAPI import BRepAlgoAPI_Cut from OCC.Core.gp import gp_Pnt, gp_Ax2, gp_Dir from OCC.Core.STEPControl import STEPControl_Writer, STEPControl_AsIs # 创建基础板 plate BRepPrimAPI_MakeBox(80.0, 40.0, 5.0).Shape() # 创建孔并挖除 for hole in holes: axis gp_Ax2(gp_Pnt(hole[x], hole[y], -1.0), gp_Dir(0, 0, 1)) cylinder BRepPrimAPI_MakeCylinder(axis, hole[diameter]/2, 7.0).Shape() plate BRepAlgoAPI_Cut(plate, cylinder).Shape() # 导出STEP writer STEPControl_Writer() writer.Transfer(plate, STEPControl_AsIs) writer.Write(output.step)这段代码看起来简单但实际跑的时候孔的坐标需要根据板的坐标系做转换。如果板的原点不在左下角而是在中心那孔的坐标就要相应偏移。我在代码里会统一把板的原点设在左下角底面中心这样孔位计算最直观。3.3 精度控制与容差设置OpenCASCADE有一套自己的容差体系默认容差是1e-7米也就是0.0001毫米。对于大多数机械零件来说这个精度足够了但如果你生成的模型要用于3D打印或者精密装配可能需要调整。我遇到过一个诡异的问题两个应该完全重合的面在布尔运算时被判为不相交导致挖孔失败。排查后发现是浮点误差累积导致的。解决办法是在创建圆柱体时把圆柱的高度稍微加长一点确保它完全穿透板厚而不是刚好等于板厚。这个技巧在挖孔、开槽、切割等操作里都适用。另一个精度相关的坑是STEP导出的版本。STEP有AP203和AP214两个常见版本AP214支持颜色和图层信息AP203更通用。如果你生成的模型要导入到老版本的CAD软件里建议用AP203。如果需要在模型里保留颜色区分用AP214。4. 导出格式的实战差异STEP、DXF、URDF各踩各的坑4.1 STEP导出最稳但也最容易忽略坐标系STEP是text-to-cad最常用的输出格式因为它是实体模型包含完整的B-rep信息几乎所有CAD软件都能读。但STEP导出有一个隐藏问题坐标系。OpenCASCADE默认使用右手坐标系Z轴向上。但有些CAD软件默认Y轴向上导入时如果不做转换模型会躺倒。我的做法是在导出前显式设置坐标系并且在文件名或元数据里标注坐标系方向。如果下游是机器人仿真通常需要Z轴向上如果是建筑或土木方向可能Y轴向上更常见。这个信息如果不传递清楚下游用户会花很多时间在旋转模型上。还有一个实际问题是文件大小。一个包含几十个孔的板STEP文件可能只有几十KB但如果是一个复杂装配体STEP文件可能上百MB。对于批量生成场景我会在导出时做一次压缩去掉不必要的曲面细分数据。4.2 DXF导出二维图纸的轻量方案DXF是二维格式适合激光切割、线切割、钣金展开这些场景。text-to-cad生成DXF的逻辑和STEP不同它不需要实体只需要轮廓线。对于一块带孔的板DXF里就是外轮廓加四个圆。DXF的坑主要在图层和单位。默认导出的DXF可能把所有线条放在同一个图层里切割机操作员需要手动区分轮廓和孔。我的做法是在导出时自动分层外轮廓放一层孔放一层中心线放一层。这样下游处理起来方便很多。单位问题在DXF里更严重因为DXF文件头里虽然可以写单位但很多软件读的时候会忽略。我通常会在文件名里带上单位比如plate_80x40mm.dxf并且在导出后用一个简单的脚本检查一下包围盒尺寸确保和预期一致。4.3 URDF导出机器人仿真的特殊需求URDF是机器人描述格式它描述的是连杆的几何、惯性、关节关系。text-to-cad生成URDF的场景通常是为了快速搭建仿真环境。比如你要在CoppeliaSim里测试一个机械臂手头没有现成的模型可以用文本描述每个连杆的尺寸生成URDF再导入。URDF的几何部分支持几种基本形状box、cylinder、sphere。对于复杂形状需要用mesh文件通常是STL或DAE。我的做法是先用text-to-cad生成STEP再转成STL然后在URDF里引用STL文件。这样比直接在URDF里写基本形状灵活得多。这里有个大坑URDF的质量和惯性矩阵。如果你只写了几何形状没写惯性参数很多仿真器会用一个默认值导致动力学行为完全不对。我的做法是根据几何形状和材料密度自动计算质量和惯性矩阵。对于长方体惯性矩阵有解析解对于复杂形状可以用网格积分近似。link namebase_link visual geometry mesh filenamebase.stl scale0.001 0.001 0.001/ /geometry /visual collision geometry mesh filenamebase.stl scale0.001 0.001 0.001/ /geometry /collision inertial mass value0.5/ inertia ixx0.0001 ixy0 ixz0 iyy0.0002 iyz0 izz0.0002/ /inertial /link注意那个scale0.001 0.001 0.001这就是毫米转米的换算。如果漏掉导入CoppeliaSim之后模型会大一千倍整个场景都废了。这个坑我踩过不止一次后来在生成URDF的代码里强制加上这个缩放。5. 批量生成与Python自动化把text-to-cad变成生产力工具5.1 批量修改CAD图纸的典型场景text-to-cad最有价值的应用场景之一是批量生成系列化零件。比如你要做二十种不同长度的安装板长度从100毫米到500毫米其他参数不变。手动建模要重复二十次用text-to-cad只需要写一个循环。lengths [100, 120, 140, 160, 180, 200, 220, 240, 260, 280, 300, 320, 340, 360, 380, 400, 420, 440, 460, 480, 500] for length in lengths: params { shape_type: plate, length: length, width: 40.0, thickness: 5.0, holes: [ {diameter: 4.0, x: 8.0, y: 8.0}, {diameter: 4.0, x: length - 8.0, y: 8.0}, {diameter: 4.0, x: 8.0, y: 32.0}, {diameter: 4.0, x: length - 8.0, y: 32.0} ], units: mm } build_and_export(params, fplate_{length}mm.step)这段代码跑一遍二十个STEP文件就出来了每个文件的孔位都自动跟着长度调整。如果手动做光是改孔位坐标就要花不少时间还容易改错。5.2 参数校验比生成更重要批量生成最大的风险是某个参数超出合理范围导致生成失败或者生成出错误模型。比如长度设成负数或者孔径大于板宽。如果不在生成前校验跑到一半报错前面的文件可能已经覆盖了旧版本。我的做法是在解析层和几何层之间加一道校验。校验规则包括所有尺寸必须为正数孔径必须小于板宽和板厚孔位必须在板内且留有余量倒角半径必须小于最小边距。校验不通过就跳过这个零件记录到日志里而不是中断整个批次。def validate(params): errors [] if params[length] 0: errors.append(length must be positive) if params[width] 0: errors.append(width must be positive) for hole in params.get(holes, []): if hole[diameter] params[width]: errors.append(fhole diameter {hole[diameter]} exceeds width) if hole[x] hole[diameter]/2 or hole[x] params[length] - hole[diameter]/2: errors.append(fhole at x{hole[x]} is outside plate) return errors这个校验函数看起来简单但它拦住过很多低级错误。有一次我批量生成时把宽度写成了4.0而不是40.0校验直接报错避免了一百个废文件。5.3 日志与版本管理批量生成一定要有日志。每个零件生成了什么文件、用了什么参数、耗时多少、有没有警告都要记下来。这样出了问题可以追溯也方便对比不同批次的差异。版本管理方面我习惯把参数字典和生成的模型文件放在同一个目录下用时间戳区分批次。如果下游反馈某个模型有问题可以快速定位到对应的参数重新生成。6. 从模型到仿真URDF导入CoppeliaSim的完整链路6.1 为什么仿真环节最容易出问题text-to-cad生成的模型最终往往要导入到仿真环境里验证。CoppeliaSim是常用的机器人仿真软件它支持URDF导入。但导入过程经常出问题原因通常不在URDF本身而在模型文件的路径和缩放。CoppeliaSim导入URDF时会按照URDF里写的mesh路径去找STL文件。如果路径是相对路径它会相对于URDF文件所在目录去找。如果STL文件不在那个位置导入就会失败或者只导入一个空壳。我的做法是把URDF和所有STL文件放在同一个目录下URDF里用相对路径引用这样迁移的时候整个目录一起拷贝就行。缩放问题前面提过了这里再强调一次。URDF默认单位是米如果你的STL是毫米单位必须在mesh标签里加scale。我见过有人导入之后发现模型巨大排查半天才发现是缩放问题。6.2 碰撞体与视觉体的区分URDF里每个link可以定义visual和collision两部分。visual是显示用的collision是物理碰撞用的。对于简单形状两者可以一样。但对于复杂形状collision用简化形状能大幅提升仿真速度。比如一个带很多孔的板visual可以用完整的STL但collision可以用一个简单的长方体。这样仿真时碰撞检测快很多视觉上又不会失真。这个技巧在搭建复杂场景时特别有用。6.3 惯性参数的自动计算前面提到惯性矩阵不能随便填。对于长方体质量m、长a、宽b、高c惯性矩阵的对角元素是Ixx m(b² c²) / 12Iyy m(a² c²) / 12Izz m(a² b²) / 12对于圆柱体质量m、半径r、高h绕轴线的惯性是m r² / 2绕径向的是m(3r² h²) / 12。我在生成URDF时会根据几何类型自动选公式计算材料密度默认用钢的7850 kg/m³也可以让用户指定。这样生成的URDF导入仿真器之后动力学行为基本是对的不需要手动调。7. 实际项目中的经验与避坑清单7.1 文本描述的规范化建议如果你要做一个text-to-cad系统给其他人用最好先定义一套描述规范。比如尺寸必须带单位孔位必须用绝对坐标或明确的相对描述形状类型必须从预定义列表里选。规范越明确解析成功率越高。我自己的规范里还要求所有尺寸用毫米所有角度用度坐标系默认Z轴向上。这些约定写在文档里用户按规范写描述系统按规范解析中间少了很多扯皮。7.2 几何内核的稳定性技巧OpenCASCADE虽然强大但有些操作容易失败。比如对非常薄的板做倒角或者对非常小的孔做布尔运算。我的经验是倒角半径不要超过最小板厚的四分之一孔径不要小于板厚的二分之一。如果确实需要更小的特征考虑用其他方式表达比如用槽代替孔。另外布尔运算之前先做一次BRepCheck_Analyzer检查确保输入形状是有效的。无效形状做布尔运算结果不可预测。7.3 格式转换的兼容性检查STEP转STL、STEP转DXF、STEP转URDF每次转换都可能丢信息。我的做法是转换之后做一次回读验证把生成的文件重新读进来检查包围盒尺寸、体积、面数是否和预期一致。如果偏差超过阈值就报警。这个验证步骤看起来多余但它拦住过好几次因为单位或缩放导致的错误。尤其是批量生成的时候人工检查不现实自动验证是唯一的保障。7.4 性能优化的一点心得text-to-cad如果做成服务性能是个问题。OpenCASCADE的布尔运算比较慢生成一个复杂零件可能要几秒。批量生成一百个零件如果串行跑可能要几分钟。我的优化方案是用多进程并行。每个零件独立生成互不依赖可以扔到进程池里跑。Python的multiprocessing模块就能做注意每个进程要独立初始化OpenCASCADE环境避免线程安全问题。另外如果同一个形状要生成多个尺寸可以把基础形状缓存起来只对变化的部分重新计算。比如一块板长度变了但孔位规则不变可以只重建板的主体孔的位置重新计算但圆柱体可以复用。7.5 一个真实的踩坑案例最后分享一个我实际踩过的坑。有一次批量生成一批安装板参数里长度是变量孔位是根据长度计算的。我写的公式是x length - 8对于长度100的板孔位在92没问题。但有一块板长度设成了16孔位算出来是8而孔径是4孔中心到边缘只有8毫米孔半径2毫米理论上不干涉。但实际生成时布尔运算失败了。排查后发现当孔中心到边缘的距离刚好等于孔径时圆柱体和板的边缘相切OpenCASCADE对这种相切情况的处理不稳定。解决办法是在孔位计算时加一个最小边距约束比如孔中心到边缘至少留1.5倍孔径。这个约束加上之后再也没出现过类似问题。这个案例说明text-to-cad的鲁棒性不仅取决于代码还取决于对几何边界的理解。很多在数学上成立的情况在几何内核里可能触发数值不稳定。作为开发者要在参数校验阶段就把这些边界情况拦住。7.6 关于CAD软件兼容性的补充生成的STEP文件在不同CAD软件里打开表现可能不一样。中望CAD、AutoCAD、SolidWorks、Fusion 360对STEP的支持程度不同。我实测下来SolidWorks和Fusion 360对STEP的兼容性最好中望CAD次之AutoCAD需要装额外的插件才能读STEP。如果下游用户用的是AutoCAD可能直接给DXF更合适。DXF虽然只有二维但AutoCAD原生支持不需要插件。对于钣金、切割这类二维加工场景DXF反而比STEP更实用。还有一个细节是CAD软件的版本。老版本的CAD软件可能不支持新版本STEP协议里的某些实体类型。如果下游环境比较老导出时选AP203而不是AP214兼容性更好。7.7 文本到CAD的边界在哪里做了这么多项目我对text-to-cad的能力边界有了比较清楚的认识。它擅长的是规则明确的参数化零件、系列化标准件、简单装配体、二维轮廓图。它不擅长的是自由曲面、有机形状、需要大量工程判断的复杂结构、外观件。所以我的建议是把text-to-cad定位成一个“参数化建模加速器”而不是“全自动建模机”。用它处理那些重复性高、规则明确的部分把工程师的时间省下来做真正需要创造力的工作。这个定位想清楚了技术选型和流程设计都会顺畅很多。如果你也在做类似的事情我的建议是从最简单的形状开始先把文本解析、几何构建、格式导出这条链路跑通再逐步增加形状类型和参数复杂度。不要一上来就追求大而全那样很容易在某个环节卡住最后什么都做不出来。先把一个矩形板做到稳定可靠再扩展到轴、法兰、支架一步一步来。