Tempo Soul 首页视觉规格书 v3.0（整合版）

本文档地位：/sky 首页视觉的唯一权威（single source of truth）。

取代：SKY-VISUAL-STANDARD-v2.md（构图/色彩/亮度/判据全体继承并修订）、SKY-VISUAL-SPEC-v1.md、SKY-STYLE-DNA-v1.md、SKY-VISUAL-SPEC-v1-ADDENDUM-80-20.md（历史依据）。

新增吸收：老板《Tempo Soul 首页视觉规格书 V1.0》（2026-09-16）+ 批次 510 样张实测修正。

建档：可吉（WorkBuddy）｜日期：2026-09-16｜批次：520

上位纪律：真实数据管线红线不得触碰；未验收不得部署线上。

---

0. 一句话结论

把 /sky 首屏从「3D 城市场景」重新定义为「真实地理数据驱动的分层视觉合成系统」——这是正确的。但本批实测挖出了更根本的一件事：项目内部冻结的构图基线 CT-1，是老板参考图（ref-c）下半部被纵向压缩到 73.8% 的版本（两图上 48.8% 逐像素最大差仅 10，属 JPEG 噪声量级；下 51.2% 呈严格仿射关系 y=1.355x−344）。此后三个独立批次（440 / 480 / 490）、数千次迭代，全部在追这个被压缩过的靶子 —— 而且用错的判据把「城市带偏暗」判成了「城市带超亮」，修复方向整体反了。

一句话根因：靶子被改过，而且判据口径跟着一起错。 与技术能力无关。

⚠️ 本结论的证据等级与裁决状态（v3.0c 审计修正）

该结论现为 E1（本端可复现实测，方向经 falsify 检验），尚非 E0（E0 需要独立复核或老板确认）。它不依赖时间戳：方向性由「信息损失不可逆」检验确定 —— 5 种标准重采样核中最好的一个（LANCZOS）也只能从 CT-1 复原 ref-c 的 92.5% 细节，且下半部逐像素最大差达 243（远超「纯重编码」的色差量级），反命题被 falsify。

但「压缩是有意修改还是无意走样」这一点，文件本身无法回答 —— 只有老板能（§21 Q0）。 在 Q0/Q1 答复前，本文档凡由 ref-c 导出的全部阈值一律标记为「临时口径」（见 §1.4 与 §19.6）。

---

1. 文档地位与版本谱系

1.1 本文件是唯一权威

本文档是 /sky 首页视觉的 single source of truth。任何与本文件冲突的既有文档、代码注释、历史截图说明，以本文件为准。

1.2 版本谱系（谁被谁取代）

1.3 上位纪律（不可触碰）

1. 真实数据管线红线：禁止回归 AI 猜图 / AI 生图静态方案；禁止以位图整幅贴图作为默认路径。
2. 未验收不得部署线上。
3. 不得删除基准资产：docs/design/ 下全部基准图、D:\专家论证稿\、AI 地图主文件。
4. 不得以「待老板确认的口径」签发硬判据（v3.0c 新增）。任何阈值在被确认前，必须显式标注「临时口径」，且不得用它做出「达标 / 不达标」的终局判决。

1.4 证据等级与复核制度（v3.0c 新增 · 制度性修复）

本节的由来：v3.0 在 §2 写下「实测证据 > 老板原文 > 既有规范 > 我的推断」，但「本端实测」恰恰是我自己做的实验 —— 等于把「我的推断」换了个名字排到第二位。这构成一个循环：用自己未复核的实测去推翻别人的说法，再用「实测优先」这条自己定的规则为自己背书。 本节把这个漏洞制度化堵住。

强制要求（写入流程，不写在别处）：

1. 每一处关键测量必须注明：① 脚本路径 ② 输入资产路径（含哈希）③ 随机性（确定性 / 种子）④ 证据等级 ⑤ 复核路径（谁能怎样复现）。
2. 关键测量清单（下列 5 项为「靶子级」测量，改一项等于改整张判据表）：

• 两图地平线位置｜ref-c 三区 mean｜下半部仿射参数｜p99.9 与近白占比｜层面积配额

1. 「靶子级」测量在 E0 之前不得单独支撑终局判决；可写为趋势判决（偏高 / 偏低 / 方向反转），不得写为精确倍数判决（见 §19.6 稳定域）。
2. 自我纠错同样需要外部校验：§2.4 所列「被实测推翻的结论」全部出自本端前批结论，属 E1 自纠。每条自纠须附「外部可复核的最小步骤」，否则降级为「待复核」。

本次已执行：§3.1c 的基准链溯源已按本节要求补齐脚本与证据等级，脚本 proto2d/verify_baseline_chain.py（确定性、无随机），输出 assets-520/verify-baseline-chain.json + .log.txt + VERIFY-baseline-chain.png，复核路径见 §3.1e。

---

2. 审计总表：老板 V1.0 规格书 × 既有规范 × 实测证据

审计口径（v3.0c 修订）：E0 实测 > 老板原文 > 既有规范 > E1 本端实测 > E2/E3 推断。

修订说明：v3.0 原文写的是「实测证据 > 老板原文 > 既有规范 > 我的推断」，其中「实测证据」被隐含等同为 E0。但本批全部实测均为本端单方复现（E1），把它排在老板原文之上，等于「用自己的实验推翻老板、再用自己定的规则背书」。现改为：E1 本端实测与老板原文并列，冲突时不自行判决，走 §21 开放问题。（老板原文若被 E1 实测挑战，须在 §21 立 Q，不得在正文直接推翻。）

本节状态：§2.1–§2.4 的条目本身不变，但其「依据」列的等级按 §1.4 重新标注。

2.1 采纳（12 条 · 直接成为 v3 正文）

2.2 修正（8 条 · 采纳其意，改其形）

