面向京津冀徒步者的山野天气，只为让每一次出发更安心

离开 WPS 圈之后，我把脚步交给了山野。徒步圈里，认识了一群同路人，参加了许多山野活动，每周都在城市与山野之间往返。走过的地方多了，每周遇见的事也多了：天雷滚滚压顶而来，不幸被雷击中、意外滑落坠崖，上强度猝然离世……这一路的风景与生死，都沉淀成了我的一部分。

徒步者最在意的是山野的天气变化。但眼下还没有一个无广告、友好且好用的天气查询入口——要么加载时夹杂广告，要么需要来回切换搜索，信息准确性难辨，体验不够好。

基于这个初衷，于是我想用WPS灵犀做一个"山野天气"：按海拔预报，覆盖京津冀的大小徒步，数据实时更新，能用手机随时打开。在2个月前依托灵犀测试版消耗2万+灵点的多次打磨后完成了300+京津冀野路线的实时天气！

1.1入场动画（化繁为简）

起初动画我觉得需要很高级，在耗费了上千灵点后，发现还是简洁的更容易成功，难点在于AI绘画太抽象了。我想要的日升日落、爬山上山下山、日照金山的加载动画。。。均失败了！

1.2首页设计（定位北京）

山野天气的首页，从打开到完成一次查询，只做了三件事：看一眼、点一下、答案出来。

打开应用，深绿色山峰图标配上"山野天气"与英文标识 SUMMIT WX，极简克制，一看就知道是给户外人做的工具。

往下是整页的核心：搜索区。一个放大镜搜索框，输入京津冀的徒步线路名即可查询；旁边并列着"坐标查询"按钮，不知道地名时，直接输入经纬度也能定位任意地点；最右侧的深绿色"查天气"按钮，是整页唯一的行动出口。三个控件各司其职，路线名、山名、坐标，三种查询方式全部兜住。

搜索区下方，是北京实时天气卡片："北京 阴"，右侧大字显示当前温度 28.3°，卡片底部用细线分隔出体感 28.3°、湿度 48%、风 3.9 m/s 三项参数。天气信息被压缩在一张小卡片里，抬眼就能读完——这正是给徒步者的设计：出发前瞄一眼，比什么都快。

页面底部是功能说明区：标题"探索山野天气"，一句话讲清产品定位——"输入京津冀徒步线路名，即可查看实时山地天气与出行建议"；紧接着补充搜索规则："支持模糊搜索，如输入「地名」或「山名」可分别查询；也可用坐标查询指定任意地点"。

最后一行是免责声明："户外活动有风险，本页信息仅供出行参考。"

整个页面没有多余的弹窗、广告和花哨装饰，浅蓝渐变背景干净通透，从查询入口到天气结果再到功能说明，纵向一条线走到底。设计上最大的克制，在出发前 30 秒内完成所有操作。

1.3.东灵山实测（雷罚之地）

实时气象总览：一页读完"此刻的山"

搜"东灵山"，结果页顶部直接亮出这座山：2303m · 40.031°N, 115.460°E · 北京之巅 · 高山草甸 · 大风，海拔、坐标、地貌特征、气候标签一次给全，旁边是收藏按钮。

核心区是实时实况：带雨点的云图标下，当前气温 8.9°，天气"毛毛雨"——紧跟着一行红色提醒："距日落 1.7 小时，留意返程时间"。徒步者最怕的不是雨，是摸黑下山。

往下是四个实时指标：体感 7.2°、湿度 85%、北风 1.5 m/s、阵风 5.6 m/s——体感与气温分开报、阵风与均风分开报，这正是户外场景需要的颗粒度。

再往下是分海拔温度：山脚 15.4° → 山腰 12.2° → 山顶 8.9°。同一个东灵山，三个维度，徒步者可以根据自己的路线和爬升计划，对号入座。

页面中部嵌入一张地形图，标注东灵山的位置，周边灵山名胜风景区、黄草梁风景区一目了然——出发前先看地形，是刻进每个户外人习惯里的动作。

底部"山地指标"板块，九项数据把细节拉满：能见度 4.3km、云量 100%、降水 0.1mm/h、风寒体感 8.3℃、日出 05:51、日落 18:41、降水概率 100%、温差 8℃、紫外线 5。山里的紫外线、温差、风寒，每一项都是城市天气 App 不报、但山里真要命的东西。

风险预报与出行建议：把"该不该去"和"怎么去"讲清楚

