每次换一台设备、换一个浏览器，甚至只是重装一次系统，最让人抓狂的不是重新登录各种账号，而是那排用了三年的书签栏突然空了——里面躺着的才是你真正的"信息高速公路匝道口"。这些年我陆陆续续整理过好几版搜索入口和分类目录入口清单，从最早手工敲在记事本里，到后来做成静态页挂在本地，再到现在用一个带巡检脚本的小仓库维护。这件事看起来只是"收藏几个网址"，实际做下来会发现它牵扯到检索对象分类、入口质量评估、失效治理、数据结构设计一整套东西。这篇就把我踩过的路完整摊开讲：搜索引擎和分类目录入口到底该怎么分类、怎么选、怎么搭、怎么养，适合刚想整理自己入口页的新手，也适合已经有一堆书签但越用越乱的老手参考。

1. 搜索入口清单为什么值得单独整理，而不是丢进收藏夹

大多数人对待搜索入口的方式是"用到就存"，收藏夹里塞了几百条，最后真正会点的还是那两三个。问题不在于懒，而在于收藏这个动作本身缺少结构：它只记录了"我某天点过这个网址"，没记录"它在什么场景下比别的入口强"。当清单里没有场景标签，大脑在需要检索时就没法从几百条里快速捞出一条，于是退回到最熟悉的那一个，其余全部沉底。

1.1 单一搜索框的三个隐性成本

习惯性只用一个搜索框，代价比想象中大。第一个成本是覆盖盲区：通用检索擅长抓取公开网页，但对结构化数据的覆盖很弱，比如你要找一份特定的数据集、某个开源库的历史版本、某个标准文档的编号，通用检索返回的往往是一堆二手转述的博客，而不是原始出处。第二个成本是结果污染：同一个关键词，不同入口的排序逻辑完全不同，商业化的入口会把推广位和内容位混在一起，你没有对照样本时就很难判断自己看到的是不是最优解。第三个成本最隐蔽，是检索语言的退化：只用过一个入口的人，通常只会"输入一句话然后翻页"，不会用限定符把范围压窄，长期下来检索效率停留在很低的水平。

我做过一个很粗糙的自测：同一个技术问题，用通用检索连续翻三页找到答案，平均要花四到六分钟；而如果先判断这个问题属于"代码实现"还是"标准定义"，直接跳到对应形态的库，通常一到两次查询就能命中。差距不在网速，在于入口和检索对象的匹配度。

1.2 分类目录在今天依然有它不可替代的位置

很多人以为人工编辑的分类目录已经被通用检索淘汰了。从流量上看确实如此，但从"发现"这个动作上看，目录的价值反而更清晰了。通用检索是你已知要什么，它帮你找到；分类目录是你只知道大致方向，它帮你圈定范围。前者是精确制导，后者是地图。

举个我自己的例子：有一次需要找一批做时序数据处理的开源工具，但我连该用什么关键词都不确定。直接在通用检索里搜"时序数据处理工具"，出来的全是营销页和测评合集。后来我转到一个人工维护的开源项目目录，按"数据存储—时序"这个分类往下点，一页里列了十几个项目，还带一句编辑写的说明，五分钟就建立起了这个领域的全景。这种"从分类结构反推关键词"的路径，是通用检索给不了的。

所以我的结论是：搜索入口和分类目录入口不是替代关系，而是两种不同的信息获取模式，前者解决"精确查找"，后者解决"范围探索"。一份完整的入口清单，两类都得有，而且要在清单结构上区分开。

1.3 清单的组织轴应该是"找什么"，而不是"哪家更强"

这是我在整理第三版清单时才想明白的事。前两版我都是按"搜索引擎""工具站""导航站"这样分，结果用起来极不顺——因为我在实际检索时，脑子里想的是"我要找一篇论文""我要找一段示例代码""我要找一个商品的真实成交价"，而不是"我要用一个搜索引擎"。分类轴和调用场景对不上，清单就永远只是个摆设。

改成按检索对象形态分类之后，清单的命中率明显上升。现在的顶层分类大概是：通用网页、代码与仓库、学术与文献、标准与规范、图像与素材、商品与价格、地理与时空、问答与社区、档案与历史。每一类下面挂三到八个入口，宁缺毋滥。这个结构还有一个好处：它天然地告诉你哪些领域你还没有像样的入口，缺口一目了然。

2. 按检索对象的形态重新给搜索引擎分一次类

