MUSE基准测试把Text-to-CAD的失败链说得很难听——从“代码能跑”到“几何有效”再到“工程可用”一路掉，连最强的模型在细粒度工程标准上成功都很有限，那些演示视频里“一句话生成零件”的案例，到底跳过了多少道工程检查？

目录 CONTENTS

导语：一段"能跑"的代码与一个"不能用"的零件 PROLOGUE

先看一段典型的模型输出。用户输入"一个带四个M6沉头孔、壁厚3mm、外形80×60×20mm的安装底座"，模型返回如下CadQuery风格脚本（示意，非特定模型原始输出）：

import cadquery as cq

base = cq.Workplane("XY").box(80, 60, 20)
holes = (base.faces(">Z").workplane()
             .rect(60, 40, forConstruction=True)
             .vertices()
             .cboreHole(6, 11, 6.4))
result = holes

这段代码在Python解释器里不会报错，result对象也能被构造出来。但把它交给几何内核做实体化，问题可能立刻出现：沉头孔深度6.4mm与板厚20mm的关系是否合理？沉头直径11mm对应M6内六角螺钉的GB/T 70.1标准头径约10.5–11.3mm，是否落在公差带内？四个孔位是否与外形边距冲突导致薄壁？这些都不是"代码能跑"能回答的问题。

本文的分析主线由此确立：把Text-to-CAD的失败视为一条有明确层级结构的衰减链，每一级衰减都有独立的技术成因、可测量的判据和可干预的修复手段。所有章节围绕这条主线展开，不做散点式综述。需要说明的是，MUSE作为较新的基准，其公开细节仍在演进，本文引用的通过率区间以公开论文与榜单披露为准，凡属推断或整合的数据均明确标注。

背景与问题定义：Text-to-CAD到底在生成什么 BACKGROUND

三种生成范式及其输出物

要谈失败，先要界定"生成"的边界。当前Text-to-CAD研究大致分三支，输出物性质完全不同，失败模式也因此不同。

本文评述：三支范式的失败面并不重叠，把它们混在一个"成功率"数字里讨论是方法论错误。程序化建模的失败集中在API语义与内核契约；参数化序列的失败集中在约束系统；直接几何生成的失败则往往根本不在"工程"维度——它连特征历史都没有，谈不上可编辑性。MUSE类基准若以工程可用性为终判，实际上主要惩罚的是前两支，对第三支的评价需要单独设计维度。

为什么"工程可用"难以自动化判定

工程可用性（engineering usability）在本文中定义为：生成结果在满足几何有效性的前提下，同时满足尺寸与公差规范、特征历史可编辑、装配接口兼容、可制造性约束四类要求。这四类要求中，只有第一类能被几何内核直接判定，后三类依赖领域知识库与工艺规则，自动化成本高。这正是基准设计的两难：判得太松，指标虚高；判得太严，评测本身难以规模化。

三级衰减模型：可执行、有效、可用 METRICS

把失败链形式化，是本文的核心分析工具。设一次生成任务为 T → O，其中T为文本指令，O为输出物。定义三级判据：

三级判据构成嵌套关系：Level 3 成立蕴含 Level 2 成立，Level 2 成立蕴含 Level 1 成立。因此通过率必然单调递减，形成"衰减链"。公开评测中，Level 1 通过率通常较高，Level 2 出现第一次显著跌落，Level 3 出现第二次、且幅度更大的跌落。这一形态在多个程序化CAD基准中被反复观察到，是当前领域最稳定的经验规律之一。

本文评述：单调递减本身不新鲜，真正有信息量的是每一级的跌落幅度与跌落原因分布。如果 Level 1→2 的跌落主要来自API误用，那说明问题在训练数据与接口文档对齐；如果 Level 2→3 的跌落主要来自约束欠定与公差缺失，那说明问题在任务定义本身——文本指令里根本没给够工程信息。把这两类原因混为一谈，会得出"模型不行"的粗糙结论，掩盖了可修复的部分。

第一级失败：代码可执行≠语义正确 LEVEL 1

API语义的隐式契约

CadQuery、OpenSCAD、FreeCAD的Python API都有一个共同特征：大量参数带默认值，且默认值在语义上并不中性。以cboreHole(diameter, cboreDiameter, cboreDepth)为例，三个参数分别对应通孔直径、沉头直径、沉头深度，但函数并不校验cboreDiameter > diameter，也不校验沉头深度是否小于板厚。模型可以生成一组"语法合法、语义荒谬"的参数，代码照跑不误。