顶部是"山地风险"板块：橙色"降雨"标签，配一句人话——"今日累计降水 6.2 mm。岩石湿滑，穿防滑大齿登山鞋，下降段抓实再迈"。不只是告诉你"会下雨"，而是告诉你下雨意味着什么、该怎么办。

中间是"今明后"逐时段预报：从 09/07 16:00 到 09/08 07:00，气温从 10° 一路降到 3°，降水概率从 83% 升至 100%，阵风在 5~8 m/s 间波动——出发前最关心的"今晚冷不冷、明早雨大不大"，扫一眼表格就有数。

底部"户外建议"板块给出五条具体指引：从穿搭、到天气观察、到出发准备——五条提示全是可执行的行动。

页尾一行数据说明很见态度："数据基于数值气象模型并按海拔修正，山地小气候如局地谷风、背风坡增温可能有偏差，最终以现场判断为准。"

2.数据从哪来（全部内联）

选择了两个完全免费、无需 API Key 的开源气象数据服务，并做了自动切换：

Open-Meteo（主数据源）：全球格点气象模型，支持按经纬度 + 海拔查询逐小时预报，精度覆盖到山野完全没有问题；

MET Norway（备用数据源）：挪威气象局的开放接口，当主源超时或失败时自动接管，保证关键时刻不断档。

免费、稳定、无需注册。对一个小工具而言，数据源不该成为门槛——谁也不想在凌晨四点的山脚下，发现 API Key 过期了。

JavaScript、CSS、地图引擎（Leaflet）全部内联，不依赖任何外部 CDN。这意味着它可以被部署到任何静态托管服务上，打开即用，断网时连部署都不会失败。

3.300+条路线（地名学问）

以北京徒步圈公认的路线清单为底，逐条比对、逐条补录，一轮轮扩充下来，路线库从最初的几十条，一路增长到 335 条——珍珠湖、百里山水画廊、三皇山、金海湖、老掌沟……京津冀的经典与小众，几乎囊括的全部能去的。

补路线容易，难的是地名学。北京的山，一个地方常常有好几个叫法，而且徒步圈、地图软件、官方地名各说各话：

大海陀＝大海坨山脊线；海陀山＝海坨山；小海陀＝小海坨；水长城＝黄花城水长城；小三峡珍珠湖＝珍珠湖；蟠龙山长城＝蟠龙山；南北梯＝圣水峪北梯南梯；香巴拉穿越＝香山；栖隐寺＝仰山栖隐寺……

为此建立了一张异名映射表（ALIAS）：无论输入哪个叫法，都能正确落到同一条路线。

例如：灵山和东灵山则更有意思——它们被很多人当成同一座山，但实际上，灵山是灵山，东灵山是东灵山，聚灵峡灵山古道和东灵山主峰是两个不同的目的地。在路线库里把两者拆成独立条目，搜索时各自精准命中，互不粘连。

4.输入 A 就出 A（精准触达）

路线库大了，搜索就成了最较劲的地方。

最初的搜索是"前缀匹配"，搜"后河"会命中"后河峡谷"；搜"武当山"会先蹦出"古武当山"。

问题在于：展示名和内部标识混在了一起，模糊命中时展示的是路线全称，看到的永远是"粘连"的名字。

重构了整条搜索链路，最终演进出六层匹配：

1. 精确匹配：输入的名与路线名完全一致，直接命中；

2. 常用名匹配：KNOWN 表兜住口语化简称；

3. 异名映射：查 ALIAS 表，海陀山 → 海坨山；

4. 前缀匹配：按输入前缀过滤；

5. 包含匹配兜底：输入"三峰"，包含匹配到"大觉寺三峰"——≥2 字时启用，单条直接出结果，多条弹候选；

6. 地理编码：以上都不中，调用坐标解析，支持任意地点的坐标查询。

最关键的一处修改：展示名与内部标识彻底分离。模糊命中时，界面上显示的是用户输入的那个词（输入 A 就出 A），但内部用路线真实名称去取数、去收藏。这样既满足了"所见即所得"，又保证了收藏链路不串线。

5.视觉的较真（华而不实）

早期版本是深色科技主题——深沉的夜空背景、发光的山峰插画，看起来很酷。但真实使用场景是：徒步者在白天、强光下掏出手机。深色背景在阳光下根本看不清。

看着深色界面摇了摇头："风格不搭。"砍掉重来，彻底转向浅色极简系统：素雅底色、克制的强调色、尽可能少的装饰。

插画也经历了几轮打磨。最初的山峰插画是水彩云海风格，“让它动起来"——给画面加了 30 秒的缓慢推进（Ken Burns 效果）、云朵横向飘动、晨雾流动、太阳呼吸缩放，一整幅静态插画变成了活的山野晨景。

