大模型做3D创作，看得见输出比规模更重要

一、一次反直觉的对比测试

先把测试现场还原一下。同一句提示词，分别交给同一家模型团队的两个版本：一个是大规格、主打深度推理的“旗舰版”，一个是小规格、主打速度与成本的“轻量版”。两边运行条件尽量拉平：都在该团队官方提供的智能体执行环境里运行，推理档位都开到最高，任务也完全一致——不借助任何现成素材，用纯代码在浏览器端基于WebGL标准的3D渲染引擎中，构建一个“熊猫骑电动车送外卖”的动态场景，并将画面渲染导出为一段10秒短片。

结果却出乎意料：

• 旗舰版：耗时约49分钟，消耗2300多万token，按闲时价格折算API成本约1.5美元。成片中，熊猫大部分时间背对镜头，观众只能看到背影，画面整体偏暗。
• 轻量版：耗时约43分钟，消耗7300多万token，成本约0.7美元。不仅按时出片，还做出了雨夜街道的氛围光效、印着“熊猫速递”字样的外卖箱，甚至补上了片头字幕。

也就是说，“更大、更贵”的那个版本，交出的作业在叙事完整度、画面质感、细节丰富度上全面落败，花的钱却约为对方的两倍。

二、胜负手：模型能不能“看见”自己的作品

复盘发现，两个版本的模型能力差距并不是主要矛盾，真正的分水岭是一个工程细节：能不能把渲染出来的画面“喂回”给模型看。

旗舰版在这次所用的执行环境里不支持图片输入，它两次尝试查看自己的渲染帧，都因通道不支持而报错。既然看不见，它只能退而求其次改用“盲调”策略——在代码里埋点做像素统计，用平均亮度、区域占比这类标量指标去间接推断画面效果，再据此调整参数。

轻量版则完全相反：整场任务里，它查看了几十次自己的渲染截图（测试记录显示为64次），形成“渲染—看图—发现—修改”的滚动循环，边看边改。

把两边的产出差异往回映射，几乎每一项都能对应到这条通道的有无：

• 背对镜头，属于构图与朝向问题。像素统计能告诉你“画面中央有一团黑白相间的像素”，却无法告诉你“主角的脸没有朝向观众”。看一眼截图，问题一目了然。
• 画面偏暗，属于光照与色调的审美判断。均值亮度可以量化，但“暗得压抑”和“暗得有氛围”之间，隔着只有视觉才能分辨的鸿沟。
• 雨夜街道、外卖箱贴纸、片头字幕，属于“看着成品找差距”才会产生的增量优化：看到路面空旷，才会想到加雨幕反射；看到开场黑场突兀，才会想到补字幕过场。

一句话总结：这次测试比的不是“谁的脑子更大”，而是“谁睁着眼睛干活”。

三、技术原理：开环盲调与闭环反馈差在哪

可以把两种工作方式抽象成两条链路：

• 开环（盲调）：写代码 → 渲染 → 数值采样 → 调参 → 再渲染
• 闭环（看图迭代）：写代码 → 渲染 → 截图回传 → 视觉诊断 → 定向修改 → 再渲染

差异的本质，是反馈信号的“信息保真度”。一张渲染帧承载的信息是高维的：主体姿态与朝向、光影分布、遮挡关系、构图留白、文字可读性……而像素统计本质上是对这张图做了一次激进的降维压缩，把海量视觉信息压成几个标量。压缩过程中，恰恰把“最需要被看见的问题”丢掉了。这就是信息瓶颈：你能优化的上限，取决于反馈通道的带宽。

更微妙的一点是：这次测试里，旗舰版并不一定天生“看不了图”，而是所用执行环境没有打通图像回传这一环。这提醒所有做智能体工程的团队——瓶颈经常不在模型，而在管线。模型具备多模态输入能力，只代表它在接口层“能看”；执行框架是否把截图编码、回传并注入对话上下文，决定了它在系统层“真的看得到”。两者之间任何一环断裂，整条流水线就是睁眼瞎。

四、工程实践：把“看图迭代”做成可靠的流水线

如果你在做AI生成3D内容、自动出片、可视化搭建一类任务，下面几条经验可以直接参考。

1. 先做“回看冒烟测试”。 长任务启动前，让模型主动请求查看一张图，验证“渲染→截图→编码→回传→注入上下文”整条链路畅通。这就像上线前的健康检查，用一分钟避免几十分钟的无效产出。

2. 渲染侧批量化、无头化。 用无头渲染方式批量产出关键帧（如第0帧、动作峰值帧、结尾帧），帧序列落盘到对象存储，供智能体按需拉取。回看不求全，抓住关键帧就能定位大部分问题。

3. 校验分层，省着用“眼睛”。 第一层做确定性硬校验：渲染是否成功、帧数是否达标、报错日志是否为空、画面是否全黑，这一层用脚本完成，快且稳定；第二层才把关键帧交给模型做视觉评审。视觉输入是昂贵资源，应花在脚本判断不了的问题上。

4. 把“审美”翻译成检查清单。 不要笼统地问“这张图哪里有问题”，而是给模型一份结构化自查清单：主体是否朝向镜头、是否被场景元素遮挡、整体曝光是否在可接受区间、画面是否有视觉焦点、画面内文字是否清晰可读。清单越可核对，诊断越可靠。

示意性的迭代主循环大致如下：

for i in range(MAX_ITERATIONS):
    frames = render_headless(scene_code, key_frames)    # 无头渲染关键帧
    issues = hard_check(frames, logs)                   # 第一层：脚本硬校验
    if issues:
        scene_code = model.revise(scene_code, issues)
        continue
    critique = model.look_and_critique(frames, checklist)  # 第二层：视觉评审
    if critique.passed:
        break
    scene_code = model.revise(scene_code, critique)    # 定向修改
export_video(frames)

5. 管好迭代预算。 每次“看图—修改—重渲染”都在消耗算力和时间。应为迭代次数、单轮回看帧数设置上限，并为每一轮修改保留快照。把流水线部署到云端时，可以借助GPU算力做批量渲染、对象存储归档每轮帧序列、日志服务记录每轮修改摘要——例如在百度智能云等平台上组合这几类通用云服务，就能低成本搭出一条可复盘的迭代管线。

五、选型启示：算“系统账”，不算“参数账”

这次测试对选型的启示，比测试本身更值钱。

第一，能力匹配优先于参数规模。 对“生成视觉内容”这类任务，支持图像输入是入场券。没有这张票，参数再大的模型也只能在黑暗里摸索。

第二，评估要看系统，不要看单点。 模型的最终表现 = 模型能力 × 工具链支持度 × 反馈通道质量。任何跑分对比，如果反馈通道不对等，结论都不可信——你以为在比两个模型，其实在比两条管线。

第三，成本要按“任务总成本”算，不按单价算。 这次轻量版消耗的token约是旗舰版的三倍，但单价低得多，总成本反而只有一半左右。小模型“以量取胜”、用更多轮次迭代逼近目标，在总账上未必吃亏。

第四，长任务要设计“自证清白”的检查点。 几十分钟的自主任务，人工无法全程盯守。在每个检查点让模型输出可快速浏览的中间产物——关键帧缩略图、状态摘要、未解决问题清单——既方便人工抽查，也便于事后定位是哪一环出了问题。

六、结语

回到开头那个反直觉的结果：旗舰版输给轻量版，输在它全程看不见自己的画。对3D出片这类“生成—感知—再生成”的任务而言，能不能看见自己的输出，比模型大小更重要。给模型一双能看见作品的眼睛，往往比给它一个更大的脑子更划算——这是本次测试最值得记住的一条工程结论。