关于 M1 / M2 / M4 的等级声明（v3.0c）：这三条是用本端 E1 实测去修改老板 V1.0 原文的表述。按 §2 修订后的口径，E1 不得直接推翻老板原文 —— 故这三条定位为「表述修正」而非「结论推翻」：它们没有改变老板的意图，只是把表述精确到可实现的层级（M1：双视点由「核心」变「结果」；M2：粒子由「散点」精确为「线框+稀点光」；M4：弱化的是「Glow 半径」而非「结构亮度」）。若老板认为这三条改动有违本意，请在 §21 立 Q 覆写。

2.3 驳回（2 条）

2.4 既有规范中被实测推翻的结论（必须作废）

本表全部条目均为 E1（本端自纠） —— 即「我推翻我自己前批的结论」。按 §1.4 纪律 4，每条附「外部复核路径」。这些自纠本身不享受 E0 待遇。

---

3. 基准资产裁定（本批最重要的一个决定）

3.1 事实

三者中，老板 V1.0 的文字与自己的参考图（56–58%）自洽；CT-1（68–69%）是内部产物。

两种测量法：行剖面法（找地平线辉光峰值）与梯度法（行均值上升斜率最大处）。两法在两张图上系统性相差约 1–2 个百分点，故每个值给出两法结果。CT-2 取值见 §3.2。

3.1b 两靶的同口径硬对照（1920×969，CT-2 口径）

带区差异是这张表的核心：CT-1 的地平线在 68–69%，所以它的「54–60% 带区」仍然全是暗天空（mean 10.54、仅 7.1% 像素 > 20）。而 ref-c 的地平线在 57–58%，同样的 54–60% 区间已经是真实城市（26.73、54.5% 像素 > 20）。

用 CT-1 当靶子测「带区」，等于拿天空去比城市。

3.1c 变形链溯源：CT-1 是 ref-c 下半部的纵向压缩版（v3.0c 重写 · 已补 falsify 检验）

v3.0c 重写说明：v3.0 原文把「时间戳（16:33 → 16:39，+6 分钟）」当作主要证据。这条证据强度不足 —— 文件 mtime 可被复制 / 导出 / 保存动作改写，它只能证明「同一会话内先后生成」，不能证明发生了「压缩」这个具体变换；而且仿射拟合本身对方向不敏感（无论谁是谁的缩放，都能拟合出高相关）。本节据此重写：以「信息损失不可逆」为主证据，时间戳降为旁证。 全部数据由 proto2d/verify_baseline_chain.py 确定性复算产出。

① 事实一：上半部同源（逐像素）

v3.0 原文记「上半部最大差 = 0」。v3.0c 更正为 ≤ 10 —— 原值系按 5% 间隔抽样测量所致（抽样带恰好避开了那几行），全行扫描后真实上界为 10。在 JPEG 噪声量级内，「同源」结论不变。

② 事实二：下半部呈严格纵向仿射

独立复算（枚举 a∈[0.60,1.60]、b∈[−400,400]，最小化下半部行剖面残差）：

y(ref-c)px = 1.355 × y(CT-1)px − 344        （H = 969，行剖面残差 = 0.7793）
等价：y(ref-c)% = 1.355 × y(CT-1)% − 35.5%
反解：CT-1 下半部 = ref-c 下半部 × 0.7380（压缩到 73.8%）

v3.0 原文记 1.36 / −348、73.5%。v3.0c 复算为 1.355 / −344、73.8% —— 差异来自步长（原步长 0.01，本次 0.005）与插值方式（本次用 np.interp 而非最近邻）。两版结论一致，本版为准。

③ 事实三（新主证据）：信息损失不可逆 ⇒ 方向确定

这是本次补上的、真正能 falsify 反命题的检验。设两个假说：

• H1：CT-1下半部 = 降采样(ref-c下半部, 0.738) —— ref-c 是源，CT-1 丢失细节
• H2：ref-c下半部 = 升采样(CT-1下半部, 1.355) —— CT-1 是源，ref-c 只是被拉大

检验法：把 CT-1 下半块按各标准核放大回 ref-c 几何，看能否复现 ref-c。

5 种标准重采样核里最好的一个，也只能复原 ref-c 的 92.5% 细节。

• 若 H2 成立，则必然存在某个核使放大结果 ≈ ref-c（比值应 ≈ 100%、MAE ≈ 0）—— 实测最高仅 92.5%。
• 且 CT-1 原始下半块的梯度能量（4.226）高于 ref-c（3.934）：这是降采样的典型指纹（特征被压进更少像素 ⇒ 相邻像素差变大）。
• ⇒ H2 被 falsify，H1 是唯一成立的解释：CT-1 下半部 = ref-c 下半部的降采样产物。

④ 事实四（新）：排除「只是重新编码」

若 CT-1 只是 ref-c 的再编码（同尺寸、仅色差），下半部逐像素差应 < 30。实测最大差 243 ⇒ 内容位置已改变 ⇒ 排除纯重编码。（这条同时回应审计意见 1 提出的「可能是导出工具的一次重新编码」假说。）

⑤ 旁证（非主证据）：时间戳与文件指纹

新发现（v3.0c）：ref-c 内嵌的 ICC profile 描述为 sRGB、info 含 Google Inc. 2016 —— 这是 Chromium/Chrome 内嵌的 sRGB profile 指纹 ⇒ ref-c 由 Chromium 系产出（浏览器截图 / 浏览器「另存图像」）。 这意味着 ref-c 的 mtime 记录的是「保存动作」的时间，不是内容生成时间 —— 因此 mtime 单证不足以定方向（审计意见 1 成立）。 方向由 ③ 的信息损失检验确定。

3.1e 复核路径（v3.0c 新增 · 按 §1.4 纪律 1）

同一个脚本还顺带回答了审计意见 2 的两项（ref-c 纯净度、JPEG 量化敏感度），见 §3.1f。

3.1f 靶子纯净度与判据稳定性（v3.0c 新增 · 直接回应审计意见 2）

