Claude在3D创意工作中的实战技巧

虽然我有时会对此感到不安，但 Claude Code 对我目前的项目来说仍是一款不可或缺的工具。在我最关心的部分——CSS、设计，以及 API 模式这类早期架构——我偶尔还是会在 NeoVim 里亲手写代码；不过，现在只要搭好骨架，大部分实际的代码编写工作都会交给机器。这并不意味着我认为它生成的代码总是很出色。事后我会进行大量清理，尽管连这些清理工作也是通过给 Claude 提出更多修改建议来完成的。我会实时查看编辑过程，也练就了快速阅读的能力，这样一旦 Claude 做出什么出格的事情，我就能立刻叫停。

这种方式非常适合大多数 Web 项目。但我发现，Claude 仍然无法推理的是那些需要用眼睛判断的“视觉”工作。它对 CSS 的推理相当不错；如果 prompt 得当，它对设计语言和色彩理论的理解也还可以。但涉及 3D 空间分析这类更复杂的任务时，它总是会失败。不过，Claude 拥有很不错的原生工具来读取普通的 2D 图像。如果把从不同角度观察同一个 3D 空间的一组图片提供给它，再配上恰当的参考语言，它通常就能琢磨出一些东西。Table Slayer 和 Counter Slayer 都是重度使用 3D 的 Web 应用。在这两个项目的早期开发中，我有大量时间都花在手动截图上，然后对它说：“看看这个，你做错了。”这样的来回沟通耗费了数个小时，主要原因是必须由我不断给它提供截图。

像这样使用 Claude 构建复杂的 3D 场景，可能会很棘手。

和大多数人一样，我很快就意识到：与 Claude 协作时，面对 LLM，你需要从“可读取的输出”这个角度思考。对大多数项目而言，这通常意味着测试层。但在设计的探索阶段，通常还没有测试，只能让它创建大量临时日志来凑合。对于 3D 项目，这些日志可能包括位置和坐标等信息。这种方法在一定程度上有效，但过程很繁琐，而且通常是在你撞上失败的南墙之后才开始做。CAD 系统里存在大量并集和差集运算。某个盒子存在于那里，并不意味着它一定可见。

Claude 原生无法读取 STL。它会告诉你它可以，但当你意识到它只是在胡扯二进制文件里的内容后，事情就会一路发展成：它想安装一堆 Python 库来查看这些文件。这种方法对于读取 STL 多少有些用处，也能让它旋转相机、放大查看某些位置；但对于 Three.js Web 应用来说却没有太大帮助，因为真正的问题出在 CAD 系统最初构建 3D 内容的过程中。

要解决这类问题，你需要建立一个真正的上下文循环，让 Claude 能够读取应用状态、移动相机、添加一些调试标记，并持续迭代。这个核心循环就是让它自行浏览应用、控制相机，并添加视觉标记——例如用红色球体提供位置上下文——来检验自己的工作。我发现，要想与 Claude 有效协作，建立这种“迭代验证”循环至关重要。这样一来，它可以在自认为已经解决问题之前，先复核自己的工作。

下面是 Counter Slayer 使用的循环。

完整的 Claude.md 在这里，其中介绍了更多细节，但这才是整个工作流的核心。“这个循环”让 Claude 可以使用 Playwright 浏览应用，选择不同的 3D 对象（例如托盘或盒子）、调整相机、在对象的特定位置放置一个红色球体、检查截图，并判断截图是否与要求相符。更重要的是，它无需征求我的确认，就能自行完成这一切。

举个例子，下面是让它能够四处浏览的工具。

总的来说，我已经开始改变自己对如何与 Claude 协作的看法。我不再期待它直接理解我的要求，而是几乎总会先构建工具，为我们提供一套讨论项目时可以共用的语言。截图循环正是建立这种共同语言的绝佳方式。