我找到 30 多个有用 GitHub 仓库并不再遗忘（Claude + Obsidian 完整指南）

我发现了 30+ 个有用的 GitHub 仓库，并且不再跟丢它们（Claude + Obsidian，完整指南）July 20, 2026 · 10 min read · View source ↗ Claude Obsidian Automation 我 star 一个仓库，clone 它，让它跑通一半，然后去解决下一个问题。三个月后我又发现同一个文件夹，却想不起来当初为什么抓它、我到底有没有真的用过它、或者我是不是用不同的名字把同一类工具 clone 了两遍。到三十多个仓库的时候，这就不再是个玩笑，而是开始耗费真实时间了。 为什么每个仓库一份 README 不够？ README 告诉你作者为什么建它。它对"你为什么抓它、你是否真的在用、或者你是否已经有三四个在做完全相同工作的工具"只字不提。 那部分没人写下来，因为没人会为不是自己的仓库写。你 clone 了某个有用的东西，让它跑通一次，而"为什么"这个上下文，在你关掉终端的那一刻就消失了。把它乘以同一个文件夹里 30 个仓库，你就得到了一片你不敢清理的坟场，因为你不确定哪些是承重的、哪些是死重。 这些，任何单独一份 README 都显现不出来。它只会在"某个东西按时间表、横跨你收集的一切去读"时显现，而且不用你记得去检查。 你最终会得到什么？ 一个 vault，两个文件夹： found-tools-vault/ ├── notes/ # 你抓过的每个仓库一份 markdown 笔记 │ ├── some-scraper-tool.md │ ├── some-telegram-lib.md │ └── ... └── memory/ └── PORTFOLIO.md # 四轮跨仓库扫描写在这里 磁盘上的纯 markdown。在 Obsidian 里打开，或从终端 cat 出来。没有数据库，没有你自己读不了的东西。 怎么搭起来？ Mac 或 Linux 上： mkdir -p ~/found-tools-vault/notes ~/found-tools-vault/memory Windows PowerShell 上： New-Item -ItemType Directory -Force -Path "$HOME\found-tools-vault\notes","$HOME\found-tools-vault\memory" 把下面的 Loop 1 和 Loop 2 指向这个文件夹，搭建就完成了。之后的一切，都是你在里面让 Claude 去做的事。 技术栈：还是那三件东西，只是指向了别人的代码？ - vault。一个 Obsidian 文件夹，你 clone 过的每个工具一份笔记，外加一个放跨仓库扫描的文件夹。 - 来源。你 clone 文件夹里的每一个仓库，无论你天天用还是忘了它存在。 - 大脑。Claude，按任务分工。便宜模型读仓库和它的 README。Sonnet 做判断：这是不是你抓过的某个别的东西的重复，以及它到底值不值得占磁盘空间。 Loop 1：每个工具一份笔记，Claude 写的，不是你写的？ 在你在任何真实东西上跑这个之前，注意： - 绝不要让这个循环 push 代码、装依赖、或运行工具本身的任何东西。永远只读。 - why_i_grabbed_it（我为什么抓它）从你自己的笔记、提交记录、或你其他项目里的用法来填，而不是从仓库自己的 README 去猜。 - 如果你分不清自己是否在用某个工具，就把笔记写成 status: unclear，而不是跳过它。 TRIGGER：新仓库 clone 进文件夹，或每天一次 步骤： 1. 读仓库：README、package.json / requirements.txt、 最后一次上游提交日期，并检查它是否在你其他项目 的任何地方被引用（imports、配置、脚本） 2. 写或更新 notes/<repo-name>.md，包含： --- repo: what_it_does: why_i_grabbed_it: last_upstream_commit: referenced_in_my_projects: [] status: in-use | shelved | duplicate | unclear --- ## What it actually does ## Why I grabbed it ## Am I actually using it VERIFY：每个字段都填满，"referenced_in_my_projects"要 对照真实用法检查，而不是假设 STOP：验证通过，或重试 2 次，然后标记为人工审核 光这个就值得构建，哪怕没有 Loop 2。你第一次背靠背读这 30 份笔记时，一半会让你吃惊，要么是因为你忘了自己在用那个工具，要么是因为你从没用过。 一份生成的工具笔记，就放在它所描述的那个实际 clone 文件夹旁边。这是你本永远不会写下来的上下文。 Loop 1 跑过之后，30 个找到的仓库实际长什么样？ 一份 Claude 每次你 clone 新东西时都重新生成、直接从笔记里拉出来的清单： github.com/author/scrape-lite - in-use，最后上游提交 2 天前，引用自：feed-reader 项目 github.com/author/tg-bot-kit - in-use，最后上游提交 5 天前，引用自：我的两个 bot github.com/author/quick-scheduler - shelved，最后上游提交 41 天前，引用自：无 github.com/author/api-wrapper-x - in-use，最后上游提交 1 天前，引用自：一个项目 github.com/author/rss-to-json - duplicate，最后上游提交 3 天前，引用自：无（跟 scrape-lite 做一样的活） github.com/author/cheap-queue - in-use，最后上游提交 6 小时前，引用自：两个项目 github.com/author/webhook-relay-lib - shelved，最后上游提交 96 天前，引用自：无 github.com/author/simple-cache - in-use，最后上游提交 2 天前，引用自：三个项目 github.com/author/old-scraper - abandoned upstream，最后上游提交 340 天前，引用自：无 github.com/author/notify-me - unclear，最后上游提交 12 天前，引用自：不确定 github.com/author/token-utils - in-use，最后上游提交 1 天前，引用自：一个项目 github.com/author/quick-parser - duplicate，最后上游提交 8 天前，引用自：无（跟 rss-to-json 做一样的活） github.com/author/tiny-orm - shelved，最后上游提交 55 天前，引用自：无 github.com/author/rate-limiter - in-use，最后上游提交 3 天前，引用自：两个项目 github.com/author/config-loader - in-use，最后上游提交 4 天前，引用自：我大部分项目 github.com/author/legacy-fetch - abandoned upstream，最后上游提交 400+ 天前，引用自：无 github.com/author/env-check - in-use，最后上游提交 9 天前，引用自：一个项目 github.com/author/pretty-logs - shelved，最后上游提交 70 天前，引用自：无 github.com/author/proxy-list - unclear，最后上游提交 20 天前，引用自：不确定 github.com/author/backoff-lib - in-use，最后上游提交 6 天前，引用自：两个项目 github.com/author/dead-simple-db - shelved，最后上游提交 88 天前，引用自：无 github.com/author/quick-hash - in-use，最后上游提交 1 天前，引用自：一个项目 github.com/author/retry-wrapper - duplicate，最后上游提交 14 天前，引用自：无（跟 backoff-lib 做一样的活） github.com/author/format-time - in-use，最后上游提交 2 天前，引用自：我大部分项目 github.com/author/quick-mailer - shelved，最后上游提交 50 天前，引用自：无 github.com/author/health-check-lib - in-use，最后上游提交 5 天前，引用自：两个项目 github.com/author/dotenv-plus - in-use，最后上游提交 3 天前，引用自：我大部分项目 github.com/author/simple-lock - unclear，最后上游提交 30 天前，引用自：不确定 github.com/author/old-notify - abandoned upstream，最后上游提交 500+ 天前，引用自：无 github.com/author/tiny-scheduler - duplicate，最后上游提交 18 天前，引用自：无（跟 quick-scheduler 做一样的活） （上面的名字是占位符，示意清单的形态，不是真实工具） 三十行，手动读没什么。但已经足够让你注意到：你有三套独立的、做同一件事的重试逻辑库，而且有一个你真正依赖的仓库，已经一年多没有上游提交了。 全部 30 份笔记存在后的 vault 图谱视图：每个工具是一个节点，重复的和同用途的仓库被拉进可见的簇里。 Loop 2：那些只有在你收集了 30+ 工具后才起作用的扫描 单个工具的 README 告诉不了你这个。只有横跨你抓过的一切去读的东西能。 TRIGGER：每 12 小时 步骤： 扫描 1，真正被搁置的： 标记任何 status: in-use、但 30+ 天没有在你任何项目 里被引用的仓库，对照你自己的仓库交叉检查真实 用法，而不是假设 扫描 2，重复工具： 跨所有笔记比较"what it actually does"，把任何解决 同一问题的归到一组，靠匹配函数名或匹配用途来确认， 而不只是听起来相似的描述 扫描 3，上游风险： 标记任何你依赖、且最后上游提交距今 120+ 天的工具， 这样你就知道哪些依赖可能在你毫无预警的情况下变陈旧 扫描 4，诚实判读： 每个工具一行，判断它到底值不值占那份磁盘空间和 记着它存在的心智开销，不粉饰 VERIFY：每轮扫描写入 memory/PORTFOLIO.md，扫描 2 的分组要 有实际共享的函数或用途匹配来支撑 STOP：四轮扫描全部完成，或某轮失败并被记录， 绝不悄悄跳过 扫描 3 是真正改变你工作方式的那一轮。你不意识到自己依赖着三个"维护者一年前就沉寂了"的工具，直到它坐进一张摆在你面前的清单里。 一张从扫描 3 生成的风险表：你真正在用的工具，按上游项目上次动过的时间排序。 先试试手动版本？ 老规矩。任何你没亲手验证过的东西，都别去排程。 你会在一个循环里干活，直到任务达标。 任务： 读 [path] 里的每一个仓库文件夹。对每一个，记下它是做什么的、 你最初为什么抓它、你是否还在真正用它、以及上游项目距离 上次提交过了多久。然后跨所有仓库比较：找出重复项， 以及任何你依赖、但上游已沉寂的东西。 成功标准（严格，不放水）： - 每一个"重复"都要有实际匹配的函数或用途支撑， 不是听起来相似的描述 - 每一个"shelved"仓库都包含"距你上次在自己项目里 引用它的天数" - 上游风险基于真实提交日期，不是假设 循环协议，每轮重复： 1. 计划——说出单一下一步 2. 执行——产出或改进输出 3. 验证——在每条标准上打 1-10 分，残忍地诚实 4. 决定——如果每条标准都 8+，打印"FINAL"并停下 规则： - 每条标准到 8+ 之前，绝不说完成 - 别问我问题，做一个合理假设然后继续 开始。跑这个循环，直到 FINAL。 如果重复清单或上游风险清单让你吃惊，它就值得一个排程。如果它只是确认了你已经知道的，那先别自动化它。 真正起作用的顺序？ 先让 Loop 1 跑起来，直到每个 clone 的仓库都有一份真笔记，而不是占位符。 让它放一两个星期。从那时起，你抓的每个新工具都自动拿到一份笔记。 只有到这时，才打开 Loop 2。重复和上游风险扫描需要足够的笔记来真正碰撞。 排程放最后，在你手动看它干净跑过至少两次之后。 它花多少钱？ Loop 1 按每次新 clone 跑，所以它随你实际抓多少而扩展，而不是一个固定排程。大多数周也就是几次便宜模型调用。 Loop 2 一天两次，跨 30+ 份笔记。把扫描 1 和扫描 3 挪到便宜模型，它们是查表，不是判断。把扫描 2 和扫描 4 留在 Sonnet 上，因为认出真正的重复、给出诚实判读，都需要一个真能推理它比较内容的模型。这样分工，30 个仓库的集合一天两跑，成本低于你手动做一次同样审计所花的时间。 要记住的一件事？ README 告诉你一个工具做什么。这个告诉你，在你找到的 30 个工具里，哪些是你真正在用的，哪些在悄悄互相重复，哪些是你依赖着、却已经没人维护的。 价值从来不在任何单份工具笔记里。而在于这个事实：你收集的任何东西，都无法悄悄腐烂、悄悄重复、或悄悄失修，而不被某个东西写下来、放到你真正会看到的地方。 先构建 Loop 1。让它跑上两三周，再碰 Loop 2。重复和上游风险扫描在只有五个仓库时毫无用处。它们大约过了二十个才开始回本。 如果你想看更多这样的拆解，我每几天在 Telegram 和 X 发一篇。都免费。 X - https://x.com/gippp69 Telegram - https://t.me/GipArcAI Tags: # X # Claude # Obsidian # Automation # Guide # Sonnet Related articles Obsidian + Claude + n8n = $8,000+ per month in retainers. Every company has a wiki. A Google Drive folder nobody opens. A Notion workspace organized once in 2022. A Confluence page where processes die. Claude Obsidian Automation AI