Simon Willison 让 Codex 控制 Blender，但渲染只是故事的一半

Simon Willison 仅凭一条提示词，就在 2 分 39 秒内生成了一个可编辑的 Blender 场景，尽管他从未通过该应用的可视化界面进行操作。他的编程智能体生成了 Python 代码，在 macOS 上启动 Blender，搭建了一只骑自行车的鹈鹕，并将结果保存为原生 .blend 文件。

这一差别至关重要。这并不是又一个生成一张难以修改的扁平图片的文生图系统。该智能体操作的是一款可编程的创意应用，留下了人们能够检查、编辑、重新渲染或制作动画的源代码与结构化 3D 对象。

这项实验也揭示了编程智能体真正面对的竞争。重要的分界线已不再是编写代码与制作视觉媒体之间的差别，而是软件能否提供可靠、可编程的控制方式，还是依旧受困于手动界面操作。

Willison 的案例小巧、有趣，且基于一位用户的个人体验。它并不是一项受控基准测试。然而，它为智能体如何突破代码仓库的边界提供了有价值的预览，而无须等待每位应用开发者提供定制集成。

Simon Willison 将 Blender 变成了编程智能体的目标

值得关注的并非鹈鹕图像，而是 Codex 将一款已安装的桌面应用视作可执行的开发工具。

在 9 月 5 日的一篇文章中，Simon Willison 介绍了自己如何在 Mac 上使用 ChatGPT Codex 控制 Blender。他最初的要求很直接：使用已安装的 Blender 应用渲染一只骑自行车的鹈鹕。

该智能体通过 Blender 的命令行可执行文件和 Python 接口找到了实现路径。Willison 随后提供了更明确的命令 /Applications/Blender.app/Contents/MacOS/Blender --background --python scene.py，它会在不启动 Blender 常规界面的情况下运行脚本。

后台模式意味着 Blender 无须打开图形工作区即可运行。这使其适用于自动化渲染、服务器任务、测试流水线和由智能体控制的任务。

Willison 表示，首次提示在 2 分 39 秒后生成了一个 .blend 项目和 Python 脚本。随后，他要求加入“背景和大量亮点”，并在 3 分 51 秒后得到了另一个版本。

最后一次要求将作品“做得好得多”，耗时 5 分 59 秒。最终的海岸游行场景包含木栈道、海洋、日落、海滩小屋、棕榈树、花卉，以及一只细节更丰富的鹈鹕。

完整过程、提示词、输出文件和耗时均见于 Willison 的 Blender experiment。这份公开记录让该案例比一张没有制作过程说明的精修图更具参考价值。

生成的文件也展示了智能体实际完成了什么。它并未调用一个隐藏的图像生成器，再将结果贴入 Blender。它通过 bpy 编写了构建场景的指令；bpy 是 Blender 用于访问对象、材质、相机、灯光、几何体、渲染设置和项目数据的 Python 模块。

Willison 发布了最终脚本，其最后一次修订包含 128 行。该 scene source 创建并修改了自行车、鸟、木栈道木板、云朵、海滩小屋、帆船和编织篮等独立元素。

这些证据限定了这一主张的范围。实验表明，一款编程智能体、一个模型配置和一套本地 Blender 安装完成了一个特定的风格化场景。它并不能证明这一方法对任意 3D 工作都具备普遍可靠性。

不过，这一工作流跨越了重要边界。一条对话式指令变成了代码，代码控制了一款成熟的桌面应用，而应用同时产出了可编辑项目和最终渲染结果。

为什么 macOS 上的 Blender 已为这一时刻做好准备

Blender 已提供自动化接口，而编程智能体则负责翻译、迭代与执行。

编程智能体最适合处理这样的系统：它们能够检查系统、编写小型程序、执行程序，并评估可观察的结果。Blender 无须专门的智能体插件，就支持这套循环的每一个环节。

其 Python API 将场景对象作为可编程数据暴露出来。脚本能够创建网格、调整坐标、分配材质、定位相机、配置灯光、保存项目文件，并启动渲染。

该应用在 macOS 上也接受命令行参数。安装完整桌面应用后，其内部可执行文件便可从终端运行。因此，编程智能体会将 Blender 视为本地机器上另一个可用工具。

这改变了集成问题。开发者不必等待一个专门的“Blender connector”，将一套有限的自然语言命令转换为界面操作。智能体可以改用技术美术人员早已可用的脚本和命令行机制。

