如果你是一个写过技术博客、总结过项目文档、整理过团队知识库的人大概率遇到过这样的困境收藏夹里躺着上百篇“以后要看”的文章本地笔记软件里堆了几百条摘录和想法可真到要写一篇系统性的技术总结时却发现素材散落各处逻辑理不清观点连不起来。你以为自己缺的是写作灵感其实缺的是一套能把碎片知识转化成文章的系统。卡片盒笔记法Zettelkasten这几年在知识管理圈里被反复讨论但大多数介绍文章停留在“什么是卡片盒”的理论层面真正能指导人动手实践的案例反而不多。所以当一本主打“更多卡片盒实操案例”的《写作系统》出现时很多想入门卡片笔记的人会问同一个问题它能成为我的卡片笔记入门书吗这篇文章不打算替你做最终决定但会给你一套判断标准。我会先把卡片盒笔记法的核心原理讲清楚再拆解一本实操导向的写作工具书应该具备哪些要素最后给你一套不依赖任何特定书籍也能跑通的最小卡片盒实践方案。读完你可以自己判断这本书适不适合你以及你的卡片笔记之路下一步该怎么走。1. 技术写作者的隐秘痛点你缺的不是灵感是系统先从一个非常具体的场景说起。假设你是一位后端开发平时负责订单系统的维护。某天你发现消息队列消费端偶发重复消息排查了半天确认是消费者在重启时没有正确提交偏移量导致。你花了一个下午定位问题解决之后觉得这个案例很有价值打算写一篇技术博客分享给团队。这时候问题来了。你的参考资料分散在哪里线上问题排查时你翻过的官方文档链接在某浏览器标签页里自己总结的排查思路写在公司Wiki某个角落之前看过的一篇关于消息幂等性的文章在你的微信收藏里还顺手截图过一段源码分析。你花了半小时翻找发现自己根本没有一个地方能把这几条线索串起来。这不是个别现象。国内外的效率社区里知识工作者普遍面临三个困境第一收集与整理脱节。收藏、截图、摘录的成本极低但整理、归档、关联的成本很高。大多数人收藏之后再也没看过那些内容导致收藏越多检索越难。第二笔记之间没有联系。传统笔记本按文件夹分类一篇笔记只能放在一个位置。但真实的知识结构是网状的不是树状的——一个消息队列的问题可能同时涉及网络、分布式一致性、操作系统和编程语言。单靠文件夹管理知识点之间很难产生化学反应。第三写作时没有素材流。真正写文章时你需要的不只是“知道”某个知识点而是能快速调出相关的、经过自己思考加工过的素材。如果你平时的笔记只是复制粘贴原文没有自己的转述和思考写文章时依然无从下手。卡片盒笔记法的设计目标恰好就是解决这三件事。它的重点不是帮你更好地收藏而是帮你建立一套从阅读到思考再到输出的流水线。它要求你把知识拆成一个个可以独立存在、又能互相连接的小卡片然后用链接把它们编织成网。这套方法最早由德国社会学家尼克拉斯·卢曼Niklas Luhmann在实践中完善——他靠着这个笔记系统30年出版了70多本书写了400多篇论文。你当然不需要像卢曼那样写70本书但如果你需要写技术博客、整理技术方案、维护个人知识库或者只是希望在下次写总结时不再从头翻找素材卡片盒笔记法就值得你花时间了解。而《写作系统》这本书从书名看就是在尝试把这套方法从理论变成可操作的案例集。2. 卡片盒笔记法从“存笔记”到“生成思想”的转变很多第一次接触卡片盒笔记的人都会问这样一个问题它和我用备忘录、Word、OneNote记笔记有什么区别先说结论传统笔记是“存储导向”的卡片盒笔记是“思考导向”的。存储导向的意思是你用文件夹把信息归类目的是以后能找回来思考导向的意思是你写卡片的目的是为了在与旧笔记的碰撞中生成新想法写下来只是这个过程的中间产物。卢曼的卡片盒笔记法核心可以拆解为三条原则。第一原子化Atomicity。每张卡片只记录一个想法、一个事实、一个论据。不要在一张卡片里塞进三个观点。这样做的直接好处是卡片之间可以任意组合形成不同的文章结构。如果你的卡片是一篇五千字文章的搬运它就无法在另一个语境里被复用。第二链接优先Link-first。卡片与卡片之间通过链接形成网络。卢曼的卡片盒里一个想法往往跟在相关想法的后面形成一个持续生长的链条。你不需要提前设计好分类体系靠链接天然就能形成结构。这一点类似超文本的思想也类似Git里通过引用把提交串成历史线的关系。第三自下而上Bottom-up。传统写作是先有提纲再去填充内容卡片盒写作反过来是从大量卡片中逐渐发现主题再组织成文章。你平时只管往卡片盒里添加经过自己思考的卡片等到卡片积累到一定程度主题和脉络会自动浮现。这时候你做的更多是选择和组织而不是凭空创造。这三条原则对应到技术写作场景里可以这样理解原子化意味着你读一篇关于分布式事务的文章时不要写一张“分布式事务总结”的大卡片而是分别写“两阶段提交的阻塞问题”“TCC方案的空回滚”“本地消息表的实现思路”。每一个都是独立的知识点以后可以被不同的文章复用。链接优先意味着当你写“本地消息表”这张卡片时要主动添加链接到“可靠消息最终一致性”“事务消息”“消息重复消费”等相关卡片。这些链接就是未来的文章骨架。自下而上意味着你不需要一开始就决定“我要写一篇关于分布式事务的文章”而是当你的卡片盒里积累了大量事务、消息、一致性相关的卡片之后你自然会看出其中的联系那时再决定要不要成文。这套理念本身并不复杂真正难的是执行。而市面上的问题恰恰在于讲理念的书和文章很多一步步带着你操作、展示完整案例的很少。这就回到了我们最初的问题《写作系统》这本书在实操案例上到底做得怎么样3. 判断一本笔记工具书是否适合入门的三个标准在没拿到《写作系统》全书内容之前谁也不敢说它一定适合所有人。但从书名和定位来看可以给出一个合理的判断框架。如果你正在犹豫要不要把它作为卡片笔记的入门书建议按下面三个标准来审视。标准一是否讲清楚了“为什么”。一本入门书首先要回答的不是“怎么做”而是“为什么这么做”。如果一本书只教你如何建笔记、打标签、做链接却不解释原子化背后的信息论原理不解释链接为什么比文件夹更适合知识生长那它只能算工具手册不能算方法论著作。从《写作系统》的标题看它把卡片盒实操案例放在副标题位置暗示内容重心在“案例”和“实操”。这并不意味着它不讲原理但读者需要留意的是它讲原理的篇幅有没有足够支撑后面的实操。如果案例很多、原理薄那更适合有一定了解的人做进阶参考如果案例背后都附带了清晰的原理说明那么作为入门完全没问题。标准二是否提供了可复制的案例。这里说的案例不是“我建议你这么记”这种话术而是完整的、带有上下文和思考过程的示例。比如一个关于“如何从三篇阅读笔记生成一篇评论文章”的完整演示原始文本是什么、你如何写文献笔记、如何转化为永久笔记、如何添加链接、如何从16张卡片中选出一篇文章的大纲。如果一本书能有三个以上这样的完整案例它的实操价值就非常高因为你可以照着它走一遍全流程。这其实很像编程领域的技术书。教Spring Boot的书如果只有理论讲解读者很难真正学会但如果有完整的Demo项目从零写到部署读者的上手速度会快很多。《写作系统》的卖点既然是“更多实操案例”那么它在这一点上是否做得足够扎实是评估它能否作为入门书的最重要维度。标准三是否处理了常见误区。卡片笔记法流行之后出现了很多被误解的实践。比如认为“卡片越多越好”“必须用某个特定软件”“所有笔记都要做永久笔记”“链接越多越厉害”。一本负责任的入门书应该明确指出哪些是误区、哪些是边界。如果一本只讲怎么做、不讲哪里容易做错的书读者很容易在实践时踩坑后放弃。这三个标准也是你自己检验任何知识管理类书籍的通用标尺。不管最终选择哪本书用这三个维度去筛选基本不会错。4. 一张表看懂卡片盒笔记里的三类卡片分工抛开《写作系统》这本书具体写了什么卡片盒笔记法本身有一套比较稳定的核心概念。无论你是准备读书还是准备直接开始实践先理解这几类卡片会很有帮助。在卢曼卡片盒笔记法及其现代变体中通常存在三类卡片文献笔记、永久笔记、索引笔记有时也叫结构笔记。它们在流程中的位置不同用途也不同。卡片类型什么时候写写什么内容存到哪里是否进入最终文章文献笔记Literature Note阅读文章、书籍、代码时用自己的话记录原文的核心观点附上出处单独的地方不放进正式卡片盒通常不直接使用作为素材来源永久笔记Permanent Note阅读后或思考时一个完整的、自解释的想法必须用自己的语言写正式卡片盒是文章的基本材料索引笔记Structure Note / Index卡片积累到一定量时把一组相关卡片组织成一个主题入口正式卡片盒作为导航可以作为文章大纲的雏形文献笔记和永久笔记的区别最容易被新手忽略。说到底文献笔记是“转述别人的观点”永久笔记是“生成自己的想法”。如果你读完一篇文章只是摘抄了一段话那是文献笔记如果你结合自己的项目经验写下了“这解释了为什么我们上次用两阶段提交时性能下降那么严重”那是永久笔记。前者是原材料后者才是产出。索引笔记可以做类比它就像代码仓库里的README。README本身不包含核心业务逻辑但会告诉你哪些目录存放哪类代码如何快速找到入口。索引笔记负责把散落在各处的卡片按主题聚合让你不需要记住每张卡片的编号就能顺着索引找到一组相关内容。很多新手头疼的问题是什么时候该写文献笔记什么时候该写永久笔记有一个很实用的判断标准当你合上文章能用一两句话讲清楚这篇文章在说什么那就写出文献笔记如果你还能把它和你已有的知识或项目经验联系起来产生了一个新的角度或疑问那就值得写一张永久笔记。这套分类不是必须照搬的教条但它是理解卡片盒笔记法的一个很好用的脚手架。有了这层认知你再去看《写作系统》这类书时会更容易判断它讲得到不到位。5. 不依赖某本书也能跑通的最小卡片盒实践方案很多人读完关于卡片盒笔记法的文章之后第一反应是好有道理但我该怎么开始这里给出一套不依赖任何特定书籍、也不依赖任何付费软件的最小实践方案。只要你有一台电脑能装一个文本编辑器就足够了。5.1 工具选型原则卡片盒笔记法的核心价值在方法论不在工具。你完全可以用免费的 Markdown 编辑器 文件夹 Git 搭建一套够用的系统。推荐使用 Markdown 而不是 Word原因有三个Markdown 是纯文本跨平台、跨软件通用永远不会因为软件停止维护而丢失。Markdown 支持双链语法[[文件名]]可以用 Link 把卡片连接起来。Markdown 方便配合 Git 做版本管理每次修改都有历史记录。5.2 目录结构与命名规则用最朴素的方式在本地创建一个文件夹作为你的卡片盒zettelkasten/ ├── 1-inbox/ # 临时收集每天整理 ├── 2-literature/ # 文献笔记按作者文章名命名 ├── 3-permanent/ # 永久笔记按时间戳关键词命名 ├── 4-structure/ # 索引笔记按主题命名 └── templates/ # 卡片模板这里有个重要的命名规则需要特别说明永久笔记的文件名不要用“分布式事务”这样的大主题词建议用日期时间戳加简短说明例如20250204-消息重复消费的幂等设计.md。为什么不用主题词命名因为同一个主题下的笔记会越来越多主题词文件名的可扩展性很差。而且如果你用主题词做文件名很容易在写卡片时下意识地想去“归类”这又回到了文件夹思维的陷阱。用时间戳命名可以让每一张卡片都是一个独立的、平等的节点真正的关系靠正文里的链接表达。5.3 永久笔记模板以下是一个经过简化的永久笔记模板适合技术写作场景--- type: permanent tags: [分布式, 消息队列] created: 2025-02-04 --- # 消息重复消费的幂等设计 ## 想法核心 在消息队列消费端重复消息不可避免业务侧必须通过幂等设计 来保证多次处理的结果与一次处理一致。 ## 背景 订单系统在消费者重启时可能因为未提交偏移量而重新拉取消息。 ## 连接到 - [[消费端手动提交偏移量的风险]] - [[数据库唯一索引实现幂等]] - [[本地消息表的实现思路]] ## 可能的写作用途 - 消息队列实战系列 - 分布式系统的可靠性设计画重点type字段标记这是一张永久笔记。tags是检索辅助不是分类是用来补充上下文标签。想法核心是卡片的灵魂必须用你自己的话写。连接到是卡片之间的链接是将来组织文章的关键。可能的写作用途是一个很有用的字段写的时候可能用不上但积累多了以后会帮你更快地识别主题。5.4 文献笔记模板文献笔记不需要追求完整它的作用是记录“我看过这篇文章它讲了这些”并给永久笔记提供素材。--- type: literature source: https://example.com/distributed-transaction-article author: xxx created: 2025-02-04 --- # 分布式事务文章阅读摘要 - 作者用三个小节讲了分布式事务的三种实现方案。 - 核心观点没有一种方案能同时保证强一致性、可用性和性能。 - 我标注的重点两阶段提交的阻塞问题Saga的补偿设计。 - 相关想法见[[两阶段提交在订单系统的适用性分析]]文献笔记和永久笔记最理想的关系是文献笔记是引子永久笔记是产物。当你从文献中产生了一个新想法时不要在那个想法后面写完就结束了而是应该独立创建一张永久笔记让它未来可以被其他文献笔记链接到。5.5 Git 版本管理卡片盒的内容是你的数字资产应该纳入版本管理。用 Git 管理卡片盒非常简单cd zettelkasten git init git add . git commit -m 初始化卡片盒 git log --oneline后续每次整理完一批卡片都可以提交一次。建议养成的习惯是每天花 10 分钟清空 inbox每周做一次 commit。这样你的卡片历史就有了完整的演化轨迹如果哪次批量修改出了问题也可以直接回滚。机器性能允许的话还可以把仓库推到自己的私有 Git 远程仓库做异地备份。注意这里强调“私有”——卡片盒里往往有大量个人想法和未公开的资料不建议放到公开仓库。6. 用 Python 脚本辅助卡片管理和链接检查卡片积累到几百张之后人工检查链接是否断裂、索引是否完整会变得很吃力。这里提供两个轻量脚本用 Python 标准库实现不需要安装任何第三方依赖。6.1 检查断链脚本这个脚本遍历3-permanent目录下的所有 Markdown 文件抽取双链语法[[文件名]]检查目标文件是否存在于本仓库中。 文件路径scripts/check_links.py 用法python scripts/check_links.py /path/to/zettelkasten import os import re import sys LINK_PATTERN re.compile(r\[\[([^\]|#])) def collect_md_files(root): md_files {} for dirpath, _, filenames in os.walk(root): if templates in dirpath: continue for name in filenames: if name.endswith(.md): full_path os.path.join(dirpath, name) key os.path.splitext(name)[0] md_files[key] full_path return md_files def check_links(root): md_files collect_md_files(root) broken [] total 0 for dirpath, _, filenames in os.walk(root): if templates in dirpath: continue for name in filenames: if not name.endswith(.md): continue full_path os.path.join(dirpath, name) with open(full_path, r, encodingutf-8) as f: content f.read() links LINK_PATTERN.findall(content) for link in links: total 1 if link not in md_files: broken.append((full_path, link)) return broken, total if __name__ __main__: root sys.argv[1] if len(sys.argv) 1 else . broken, total check_links(root) print(f共检查 {total} 个链接发现 {len(broken)} 个断链) for path, link in broken: print(f {path} - 缺少 [[{link}]])运行方式python scripts/check_links.py /path/to/zettelkasten预期输出共检查 128 个链接发现 3 个断链 /path/to/zettelkasten/3-permanent/20250118-xx.md - 缺少 [[未创建的卡片名]]这里有一个判断需要提前说明检查脚本发现的“断链”并不一定表示出错。在卡片盒实践里在链接处写一个还没创建的卡片名本身就是一种写作思路标记表示“这里未来应该有一张卡”。所以脚本的定位是帮你发现并确认这些提前占位再决定是创建对应卡片还是删除这个无效链接。6.2 生成随机卡片入口脚本有时你会面对一堆卡片不知从哪里开始。一个有趣的实践是“随机抽取卡片”随机抽三张尝试把它们连接成一个新的想法。这在卢曼卡片盒的实际使用中是一种自下而上寻找主题的方法。 文件路径scripts/sample_cards.py 用法python scripts/sample_cards.py /path/to/zettelkasten 3 import os import random import sys def get_permanent_cards(root): card_dir os.path.join(root, 3-permanent) if not os.path.isdir(card_dir): return [] cards [] for name in os.listdir(card_dir): if name.endswith(.md): cards.append(os.path.join(card_dir, name)) return cards if __name__ __main__: root sys.argv[1] if len(sys.argv) 1 else . n int(sys.argv[2]) if len(sys.argv) 2 else 3 cards get_permanent_cards(root) if len(cards) n: print(f卡片数量不足当前有 {len(cards)} 张需要 {n} 张) sys.exit(1) samples random.sample(cards, n) for path in samples: print(os.path.basename(path)) with open(path, r, encodingutf-8) as f: first_line f.readline().strip(# \n) print(f - {first_line})运行方式python scripts/sample_cards.py /path/to/zettelkasten 3预期输出20250112-数据库唯一索引实现幂等.md - 数据库唯一索引实现幂等 20250120-消费端手动提交偏移量的风险.md - 消费端手动提交偏移量的风险 20250128-本地消息表的实现思路.md - 本地消息表的实现思路随机抽卡这个动作听起来没什么技术含量但它确实有效。当你积累了一批卡片后把毫不相关的卡片放在一起经常能发现意外的关联。做技术写作时这种意外关联往往就是文章创新点的来源。7. 从卡片到成稿用写作系统支撑一篇技术文章现在回到最开始那个订单系统消息重复消费的场景。假设你已经用了卡片盒笔记法一段时间卡片盒里积累了一批相关卡片你会如何写出一篇完整的技术博客7.1 写作前卡片聚合你要写的文章主题是“消息队列消费端的幂等设计”。这时候不要从空白文档开始而是先在卡片盒里检索所有相关卡片。在已有的实践里可能会找到这样几张消息重复消费的幂等设计消费端手动提交偏移量的风险数据库唯一索引实现幂等本地消息表的实现思路Redis SETNX 实现幂等的优缺点我的线上幂等设计失误复盘这六张卡片已经天然构成了一篇文章的骨架。注意这个过程中的关键动作是“检索和组织”而不是“凭灵感创作”。卡片盒最大的价值就在于此它把写作从一种“灵感的赌博”变成了一种“素材的组织”。7.2 写作中大纲生成接下来从这六张卡片中提炼文章大纲。这里用到一个很实用的方法把索引笔记当作大纲草稿。一个简单的做法是新建一张结构笔记列出文章的小标题然后为每个小标题关联卡片# 大纲消息重复消费的幂等设计实战 ## 1. 背景消费者重启引发线上重复消息 - 关联[[消费端手动提交偏移量的风险]] - 关联[[我的线上幂等设计失误复盘]] ## 2. 重复消息为什么不可避免 - 关联[[消息队列的 At Least Once 语义]] ## 3. 三种幂等方案对比 - 关联[[数据库唯一索引实现幂等]] - 关联[[Redis SETNX 实现幂等的优缺点]] - 关联[[本地消息表的实现思路]] ## 4. 实践总结 - 关联[[消息重复消费的幂等设计]]从这张结构笔记出发写文章时就非常轻松了。每个小节都有现成的素材你只需要用自己的语言把卡片串成一个连贯的叙述。7.3 写作后卡片回填文章发布之后还有一个很多人忽略的收尾动作把文章本身写成一张卡片或者至少建立文章与相关卡片的反向链接。这样下次当你要写一个更宏观的主题比如“分布式系统可靠性设计”时这篇成文又能作为一张更完整的素材被检索到。这个回填动作极其重要。它让写作的产出重新变成卡片盒输入形成正向循环。如果你只是写文章而不回填卡片盒就只是单向消耗素材没有复利效应。8. 常见问题与排查思路卡片盒笔记法实践过程中几乎每个人都会遇到下面这些问题。整理成一个排查表供你对照。问题现象可能原因排查方式解决方案卡片写了不少但写文章时还是没素材写的大多是文献笔记缺少自己的永久笔记检查永久笔记数量占卡片总量比例每读完一篇资料强制写至少一张用自己的话表达的永久笔记链接很多但全是死链和随手链接为链接而链接没有考虑卡片之间的真实逻辑关系抽查链接目标看两个卡片放在一起是否有意义只在写下“这张卡片补充了另一张的某个角度”时才加链接分类混乱不知道卡片该放哪个文件夹还在用文件夹思维管理卡片检查目录是否超过三层、文件命名是否用主题词回归原子化原则带时间戳命名并把连接交给正文中的双链用了一段时间坚持不下去一开始设定了过高的整理目标回看制定规则时是否要求每篇文献都做完整卡片降低标准先保证每周写 2-3 张高质量永久笔记比追求数量更重要卡片内容太长几乎是一篇文章没有拆分成原子化检查单张卡片是否包含多个想法把每张卡片压缩为一个想法多余想法拆分成新的卡片并互链这里面最值得强调的一点是卡片数量不是目标。卢曼的卡片盒之所以有用不是因为他写了九万张卡片而是因为这九万张卡片编织成了一个可以持续生成思想的网络。对普通技术写作者来说一年积累三四百张高质量的永久笔记已经足够支撑相当可观的技术文章产出。9. 最佳实践与工程建议结合长期实践下面几条建议对想要入门的读者最有用。第一先跑通最小闭环再追求流程完整。不要等到读完所有关于卡片盒的资料才开始实践。用一个周末搭建最简单的 Markdown Git 卡片盒写五张卡片尝试从这五张卡片里找出一篇短文的骨架。先跑通这个闭环你对卡片盒笔记法的理解会明显加深。第二强制“用自己的话”写作。永久笔记最忌讳直接摘抄原文。你可以引用一小段但卡片的主体必须是把原文掰开揉碎后用你的语言重写。这不仅是知识管理的要求更是认知训练一个人如何用自己的话表达决定了TA是否真正理解了那个概念。第三每周做一次回顾和整理。建议把这作为固定习惯每周抽 30 分钟清空 inbox把临时的想法转化为正式卡片检查是否有断链需要处理顺便看看最近一周的卡片里是否出现了新的主题。这一步能防止卡片盒在积累中变得混乱。第四注意隐私与备份。卡片盒里可能有个人思考和未公开的技术方案建议使用私有仓库存储并养成定期 Git 提交的习惯。如果使用云同步盘最好加密或至少确认云服务商的隐私条款。第五适合自己的方法才是好方法。卡片盒笔记法的理念是清晰的但具体到每个人原子化到什么粒度、链接写多少、索引怎么建都需要在实践里调整。你可以从通用模板开始但在使用两周之后一定要根据自己写技术文章的规律改出一套属于你自己的模板变量。第六用 AI 工具辅助而不是替代思考。在卡片创作阶段可以先用 AI 生成初步的摘要和结构化要点但最终放入永久笔记的内容必须有你自己整合后的判断。在卡片检索和组合阶段AI 可以帮助你找出主题、推荐可能相关但你又遗忘的卡片这样可以很大程度上缓解“笔记多了找不到”的痛点。但请注意不要把 AI 生成的总结当成你的永久笔记直接入库那样你会失去卡片盒笔记法里最重要的“加工”环节。10. 回到最初的问题《写作系统》值得作为入门书吗现在我们可以给这篇文章最开始的问题一个较完整的回答。判断一本讲卡片笔记的实操书籍能否作为你的入门书关键看三条是否讲清楚了“为什么”而不只是“怎么做”、是否提供了可以照着走一遍的完整案例、是否指出了常见的误区。从《写作系统》的定位来看它把大量篇幅放在实操案例上这正好是对市面上很多“理论有余、案例不足”的笔记书籍的一种补充。如果你已经看过一些卡片盒笔记法的理论文章急需用完整案例把所有环节串起来这本书的实操属性会更契合你的需求。如果你是完全的新手对卡片盒笔记法的基本概念都不太熟悉那么建议你先用本文前四章的内容建立基础认知再配合本书的案例动手实践。无论最终使用哪本书或哪套方法都请记住卡片盒笔记法的本质它不是收藏工具而是一个生成思想的系统它的目的不是存储知识而是让知识在使用中产生新的洞见。你不需要等一本书读完才动手最好的开始时间就是你坐下来写下第一张永久笔记的今天。下一步建议很具体建一个空文件夹复制上文给出的模板写三张卡片一张关于你最近修复的一个线上 Bug一张关于你最近读到的一篇值得记住的博客一张关于你明天可能要写的文章大纲。然后给它们建立至少两条互相引用的链接。这一步完成之后你对卡片盒笔记法的理解会比读任何书的前三章都来得深刻。 卡片盒笔记法实操指南：从碎片知识到技术文章的系统化写作
如果你是一个写过技术博客、总结过项目文档、整理过团队知识库的人大概率遇到过这样的困境收藏夹里躺着上百篇“以后要看”的文章本地笔记软件里堆了几百条摘录和想法可真到要写一篇系统性的技术总结时却发现素材散落各处逻辑理不清观点连不起来。你以为自己缺的是写作灵感其实缺的是一套能把碎片知识转化成文章的系统。卡片盒笔记法Zettelkasten这几年在知识管理圈里被反复讨论但大多数介绍文章停留在“什么是卡片盒”的理论层面真正能指导人动手实践的案例反而不多。所以当一本主打“更多卡片盒实操案例”的《写作系统》出现时很多想入门卡片笔记的人会问同一个问题它能成为我的卡片笔记入门书吗这篇文章不打算替你做最终决定但会给你一套判断标准。我会先把卡片盒笔记法的核心原理讲清楚再拆解一本实操导向的写作工具书应该具备哪些要素最后给你一套不依赖任何特定书籍也能跑通的最小卡片盒实践方案。读完你可以自己判断这本书适不适合你以及你的卡片笔记之路下一步该怎么走。1. 技术写作者的隐秘痛点你缺的不是灵感是系统先从一个非常具体的场景说起。假设你是一位后端开发平时负责订单系统的维护。某天你发现消息队列消费端偶发重复消息排查了半天确认是消费者在重启时没有正确提交偏移量导致。你花了一个下午定位问题解决之后觉得这个案例很有价值打算写一篇技术博客分享给团队。这时候问题来了。你的参考资料分散在哪里线上问题排查时你翻过的官方文档链接在某浏览器标签页里自己总结的排查思路写在公司Wiki某个角落之前看过的一篇关于消息幂等性的文章在你的微信收藏里还顺手截图过一段源码分析。你花了半小时翻找发现自己根本没有一个地方能把这几条线索串起来。这不是个别现象。国内外的效率社区里知识工作者普遍面临三个困境第一收集与整理脱节。收藏、截图、摘录的成本极低但整理、归档、关联的成本很高。大多数人收藏之后再也没看过那些内容导致收藏越多检索越难。第二笔记之间没有联系。传统笔记本按文件夹分类一篇笔记只能放在一个位置。但真实的知识结构是网状的不是树状的——一个消息队列的问题可能同时涉及网络、分布式一致性、操作系统和编程语言。单靠文件夹管理知识点之间很难产生化学反应。第三写作时没有素材流。真正写文章时你需要的不只是“知道”某个知识点而是能快速调出相关的、经过自己思考加工过的素材。如果你平时的笔记只是复制粘贴原文没有自己的转述和思考写文章时依然无从下手。卡片盒笔记法的设计目标恰好就是解决这三件事。它的重点不是帮你更好地收藏而是帮你建立一套从阅读到思考再到输出的流水线。它要求你把知识拆成一个个可以独立存在、又能互相连接的小卡片然后用链接把它们编织成网。这套方法最早由德国社会学家尼克拉斯·卢曼Niklas Luhmann在实践中完善——他靠着这个笔记系统30年出版了70多本书写了400多篇论文。你当然不需要像卢曼那样写70本书但如果你需要写技术博客、整理技术方案、维护个人知识库或者只是希望在下次写总结时不再从头翻找素材卡片盒笔记法就值得你花时间了解。而《写作系统》这本书从书名看就是在尝试把这套方法从理论变成可操作的案例集。2. 卡片盒笔记法从“存笔记”到“生成思想”的转变很多第一次接触卡片盒笔记的人都会问这样一个问题它和我用备忘录、Word、OneNote记笔记有什么区别先说结论传统笔记是“存储导向”的卡片盒笔记是“思考导向”的。存储导向的意思是你用文件夹把信息归类目的是以后能找回来思考导向的意思是你写卡片的目的是为了在与旧笔记的碰撞中生成新想法写下来只是这个过程的中间产物。卢曼的卡片盒笔记法核心可以拆解为三条原则。第一原子化Atomicity。每张卡片只记录一个想法、一个事实、一个论据。不要在一张卡片里塞进三个观点。这样做的直接好处是卡片之间可以任意组合形成不同的文章结构。如果你的卡片是一篇五千字文章的搬运它就无法在另一个语境里被复用。第二链接优先Link-first。卡片与卡片之间通过链接形成网络。卢曼的卡片盒里一个想法往往跟在相关想法的后面形成一个持续生长的链条。你不需要提前设计好分类体系靠链接天然就能形成结构。这一点类似超文本的思想也类似Git里通过引用把提交串成历史线的关系。第三自下而上Bottom-up。传统写作是先有提纲再去填充内容卡片盒写作反过来是从大量卡片中逐渐发现主题再组织成文章。你平时只管往卡片盒里添加经过自己思考的卡片等到卡片积累到一定程度主题和脉络会自动浮现。这时候你做的更多是选择和组织而不是凭空创造。这三条原则对应到技术写作场景里可以这样理解原子化意味着你读一篇关于分布式事务的文章时不要写一张“分布式事务总结”的大卡片而是分别写“两阶段提交的阻塞问题”“TCC方案的空回滚”“本地消息表的实现思路”。每一个都是独立的知识点以后可以被不同的文章复用。链接优先意味着当你写“本地消息表”这张卡片时要主动添加链接到“可靠消息最终一致性”“事务消息”“消息重复消费”等相关卡片。这些链接就是未来的文章骨架。自下而上意味着你不需要一开始就决定“我要写一篇关于分布式事务的文章”而是当你的卡片盒里积累了大量事务、消息、一致性相关的卡片之后你自然会看出其中的联系那时再决定要不要成文。这套理念本身并不复杂真正难的是执行。而市面上的问题恰恰在于讲理念的书和文章很多一步步带着你操作、展示完整案例的很少。这就回到了我们最初的问题《写作系统》这本书在实操案例上到底做得怎么样3. 判断一本笔记工具书是否适合入门的三个标准在没拿到《写作系统》全书内容之前谁也不敢说它一定适合所有人。但从书名和定位来看可以给出一个合理的判断框架。如果你正在犹豫要不要把它作为卡片笔记的入门书建议按下面三个标准来审视。标准一是否讲清楚了“为什么”。一本入门书首先要回答的不是“怎么做”而是“为什么这么做”。如果一本书只教你如何建笔记、打标签、做链接却不解释原子化背后的信息论原理不解释链接为什么比文件夹更适合知识生长那它只能算工具手册不能算方法论著作。从《写作系统》的标题看它把卡片盒实操案例放在副标题位置暗示内容重心在“案例”和“实操”。这并不意味着它不讲原理但读者需要留意的是它讲原理的篇幅有没有足够支撑后面的实操。如果案例很多、原理薄那更适合有一定了解的人做进阶参考如果案例背后都附带了清晰的原理说明那么作为入门完全没问题。标准二是否提供了可复制的案例。这里说的案例不是“我建议你这么记”这种话术而是完整的、带有上下文和思考过程的示例。比如一个关于“如何从三篇阅读笔记生成一篇评论文章”的完整演示原始文本是什么、你如何写文献笔记、如何转化为永久笔记、如何添加链接、如何从16张卡片中选出一篇文章的大纲。如果一本书能有三个以上这样的完整案例它的实操价值就非常高因为你可以照着它走一遍全流程。这其实很像编程领域的技术书。教Spring Boot的书如果只有理论讲解读者很难真正学会但如果有完整的Demo项目从零写到部署读者的上手速度会快很多。《写作系统》的卖点既然是“更多实操案例”那么它在这一点上是否做得足够扎实是评估它能否作为入门书的最重要维度。标准三是否处理了常见误区。卡片笔记法流行之后出现了很多被误解的实践。比如认为“卡片越多越好”“必须用某个特定软件”“所有笔记都要做永久笔记”“链接越多越厉害”。一本负责任的入门书应该明确指出哪些是误区、哪些是边界。如果一本只讲怎么做、不讲哪里容易做错的书读者很容易在实践时踩坑后放弃。这三个标准也是你自己检验任何知识管理类书籍的通用标尺。不管最终选择哪本书用这三个维度去筛选基本不会错。4. 一张表看懂卡片盒笔记里的三类卡片分工抛开《写作系统》这本书具体写了什么卡片盒笔记法本身有一套比较稳定的核心概念。无论你是准备读书还是准备直接开始实践先理解这几类卡片会很有帮助。在卢曼卡片盒笔记法及其现代变体中通常存在三类卡片文献笔记、永久笔记、索引笔记有时也叫结构笔记。它们在流程中的位置不同用途也不同。卡片类型什么时候写写什么内容存到哪里是否进入最终文章文献笔记Literature Note阅读文章、书籍、代码时用自己的话记录原文的核心观点附上出处单独的地方不放进正式卡片盒通常不直接使用作为素材来源永久笔记Permanent Note阅读后或思考时一个完整的、自解释的想法必须用自己的语言写正式卡片盒是文章的基本材料索引笔记Structure Note / Index卡片积累到一定量时把一组相关卡片组织成一个主题入口正式卡片盒作为导航可以作为文章大纲的雏形文献笔记和永久笔记的区别最容易被新手忽略。说到底文献笔记是“转述别人的观点”永久笔记是“生成自己的想法”。如果你读完一篇文章只是摘抄了一段话那是文献笔记如果你结合自己的项目经验写下了“这解释了为什么我们上次用两阶段提交时性能下降那么严重”那是永久笔记。前者是原材料后者才是产出。索引笔记可以做类比它就像代码仓库里的README。README本身不包含核心业务逻辑但会告诉你哪些目录存放哪类代码如何快速找到入口。索引笔记负责把散落在各处的卡片按主题聚合让你不需要记住每张卡片的编号就能顺着索引找到一组相关内容。很多新手头疼的问题是什么时候该写文献笔记什么时候该写永久笔记有一个很实用的判断标准当你合上文章能用一两句话讲清楚这篇文章在说什么那就写出文献笔记如果你还能把它和你已有的知识或项目经验联系起来产生了一个新的角度或疑问那就值得写一张永久笔记。这套分类不是必须照搬的教条但它是理解卡片盒笔记法的一个很好用的脚手架。有了这层认知你再去看《写作系统》这类书时会更容易判断它讲得到不到位。5. 不依赖某本书也能跑通的最小卡片盒实践方案很多人读完关于卡片盒笔记法的文章之后第一反应是好有道理但我该怎么开始这里给出一套不依赖任何特定书籍、也不依赖任何付费软件的最小实践方案。只要你有一台电脑能装一个文本编辑器就足够了。5.1 工具选型原则卡片盒笔记法的核心价值在方法论不在工具。你完全可以用免费的 Markdown 编辑器 文件夹 Git 搭建一套够用的系统。推荐使用 Markdown 而不是 Word原因有三个Markdown 是纯文本跨平台、跨软件通用永远不会因为软件停止维护而丢失。Markdown 支持双链语法[[文件名]]可以用 Link 把卡片连接起来。Markdown 方便配合 Git 做版本管理每次修改都有历史记录。5.2 目录结构与命名规则用最朴素的方式在本地创建一个文件夹作为你的卡片盒zettelkasten/ ├── 1-inbox/ # 临时收集每天整理 ├── 2-literature/ # 文献笔记按作者文章名命名 ├── 3-permanent/ # 永久笔记按时间戳关键词命名 ├── 4-structure/ # 索引笔记按主题命名 └── templates/ # 卡片模板这里有个重要的命名规则需要特别说明永久笔记的文件名不要用“分布式事务”这样的大主题词建议用日期时间戳加简短说明例如20250204-消息重复消费的幂等设计.md。为什么不用主题词命名因为同一个主题下的笔记会越来越多主题词文件名的可扩展性很差。而且如果你用主题词做文件名很容易在写卡片时下意识地想去“归类”这又回到了文件夹思维的陷阱。用时间戳命名可以让每一张卡片都是一个独立的、平等的节点真正的关系靠正文里的链接表达。5.3 永久笔记模板以下是一个经过简化的永久笔记模板适合技术写作场景--- type: permanent tags: [分布式, 消息队列] created: 2025-02-04 --- # 消息重复消费的幂等设计 ## 想法核心 在消息队列消费端重复消息不可避免业务侧必须通过幂等设计 来保证多次处理的结果与一次处理一致。 ## 背景 订单系统在消费者重启时可能因为未提交偏移量而重新拉取消息。 ## 连接到 - [[消费端手动提交偏移量的风险]] - [[数据库唯一索引实现幂等]] - [[本地消息表的实现思路]] ## 可能的写作用途 - 消息队列实战系列 - 分布式系统的可靠性设计画重点type字段标记这是一张永久笔记。tags是检索辅助不是分类是用来补充上下文标签。想法核心是卡片的灵魂必须用你自己的话写。连接到是卡片之间的链接是将来组织文章的关键。可能的写作用途是一个很有用的字段写的时候可能用不上但积累多了以后会帮你更快地识别主题。5.4 文献笔记模板文献笔记不需要追求完整它的作用是记录“我看过这篇文章它讲了这些”并给永久笔记提供素材。--- type: literature source: https://example.com/distributed-transaction-article author: xxx created: 2025-02-04 --- # 分布式事务文章阅读摘要 - 作者用三个小节讲了分布式事务的三种实现方案。 - 核心观点没有一种方案能同时保证强一致性、可用性和性能。 - 我标注的重点两阶段提交的阻塞问题Saga的补偿设计。 - 相关想法见[[两阶段提交在订单系统的适用性分析]]文献笔记和永久笔记最理想的关系是文献笔记是引子永久笔记是产物。当你从文献中产生了一个新想法时不要在那个想法后面写完就结束了而是应该独立创建一张永久笔记让它未来可以被其他文献笔记链接到。5.5 Git 版本管理卡片盒的内容是你的数字资产应该纳入版本管理。用 Git 管理卡片盒非常简单cd zettelkasten git init git add . git commit -m 初始化卡片盒 git log --oneline后续每次整理完一批卡片都可以提交一次。建议养成的习惯是每天花 10 分钟清空 inbox每周做一次 commit。这样你的卡片历史就有了完整的演化轨迹如果哪次批量修改出了问题也可以直接回滚。机器性能允许的话还可以把仓库推到自己的私有 Git 远程仓库做异地备份。注意这里强调“私有”——卡片盒里往往有大量个人想法和未公开的资料不建议放到公开仓库。6. 用 Python 脚本辅助卡片管理和链接检查卡片积累到几百张之后人工检查链接是否断裂、索引是否完整会变得很吃力。这里提供两个轻量脚本用 Python 标准库实现不需要安装任何第三方依赖。6.1 检查断链脚本这个脚本遍历3-permanent目录下的所有 Markdown 文件抽取双链语法[[文件名]]检查目标文件是否存在于本仓库中。 文件路径scripts/check_links.py 用法python scripts/check_links.py /path/to/zettelkasten import os import re import sys LINK_PATTERN re.compile(r\[\[([^\]|#])) def collect_md_files(root): md_files {} for dirpath, _, filenames in os.walk(root): if templates in dirpath: continue for name in filenames: if name.endswith(.md): full_path os.path.join(dirpath, name) key os.path.splitext(name)[0] md_files[key] full_path return md_files def check_links(root): md_files collect_md_files(root) broken [] total 0 for dirpath, _, filenames in os.walk(root): if templates in dirpath: continue for name in filenames: if not name.endswith(.md): continue full_path os.path.join(dirpath, name) with open(full_path, r, encodingutf-8) as f: content f.read() links LINK_PATTERN.findall(content) for link in links: total 1 if link not in md_files: broken.append((full_path, link)) return broken, total if __name__ __main__: root sys.argv[1] if len(sys.argv) 1 else . broken, total check_links(root) print(f共检查 {total} 个链接发现 {len(broken)} 个断链) for path, link in broken: print(f {path} - 缺少 [[{link}]])运行方式python scripts/check_links.py /path/to/zettelkasten预期输出共检查 128 个链接发现 3 个断链 /path/to/zettelkasten/3-permanent/20250118-xx.md - 缺少 [[未创建的卡片名]]这里有一个判断需要提前说明检查脚本发现的“断链”并不一定表示出错。在卡片盒实践里在链接处写一个还没创建的卡片名本身就是一种写作思路标记表示“这里未来应该有一张卡”。所以脚本的定位是帮你发现并确认这些提前占位再决定是创建对应卡片还是删除这个无效链接。6.2 生成随机卡片入口脚本有时你会面对一堆卡片不知从哪里开始。一个有趣的实践是“随机抽取卡片”随机抽三张尝试把它们连接成一个新的想法。这在卢曼卡片盒的实际使用中是一种自下而上寻找主题的方法。 文件路径scripts/sample_cards.py 用法python scripts/sample_cards.py /path/to/zettelkasten 3 import os import random import sys def get_permanent_cards(root): card_dir os.path.join(root, 3-permanent) if not os.path.isdir(card_dir): return [] cards [] for name in os.listdir(card_dir): if name.endswith(.md): cards.append(os.path.join(card_dir, name)) return cards if __name__ __main__: root sys.argv[1] if len(sys.argv) 1 else . n int(sys.argv[2]) if len(sys.argv) 2 else 3 cards get_permanent_cards(root) if len(cards) n: print(f卡片数量不足当前有 {len(cards)} 张需要 {n} 张) sys.exit(1) samples random.sample(cards, n) for path in samples: print(os.path.basename(path)) with open(path, r, encodingutf-8) as f: first_line f.readline().strip(# \n) print(f - {first_line})运行方式python scripts/sample_cards.py /path/to/zettelkasten 3预期输出20250112-数据库唯一索引实现幂等.md - 数据库唯一索引实现幂等 20250120-消费端手动提交偏移量的风险.md - 消费端手动提交偏移量的风险 20250128-本地消息表的实现思路.md - 本地消息表的实现思路随机抽卡这个动作听起来没什么技术含量但它确实有效。当你积累了一批卡片后把毫不相关的卡片放在一起经常能发现意外的关联。做技术写作时这种意外关联往往就是文章创新点的来源。7. 从卡片到成稿用写作系统支撑一篇技术文章现在回到最开始那个订单系统消息重复消费的场景。假设你已经用了卡片盒笔记法一段时间卡片盒里积累了一批相关卡片你会如何写出一篇完整的技术博客7.1 写作前卡片聚合你要写的文章主题是“消息队列消费端的幂等设计”。这时候不要从空白文档开始而是先在卡片盒里检索所有相关卡片。在已有的实践里可能会找到这样几张消息重复消费的幂等设计消费端手动提交偏移量的风险数据库唯一索引实现幂等本地消息表的实现思路Redis SETNX 实现幂等的优缺点我的线上幂等设计失误复盘这六张卡片已经天然构成了一篇文章的骨架。注意这个过程中的关键动作是“检索和组织”而不是“凭灵感创作”。卡片盒最大的价值就在于此它把写作从一种“灵感的赌博”变成了一种“素材的组织”。7.2 写作中大纲生成接下来从这六张卡片中提炼文章大纲。这里用到一个很实用的方法把索引笔记当作大纲草稿。一个简单的做法是新建一张结构笔记列出文章的小标题然后为每个小标题关联卡片# 大纲消息重复消费的幂等设计实战 ## 1. 背景消费者重启引发线上重复消息 - 关联[[消费端手动提交偏移量的风险]] - 关联[[我的线上幂等设计失误复盘]] ## 2. 重复消息为什么不可避免 - 关联[[消息队列的 At Least Once 语义]] ## 3. 三种幂等方案对比 - 关联[[数据库唯一索引实现幂等]] - 关联[[Redis SETNX 实现幂等的优缺点]] - 关联[[本地消息表的实现思路]] ## 4. 实践总结 - 关联[[消息重复消费的幂等设计]]从这张结构笔记出发写文章时就非常轻松了。每个小节都有现成的素材你只需要用自己的语言把卡片串成一个连贯的叙述。7.3 写作后卡片回填文章发布之后还有一个很多人忽略的收尾动作把文章本身写成一张卡片或者至少建立文章与相关卡片的反向链接。这样下次当你要写一个更宏观的主题比如“分布式系统可靠性设计”时这篇成文又能作为一张更完整的素材被检索到。这个回填动作极其重要。它让写作的产出重新变成卡片盒输入形成正向循环。如果你只是写文章而不回填卡片盒就只是单向消耗素材没有复利效应。8. 常见问题与排查思路卡片盒笔记法实践过程中几乎每个人都会遇到下面这些问题。整理成一个排查表供你对照。问题现象可能原因排查方式解决方案卡片写了不少但写文章时还是没素材写的大多是文献笔记缺少自己的永久笔记检查永久笔记数量占卡片总量比例每读完一篇资料强制写至少一张用自己的话表达的永久笔记链接很多但全是死链和随手链接为链接而链接没有考虑卡片之间的真实逻辑关系抽查链接目标看两个卡片放在一起是否有意义只在写下“这张卡片补充了另一张的某个角度”时才加链接分类混乱不知道卡片该放哪个文件夹还在用文件夹思维管理卡片检查目录是否超过三层、文件命名是否用主题词回归原子化原则带时间戳命名并把连接交给正文中的双链用了一段时间坚持不下去一开始设定了过高的整理目标回看制定规则时是否要求每篇文献都做完整卡片降低标准先保证每周写 2-3 张高质量永久笔记比追求数量更重要卡片内容太长几乎是一篇文章没有拆分成原子化检查单张卡片是否包含多个想法把每张卡片压缩为一个想法多余想法拆分成新的卡片并互链这里面最值得强调的一点是卡片数量不是目标。卢曼的卡片盒之所以有用不是因为他写了九万张卡片而是因为这九万张卡片编织成了一个可以持续生成思想的网络。对普通技术写作者来说一年积累三四百张高质量的永久笔记已经足够支撑相当可观的技术文章产出。9. 最佳实践与工程建议结合长期实践下面几条建议对想要入门的读者最有用。第一先跑通最小闭环再追求流程完整。不要等到读完所有关于卡片盒的资料才开始实践。用一个周末搭建最简单的 Markdown Git 卡片盒写五张卡片尝试从这五张卡片里找出一篇短文的骨架。先跑通这个闭环你对卡片盒笔记法的理解会明显加深。第二强制“用自己的话”写作。永久笔记最忌讳直接摘抄原文。你可以引用一小段但卡片的主体必须是把原文掰开揉碎后用你的语言重写。这不仅是知识管理的要求更是认知训练一个人如何用自己的话表达决定了TA是否真正理解了那个概念。第三每周做一次回顾和整理。建议把这作为固定习惯每周抽 30 分钟清空 inbox把临时的想法转化为正式卡片检查是否有断链需要处理顺便看看最近一周的卡片里是否出现了新的主题。这一步能防止卡片盒在积累中变得混乱。第四注意隐私与备份。卡片盒里可能有个人思考和未公开的技术方案建议使用私有仓库存储并养成定期 Git 提交的习惯。如果使用云同步盘最好加密或至少确认云服务商的隐私条款。第五适合自己的方法才是好方法。卡片盒笔记法的理念是清晰的但具体到每个人原子化到什么粒度、链接写多少、索引怎么建都需要在实践里调整。你可以从通用模板开始但在使用两周之后一定要根据自己写技术文章的规律改出一套属于你自己的模板变量。第六用 AI 工具辅助而不是替代思考。在卡片创作阶段可以先用 AI 生成初步的摘要和结构化要点但最终放入永久笔记的内容必须有你自己整合后的判断。在卡片检索和组合阶段AI 可以帮助你找出主题、推荐可能相关但你又遗忘的卡片这样可以很大程度上缓解“笔记多了找不到”的痛点。但请注意不要把 AI 生成的总结当成你的永久笔记直接入库那样你会失去卡片盒笔记法里最重要的“加工”环节。10. 回到最初的问题《写作系统》值得作为入门书吗现在我们可以给这篇文章最开始的问题一个较完整的回答。判断一本讲卡片笔记的实操书籍能否作为你的入门书关键看三条是否讲清楚了“为什么”而不只是“怎么做”、是否提供了可以照着走一遍的完整案例、是否指出了常见的误区。从《写作系统》的定位来看它把大量篇幅放在实操案例上这正好是对市面上很多“理论有余、案例不足”的笔记书籍的一种补充。如果你已经看过一些卡片盒笔记法的理论文章急需用完整案例把所有环节串起来这本书的实操属性会更契合你的需求。如果你是完全的新手对卡片盒笔记法的基本概念都不太熟悉那么建议你先用本文前四章的内容建立基础认知再配合本书的案例动手实践。无论最终使用哪本书或哪套方法都请记住卡片盒笔记法的本质它不是收藏工具而是一个生成思想的系统它的目的不是存储知识而是让知识在使用中产生新的洞见。你不需要等一本书读完才动手最好的开始时间就是你坐下来写下第一张永久笔记的今天。下一步建议很具体建一个空文件夹复制上文给出的模板写三张卡片一张关于你最近修复的一个线上 Bug一张关于你最近读到的一篇值得记住的博客一张关于你明天可能要写的文章大纲。然后给它们建立至少两条互相引用的链接。这一步完成之后你对卡片盒笔记法的理解会比读任何书的前三章都来得深刻。