github.com starcat-app/Starcat GitHub - starcat-app/Starcat: A native macOS app that turns GitHub Stars into a searchable, organized, AI-powered personal knowledge base. A native macOS app that turns GitHub Stars into a searchable, organized, AI-powered personal knowledge base.

各位佬友们好，占用大家一点时间，主要是介绍一些最近花了 2 个月写的一个 GitHub Star 管理工具，但是 Star 管理只是基础功能， 我想做的是将我们 Star 过的项目转变为可用的知识库。 且听我细细道来。

作为一个开发者，我经常到 GitHub 去看一些有意思的开源项目，且毫无吝啬的给我感兴趣的项目 Star, 但是久而久之 Star 过的项目越来越多, 尤其是从 25 年开始, 出现了太多优秀的 AI 相关的项目了, 而且我又是一个工具控，不敢用不用得上, 基本上每天都在给开源项目点 Star.

但是问题也出现了, Star 的目的不仅仅是对项目的认可与鼓励, 我还把它当成书签来用, GitHub 上可以随时查看个人 Star 过的项目, 但是并不能区分哪些是表示认可, 哪些是在之后的工作中可以学习参考的项目.

以上是现在 GitHub Star 管理的主要矛盾, 虽然 Github Lists 可以通过分组的方式来做简单的管理, 但是并不能满足我的需求.

所以之前我一直在使用 OhMyStar 这款优秀的 macOS 应用来管理 Star, 但是发现许久都没有更新了(🥲, 尴尬了 在写这个帖子的时候, 又去看了一下, 居然发布更新了…..).

然后又调研了同类型的其他工具， 都没有达到我预期的效果，因为我要的不仅仅是基础的 Star 管理， 我更想从已 Star 的项目中挖掘更多的信息， 所以我考虑自己开发一个 macOS 应用来满足我的需求。

现在 Starcat For GitHub 已经完成了， 且迭代到 1.5.0 版本了（今天刚刚发布），目前应该算是比较稳定且功能已满足我日常使用了，所以今天来到 L站 给佬友们汇报一下工作。

Starcat 最初是收费产品，本想靠这个产品发家致富, 但是梦想太美好, 哈哈哈哈.
在发布到 AppStore 和 海外市场后, 发现并没有多少流量, 且理性的想了一下后, 靠这个发家致富简直是痴人说梦, 所以现在全部开源, 至少还能收到大家的 Star, 仅保留负责 Direct 渠道授权的 starcat-license-api 为私有(这个服务对接了 Creem 来做授权管理, 所以现在无法开源). 官方 Mac App Store 和 Direct（starcat.ink）版本仍会持续提供和维护。

特性

这个项目花了很多精力, 功能也非常多,但是我不想一一列举, 感兴趣的佬友们可以直接看全部的 更新日志, 我挑几个我认为比较好用且经常使用的功能.

Star 基础管理

典型的三栏布局, 左边导航, 中间项目列表, 右边详情展示, 普普通通, 但是加上了自认为比较美观的 UI(大佬勿喷, 后端开发非专业 UI设计).

星标模块

这个是我们最常用的功能, 可以看到我们 Star 过的所有项目, 项目的的 Star, Forks, Watchers 等数据全部能看到, 详情页还能做点笔记, 懒的话还能先使用 AI 生成出一个模板出来然后在慢慢添加项目使用的坑点等(反正我就是这么做的, 写点填坑记录).

另一个就是 AI 摘要生成和对话:

让 AI 帮我总结一下这个项目, 默认使用 README 来生成, 不过也可以开启代码上下文(会下载整个项目并分析, 这就比较慢了哈)与外部网络搜索(现在支持 AnySearch, Tavily, Exa 和 Brave, 后续应该会集成更多更好用的 LLM 友好的搜索服务, 优先免费的), 目的是增加项目的摘要准确性.

翻译功能:

现在支持 18+ 语言, 会先根据当前应用的语言来自动翻译, 同时支持分段和全文翻译.
但是用下来发现 AI 翻译的其实并不快, 原因是 README 渲染为了保持和 GitHub 相同的样式, 是直接加载的 HTML, 所以需要先抽取待翻译的内容发送给 AI, 翻译完成后还要再次渲染, 这种方式也就无法使用 macOS 内置的翻译接口了, 所以这个也是后续优化的点.

