1. 本册用途#
这一册管什么：统一天气系统的必要性、天气类型、影响链路（施工窗口 / 能耗 / 客流）、生成与确定性、玩家可见性。
这一册不管什么：具体城市的季节曲线（见 CITY-02~05）；极端环境的结构性约束（台风对海上结构与海岛、极寒对施工窗口）——那分别属于 EXP-09（海况）与 EXP-07（极地施工窗口）。
2. 档期与优先级#
| 项目 | 内容 |
|---|---|
| 档期 | P1 |
| 被谁依赖 | TRANS-01~04 · SYS-07 · EXP-09/07 |
| 上游依据 | 既有分册迁入 |
本文定位：本文是《SKYLINE CHRONICLE》文档体系的独立分册。主文档（《完整设计方案 v1.21》《城市与地区设计规格 v3.10》《技术架构文档 v1.11》《战役剧情与章表 v3.2》《主菜单与首屏 UI 规格 v1.1》）中只保留指示与描述，完整规则以本文为准。若主文档与本文冲突，以本文为准。
3. 规格与清单#
本册的核心玩法规则。原分册的机制部分全部迁入本节。
定位与档期#
| 项 | 内容 |
|---|---|
| 性质 | 全局统一天气系统。新增（D5 裁决），不属于任何单个系统域。 |
| 档期 | P1（首发）。 |
| 层 | Kernel 层全局单例 WeatherService——不依赖城市 / 楼栋实体而存在 |
| 一句话 | 天气不是装饰，是三条链路的共同输入：施工窗口、能耗、客流。此前这三条各自解释天气，口径不一；v1.0 收斂为一个全局系统。 |
为什么需要一个统一天气系统#
v1.21 之前，天气在文档里出现过 三处，且互不相干：
① S7 机电系统故障表里：「极端天气（暴雨 / 高温 / 寒潮）考验系统」；
② S13 昼夜与季节表里：「天气（雨 / 雪 / 高温 / 雾霾）」作为一行列举；
③ 各远期系统里：铁路的施工窗口、旅游的客流、航空的延误，各自假定「天气会影响我」。
三处没有共同的真值源——施工窗口说今天能干，旅游客流却按暴雨算，就会出现「暴雪天还在正常打混凝土」这类不自洽。统一天气系统就是为了消灭这类不自洽。
天气类型#
| 天气 | 施工窗口 | 能耗 | 客流 | 备注 |
|---|---|---|---|---|
| 晴 | 1.00（正常） | 1.00 | 1.00 | 基准态。多数日子的样子 |
| 雨 | 0.75 | 1.05（照明 + 抽水） | 0.80 | 室外业态与观光直接受损 |
| 暴雨 | 0.20 | 1.15 | 0.45 | 土方与混凝土作业基本停摆；航班取消概率显著上升 |
| 雪 | 0.60 | 1.35（供暖） | 0.70 | 北方城市与高纬度城市的常见态 |
| 暴雪 | 0.10 | 1.60 | 0.40 | 极端态。铁路班次削减、航班取消、施工全面停工 |
| 高温 | 0.85（限工时） | 1.45（制冷） | 0.85 | 南方城市与沙漠城市（迪拜）常见；机电故障率上升 |
| 寒潮 | 0.70 | 1.55 | 0.65 | 供暖峰值；管道冻裂风险 |
| 大风 | 0.35（吊装停工） | 1.00 | 0.75 | 高层施工的专属克星——塔吊停摆与楼层高度强相关 |
| 雾霾 | 0.90 | 1.00 | 0.55 | 景观类业态（观景台、观光线路）受损最重 |
| 台风 / 飓风 | 0.00 | 1.30 | 0.20 | 极端事件。低频、高冲击；沿海城市专属 |
系数为乘性修正，基准 1.00。大风是本作特有的关键天气——它直接打击「把楼盖高」这一核心行为，是天气系统与主线张力最强的一处接口。
影响链路#
┌─────────────────────────┐
│ WeatherService (Kernel) │
│ 当日天气态 + 次日预报 │
└───────────┬─────────────┘
│ 三个只读系数
┌────────────────────┼────────────────────┐
▼ ▼ ▼
construction_window energy_factor traffic_factor
（施工窗口） （能耗） （客流）
│ │ │
┌──────┴──────┐ │ ┌───────┴───────┐
▼ ▼ ▼ ▼ ▼
地基施工 楼层施工 机电 OPEX 商业客流 旅游 / 航空
进度打折 进度打折 按日放大 按日削减 班次取消风险
| 系数 | 作用对象 | 具体规则 |
|---|---|---|
| construction_window | 地基施工、楼层施工、铁路铺设、机场扩建 | 当日可施工时长按比例折算。不是「停工或不停工」的二值开关，而是「今天能干几小时」——因此工期会平滑延长，而不是卡死 |
| energy_factor | 机电 OPEX、供暖、制冷 | 按日放大当日的能耗支出。只影响钱，不影响实体状态——不引入新的损坏机制 |
| traffic_factor | 商业客流、旅游客流、铁路班次、航空准点 | 按日削减当日客流。航空额外按天气类型计算取消概率 |
天气不改变任何资产的存量状态——它不会让楼掉耐久、不会让租户跑掉、不会让产线损坏。它只改变当日的流量（能干多少活、花多少钱、来多少人）。这条约束很重要：一旦天气能造成永久损伤，玩家就会因为随机事件而愤怒，而本作的挫败感应该来自玩家自己的决策，不是随机数。
生成与确定性#
| 项 | 规则 |
|---|---|
| 生成方式 | 由 存档种子 + 游戏内日期确定性推导。同一存档 + 同一天 = 同一天气，可复现 |
| 存档只存种子 | 天气序列不进存档，只存种子。这让存档体积不随游戏时长增长（架构 D-14 边界⑤） |
| 地域差异 | 天气概率分布按城市而异：迪拜多高温、少雨雪；高纬度城市多雪、施工窗口本就窄；新加坡多雨。这让「换城市 = 换玩法」在天气维度上也成立 |
| 季节调制 | 在城市的基准分布上叠加季节调制。冬季寒潮概率上升、夏季高温概率上升 |
| 极端事件 | 台风 / 飓风为低频事件，仅沿海城市可能触发，且有预报（提前 2–3 天可见）——给玩家止损窗口 |
玩家可见性#
| 界面 | 内容 |
|---|---|
| 剖面视图顶部 | 一行天气指示（图标 + 文字），显示当日天气 |
| 悬停 / 点击 | 展开当日三个系数的具体数值（施工窗口 ×0.35 等），让玩家知道代价 |
| 次日预报 | 显示明日天气与预报置信度。只到次日，不做一周预报 |
| 极端事件预警 | 台风 / 飓风提前 2–3 天弹出预警，允许玩家调整施工计划 |
| 设置开关 | 可整体关闭天气系统。关闭时三个系数恒为 1.00，零开销（架构 D-14 边界④） |
4. 数据字段#
本册的数据结构与字段说明。
数据字段#
weather_type id, name, icon, construction_window, energy_factor, traffic_factor is_extreme, cancel_probability(航空), valid_climates[] city_climate city_id, climate_band(热带/温带/寒带/沙漠/极地) monthly_weights[12][weather_type_id → 权重] extreme_event_types[], extreme_event_base_rate （天气序列不进存档；由 save_seed + date 确定性推导）
5. 边界与不做的#
不做逐小时的天气流体模拟；不做气候变化的长线推演；不做区域性微气候（本作的天气是城市级的一个全局量）
完整的「不管什么」见第 1 节；相邻系统的职责划分见第 7 节。 本节是防止分册无边界膨胀的关键——任何新需求如果落在这三条里，一律拒绝。
6. 相邻系统接口#
与哪些册交互、以什么方式、谁向谁提供数据。
架构位置#
| 项 | 规则 |
|---|---|
| 层 | Kernel 层全局单例 WeatherService，不依赖城市 / 楼栋实体 |
| 接口 | 只提供一个查询接口：get_weather(city_id, date) → 当日天气态 + 三个系数 |
| 不进实体模型 | 天气不是实体、不进对象池、不参与序列化。它没有身份，只有数值 |
| 可整体关闭 | 关闭时返回全 1.0 系数，零开销 |
| 存档 | 只存种子，不存天气序列 |
与主文档的接口#
| 本文内容 | 主文档依据 |
|---|---|
| 新增统一天气系统 | v1.21 审查裁决 D5；《完整设计方案 v1.21》S13-pre 索引节 |
| Kernel 层全局单例、可关闭、零开销 | 《技术架构文档 v1.11》D-14；§21 远期系统边界 |
| 机电故障表中的极端天气 | 《完整设计方案 v1.21》S7（原有表述保留，真值源改为本文） |
| 天气对施工窗口的影响 | 《铁路与线路规划规格 v1.0》§8 |
| 天气对客流与航班的影响 | 《旅游公司规格 v1.0》§6、《航空公司规格 v1.0》§7–8 |
本文由 v3.10 / v1.21 一轮审查中「新增统一天气系统（D5）」的裁决产生。此前不存在这一系统——天气只在三处文档里以一句话的形式散落出现。本文第一次把天气定义为一个真实的系统，并划清了它与施工、能耗、客流三条链路的接口，以及它明确不做的六件事。