方案评审 · 从「3D 城市场景」转向「分层视觉合成」

批次 510 ｜ 2026-09-16 ｜ 类型：纯分析批，零代码改动

---

结论（先给判断）

你这份方案的主干是对的，而且它恰好命中了我们连续三批卡死的真正原因。但方案里有四处需要修正 —— 其中一处若不修正，会把你重新带回「两台相机」那个错误框架里。

三句话总结：

1. "先拆解参考图成可控视觉层 → 建艺术合成引擎 → 再映射真实数据" —— 这是全程最重要的一条，顺序完全正确，且已被实测证实可行。
2. "双视点合成是最值得保留的核心" —— 这一条要降级。它不是核心，是结果。当城市被拆成独立图层后，"两个视点"自动退化为"两个图层各自的投影约定"，不再需要"相机"这个概念。继续用相机隐喻，就是你说的"被错误框架带着跑"。
3. "数据真实，视觉艺术化" —— 这条推翻了我上一批的"尺度天花板"结论。你是对的：一旦脱离物理相机，高度只是一个可自由映射的构图参数。

---

一、先说一件我必须承认的事：我对样张的理解错了

在评审你的方案之前，先纠正我自己。看完原图并做像素级测量后，我此前对样张的描述有两处硬错误：

实测数据（地平线以下区域，约占画面 44%）：

也就是说：样张的城市区是一大片青蓝色、中高亮度、纹理极密的连续区域，塔群是个体清晰、轮廓分明的高楼 —— 完全不是"暗色剪影"。

我 490 那批"柱阵 → 细带"的两极摆动，根因不是"画法不对"，而是我把目标本身看错了：我以为要压暗，实际样张的城市比我做的亮得多。

这条修正比任何参数都有价值 —— 它说明前三批的失败不在工程能力，在靶子瞄错了。

---

二、样张的真实解剖：9 个可分离层

我把原图做了多尺度分解（大尺度=天空底 / 中尺度=线面结构 / 小尺度=星点与细节），分离结果如下。

这一节是你方案第一句"先把参考图拆解成可控视觉层"的实证执行。

这张表揭示的三个关键事实

事实一：九层之间没有相互依赖 —— 层 i 的生成不需要知道层 j 的内容。

这在工程上意味着分层合成不只是"可能"，而是天然可并行。你的方案成立，有实证支撑。

事实二：真正撑起画面的面积只有 4 层。

⑦ 城市天际线（12.7%）+ ⑧ 俯视肌理（33.6%）+ ① 天空底（25.8%）+ ⑤ 辐射网（6.0%）≈ 78% 的画面。

其余五层（②③④⑥⑨）合计不到 10% 面积，但全都是"气质层" —— 去掉它们画面立刻从"作品"变成"图表"。这解释了为什么单靠调城市参数永远调不出感觉：我一直在 78% 的工程层里打转，从未立起那 10% 的气质层。

事实三：画面真正的构图骨架是第 ⑤ 层"中轴光柱 + 辐射网"，不是城市。

它只占 6.0% 面积，却把月亮（52.4%）、人影（画面底部中央）、城市（两侧）、道路（向外扩散）全部串在一条中轴线上。这一层我此前完全没有发现。

而它恰好是真实数据最优雅的落点 —— 可以用真实路网投影成辐射网。

---

三、逐条评审你的方案

✅ 完全成立（4 条）

⚠️ 需要修正（4 条）

修正一：「双视点合成」不是核心，是结果 —— 建议放弃"相机"这个隐喻

你原文有两句：前面说"双视点合成是整个方案最值得保留的核心"，后面说"你不会再被'两台相机'这个错误的框架带着跑"。这两句其实是矛盾的，而后者才是对的。

真相是：当城市被拆成 ⑦ 天际线层 + ⑧ 肌理层 两个独立图层后：

旧的错误框架：  一个 3D 场景 ← 两台相机 ← 物理上互斥 ← 无解
正确的框架：    两个独立图层，各自有自己的「投影假设」
                 ⑦ 层：假设视点低 → 塔群遮挡关系向上堆叠
                 ⑧ 层：假设视点高 → 路网向下透视收敛
                 ↓
                 合成时按带融合，不需要任何"相机"存在

"双视点"是拆层之后的自然结果，把它当成核心来追求，就会重新掉进"怎么让一台相机同时做到两件事"的死循环。 我 v3/v4 两个原型就是在这个框架里打转的。

修正二：「荧光粒子」需要精确化 —— 城市不是粒子云

样张城市的构成是三层叠加，不是粒子系统：

城市主体是连续线框，不是散点。如果用 GPU 粒子系统去实现，会重新掉进 440 那批「LED 点阵墙」的坑。建议措辞改为「荧光线条 + 稀点光 + Bloom」。

修正三：技术栈方向对，但阶段划分要改 —— 阶段 0 用不上 Three.js