这种方式契合 Codex 在本地环境中的工作方式。根据 Codex documentation，智能体可以检查文件、使用终端、编辑代码，并在用户授予的权限范围内运行命令。

Blender 在应用层提供确定性的执行。语言模型则提供一个并不完美但灵活的规划器，将意图转换为 Python。两者单独都无法提供完整工作流。

时机之所以重要，是因为当前编程智能体能够维持比简单自动补全系统更长的操作序列。它们可以创建脚本、运行脚本、发现错误、修改文件，并在保留项目状态的同时重复这一过程。

传统聊天机器人或许会生成示例 Blender Python 代码，用户还需自行复制、调试并运行。智能体则可以在同一个工作会话中处理这些步骤，从而弥合执行上的缺口。

视觉输出也为智能体和用户提供了具体的检查点。与逐一阅读生成脚本中的所有坐标相比，渲染图能更快暴露构图错误、缺失几何体、光照不佳或画面元素过载等问题。

然而，视觉反馈并不保证视觉判断力。智能体可以成功渲染一张仍存在生理结构别扭、比例不一致、物体相交或构图薄弱等问题的图像。执行成功与艺术成功仍是两套独立标准。

这正是本地应用的重要性所在。Blender 会在初始生成后保留可编辑的几何体和材质。人类艺术家可以直接修正缺陷，而不必要求模型从头重新生成一张不透明的图像。

对于许多创意任务而言，可编辑性比醒目的首个结果更有价值。它让团队可以保留已获批准的元素、隔离错误，并且只改动需要处理的部分。

真正的竞争是 API 对阵界面自动化

Willison 的实验更有利于那些具备可编程内部模型的应用，而非依赖模拟点击的工作流。

计算机使用智能体通常通过解读屏幕截图并控制鼠标或键盘来操作软件。这种路径具备广泛兼容性，因为几乎每款桌面应用都有界面。

它也带来了不确定性。按钮会移动，对话框会中断操作序列，窗口焦点会变化，智能体必须从像素中推断状态。一次漏点就可能悄然改变整个工作流的方向。

Blender 的 Python API 避开了许多这类歧义。智能体可以通过具名操作来定位对象、相机、材质或渲染设置。所得脚本成为其操作的可检查记录。

这并非完美的确定性。生成的代码可能包含无效调用、选择不佳的参数或逻辑错误。Blender 的不同版本也可能改变 API 行为。

但与界面操作失败相比，代码失败通常能留下更好的证据。用户可以保留脚本、检查异常、比较修订版本，并重新运行同一条命令。

.blend 文件则增加了另一层可检查性。它包含的是结构化场景，而不只是最终像素。用户可以打开项目，检查智能体创建的内容。

Willison 的最终脚本体现了这种结构。它以程序化方式放置木栈道木板、构建棕榈叶、生成泡沫线条，并添加独立的篮子元素。这些都是可寻址组件，而非一张合并后的图片。

这为迭代提示带来了实际优势。“添加背景”可以修改现有场景，而不会丢弃自行车和鹈鹕。“做得更好”可以在保留既有工作的同时优化选定组件。

弱点在于，模糊语言依旧会迫使模型做出未明确说明的设计选择。“更好”可能意味着更多细节、更清晰的构图、更强的真实感，或者只是更多装饰物。

Willison 的结果倾向于精致、玩具般的海岸插画风格。另一位用户可能想要物理真实感或简约的编辑风格。智能体无法可靠地推断每一种未言明的偏好。

这为创意软件供应商带来了新的责任。拥有文档化脚本接口、稳定文件格式和无界面执行能力的产品，更容易由智能体操作，也更容易供用户审计。

仅暴露视觉控件的应用，会让智能体处于对人类交互进行脆弱模仿的状态。暴露结构化命令的应用，则让智能体能更贴近程序的底层状态开展工作。

Blender 的优势尤其突出，因为它结合了视觉编辑、Python 自动化、渲染、动画和原生项目文件。这种组合使它既成为生产工具，也成为执行环境。

同一原则也适用于 3D 图形之外的领域。当项目可以通过代码创建和修改时，视频编辑器、设计应用、数据工具和数字音频工作站都会成为更好的智能体目标。