审计指出两个隐患：(a) ref-c 疑似「画面 + 标注面板」复合 ⇒ 用作亮度基准会被污染；(b) V44/V45 的推导基于对一张 JPEG 的 p99.9 测量 ⇒ JPEG 量化本身会削峰，精确倍数不可靠。两项均已实查。

(a) 拼接缝归属 —— v3.0 原文张冠李戴，已更正

结论：那条「50.9% 拼接缝」属于 SKY-BASELINE-CT1-annotated.png，不属于 ref-c。 该文件是 2580 = 1920（画面）+ 660（标注面板）的横向复合图：列均值在 x=1919→1920 处由 12.83 跳到 60.00（面板左边框），面板底色 9.00–12.30。50.88% 的强行跳变由面板内容在纵向上的起止造成，与画面地平线无关。 历史「地平线 69.76%」正是在这张 2580px 复合图上误测的 —— 这解释了该错误的确切来源。

⇒ v3.0 原 D13「ref-c 在 50.9% 处有拼接缝」为错误归属，已在 §23.3 更正。

(b) ref-c 纯净度四查 —— 全部通过

⇒ ref-c 是单幅画面，不含标注面板 / UI 控件。§19 全部由 ref-c 导出的基准值未被污染，审计意见 2(a) 的风险排除。

(c) JPEG 量化敏感度 —— 结论方向可信，但精确倍数不可写死

把 CT-1（PNG 无损）按各质量重编码后重测：

对 ref-c（本身即 JPEG）重编码：p99.9 落在 164.0–165.67（Δ ≤ 1.34），近白占比 0.0060–0.0074%。

⇒ JPEG 量化对 p99.9 与近白占比的影响仅为「个位数点位」量级，而 480 批与目标的差距是 ~70 点 / ~130 倍量级。判据方向与量级完全可信；但「134 倍」「18.8 倍」这类精确倍数不得写成硬阈值。 §19.4b 的阈值已按此改为稳定域判据（见 §19.6）。

3.1d 这就是「两千次卡住」的真正根因

项目把老板的参考图下半部纵向压缩了 26.2%（压到 73.8%），并把这个压缩版冻结成「CT-1 基线」。此后 440 / 480 / 490 三个批次、数千次迭代，全部在追这个被压缩过的靶子。

⚠️ 两处必须由老板裁决、本端不得自行断定的地方（v3.0c 补）

1. 意图未知：文件本身只能证明「发生了压缩」，不能证明这是有意修改还是无意走样（例如：某个上屏 / 截图 / 导出环节做了纵向适配，而产物被直接归档为基线）。只有老板能回答（§21 Q0）。
2. 若压缩是有意为之，则 CT-1 本身就是「老板要的效果」，全部判据须回 CT-1 口径重算 —— 这是一个会翻转所有数字的岔路，必须以 Q0 为唯一开关。

在 Q0 答复前：§19 全部阈值标记为「临时口径」，不得用于终局判决（详见 §19.6）。

三层错误叠加：

证据图：docs/sky/assets-520/PROOF-ct1-is-compressed-refc.png（含两图城市体等高缩放对照 —— 压缩后两块内容一致）

对照图：docs/sky/assets-520/TARGET-OFFSET-ct1-vs-refc.png（含 CT-2 分区线与实测地平线标注）

3.2 裁定（v3.0c 修订：区分「建表」与「施工」）

候选模板 CT-2：地平线 57 ± 3%（实测两法 56.2% / 58.4%）；分区 天空区 0–54%、带区 54–60%、地貌区 60–100%。

• CT-1 冻结资产保留不动（作为历史基线继续对拍用），但拟不再作为新批次的验收靶子。
• 全部三区量化判据拟按 CT-2 口径重算（已算，见 §19）。

门禁的两道闸（v3.0c 新增，解决原版自相矛盾）

v3.0 原文写「确认前不进入实施阶段」，但同一批又「同批完成」了 S0 回填 —— 而回填确实是实施的第一步。这是自相矛盾，现拆成两道闸：

理由：建表闸的产物是数字与文档，即使 CT-2 被否，也只需重跑一次 probe（§28 已列此回退）；施工闸的产物是画面方向，一旦押错方向就会重演 440–490 那种「数千次迭代全废」。把两道闸分开，才能既不等死、也不押错。

闸 2 的唯一开关是老板的一句话（§21 Q0 与 Q1）。在拿到之前，本端不写任何渲染代码。

3.3 为什么这是本批最重要的发现

前三个独立批次（440 LED 点阵墙 / 480 青色栅栏 / 490 竖柱阵）全部被判定为「不达标」，而判定所用的数字，是拿 CT-1（68–69%） 当靶子算的。真实目标（ref-c，老板参考图）在 56–58%。

靶子偏了约 11 个百分点 ⇒ 所有「超标 / 达标」判决都失去意义。 这是「两千次仍卡住」的第一个根因，与技术能力无关。

而且判决方向是反的。 以 480 批的带区为例：

同一个实测值，换个靶子，从「太亮」变成「太暗」，结论 180° 反转。

这意味着 480 批的修复方向可能一直是错的 —— 当时为「降带区亮度」做的多轮调参（TILE_Z_SCALE / 高度系数 / winGain 收敛），是在把已经偏暗的城市继续压暗，而真实目标是一块更亮、更密、更连续的城市带（ref-c 带区 54.5% 的像素亮度 > 20）。

这与 §2.4 中「样张是暗色剪影」的错误认知互为因果 —— 两者共同构成了 440–490 三批失败的真实原因。

---

4. 视觉北极星（North Star）—— 唯一裁判

让用户站在自己的此时此地，面对宇宙，看见自己的生命节律。

4.1 三条不可让渡的气质判据

4.2 风格关键词（给设计 / 给 AI 的唯一口径）

Cosmic + Human + Reality + Rhythm + Luminous Wireframe + Particle + Minimal + Deep Space + Real-Time Sky + Abstract Geography

