Antigravity 2.0 跑赢万神殿建模测试：AI 写 CAD，难点不在会写几行 OpenSCAD

ModelRift 最近做了一个小规模实测：给多款 AI 编程工具两张万神殿参考图，让它们生成 OpenSCAD 文件，再调用 OpenSCAD CLI 渲染 PNG 预览，边看边改。

结果最好的全自主流程，是 Google Antigravity 2.0 搭配 Gemini 3.5 Flash High。质量分 4.5/5，但速度分只有 1/5，观察到的实现耗时约 12 分钟。

我更在意的不是“谁赢了”。这不是通用模型榜，也不是 CAD 行业权威基准。它更像一个切片：当 AI 从写网页、写脚本，走到写可交付的 3D 几何文件时，短板会很快暴露。

这项测试测的不是聊天能力，而是空间建模闭环

OpenSCAD 对 LLM 比较友好。模型不是拖拽出来的，而是代码写出来的：圆柱、旋转、布尔运算、模块、参数，都能被文本表达。

这也是它适合做测试的原因。AI 生成的不是一张“看起来像”的图，而是一份可以渲染、导出、检查的建模代码。

ModelRift 选万神殿，也不是随便找个建筑图。万神殿有圆形大厅、穹顶、中央天窗、柱廊、三角山花、台阶和正面铭文。弱一点的工具可以做出“带穹顶的建筑”。强一点的工具，才会处理比例、层级和内部结构。

这对做 AI 建模、3D 打印、CAD 自动化的团队很直接：单次生成截图不够。你要测的是一条闭环——读图、写代码、渲染、发现问题、再修改。

Antigravity 赢在细节，但速度和边界也很清楚

这次对比里，Antigravity 的优势不是一句“模型更强”就能解释。它做对了几件 CAD 里很要命的小事。

它使用了真实万神殿参数，把圆厅、穹顶、门廊和天窗转成可调 OpenSCAD 值。它还实现了正面铭文、cutaway 模式，以及内穹顶 5 圈 28 格藻井。

这些不是装饰。对 CAD 来说，铭文、藻井、剖切模式，都是在检验模型能不能把参考图里的空间关系变成结构化代码。

这里最容易误读的是速度分。它不是模型发布时间，也不是纯推理速度排名，而是这次任务里观察到的实现耗时。

Antigravity 质量最高，但并不快。Cursor 很快，但结果差。Codex 的预览好看，却在最终 STL 上掉链子。

这说明一个现实约束：CAD 交付不能只看中间预览。PNG 是给人看的，STL/3MF 才是要被切片、打印、装配的文件。预览漂亮，文件不可用，项目照样要返工。

真正该调整的是评估方法

如果你是 AI 编程 Agent 或 CAD 工具团队，这个测试最有用的地方，是帮你改评估表。

不要只问模型会不会写 OpenSCAD。更该问三件事：

• 能不能把参考图里的空间关系转成参数化结构；
• 能不能调用 OpenSCAD CLI 渲染，并根据预览继续修改；
• 能不能保证 PNG 预览和最终 STL 导出一致。

这会影响实际动作。

做 3D 打印工具的团队，不适合马上按这一个榜单迁移模型。更稳的做法，是把自己的典型零件、建筑构件或外壳结构，做成内部回归测试。每次评估都同时检查截图、源代码和最终导出文件。

做 AI CAD 产品的团队，也不该把“全自主”当成唯一卖点。ModelRift / Gemini Flash 3.0 的 3.8/5 就是提醒：有人类介入的流程可以拿到不错结果，但它证明的是人机协作有效，不是 Gemini Flash 3.0 在全自主条件下超过其他工具。

采购或技术负责人更应该延后下结论。至少等到同类任务扩展到更多模型、更多几何类型、更多导出格式，再决定是否把某个 Agent 放进生产流程。现在能判断的是方向，不是最终名单。

这次测试的边界也要摆清楚。样本是 Pantheon/OpenSCAD，评分只适用于这个任务。公开信息里也看不到足够完整的成本、硬件环境和大样本统计。把它当成线索可以，当成行业定论就过头了。

回到开头那两张参考图。AI 写 CAD 的难点，不是把万神殿“画得像”。难点是把图像里的建筑关系，变成可复现、可检查、可导出的几何文件。

这一步，才是 Agent 从会写代码走向能交付东西的门槛。