摘要：Autodesk Research发布Zero-to-CAD框架，将LLM嵌入反馈驱动的CAD环境中，通过Agent式搜索合成约100万个可执行、可读、可编辑的CAD构造序列，涵盖倒角、圆角、布尔运算等丰富操作词汇，无需任何真实CAD历史数据。微调后的视觉语言模型在图像到CAD重建任务中超越GPT-5.2。
最近 Autodesk Research 放出一个很值得工业软件圈关注的项目，叫 Zero-to-CAD。如果只看表面，它像是一篇典型的 AI for CAD 论文，讲的是怎么让大模型自动生成 CAD 程序，但如果往深一点看，这个项目真正想解决的，其实是 CAD 智能化里一个卡了很多年的老问题，高质量、可编辑、带设计历史的训练数据太少了。
过去几年，生成式 AI 在文本、图像、音频、视频上一路狂飙，但一到 CAD 这里，进展总显得慢半拍。原因不是 CAD 不重要，恰恰相反，CAD 是制造业、工业设计、机械工程、建筑工程里最核心的软件基础设施之一。问题在于，CAD 数据和普通 3D 数据根本不是一回事。
一个 mesh 模型、点云模型，或者某个物体的几何表面，当然也能表达形状，但它们表达不了工程师真正关心的东西，这个孔为什么在这里，这个圆角是不是功能性设计，这个支架能不能把壁厚改成 2.5 毫米之后继续稳定重建。这些信息，往往都藏在 CAD 的参数、约束和建模历史里。
也就是说，CAD 的核心不是“最后长什么样”，而是“它是怎么被构造出来的”。
这正是 Zero-to-CAD 的切入点。它不是从已有的大量真实 CAD 历史数据出发，因为这种数据本来就极难获取。很多设计数据掌握在企业内部，带有专有格式、商业机密和复杂权限，不可能像互联网图片那样大规模开放。于是 Autodesk Research 反过来走了一条很激进的路，既然拿不到足够多的真实数据，那就让 AI 自己去生成一批能执行、能编辑、能复用的 CAD 程序。
这个思路听上去有点像“用 AI 造训练 AI 的数据”，但难点远比图像合成高得多。因为 CAD 不是写一段看起来像代码的文本就行了，它必须真的能在建模环境里运行，运行后还得生成合理的几何结构，而且最好具备人能读懂、后续还能继续改的设计逻辑。
Zero-to-CAD 的方法，本质上是把大模型放进一个带反馈的 CAD 环境里，让它不再一次性“猜答案”，而是像一个会不断试错的 Agent 那样工作。
流程大致是这样的，模型先根据某种零件描述写出一段 CadQuery 程序，然后交给执行环境去运行。如果执行报错，系统就把错误信息和相关 API 文档再喂回给模型，让它继续改。如果生成的几何不合理，也会被过滤掉。只有那些最终可执行、几何有效的程序，才会进入数据集。
这里最关键的一点，是它把“语言生成”变成了“生成、执行、验证、修正”的闭环。这个闭环非常像今天大家常说的 Agent 工作流，只不过应用场景不是办公自动化，也不是网页任务，而是严格得多的 CAD 构造环境。
这种方法为什么重要？因为大语言模型其实并不天然擅长 CAD 语法。它可能知道一个机械支架通常有安装孔，知道某些零件会有倒角和圆角，也能从大量文本中学到不少工程常识，但一旦你让它精确地写出一段能被 CAD 内核执行的参数化程序，事情立刻就难了。少一个约束，一个 API 调错，一个草图闭合失败，整段程序就废了。
所以 Zero-to-CAD 不再把模型当成“直接输出最终结果的天才”，而是把它当成“在工具环境中逐步逼近正确答案的执行者”。这个思路很现实，也比很多只展示 demo 的 AI CAD 方案更接近工业可用性。
从论文和公开资料来看，Autodesk 这次构建出的数据规模大约在 100 万级，并且不是单一的“草图加拉伸”套路，而是覆盖了更丰富的 CAD 操作词汇，比如倒角、圆角、布尔运算、壳体、放样以及更复杂的草图结构。这个点非常重要。
因为早期很多 CAD 数据集虽然也号称能训练模型生成参数化序列，但实际表达能力有限，生成出来更像课堂练习，不太像真实工程零件。真正进入机械、工业设备和产品结构设计之后，复杂特征远比简单拉伸常见。一个只会“画草图再拉伸”的模型，离真正有价值的 CAD AI 还差得很远。
另一个值得注意的点，是 Zero-to-CAD 生成的数据强调可读性和可编辑性。这意味着它追求的不是把几何结果“糊出来”，而是让生成的程序像工程师会写的东西，有合理的参数命名、相对清楚的建模步骤，以及继续修改的可能性。
这一点其实决定了它和很多“从图像恢复 3D 形状”的方法不是一条赛道。后者更关心的是外形复原得像不像，前者更关心的是你能不能拿到一个真正可继续设计、可继续迭代的工程对象。对工业界来说，后者显然更难，但也更值钱。因为企业不是为了看一个漂亮 3D 壳子，他们需要的是可制造、可改版、可协同的数字模型。
论文里还有一个结果很能说明问题。研究团队用这些合成数据去微调视觉语言模型，做图像到 CAD 程序的重建任务，结果超过了一些非常强的通用模型基线。这个结论的意义不只是“分数更高了”，而是说明，即便没有海量真实 CAD 历史数据，只要合成数据的结构足够好、验证足够严，依然可以对下游任务形成真实提升。
这背后反映的是一个越来越值得重视的趋势，在某些高度专业化领域，未来最稀缺的可能不是模型本身，而是经过领域约束筛选的数据生产能力。谁能把通用模型的知识，转化成专业环境里可执行、可验证、可积累的数据，谁就更可能建立真正的壁垒。
Zero-to-CAD 的价值，也正在这里。它不只是做了一个 Agent，也不只是放了一个视频 demo，而是在尝试建立一种“用计算换数据，再用数据反哺模型”的新循环。
当然，这个项目也不该被神化。首先，合成数据再强，也不等于真实工程历史。很多企业级 CAD 模型背后包含装配关系、工艺约束、版本协作、工程变更记录，这些并不是单个零件程序就能完全覆盖的。其次，CadQuery 作为脚本式参数化建模工具，虽然非常适合研究和自动化生成，但它和工业现场常用的主流 CAD 平台之间仍然存在生态差异。换句话说，Zero-to-CAD 更像是在打通“研究可行性”和“数据供给能力”，距离全面进入企业设计流程，还有一段路要走。
但即便如此，我还是觉得这篇工作很重要。因为它抓住的是 CAD AI 里最硬的那个问题，不是界面炫不炫，也不是一句话生成模型的短暂惊艳，而是数据和表示层面的根基。
过去大家总说工业软件最难被生成式 AI 迅速改造，其中一个重要原因就是这里的知识不只是语言知识，而是强结构、强约束、强执行反馈的知识。Zero-to-CAD 至少给出了一条能往前推进的路径，把大模型关进一个严格的工具环境里，让它在失败和修正中，慢慢学会生成真正能落地的结果。
这条路不轻松，但很可能是对的。
如果这个方向继续成熟，未来 CAD AI 也许不会先表现为“人人一句话造飞机”，而是先表现为更现实的东西，自动补全建模步骤、从图片快速恢复可编辑参数模型、根据设计意图生成多个工程可行版本，或者帮工程师把重复性的参数建模工作大规模自动化。
这才是工业界真正会买单的地方。
从这个意义上说，Zero-to-CAD 不是 CAD 智能化的终点，更像是一块终于补上的基础拼图。它告诉大家，CAD 这件事未必要等真实数据完全开放才开始进步，也可以先靠 Agent 式合成把路探出来。
而在今天这个时间点，这已经很值得认真看一眼了。
上面这段演示视频也很直观，能看到这个项目不是单纯在“画形状”，而是在生成具备构造逻辑的 CAD 程序。配合论文一起看，会更容易理解它为什么值得关注。
参考链接：