这并不意味着图形界面会被淘汰，而是改变了其角色。智能体可以处理重复性的构建工作，而界面仍是人们审查、修正并进行艺术指导的场所。

鹈鹕渲染并未证明什么

一次成功演示证明的是工作流的可行性，而不是可靠的创意生产能力。

Willison 展示的是个人实验，而不是基准测试。没有重复试验、独立评估者、受控提示词，也没有跨模型和 Blender 版本的比较。

所报告的耗时是有用的观察结果，但不应被泛化为性能指标。渲染时间取决于 Mac、场景复杂度、渲染引擎、分辨率，以及智能体尝试的次数。

该案例也受益于一个宽容的主题。一只骑自行车的风格化鹈鹕可以容忍夸张的解剖结构和俏皮的比例。建筑可视化、产品设计、医学动画和工程工作则对精度提出更严格的要求。

一个场景即便看起来很有说服力，技术质量仍可能不佳。网格拓扑或许难以编辑。材质在不同光照下的表现可能不一致。物体也可能在选定相机角度之外发生相交。

这里同样没有证据表明，智能体针对动画、实时渲染或下游导出优化了几何体。一张静态图像只测试了一个视角和一个时刻下的场景。

最终脚本以程序化方式构建了大量视觉元素。这为用户提供了可追溯的产物，但如果缺乏清晰的组织结构，生成的程序化代码可能会变得难以维护。

连续的提示词可能会加剧这一问题。代理可能只是不断追加新操作，而不是重新设计不稳定的基础。项目的视觉效果可以有所提升，但其内部构造却可能变得更加脆弱。

安全性同样值得重视。能够执行 Blender 的编程代理，也可以在其环境现有权限范围内执行生成的 Python。用户应检查不熟悉的脚本，并限制其对敏感文件的访问。

Blender 可执行文件本身并非风险所在。真正的风险在于，在不了解生成代码会读取、写入、下载或启动哪些内容的情况下，授予它广泛访问权限。

与托管式图像生成器相比，本地代理也形成了更复杂的信任边界。它们可能访问同一台计算机上的项目目录、参考图、脚本、渲染输出及其他资源。

团队需要明确规定代理可以使用哪些目录，以及哪些命令必须经过批准。当创意项目包含未发布的设计或客户资料时，这些控制措施就更为重要。

许可带来了另一类担忧。Blender 依据 GNU General Public License 发布，而艺术输出通常仍归创作者所有。Blender license 并不能解决涉及生成代码、训练数据、第三方资产或复制风格的权利问题。

用户仍必须追踪纹理、模型、参考图和其他输入的来源。可编辑输出比扁平化图像更容易检查，但可编辑性并不能证明其来源清晰无误。

因此，质量控制仍然是人类的工作。经验丰富的艺术家能够识别解剖结构、构图、灯光和制作上的缺陷，而通用编程代理可能会忽略这些问题。

最恰当的解读应当保持克制。该测试表明，编程代理能够编排真实的创意应用，并产出有用的起点。但这并不意味着创意指导已经实现自动化。

编程代理获得的不只是一个图像生成器

更深层的变化，在于创建了一套可复用的制作系统，而非单一的视觉资产。

Willison 在实验结束时，请 Codex 创建一项技能，说明如何使用已安装的 Blender 应用。技能是一组操作说明，可帮助代理重复执行专业化工作流。

这最后一步将一次成功的会话转化为可复用的知识。未来的请求不再需要重新摸索可执行文件路径、后台模式命令，或场景脚本编写的基本方法。

这很重要，因为代理的生产力通常依赖于保留的流程。模型或许每次都能找到解决方案，但反复探索既浪费时间，也会引入差异。

保存下来的技能可以记录启动 Blender 的命令、预期文件位置、渲染约定和验证步骤。它也可以规定代理应在何时保存中间 .blend 文件。

其核心教训对工程团队来说并不陌生：一次性的成果在其流程被记录、审查和复用后，会变得更有价值。

团队可以将同样的模式应用于品牌渲染、产品样机、分镜场景或定期数据可视化。代理将在有文档记录的流水线内进行构建，而不是为每个项目临时 improvising。

优秀的可复用工作流会将生成的源文件与渲染输出分开。它会保留提示词历史、统一命名场景对象，并在重大修改前保留检查点。

这些做法让代理的工作更容易审查，也能降低含糊的后续请求造成过度改动的风险。