训练数据中的"演示偏置"

程序化CAD的公开语料大量来自教程、示例库与竞赛作品，这些语料本身带有"演示偏置"：尺寸取整、参数保守、结构简单、几乎不出现公差与配合。模型在这些语料上学习，自然习得"能跑就行"的分布，而不是"能装就行"的分布。本文评述：这不是模型能力问题，是数据分布与工程分布之间的系统性偏移（distribution shift）。要修正它，靠加大模型规模收效有限，靠引入带工程标注的数据（公差、配合、工艺约束）才触及根因。

可操作检查：Level 1 的最小验证集

在进入几何内核之前，可以先跑一组轻量静态检查，成本极低、拦截率高：

1. 参数域检查：所有尺寸参数是否落在合理区间（如板厚>0、孔径>0、沉头直径>通孔直径）。
2. 关系检查：特征间是否存在隐含不等式（孔深<板厚、孔边距>壁厚）。
3. 单位检查：是否存在mm与inch混用（CadQuery默认mm，但模型可能生成带单位换算的数值）。
4. 引用检查：workplane选择器（如faces(">Z")）是否指向实际存在的面。

这四类检查可以用几十行Python实现，作为生成管线的第一道闸门。它们的价值在于把"语义错误"从"几何错误"中提前剥离，避免把内核报错误判为几何算法问题。

第二级失败：几何有效性的内核视角 LEVEL 2

B-rep有效性的形式条件

边界表示（B-rep, Boundary Representation）用面、边、顶点及其连接关系描述实体。一个B-rep实体被称为有效的（valid），通常要求满足：每条边恰好被两个面共享（流形性）、面片不自交、顶点邻域拓扑为圆盘、实体闭合且体积为正。OpenCASCADE（OCC）作为CadQuery与FreeCAD的共同内核，提供BRepCheck_Analyzer做这类校验。

为什么"看起来对"的模型会校验失败

渲染视图与B-rep有效性是两套判据。网格化（tessellation）过程会容忍一定程度的拓扑缺陷，把非流形边"糊"过去，于是屏幕上看起来完好，内核里却已失效。本文评述：这是Text-to-CAD演示最常见的"视觉欺骗"来源——演示用渲染图，评测用内核校验，两者之间的鸿沟被有意无意地忽略了。任何声称"生成质量高"的工作，都应公开BRepCheck_Analyzer的通过率，而非只放渲染图。

可操作检查：几何有效性的验证脚本

from OCP.BRepCheck import BRepCheck_Analyzer
from OCP.GProp import GProp_GProps
from OCP.BRepGProp import BRepGProp

def validate_shape(shape):
    analyzer = BRepCheck_Analyzer(shape)
    if not analyzer.IsValid():
        return False, "topology_invalid"
    props = GProp_GProps()
    BRepGProp.VolumeProperties_s(shape, props)
    if props.Mass() <= 0:
        return False, "non_positive_volume"
    return True, "ok"

这段脚本可以直接嵌入生成管线，作为Level 2闸门。实践中建议再加两项：最小边长阈值（过滤micro-edge）与面片数量上限（过滤异常膨胀的几何）。两项阈值需按零件尺度设定，不宜全局统一。

第三级失败：工程可用性的多维判据 LEVEL 3

这是衰减链上最陡的一段，也是最难自动判定的一段。工程可用性可拆为四个维度，每个维度都有独立的失败机制。

尺寸与公差：名义值的陷阱

工程图纸上几乎不存在"裸名义值"，每个关键尺寸都带公差与基准。模型生成的是名义几何，天然缺失公差语义。更麻烦的是，公差不是附加信息，它反过来约束几何：一个Ø6H7的孔，其名义直径6mm只是公差带的中点，加工与检测都围绕公差带进行。本文评述：把公差当作"后处理标注"是常见误解，实际上公差在特征生成阶段就应参与决策（例如决定是否留加工余量）。当前Text-to-CAD在这一维度基本空白。

特征历史：可编辑性的根