经历了多轮尝试和内耗全部重推（看着灵点只剩不到1万）决定"素雅化"：降饱和、提亮、降对比，让插画与浅色界面真正贴合。

6.把一张地图搬进来（位置可视）

我选用了 Leaflet——轻量、开源、可完全本地化。但国内网络环境下，地形瓦片服务的选择是门学问：主流的公共瓦片源在国内时常加载失败，页面会卡在一片空白。

最终做了三级瓦片源轮换：高德地形图（国内必达）为首选，加载失败自动切换 Esri World Topo，再失败切换 OpenTopoMap。

另一个"看不见"的工程是单文件化：Leaflet 的 JS 和 CSS 合计数百 KB，如果从 CDN 加载，一旦 CDN 被墙或抖动，整个地图模块就废了。

我干脆把 Leaflet 完整内联进 HTML——代价是文件变大，换来的是首屏 0.25 秒、永不依赖外部服务。地图标记也用纯 CSS 的 div 图标替代图片资源，做到真正的零外部依赖。

7.线上网页部署（多次上网）

从本地文件到公网链接，"山野天气"的部署其实走了一条极简的路：产品最终打包成一个自包含的 HTML 文件——JS、CSS、地图引擎全内联在里面，不依赖任何外部 CDN。不需要服务器、不需要数据库、不需要配置环境，一个文件就是整个产品。

部署流程是这样的：

1.部署目录- 把构建好的 index.html（连同引导页用到的插画素材）单独放进一个 deploy 目录，不掺任何开发文件——保证发上去的就是产品本身。

2.部署登录-托管服务用的是 Surge，命令行工具通过 npm 全局安装，登录一次之后，发布就是一条命令的事。

这个环节有个反复踩的坑：开发环境每被重置一次，登录会话就失效，得重新安装工具、重建登录脚本、重新认证，才能再次发布。

3.公网发布- 一条 surge 命令，把 deploy 目录推上去，几秒钟后返回发布成功的链接——应用就被"搬"到了公网服务器上，任何人打开链接都能访问。

4.上线验证-每次都会立刻做三件事：用 curl 请求线上地址确认返回 200；拉取线上文件比对本地版本号，确认部署的是最新版而不是旧缓存；再在浏览器里打开，逐项点一遍关键功能（搜索、天气、地形图），确认一切真的在线上生效，才跟用户说"可以了"。

流水线：本地开发 → 单文件打包 → 目录部署 → 链接发布 → 线上冒烟验证。

8.那些踩过的坑（吞吃灵点）

• 环境说没就没-开发环境数次被重置，部署工具（Surge CLI、登录会话）随之丢失，每次都得从装 npm 包、重建登录脚本开始。痛定思痛，把部署流程脚本化，把"重来一遍"的时间从一小时压到三分钟。

• 服务器全站宕机-线上站点突然全线 000——托管服务商故障，应用打不开了。紧急尝试迁移：Cloudflare Pages 注册被验证卡住，Netlify 上传后返回 401 私有……折腾一圈后，原服务恢复，第一时间重新部署并验证了线上版本，同时把"多平台备份"列进了长期计划。

• 一个诡异的 null-搜索候选弹窗有时点击后直接报错——原因是关闭弹窗的代码执行早于读取候选数据的代码，弹窗一关，数据引用就变成了 null。调整执行顺序后，这个只在特定操作路径下出现的 bug 才彻底消失。

• 消失的灵点-任务频繁答非所问，指路为马，灵点扣了，任务没完成，反复的重新跑流程，跑到无奈去pua就正确了，常常一个问题，需要5遍以上才能跑通。灵犀小队长主动给我补了 2000 灵点。说实话，这事有点出乎意料——它悄悄把我对 WPS 的"刻板印象"撬开了一道缝，好感度也跟着往上抬了一截。

9.对山的敬畏

做「山野天气」，最深的体会是：徒步天气不是"锦上添花"的功能，而是"生死攸关"的信息。海拔每上升 1000 米，气温下降约 6 度；山脊上的阵风可以轻易超过 8 级；一场午后雷雨，足以让一条轻松的路线变成危险的下撤。

300+ 条路线，是两个数据源，是对每一座山、每一条路的敬畏。

遇见山野，量力而行；在山野中撒欢，在山野中寻找纯真。

愿每一次出发，都晴空万里；愿每一次下撤，都平安归来。

网页/手机:山野天气