接下来就是洞察页面了, 我为每个项目都添加了洞察页面, 目的就是更好的了解这个项目:

你可以在这个页面看到这个项目的大量统计信息, 其中我最关心的就是 Star 历史数据, 因为 GitHub 不再为非项目成员开放获取 Star 历史的功能了， 所以为了能展示项目的 Star 历史曲线, 我爬取了从 2016 到 2026 年的所有 Watch Event 数据（家里的 ZFS 服务器终于派上用场了）， 并且会每日增量更新。虽然数据并不实时，但是这个场景足够使用了, 而且这个历史数据解决也会开放出来，让大家免费使用。

知识库：

已 Star 的项目和知识库的关系这个需要跟佬友们汇报一下。前面我们说了 Star 的项目中包含了单纯的认可和之后我们可能会使用到的项目，我们需要将后者这部分项目区分出来，作为后续 RAG 的数据来源， 所以这里新增了一个 知识库 分类。

其他就是一些不痛不痒的功能了，比如 AI 批量整理标签， AI 整理分组，智能集合，订阅发布管理等等

探索模块

前面一直在说怎么管理自己已经 Star 的项目，但是 Starcat 肯定不能只做一个“仓库收纳箱”。
因为我自己 Star 这么多项目的源头，其实就是每天都还在不断发现新的项目。GitHub Trending、各种周刊、榜单、Awesome List，我都会去看。但是这些内容分散在不同地方，看到了一个项目之后，往往又要自己回 GitHub 打开、判断、收藏、整理。
所以 Starcat 里面做了探索模块，把这些发现入口尽量放到了一起。
最基础的就是 GitHub Trending，支持按时间、语言看榜单；除此之外还有发现榜单、新发布项目、阮一峰周刊、Show HN、HelloGitHub 等来源。看到感兴趣的仓库，可以直接看 README、项目详情，也可以不 Star 直接放进知识库，后面再慢慢研究。

这里主要说一下 Weekly 这个分类吧，这里收集了比较火的几个数据来源：

1. 阮一峰老师的 Weekly 项目， 这个就不用多介绍了吧。
2. ZRead：ZRead 每周也会有项目推荐，而且这些项目都会在 ZRead 上有 AI 生成的文档，那就非常方便我们生深入了解这个项目。
3. Hacker News：Show HN 栏目下的开源项目，很多新项目，虽然星标不高但是也是一个趋势吧， 可以了解一下大家都在开发哪些有趣的项目。
4. HelloGitHub：如果是 Java 技术栈的话， 就很熟悉这个大佬了，这里也借用了一下大佬的接口（没有爬取，合理调用且增加了缓存）
5. AI 情报：这个是我在 B 站上看到一些比较感兴趣的 AI 开源项目，就会通过 Skill 写入到后端服务， 这样大家就都可以看到了。

1.5.0 里面我自己比较满意的是 Awesome 发现，现在可以直接浏览 Starcat 精选的 Awesome 项目，也可以把公开的 GitHub Awesome 仓库加成自己的来源。后台会去解析 README，把里面的项目按章节拆出来，方便搜索、筛选和批量选择。
我自己现在发现项目的流程，基本就是先在这里挑一轮，觉得有价值的先入知识库，真正需要长期关注的再去 Star、打标签、写笔记。

活动模块

活动模块不是一个单纯看仓库动态的页面，它更像是我放在 Starcat 里面的 GitHub 收件箱。
平时 GitHub 的通知很多，有人 @ 你、邀请你 Review、给你分配 Issue、Discussion 有回复、订阅的项目发了 Release，甚至还有安全公告。以前我都是浏览器开着 GitHub Notifications，有时候堆了很多也懒得处理。

现在这些内容可以直接在 Starcat 的活动页里面看，支持按未读、提及、评审、Issue、PR 等分类筛选，也会按今天、昨天、本周和更早分组。Issue 和 PR 能直接看到当前是 Open、Closed 还是 Merged；自己 Star、取消 Star、Fork 的记录，也能在时间线上一起看。

这个页面完全按照 GitHub Issues 来实现，支持从剪切板上传图片，Markdown 预览，AI 翻译讨论和 AI 撰写回复等等功能，佬友们可以试试好不好用，这应该算是我常用的功能了。

洞察模块