市面上的搜索引擎多到数不清，但如果按"它索引的到底是什么东西"来切，其实就那么几大类。想清楚这个分类，你才能在需要的时候知道自己缺哪一块，而不是盲目地往清单里加网址。

2.1 通用检索与元检索的分工

通用检索索引的是公开网页，特点是覆盖面广、更新快、但结果质量方差极大。它的最佳使用场景是你已经能写出较精确的查询式，比如带限定符、带专有名词、带时间范围的查询。反过来，如果你的查询很模糊，通用检索会把你带进一堆内容农场。

元检索（聚合检索）不自己建索引，而是把查询同时发给多个下游检索服务，再把结果合并排序。它的价值在于对抗单一排序逻辑的偏见：同一组关键词，不同下游服务的排序差异很大，聚合之后你能看到更分散的结果面。代价是响应慢，通常要等好几秒，而且各家结果的去重和排序融合做得好的并不多。我的用法是把它当成"抽样工具"——当我对某个陌生领域完全没有概念、连该用什么关键词都不确定时，用元检索跑一轮，看看返回结果的标题里反复出现哪些词，再用这些词回到通用检索里精查。

这里有个容易忽略的细节：元检索的结果通常不带完整的摘要，点进去还得二次加载。所以它适合做关键词发现，不适合直接拿来当最终答案。

2.2 垂直检索的六条主线

垂直检索是入口清单里最该下功夫的部分，因为它直接决定了你在专业场景下的效率。我把它拆成六条主线，每条下面给出选型关注点。

这张表我在自己清单里就是顶层目录，每次觉得"找不到东西"时，先对照一遍看是不是用错了形态。十次里有六七次是形态用错了，而不是入口不够多。

代码检索这条线值得多说两句。很多人查技术问题的路径是"通用检索 → 点进某篇博客"，但博客的时效性极差，一个三年前的写法很可能早就废弃了。更可靠的路径是直接进代码检索或包管理器的检索入口，看当前版本的实际实现和最近的提交记录。代码是不会说谎的，博客会。我现在遇到 API 用法不确定的情况，第一反应是去代码检索里搜函数名，看别人怎么调的，而不是搜"XX 怎么用"。

学术检索这条线的关键是引文追溯。单纯的全文检索只能找到提到关键词的论文，而引文关系能让你从一篇已知的好论文出发，往前找它引用的基础工作，往后找引用它的后续研究。这个"双向爬"的能力，是学术型入口和通用检索最本质的区别。

2.3 三类被严重低估的入口：文档型、问答型、档案型

除了上面六条主线，还有三类入口在大多数人的清单里是缺失的，但实际用起来价值很高。

文档型检索指的是专门索引文档正文的服务，比如各类文档分享平台、说明书库、手册库。它的强项是能搜到 PDF、演示文稿、表格里的正文内容，这些内容通用检索往往索引不全。我找设备说明书、找某个软件的官方手册 PDF，基本都走这条路。

问答型检索指的是结构化的问答社区。它的价值不在于答案本身（答案经常过时），而在于问题描述——同一个报错，别人是怎么描述它的，用了什么术语。找到准确的术语，再回到通用检索或代码检索，成功率会高很多。我经常把问答社区当成"术语词典"来用。

档案型检索指的是历史网页、历史版本、历史数据的存档服务。当你需要确认"某个页面在去年是什么样子""某个规范在改版前怎么写的"，只有档案型入口能给你答案。这类入口在清单里出现频率极低，但一旦用上就是救命的。

3. 分类目录入口的三种活法与收录判断标准

分类目录和搜索引擎的维护成本完全不是一个量级：搜索引擎靠爬虫自动扩张，目录靠人一条条挑。这决定了目录的数量天然稀少，也决定了它的质量上限更高。但"人工编辑"这四个字不等于"可信"，判断一个目录还值不值得放进清单，得有一套自己的标准。

3.1 通用型人工目录的筛选价值在哪里

通用型人工目录的特点是分类颗粒度适中、收录标准公开、每条目带一句人工撰写的说明。它最大的价值不是"帮你找到某个具体站点"，而是帮你判断一个站点属于什么性质。同样是一个看起来很像官方的页面，人工目录里如果把它归在"个人博客"分类下，你立刻就知道该用什么样的信任级别去读它。这种"性质标注"是自动索引给不了的。

