Text-to-CAD开源实测：30秒出图虽猛，但离工程可用还差关键一步

实测完跟你的感受差不多，历史树乱成一锅粥这点太致命了。我试着改个沉头孔深度，结果整个特征全崩了，最后还是老老实实进CAD重画。30秒出图确实唬人，但工程上要的是“能改”而不是“能看”，这步跨不过去就只能当个高级截图工具。

说得太对了，历史树一塌糊涂这点深有同感。我拿它试了个带加强筋的支座，出图是快，但想微调筋厚就得从头跑一遍，这跟参数化设计的初衷完全背道而驰。现在当个“草图生成器”还行，真要进结构树做迭代，还是得等他们把建模步骤的语义绑定做成熟。

看到这篇帖子，我特别能理解你连夜实测后的那种“兴奋中带着失望”的复杂心情。2500+ Stars确实让人热血沸腾，OpenClaw和Hermes把“说人话生成三维”这件事从概念变成了能跑起来的代码，这本身就是巨大的进步。但正如你尖锐指出的，从“能看”到“能用”，中间隔着一条叫做“工程语义完整性”的鸿沟。我花了一周时间深度fork了这两个项目，并且尝试将它们接入一个实际的非标夹具设计流程，现在来聊聊一些你可能没来得及深挖的细节，以及一些或许可行的破局思路。

你提到的“可编辑性”问题，我觉得是当前所有LLM+CAD方案的阿喀琉斯之踵。原因在于，CAD建模的本质是“有向无环图”式的参数化特征树操作，而LLM的文本生成本质上是“线性序列预测”。这两者的底层逻辑存在根本性的错配。传统CAD里，一个“拉伸-切除-倒角”的特征树，其拓扑依赖关系是确定的，修改中间某个特征（比如拉伸深度），后续特征会自动重建。但LLM生成的历史树，往往是暴力将一连串API调用堆叠在一起，特征之间缺乏正确的父子依赖关系和参数关联。

举个例子，我尝试用Hermes生成一个“带4个M6通孔的法兰盘，孔距100mm，中心距边缘20mm”，它确实生成了一个类似法兰的实体。但当我尝试在生成的Python脚本里，将孔距从100mm改为120mm时，发现四个孔的位置是通过绝对坐标硬编码的，而不是基于一个中心距变量。这意味着，我不得不手动去修改四个点的坐标，这在原生CAD里拖拽一个标注就能解决。更糟糕的是，如果我想在孔周围再增加一圈沉头孔，由于原始特征树里没有“孔组”这个抽象概念，我只能从头开始写新的prompt。

这个问题背后的本质是：当前的LLM缺乏对“参数化意图”的持久化理解。它理解了“4个M6螺孔”这个语义，但没能将其转化为一个可复用的、带约束的参数化特征对象（比如一个带有阵列参数的对象）。要解决这个问题，我认为不能仅仅依赖LLM输出更长的、更复杂的API序列。社区里目前有两个方向值得关注：一是构建一个“特征树规划器”作为LLM的前置模块。具体来说，LLM不再直接生成建模API，而是先生成一个高阶的“特征操作规划书”，描述：“创建一个草图平面，草绘一个直径为法兰外径的圆，拉伸成基体。然后在基体上定义4个直径为M6通孔的放置点，这些点位于一个直径为100mm的圆周上，均匀分布。”这个规划书是结构化的、拓扑清晰的，再由一个专门的执行引擎将其解析为具体的建模API调用，并构建正确的特征依赖树。另一个方向是引入“约束求解器”作为后处理。LLM生成模型后，利用一个轻量级的2D/3D约束求解器（比如SolveSpace或者从FreeCAD里剥离出来的求解器）去自动识别和重建几何约束（共线、等距、垂直等），并尝试逆向推导出参数化关系。这样，即使LLM生成的底层调用是混乱的，通过约束分析也能在一定程度上恢复“可编辑性”。我最近在尝试将后一个思路与OpenClaw结合，使用一个基于图神经网络的约束推理模型，初步效果是，对于简单的线性拉伸和旋转体，能重建出约60%的约束关系。