前面一直在讲怎么把项目收进来、怎么整理、怎么找回，但是项目一多之后，还有一个很现实的问题：
我到底收藏了多少东西？
这些项目我整理了多少？
哪些只是点了 Star 就再也没看过？
我的知识库里面现在到底有什么？

所以 Starcat 里面有一个单独的洞察模块，它看的不是某一个仓库，而是我整个 Star 收藏和知识库的全局情况。可以在“全部收藏”和“知识库”两个范围之间切换。

比如我所有收藏里面有多少已经整理、有多少还没打标签、有多少还没读；知识库里面有多少 README、可用于检索的内容、向量索引已经准备好了多少。

这样我就不用一个一个仓库点进去看，而是能先知道自己的资料库现在大概是什么状态。

另外还能看技术分布、Topics、开源协议、项目状态这些统计。收藏久了之后，确实会发现自己某段时间特别爱 Star 某一类项目，比如 AI、Agent、RAG、macOS 工具，或者又不知不觉攒了一堆 Rust 项目。😂

我自己最常看的是“待处理事项”，没打标签的、还没读的、缺 README 的、还不能建立索引的、健康度或 OpenSSF 安全评分还没拉到的，还有存在维护或安全风险的项目，都会集中在这里。

点击对应项目可以直接下钻到仓库列表，不是只给你看一个数字就完了。
还有一些已经长期没有动静、被归档，或者 GitHub 上已经不可用的项目，也能在这里集中看到。毕竟 Star 多了之后，定期整理一下还是很有必要的，不然知识库最后也会变成另一个“稍后再看”

支撑项目

Starcat 主体是 macOS 原生应用，核心功能、数据和代码都在主仓库里。不过有些能力如果全部塞进客户端，不太合适，也不太现实。
比如 GitHub Trending 本身没有官方 API；周刊、发现榜单、Awesome 解析、Wiki 收录探测、相似仓库推荐、公开分享页这些，也都需要独立服务来提供数据。
所以我围绕 Starcat 又拆了一些配套项目。它们不是一个大而全的后端，而是按能力拆分的小服务，需要的话都可以自己部署。

目前主要包括：

• starcat-trending-api：抓取 GitHub Trending 并提供 API
• starcat-weekly-api：阮一峰周刊、Show HN、HelloGitHub 等发现来源
• starcat-discovery-api：探索、热门、新发布榜单
• starcat-wiki-api：探测 DeepWiki、Zread、CodeWiki 等收录情况
• starcat-recommend-api：相似仓库推荐
• starcat-sharing-api：仓库公开分享页和短链
• starcat-api-kit：这些业务 API 共用的鉴权、响应结构和 GitHub 基础能力

除了服务端，我还做了 Chrome、Safari 插件，以及 Alfred、uTools、Raycast 的搜索插件，方便在不同入口直接找到本地已经同步过的仓库。

知识库的关键词搜索默认还是走本地 SQLite FTS5，向量默认也可以在本地算；如果想接 Meilisearch、Qdrant 等外部检索后端，也可以自己配。整体思路就是：默认本地优先，需要扩展时再接服务，而不是把所有数据都强行丢到某个云端。

这些支撑项目、部署说明和源码都在 Starcat GitHub Organization 下面，感兴趣的佬友可以自己看：

https://github.com/starcat-app

RAG 工作台

前面说知识库的时候，提到过 Star 和知识库是两层关系。
Star 更像是公开收藏，表示“这个项目我认可”或者“我以后可能会看”；知识库则是我明确想留下来、后续可能真的会用到的一批项目。

RAG 工作台就是基于这部分知识库做的。它是一个独立窗口，默认只会从已经入库的项目里面找资料。

比如我可以问：

• 我收藏的 Agent 框架里面，哪些支持 MCP？
• 帮我找一下适合做 macOS 菜单栏应用的 Swift 项目。
• 我之前收藏过哪些和本地 RAG 有关的项目？

回答不是只丢一段 AI 生成的文字出来，也会带上各种上下文，右边有一个 Citation Inspector，可以看到这段回答具体引用了哪个仓库、README 的哪一段、笔记还是摘要内容，也可以直接跳回原始证据。
检索部分不是单纯把所有 README 塞进模型上下文，而是结合了 FTS5 关键词检索、Embedding 语义召回和 RRF 融合。