使用这类目录有个技巧：不要顺着分类一层层点到最深处，那样效率很低。更有效的做法是用目录的站内检索定位到一个条目，然后看它所在的分类路径——路径本身就是信息，它告诉你这个条目在整个知识地图上的位置，以及它旁边还有哪些同类条目。我经常靠这个方法一次性发现五六个相关的站点。

3.2 行业目录与开源项目目录的正确打开方式

行业目录的颗粒度比通用目录细得多，通常按细分领域组织，条目下会标注成立年份、主营方向、是否活跃等信息。开源项目目录则更进一步，会标注许可证类型、最近提交时间、依赖数量这些硬指标。

这两类目录的正确用法是做初筛，而不是做决策。目录里的"活跃"标注往往滞后几个月，许可证标注也可能因为项目改协议而过时。我的做法是：用目录快速圈出五到十个候选，然后逐个到项目自己的仓库页面去核实最近提交时间、开放议题数量、发版节奏。目录负责"广度"，核实负责"深度"，两步都不能省。

开源项目目录还有一个隐藏用法：顺着"相似项目"找替代品。当你要用某个库但发现它维护停滞时，目录里的同类推荐往往能直接给出仍在活跃维护的替代方案，比自己在通用检索里翻要快得多。

3.3 判断一个目录还值不值得留的四个信号

清单维护久了，最头疼的是目录类入口的衰减。它们不像搜索引擎那样会挂掉，而是慢慢变成"活着但没内容"的状态。我总结了四个信号，命中两个以上就该考虑移出主清单：

• 死链率明显上升：随机抽十条，点开有三条以上打不开或者跳转到无关页面，说明维护基本停摆。
• 收录标准不再公开：早期页面会写清楚"什么样的站点会被收录"，后来这页悄悄消失，只剩下一个提交表单，通常意味着开始接商业排序。
• 分类结构长期不调整：一个领域三年没有新增子分类，说明编辑已经不看了。
• 条目说明退化成关键词堆砌：从"这个站点提供什么、适合谁用"变成一串关键词，说明是批量生成的，人工价值已经没了。

这四条我大概每季度过一遍，每次都会清掉一两个。清掉之后不用急着找替代品，往往过一阵子你会发现那个位置本来就不该有东西——入口少了，检索反而更快。

4. 从零搭一个自己用得顺手的入口页

讲完分类和选型，落到动手。这部分是整篇里最"可抄"的一段，我会把形态选型、数据结构、页面骨架、批量处理脚本都给出来，照着改就能用。

4.1 形态选型的四种方案与适用人群

我自己走的是第三条路：一个纯静态的 HTML 文件，放在本地，用 Git 管理历史，需要换设备时直接拷过去或者同步目录。选它的理由很实在——不依赖任何账号体系，不会因为某个服务下线而丢失数据，而且改起来就是改一个文本文件。

如果你只是想让入口不被弄丢，书签栏加导出备份完全够用。但如果你像我一样，入口清单本身就是一个持续迭代的东西（要加备注、要标验证日期、要记录失效原因），那静态页或者结构化文本是更合适的载体。

4.2 一条入口记录应该包含哪些字段

这是整个方案的地基。字段设计得好，后面加功能都是顺水推舟；设计得差，用半年就得推倒重来。我现在的字段是这样：

{ "id": "code-003", "name": "示例代码检索入口", "category": "代码与仓库", "object": "源码文件", "url": "https://example.invalid/search", "alias": ["代码检索"], "scene": "查某个函数在真实项目里的调用方式", "auth": false, "added": "2024-03-11", "verified": "2024-11-02", "status": "ok", "note": "支持按语言和许可证过滤，结果页可直接跳转历史版本" }

几个字段值得单独解释一下为什么要加：

• scene（适用场景）：这是最有价值的一个字段。它逼着你在收录时就写清楚"什么时候该用它"，而不是"这个站挺好的"。写不出来就说明你其实不需要它。
• auth（是否需要登录）：很多垂直检索服务不登录只能看个位数结果，提前标注能省掉很多次"点进去发现看不了"的挫败。
• verified（最近验证日期）：这是失效治理的基础，没有它你根本不知道哪些入口已经半年没碰过了。
• status：我只有三个值——ok、slow、dead。不要设计太细，细了就不会维护。
• alias（别名）：备用记录，当主入口调整结构时，用来快速切换，同时也能当作搜索时的关键词提示。

字段数量控制在十二个以内，超了就一定会有字段长期空着，空着就等于不存在。

4.3 一个可以直接改的静态入口页骨架