中文：宇宙、人在其中、真实世界、生命节律、荧光线稿、粒子、极简、深空、实时星空、抽象地理。

关键词不是 "3D City"。任何以 "3D City" 为目标的实现路径，一律视为方向性错误。

---

5. 分层结构与面积配额

5.1 九层模型（实测口径 · 权威）

样张经多尺度分解后得到 9 个可独立提取的层，层间零依赖。v3 采用此 9 层为实施口径。

5.2 两条由实测得出的配额铁律

铁律一：工程层撑体量，气质层定成败。

① ⑤ ⑦ ⑧ 合计 78.1%，是画面的体量；② ③ ④ ⑥ ⑨ 合计 9.2%，是画面的「气质」。后者任何一个缺失，画面从「作品」退化为「图表」。

前三个批次的全部工作量都投在 78% 的工程层里，那 9.2% 的气质层从未立起来。 这是「两千次仍卡住」的第二个根因。

铁律二：画面真正的构图骨架是第 ⑤ 层「辐射网」，不是城市。

它只占 6.0% 面积，却把月亮、人影、城市、道路全串在一条中轴线上。而且它可以直接由真实路网驱动 —— 这是真实地理数据在整个画面里最优雅的落点：既是构图骨架，又是数据落点，又是鼠标视差的载体。

5.3 分层实现约束

1. 每层独立可开关、独立可调，禁止耦合进一个 3D Scene 后指望相机给出理想构图。
2. 每层只保留一个投影假设（M1）。⑦ 用低视点剪影假设；⑧ 用高视点俯视假设；两者通过带融合拼接，无需「两台相机」这个概念。
3. 层间通过 seam 位置 对齐，seam = 目标地平线（CT-2：56%）。

---

6. 逐层规范

6.1 ① 天空底 · 大气渐变（25.8%）

• 基础接近纯黑，极低亮度蓝黑渐变。
• 禁止明显科幻银河、禁止五颜六色、禁止大面积紫 / 红 / 橙。
• 星云仅作极弱背景存在：blob 数 ≤ 9；alpha 上限 0.15；必须叠分形噪声遮罩（禁 createRadialGradient 直填的硬边贴片感）。

6.2 ② 星野 · 银河雾（1.0%）

保留（驳回 R1 的「完全不要」），但严格限幅：面积 ≤ 1.5%，亮度不超过相邻天空 +8。

6.3 ③ 真实星空 · 星座（2.2%）

数据来源（硬性）：恒星位置必须由 用户位置 + 当前时间 + 天文算法 计算。不是随机撒点，不是背景图，不是 AI 生成。

6.4 ④ 月牙（0.04%）

• 位置由 真实时间 + 用户位置 计算。
• 极其小、极其克制；亮度低于主要视觉元素。
• 唯一允许的暖色焦点（暖色配额见 §8）。
• 480 批状态：缺失，为必须补齐项。

6.5 ⑤ 中轴光柱 + 辐射网（6.0%）← 全图骨架

这是 v3 相对老板 V1.0 的新增层，优先级最高。

6.6 ⑥ 山脉框景 · 左右对称（3.2%）

• 左右两侧形成天然视觉框架，对称性由样张实测确认。
• 由 DEM 高程驱动，程序化生成山脊线（禁 AI 生图）。
• 480 批状态：缺失，为必须补齐项。
• 山体只略高于地平线，主体向下（500 批原型 v4 已验证此参数方向）。

6.7 ⑦ 城市天际线 · 密集塔群（12.7%）

表现优先级（严格按老板 V1.0 §7 权重表）：整体构图 ★5 > 光线氛围 ★5 > 城市轮廓 ★4 > 真实数据 ★4 > 建筑细节 ★2 > 真实 3D ★1。

6.8 ⑧ 俯视城市肌理 · 路网街区（33.6%）

视觉目标：地图 × 星图 × 建筑线稿 × 粒子艺术。不是 Google Maps × 3D 游戏。

像素级事实：样张下半区实测 平均亮度 34.9、p95 = 94.0、亮度 > 20 的像素占 63.6%、最大连续亮块 479,805 px（占下半区 24%）、青蓝像素 96–98%。

即：⑧ 层是「亮而细」，不是「暗而糊」。 480 / 490 批按「暗而糊」做，方向反了（见 §2.4）。

6.9 ⑨ 前景 · 人影与地光（2.8%）

人物是页面的情绪核心，但：

• 不是具体的人、不是真实照片、不是写实 3D 人物 → 是「一个正在面对宇宙的人」。
• 位置：画面底部中央附近；身体不需完整（背影 / 肩 / 头 / 上半身）。
• 表现：半透明深色剪影 + 青蓝色粒子边缘；轮廓不能太亮。
• 暗剪影 + 亮背景：人形是相对更暗的形体，被背后辉光托出。禁止渲染成「一根亮白立柱」（v1 R4 历史事故）。
• 禁止：写实脸 / 衣服细节 / 摄影感 / 超级英雄感 / 游戏角色感。

前景环境代表「人的现实世界」，语义链：宇宙 = 无限；城市 = 现实；人物 = 我；前景 = 我所处的人生环境。表现用几何线条、曲折结构、粒子、微弱荧光、不完整轮廓 —— 形成「复杂、曲折、但仍可向前走」的空间。

---

7. 构图硬指标（CT-2）

7.1 分区（相对画面高度 y%）

7.2 硬指标

🔒 临时口径：本表的「地平线 57±3%」与「城市体纵高 ≥ 40 pt」均由 ref-c 导出，在 §21 Q0/Q1 答复前为临时口径（§19.6）。Q1 若选 (B)，地平线须改回 CT-1 的 68–69%，纵高判据随之作废（CT-1 只有 32.5 pt）。

7.3 地平线辉光规范（视觉锚点）