简单理解就是：既能找“字面上写了什么”，也尽量能找“意思相近的内容”。

除了知识库里的 README、笔记、摘要之外，还可以附带 Markdown、JSON、源码文件等内容；需要时也能明确开启 GitHub 结构化查询或者联网搜索。

整个过程会显示在执行时间线上，方便知道这次回答到底查了哪些东西。

默认情况下，RAG 工作台是只读的，它不会自己给项目打标签、改笔记，或者把项目偷偷加入知识库。毕竟 AI 帮忙查资料可以，直接改我的收藏还是要谨慎一点。
Direct 版本目前还可以选择使用本机已安装的 Codex CLI 或 Claude Code CLI 来负责 RAG 的推理；但检索、引用、索引和本地数据仍然由 Starcat 自己控制。

Agent 工作台

Agent 工作台我把它设计成目前大多说 Agent 工具类似的样子，给几个内置的 Agent 工作流，比如本周热点项目，替代项目发现等，但是现在还是 Beta 版本，这块只能算“可用”，离我自己期待的“好用”还有一段距离。

它和 RAG 工作台不一样：RAG 主要是基于知识库回答问题；Agent 更偏向完成一个明确任务，比如生成 GitHub 周报、整理仓库信息、找替代项目，或者处理未分类仓库。

目前已经接入了 Starcat 内置 Runtime、DeepSeek Harness 和 Codex App Server，也能展示任务计划、工具调用过程和最终产物。

特别是多 Runtime 的事件展示、复杂任务执行、错误恢复和整体交互体验，后面都还需要继续打磨。

所以这个功能现在主要是给感兴趣的佬友尝鲜和交流用，不建议把它当成一个已经完全成熟的 Agent 产品。

后续我会持续完善，等真正达到我觉得好用的程度，再重点和大家介绍。

后续路线

接下来首先还是继续把现有功能打磨稳定。尤其是 RAG、Agent、探索来源、活动通知这几块，功能越多，越需要把错误恢复、加载体验、数据准确性和交互细节继续做好。
RAG 这边会继续优化检索质量、中文问题的召回、引用证据和真实知识库下的使用体验；Agent 工作台则会继续完善多 Runtime 的事件语义、失败恢复和复杂任务体验。

另外一个重点是项目推荐，目前 Starcat 的相似项目推荐，使用的是 SimRepo 提供的接口。这个开源项目本身做得不错，我在使用前也已经得到了作者的授权。

不过从长期来看，我还是希望把推荐能力慢慢收回到 Starcat 自己的生态里面，毕竟 Starcat 已经有用户收藏、知识库、标签、项目元数据等数据基础。如果后面能自己训练出一个更贴合 Starcat 使用场景的推荐模型，推荐结果应该会比通用方案更符合“我收藏了这些项目之后，接下来可能还会对什么感兴趣”这个问题。

还有前面提到的 Star History API， 其实 SimRepo 项目同样提供历史数据的接口， 但是限流太严格，所以还是前面的思路，自己做一个类似的服务出来。
这个接口后续肯定会开放出来，让其他开发者和项目也能使用 Star 历史数据。
不过目前还有不少数据质量、增量更新、容量和接口体验上的问题需要继续优化，所以暂时不会急着放出去。
我更希望先自己用一段时间，把 Starcat 里面的历史曲线继续迭代几个版本，等数据和服务都更稳定一些之后，再把它作为一个独立能力开放出来。

写在最后

这个产品我投入了太多的精力，以至于工作都不想找了（说的好像找的到一样），所以对这个产品寄托了太多的希望，这也是我作为 Java 技术栈的开发者首次尝试 macOS 原生开发，因为用了这么多年的 mac， 一直非常喜欢 macOS 的 UI 和操作, 也一直想有一个自己开发的 macOS 应用, 所以从我个人的需求出发开发了 Starcat 这款应用， 我想这也不会是我最后一款 macOS 产品， 目前在小本本上已经记录了几个玩儿 HomeLab 的痛点，我想可以做几个应用出来解决这些问题。

因为 Starcat 只支持 macOS 系统， 所以如果 Windows 用户也要想 GitHub Star 管理的话， 推荐使用 GithubStarsManager, 它也是一款非常优秀的 Star 管理工具, 而且是跨平台的.