下面这个页面结构我用了很久，核心思路是数据与视图分离：所有入口写在一个数组里，渲染逻辑单独一段，加条目就是往数组里加一条对象，不用碰 HTML。

<!doctype html> <html lang="zh-CN"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width,initial-scale=1"> <title>我的检索入口</title> <style> body{font:15px/1.7 system-ui,sans-serif;max-width:960px;margin:40px auto;padding:0 16px;color:#222} h2{font-size:16px;margin:28px 0 10px;padding-bottom:6px;border-bottom:1px solid #ddd} .item{display:flex;gap:12px;padding:6px 0;align-items:baseline} .item a{color:#0a58ca;text-decoration:none;min-width:200px} .item span{color:#666;font-size:13px} .dead a{color:#999;text-decoration:line-through} #q{width:100%;padding:8px;margin-bottom:20px;border:1px solid #ccc;border-radius:4px} </style> </head> <body> <input id="q" placeholder="输入关键词，按名称、场景、分类过滤"> <div id="app"></div> <script> const DATA = [ {n:"通用检索A", c:"通用网页", u:"https://example.invalid/a", s:"写得出精确查询式时使用", st:"ok"}, {n:"聚合检索B", c:"通用网页", u:"https://example.invalid/b", s:"陌生领域做关键词发现", st:"ok"}, {n:"代码检索C", c:"代码与仓库", u:"https://example.invalid/c", s:"查函数真实调用方式", st:"ok"}, {n:"学术索引D", c:"学术与文献", u:"https://example.invalid/d", s:"做引文双向追溯", st:"slow"} ]; function render(kw=""){ const k = kw.trim().toLowerCase(); const groups = {}; DATA.filter(d => d.st==="ok" || d.st==="slow") .filter(d => !k || (d.n+d.c+d.s).toLowerCase().includes(k)) .forEach(d => (groups[d.c] = groups[d.c] || []).push(d)); document.getElementById("app").innerHTML = Object.keys(groups).map(cat => `<h2>${cat}</h2>` + groups[cat].map(d => `<div class="item ${d.st==='slow'?'dead':''}"> <a href="${d.u}" target="_blank" rel="noopener">${d.n}</a> <span>${d.s}</span> </div>`).join("") ).join(""); } document.getElementById("q").addEventListener("input", e => render(e.target.value)); render(); </script> </body> </html>

这个骨架有两个我特意做的设计。第一，把"场景"和"名称"并排显示，而不是只显示名称，因为场景才是让人决定点不点的那句话。第二，过滤框只匹配名称、分类、场景三个字段，不匹配网址，因为网址里的字符对人不构成记忆线索。

如果入口超过一百条，可以再加一层：给每个分类配一个锚点导航，页面顶部放一行分类跳转链接，滚动时保持吸顶。这一步在手机上收益特别明显。

4.4 批量导入与去重的小脚本

从浏览器导出的书签文件是 Netscape 格式的 HTML，格式很规整，用几十行脚本就能解析成结构化数据，再和现有清单做合并去重。我一般按域名去重，因为同域名下的多个页面通常指同一个入口。

import re, json, pathlib from urllib.parse import urlparse def parse_bookmarks(path): html = pathlib.Path(path).read_text(encoding="utf-8", errors="ignore") items = [] for m in re.finditer(r'<A[^>]*HREF="([^"]+)"[^>]*>(.*?)</A>', html, re.I | re.S): url, name = m.group(1).strip(), re.sub(r"<[^>]+>", "", m.group(2)).strip() host = urlparse(url).netloc.lower() if host and not url.startswith(("javascript:", "place:")): items.append({"name": name, "url": url, "host": host}) return items def merge(existing_path, bookmark_path): existing = json.loads(pathlib.Path(existing_path).read_text(encoding="utf-8")) seen = {urlparse(e["url"]).netloc.lower() for e in existing} new = [b for b in parse_bookmarks(bookmark_path) if b["host"] not in seen] existing.extend({**b, "category": "待归类", "scene": "", "status": "ok"} for b in new) pathlib.Path(existing_path).write_text( json.dumps(existing, ensure_ascii=False, indent=2), encoding="utf-8") print(f"新增 {len(new)} 条，当前共 {len(existing)} 条") if __name__ == "__main__": merge("entrances.json", "bookmarks.html")

这段脚本的重点不是技术含量，而是把"待归类"作为默认状态。新导入的条目一律先落进"待归类"，逼着自己每周花十分钟给它们补上场景说明，补不上就直接删掉。这个机制能有效阻止清单无限膨胀——没有场景的入口等于没有入口。

