我本地有个叫dl-links的目录里面躺着四十来个 Markdown 文件没有一行训练代码全是链接——深度学习相关的文档、课程、论文入口、工具说明、踩坑记录。有朋友第一次看到会问这不就是个高级收藏夹吗说实话三年前我也这么想直到我为了复现一个损失函数的重参数化写法在浏览器书签里翻了二十分钟最后发现当初存的那篇讲解已经变成 404只能从头再搜一遍。那次之后我才把“链接备用”当成一个正经事来做它不是把网址往收藏夹一扔就完事而是一套带分类、带元数据、带巡检、带检索的轻量资源库。这篇东西写给两类人看——刚入门、资料越存越乱的同学以及已经有一堆资料但从来想不起来翻的从业者。不管你现在是用浏览器书签还是笔记软件下面这套方法都能直接搬走用。1. 把“链接备用”当成一个工程项目来做1.1 收藏夹失效的真实成本先说清楚这件事到底值不值得花时间。我观察过身边不少人的资料管理方式基本是三段式看到好文章CtrlD 存书签书签栏满了建个文件夹叫“待读”文件夹攒到上百个再也不点开。问题不在于存的动作而在于存完之后这套东西既不告诉你“这是什么”也不告诉你“什么时候存的”更不会提醒你“它已经挂了”。成本可以粗略估一下。假设每周有三次需要回头找资料每次平均花八分钟在书签、搜索历史、聊天记录之间翻找一年就是二十多个小时。这还没算找不到之后重新检索、重新阅读、重新判断质量的时间。更要命的是隐性成本某开发者接手一个训练流水线需要确认某个归一化层的默认参数翻遍收藏夹发现当初存的是某个论坛的二手转述参数早就随版本变了照着调了两天指标都不对最后回到官方文档才发现问题。这种损失很难量化但发生过一次就够记一辈子。所以“链接备用”真正的价值不是“存”而是三个更具体的能力快速判断一条资料现在还能不能用、快速判断它当初为什么被我收藏、快速判断有没有更权威的替代源。这三点决定了它不是收藏行为而是信息资产管理行为。1.2 链接库的三层结构设计我这套东西是三层从外到内分别是入口层、分类层、条目层各管一件事。入口层只有一个文件我管它叫索引页。它不存具体链接只回答一个问题“我現在要做某件事该去看哪几类”比如“我要搭一个图像分类的训练脚本”索引页会指向框架文档类、数据处理类、训练调优类三个文件。这一层的作用是减少决策成本避免每次都从几十个分类里挑。分类层是主体一个主题一个文件比如“框架与工具链文档”“模型结构与论文入口”“部署与推理优化”。每条链接的完整元数据都写在对应的分类文件里不跨文件重复。条目层就是单条链接本身包含标题、地址、标签、难度、添加时间、可用状态、一句话理由。这一层是整套东西的地基字段设计得好不好直接决定三个月后你还能不能用它。为什么不直接做一个大清单我试过。一个两千行的 Markdown 文件编辑器打开就卡git diff 全是整段变动两个人同时改必冲突而且排序一旦被打乱就再也理不顺。分层之后每个文件控制在两三百行改一条只动几行脚本也好处理。1.3 先想清楚“给谁用、用多久”这件事有个容易被忽略的前提你得先明确这个库是给一个人用还是给一个小组用。个人用字段可以随便点标签自己看得懂就行小组用就得约定命名规则否则 A 同学写的“入门”和 B 同学写的“基础”会变成两个标签。还有一个时间维度的问题。如果这个库只打算用三个月那不用折腾笔记软件里建个文档就行如果打算用三年以上就必须考虑载体会不会关停、格式会不会变、内容会不会被平台锁死。我个人的判断标准很简单任何需要我投入超过十小时整理的东西都必须存成十年后还能打开的形式。这条标准直接决定了后面第 3 节的载体选型。2. 分类体系让每一条链接有唯一归属2.1 一级分类按“使用目的”划分不按“内容类型”划分这是我这几年改得最狠的一处。早期我按内容类型分论文、博客、视频、代码。结果每次找东西都失效——我要解决的是“模型训练不收敛”这个需求可能同时命中论文、博客、代码三种类型我到底该翻哪个文件夹换成按使用目的划分之后就顺了。目前我的一级分类大概是这样入门与体系化学习路径数学与基础理论补充框架与工具链官方文档模型结构与论文入口数据处理与标注方法训练过程与调优实践部署、量化与推理优化可视化、调试与性能分析可复现项目与代码样板社区问答与经验帖这十类基本覆盖了从“我想学”到“我要上线”的完整链条。数量上我控制在七到十个这一点很重要——分类数量超过十个归档时的决策成本会急剧上升最后的结果就是“懒得分类全扔 misc”那等于没有分类。2.2 标签做交叉主类只留一个一条链接只能有一个主分类但可以有多个标签。主分类决定它放在哪个文件里标签决定它能不能被交叉检索到。我用的标签维度有这么几组标签维度取值示例解决什么问题难度入门 / 进阶 / 深入判断现在读合不合适形态文档 / 教程 / 论文 / 代码 / 视频判断获取成本时效长期有效 / 随版本变化 / 易过时判断要不要优先看语言中文 / 英文赶时间时的筛选条件含代码是 / 否想直接抄作业时用“时效”这个标签是我后来加的价值极高。官方 API 文档属于“随版本变化”看的时候必须核对版本号而一篇讲梯度消失原理的经典文章属于“长期有效”五年前写的照样能看。有了这个标签我在时间紧张的时候会优先读长期有效的内容避免一头扎进可能已经过时的操作指南。2.3 三个常见的分类误区按网站分类。把某代码托管平台的都放一起、某视频平台的都放一起看起来整齐实际上完全无法支撑任务导向的检索。我要找的是“怎么做模型蒸馏”不是“某个网站上的所有东西”。按收藏时间分类。曾经我建过“2023 年收藏”这种文件夹后来发现它唯一的作用是让我知道自己收藏了很多没看的东西。时间是元数据不是分类维度。粒度过细。有人会分出“卷积网络”“循环网络”“注意力机制”“图网络”等十几个子类结果每个子类下面只有两三条链接。这种结构的维护成本远高于收益我一般的做法是某个子类累计超过十五条再拆出来否则先挂在父类下面。3. 存储载体选型这些链接到底装在哪儿3.1 四种常见载体的横向对比载体选型是这套东西能不能长期活下去的关键我用过四种各自的体验差别很大维度浏览器书签笔记软件在线表格纯文本仓库检索能力只有标题匹配全文检索较强按列筛选全文检索 正则版本管理无弱有历史但难比对完整 diff批量处理几乎不可能依赖导出支持导入导出脚本随便跑跨设备需登录同步需登录同步需登录任意方式长期可读依赖浏览器依赖厂商依赖厂商任何编辑器协作不支持一般好需自建流程书签的问题是它只能回答“这个网址是什么标题”回答不了“我为什么存它”笔记软件体验最好但导出格式经常带一堆私有标记在线表格适合多人协作但版本比对很痛苦。3.2 为什么最后落到纯文本仓库我最终选的是 Markdown 文件加版本管理工具。理由不复杂第一纯文本没有格式锁定十年后随便一个编辑器都能打开第二每条链接是独立的一行或一小块改动可以通过差异比对看清楚谁在什么时候把哪条链接改成了什么一目了然第三可以被命令行工具直接检索这一点在后面第 6 节会详细讲第四脚本能直接读写做去重、巡检、统计都不用导出转换。代价也有没有图形界面多人协作需要一点约定。但对个人和小团队来说这个代价远小于被某个平台锁死的风险。我见过太多人把资料整理在某个小众工具里工具一关停几年的积累全成了导出失败的压缩包。3.3 单条链接的字段规范字段设计的原则是每个字段都要对应一个具体的决策场景没用的字段一个都不要。我现在的条目长这样- title: 某动态图框架的自动混合精度使用说明 url: https://example.com/docs/amp-guide topic: 训练过程与调优实践 tags: [进阶, 文档, 随版本变化, 英文, 含代码] added: 2025-03-11 status: ok mirror: 本地快照 2025-03-11 note: 混合精度下损失缩放系数的初始值设定结论是先用默认值跑通再调。逐个说下意图。title不是照抄网页标题而是改写成“我以后会用什么词搜它”的形式因为网页标题经常是营销式的。topic对应主分类保证唯一归属。tags承担交叉检索。added解决时效判断配合tags里的“随版本变化”一起用。status是巡检脚本回写的ok 之外还有 moved、dead、blocked 三种。mirror记录有没有本地快照。note是最关键的字段下面单独说。3.4 最容易被跳过、也最值钱的字段note绝大多数人的收藏夹里只有标题和网址三个月后打开完全想不起来当初为什么存。我的要求是 note 必须写两句话一句说明它解决什么问题一句写出我自己的结论或判断。比如上面那条的例子“混合精度下损失缩放系数的初始值设定”是它解决的问题“先用默认值跑通再调”是我的结论。这两句话让一条链接从“待读”变成了“已消化”。写不出结论怎么办那就写“待验证”加一个具体问题比如“待验证这个默认值在小批量场景下是否仍然适用”。带着问题去读比漫无目的地看效率高得多。4. 采集与录入把随手存变成可复用资产4.1 录入之前先问三个问题我给自己定了个规矩看到想存的链接先停十秒回答三个问题答不上来就不存。第一它解决的是哪个具体问题如果只是“感觉以后可能有用”那基本等于永远用不上。能具体到“多卡训练时的梯度同步顺序”这种粒度才值得占一个位置。第二三个月后我还能判断它是否过时吗如果一条资料没有版本号、没有发布日期、没有适用环境说明那它的保质期是不可知的。这类内容我会降级处理只在 note 里记个结论不强求保留原链接。第三有没有更权威或更稳定的替代源二手转述的博客可以先看但如果官方文档里有同样的内容我最终存的是官方那一份博客只在 note 里提一句“从这里看到的”。这三个问题看起来啰嗦实际用起来十几秒就能过一遍但它能把收藏量砍掉一半以上剩下的全是真正用得上的。4.2 标题和摘要的写法对比很多人卡在“不知道怎么写标题”。我的做法是把网页原标题改写成“动作 对象 限定条件”的结构方便以后按关键词命中。差的写法好的写法差别在哪深度学习教程从零实现一个图像分类训练循环后者能命中“训练循环”这个搜索词论文分享关于注意力机制计算复杂度的分析后者保留了主题和角度某框架文档某框架数据加载模块的多进程参数说明后者定位到了具体模块收藏混合精度训练中损失缩放的三个坑后者直接给出了内容价值规律很清楚标题里要出现你未来会用来搜索的那个词而不是原页面想让你点的那个词。4.3 地址规范化与去重从各种渠道复制来的地址经常带着一堆噪声追踪参数、锚点、大小写混用、多余的末尾斜杠。不去重的话同一个页面会被存好几次而且你根本发现不了。我写了个小函数做规范化判断重复时只看规范化后的结果。from urllib.parse import urlsplit, urlunsplit, parse_qsl, urlencode # 常见的追踪类参数直接剔除 TRACKING_KEYS {utm_source, utm_medium, utm_campaign, utm_term, utm_content, ref, spm, from} def normalize(url: str) - str: parts urlsplit(url.strip()) scheme https if parts.scheme in (http, https) else parts.scheme host parts.netloc.lower() if host.startswith(www.): host host[4:] # 锚点对判断是否同一页面没有意义直接丢弃 path parts.path.rstrip(/) or / query [(k, v) for k, v in parse_qsl(parts.query, keep_blank_valuesTrue) if k.lower() not in TRACKING_KEYS] query.sort() return urlunsplit((scheme, host, path, urlencode(query), )) if __name__ __main__: raw [ http://www.example.com/docs/guide/?utm_sourcefeedid7, https://example.com/docs/guide?id7#section-2, https://example.com/docs/guide/?id7, ] print(len({normalize(u) for u in raw})) # 输出 1这段逻辑有几个判断点值得说明。丢弃锚点是权衡后的选择如果某个文档特别长我需要定位到具体小节那我在 note 里写“看第三节”而不是依赖锚点因为锚点在小标题改名后会失效。统一去掉www.前缀是为了避免同一个站点出现两个变体。查询参数排序是为了让?a1b2和?b2a1判为同一条。注意锚点丢弃这条不适用于“文档本身就是靠锚点区分内容”的场景比如某些单页应用的接口文档。遇到这种情况我会在做规范化之前先判断路径里有没有#/有就跳过锚点处理。4.4 从浏览器批量导入历史包袱总得处理。浏览器导出的书签是一个标准 HTML 文件结构是嵌套的列表用 Python 的html.parser就能解析不需要额外依赖。from html.parser import HTMLParser from pathlib import Path class BookmarkParser(HTMLParser): def __init__(self): super().__init__() self.items [] self._folder [] self._in_anchor False self._href self._text def handle_starttag(self, tag, attrs): attrs dict(attrs) if tag a: self._in_anchor True self._href attrs.get(href, ) self._text elif tag h3: self._folder.append() def handle_data(self, data): if self._in_anchor: self._text data def handle_endtag(self, tag): if tag a and self._in_anchor: self.items.append({ title: self._text.strip(), url: self._href, folder: /.join(f for f in self._folder if f), }) self._in_anchor False elif tag h3 and self._folder: pass # 文件夹名在 handle_data 里捕获这里保持层级 if __name__ __main__: p BookmarkParser() p.feed(Path(bookmarks.html).read_text(encodingutf-8)) print(f共解析 {len(p.items)} 条)导入之后不要急着合并先做两件事一是按第 4.3 节的函数去重二是统计每个原文件夹下有多少条。后者很有用它能直接告诉你哪些文件夹是“垃圾场”——如果一个文件夹里有八十条链接但名字叫“其他”那基本可以判定这八十条里有七成不需要保留。我当初导入了接近九百条去重加清理之后留下两百出头剩下的大部分是当时觉得有用、现在完全想不起来的。5. 链接巡检让失效链接无处藏身5.1 巡检脚本的实现要点链接库最大的敌人是沉默的失效。一条链接挂掉不会通知你它只会在你真正需要的时候给你一个 404。所以巡检必须自动化我一般按月跑一次全量。脚本的核心逻辑不复杂读文件、抽地址、发请求、看状态码、回写。真正的坑都在细节里。直接上代码import time import requests from concurrent.futures import ThreadPoolExecutor, as_completed from urllib.parse import urlsplit HEADERS { User-Agent: dl-links-checker/1.0 (personal link library maintenance) } TIMEOUT (5, 15) # 连接 5 秒读取 15 秒 def check_one(url: str, retries: int 2) - dict: last_err for attempt in range(retries 1): try: # 先试 HEAD省流量部分站点不支持 HEAD回退到 GET resp requests.head(url, headersHEADERS, timeoutTIMEOUT, allow_redirectsTrue) if resp.status_code in (403, 405, 501): resp requests.get(url, headersHEADERS, timeoutTIMEOUT, allow_redirectsTrue, streamTrue) code resp.status_code if code 400: return {url: url, status: ok, code: code, final: resp.url} if code 500 and code ! 429: # 4xx 里除限流外重试没意义直接返回 return {url: url, status: dead, code: code, final: resp.url} last_err fhttp {code} except requests.exceptions.Timeout: last_err timeout except requests.exceptions.ConnectionError as e: last_err fconn: {type(e).__name__} except requests.exceptions.RequestException as e: last_err freq: {type(e).__name__} # 退避重试避免连续撞同一个站点 time.sleep(1.5 * (attempt 1)) return {url: url, status: unknown, code: None, error: last_err} def check_many(urls, workers: int 6): results [] with ThreadPoolExecutor(max_workersworkers) as pool: futures {pool.submit(check_one, u): u for u in urls} for fut in as_completed(futures): results.append(fut.result()) return results几个参数的选择理由说清楚。并发数我压在六不是技术上不能更高而是很多站点对短时间高频请求会直接返回限流状态把正常链接误判成失效。超时设成五秒连接、十五秒读取是因为有些文档站首页会加载一堆静态资源读取慢了很正常超时设太短会误杀。重试次数给两次指数退避主要针对偶发的网络抖动。还有一点很关键只对 GET 回退的请求做流式处理。streamTrue加上不读响应体可以避免为了检查一条链接而下载几十兆文件。5.2 状态分级与处置策略拿到状态码只是第一步怎么处理才是重点。我按下面的规则分档返回情况判定处置动作200 且地址未变正常保持200 但最终地址变了已迁移更新 urlnote 里记原地址301/302/307/308重定向更新为目标地址401/403拒绝访问不删标 blocked人工确认404/410已消失优先找快照或替代源429限流不判定隔天单独重跑5xx服务端异常连续两次才判定避免误杀超时 / 连接错误不确定三次重试仍失败再标 unknown最需要小心的是 403 和 429。有些站点会对非浏览器请求统一返回 403链接本身完全正常手点就能打开如果不加区分地标成失效会误删掉一堆好资料。我的做法是这类一律不自动处理只标记等人工抽查。另一个经验是不要在同一天对同一个域名跑两次全量。有些文档站会把短时间内的密集请求当成异常流量导致后面几小时内所有请求都被拒。脚本里最好加一个按域名分组、单域名串行的逻辑牺牲一点速度换准确率。5.3 内容快照与替代源链接会死但内容未必会死。对于判断为“长期有效”且 note 里已经写了结论的条目我会做一份轻量快照不存整页 HTML只存三样东西标题、抓取时间、正文里的关键段落或公式。这三样东西已经足够让我在链接失效后回忆出内容要点。替代源的查找顺序我也有固定套路先看目标站点有没有带版本号的稳定路径再看有没有公开的归档快照最后才去找内容等价的另一份资料。很多文档站的地址里带着版本号或者语言段改动这个段往往能找回同一篇内容。提示如果一条链接的价值只在于“某个具体数字或默认值”那更强的做法是把那个数字直接写进 note链接降级为参考。数字留在本地链接失效也无所谓。5.4 巡检节奏全量月度一次增量每周一次——只检查本周新增的条目。提交改动之前本地跑一次只针对改动行的检查避免把刚存进来的坏链接一起提交。这套节奏我用了两年多误报率控制在很低的水位。6. 检索让存下来的东西真的被用起来6.1 命令行的分钟级检索纯文本仓库最大的好处是可被命令行直接检索。我常用的几条# 按关键词搜标题和理由列出文件名和行号 rg -n 混合精度|损失缩放 --type md # 只搜标签行快速找出所有进阶难度且随版本变化的内容 rg -n tags:.*进阶.*随版本变化 --type md # 统计每个分类下的条目数看看哪个分类在膨胀 rg -c ^- title: --type md | sort -t: -k2 -nr # 找出所有还没做过快照的条目 rg -n mirror:\s*$ --type md比图形界面快得多尤其是需要组合条件的时候。比如“英文、含代码、和我当前问题相关”一条正则就能筛出来。6.2 给高频任务做入口别名我把几个最常用的检索固化成了命令行别名输入两三个字母就能跑。比如查某个主题的所有链接、查最近一个月新增的、查所有待验证的。这类小工具的价值在于把“想起来去翻资料”的动作成本降到几乎为零成本一低使用的频率自然就上去了。索引页在这里也起作用。我会在索引页里维护一个“最近在解决的问题”小节列出三到五个当前关注的方向每个方向下面挂三到五条最相关的链接。这个列表每周更新一次过期就换。它相当于一个工作台避免我在几十个分类文件里漫游。6.3 每周一次的知识回流光存不读是最常见的问题我自己的解法是每周固定花二十分钟做一次回流从本周新增或本周用到的条目里挑一条在 note 里补三行——它讲了什么、和我的问题什么关系、下一步做什么。听起来很轻坚持下来效果很明显。一年五十多周就是五十多条被真正消化过的资料这比存两千条链接然后全忘掉强太多。而且这个过程会自然淘汰一批“存了但没什么可说”的条目库的体积反而更健康。7. 常见问题与排查实录7.1 问题速查表现象可能原因处理方式脚本报大量 403缺 UA 或站点反爬补 User-Agent降并发改人工抽查同一页面存了多份地址带追踪参数先规范化再去重见 4.3巡检跑几小时不结束单条超时未设上限连接和读取超时都要设并发控制在 6 左右快照和正文对不上站点改版后内容替换快照里记录抓取时间检查时以时间戳为准搜索找不到明明存过的内容标题用的是网页原标题改写标题见 4.2分类文件越来越大没做子类拆分单类超 15 条再拆别提前拆两个人同时改冲突用单文件存放按主题拆文件降低冲突面版本更新后条目全过时缺时效标签补“随版本变化”标签巡检时重点看7.2 几个踩过的坑坑一只存地址不存理由。这是最致命的。我早期存了大概三百条全部只有标题和网址半年后打开能想起来为什么存的不到二十条。现在我对没有 note 的条目一律视为“未完成”宁可先不存。坑二只存首页不存具体页。存一个站点的首页等于什么都没存因为首页会变而且你还要再点进去找。一定要存到能直接看到内容的那一层地址最好带版本号或固定路径。坑三把工具当目标。有一阵子我沉迷于找“更好的资料管理工具”换了三四个每次迁移都丢一批数据。后来想明白了工具只是壳真正的价值在字段设计和维护习惯上同样的东西用最朴素的文本文件也能跑起来。坑四巡检脚本太激进。早期我设了二十并发加一秒超时跑完一看四十多条正常链接被判成失效。后来老老实实降并发、加超时、加退避准确率才上来。检查链接这件事稳比快重要得多。坑五忘了自己也会变。一年前存的入门资料现在看已经太浅当时觉得晦涩的论文现在读起来刚好。所以标签里的“难度”是需要维护的我一般每季度扫一遍把难度标签往上调一档。这一步很少有人做但做完之后整个库的可用性会明显不同。最后分享一个我一直在用的小习惯每次要查资料之前先在库里搜一遍搜不到再去网上找。搜到了就直接用搜不到就把新找到的顺手入库并写清理由。这样一个动作同时完成了“用”和“养”库不会变成只进不出的死水也不会在需要的时候掉链子。