Willison 的公开仓库记录了其中一部分历史。它包含连续版本的 .blend 文件、Python 脚本和导出的对话记录，让读者可以查看从最初请求到最终渲染的过程。

这份记录比最终图像本身更有价值。它展示了代理在哪些地方使用了代码、场景如何扩展，以及哪些产物仍可编辑。

探索类似工作流的组织应将提示词、脚本、项目文件和审查笔记视为相互关联的技术知识。可搜索的工程知识库能够保留工作流成功的原因，而不仅仅是文件存放的位置。

这种方法也改变了小型创意实验的经济性，而无需进行价格比较。开发者可以在让专业人士投入精细制作前，先测试一个视觉概念。

这不应被描述为取代 3D 艺术家。它改变的是起点。艺术家接手的可能是一个粗略但结构化的场景，而不是一段文字；开发者则可以探索那些过去在原型阶段之前便停滞的想法。

当生成对象被清晰地命名和分组时，交接会特别有用。专业人士随后可以替换较弱的几何体、调整材质，或重建绑定，而无需重新构建整个场景。

编程代理还可以将 Blender 与周边工具连接起来。它们可以准备输入数据、生成场景脚本、整理渲染结果，并调用媒体工具处理输出。

Willison 指出，代理可以渲染图像序列，并使用 FFmpeg 将其合成。这将模式从静态图像扩展为自动化动画流水线，尽管他的鹈鹕示例聚焦于渲染场景。

更广泛的价值在于编排。代理不必成为最出色的建模师、渲染师或视频编码器；它需要做的是协调专业工具，同时保留人类可以检查的产物。

Simon Willison 的 Blender 测试之后值得关注什么

三项信号将决定这一模式能否超越令人印象深刻的个人演示。

第一个信号是它能否在不同模型、机器和 Blender 版本之间复现。其他用户应能够给出相近的提示词，并获得有效脚本、可编辑项目文件和成功渲染。

重复测试不应只追踪是否出现了一张图像。还应考察错误率、重试次数、场景组织、渲染一致性，以及项目在后续编辑中的存续情况。

如果这些结果在不同环境中保持稳定，Blender 编程代理的论据将更有说服力。如果成功依赖于某一种模型配置和谨慎的补救提示词，这一工作流仍属于实验阶段。

第二个信号是，创意专业人士是否会将代理生成的场景采用为可用的起始资产。他们的判断很重要，因为他们能够评估拓扑、材质、灯光、命名、构图和下游兼容性。

专业工作流必须能够承受修改。场景应在多次提示后仍然易于理解，能在人与人之间顺畅交接，并支持超出原始相机视角的改动。

如果有证据表明艺术家正在完善生成的 .blend 文件，就会强化代理能够参与制作的说法。若只出现大量吸引眼球却一次性使用的渲染图，则会削弱这一观点。

第三个信号是创意软件厂商如何改善可编程访问。Blender 已经提供了成熟的 Python 接口和无头执行能力。其他应用可能会以更好的脚本支持、结构化项目 API、面向代理的文档或更安全的权限模型作出回应。

如果厂商投入这些能力，竞争将从原始界面控制转移开来。代理将越来越多地通过明确命令和可检查状态来操作应用程序。

如果厂商优先发展封闭式界面，代理就会继续依赖截图理解和模拟点击。这条路径可以覆盖更多软件，但仍然更难复现和审计。

Simon Willison 的示例为开发者提供了一个今天就能开展的实用测试。选择一个范围明确的场景，保留每个脚本和项目修订版本，并评估可编辑结果，而不只是最终渲染图。

询问代理是否创建了另一人能够理解的文件。检查下一条提示词是否能改进场景而不损害之前的工作。在授予生成的 Python 更广泛权限前，审查其代码。

最重要的是，根据交接质量来评判这一工作流。一张令人愉悦的鹈鹕图像能够吸引注意力，但可编辑场景、可读脚本和可重复流程才能创造持久价值。

这正是该实验所凸显的冲突。编程代理如今可以触及源代码仓库之外的广阔领域，但只有具备可访问控制的软件，才能为它们提供可靠路径。

下一个决定性的案例不会是视觉上最夸张的案例，而会是那些让人类能够打开项目、理解代理的选择、纠正其错误，并充满信心地继续推进工作的案例。