做 3D 原型，GPT-6 的三条路别走反了

做 3D 原型这件事，最近突然有了一种很危险的轻松感。

把一句描述扔给 GPT-6，Blender 自己打开，模型自己长出来，渲染图也像模像样。看完演示，很容易以为从此不必碰软件界面了。

先别急着把鼠标交出去。

一份公开的 Blender 实操记录把同一个问题拆成了三条路，Computer Use、MCP、CLI 加 Python。它们的差别，不是 AI 会不会做 3D，而是你最后拿到的是一次炫目的画面，还是一个下周还能继续改的项目。

如果你要做产品演示、游戏原型、建筑概念图，第一版最该问的不是“能不能生成”，而是“这套东西怎么复跑”。

先别迷信它会点按钮

Computer Use 最像人。

它看着 Blender 界面点菜单、拖参数、切视角。好处是你能顺着过程看懂它做了什么，卡住时也容易接手。公开记录里，它用这条路搭了祈年殿，跑了大约四小时。

图源为上述公开实操记录，画面能看见模型在 Blender 场景里，而不是一张脱离工程文件的效果图。

可这种直观有账单。

界面自动化把大量时间花在找控件、等渲染、反复确认状态上。它适合第一次摸陌生软件，适合需要人随时插手的探索，也适合你还没说清目标的阶段。要它连续做一个复杂资产，成本和时长都会开始磨人。

好家伙，AI 不是从鼠标里长出了美术总监，它只是很勤快地替你点了很多次。

真正干活的，是可检查的脚本

MCP 让模型直接读取场景信息并调用软件能力，CLI 则让它启动 Blender 后运行 Python。两条路都比盯着界面高效得多，最后也都会落到 Blender 的 Python API 上。

这点很关键。

一辆摩托车能不能继续改颜色、换轮组、做拆解动画，不取决于渲染图有多亮，而取决于车架、轮毂、材质和相机有没有留成独立、命名清楚的对象。公开实操里的摩托车案例就更适合这条路。

图源为上述公开实操记录。能继续选中、替换和导出的场景，才比一张漂亮截图更有用。

MCP 的优势是能看见正在运行的场景，适合改到一半还要问 AI“这一块为什么穿模”。CLI 的优势是能把脚本留进仓库，下一次换个尺寸、材质或参考图再跑一遍。两者不必争谁更高级，核心问题只有一个。

这次任务，是一次现场协作，还是一条以后会重复执行的生产线？

前者用 MCP，后者优先 CLI 加 Python。只有还在摸索软件、需要看着它学会操作时，再把 Computer Use 放到前面。

复杂任务还有个很实用的避坑法，别一上来就让它“完整做一座建筑”或“精细复刻一辆车”。这种提示词看着威风，实际会把检索、建模、材质、渲染和返工塞进同一次长跑里。公开实操也记录过，动画生成在单次运行中超时了。

更稳的写法，是先让它做一个质量样板。

先完成一个可编辑的低模版本，只做主体比例和主要部件。
渲染正面、侧面和局部各一张，附上对象清单。
我确认比例后，再补材质、细节和动画。
任何阶段报错或超时，都保留当前 .blend 文件和脚本。

这不是把 AI 当实习生折腾，而是把一个不可控的大任务切成能验收的小回合。模型跑得再快，也需要一个明确的停靠点。

第一版交付，至少留住四样东西

别只让 Agent 回一句“完成”。那种完成最容易在第二天打开文件时变成一团空气。

给它任务时，可以直接加上这段要求。

所有主要部件保持独立并清晰命名。
每完成一批资产就渲染检查，发现穿模、比例或材质问题后修正。
保存可编辑的 .blend 文件，并导出本次运行使用的 Python 脚本。
交付物附一张总览渲染图和一个对象清单。

这四样东西很朴素，却能把演示和资产分开。

独立对象决定后面能不能改，脚本决定能不能复跑，渲染图负责验收，对象清单负责让下一位接手的人知道文件里有什么。没有这些，再好看的第一张图也只是一次性烟花。

还有一个边界得提前写进任务里。规则几何、建筑、车辆、机械件，比较适合让模型一层层拆开做。人物、生物和需要细腻雕刻的角色，仍然容易在结构和细节上失手。遇到这类任务，可以先用专门的 3D 生成工具拿一个粗胚，再回 Blender 做绑定、材质和镜头。

不是哥们，别拿一个复杂角色去考它会不会当资深雕刻师。那是给额度上强度。

AI 操作 Blender 的有趣之处，不是它终于会画一个 3D 图，而是它开始能参与一条真实的软件流水线。你负责把交付标准钉住，它负责把重复劳动扛走。

如果现在让你做第一个 3D 原型，你更愿意先看着它点界面，还是直接留下能复跑的脚本？