• 位置：地平线附近，极薄、极柔、低亮度。
• 从中心向两侧逐渐减弱；不形成明显横线。
• 禁止：激光线 / Neon 横线 / 赛博朋克效果 / 强烈 Bloom。
• v2 §3.6 已承认此残留，v3 定为必须解决项。

---

8. 色彩规范

8.1 色板（严格克制）

8.2 硬禁令

暖色禁止大面积使用。 480 批实测暖色 0.008%（月亮缺失），需补齐至设计值但不得超过 0.5%。

---

9. 亮度层级与光效体系（一切参数的推导源）

9.1 层级（L0–L5，继承 v2 / SPEC-v1）

层级判据（A1）：必须一眼读出「星空 > 地貌 > 城市 > 人物 > 细节」五级层次，相邻两级峰值亮度差 ≥ 25%。禁止平铺。

9.2 Glow 规范 —— 本页最容易做坏之处

原则（M4 修正版）：弱的是「Glow 半径与溢散」，不是「结构层亮度」。宁可弱，不要强 —— 但不要因此把结构本身压暗。

核心线
████

第一层 Glow
░░████░░

第二层 Glow
░░░░████░░░░

禁止 ████████████████ —— 一旦出现立即变成赛博朋克 / 游戏 UI / 科幻宣传片。

9.2b 硬指标：禁止近白核（V44 / V45 · 🔒 临时口径）

目标画面在数值上「亮而不爆」：均值高（地貌区 35.27）、尾部低（p99.9 = 164.3），近白 L>200 占比仅 0.0062%。

正确的 Glow 做法：

一句话：靠「面」亮起来，不靠「点」爆出来。

操作禁令（v3.0c 按稳定域修订）：

v3.0c 修订说明：原版写「任何图层不得产生 L > 200 的像素（月亮除外）」—— 这与实测不符（目标 ref-c 自身就有 0.0062% 的 L>200 像素）。禁令的对象不是「>200 的存在」，而是「>200 的规模与形态」 —— 即「少量离散点可以，成片硬核不行」。现按稳定域重写。此数值在 Q0/Q1 答复前为临时口径（§19.6）。

9.3 调参优先级（来自老板 V1.0 §7 权重表）

---

10. 粒子规范

10.1 四类粒子（必须有意义，不能只是撒点）

10.2 行为白名单 / 黑名单

---

11. 动画与交互

11.1 动画速度（整体必须慢）

禁止快速动画。

11.2 鼠标交互（必须非常轻）

核心原则：用户应感觉「这个世界在呼吸」，而不是「我在操作一个 3D 游戏」。

11.3 交互层的技术定位（吸收老板 §4 的 2.5D 主张）

3D 数据源 + 2.5D/2D GPU 合成 + WebGL 交互层

即：数据是 3D 的，合成是 2D 的，交互层挂 WebGL。这样既有视差 / 呼吸 / 响应，又不掉进「真正 3D 城市必须物理正确」的陷阱。

---

12. 硬禁令（合并 v2 红线 + 老板 V1.0 §23）

12.1 视觉层禁止

赛博朋克 · 科幻城市 · 游戏地图 · Google Earth 风格 · 写实 3D 建筑 · 大面积霓虹 · 大量彩色粒子 · 紫红色银河 · 强 Bloom · 机械 HUD · 雷达 · 数据面板 · 科技 UI · 大量文字 · 复杂按钮 · 普通网页渐变背景

12.2 实现层禁止（红线 · 不可触碰）

---

13. 系统架构

13.1 三引擎架构

                      Tempo Soul
                           │
          ┌────────────────┴────────────────┐
          ↓                                 ↓
 Astronomical Engine              Geo-Luminous Engine
 （天文引擎 · 已有）              （地理灵境引擎 · 新建）
          │                                 │
 真实星空 / 月亮 / 星座            城市 / 建筑 / 山河 / 地标
          │                                 │
          └────────────────┬────────────────┘
                           ↓
                    Visual Engine
              （Shader / Particle / 分层合成）
                           ↓
                      合成场景
                           ↓
                    Hero 首屏

引擎间唯一契约：两者各自输出图层，不共享坐标系、不共享相机。Visual Engine 只负责按 §7 分区融合。

13.2 引擎内部数据流

用户位置 + 当前时间
        ↓
真实地理数据（建筑 / 道路 / 河流 / 山脉 / 地标 / 高度）
        ↓
城市高度场 + 矢量数据
        ↓
 ┌──────────────┬──────────────┐
 ↓                              ↓
投影假设 A                    投影假设 B
低视点                        高视点
 ↓                              ↓
⑦ 城市天际线剪影              ⑧ 城市俯视肌理
 ↓                              ↓
 └──────────────┬──────────────┘
                ↓
         GPU 分层合成
                ↓
 ①②③④⑤⑥ + ⑦⑧⑨ + Bloom + 调色
                ↓
          Tempo Soul 首屏

注意：图中「投影假设 A / B」不实现为两个相机对象（M1）。它们是两个独立的图层生成函数，各自只保留一个投影假设。

13.3 技术栈（分阶段）

为什么阶段 0 刻意不用 Three.js（M3）：阶段 0 是纯 2D 图层语法复刻，不需要 3D 引擎。引入它会产生「我该建一个 3D 场景」的本能，而那正是导致 440–490 三批卡死的机制。Python/numpy 也更快 —— 改一行、0.2 秒出图，适合逐层对拍。

---

14. 「数据真实，表现艺术化」的代码约束

原则（老板 V1.0 §18）：允许非线性视觉映射；不能把虚假的建筑说成真实建筑。

14.1 强制字段

每一个图元（建筑 / 道路 / 河流 / 山脊 / 地标）必须携带 source 字段。

{
  "id": "b_1042",
  "kind": "building",
  "source": "osm:way/123456789",     // 真实来源；合成数据则为 "synth:roadside/v1"
  "h_real_m": 60.0,                  // 真实高度（米）—— 永不改写
  "h_visual": 138.0,                 // 视觉高度（单位）—— 可非线性映射
  "lat": 29.7271, "lon": 120.2345,
  "footprint": [[...]],
  "synth": false
}

