我收藏一个仓库，克隆下来，让它运行到一半能工作，然后就转向下一个问题。三个月后，我再次找到同一个文件夹，却想不起来当初为什么拿它，我到底有没有真正用过它，或者我是不是用不同的名字克隆了两次同类型的工具。当仓库数量超过三十个，这就从玩笑变成了实实在在的时间成本。
为什么每个仓库一个 README 不够？
README 告诉你作者为什么构建它。它完全没提你为什么要拿它，你是否真的在用，或者你手头是否已经有三个其他工具在做完全相同的事情。
这部分没人会写下来，因为没人会为不属于自己的仓库写这些。你克隆了一个有用的东西，让它运行过一次，然后关于原因的背景信息在你关闭终端的那一刻就消失了。把这个场景乘以三十个躺在同一个文件夹里的仓库，你就得到了一个你不敢清理的"坟场"，因为你不确定哪个是承重墙，哪个是死重。
这些信息不会出现在任何一个单独的 README 里。它只会在某个东西能够跨你收集的所有内容进行读取时才会显现，而且是以定期的方式，不需要你记得去检查。
你最终会得到什么？
一个仓库，两个文件夹：
1found-tools-vault/2├── notes/ # 你拿的每个仓库对应一个 Markdown 笔记3│ ├── some-scraper-tool.md4│ ├── some-telegram-lib.md5│ └── ...6└── memory/7 └── PORTFOLIO.md # 四个跨仓库扫描结果写到这里
纯 Markdown 文件存在磁盘上。在 Obsidian 里打开，或者在终端里用 cat 命令查看。没有数据库，没有任何你自己读不了的东西。
如何设置？
在 Mac 或 Linux 上：
1mkdir -p ~/found-tools-vault/notes ~/found-tools-vault/memory
在 Windows 上，PowerShell：
1New-Item -ItemType Directory -Force -Path "$HOME\found-tools-vault\notes","$HOME\found-tools-vault\memory"
将下面的循环 1 和循环 2 指向这个文件夹，设置就完成了。从这里开始，剩下的就是告诉 Claude 在这个文件夹里做什么。
这套东西：是不是同样的三个部分，只是指向了别人的代码？
仓库（vault）。 一个 Obsidian 文件夹，你克隆的每个工具一个笔记，再加上一个用于跨仓库扫描的文件夹。
数据源（source）。 你克隆文件夹里的每一个仓库，无论你每天用还是已经忘了它的存在。
大脑（brain）。 Claude，按任务分工。便宜的模型负责读取仓库及其 README。Sonnet 负责做判断：这个是不是你手头已经有的另一个工具的重复品，以及它是否真的值得占用磁盘空间。
循环 1：每个工具一个笔记，由 Claude 而不是你编写？
重要提示，在你对任何真实数据运行之前：
- 永远不要让这个循环推送代码、安装依赖项或运行工具本身的任何东西。始终只读。
why_i_grabbed_it字段的内容来自你自己的笔记、提交记录或你在自己项目中的其他使用情况，而不是从仓库自己的 README 中猜测。- 如果你无法判断自己是否在使用一个工具，先写下笔记，状态设为
unclear，而不是跳过它。
1触发器： 新仓库克隆到文件夹时，或每天一次2步骤：3 1. 读取仓库：README、package.json / requirements.txt、上游4 最后一次提交日期，并检查它是否在你其他项目中被引用过5 （导入、配置文件、脚本）6 2. 编写或更新 notes/<repo-name>.md，内容包括：7 ---8 repo:9 what_it_does:10 why_i_grabbed_it:11 last_upstream_commit:12 referenced_in_my_projects: []13 status: in-use | shelved | duplicate | unclear14 ---15 ## 它实际做什么16 ## 我为什么拿它17 ## 我是否真的在用18验证： 每个字段都已填写，"referenced_in_my_projects" 已根据19 实际使用情况进行检查，而非假设20停止条件：验证通过，或重试 2 次后标记为需要人工审核
即使没有循环 2，仅仅构建这个循环本身就值得。当你第一次连续阅读 30 个这样的笔记时，其中一半会让你感到惊讶，要么是因为你忘了自己在用这个工具，要么是因为你从来就没用过。
一个自动生成的工具笔记，紧挨着它所描述的、你实际克隆的文件夹。这就是你原本永远不会写下来的背景信息。
一旦循环 1 运行完毕，30 个已发现的仓库看起来是什么样子？
一个每次你克隆新东西时 Claude 都会重新生成的列表，直接取自笔记：
- github.com/author/scrape-lite - 正在使用，上次上游提交 2 天前，项目引用：feed-reader 项目
- github.com/author/tg-bot-kit - 正在使用，上次上游提交 5 天前，项目引用：我的两个机器人
- github.com/author/quick-scheduler - 已搁置，上次上游提交 41 天前，项目引用：无
- github.com/author/api-wrapper-x - 正在使用，上次上游提交 1 天前，项目引用：一个项目
- github.com/author/rss-to-json - 重复，上次上游提交 3 天前，项目引用：无（与 scrape-lite 功能相同）
- github.com/author/cheap-queue - 正在使用，上次上游提交 6 小时前，项目引用：两个项目
- github.com/author/webhook-relay-lib - 已搁置，上次上游提交 96 天前，项目引用：无
- github.com/author/simple-cache - 正在使用，上次上游提交 2 天前，项目引用：三个项目
- github.com/author/old-scraper - 上游已废弃，上次上游提交 340 天前，项目引用：无
- github.com/author/notify-me - 不明确，上次上游提交 12 天前，项目引用：不确定
- github.com/author/token-utils - 正在使用，上次上游提交 1 天前，项目引用：一个项目
- github.com/author/quick-parser - 重复，上次上游提交 8 天前，项目引用：无（与 rss-to-json 功能相同）
- github.com/author/tiny-orm - 已搁置，上次上游提交 55 天前，项目引用：无
- github.com/author/rate-limiter - 正在使用，上次上游提交 3 天前，项目引用：两个项目
- github.com/author/config-loader - 正在使用，上次上游提交 4 天前，项目引用：我的大多数项目
- github.com/author/legacy-fetch - 上游已废弃，上次上游提交 400+ 天前，项目引用：无
- github.com/author/env-check - 正在使用，上次上游提交 9 天前，项目引用：一个项目
- github.com/author/pretty-logs - 已搁置，上次上游提交 70 天前，项目引用：无
- github.com/author/proxy-list - 不明确，上次上游提交 20 天前，项目引用：不确定
- github.com/author/backoff-lib - 正在使用，上次上游提交 6 天前，项目引用：两个项目
- github.com/author/dead-simple-db - 已搁置，上次上游提交 88 天前，项目引用：无
- github.com/author/quick-hash - 正在使用，上次上游提交 1 天前，项目引用：一个项目
- github.com/author/retry-wrapper - 重复，上次上游提交 14 天前，项目引用：无（与 backoff-lib 功能相同）
- github.com/author/format-time - 正在使用，上次上游提交 2 天前，项目引用：我的大多数项目
- github.com/author/quick-mailer - 已搁置，上次上游提交 50 天前，项目引用：无
- github.com/author/health-check-lib - 正在使用，上次上游提交 5 天前，项目引用：两个项目
- github.com/author/dotenv-plus - 正在使用，上次上游提交 3 天前，项目引用：我的大多数项目
- github.com/author/simple-lock - 不明确，上次上游提交 30 天前，项目引用：不确定
- github.com/author/old-notify - 上游已废弃，上次上游提交 500+ 天前，项目引用：无
- github.com/author/tiny-scheduler - 重复，上次上游提交 18 天前，项目引用：无（与 quick-scheduler 功能相同）
（上面的名称是占位符，用来说明列表的形态，而非实际工具）
三十行手动阅读并不费事。但这也足以让你注意到，你手头有三个各自独立的重试逻辑库在做同样的事情，而且你实际依赖的一个仓库已经超过一年没有上游提交了。
一旦所有 30 个笔记都存在，仓库的图谱视图：每个工具都是一个节点，重复的和功能相似的仓库聚集成可见的群组。
循环 2：只有当你收集了 30 个以上的工具后才能发挥作用的扫描？
一个单独工具的 README 无法告诉你这些。只有能够跨你收集的所有内容进行读取的东西才能做到。
1触发器： 每 12 小时2步骤：3 扫描 1，实际已搁置：4 标记任何状态为 "in-use" 但在过去 30 多天内未在你任何项目5 中被引用的仓库，对照你自己的仓库进行实际使用情况交叉验证，6 而不是基于假设7 扫描 2，重复工具：8 比较所有笔记中 "what it actually does" 的内容，将任何解决9 相同问题的仓库分组，通过匹配的函数名或匹配的目的确认，而10 不仅仅是听起来相似的描述11 扫描 3，上游风险：12 标记你依赖的、上次上游提交距今超过 120 天的任何工具，这样13 你就知道哪些依赖项可能在毫无预警的情况下变得过时14 扫描 4，诚实评估：15 每个工具一行，说明它是否值得占用磁盘空间和记住它存在的心16 智负担，不拐弯抹角17验证： 每次扫描结果写入 memory/PORTFOLIO.md，扫描 2 的分组18 必须基于实际共享的函数或目的匹配19停止条件：所有四次扫描完成，或某次扫描失败并被记录，绝不静默跳过
扫描 3 是真正能改变你工作方式的那个。你直到一份列表摆在你面前时，才会意识到自己正在依赖三个维护者已经一年没有动静的工具。
从扫描 3 生成的风险表：你实际正在使用的工具，按它们上游项目上次更新距今的时间排序。
先手动试试？
规则不变。没有亲手验证过的东西，不要安排自动化。
1你将在一个循环中工作，直到任务达到标准。23任务：4读取 [path] 中的每个仓库文件夹。对每个文件夹，记录它的功能、5你最初为什么拿它、你是否还在实际使用它，以及上游项目上次提6交距今多久。然后跨所有仓库进行比较：找出重复项和你依赖的、7但上游已经沉寂的仓库。89成功标准（严格，无宽松通过）：10- 每个 "duplicate" 都基于实际匹配的函数或目的，而非听起来相似11 的描述12- 每个 "shelved" 仓库都包含你最后一次在你自己的项目中引用它13 距今的天数14- 上游风险基于真实的提交日期，而非假设1516循环协议，每轮重复：171. 计划 - 说明下一步要做什么182. 执行 - 生成或改进输出193. 验证 - 对每个标准打分 1-10 分，要极其诚实204. 决定 - 如果每个标准都达到 8 分以上，打印 "FINAL" 并停止2122规则：23- 在每个标准都达到 8 分以上之前，永远不要声称任务完成24- 不要问我问题，做出合理的假设并继续2526开始。运行循环直到 FINAL。
如果重复列表或上游风险列表让你感到惊讶，那么它就值得安排自动化。如果它只是确认了你已经知道的事情，那就先不要自动化。
真正有效的顺序？
先让循环 1 运行起来，直到每个克隆的仓库都有一个真正的笔记，而不是一个占位符。
让它运行一两周。从那时起，你拿的每个新工具都会自动生成一个笔记。
然后才开启循环 2。重复项和上游风险扫描需要足够多的笔记才能产生有意义的碰撞。
最后再安排自动化调度，在你亲眼看着它至少手动干净地运行两次之后。
成本是多少？
循环 1 每次新克隆时运行，因此它与你实际拿取的数量成正比，而不是按固定时间表运行。大多数情况下，每周只有几次便宜的模型调用。
循环 2 每天在 30 多个笔记上运行两次。将扫描 1 和扫描 3 移到便宜的模型上，它们只是查找，不是判断。将扫描 2 和扫描 4 保留在 Sonnet 上，因为发现真正的重复项和给出诚实的评估都需要一个能够真正推理它所比较内容的模型。这样拆分后，在一个 30 个仓库的集合上每天运行两次，成本低于你手动做一次同样的审计所花费的时间。
需要记住的一件事？
README 告诉你一个工具能做什么。而这套方法告诉你，你找到的 30 个工具中，哪些是你真正在用的，哪些正在悄悄地互相重复，以及哪些你依赖的工具已经没有人维护了。
价值从来不在任何一个单独的工具笔记里。它在于这样一个事实：你收集的任何东西都不能悄悄地腐烂、悄悄地重复、或者悄悄地变得无人维护，而没有任何东西会把这一点记录下来，让你真正看到。
先构建循环 1。让它运行两三周，然后再碰循环 2。重复项和上游风险扫描在只有五个仓库时毫无用处。它们开始体现价值是在仓库数量超过二十个之后。
如果你想要更多类似的深度解析，我每隔几天会在 Telegram 和 X 上发布一次。两者都是免费的。
Telegram - https://t.me/GipArcAI
