应用介绍
给 App 加推送，第一版永远很简单：调一下 APNs，把 token 存进数据库，发。麻烦是从第二个月开始冒出来的——用户换了手机，旧 token 一直发失败；同一条消息想只发给"这周练过三次的付费用户"，得自己写查询；用户在设置里关掉了"营销通知"，你得自己记住并在每个发送点判断；APNs 偶发 503，重试逻辑又要自己补一套。等这些都补完，你的业务代码里已经躺着一个没人想维护的通知系统了。
BuzzKit 把这一层单独拎出来。密钥还是你自己的，它不碰你的推送账号，只负责上面那些烦人的部分：订阅者和设备的同步、按属性和行为圈人、用户自己的通知偏好、定时和工作流、失败重试、送达回执，一个 API、一个后台全都有。
接入方式是"接一次，之后靠事件驱动"。SDK 负责让用户和设备信息保持最新，你的 App 和后端只管把发生了什么报上去，剩下发什么、什么时候发，交给后台里配好的工作流决定。目前正式支持 iOS 推送，Android、邮件、短信作为连接器接在同一套多渠道内核上，路线图里已经排好。可以直接用 buzzkit.dev 的托管服务，也可以把同一份代码自己部署。
可视化工作流：触发条件、分支判断、等待、发送串成一张流程图。"试用开始后一天，如果用户还没打开过 App 就推一条提醒"这种逻辑在后台点几下就配好，不用发版。
按行为圈人：分群条件支持用户属性、事件次数和活跃时间的组合，比如"套餐是 pro 且最近 7 天完成过 3 次训练且 30 天内活跃过"，条件写完立刻能看到命中多少人。
订阅者与设备同步：SDK 自动维护用户与设备 token 的对应关系，换机、卸载、权限撤销都会同步，不用自己清理失效 token。
通知偏好与 Topic：用户可以按主题订阅或退订，偏好由 BuzzKit 统一保管并在发送时生效，你的业务代码不用再各处判断。
送达回执与事件流：每条消息的可达、已发送、待发、失败数量逐条留痕，事件流基于 Tinybird，能一直追到具体某个订阅者。
自带密钥自托管：推送凭据由你提供并加密保存，整套代码 AGPLv3 开源，可以部署在自己的 Cloudflare Workers、PostgreSQL 和 Tinybird 上。
类型安全的 SDK：服务端 SDK 与 API 共用同一套 schema，工作流、数据源、导入格式在客户端和服务端用同一份定义校验，接口改动编译期就能发现。
BuzzKit 把这一层单独拎出来。密钥还是你自己的，它不碰你的推送账号，只负责上面那些烦人的部分：订阅者和设备的同步、按属性和行为圈人、用户自己的通知偏好、定时和工作流、失败重试、送达回执，一个 API、一个后台全都有。
接入方式是"接一次，之后靠事件驱动"。SDK 负责让用户和设备信息保持最新，你的 App 和后端只管把发生了什么报上去，剩下发什么、什么时候发，交给后台里配好的工作流决定。目前正式支持 iOS 推送，Android、邮件、短信作为连接器接在同一套多渠道内核上，路线图里已经排好。可以直接用 buzzkit.dev 的托管服务，也可以把同一份代码自己部署。
软件功能
可视化工作流：触发条件、分支判断、等待、发送串成一张流程图。"试用开始后一天，如果用户还没打开过 App 就推一条提醒"这种逻辑在后台点几下就配好，不用发版。
按行为圈人：分群条件支持用户属性、事件次数和活跃时间的组合，比如"套餐是 pro 且最近 7 天完成过 3 次训练且 30 天内活跃过"，条件写完立刻能看到命中多少人。
订阅者与设备同步：SDK 自动维护用户与设备 token 的对应关系，换机、卸载、权限撤销都会同步，不用自己清理失效 token。
通知偏好与 Topic：用户可以按主题订阅或退订，偏好由 BuzzKit 统一保管并在发送时生效，你的业务代码不用再各处判断。
送达回执与事件流：每条消息的可达、已发送、待发、失败数量逐条留痕，事件流基于 Tinybird，能一直追到具体某个订阅者。
自带密钥自托管：推送凭据由你提供并加密保存，整套代码 AGPLv3 开源，可以部署在自己的 Cloudflare Workers、PostgreSQL 和 Tinybird 上。
类型安全的 SDK：服务端 SDK 与 API 共用同一套 schema，工作流、数据源、导入格式在客户端和服务端用同一份定义校验，接口改动编译期就能发现。
