← #803

Show HN：Brolly，一个纯文本天气预报站点

文章摘要

作者 jsax 的动机很具体：英国气象局（Met Office）最近改版了网站，加了大量留白、滚动和动画，可用性对他而言显著下降，他想要一个「一眼看完」的天气站点。于是有了 brolly.sh——一个极简的纯文本天气预报站。

功能覆盖得相当完整：全球任意地点的 7 天预报；前一日回顾（这样你可以确认昨天到底是更凉更热、更湿还是更干）；逐小时的降雨、风、气温和天气状况；逐小时的紫外线、空气质量和花粉，在欧盟与英国境内还细分到具体花粉种类。

页面刻意设计成单列长滚动，为手机优化，桌面端也能看，只是左右留白很多。作者说自己从 plaintextsports.com 汲取了大量灵感——虽然他并不看体育，但很喜欢那种美学；不过他强调这不是照搬，Brolly 有自己的观感。他在可视化上花了很多时间，让所有图表只用字符实现，他最得意的是花粉计数用的逐小时热力图。

另一个设计要点是所有页面状态都编码进 URL：地点、选中的日期、展开或折叠的区块。他的原话是，交互式站点最让人恼火的一点，是你没法把一个页面分享给朋友并让对方看到和你一样的东西；把状态放进 URL 之后，你可以分享或收藏某个具体视图，而且知道自己总能回到它。

技术上，站点用 PocketBase，Go 加纯 HTML/JavaScript/CSS 编写，所有页面后端渲染，只用少量 JavaScript 在切换前后日时无跳动地重载内容。天气数据来自 open-meteo.com（免费额度很慷慨），并在 PocketBase 之上自建了一层 LRU 缓存。作者在 About 页对 AI 的表态也被评论区特别称赞：站点是他手工设计的，架构和结构由他定义；他用 AI 实现了相当大的一部分，但把最有意思的部分留给自己写。他说自己对 AI 感受复杂——没有它他根本没时间做出这个站，日常工作里也重度使用它来提速；但也有些地方他刻意不用，或是为了保住专注解决问题的乐趣，或是为了确保自己不会不小心「AI 刷屏」地过完一生。一切都是平衡。

实际页面长这样：顶部是当前状况（气温与体感、风速与阵风、UV、AQI、湿度与露点），接着是本周表格（含「昨天」一行），然后是逐小时状况表，再往下是全部用 ASCII 字符画出的降水、气温/湿度双轴、紫外线、空气质量和花粉图表，每个图表下方都附有图例和峰值时刻。

HN 评论精华

帖子拿到 228 分，讨论出奇地建设性——几乎全部是功能请求和技术细节，作者逐条认真回复。

最大的共同诉求：让它真的能被 curl

kachnuv_ocasek 开场就问：纯文本模式怎么开？我试了 Accept: text/plain，拿到的还是 HTML。raajg 替他回答：这不是「真正的」纯文本，而是渲染得像纯文本的 HTML/CSS——不过仍然很漂亮。wormpilled 立刻搬出了参照物：curl wttr.in。
speerer、Gualdrapo、hliyan、rlopezcc 等多人接力提出同一件事：如果 curl 这个站能返回终端文本视图会非常酷。trollbridge 给出了具体的接口设计建议：理想情况下应该支持设置 Accept: text/plain，或者提供一个 .txt 结尾的端点。hliyan 更进一步，建议做成类似命令行工具的形态——参数通过 URL 或 query 传递，再来一个 /help 路由返回支持的参数；Symbiote 推荐参考 traintimes.org.uk 那种把参数编进 URL 路径段的做法。作者表示这条反馈收到了很多次，一定会做，并反问大家期望输出是单日、多日还是两者都要。
这条支线还长出了一段考古：O1111OOO 贴出了通过 finger 协议查天气的方法（printf 'weather:85334\r\n' | nc bbs.airandwave.net 79），trollbridge 遗憾地回复：真失望你没直接写成 finger weather:85534@bbs.airandwave.net。