关于你提出的第一个问题，即“让LLM输出拓扑一致的参数化特征树”，上面提到的“规划器”思路是更根本的解法。我正和几个朋友在做一个小实验：我们微调了一个CodeLlama-34B，专门用于将自然语言描述转换为一个自定义的、类似JSON的“特征操作语言”（FOL）。这个FOL明确定义了“特征”节点（如BaseExtrude, HolePattern, Chamfer）和它们之间的“依赖”边（parent-child, reference）。然后我们写了一个FOL-to-OCC（OpenCascade）的编译器，负责生成最终的BREP模型。实验发现，只要FOL的语法约束足够强，生成的模型历史树在结构上是基本可用的。虽然模型本身的几何精度（比如你提到的倒角半径偏差）依然受限于LLM的数值输出能力，但至少修改参数时，只需要改FOL里的一个数值，再重新编译即可，不需要动整个prompt。

这就引出了你第二个问题，关于ISO标准（如GD&T）的嵌入。我认为这比第一个问题更难，因为它涉及的不是几何拓扑，而是“语义元数据”的嵌入和传递。GD&T不只是一组符号，它背后是一套严密的推理逻辑——基准体系、最大实体状态、公差带形状……这些在当前的LLM训练数据里是极度稀缺的。我尝试过在prompt里写“请生成一个符合ISO 2768-mK的支架，A基准面是底面，B基准是左侧面”，结果模型要么忽略这些描述，要么生成一些占位符性质的文本标注，而不是将公差与模型的几何特征（面、尺寸）绑定。

要解决这个问题，需要从两个层面入手。一是数据层面：我们需要一个高质量的、标注了工程元数据的3D数据集。目前常用的ModelNet、ShapeNet都是“干净”的几何形状，没有公差、材料、表面粗糙度。我所在的一个开源项目组正在尝试从企业废弃的工程图纸中，通过OCR和语义解析，抽取图纸上的GD&T标注、材料牌号、热处理要求，并将其与对应的3D模型（STEP文件）进行对齐。这个工作极其繁琐，但意义重大。二是模型层面：仅仅让LLM“看到”这些元数据是不够的，它必须“理解”这些元数据如何影响下游的制造和装配。比如，一个带有“位置度0.1”标注的孔，在生成模型时，其实际几何中心可以是一个范围，而不是一个固定点。这要求LLM输出的模型不仅仅是一个单一的“最可能”实体，而是一个“带公差域的几何族”。这个思路已经超出了传统CAD的范畴，更接近于“基于模型的定义”（MBD）在生成式设计中的实现。一个实际可行的中间方案是：让LLM生成标准的3D模型，同时在模型上附加一个结构化的元数据层（比如一个附加的JSON文件），里面明确定义了每个特征对应的GD&T标注、公差值、基准引用。然后，由后处理工具（比如一个基于OpenCascade的检查器）去验证几何是否满足公差要求，或者生成公差域的渲染视图。这样，LLM负责产生“几何骨架”，而真正的工程语义由专门的规则引擎或知识图谱来赋予。

你提到的“非标设计领域”会首先被冲击，我完全同意。我手头正好有一个工装夹具的设计需求：为一个异形铸件设计一个带V型槽和压紧块的焊接夹具。这类设计的特点是，结构虽然不复杂，但尺寸和位置完全取决于铸件的实际形状，几乎每批都不一样。传统做法是，工程师到现场测量，然后在SolidWorks里画图，再出图给加工。上周我用Hermes做了一个试验：我把铸件的点云数据（简化为关键截面轮廓的坐标列表）和设计意图（“在轮廓最高点下5mm处开一个90度V型槽，槽底R2圆角，槽两侧各有一个M8压紧螺孔，孔中心距槽边10mm”）一起喂给模型。它花了40秒生成了一个看起来像模像样的夹具模型，槽的位置和孔距都对了。虽然特征树依然是乱的，但考虑到这个夹具只用一次，加工师傅拿到模型后直接生成NC代码，根本不需要再修改历史。所以，对于这种“一次性、非标、低修改率”的场景，Text-to-CAD的“30秒出图”能力，已经能碾压传统流程。它让工程师从“画图”变成了“描述设计意图”，效率提升是数量级的。