5. 入口清单的失效治理与长期维护

搭起来只是开始，真正决定这份清单能不能用三年以上的，是维护流程。我见过太多人第一周兴致勃勃整理了二百条，第三个月开始一半点不开，第六个月直接放弃。失效治理这件事，靠意志力不如靠流程。

5.1 入口失效的几种典型原因

先搞清楚入口为什么会失效，才能有针对性地处理。我遇到过的原因大概是这几类：

站点结构调整是最常见的。原来的检索页从一级域名挪到了子目录，或者从独立页面变成了嵌入某个主站的模块，老链接直接跳首页或者返回错误。这类情况其实站点还活着，只是路径变了，处理方式是找到新的检索页地址，更新url字段，status保持ok。

服务下线或并入其他产品，这类是真正的死亡。判断方法很简单：访问根域看看是否还能正常打开，如果整站跳转到另一个产品的落地页，基本可以确认。这类直接标记dead，同时看看有没有同类替代，在note里写一句。

要求登录或地区限制，这类不是失效，是"门槛变了"。有些垂直检索服务早期完全开放，后来改成必须注册才能看完整结果。发现这种情况，把auth改成true，如果门槛高到影响使用，就在note里注明，日常使用时自然会降低它的优先级。

被大量低质内容占据，这类最隐蔽，因为链接好好的、页面也能打开，但检索质量已经在往下掉。判断方法是用一组固定测试查询跑一遍，看看首屏结果是原始出处还是转述合集。这个只能靠人判断，脚本帮不上忙。

5.2 一个轻量的巡检流程

巡检不要搞复杂，复杂了就不会执行。我的做法是每月跑一次脚本做机器能做的部分，再花二十分钟做人工判断。

import json, pathlib, datetime, urllib.request, urllib.error def probe(url, timeout=8): req = urllib.request.Request(url, method="HEAD", headers={"User-Agent": "Mozilla/5.0 (entrance-check)"}) try: with urllib.request.urlopen(req, timeout=timeout) as r: return r.status except urllib.error.HTTPError as e: return e.code except Exception: return 0 p = pathlib.Path("entrances.json") data = json.loads(p.read_text(encoding="utf-8")) today = datetime.date.today().isoformat() for item in data: if item.get("status") == "dead": continue code = probe(item["url"]) if code == 0 or code >= 500: item["status"] = "dead" elif code >= 400 or code == 0: item["status"] = "slow" else: item["status"] = "ok" item["verified"] = today print(code, item["status"], item["url"]) p.write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")

有几个实践细节需要提醒。不要用 GET 请求做巡检，很多检索站点的 GET 会真实执行一次查询，白白消耗资源，而且响应体很大。超时设短一点，八秒足够，很多失效站点是直接挂起而不是返回错误，超时设长了整轮巡检会跑很久。不要把 403 直接判成死链，有些站点对不带浏览器指纹的请求一律拒绝，这种情况要么加更完整的请求头，要么就人工看一眼。

机器判完之后，人工部分只看两件事：一是status变成dead的条目，确认是彻底没了还是只是拒绝脚本请求；二是抽查五条ok的条目，手动点进去看看检索质量有没有变化。后者是脚本永远替代不了的。

5.3 每季度回顾一次：该删的永远比该加的多

我给自己定了个规矩：季度回顾时只做减法，不加新条目。这个规矩一开始让我很不舒服，因为总觉得"发现了新东西不记下来会忘"。执行了两年之后，我的感受完全反过来了——大部分"发现的新东西"，过一个月再看其实用不上，而清单里那些半年没点过的条目，才是实打实占着位置的噪音。

回顾的具体做法是把清单按verified字段排序，把所有超过九十天没验证的条目标黄，逐条问自己三个问题：过去三个月我用过它吗？如果没用，是因为不需要，还是因为忘了有这个入口？如果是忘了，说明场景描述写得不够好，改描述；如果是压根不需要，直接删。这个方法听起来很粗糙，但执行下来，每次都能删掉一成左右的条目，而清单的可用性反而每次都在提升。

还有一个心得：别怕删掉之后又需要。删掉不等于永久删除，status改成dead或者直接扔进一个archive.json就够了，真需要的时候搜一下还能找回来。心理负担放下了，减法才做得动。

6. 入口只是起点，检索效率的真正差距在使用方式

