Fable 5.2 如何纯代码生成 1.4MB 视觉作品？

“纯代码生成视觉作品”最容易被理解成模型直接输出一张成品图，或者作品完全绕开图形引擎。严格来说，这两种理解都不准确。它描述的是另一条路线：场景、材质、光照和运动规则由程序定义，最终像素再由渲染程序计算。模型可以生成 Three.js、WebGL 或 WebGPU 代码，但图形 API 仍然是程序与 GPU 之间的接口。

掘金热榜文章把案例标为 Fable 5.2、1.4MB，并集中讨论了光追、水面、倒影和火光四类效果。但“1.4MB”究竟是网页、源码包、导出视频还是其他文件，是否包含依赖和媒体素材，以及“纯代码”是否允许调用图形库，仍需核对原始产物。文件体积可以说明交付方式，却不能直接说明画质、帧率或显存占用。

“纯代码视觉作品”究竟生成了什么？

程序化视觉最终可能落成三种不同产物：

因此，即使两个文件都是 1.4MB，含义也可能完全不同：网页的 1.4MB 关注加载成本，源码包的 1.4MB 关注文本与依赖规模，视频的 1.4MB 则取决于编码器、分辨率、帧率和时长。掘金标题没有给出足够信息来判定 Fable 5.2 属于哪一种，当前不应直接把它写成“1.4MB 的单文件网页”或“1.4MB 的成片”。

“纯代码”还需要拆成三个层次判断：

即使所有视觉内容都由程序生成，使用第三方图形库也不必然违反“纯代码”这一口径；反过来，如果模型调用图像 API 生成纹理，再把纹理嵌入网页，那么最终像素就不是完全由代码路径独立构造。讨论这个问题时，关键是分别记录资产、库和工具调用，明确“纯代码”具体指什么。

从代码生成到作品交付，大致会经过六个环节：

1. 理解需求，确定画面类型、镜头、交互和目标性能。
2. 规划场景，拆分几何体、材质、灯光、反射方式和后处理链。
3. 编写程序，把场景描述转换成 JavaScript、着色器和资源生成逻辑。
4. 运行渲染，由浏览器或图形引擎逐帧生成画面。
5. 观察结果，检查遮挡、反射缺失、噪声尺度、曝光和帧时间。
6. 迭代修正，在视觉质量与运行成本之间调整参数。

生成过程涉及两个角色：模型负责理解需求并编写程序，程序负责确定性地执行渲染逻辑。最终作品是否稳定，不会只由模型一次生成的代码决定，还取决于浮点精度、随机种子、时间推进方式、浏览器图形后端和具体设备。

相关材料可以提供一些参照，但不能作为 Fable 5.2 的技术依据。网易转载的一篇报道讨论了据称尚未正式发布的 Claude Fable 5.5，称其在没有调用图像或视频生成工具的情况下编写代码制作动画和 3D 场景，其中还使用了 Three.js；报道同时承认，这些测试缺乏统一评测环境，不能直接视为模型性能排名。至于检索中出现的 Fable 叙事网站及 Fable 动作 RPG，则分别属于内容平台和游戏项目，与本文案例没有可验证的技术关系。

“光追、水面和倒影”怎样在同一帧里工作？

一帧画面通常不是按“先生成水面、再生成倒影、最后加火光”的孤立步骤完成，而是共享相机、深度和光源信息。简化后的渲染链路可以表示为：

需求与场景描述
      ↓
相机 / 几何体 / 材质 / 光源
      ↓
主射线生成 → 几何求交 → 深度缓冲
      │                    │
      ├─ 直接光、阴影与反射分支
      │       ├─ 平面反射
      │       ├─ 屏幕空间反射 SSR
      │       └─ 光线追踪反射
      ▼
水面：波形位移 → 动态法线 → 菲涅耳混合
      ↓
火光：密度场或粒子 → 自发光与动态照明
      ↓
透明合成 → 辉光 → 色调映射 → 屏幕

传统光线追踪从相机像素生成主射线，与场景几何体求交。命中表面后，程序可以继续生成阴影射线，判断表面是否被光源直接照亮；也可以生成反射或折射射线，寻找其他物体。大量三角形会显著增加求交成本，因此实时系统通常使用 BVH 一类加速结构，先按空间层次排除不可能命中的包围盒。它解决的是“怎样更快找到交点”，而不是反射本身。

“光追”在演示语境中还需要进一步消歧。真正的光线追踪依赖几何求交；光线步进则沿着程序化距离场或密度场逐步前进，常用于烟雾、雾和体积火焰。如果案例中的“光追”实际指屏幕空间反射、立方体贴图或近似的二次光线，也不能仅凭画面效果反推其底层实现。尤其在移动端或单文件网页中，开发者可能用较便宜的近似方案换取实时帧率。

水面通常由几层机制共同完成。几何层可以用 Gerstner 波或噪声函数改变顶点位置，让轮廓本身发生起伏；仅在法线上增加扰动，则能产生波动感，却不会改变水体的几何轮廓。法线可以根据解析导数或噪声梯度实时计算。

着色层会同时读取反射与折射结果。菲涅耳权重由观察角度和材质折射率决定：视线越接近平行于水面，反射占比通常越高。折射可以来自重新渲染的场景、屏幕空间采样或光线追踪；深度差可用于估算水体厚度，再通过吸收和雾化参数调整颜色与透明度。由于这些结果依赖不透明场景和深度缓冲，水面通常在不透明物体之后渲染。

倒影则有三条常见路线：

