ntfy 叮：我和 AI 半天做出一个 Firefox 推送通知插件

又是一个「顺手做个小工具」的周末。这次的产物是一个 Firefox 插件------ntfy 叮 (Receive from ntfy) ：常驻在浏览器后台，监听 ntfy.sh 上你订阅的公共频道，一来消息就弹一条桌面通知，顺带「叮」一声。

从下午制定方案开始，到凌晨把打包好的源码丢进 Firefox 的 AMO 商店排队审核，中间连写代码带做图标、截图、三语翻译文案、README，满打满算半天多一点。在 Claude Code 的助力下，这种「一个念头到能提交上架」的距离被压得非常短。

ntfy 是什么，为什么要它

ntfy 是一个基于 HTTP 的极简推送服务：你往一个「频道」(topic) PUT/POST 一段文字，所有订阅了这个频道的客户端就能立刻收到。没有账号、没有 App 绑定，一条 curl 就能发通知：

bash 复制代码

curl -d "构建挂了" https://ntfy.sh/my-alerts

它天然适合当各种自动化的「最后一公里」------服务器磁盘告警、CI 构建结果、网页爬虫状态报告，任何脚本（Python 之类）发个简单 HTTP 请求就能把消息推送出去，没有 SDK、服务器和账号体系负担。官方有手机 App 和网页端，但都不太合我的工作习惯：我一整天基本都坐在电脑前，手机又常年静音，消息与其推到手机上，不如直接推到眼前的电脑来得及时。

至于 ntfy 网页版，他要长期占着一份不小的内存（实测约 190MB）和页签空间，这种不必要的开销实在让丐版 mac mini 吃不消。真正让我动念，是受到 Firefox 插件 Checker Plus for Gmail 的启发：一个小图标安安静静待在工具栏图标上，邮件来了叮一下，点开就能简单处理，轻量又不打扰。我想要的，就是这套体验的 ntfy 版，让浏览器的插件栏直接替我接住这些消息。

动手前我先在 Firefox 的插件市场里翻了一圈，我想这么直接的需求总该有现成的，结果没找到能用的：直接对接 ntfy 的插件只有两款，一款是收信的，但已经很久没人维护，实测不能正常工作；另一款则专门用来发消息，叫 Send to ntfy------正是我这个插件英文名 (Receive from ntfy) 的灵感来源。

于是就有了这个插件。目标很明确，做「减法」也做得干脆：只订阅公共的 ntfy.sh，打开即用，不碰登录、不碰自建服务器、不发消息，就安安静静地收。

它能做什么

订阅任意数量的 ntfy.sh 公共频道
来消息发出「叮」一声，接住消息，并弹出桌面通知
支持 ntfy 的常用字段：优先级、emoji 标签、消息链接、附件提示、操作按钮（打开链接 / 发请求 / 复制文本）
本地缓存历史消息，数量可调
支持简繁中文、英文界面，跟随 Firefox 语言自动切换

怎么用（没接触过 ntfy 也能三步试上手）

ntfy 的公共频道没有账号、没有密钥，频道名就是唯一的「地址」------谁知道名字谁就能收发。所以取一个别人猜不到的频道名（比如 wavky-test-9f3a2），就当成你的私有通道。

订阅：装好插件后，在弹窗里把这个频道名加进订阅列表。
发消息 ：随便挑一种方式往这个频道发一条------
- 命令行一条 curl 就行：
  bash 复制代码
```
curl -d "Hello, World!" https://ntfy.sh/wavky-test-9f3a2
```
- 不想敲命令，直接打开 ntfy.sh/wavky-test-9f3a2 这个网页，在输入框里打字发送也一样。
接住：浏览器右上角就会「叮」一声弹出通知。

跑通之后，把那条 curl 塞进你的脚本、爬虫或 CI 流程的收尾处，任务一结束消息就直接推到眼前了。

技术选型

Manifest V2 而非 V3。 「一直挂着监听」需要一条常驻连接，而 MV3 的后台是 service worker，空闲即被回收、长连接会断。Firefox 长期支持 MV2，其后台页可设常驻，只需约 10MB 固定内存，比常开一个 ntfy 网页标签（约 190MB）轻量得多。（由于 Chrome 已经不再支持 MV2，加上上架还要付费，就不考虑移植了。）

SSE 而非 WebSocket。 ntfy 官方提供 /{topic}/sse 端点，原生 EventSource 自带断线重连，省去手写心跳；多个频道还能用逗号拼进一个 URL 合并成单条连接。

已知的边界

最大的一条限制是：只支持公共的 ntfy.sh，不支持自建 / 私有服务器 ------域名写死在代码里，权限也只申请了 https://ntfy.sh/*。原因很骨感：我自己既没有服务器资源、也没注册 ntfy 账号，暂时没有对接私有实例的需求，也就没做这块实现。

但我得诚实承认，这其实把相当一部分潜在用户挡在了门外：ntfy 的核心用户群明显偏自建（GitHub 18k+ star，Reddit 有独立版块，是 selfhosted 圈子里的常客），很多人跑的正是自己的私有实例。支持自建不是架构级的大改，主要是要改成运行时动态申请域名权限、再处理一下鉴权凭证------这些就留给后续版本了。

不过话又说回来，这也和插件的定位有关：它面向的主要是个人工具脚本、爬虫这类自动化程序产出的消息推送，由插件在浏览器里安安静静地接住并弹个通知，图的是轻量顺手，而非用于生产环境级别的通知接收。抱着这个心态去看，公共 ntfy.sh 其实已经够用了。

半天的意义

回过头看，真正被压缩的不是「写代码」这一步，而是它周围那一圈琐碎但绕不开的东西：绘制矢量图标、搜集浏览器插件的架构接口规范、调研 ntfy 消息特性和对接方式、界面多语言文案和翻译、截图加工、写用户向的 README、搞清楚 Firefox 插件提交的方式和审查规则......过去这些七零八碎加起来，往往比核心逻辑还耗时间。更别提对于 Android 工程师来说，JS 框架、MV2、i18n 等前端技术概念，基本上都在我一知半解的知识盲区里。

但现在，我只需要像个监工一样端着杯茶，看 AI 评估总结方案让我拍板，然后吭哧吭哧开始干活，干得不好给他骂骂咧咧指点两句回炉重练，直至产出像模像样的产品，一个晚上就能把它们连同代码一起收尾，然后安心地丢进审核队列去睡觉，这种近乎零成本的跨赛道的体验，是这个年代技术赋予的专属特权。

我越来越觉得，这正是这个时代对「懂技术的产品经理」的意义所在：AI 拉平的是「某一门具体技术的实现门槛」，没有拉平的是「判断什么值得做、怎么做才算做对」的能力。前者曾经是一堵硬墙，逼着你要么已经是专业赛道选手、要么一头扎进文档死磕，如今更像随时可以调用的产能；而后者需要基于工程直觉决定取舍的分寸，和对体验的挑剔，依然得由人来提供，也因此比过去更值钱。（这几段都是 AI 在胡扯）

插件已经通过审核，上架在 Firefox Add-ons 上，点开就能直接安装。

代码也开源在 GitHub 上，MIT 协议，欢迎 star / issue / PR。

如果你也在用 ntfy，欢迎试试让浏览器帮你接住那些「叮」。

本文原载于我的博客：ntfy 叮：AI 半天做出一个推送通知插件