做了一个带知识库 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](https://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/](https://starcat.ink/)
欢迎拍砖，特别是对 RAG 方向的反馈。
---
原文链接：[点击查看](https://www.v2ex.com/t/1229165)
### 起因
我自己的 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](https://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/](https://starcat.ink/)
欢迎拍砖，特别是对 RAG 方向的反馈。
---
原文链接：[点击查看](https://www.v2ex.com/t/1229165)
评论
暂无评论。