这份 27 页的《AI For SketchUp 评测报告》出自北京航空航天大学人文与社会科学高等研究院，以及清华大学新闻与传播学院、人工智能学院双聘教授 @新媒沈阳 团队与何静副教授。测试对象是 ChatGPT Codex 这类智能体，报告标注适配 Codex、Claude Code、WorkBuddy 等多种工具，也在封面就写明了 测试样本有限，结果仅供参考。它想回答的问题很实在：当智能体开始操作专业设计软件，从想法到模型的过程会发生什么变化。
01 三条老痛点，被拆得很清楚
报告先把 SketchUp 的日常摊开。建模前的痛点是「意图难落地」：「现代简约」「空间开阔」这类描述很难直接变成参数，没有平面图时只凭文字建模，容易出现比例不准、功能分区不清。建模阶段是「重复劳动密集」：拉墙体、开门窗、做楼板、摆家具，标准空间明明形态相似，每次仍要重来。改模阶段是「联动修改困难」：客户一句「会议室扩大一点、玻璃隔断换成实体墙」，牵动的却是墙体、门窗、家具、材质和标注。
02 四条路径，考核点各不相同
智能体驱动 SketchUp 有四种走法，各自要看的东西不一样。直接生成模型文件看结果，要求产出 .skp、.obj、.dae、.glb 这类能打开或导入的成果；生成 Ruby 脚本看逻辑，验证参数化建模与批量布置；MCP 调用看交互，验证能否在已有模型里读取、定位、修改并另存；Skill 封装看复用，考察流程标准化与组件库调用。模型文件看结果，Ruby 脚本看逻辑，MCP 看交互，Skill 看复用，这一句基本就是整份报告的评测框架。
03 建模阶段：规则明确的部分最稳
中间十几页是逐场景实测，共 17 个场景，按建模前 3 个、建模阶段 9 个、改模阶段 5 个排列。基础体块、墙体、门洞、窗洞、楼板这类规则明确的任务，用 Ruby 脚本完成得比较稳；楼梯、栏杆和坡道能被拆成可计算参数，再自动生成可编辑模型；平面图复刻建模验证的是「参考图理解、软件建模、分组命名、结果保存、截图导出」的完整链路。
04 改模阶段：真正难的部分
改模比建模更考验智能体。报告用 MCP 方式直接操作已有模型，逐项跑通了尺寸参数联动修改、组件批量替换、材质与风格批量替换、空间功能转换，以及方案 A/B 版本生成。验收标准也写得很具体：能不能准确识别目标对象、能不能保持原有位置关系、能不能不覆盖原始模型地生成差异化版本。这五个场景是整份报告里最接近真实工作流的一段。
05 边界也写在了同一份报告里
报告没有回避局限。一句话风格指令可以被拆成草屋屋顶、雨线、水坑、湿地、积雪这些可建模元素，但受 SketchUp 原生材质与渲染能力限制，结果更接近风格化模型表达，达不到照片级。文生 3D 资产导入后，比例、面数和细节仍需人工复核；未标注的尺寸与模糊构件也要人来补判断。报告还特别说明，测试基于本地 SketchUp MCP Server 与 Ruby 执行能力，能力边界取决于具体 Server 的工具集，并不代表所有连接器都支持。
06 谁受益，往哪走
价值对象列了五类：不会操作 SketchUp 的小白可以用自然语言拿到初步空间模型；设计师能把时间从拉墙摆家具挪回方案判断；改模流程靠 MCP 定位对象批量修改，降低「改一处漏一处」的风险；模型管理可以自动整理群组、组件、标签与场景命名；教学演示则能完整展示「需求、模型、修改」的全过程。
报告最后给出四条趋势：从参数建模走向空间意图理解，从单步操作走向多轮设计推理，从几何生成走向设计规则约束，从组件调用走向资产智能匹配。换成白话，就是模型不只要「能看」，还要逐步接近「合理、可用、符合基本设计规范」。
整份报告最值得记住的，是它把「什么交给 AI、什么留给人」这条线划了出来。生成可以很快，复核仍要人做，这两件事它分得很清楚。
