用 Three.js 当试金石：测试大模型能否把「过程」传给小模型

Reddit 用户近日在 r/LocalLLaMA 板块分享了一项有趣的实验：让大模型生成一段「过程性脚手架」，看能否在不微调参数的前提下，帮助小模型在复杂的 Three.js 渲染任务上把场景搭得更合理。作者自行完成的初步肉眼评估显示，小模型（27B 乃至 Q3_K_M 量化后的 35B）在套入该脚手架后，画面结构与可读性出现明显改善，而大模型本身的提升主要体现在润色层面。

实验缘起：小模型「知道」但「做不好」

作者观察到一个普遍现象：小模型虽然掌握语法、库函数和大致任务语义，但生成的输出往往缺乏层次、规划与视觉结构。常规代码任务中，这部分弱点容易被冗长解释或既有模式掩盖。因此他选择 Three.js 作为试金石——渲染结果会直接暴露模型的「结构能力」：几何规划、相机、灯光、层级与构图若没到位，画面一眼就能看出问题。

两类截然不同的任务

实验选取两个差异显著的领域：

• 角色类：Thriller 风格的编舞场景，涉及多角色识别、动画、灯光与舞台调度；
• 机械类：低面数的 BMPT-72 炮塔，强调外形识别、武器布置与剪影。

两者共用 Three.js，但考察的能力完全不同：前者比角色、姿态与环境，后者比结构、比例与剪影。作者强调，实验目标并非迁移场景本身的内容，而是迁移「过程」。

脚手架协议

设大模型 A、小模型 B、源提示 P1、目标提示 P2、过程性脚手架 S，步骤为：

• 先分别用 A 与 B 跑 P1 与 P2，得到 D1A、D2A、D1B、D2B；
• 再让 A 基于 B 在 P1 上的弱点生成 S；生成 S 时 A 不可见 P2、D2A，也不知道目标域测试是什么；
• 最后用 B 带着 S 再跑 P1、P2，得到 D1B_S 与 D2B_S。

核心问题是：D2B_S 是否比 D2B 更接近 D2A？即脚手架能否跨任务改善小模型，而非仅在见过答案的题目上提升。

初步肉眼评估

作者对比了 DeepSeek V4 Pro、Qwen 27B 以及 Q3_K_M 量化的 35B A3：

• DeepSeek V4 Pro 本就较强，脚手架主要带来「打磨」：灯光、呈现与整体美术更精致，结构层面增益有限；
• Qwen 27B 提升最为显著：基线版本常出现「黑暗中散落几何体」的典型小模型失败模式，套用脚手架后，Thriller 场景的分层、灯光、舞台分隔明显改善；炮塔任务中，机身、炮塔、武器、剪影也更加清晰；
• 量化后的 35B A3 同样受益，尽管并非质变，但能更好地遵循构造流程。

关键发现是：脚手架没有把源域的内容「抄」进目标域——Thriller 细节不会出现在坦克上，人肢也不会冒到炮塔边。真正被传递的是更抽象的过程规范：

• 先规划后编码；
• 定义场景契约；
• 分层构建；
• 分离主体、环境、灯光与相机；
• 保留剪影；
• 补充辨识特征；
• 避免纯几何体堆砌；
• 出稿前自审。

效应不对称

大模型获得的主要是润色，小模型收获最多的是结构与可读性。作者把这一现象解释为：小模型未必缺知识，而是缺乏在长生成中维持整体结构的过程控制能力；脚手架相当于在上下文中临时注入一份「规划纪律」，让模型把已经具备的能力组织起来。

下一步：盲测与可复用性

作者明确指出目前只是肉眼 sanity check，尚非正式 benchmark。下一步要把实验改造成盲测：由不知情的评估者仅凭渲染图对 D2A、D2B、D2B_S 三份输出打分，看是否能在大量提示上稳定满足 Score(D2A, D2B_S) > Score(D2A, D2B)。若成立，则脚手架传递的就不是单次提示技巧，而是一种可复用的过程。