image-blaster 一句话：一张图进去，5 分钟内出来一整套能直接用的 3D 资产——动态物体的 3D 模型、静态场景的高斯泼溅、循环环境音加物体碰撞音效。它不自己算这些重活，而是把活分给三个云端模型，自己当那个「指挥家」。

一、它到底是啥：一个跑在 Claude Code 上的编排层

打开这个仓库你会看到一个很反直觉的结构：根目录里有一个几乎为空的 CLAUDE.md（0 行），一个 .claudeignore（内容就一行 /app），以及一个 .env.example（只声明两个 key：WORLD_LABS_API_KEY 和 FAL_KEY）。真正能跑的 3D 查看器藏在 app/ 里——而它被 .claudeignore 明确挡在了 Claude 的视野之外。

这说明 image-blaster 的核心逻辑不是「写代码」，而是「编排」。你给 Claude 一张参考图，Claude 按 skill 里定义的流程，依次调用三个外部服务把活干完，最后 app/ 那个 React 查看器负责把产物渲染出来让你看。它本质是一个工作流编排层，不是一个模型。

.env.example:
  WORLD_LABS_API_KEY=...   # World Labs（marble-1.1）
  FAL_KEY=...             # FAL（hunyuan-3d 等）
  就这两个 key。
  Claude 拿到这两把钥匙，按 skill 流程跑完全家当。

二、三个云端模型，各干各的活

README 把分工写得很清楚，整条流水线的重活全部在云端：

  • marble-1.1（World Labs）——把参考图变成一个可进入、可漫游的高斯泼溅场景，产物是 .spz，负责静态环境。
  • hunyuan-3d（走 FAL）——把动态物体生成带网格的 3D 模型，产物 .glb / .obj，支持 --face-count（40000~1500000，默认 50000）、--enable-pbr（默认开）、--generate-type。
  • elevenlabs-sfx（ElevenLabs）——生成循环环境音 + 物体专属物理音效，产物 .mp3。
  • nano-banana / gpt-image-2——可选的图像清洗，把参考图做干净、出 clean plate、出物体参考图，是预处理工具。

整条链路产出三样东西：.glb/.obj（动态物体）+ .spz（静态高斯环境）+ .mp3（音效）。这就是「一张图 → meshed 3D 环境」的全貌。

三、本地实跑：纯 CPU 也能把查看器跑起来

我自己把 app/ 这个 React 查看器真的构建并跑了一遍，验证「本地压力不大」这件事。构建阶段有个坑：仓库是 bun.lock 管的，用 npm install 会拉到一个类型对不上的 @sparkjsdev/spark，tsc 直接报 encodeLinear 不存在。跳过类型检查、直接 npx vite build 打包成功（16 秒，5443 个模块，主 JS bundle 6.4MB）。再用本地 http server 起 dist/，headless 浏览器截到的画面是这样的：

本地实跑：vite 打包后起查看器，因 worlds/ 为空显示 “No worlds found in worlds/” 空态——纯 CPU 就能跑起来
本地实跑：vite 打包后起查看器，因 worlds/ 为空显示 “No worlds found in worlds/” 空态——纯 CPU 就能跑起来

这张截图本身就是一枚证据：没有配任何 World Labs / FAL 的 key，本地只靠 CPU 就把 3D 查看器完整跑起来了，UI、路由、空态、渲染管线全在，只差喂一个 .spz 进去。换句话说，本地这段真的就是「薄壳」。

四、硬件压力到底在哪（诚实边界）

既然重活都在云端，本地到底要什么配置？把话说透：
纯调 API 跑流水线：普通 CPU + 8GB 内存就够。因为生成 3D 模型、高斯场景、音效全在 World Labs / FAL / ElevenLabs 的服务器上算完，本地只负责发请求、收文件、跑查看器。
本地深度估计 + 高斯优化留余量：官方没给一条明确的配置线，社区实操建议是显存不低于 8GB 的独显会更稳——这部分余量留给本地可能做的深度估计和高斯优化等计算。如果你的流程纯走云端，这条可以无视。

五、横向对比：图和 3D 这条赛道上它的位置

  • 对比「一键 3D」类工具（Meshy、Trellis、Tripo）：image-blaster 不只是一个模型，它是场景级的——同时给静态高斯环境 + 动态网格 + 音效，而多数工具只给你单个物体 mesh。
  • 对比本地 3D 生成：把重活甩给云端，是本机显存/内存友好的最大卖点，代价是必须买 World Labs + FAL 的 key（按量计费），且断网/没额度就转不动。
  • 对比纯高斯泼溅工具（如各类 .spz 生成器）：它多了 SFX 音效层和「可进入漫游」这层叙事，更接近「跳进场景」而非「看个模型」。

六、我的判断

image-blaster 的定位很清楚：它是 3D 资产流水线的「启动器」，不是替代你的 3D 引擎。README 自己都说得很克制——「great for jumpstarting 3D work」，意思是 5 分钟先搭个能动的场景把活干起来，精修还得回引擎里做。真正值得学的是它的编排思路：用 Claude 当指挥官，把「图像 → 场景/网格/音效」拆成三次外部调用，本地只留薄壳查看器。想试的话成本门槛是两个付费 API key，不是硬件；本机 8G 内存就能起步。