14.2 三条硬规则

14.3 推荐视觉高度映射

h_visual = clamp( pow(h_real_m, 0.35) * k , h_min , h_max )

• 幂压缩：保留高度排序关系（高的仍更高），同时压缩量级差。
• k / h_min / h_max 为全局常量，写在本文件，改动需记变更记录。
• 禁止：给一栋实测 60m 的楼渲染出数值上等同 300m 楼的高度（那等于伪造城市事实）。允许的是「让 60m 的楼在画面里更有轮廓存在感」—— 即增强轮廓与辉光，不虚构楼体高度数值、数量与位置。

---

15. 数据不足的三级降级（老板 V1.0 §19）

15.1 分级定义

15.2 实测案例（决定此节存在的证据）

诸暨市中心在开放地图上只有 10 栋建筑。中国中小城市的建筑数据基本空白 —— 路有人画，楼没人画。这不是渲染问题，是数据源事实。V1.0 的三级降级不是可选项，是必需品。

15.3 Level 2 的合成纪律

• 合成建筑位置必须锚定真实路网两侧（沿路采样），不得凭空散落。
• 高度按道路等级 + 距中心距离推断，伪随机固定种子可复现。
• 全部打 synth: true 标记。
• 不得对用户宣称这是该城市的真实建筑。

---

16. Geo Tile 资产格式（全球化的实现基础）

16.1 目录约定

/geo/<city-slug>/
  ├── height.bin        高度场（raster）
  ├── buildings.bin     建筑 footprint + height
  ├── roads.bin         路网
  ├── water.bin         水系
  ├── dem.json          地形高程（生成 ⑥ 山脊）
  ├── landmarks.json    地标（⑦ 高亮槽位数据源）
  └── meta.json         { slug, name, lat, lon, radiusM, level, source, built_at }

渲染器完全一样，只更换 Geo Tile。 这是全球化成立的前提 —— 每个城市不再需要「生成一个场景」。

16.2 阶段边界

阶段 0 不生产任何 Geo Tile，不碰全球城市、不碰 GPS、不碰网页。

---

17. 性能预算（v3.0c：标注等级与依据）

本节的数字分两档，不得混用：一档是实测量级（可作判据），一档是估算（E2）（只作设计目标，不作验收判据）。v3.0 原文把二者都写成了硬指标，现更正。

关于「3 秒」的概念纠正：老板 V1.0 提到的「3 秒」混了「拉数据」与「首屏出图」两件事。拉取 + 烘焙留在离线（overpass 拉取可 20 分钟）；首屏只做加载 + 合成。

阶段 2 的强制动作：在真实 GPU 上 profile 首屏，把 E2 估算替换为 E1 实测，再决定 ≤300 ms 能否作为验收判据。在那之前，任何「首屏性能达标」的声明都无效。

17.1 验收显示环境（v3.0c 新增 · 回应审计遗漏项）

审计意见 5 指出：全部亮度测量都在 sRGB 数值域上做，而五问由老板的眼睛裁决 —— 若验收显示器未校准，「亮而不爆」（V44/V45）与「暗剪影」的观感判断可能互相打架。

---

18. 验收判据总则 —— POC 五问（最高优先级）

不再用「代码完成了吗」作为验收。只问下面 5 个问题。

通过条件：① ② ③ ④ = 是，且 ⑤ = 没有。

18.1 判据层级与优先级

当机器数字与人的眼睛冲突时，以眼睛为准。

五问的显示环境要求（v3.0c 新增 · 回应审计遗漏项）：五问由眼睛裁决，故必须同一台显示器 + 同一亮度设置下作答；换设备后需重答。每轮 ROUND 文档须记录「验收设备 / 亮度 / 是否夜间模式」。详见 §17.1。

冲突处理：若数值判据（P1）与眼睛（P0）冲突 —— 按本节以眼睛为准，但必须把冲突写进 ROUND 文档，不得静默忽略（这是 440 事故「用失敏指标自我打勾」的制度性防范）。

18.2 机器判据的三条使用纪律（吸取 440/480 教训）

1. 不得自我打勾：任一口径被推翻后，必须换口径重测，不得沿用旧数字。
2. 不得用失敏指标：「分区均亮」已被批判为失敏指标（440 就是被它判成达标的）。
3. 迭代必须给人看：每完成一层 / 一轮，必须出图给需求方看，由他说行不行 —— 不得靠数字自我判定「在进步」。（440 与 480 两次事故的共同形态：8 轮迭代一次都没出图给人看。）

---

19. 量化判据（CT-2 口径）

⚠️ 全部阈值为「临时口径」—— 不得用于终局判决

本节所有由 ref-c 导出的基准值（V41–V48 的阈值列）成立于「CT-2 取代 CT-1」这一裁定之上，而该裁定尚未获老板确认（§21 Q0 / Q1）。 因此：

允许	禁止
报趋势判决：偏高 / 偏低 / 方向反转	报终局判决：「达标」「不达标」
用作迭代时的相对刻度（这版比上版更接近目标）	用作放行依据（据此宣布某批通过验收）
在 Q1 答复后一键转正	在 Q0/Q1 悬空时对外声称「按规格书达标」

转正条件：§21 Q0 与 Q1 答复 + §3.1e 的复核路径被执行（E1 → E0）。

一键回退：若 Q1 选 (B)（仍以 CT-1 为准），本节全部数字作废，重跑 probe 即可（工作量：1 个脚本 + 本节表格）。

19.1 分区口径变更

19.2 参考值对照表（本批实测，单一方法学）

方法学：全部图像统一 resize 到 1920×969；L = RGB 均值；亮度阈值为 L 值。口径一旦固定不得混用（§18.2 纪律一）。