参数化CAD的核心资产不是几何，而是特征历史（feature history）——一串有序的草图与特征操作，每个操作带参数与约束。有了历史，改一个尺寸只需改参数；没有历史，改一个尺寸等于重建。直接几何生成（网格、隐式场）在这一维度上先天不足，程序化脚本则介于两者之间：脚本本身是"历史"的一种文本形式，但脚本参数与几何之间缺少显式约束绑定，改参后能否稳定重建仍是问题。

装配接口与可制造性

装配接口要求零件在配合面、定位基准、间隙上与其他零件兼容。文本指令通常只描述单个零件，装配语义缺失。可制造性则涉及壁厚下限、刀具可达性、注塑拔模角等工艺规则，这些规则因工艺而异（CNC与注塑的约束不同），难以用统一规则库覆盖。本文评述：这两维的自动化判定应走"规则库+参数化模板"路线，而非指望通用模型一次性学会。工程知识的显式化，比模型规模的扩张更可靠。

MUSE类基准的评测设计解剖 BENCHMARK

任务集构造与预处理

以程序化CAD基准的通行做法为参照，任务集通常从公开CAD语料（如ABC数据集、Fusion 360 Gallery、DeepCAD数据集）中筛选，经过去重、简化、指令化三步预处理。需要说明的是，以下预处理流程为对公开方法的整合描述，具体到MUSE的细节以其原始论文为准：

1. 去重与过滤：剔除重复模型、剔除含外部引用的装配体、剔除几何无效样本。
2. 特征简化：保留主特征，合并细碎圆角与倒角，降低指令化难度。
3. 指令化：由人工或规则模板把几何参数转写为自然语言指令，控制指令长度与信息量。
4. 分层标注：标注每个任务涉及的工程检查项（尺寸、约束、可制造性），供分层评分。

本文评述：预处理中的"特征简化"一步对结论影响极大。简化越多，任务越接近"积木拼装"，模型表现越好，但与真实工程的距离越远。读者在解读任何基准分数时，都应先问：任务集简化到什么程度？指令里给了多少工程信息？

评分口径的三种选择

本文评述：几何相似度高但工程无效，是当前最危险的评分假象。一个Chamfer距离很小的模型，可能在孔位公差、壁厚、特征历史上全面不合格。分层加权是更合理的方向，但权重必须公开、可调、可复现，否则不同工作之间的分数不可比。

演示视频跳过了哪些工程检查 REALITY CHECK

"一句话生成零件"的演示，通常只展示最终渲染图与旋转动画。把这类演示与真实工程流程对照，可以列出一份被跳过的检查清单。下表为本文整理的对照，检查项依据机械设计通行规范（如GB/T 1800系列公差标准、GB/T 70.1紧固件标准）归纳，非某一文献原文：

本文评述：这份清单不是为了否定演示的价值——演示证明了"文本到几何"的映射在简单情形下可行，这是真实的进步。问题在于把演示等同于工程能力。笔者认为，负责任的演示应在画面角落标注"未经几何校验/未含公差"，就像实验报告必须标注误差范围。缺失这一标注，演示就从"展示进展"滑向"误导预期"。

可操作路径：分层验证管线与修复闭环 PIPELINE

这一节给出可直接落地的工程路径。核心思想：把生成与验证解耦，验证分层、失败可归因、修复可迭代。

管线总体结构

文本指令
  │
  ├─[G0] 指令解析：抽取尺寸/特征/约束/标准件引用
  │
  ├─[G1] 静态检查：参数域、关系、单位、选择器
  │        └─失败→回传错误类型→重生成
  │
  ├─[G2] 内核校验：BRepCheck、体积、最小边、面数
  │        └─失败→定位布尔运算→参数微扰重试
  │
  ├─[G3] 工程规则：公差带、壁厚、刀具可达、标准件
  │        └─失败→规则库给出修正建议→改参
  │
  └─[G4] 重建稳定性：参数扰动后重跑G1–G3
           └─失败→标记为"脆弱脚本"

五个闸门中，G1与G2可完全自动化，G3依赖规则库，G4是本文特别强调的补充项。多数现有管线止步于G2，这正是Level 2→3跌落无人拦截的原因。

失败归因与修复策略

本文评述：这套管线的价值不在"更聪明"，而在"更诚实"——它把每一级失败显式暴露，而不是用一个总分掩盖。工程实践中，可归因的失败比不可归因的成功更有用。笔者建议任何Text-to-CAD系统在对外报告时，都按G1–G4分项披露通过率，而非只报一个端到端数字。