URL 短码之争

Contortion 和 vatsel 都问了同一件事：为什么 URL 参数是混淆的？伦敦是 forecast/zRKY7wMc，做成 brolly.sh/forecast/united-kingdom/yorkshire/york 对用户和 SEO 都更友好。goodmythical 的对比更直接：wttr.in/nyc 一目了然，forecast/YcUDdBLc 对我毫无意义。
作者 jsax 给了详细解释：最初 URL 用的是经纬度，也试过地名，最后落到短码是为了尽量减少对下游服务的 API 调用。短码在搜索时生成，映射到一张表里的地名、经纬度、海拔等；短码由地名派生，所以两个人搜同一个地方会得到同一个短码。这样一次预报查询就是一次 SQLite 读加一次预报 API 调用。而描述性 URL 需要两次串行调用——一次算经纬度和地名，一次取预报；这不是巨大的速度问题，但他找不到免费额度慷慨或低量定价合理的地理编码 API，而且地理编码 API 的输出可能变化，会让同一 URL 的预报变得不确定。他也承认短码很可能不是正确解法，会再想想。
echoangle 并不买账，把流程一步步拆开质问：搜索地点 XYZ，地理编码 API 返回经纬度和规范名 ABC，你把它和 slug 存进数据库，返回 abc 给用户；下次有人请求 abc，你查库拿到经纬度再去查天气——这跟短码方案有什么区别？在哪一步多出了一次地理编码请求？这条追问最后也没得到作者的正面回答。Svip 提出了折中方案：在短码后面附加地名后缀，形如 /forecast/<shortcode>/united-kingdom/yorkshire/york，后半段对站点无用但对用户有意义。

搜索是最集中的 bug

8ig8 搜「Raleigh, NC」找不到，只搜「Raleigh」才行；jen20 搜「Austin, Texas, United States」「Austin, Texas」甚至「Texas」都几乎没结果；Pikamander2 报「Orlando」有一堆结果但「Orlando FL」一个都没有，并建议加输入即时补全。作者表示会考虑改进搜索甚至更换 API 提供方。这条支线最漂亮的地方是 terraputix 的出现——open-meteo 地理编码 API 那边的人直接在评论区开了 issue（open-meteo/geocoding-api#33）跟进，说支持这个应该不难，近日就看。

历史数据意外成为杀手功能

firasd 说「上周比这周暖」这类过去几天的趋势在日常闲聊里极常见，却在天气应用里被严重低估。andrepd 附和：我一直很烦没有任何天气网站能让我看历史数据，哪怕只是过去几天的。bthallplz 也特意点出，他非常欣赏能看到本地过去几天的记录，太多天气站点只朝前看；他还提了个延伸想法：如果站点能告诉你某地最近的天气有多反常，对于你正在度假或考虑搬去的地方会非常有用。
Leftium（自己也做了一个基于 open-meteo 的天气站）在多条回复里贡献了扎实的领域知识：open-meteo 可以查到 1940 年以来的历史数据，而且是他所知唯一能用一次调用同时拿到预报和历史的天气 API；配好一个常量甚至能一次拿到 90 天历史加预报。他还对降水图表提了个反直觉的建议：可以干脆丢掉降水概率——他长期对比下来，即使预报 90% 以上的概率也往往完全不下雨，就算下了量也常常不值得带伞；他贴出首尔前几天的数据说明，按概率看像是连续下了 48 小时以上，但降水量柱状图才真正说明雨在什么时候落下。他认为最该补的数据是 60 分钟降水预报，可惜 open-meteo 不提供。

LLM 友好性被反复提到

firasd 顺手做了个实验：把德里页面的内容粘给两个模型问「大意是什么」，一个答「炎热潮湿，午后有小阵雨可能」，另一个答「大部分晴朗，但炎热且非常潮湿，实际最高 34 度而午后体感 42 度」，他评价这个输出「恰好是为 LLM 做过上下文工程的」。winterscott 补充说这种结构化、简洁、没有 UI 噪音的格式对 agent 解析和总结友好得多，建议加个 JSON 端点或 MCP 服务器。efilife 泼了盆冷水：可为什么呢？我们已经有 API 了，何必解析一个网站再喂给 LLM？