你建议的核心栈是 Three.js + WebGL + GLSL + GPU Particle。方向我认同，但：

阶段 0（语法复刻）根本用不上 Three.js。 它是纯 2D 图层合成，一个全屏 quad 的 fragment shader 就够了。引入 3D 引擎会让人本能地去建 3D 场景 —— 这正是前面卡死的机制本身。

• 阶段 0：Python/numpy 图层合成器（秒级，便于调参）
• 阶段 1：同上，输入换成真实数据
• 阶段 2：才 GLSL 化 + Three.js 交互层

修正四：方案里有两个互相矛盾的下一步，建议按后者走

你前面建议「下一步做台北 101 × 3km POC」，后面说「先做样张生成器，不碰全球城市、不碰 GPS、不管网页」。

建议按后者。 台北 POC 仍要背真实数据 —— 一旦数据形态与语法不匹配，立刻又会陷入"改数据还是改语法"的双变量纠结。先纯语法（零数据），再映射（有数据），是唯一能隔离变量的顺序。台北 101 留到阶段 1 的第一个样本。

➕ 我要补充（3 条，方案里没有）

补充一：必须钉死一条代码级设计公理

「语法层可以自由，但每个进入画面的城市元素必须可追溯到真实数据」。

这条不是审美要求，是红线防御。 你的"艺术合成引擎"如果做得太自由，会自然滑向"我画一张好看的黑青插画" —— 那就是 AI 生图/纯手绘，再次触项目红线。

正确做法：每个图元带 source 字段（osm:way/12345 或 synth:seed=7），合成器可随时输出"画面构成溯源表"。你说的"不能伪造城市事实"，要变成代码约束而不是口头原则。

补充二：样张里有两个"可识别性锚点"，引擎必须留槽位

让用户"一眼认出这是我的城市"的，不是整体轮廓，而是具体地标：

• 右侧环形建筑（体育场/体育场式，样张右下角）
• 塔群中个别超高塔（高出天际线一个量级）

引擎必须预留"地标高亮槽位" —— 用真实地标的 footprint 单独渲染 + 加强 Bloom。这是"这是我的城市"的唯一来源。

补充三：第 ⑤ 层（辐射网）是真实数据的最佳落点

前面提到，⑤ 是画面真正的构图骨架。它天然可由真实路网驱动：把真实道路按距离中心分级 → 投影成辐射网格 → 越近中心越亮。

这一层同时解决了三个问题：构图骨架有了、真实数据有落点了、"空间感"有了（视差就作用在这一层）。

---

四、修正后的路线

阶段 0 · 语法复刻器            ← 现在做这个
  输入：无（零真实数据）
  输出：一张「同一个产品世界观」的画面
  构成：9 层独立生成器 + 合成器 + 调色/Bloom
  技术：Python/numpy（不碰 Three.js、不碰 worktree）
  验收：你的眼睛（世界观一致，非像素一致）

阶段 1 · 真实数据映射
  ⑦ 层 ← 真实建筑 footprint + 高度（含视觉高度映射）
  ⑧ 层 ← 真实路网 + 街区 + 水系
  ⑤ 层 ← 真实路网投影成辐射网
  地标槽位 ← 真实地标（台北 101 / 北京中国尊）
  样本：台北 101 × 3km（有真数据）+ 诸暨（弱数据，验证高度映射）
  验收：你的眼睛 + 「我能不能认出这是哪个城市」

阶段 2 · 实时化与交互        ← 才引入 WebGL/Three.js
  GLSL 化、60 FPS、鼠标视差、点击地标

阶段 3 · 全球化
  纯数据生产问题（Geo Tile 流水线），非核心技术问题

---

五、要你拍的三个板

---

六、本轮产物与纪律

产物：

• assets-510/LAYERS-ct1-decomposition.png —— 样张 9 层拆解图（本分析的核心证据）
• 本文档 ROUND-20260916-510-方案评审.md + 同内容 HTML

纪律：本批为纯分析批。

• 主仓 src/、functions/ 零改动
• worktree 未提交、未部署
• 线上 /sky 仍为 09-13 v2
• CT-1 冻结基线未覆盖
• 新增仅为分析脚本 proto2d/analyze_ref.py、proto2d/decompose_layers.py

关键修正记录（供后续批次引用）：

1. 样张地平线真值 56.2%（此前误用 69.76%，源于标注面板拼接缝）
2. 样张城市区不是暗色剪影，是青蓝色中高亮连续结构（下半平均 L=34.9，最大连续亮块 47.98 万 px）——推翻 490 批及之前的靶子设定
3. "诸暨 60m 做不出天际线" 是过度约束，仅成立于物理真实渲染前提；艺术化映射下不成立
4. 画面构图骨架是第 ⑤ 层辐射网（6.0% 面积），非城市本体