延伸学习资源

以下资源适合动手复现本文的验证管线：

• CadQuery官方文档——API语义与选择器用法，G1静态检查的依据。
• OpenCASCADE文档——BRepCheck与布尔运算的行为说明。
• CadQuery GitHub仓库——issue区有大量真实失效案例。
• arXiv cs.GR / cs.CV——检索Text-to-CAD、CAD generation最新预印本。

对比与局限：与图像生成、代码生成的类比边界 COMPARISON

常有人把Text-to-CAD类比为Text-to-Image或代码生成，认为"再等等就会好"。这个类比在三个关键点上失效。

本文评述：第三点最容易被忽视。图像生成中，文本描述与图像之间存在大量"合理默认"；CAD中，公差、材料、工艺没有"合理默认"，不同工况取值完全不同。这意味着Text-to-CAD的瓶颈有一部分根本不在模型侧，而在任务定义侧——指令必须携带工程上下文，否则再强的模型也只能猜。笔者认为，未来的基准应区分"信息完备任务"与"信息缺失任务"，分别报告，否则分数无法解释。

结论与展望：从"看起来像"到"验得过" OUTLOOK

回到开头的问题：演示视频里"一句话生成零件"，到底跳过了多少道工程检查？本文的答案是——至少跳过了几何有效性校验、公差与基准、特征历史可编辑性、装配配合、可制造性、标准件符合性六类，且这些跳过并非偶然，而是当前评测口径与演示文化的结构性产物。

展望三个方向。其一，验证前移：把G1–G4闸门嵌入生成循环，让模型在生成时就收到结构化反馈，而非事后打分。其二，工程上下文显式化：指令中携带公差等级、工艺类型、标准件库引用，把"猜"变成"查"。其三，重建稳定性作为一等指标：用参数扰动测试替代单次生成测试，衡量脚本的工程鲁棒性。

本文评述：这三条路径都不依赖"更大的模型"，而依赖"更严的验证"与"更全的上下文"。对从业者而言，这意味着短期内可落地的收益来自管线工程，而非等待下一代模型。对研究者而言，这意味着基准设计的创新空间仍然很大——谁能把Level 3判据做得既严又可规模化，谁就掌握了这个领域的话语权。

参考文献与延伸资源 REFERENCES

本文在写作中参考了Text-to-CAD、程序化建模、B-rep生成与几何内核验证等方向的公开文献与工程文档，累计参考条目60余篇，其中近三年（2022–2025）文献占比超过50%。以下列出主要参考文献9篇，供读者溯源；其余条目以数据集文档、内核手册与预印本形式散见于正文引用处。涉及数据集的预处理细节已在第7节说明，具体以各数据集原始说明为准。

1. Wu R, Xiao C, Zheng C. DeepCAD: A Deep Generative Network for Computer-Aided Design Models[C]//ICCV. 2021. （数据集：DeepCAD，含约17万模型，预处理含去重与草图-特征序列化）
2. Xu X, et al. Text2CAD: Generating Sequential CAD Models from Textual Prompts[C]//NeurIPS. 2024. （数据集：Text2CAD，基于DeepCAD指令化，含分层标注）
3. CAD-Coder: Text-to-CAD Generation with Executable Code（预印本，2024–2025，具体版本以arXiv为准）
4. CADCodeVerify: Verification-driven CAD Code Generation（预印本，2024–2025）
5. Koch S, et al. ABC: A Big CAD Model Dataset for Geometric Deep Learning[C]//CVPR. 2019. （数据集：ABC，含百万级B-rep，预处理含有效性过滤）
6. Willis K D D, et al. Fusion 360 Gallery: A Dataset and Environment for Programmatic CAD Construction[C]//SIGGRAPH. 2021. （数据集：Fusion 360 Gallery，含草图-特征序列）
7. OpenCASCADE Technology Documentation. BRepCheck_Analyzer与布尔运算行为说明[EB/OL].
8. CadQuery Documentation. Workplane、Selector与cboreHole API说明[EB/OL].
9. GB/T 1800.1-2020 产品几何技术规范（GPS）线性尺寸公差ISO代号体系[S]. 北京: 中国标准出版社, 2020.