清单整理好之后，很多人会发现效率提升没有想象中那么大。原因在于入口解决的是"到哪儿找"，而真正决定结果质量的是"怎么问"。这一节讲讲我在实际使用中攒下来的检索技巧，都是能立刻上手的。

6.1 限定符是最便宜的效率工具

通用检索的限定符看起来是基础功能，但真的是被严重低估的东西。常用的就那么几个：site:限定站点或域名，filetype:限定文件格式，intitle:限定标题必须包含的词，引号做精确短语匹配，减号排除干扰词，OR做多选一。

我举个例子说明差距有多大。要找一个特定版本规范的原文，直接搜关键词，返回的是各种转载和解读，翻了五页还没见到原始文档。改成在检索框里写限定词加filetype:pdf，再配合site:圈定官方域名范围，第一页第一条就是原文 PDF。同样的需求，前者五分钟，后者二十秒。

限定符的使用还有个进阶习惯：把常用查询式存成模板。我的备注里存了几条自己常用的组合，比如"查库的真实用法：<函数名> site:<代码托管域名>"、"查标准原文：<标准编号> filetype:pdf"、"查历史版本：<产品名> <版本号> release notes"。这些模板不需要记在脑子里，写在入口页的备注区就行，用的时候顺手抄一下。

6.2 同一个问题用不同形态的库交叉验证

单一来源的结论永远要打个折扣，尤其是技术类问题。我现在的习惯是至少两源对照，而且是跨形态的对照，而不是同一个形态里看两篇文章。

具体的对照组合大概是这几种。代码库对照文档库：从代码检索里看到某个函数的真实调用方式，再回到官方文档确认这个用法在语义上是否被支持，两者对不上就说明你看到的可能是历史遗留写法。问答社区对照代码库：社区里有人说"这样写能跑"，代码库里搜一下发现没人这么写，那就要警惕这是个偶然能跑的写法。学术库对照通用检索：论文里的结论，用通用检索看看有没有后续的复现或质疑，很多被广泛引用的结论后来都被修正过。

跨形态对照还有个副产品：它能帮你发现自己判断错了检索形态。比如你以为这是个代码问题，去代码库里搜了半天没有结果，换到学术库一搜发现这是个算法层面的问题，实现细节根本不是重点。这种"形态纠错"的价值，比找到答案本身还大。

6.3 我在实际使用中踩过的几个坑

最后把几个具体的坑列出来，都是我自己实打实栽过的。

第一个坑是把聚合检索当成主入口。有一阵子我图省事，什么都先用聚合检索跑一遍，结果发现效率反而降低了——它响应慢、摘要不全，我经常在等结果的时候跑去干别的，回来又忘了自己在查什么。后来明确了它的定位：只用来做陌生领域的关键词发现，日常精确查询一律走垂直入口。

第二个坑是过度依赖单一权威入口。有段时间我所有技术问题都从一个入口查，慢慢形成了一种"它没搜到就是没有"的错觉。实际上那个入口对某些类型的资源覆盖很差，比如社区讨论、问题追踪记录，它几乎索引不到。发现这个问题是因为一次排查，我在那个入口搜了半天没有线索，换到问答社区三分钟就找到了别人遇到过的同样问题。

第三个坑是入口清单本身变成了负担。最夸张的时候我的清单有三百多条，分类做了四层。结果是每次检索前要先做一次"选哪个入口"的决策，这个决策成本比检索本身还高。后来砍到一百条以内、分类压到一层，效率反而上来了。这件事让我记住一个原则：清单的规模应该以"能记住大致有哪些"为上限，记不住就说明太多了。

第四个坑是忽视入口的"门槛标注"。早期我的清单里不记是否需要登录、是否需要付费，结果经常出现"点进去发现看不了完整结果"的情况，一次白跑就是几分钟。加上auth字段之后，我在检索前就能判断优先级，先走不需要门槛的，实在没有再走需要登录的。

还有一个小体会是关于分类目录的：不要指望目录帮你做最终决策。目录的人工编辑确实有筛选价值，但它的更新节奏永远滞后于领域变化。我现在的用法是拿目录做"领域地图"，圈出大方向之后，所有具体判断都回到一手信息上做。

这套东西我维护到现在，最大的感受是它其实不是一个"工具"，而是一种把信息获取过程显性化的习惯——你得先想清楚自己在找什么形态的东西，才谈得上找到。清单、页面、脚本都只是把这个思考过程固定下来的载体，载体可以换，那套"先分形态、再选入口、最后交叉验证"的顺序，才是真正省时间的地方。