让 AI 建一个“完整的星球”，听起来顺理成章：游戏里不是有一颗星球吗？一次真实尝试的结果是，额度大量消耗，星球却没有建出来。问题不出在模型不够强，而出在任务本身被描述错了。
星球不是一整块建模
游戏世界从来不是按真实尺度建造的。在那次尝试里，需求是“把星球上的建模都建出来”，但游戏实际的实现方式是工程化的：外面是一个星球，玩家进入时播放过场动画，然后加载当前的一个区域，区域有边界。完整的视觉印象，由一个星球外壳加上里面五六个场景拼成。
要求模型按真实星球那样的面积去建模，AI 做不到，人也做不到。任务是“造一颗星球”，还是“做一个由分区加载组成的游戏世界”，规模相差几个数量级——前者在物理上就不可行。任务描述直接决定了任务规模，也决定了它有没有解。
需求错了，代价不只是做不出来。同一时期的使用观察里，一类常见的抱怨是两百美元的订阅额度一周耗尽，做出来的东西还不符合要求；背后的原因正是要求太多、对要做的东西缺乏概念，还有人沿用“你是一个某某”式的提示词模板，用大量文字去规定模型本不需要被规定的部分。
与之对照，另一次使用的消耗小得多：一个 Roguelike 小游戏先花了额度的 3%，再扩展成吸血鬼幸存者那种一直刷怪、不断升级选武器的无限玩法，又用了 2%。5% 的额度对应的是边界清晰、可以分步描述的任务。需要说明的是，订阅额度的百分比不是通用的成本单位，它取决于订阅档位、模型定价和具体任务，换算不出“做一款游戏要多少钱”；它能说明的只是相对规模——同样是让 AI 做游戏，任务表达不同，消耗可以差出很多倍。
给模型一段能写代码的接口
表达方式之外，工具接口也在影响这类任务的成本。
这次 3D 建模表现出色的一个原因，是Blender 过去几年积累的脚本基建。模型建模时用的不是在图形界面上点选，而是 bpy——Blender 自带的 Python 接口。它一直在写代码，界面停在欢迎页没有任何动静，过一会儿告诉你建好了，打开一看模型已经完成。过程中几乎不需要截图确认结果，Token 消耗很低。
游戏引擎也有类似的东西。Godot 引擎同样提供程序化接口，模型做完直接打开就能看到结果，省掉了操作界面的整个过程。对模型来说，用代码描述几何、灯光和场景，比在图形界面里逐步点击更精确，也更省。
这提示软件的一个调整方向：把核心能力做成模型可以直接调用的代码接口，界面留给人看交互和内容。当然，这条路依赖软件本身有成熟的脚本接口，不是每类工具都能照搬；图形创作类软件里，操作界面本身仍是表达的一部分。
从数字模型到实物（延伸）
3D 建模的下游连着 3D 打印。以前打印用的模型基本来自社区，别人建好的模型不符合要求时很难修改：有人做过一个把 iPhone 变成闹钟的充电卡扣，模型是按 iPhone 18 做的，想改成自己的机型几乎改不动。建模能力接上之后，这类修改可以交给模型完成，打印机的配套软件也可以通过操作电脑代为使用，上料、支撑这些过去要专门学习的操作门槛随之降低。
不过建模成功只是第一步。材料、支撑结构、打印参数，这些实物环节仍然决定最终能不能打出来、打出来像不像。从数字模型到物理成品之间，还有一段需要动手验证的距离，建模顺利不能默认打印顺利。