基准纯净度：ref-c 已做四项纯净度检查（边带 / 游程 / 边角 / 元数据），确认不含面板或 UI，数值未经污染 —— 详见 §3.1f(b)。

基准抗噪性：ref-c 为 JPEG，已实测量化敏感度：p99.9 在 q=50–95 区间波动 ≤ 1.34，基准值抗 JPEG 噪声 —— 详见 §3.1f(c)。

等级：全部为 E1（本端单方复现），脚本 verify_baseline_chain.py / zone_probe_ct2.py / target_offset.py。

数值来源（v3.0c 校准）：p99.9 与近白占比取 verify_baseline_chain.py §E 的确定性复算值（ref-c p99.9=164.33 / 近白 0.0062%；CT-1 p99.9=163.00 / 近白 0.0073%）。v3.0 原文记 «164.3 / 0.006%» 与 «163.0 / 0.007%»，结论一致，小数位以本节为准。

两个新发现（本批首次量化）

发现一（带区方向反了）：480 批实测带区 20.77，对 CT-1（10.54）判「超标 +74.7%」，对 ref-c（26.73）应判「偏低 −22.3%」。同一数值，结论 180° 反转（详见 §3.3）。

发现二（硬高光核）：目标图（CT-1 与 ref-c）几乎没有近白像素 —— >200 占比仅 0.006–0.007%，p99.9 ≈ 163。而 480 批 >200 占比 0.940%、p99.9 = 235。

这说明目标画面的城市是「亮而不爆」：均值高（35.27）、尾部低（p99.9 164）。480 批做成了相反的形态 —— 均值偏低（28.60）但尾部极高（235），即「大面积偏暗 + 少量爆亮硬核」。

这直接定义了 Glow 的正确做法：靠「面」亮起来（大范围中亮度的连续结构），不是靠「点」爆出来（少数饱和硬核）。 这条同时修正了 §9.2 —— 不只是「降 Glow 亮度」，而是禁止出现近白核。

抗噪性声明（v3.0c 补，回应审计意见 2(b)）：审计质疑「对一张 JPEG 测 p99.9，JPEG 会削峰 ⇒ 精确倍数不可靠」。已实查并结论如下：把 CT-1 按 JPEG q=50–95 重编码，p99.9 波动仅 163.0–163.67（Δ ≤ 0.67），近白占比波动 0.0071–0.0082%（≤ 1.12×）；ref-c 自身重编码波动 ≤ 1.34。⇒ 编解码器噪声为「个位点数」量级，而 480 批与目标的差距是 ~70 点 / 两个数量级 ⇒ 判据方向与量级不受 JPEG 影响。

但审计是对的：不得把「134 倍」这类精确倍数写进硬阈值。 §19.4b 已据此改为稳定域判据（见 §19.6）。

19.3 逐层量化判据（V32–V40 · 新增）

19.4 三区数值判据（V41–V43 · 按 CT-2 口径重算 · 🔒 临时口径）

判据列已改名为「趋势判决」 —— 在 §21 Q0/Q1 答复前，不允许出「达标 / 不达标」的终局判决（见 §19.6 规则 1）。

V42 是「靶子偏了 ⇒ 结论反转」的直接体现：同一实测值 20.77，对旧靶（10.54）判「超标 +74.7%」，对新靶（26.73）判「偏低 −22.3%」。

容差 ±12% / ±15% 的依据：E3 经验值（本端设定，非从数据推出） —— 阶段 0 期间须用真实样本方差校准，见 §19.6 残余风险 3。

19.4b 尾部判据（V44–V45 · 本批新增 · 稳定域版本）

依据 §19.2 发现二：目标画面没有近白像素，城市是「亮而不爆」。

v3.0c 修订：原版阈值 ≤ 180 / ≤ 0.05% 建立在单点测量 + 「134 倍 / 18.8 倍」的精确倍数论证上。审计指出 JPEG 量化会削峰 ⇒ 精确倍数不可靠。现改为稳定域判据 —— 阈值与目标值的余量放宽到编解码噪声的 10 倍以上，结论不再依赖精确倍数。

稳定域阈值的设计逻辑（重要）：V45 阈值 0.06% 与目标 0.0062% 之间留了 ~10 倍余量，而实测编解码噪声的最大漂移仅 1.12 倍。⇒ 阈值比噪声宽一个数量级，结论不依赖「精确倍数」这种脆弱论证。 480 批的 0.940% 即便打满噪声折扣，仍是阈值的 ~15 倍以上。结论稳健，但表述必须用「两个数量级」，不写「150 倍」这类精确倍数。

V44/V45 的操作含义：禁止出现近白硬核。 城市层要「整体提亮 + 消除爆点」，即把能量从「少数饱和像素」重新分配到「大范围中亮度连续结构」。

这是 480 批「竖柱阵」在数值上的真面目 —— 柱阵不是"太亮"，是能量分布形态错误（尖峰而非平台）。

19.5 状态标记（v3.0c 改版）

一句话：临时口径期内，本节的任何标记只是迭代刻度，不是验收结论。

19.6 临时口径与稳定域（v3.0c 新增 · 直接回应审计核心意见）

审计原文：「这份文档最大的优点是『用证据推翻自己』，最大的隐患是 —— 它正在用同样自信的口吻，把一批尚未经老板确认（Q0/Q1）的数字写成硬判据。CT-1 的教训是『靶子被悄悄改了』；下一个教训可能就是『新靶子未经确认就被当成了铁律』。」

本节即为堵此漏洞而设。 三条硬规则：

残余风险（诚实列出，不掩饰）：

---

20. 门禁与对拍流程

20.1 对拍基准

