我开发了一个工具，可以将原始的 Git 活动转化为 AI 摘要。
1 分•作者: slmslm•19 天前
和许多开发者一样，我厌倦了在不同的代码仓库之间来回切换，仅仅是为了回答一些简单的问题，比如：
这周到底改了什么？
哪些 PR 停滞不前了？
我们发布了什么？
谁在等待审核？
它位于你的 GitHub/GitLab/Bitbucket 代码仓库之上，并将这些杂乱的信息转化为可读的内容。
到目前为止，最难的部分是什么？Webhooks。
每个提供商发送的负载信息都完全不同：
不同的键
不同的结构
缺失的字段
命名不一致
你最终花费在规范化数据上的时间比构建功能还要多。
我们通过创建一个内部统一的事件模式 + 每个提供商的映射器来解决这个问题。
所有规范化的事件都存储在 MongoDB 中，这非常有帮助，因为灵活的文档模型使得处理略有不同的数据结构变得毫不费力，而且不会破坏任何东西。
一旦我们拥有了这些，功能就自然而然地出现了：
实时提交和 PR 监控
基于你的代码仓库活动训练的 AI 智能体
自动化的每周/每月摘要（电子邮件或 Slack）
贡献评分排行榜
公开的变更日志页面
多平台支持（GitHub/GitLab/Bitbucket）
基本上，这是一个为快速行动的团队提供的统一活动层。
为什么要构建它？
Git 平台给你原始数据。
团队需要上下文。
开发者需要快速的答案。
管理者需要摘要，而不是仪表板。
查看原文
Like many devs, I got tired of bouncing between repos just to answer simple questions like:<p>What actually changed this week?<p>Which PRs are stuck?<p>What did we ship?<p>Who’s waiting on a review?<p>It sits on top of your GitHub/GitLab/Bitbucket repos and turns the noise into something readable.<p>The hardest part by far? Webhooks.
Each provider sends totally different payloads:<p>different keys<p>different structures<p>missing fields<p>inconsistent naming<p>You end up spending more time normalizing than building features<p>We solved it by creating an internal unified event schema + a mapper for each provider.
All normalized events get stored in MongoDB, which helps a lot because the flexible document model makes it painless to handle slightly different shapes of data without breaking anything.<p>Once we had that, the features came naturally
Real-time commit & PR monitoring<p>AI agent trained on your repo activity<p>Automated weekly/monthly summaries (email or Slack)<p>Leaderboard with contribution scoring<p>Public changelog pages<p>Multi-platform support (GitHub/GitLab/Bitbucket)<p>Basically a unified activity layer for teams that move fast.<p>Why even build it?
Git platforms give you raw data.
Teams want context.
Devs want fast answers.
Managers want summaries, not dashboards.