功能请求清单

湿度（leonpillow，作者回复会加，还打算加湿球温度）；日出日落时间和流星雨等天象（作者自己的清单）；华氏度切换（bl4kers、SaltyAstronaut，注意到 URL 里也没有单位设置）；深色模式（m_walden，理由是照顾视觉不适的用户，并指出 wttr.in 就是深色的）；Unicode 天气符号（benj111、bluebarbet，作者说页面顶部的雨伞 logo 本身就是个 Unicode 字符，这个想法很契合）；机场代码/ICAO 直达（leetrout 建议 brolly.sh/kjfk，sssilver 想要同样美学下的 METAR）。

weatherphan 给了一段颇有远见的提醒：一旦大家用上 Brolly，会立刻爱上它，随之而来的是功能请求的洪水；所以最好现在就设计好支持多样化定制所需的分层结构。他以航海场景为例——需要节为单位的风速、风向、露点，还要一段近期气压时序来判断天气系统尺度的形势；而且即使在航海这个细分里，需求差异也很大（摄氏还是华氏、hPa 还是英寸汞柱）。他建议把用户偏好也编码进 URL，让每个人都能得到属于自己的定制预报，同时保留常见场景的预制页面。作者回应说他也在考虑做覆盖这些用例的专门子页面，主页面只留一个入口区块——航海页确实可行。

性能与地理定位

jonahx 指出纯文本服务的好处之一是近乎瞬时加载，但这个站在快速宽带上要几秒，刷新同一页也一样。作者道歉并解释：站点跑在 DigitalOcean 伦敦机房一台 512MB 的小 droplet 上的 PocketBase 实例，当前负载远高于平常。jonahx 用 Chrome DevTools 追查后发现延迟可能来自自定义字体，hahahaa 和 winrid 都建议干脆去掉自定义字体、改用系统字体栈。
gregsadetsky 建议用 IP 地理定位给一个足够好的初始位置；hogwasher 立刻反对：他恰恰喜欢它不这么做，因为那样的站点在用 VPN 时会变得头疼甚至完全不可用；而且既然可以把位置收藏成书签，自动定位顶多让非 VPN 用户的首次访问稍快一点。

情怀与同类项目

NeuroDoc 贡献了最有年代感的一条：看到纯文本天气报告把他带回 34 年前——1992 年他在北卡教堂山写神经科学博士论文，写作间隙在实验室电脑上折腾，其中一个纯为好玩的项目就是写一个 Bourne shell 脚本去取 Weather Underground 的数据。「真高兴看到纯文本天气至今仍有用武之地。」
popalchemist 一句话：有那味儿了，这才是网页曾经的感觉。syngrog66：感谢你为这个世界又带来一个 TUI。
评论区顺带冒出一批同类项目：Leftium 的 weather-sense（同样基于 open-meteo，主打历史天气对比）、karteum 几个月前 vibe code 出来的自用 meteo 站（可在地图上点选多个点）、lowkeyokay 走完全相反视觉路线的 tshirtweather.fyi，以及被反复提及的祖师爷 wttr.in。
walthamstow 说了句大概让作者很有共鸣的话：太好了，原来讨厌 Met Office 新网站和 app 的不止我一个——但他们的预报和雷达图确实是最好的。作者解释 open-meteo 会按地区从大约 30 个模型里取数，在英国通常就用 Met Office 的数据；他没有强制只用 Met Office，因为后者并不提供页面上展示的全部数据（比如按种类细分的花粉计数）。
smnscu 讲了个小乌龙：他一开始完全困惑于网站为什么显示约克的天气——他在那里读过书，常回去所以经常查约克的天气，还以为是自己设置过却不记得了。simonjgreen 从 About 页找到答案：那是作者的家乡。