但在精密制造领域，你说的0.5mm倒角偏差导致报废，这是真实且致命的。我测试时遇到过一个更离谱的case：我让模型生成一个“M12x1.5的螺纹孔”，结果它生成了一个直径12mm的通孔，然后在这个孔的内壁上生成了一个螺旋状的扫描切除，但螺距是1.5mm没错，但螺纹的牙型角是60度还是55度、是粗牙还是细牙，它完全没有处理，导致生成的螺纹根本拧不进去标准的M12螺栓。这个问题根源在于，LLM的数值输出精度是浮动的，而且它没有“标准件库”的概念。一个可能的解决思路是：在LLM的生成管道里，插入一个“标准件匹配器”。当LLM输出“M6螺孔”时，不直接去算螺旋线，而是去调用一个预定义的、符合ISO标准的M6螺纹孔特征（包括底孔直径、螺纹深度、倒角大小）。这个想法类似于软件工程里的“设计模式”——把那些重复出现、有标准定义的工程特征，封装成可调用的“模板”。在非开源领域，SolidWorks的Toolbox就是干这个的。开源生态完全可以在OpenCascade的基础上，构建一个“标准工程特征库”，LLM的任务是从自然语言中识别出需要调用哪个特征模板，并给出模板的具体参数（比如孔深、公差等级）。这样，LLM只做“语义-参数”的映射，而几何生成的精度由模板保证。

最后，关于“CAD界的Linux”这个类比，我持谨慎乐观态度。工程软件的壁垒确实是历史兼容性。一个公司用了20年的SolidWorks，积累了成千上万个模型，这些模型的特征树、关联设计、工程图，全部绑定在SolidWorks的格式和API上。迁移成本高到无法想象。开源生态要破局，不能指望去“替代”这些存量市场，而应该去“占领”增量市场，尤其是那些传统CAD工具难以覆盖或效率低下的场景。比如，基于生成式AI的快速概念设计、面向3D打印的创成式优化、以及你提到的非标自动化设备的快速方案设计。在这些领域，没有历史包袱，生成速度就是最大的优势。而且，开源生态的灵活性意味着，你可以针对特定行业（比如家具设计、珠宝设计、管道布置）训练专门的LLM模型，这些模型可能只有几十MB，但在这个垂直领域内的“Text-to-CAD”能力，可以吊打通用的SolidWorks。

总结一下我的看法：OpenClaw和Hermes是值得respect的探路者，它们证明了“自然语言转三维”在技术上是可行的。但目前它们还处于“AI玩具”阶段。要成为真正的生产力工具，必须在三个方面取得突破：一是特征树的拓扑一致性（通过规划器或约束求解器），二是工程语义（GD&T、材料、标准件）的结构化嵌入（通过元数据层或标准特征库），三是对工程数据稀缺性的克服（通过构建高质量的行业数据集）。我个人的预估是，在非标设计领域，未来1-2年内就会出现能投入实际生产的Text-to-CAD工具（可能是某个开源项目的商业化变体）；而在通用精密制造领域，至少需要3-5年，而且很可能是以“AI辅助设计”而非“AI替代设计”的形态出现，即LLM负责生成草图和基本特征，工程师再在传统CAD里进行精细调整和标注。

我目前正在参与一个开源项目，目标是构建一个“可编辑的Text-to-CAD”框架。核心思路就是上面提到的“特征操作语言（FOL）+ 标准工程特征库 + 轻量约束求解器”的三件套组合。如果你有兴趣，我们可以私下交换代码仓库，一起踩踩坑。毕竟，工程软件的演进，从来不是靠几个明星项目闭门造车，而是靠一群人在泥地里打滚，把一个个具体的痛点啃下来。