它们的渲染顺序也不同。平面反射通常先渲染反射目标，再进入主画面；SSR 需要在主场景的不透明颜色与深度生成后执行；光线追踪反射则可以发生在材质着色阶段。实现倒影并不等于完整还原现实：屏幕空间方法缺少屏外内容，平面方法受限于表面形状，光线追踪则受制于采样预算。

没有预制图片时，程序可以生成网格、渐变天空、噪声材质、距离场和粒子系统，但仍需要处理透明度、遮挡与排序。下面是一段概念伪代码，用来展示这些机制如何进入同一帧；它不是对 Fable 5.2 原始源码的还原：

# 概念伪代码；reflection_mode 可为 planar、ssr 或 rt
for pixel in viewport:
    primary_ray = make_camera_ray(pixel)
    hit = bvh.intersect(scene, primary_ray)

    color = sample_background(primary_ray)
    depth = float("inf")

    if hit:
        depth = hit.t
        color = direct_lighting(hit)
        color += trace_shadow(hit)

    if hit and hit.material == "water":
        normal = sample_wave_normal(hit.position, time)
        reflected = sample_reflection(
            reflect(primary_ray, normal),
            mode=reflection_mode
        )
        refracted = sample_refraction(hit, depth_buffer)
        attenuation = exp(-absorption * estimate_water_depth(hit, depth))
        color = mix(
            refracted * attenuation,
            reflected,
            fresnel_weight(primary_ray, normal)
        )

    fire = integrate_fire_density(primary_ray, time)
    color += fire

    color = apply_bloom(color)
    framebuffer[pixel] = tone_map(color)

“火光与 1.4MB”分别考验什么？

火光的程序化实现可以走体积或粒子两条路线。体积路线通常用多个八度的分形布朗运动，也就是 fBm 噪声，构造随时间变化的密度场，再沿视线积分得到发光颜色。粒子路线则生成许多寿命、速度和尺寸不同的微粒，通过加法混合叠加亮度。两者还可以组合，用体积雾承载主体，用少量火星粒子补充运动细节。

颜色映射常采用黑体色近似，把温度或能量强度转换为偏红、偏黄或偏白的颜色。这只是视觉近似，并不意味着程序真的模拟了燃烧化学反应。火焰边缘的随机抖动通常由时间函数和固定随机种子共同控制；如果火焰还要照亮附近物体，就需要额外加入动态点光或面光，并决定是否计算阴影。自发光只负责让火焰本身变亮，不会自动照亮环境。

火焰看起来“发光”还经常依赖辉光后处理：先提取高亮区域，经过降采样和多级模糊，再与原图合成。它扩大的是明亮区域的视觉范围，不是光源影响范围。没有泛光时，火焰仍可存在，只是高光边缘会更硬。

“1.4MB”对应哪个评价维度，取决于它所衡量的对象：

如果所谓“纯代码作品”只提供一个网页，那么 1.4MB 可能只是压缩前的 HTML、JavaScript 和 CSS；如果 Three.js、WASM、着色器或纹理通过 CDN 加载，本地文件会更小，但首次打开需要网络，版本也可能变化。反过来，把全部依赖打包进去能提高可复现性，却不等于运行更快。

影响运行性能的主要因素包括：分辨率与设备像素比、反射缓冲尺寸、二次光线采样数、阴影数量、体积积分步数、粒子数量、透明物体过度绘制以及辉光链的层级。桌面浏览器可以提高反射分辨率和采样数，移动端则需要降低设备像素比、缩小反射目标、减少采样和粒子，或用更简单的水面法线替代波动几何。代码越精简，运行时仍可能很重；代码很大，也不代表每一帧都要执行全部逻辑。

要复现或评测这类作品，至少应记录以下信息：

• 完整源码、版本号或提交哈希，以及依赖锁文件。
• 媒体资产清单和运行时网络请求，用于确认是否真的没有外部素材。
• 随机种子、时间控制方式和质量档位。
• 浏览器、操作系统、GPU、驱动及使用的图形后端。
• 画布分辨率、设备像素比和是否启用动态降级。
• 首帧时间、平均帧时间、帧率波动、GPU 显存和长时间运行表现。
• 基准画面、参数快照及导出文件校验值。

它与 中的 FLUX.1-dev 路线不同。按照该资料的描述，FLUX.1-dev 路线先生成位图，再通过色彩量化适配 PICO-8 的 16 色调色板和 128×128 分辨率，交付物是已经确定的像素图像。代码渲染路线交付的则是场景规则和可执行程序，像素要到运行时才产生，因此调节分辨率、动画和交互更容易，代价则转移到浏览器、GPU 和性能稳定性上。资料中提到的色彩量化、VAE Tiling、CPU offload 和 LoRA 属于 FLUX.1-dev 的实现背景，不能直接移植为 Fable 5.2 的技术结论。

就目前可核验的信息而言，判断 Fable 5.2 案例不能只看“1.4MB”，还要看视觉内容能否被压缩成一段可检查、可修改、可重复执行的程序。仍待核实的问题包括：原始源码和生成日志是否公开，依赖是否完整，随机结果能否复现，不同设备能否保持接近的帧率与画面，以及 Fable 5.2 本身是否有足够公开的技术资料。相邻的 Fable 5.5 报道也承认缺少统一评测环境，因此更适合作为自主代码生成视觉的案例，而不是渲染器性能结论。在这些问题得到回答之前，不宜把单次演示视为通用能力的证明，应通过源码、首帧时间、帧时间、显存和跨设备一致性加以检验。