被GitHub通知淹没？开发者用AI摘要做了个降噪工具

GitHub 通知堆积是不少开发者日常的隐痛：几百条未读里，真正需要你动手的可能只有几条。开发者单独构建了一款名为 GitHub Digest 的工具，试图用优先级分类加 AI 摘要的方式解决这个问题。

问题：真正等你处理的通知，被噪音埋掉了

作者描述了自己的真实处境——通知栏里有上百条未读消息，但无法分辨哪些在等自己回应、哪些只是围观性质的噪音。最典型的场景是：一个待你审核的 PR 请求，被 40 条无关紧要的讨论通知压在下面，很容易被彻底忽略。

这类问题的根源在于 GitHub 原生通知按时间倒序排列，不区分"是否指向你"和"是否需要动作"。越活跃的仓库，噪音越大，真正卡在你这里的任务反而越难被发现。

解法：三档优先级 + 一句话说明分类理由

GitHub Digest 用 GitHub 账号登录后，把通知自动归入三组：

• 需要你现在处理（Needs you now）：审核请求、直接向你提出的问题、构建失败
• 今天值得一看（Worth a look today）：@ 提及和评论
• 可以等（Can wait）：其余全部

每条通知还会附加三层信息：一段 AI 生成的短摘要，说明这条通知想让你做什么；一行"Why it's here"（为什么它在这里），例如"有人需要你审核"；以及 Done 和 Mute 按钮，处理完或屏蔽后不会再回到列表。

一个细节值得一提：审核请求停留超过 2 天，会被打上"Waiting"标记。这个设计把"拖延中"的状态显性化，避免请求悄无声息地烂在列表里。

技术实现：只用最小权限，AI 摘要不碰内容正文

作者公开了完整的技术栈和几个关键取舍：

• 后端：Node.js + Express
• 登录：GitHub OAuth，仅申请 read:user 和 notifications 两个权限，不触碰代码仓库
• 数据库：Turso（托管式 SQLite），访问令牌存储前加密
• AI 摘要：Google Gemini，只处理最紧急的 20 条线程，且只发送标题、类型、分类原因和仓库名，不发送通知正文
• 托管：Render

这些约束说明作者在隐私和权限边界上做了刻意控制：AI 能看到的信息量被压到最低，token 加密存储，权限范围只覆盖通知读取本身。对在意数据安全的开发者来说，这套设计比"先跑起来再说"的实现更有参考价值。

GitHub OAuth 的权限体系通过 scope（授权范围）来控制第三方应用能访问的数据边界。read:user 只允许读取用户的基本公开资料，例如用户名、头像和邮箱；notifications 则允许读取和管理通知，但无法访问代码仓库内容、Issue 正文或 PR 差异。GitHub 近年来还引入了更细粒度的 fine-grained token，但 OAuth App 仍以 scope 为主要控制手段。因此，一个应用申请哪些 scope，直接决定了它一旦 token 泄露或被滥用时可能造成的破坏面。GitHub Digest 只申请这两个权限，意味着即使服务端被攻破，攻击者也无法借此读取任何私有仓库代码，这是它在权限设计上最值得称道的取舍之一。

Turso 是一个基于 libSQL（SQLite 的开源分支）的托管式数据库服务，主打边缘部署和低延迟读取。它兼容 SQLite 的 SQL 语法和大部分生态工具，但通过网络提供托管访问，并支持嵌入式副本（embedded replica）模式，让应用在本地保留一份只读副本以加速查询。对于 GitHub Digest 这类中小规模、读多写少的个人项目，Turso 省去了自建数据库和运维的麻烦，同时保留了 SQLite 的简单性。作者特别提到访问令牌在存储前加密，这针对的是 OAuth token 一旦落库明文就可能被内部或外部人员读取的风险，属于对敏感数据的额外一层保护。

踩坑与迭代：线上环境变量名写错，查了几小时

作者分享了两个具体教训。一是把 OAuth、session 和数据库串起来跑通的工程经验，比任何教程都更有价值——这类集成问题往往没有标准答案，只能自己趟。

二是线上才出现的一个 bug，最终定位为环境变量命名错误，耗掉数小时。作者的建议很直接：先看部署日志。

第三个迭代来自外部反馈。有 Reddit 用户在讨论中提到，优先级标签只有在能解释自己的时候才更容易被信任。作者当天就加上了"Why it's here"这一行。这个细节说明分类工具的核心不只是分得准，还要让用户理解分类逻辑——否则错误的优先级反而会破坏信任。

环境变量命名错误之所以能在本地通过、线上却翻车，通常是因为本地开发往往有默认值、.env 文件或 IDE 注入的变量，而线上托管平台（如 Render）需要手动在控制台配置。大小写、拼写或前缀不一致时，代码在本地读到的是正确值，线上则读到 undefined，于是 OAuth 回调失败、session 无法签名或数据库连接被拒。这类问题不会有编译期报错，往往表现为运行时某个功能静默失效，排查时容易先怀疑代码逻辑而忽略配置。作者建议先看部署日志，正是因为托管平台通常会在启动或请求阶段打印缺失变量的警告，先核对环境变量清单往往比逐行调试更快定位。

后续计划：允许纠正优先级，邮件摘要代码已就绪

作者列出的下一步计划有两个：一是允许用户在优先级判断错误时手动纠正；二是每日邮件摘要——代码已经写好，但尚未启用开关。

工具目前处于免费阶段，作者在独自开发，并公开征询反馈：哪里让人困惑、缺了什么、以及什么功能会让你真正用起来。对于同样被通知淹没的开发者，这是一个值得观察的小工具样本，它也展示了用最小权限 + 受限 AI 调用解决具体痛点的一种可行路径。