做了一个带知识库 RAG 问答的 macOS GitHub Stars 工具，想听听大家的建议

最近一直在做一个 macOS 工具，叫 Starcat 。从最初简单的 stars 同步到现在加入知识库 RAG 问答，想分享一下进展和设计思路，听听大家的反馈。

起因

我自己的 GitHub Stars 已经一千八百多个了。刚开始 star 是收藏，后来变成「以后再看」，再后来就是精神负债了。最近一次触发我的是：想找一个以前 star 过的 Swift 剪贴板管理工具，记不清名字，在 GitHub Stars 页面翻了快 20 分钟。找到了，但这个过程让我觉得——GitHub 提供了「收藏」，但没提供「找回」。

所以我做了 Starcat ，一个 macOS 原生应用。最开始做了最基础的事：把 stars 同步到本地，三栏管理，支持标签、笔记、阅读状态、全文搜索、AI 摘要。

最近在做的：知识库 RAG 问答

但最近最花精力的功能是知识库 RAG。这个东西的动机很简单：有时候你需要的不是「搜到一个 repo 」，而是「回答一个问题」。

举个例子。我想知道「我收藏的 SwiftUI 项目里，哪些用了 Core Data 做本地存储？」。这不是一个搜索词能表达的问题。GitHub 搜索帮不了我，全文搜索也帮不了我——因为这个问题需要理解「用了 Core Data 做本地存储」这个语义，然后在我本地几百个 repo 的 README 、笔记、摘要里找到匹配的内容，最后综合成答案。

RAG 工作台做的事情就是：

1. 理解你的自然语言问题。


2. 从你的知识库（你主动筛选入库的 repo ，不是全部 stars ）里做混合检索——本地 FTS5 全文 + 本地 embedding 向量。


3. 找到相关的 README 段落、笔记片段、AI 摘要。


4. 把这些上下文和你的问题一起发给 LLM ，生成带引用的回答。


5. 每个结论都链接回具体 repo 和段落，你可以点进去验证。

为什么不直接用全部 stars ？

知识库和 stars 是两个概念。stars 是「我看过觉得有意思」，知识库是「我研究过、有价值、想持续跟踪」。RAG 在知识库范围内工作，用户才知道回答的来源是自己筛选过的数据。这会比直接在全量 stars 上检索更可信。

为什么放本地？

整个检索链路（ FTS5 + 向量扫描）都在本地完成。只有最后一步 LLM 生成需要调 AI provider 。1.8 万个本地向量的相似度计算用了 vDSP 加速，实测比纯 Swift 快了约 23 倍。即使没有网络，本地检索也能跑完——只是生成那一步需要网络（或者你可以接 Ollama 本地模型）。

AI 还是不能自动写

这个原则从第一版到现在都没变。RAG 是只读的，不自动写标签、不自动写笔记、不自动改 star 状态。标签建议仍然需要用户确认，笔记草稿仍然需要用户手动保存。我觉得对于一个本地知识库来说，这个边界比「自动化」更重要。

关于 AI 工具链

除了人用，Starcat 也做了本地 MCP Service ，外部 Agent （ Claude / Codex 等）可以查你的 stars 和知识库；另有跨平台 starcat-cli 做命令行桥接。项目在 github.com/starcat-app，反馈可提到 starcat-app/starcat-pro。

想听听大家的想法

几个我最近在纠结的问题，想听听社区的意见：

1. 知识库 vs stars 的 RAG 边界：现在默认只检索知识库。你觉得提供一个「搜索全部 stars 」的可选项有用吗？还是保持现在的严格边界更好？


2. RAG 回答的长短：现在默认输出 200-500 字的摘要性回答带引用。你更倾向于短的（直接给结论+来源），还是长的（详细分析+对比+风险提示）？


3. 你们现在怎么管理 GitHub Stars ？ 是不是和我一样，star 了就不管了？有没有什么自己摸索出来的土办法？


4. 对「 Agent 替你写标签/笔记」这个方向怎么看？ 我觉得风险大于收益，但也许有人觉得自动化的好处超过风险？

官网： https://starcat.ink

欢迎拍砖，特别是对 RAG 方向的反馈。