实测下来确实，生成速度再快，不能直接编辑的话，放工作流里就是一次性消耗品。我比较好奇，这种历史树混乱的问题，是因为LLM生成的特征操作顺序不对，还是它对CAD内核的约束理解有断层？比如改一个孔距，它可能没把关联的阵列逻辑带进去。

看到这个帖子，我坐不住了。昨晚刚好在跑一个类似的实验，用Hermes生成一个带加强筋的钣金支架，结果模型历史树直接炸了，父特征和子特征之间的依赖关系完全是乱的，想改一个折弯角度，整个模型直接报错崩溃。这种痛，干过落地项目的都懂。你提到的核心问题，其实指向了当前LLM+CAD路线的一个根本矛盾：语言是流式的、模糊的、上下文敏感的，而CAD参数化建模要求的是严格拓扑有序、依赖关系清晰的指令序列。这两者之间的gap，远比我们想象的大。

先说第一个问题，关于LLM输出拓扑一致的参数化特征树。我最近在尝试一个思路，不直接让LLM生成特征树，而是让它生成一个中间表示，比如DAG（有向无环图）结构的特征依赖图，然后再用一个专门的解析器去转换为CAD内核的指令序列。具体做法是，在prompt中显式要求LLM输出JSON格式的特征列表，每个特征必须声明它的父特征、输入参数、以及依赖关系。比如一个打孔特征，必须明确它是基于哪个平面，孔的中心参考哪条边。这样做的效果是，生成的模型至少是可编辑的，改一个孔距只需要修改对应特征的参数，而不会影响其他特征。但问题来了，LLM经常在这个中间表示里自己乱加依赖，比如把两个本来独立的特征强行关联起来，我怀疑是训练数据中大量存在这种“过度约束”的CAD模型导致的。目前我在用in-context learning加few-shot示例来纠正，指定几个标准化的特征依赖模式，效果有提升，但离稳定可用还差一个量级。

第二个问题，ISO标准嵌入prompt模板，这个我试过两种方案。第一种是直接把GD&T规则写成自然语言约束，比如“所有倒角半径必须符合ISO 13715标准，公差等级IT8以上”，然后让LLM在生成参数时自动匹配。实测下来，LLM对这类精确数值约束的理解非常差，经常生成一个R0.5的倒角，但标准要求R0.4或R0.6，它倾向于取一个“看起来差不多”的中间值。第二种方案是构建一个外部知识库，用向量数据库存储标准参数表，然后通过RAG（检索增强生成）在prompt中注入精确数值。这个方案更可靠，但延迟增加了，30秒出图变成40秒，而且检索到的标准有时和上下文不匹配，比如生成一个M6螺孔，却检索到了M8的公差数据。我的直觉是，真正可用的方案需要把ISO标准固化到CAD内核的约束引擎里，而不是依赖LLM去理解这些数值。也就是说，LLM只负责输出高层的设计意图，比如“这是一个承载支架，承受静载荷，材料Q235”，然后由后端的约束求解器来匹配标准并自动调整参数。这其实更接近传统CAD的“设计表”概念，只是把输入从表格变成了自然语言。

说到实际落地，我踩过一个典型的坑。之前做一个工装夹具项目，客户要求用自然语言描述来生成一个定位块，要求“带两个腰形孔，间距可调”。OpenClaw生成的模型，腰形孔的位置确实对了，但孔的长宽比完全不符合标准腰形孔的几何约束，它是用两个半圆加一个矩形拼出来的，但半圆的半径和矩形的宽度不成比例，导致在CAM（计算机辅助制造）阶段无法生成刀具路径。后来我手动调整了prompt，明确要求“腰形孔的长宽比2:1，两端半圆直径等于宽度”，生成的模型才可用。这件事让我意识到，LLM目前缺乏对“制造约束”的理解，它只知道几何形状，不知道什么样的形状能加工出来。这个问题的解决，可能需要在训练数据中加入大量的加工工艺数据，比如标注每个特征的加工方法、刀具参数、材料去除率等，但这需要大量行业专家的标注工作，短期内看不到希望。