• 新靶（拟）：docs/design/redraw-20260914/_refs/ref-c-老板参考构图.jpg（1920×969）— 🔒 待 §21 Q1 转正
• 历史对照：docs/design/baseline/ CT-1 冻结资产（保留，不覆盖，仅作历史对照）
• 拟禁止：用 CT-1 作为新批次的通过 / 不通过判据（§3.2；若 Q1 选 (B) 则此条作废）
• 永久禁止（v3.0c 新增）：SKY-BASELINE-CT1-annotated.png 及任何复合 / 标注图进入 probe 脚本或任何测量管线（§12.2）。 该类文件只允许人工阅读。
• 基准图只读：任何工具、脚本、导出流程不得覆盖 docs/design/ 下的基准资产。每次使用前可用 §3.1e 的脚本核一次尺寸与行跳变，确认未被改写。

基准健康检查（v3.0c 新增，每次开批前 30 秒可跑）：三张图的 (尺寸, 最大行跳变) 应为

ref-c: 1920×969 / 7.11、CT-1: 1920×969 / 7.98、CT-1-annotated: 2580×969 / 100.97。

任一项不符 ⇒ 基准已被改写 ⇒ 立即停批、重跑 §3.1e 脚本、按 §28「基准资产被再次改写」处置。

20.2 每轮出图纪律（强制）

改一层 → 出图 → 给需求方看 → 记「是/否」 → 下一层

1. 每轮产出物：<layer>-v<n>.png + 与 ref-c 的同尺寸叠放对照图。
2. 每轮必须在报告中回答 五问，不得只报数字。
3. 跨批交付物：docs/sky/ROUND-YYYYMMDD-<批号>-<主题>.md + 同内容深色 HTML。

20.3 部署门禁

---

21. 开放问题（待老板拍板）

门禁提示：Q0 与 Q1 是 §3.2「施工闸」的唯一开关。在二者有明确答复前，本端不写任何渲染代码。（纪律来源：480 批「需求裁决悬空时自行默认选路」的教训。）

---

22. 变更记录

---

23. 执行计划 · 困难清单

先摆困难，再谈路径。以下每条都有实测依据，不是预判。

23.1 一级困难（会导致路线失效，必须先解）

23.2 二级困难（拖慢但不致命）

23.3 认知类困难（最容易被忽略）

---

24. 阶段划分与总路线

阶段 0  语法复刻（不碰数据、不碰网页、不碰 GPS）
   ↓    目标：稳定复刻视觉语言，五问通过
阶段 1  真实数据映射（只接一个城市：真实建筑 → 高度场 → ⑦⑧）
   ↓    目标：数据进来后视觉语言不塌
阶段 2  工程化（WebGL/Three.js 重写 + GPU 合成 + 交互 + 性能）
   ↓    目标：60 FPS、≤300ms 首屏、可交前端
阶段 3  全球化（Geo Tile 生产流水线 + 多城市）

24.1 为什么阶段 0 必须「不碰数据」

因为一旦同时引入「数据」和「语法」两个变量，失败时就无法判断是语法错了还是数据错了。 490 批同时背真实数据 + 语法探索，结果在「数据稀疏」与「形态不对」之间反复纠结 —— 这是双变量陷阱。

阶段 0 的产物是一块纯语法样张（不含任何地理信息），它必须先独立通过五问。

24.2 阶段路线对照（老板 V1.0 §26 三天口径）

工期是叙述性的，不是承诺 —— 只作为收敛刻度。验收按五问，按层，不按时间。

---

25. 阶段 0 详细计划（下一步实际动作）

25.1 工作环境（全部在沙箱，不碰 worktree）

阶段 0 不使用 Three.js / WebGL / 任何 3D 引擎（M3）。理由见 §13.3。

25.2 执行步骤（每步一图一验收）

每完成 S1–S11 任一步，立即出图 + 报五问。老板说不行就停在那一步改，不往下走。

25.3 阶段 0 通过条件

五问：① 是 ② 是 ③ 是（此处指「有城市感」，阶段 0 无真实数据，判据放宽为「抽象城市是否成立」）④ 是 ⑤ 没有。

全过 → 进阶段 1（换真实数据）。任一不过 → 停，回报，等指令。

---

26. 阶段 1 计划（真实数据映射）

只做一个城市：台北 101 × 3 km（不东京、不纽约、不全球）。

为什么选台北 101：项目已有台北数据与 Geo Tile 资产（taipei101-{L0,L1,L2,dem}.json），无需新拉数据；且 101 是「超出天际线一个量级」的地标样板，最能验证地标槽位。

26.1 阶段 0 → 阶段 1 的量化回归闸（v3.0c 新增 · 回应审计意见 4）

审计原文：「§25 的 layer-NN 逐层产物与 §26 阶段 1 的 Geo Tile 格式之间缺少对拍方案 —— 阶段 1『数据进来后视觉语言不塌』的验收标准只有一句五问，没有量化回归。这是下一个『方向漂移』最可能发生的位置。」

本节即为补此缺口。 五问回答「像不像」，量化回归回答「有没有在换数据时把已经对好的东西弄坏」。

执行纪律：

1. 本闸只比「阶段 1 vs 阶段 0」，不与 ref-c 比绝对值 —— 因为阶段 0 已经过了五问，它是「已知合格」的内部参照。这样可把「换数据导致的语言漂移」与「阶段 0 本身就还差的差距」分开。
2. 任一 G 判据超差 ⇒ 不追加新功能，先定位是哪一层的哪一步引入的（逐层比对 layer-NN 前后）。
3. G1–G6 全部通过 + 五问全过，才允许进阶段 2。 只过五问而 G 超差 ⇒ 视为「偶然像」，必须回退查因。

---

27. 阶段 2 计划（工程化）

---

28. 风险与回退

任何阶段的主仓改动：默认零。需改动前先出清单 + 备份 + 二次确认。

---

29. 下一步实际动作（等老板一句话）

在 Q0 / Q1 / Q2 有明确答复前，我不动手写任何渲染代码。（纪律来源：需求裁决悬空时不得自行默认选路 —— 480 批的教训。）

本批（520-C）已做的，全部落在「闸 1（建表闸）」之内：重测、复核、修订文档、补证据脚本。一行渲染代码都没有写。

---