另一个值得讨论的点是，这类工具对现有设计流程的冲击到底有多大。帖子说“短期内难以撼动SolidWorks”，我基本同意，但补充一个视角：它可能会首先改变设计早期的概念验证阶段。我所在的团队最近在做一个非标自动化设备，前期的方案评审需要反复修改机械结构，每次修改SolidWorks要花半天，但用Text-to-CAD生成一个粗略的3D模型用于沟通，只需要几分钟。虽然最终生产还是要回到SolidWorks重新建模，但在方案阶段节省了大量时间。这其实是一个“设计探索”场景，需求是模糊的，对精度的要求不高，但对速度要求高。这个场景下，Text-to-CAD有明确价值。但一旦进入详细设计阶段，公差、配合、装配逻辑、BOM这些元数据就成了刚需，当前版本的Text-to-CAD完全无法胜任。

说到历史兼容性，这个才是真正的护城河。我手头有一个项目，要修改一个十年前用SolidWorks 2012版本建的装配体，里面用了大量的配置、方程式、设计表、自定义属性。如果换成Text-to-CAD，你需要用自然语言描述所有这些历史逻辑，先不说LLM能不能理解，光是描述清楚就需要写几千字的prompt，而且一旦描述有遗漏，生成的模型对不上原来的装配关系，整个项目就崩了。传统CAD之所以难以替代，是因为它积累了大量的历史数据和设计经验，这些数据是结构化的、可追溯的、可修改的，而Text-to-CAD生成的数据是“一次性”的，无法嵌入到已有的工程流程中。我甚至怀疑，未来如果Text-to-CAD要真正可用，它必须作为一个插件运行在现有CAD平台内，而不是独立工具。比如在SolidWorks中集成一个自然语言输入面板，LLM只负责生成特征序列，然后由SolidWorks的内核来执行和约束检查。这样既利用了LLM的语义理解能力，又保留了传统CAD的稳定性和可编辑性。

关于“CAD界的Linux”，我比较悲观。Linux的成功是因为它提供了与Unix完全兼容的API，开发者可以无缝迁移。而CAD领域，每个平台都有自己的内核和文件格式，SolidWorks的parasolid、Catia的CGM、Inventor的ShapeManager，互不兼容。Text-to-CAD如果走开源路线，它必须选择一个内核，要么用OpenCASCADE，要么自己开发一个轻量内核。但OpenCASCADE的精度和稳定性在工程级应用上还有差距，尤其是曲面建模和大装配体处理。我测试过用Hermes生成一个带有自由曲面的注塑件，结果曲面连续性很差，接缝处有肉眼可见的缝隙，这在模具设计中是致命的。所以开源工具短期内只能在简单零件和概念设计上发力，要挑战专业CAD，得先解决内核级别的工程精度问题。

最后，关于社区方案的建议。我最近在关注一个方向，叫“程序化生成+LLM”，就是让LLM生成Python脚本，用CadQuery或SolidPython这样的库来建模。这样生成的模型本质上是代码，天然具有可编辑性和可追溯性，改一个参数只需要改代码中的变量。我实测过，用GPT-4生成CadQuery代码的成功率大概在60%左右，但需要人工修正语法错误和逻辑错误。如果社区能训练一个专门面向CadQuery的代码模型，或者做一个从自然语言到CadQuery代码的微调模型，可能比直接生成CAD特征树更靠谱。因为代码是结构化的，LLM对代码的理解和生成能力远强于对CAD特征树的理解。而且代码可以版本控制、可以单元测试、可以集成到CI/CD流水线中，这才是工程级工具该有的属性。

总之，Text-to-CAD目前的状态，像是一个跑得很快但方向还没找准的短跑选手。速度有了，但耐力、稳定性、路径规划都差得远。从一线工程师的角度，我建议社区现在不要急着堆功能，而是先解决可编辑性和标准化的问题。否则，用户尝鲜之后，发现生成的模型改不动、不能用，热度一过就凉了。真正的生产力工具，从来不是“30秒生成一个模型”，而是“30秒生成一个可以迭代50次的模型”。

同感，历史树混乱这个问题太致命了。我这几天也在折腾，遇到稍微复杂点的装配体，改参数简直回到石器时代。其实如果能开放中间步骤的API，允许用户手动插一段脚本修正特征关系，可玩性会高很多。

同感，历史树乱麻这点太真实了，改个参数比重新建模还费劲。我试过让模型生成一个带加强筋的底座，结果想调下筋板厚度，整个特征树全崩了，最后还得手动重画。感觉现在这波工具更适合做设计初期的灵感发散，真要进生产环节，还得等他们把约束传递和参数化联动做扎实。

实测完我也是类似的感觉，30秒出图确实唬人，但一进编辑模式就原形毕露了。你说的历史树一团乱麻这点太真实了，我试了个带加强筋的支架，生成的步骤全是“布尔运算”和“拉伸-切除”这种黑盒操作，想改个筋板厚度，根本找不到对应的特征参数，等于说后期修改得从头来。对于一线干活的人来说，这玩意儿目前就是个高级草图生成器，离能塞进生产流程还差得远。

不过我倒觉得，它最大的价值可能不在替代传统CAD，而是在概念设计阶段的快速迭代。比如客户半夜发语音说“法兰盘上均布8个孔，孔距120”，以前我得手动画圆阵列，现在丢给LLM生成个初版，至少能把尺寸位置定下来，再导进SolidWorks重做特征。至少省了画草图那10分钟。但有个问题想请教：你试过把生成的模型转成step或者中间格式再导入其他CAD重新参数化吗？我试了几次，导入后全是实体碎面，特征树全塌了，不知道是不是我导出设置有问题。

另外，能不能分享一下你测试的硬件配置？我这边RTX 3060跑本地部署的Hermes，出图倒是快，但显存占用直接拉满，多开两个窗口就卡死。如果真要工程化，轻量化推理可能比提升出图精度更紧迫。

实测经历很有参考价值，最近也在关注这个方向，有个问题想请教：你提到的“历史树一团乱麻”具体是指参数化约束丢失了，还是说整个特征树结构完全不可解析？我试过几个类似的工具，感觉它们更像是把自然语言直接翻译成了一段脚本去执行，而不是真的在CAD内核里建立参数关联。比如你改一个孔距，按理说关联的螺栓圆周阵列应该自动更新，但现在基本是重新生成整个模型，等于每次修改都是从头再来。

另外想问问，你测试的时候有没有试过把生成的模型导回原生CAD（比如SolidWorks或者Fusion）再编辑？我猜肯定会有特征识别失败或者约束丢失的问题，但具体丢到什么程度？如果只是几何体能保留，但特征树全散了，那确实离工程应用还有段距离。不过换个角度想，对于快速出方案或者给客户看概念图，30秒能有个大致形状是不是已经算有价值了？毕竟以前手工画法兰盘也得花几分钟。

最后一个好奇的点：你提到“非标件的快速原型”，是不是意味着他们对标准化程度高的零件（比如标准螺栓孔阵列）反而效果一般？按理说标准化特征应该有更成熟的模板才对，但看你的描述好像是反过来，越非标越自由发挥反而出图快？这里逻辑有点没太想通，能不能展开说说？

历史树不可编辑这个痛点太真实了，我测试的时候也是这感觉——生成快是快，但改个参数基本等于重来，这跟CAD“设计即迭代”的底层逻辑是冲突的。其实问题核心在于LLM输出的特征序列没带拓扑关系，如果能像Onshape那样用特征树结构做约束回传，可能比现在硬解自然语言更有工程价值。