我在Obsidian里攒了三年的东西，直到开始写作，它们才真正活了

我在Obsidian里攒了三年的东西，直到开始写作，它们才真正活了

——"赛博时代的认知进化论"系列 第六篇

这个系列的第五篇发出去之后，我收到了很多私信。

其中有一条，让我盯着屏幕看了很长时间。

发信人是一个做产品经理的读者，她说：

"阿木木，我把你说的那些都做了。用AI苏格拉底法逼出了隐性知识，删掉了文件夹，装了Smart Connections，还建了Dataview仪表盘。我的Obsidian库现在有将近八百条笔记，连接很密，看起来很漂亮。

但我一篇文章都没写出来。

我感觉我的库就像一个很贵的健身房会员卡——我每天去打卡，我知道里面的器械都很好，但我不知道我练出来的东西，到底有没有用。"

我把这条私信转进了Obsidian，标题是：“一个库满为患却无法输出的人”。

然后我在下面写了一句话：

这是我三年前的样子。

2021年，我的Obsidian库刚刚起步。我花了大量的时间在构建这个系统，读了大量关于PKM的文章，把所有的方法论都试了一遍。那段时间，我对这个库的热情是真实的，但热情的方向出了问题。

我在建一个越来越精密的系统，却没有问自己一个最基本的问题：

这个系统，最终是为了产出什么？

直到有一天，我参加了一个技术社区的征文活动。主题是"微服务实践中的那些坑"。我心想，这不正是我最擅长的吗？我有大量的实践经验，我的Obsidian库里也记录了很多相关的笔记。

我打开库，想把那些笔记"拼"成一篇文章。

然后我发现了一个让我颇为尴尬的事实：

我有很多笔记，但它们都是碎片。每一条单独看都有道理，但把它们放在一起，根本无法形成一篇有逻辑、有温度、能让人看下去的文章。

它们是建筑材料，但我不知道怎么盖房子。

我那次没有投稿。

那次失败之后，我开始认真思考一个问题：

知识库和写作之间，到底缺了什么？

我花了很长时间，才在一本书里找到了那个缺失的东西的名字。

一、Tiago Forte说了一个被大多数人跳过的步骤

Tiago Forte的《打造第二大脑》（Building a Second Brain）是PKM领域最流行的书之一。它提出了一个著名的框架，叫做CODE：

Capture（捕捉）→ Organize（组织）→ Distill（萃取）→ Express（表达）

这个系列的前五篇，我们聊的基本上是前三个步骤。

怎么捕捉你的隐性知识（第一篇）。 怎么组织你的知识网络（第二篇）。 怎么通过主题阅读萃取深层洞察（第三篇）。 怎么维护让知识不腐烂（第四篇）。

但Express（表达），我几乎没有认真讲过。

Forte在书里有一个观点，但大多数人读到这里已经兴奋于前面的方法论，把这一步当成理所当然地跳过了：

表达，不是知识管理的终点，它是知识管理中最重要的一个环节。

他说，知识如果不经过表达，就永远无法被真正检验。你以为你理解了某件事，但只有当你试图把它写出来、说出来、画出来的时候，你才会发现你理解的漏洞在哪里。

这句话，我在第一次读到的时候，理解是浅的。

但在那次征文失败之后，我彻底明白了他说的是什么。

我以为我理解了我的那些笔记，但当我试图把它们组织成一篇文章的时候，我发现我其实只是在储存它们，从来没有真正理解过它们。

理解，需要在表达的过程中完成。

但我想在Forte的这个洞察上，再往前走一步。

因为我后来读到了另一本书，一本比Forte的书更早、更根本地触及这个问题的书。

这本书叫做**《每一页都是第一页》（Every Page is Page One）**，作者是Mark Baker。

Baker是一个技术文档专家，这本书表面上是在讲如何写技术文档，但它的核心洞察，适用于所有形式的知识输出：

在搜索时代，读者不是从第一页开始读你的文章的。他们从Google搜索进来，直接落在某一个具体的页面上。那个页面，必须是自洽的——它必须独立成立，不依赖任何上下文，直接回答读者带着来的那个问题。

Baker的这个洞察，对我产生了一个根本性的冲击：

我的Obsidian库里的笔记，每一条都是"某一页"。但我的读者，是我自己。

当我试图写一篇文章的时候，我其实是在扮演一个搜索用户——我带着一个问题（“我想写一篇关于XX的文章”），进入我的库，试图找到能回答这个问题的内容。

但我的库里的内容，很多都不是"自洽的"。

它们是碎片化的思考，依赖大量我自己才知道的上下文。一条笔记单独看，我自己都看不懂当时在想什么。

一个对写作者来说无法检索的知识库，不管它内部有多少连接，对写作都没有价值。

这是我征文失败的真正原因。

二、写作不是知识管理的下游，它是知识管理的一部分

在解决这个问题之前，我需要先推翻一个几乎所有人都默认成立的前提：

写作，是在知识管理之后发生的事情。

这个前提的逻辑是：先积累知识，再产出内容。先有input，再有output。先建库，再写文章。

这个逻辑，我曾经深信不疑。

但它是错的。

正确的逻辑应该是这样的：

写作，是知识管理中最高效的一种形式。

不是先管理，再写作。写作本身，就是管理。

我来解释这是什么意思。

你在Obsidian里记了一条笔记：“系统的复杂度只能被转移，不能被消灭。”

这条笔记，在你没有试图用它来解释某件事情之前，你不知道你真正理解了它还是只是记住了它。

但当你试图用它来写一段文章——当你试图向一个没有这个背景的读者解释这句话的时候——你会发现：

你必须找到一个具体的例子。你必须解释"转移"是什么意思。你必须回答"如果只是转移，那有什么意义"这个读者一定会提出的问题。

在这个过程里，你可能会发现你的例子站不住脚，你的解释有漏洞，你的结论需要被修正。

你以为你在写作，实际上你在做最深度的一次检视阅读——对你自己的知识做检视阅读。

这是写作者和读书者最本质的区别：

读书者把别人的知识装进来。 写作者把自己的知识逼出去，在逼出去的过程中，发现装进来的东西哪里是错的、哪里是空的、哪里是真实的。

费曼有一个著名的学习法则，叫做**“费曼技巧”**：如果你不能用简单的语言向一个外行解释某件事，你就没有真正理解它。

写作，是对费曼技巧的实践。你的读者，是你理解深度的测量仪。

明白了这一点，我回头看那次征文失败，有了完全不同的理解。

我当时的问题，不是库里的东西不够多。

是我从来没有试图用库里的东西向任何人解释任何事情，所以我不知道那些东西哪里是真实的，哪里是幻觉。

我的库，是一个从来没有被测试过的系统。

我以为它很稳，因为它看起来很稳。

但所有程序员都知道：没有被测试过的代码，不叫稳定，叫没有暴露问题。

三、一次真实的写作过程，和它暴露出来的所有问题

让我带你看一次真实的写作过程。

不是那种行云流水的理想状态，是那种一开始就卡住、中间发现自己根本不懂、最后磕磕绊绊写出来的真实过程。

前几个月，我想写一篇关于"技术债务"的文章。这是我很熟悉的主题，我在工作中处理技术债务的经验也很丰富，库里有大量相关笔记。

我坐下来，打开一个新的文档，写下了标题：

“技术债务：你以为你在借钱，其实你在透支身体”

然后我开始写第一段。

写了三句话，我停下来了。

因为我意识到，我写的这三句话，是"关于技术债务的正确废话"——每个人都知道的东西，没有任何信息量，没有任何我自己的东西在里面。

我重新打开Obsidian，搜索"技术债务"，找到了我所有相关的笔记，大概有二十三条。

我开始逐条看。

看到第七条的时候，我发现了一个问题：

我有一条笔记说：“技术债务应该被量化，用代码复杂度指标来衡量。”

我有另一条笔记说：“技术债务的真正成本不在代码本身，在于它对团队速度的拖慢，而这几乎无法被量化。”

这两条笔记，互相矛盾。

它们写于不同的时间，来自不同的场景。我当时把它们分别记下来，觉得都有道理，但从来没有把它们放在一起看过。

我在库里打开这两条笔记，在中间建了一条新的笔记，标题是：

“技术债务能被量化吗？——一个我还没想清楚的矛盾”

然后我继续往下读那二十三条笔记。

发现了三个类似的矛盾。

用了将近一个小时，我没有写出任何一段正式的文章内容，但我在库里新建了五条笔记，修改了两条旧笔记，发现了三个我以为自己理解但实际上没有想清楚的问题。

然后我做了一件事，这是我后来写作流程里最重要的一步：

我把那三个矛盾，原封不动地写进了文章里。

不是作为问题，而是作为文章的核心结构。

最终那篇文章的结构是这样的：

开篇： 一个具体的故事，我们团队因为技术债务导致的一次线上事故。

第一个矛盾： 技术债务应该被量化，还是本质上无法被量化？（把我库里那两条矛盾的笔记的思考过程，完整地还原给读者）

第二个矛盾： 技术债务是应该被立刻偿还，还是应该被战略性地保留？（很多创业公司的快速发展，恰恰依赖于"主动选择"的技术债务）

第三个矛盾： 谁应该为技术债务负责？（是当初写出这段代码的工程师，还是要求他"快点上线"的产品经理，还是那个压缩了时间表的管理层？）

结尾： 把这三个矛盾汇聚成一个更深层的问题——技术债务不是技术问题，它是组织问题，是决策问题，是一个系统在什么条件下愿意为未来投资的问题。

这篇文章，是我写过的转发量最高的技术文章之一。

很多评论说：“终于看到一篇不是教你怎么消灭技术债务，而是真正在讨论技术债务是什么的文章。”

但这篇文章真正的来源，是我在Obsidian里发现的那三个自相矛盾的笔记。

如果不是因为试图写这篇文章，我永远不会把那二十三条笔记放在一起看。我永远不会发现那三个矛盾。我永远不会想清楚那三个矛盾背后的深层问题。

写作，逼出了我的Obsidian库里本来已经在那里、但我自己都没有意识到的东西。

四、让AI成为你的"第一个读者"

在我真正理解了"写作是知识管理的一部分"这件事之后，我的写作流程发生了一个根本性的变化。

我不再试图先把所有笔记整理好，再开始写。

我开始带着问题进入写作，在写作中发现知识的漏洞，然后用库和AI来填补这些漏洞。

整个流程是这样的：

Step 1：从一个真实的困惑开始，而不是从一个主题开始

很多人写文章的起点是：“我想写一篇关于XX的文章。”

这是一个主题，不是一个问题。

从主题出发的写作，往往变成知识的罗列——你把你知道的关于这个主题的东西，按照某种顺序堆在一起。

从困惑出发的写作，才能产生洞察——因为你在试图回答一个你自己还没有想清楚的问题。

在Obsidian里，把你想写的文章，先写成一个问题。

不是"我想写技术债务"，而是： “为什么我们团队每次说’下个版本要还技术债务’，下个版本却永远有更紧急的事情？这是时间管理问题，还是有更深层的原因？”

这个问题，才是你真正想写的东西。

Step 2：在Obsidian里做"写前侦察"

带着这个问题，在库里做一次侦察，而不是整理。

侦察和整理的区别：

整理是把相关内容找出来，按顺序排好，准备"用"它们。 侦察是带着问题扫描相关内容，专门找矛盾、意外和漏洞。

你在找的，不是能支持你观点的笔记，而是能挑战你观点的笔记。

用这个Prompt让AI帮你做侦察：

text

1
2
3
4
5
6
7
8
9
10
11
12
13
14
以下是我库里关于[主题]的笔记：

[粘贴相关笔记的标题和核心观点]

我想写的文章要回答这个问题：
[你的核心问题]

请帮我做三件事：
1. 找出这些笔记里相互矛盾的地方
2. 找出这些笔记里有明显漏洞、没有考虑到某个重要反例的地方
3. 告诉我：如果我现在就用这些笔记写文章，
   一个认真的读者最可能提出的反驳是什么？

不需要帮我填补这些漏洞，只需要指出它们。

AI指出的矛盾和漏洞，不是你写作的障碍。

它们，就是你文章的骨架。

Step 3：用"笨方法"写第一稿——不用任何AI

这是整个流程里唯一一个我坚持不用AI的步骤。

我知道这听起来很反直觉。我一直在强调AI的价值，但在写第一稿的时候，我刻意不用AI。

原因很简单：

第一稿是你和你自己的对话。你在试图把你脑子里的东西逼出来，检验你真正理解了什么，没有理解什么。

如果你用AI来帮你写第一稿，你会得到一篇流畅的、结构合理的文章。但那篇文章检验的是AI的理解，不是你的理解。

你会跳过那个最痛苦但最有价值的过程：在写不下去的地方停住，意识到你其实不懂，然后去真正搞懂它。

写不下去的地方，是你的知识漏洞的精确坐标。

每次你写到卡住了，不要去找AI帮你写，而是在Obsidian里建一条新笔记，标题是你卡住的那个问题。

然后用AI苏格拉底法——就像我们在第一篇里说的——去把那个问题追问清楚。

追问清楚了，再回来继续写。

这个过程很慢，很痛苦，但每一次卡住，你都在给你的Obsidian库增加一条真正有价值的笔记，而不是一条你不知道自己不理解的笔记。

Step 4：把AI当成你最挑剔的编辑，而不是你最顺从的助手

第一稿写完之后，把它发给AI，但不要用这个Prompt：

text

1
2
3
❌ 帮我优化这篇文章
❌ 帮我让这篇文章读起来更好
❌ 帮我扩写这篇文章

用这个Prompt：

text

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
你是一个极度挑剔的读者，你的工作是找出这篇文章里所有的问题。

请从以下几个维度批评我的文章：

1. 逻辑漏洞：哪些地方的论证不成立？
   哪些结论没有被充分支持？

2. 未被回答的问题：读完这篇文章，
   一个认真的读者还会有哪些重要的疑问没有被解答？

3. 过于自信的地方：哪些地方我说得太绝对，
   实际上应该有更多的条件限制？

4. 最薄弱的一段：整篇文章里，
   哪一段是最经不起追问的？

不要告诉我哪里好，只告诉我哪里有问题。

这是你文章真正被强化的地方。

AI找出的问题，你逐条判断：哪些是真实存在的问题，哪些是AI没有理解你的上下文导致的误判。

对于真实存在的问题，你有两个选择：

• 修改文章：把漏洞补上。

• 把漏洞变成文章的一部分：承认这是一个你还没有想清楚的问题，直接写进文章里。

第二个选择，往往比第一个选择更有价值。

一篇承认自己局限性的文章，比一篇假装自己已经解决了所有问题的文章，更值得被信任。

Step 5：写完文章之后，把文章"拆回"Obsidian

这是大多数人从来没有想过的一步。

文章写完、发布，大多数人的逻辑是：写作流程结束了。

但我的逻辑是：文章发布，是Obsidian库的一次更新时机。

因为这篇文章里，有大量在写作过程中新产生的洞察——那些是在整理笔记的时候不存在的，是在和读者对话的压力下逼出来的。

我会做这几件事：

把文章里最重要的几个核心洞察，拆解成原子笔记，加回库里。

把文章里发现的那些矛盾和漏洞，建成新的"未解决问题"笔记。

把读者评论里有价值的反驳和补充，整理成笔记，连接到相关节点。

读者的评论，是你的知识库里最廉价也最宝贵的测试数据。

他们指出的问题，是你自己看不见的盲区。他们补充的经验，是你自己没有经历过的场景。

一篇文章发出去之后，你的库应该比发出去之前更丰富，而不是停在原地。

五、一个让我重新理解"个人IP"的视角

说到这里，我想讲一个让我重新理解这整件事的视角转变。

很多人建立个人IP的逻辑是这样的：

积累足够多的知识 → 输出足够多的内容 → 建立足够大的影响力

这个逻辑的底层假设是：你的IP，是你知识的外部展示。

但我越来越觉得，这个逻辑是倒过来的。

真正持久的个人IP，不是你的知识展示，而是你的思维方式的展示。

读者关注你，不是因为你知道的比他们多——在AI时代，这个理由越来越站不住脚了。

读者关注你，是因为你思考问题的方式，让他们感到被击中，或者感到被挑战，或者感到有了一个新的视角去看他们自己的问题。

而你的思维方式，恰恰不在你的结论里，它在你的推理过程里。

这就是为什么我在这个系列里，一直在写我犯过的错误，走过的弯路，想了三个月才想清楚的问题。

那些东西，不是这个系列的缺陷，那些东西，是这个系列存在的理由。

任何人都可以写"如何用Obsidian管理知识"的教程。但只有我能写"一个叫阿木木的后端程序员，在真实的工作场景里，如何犯错，如何想通，如何慢慢形成了他自己对这件事的理解"的故事。

你的Obsidian库，是你的私有语料。

你的写作，是你用这个私有语料，向外界证明你的推理路径和你的思维方式。

你的个人IP，不是你的名片，是你的思维的实时记录。

写在最后

那个产品经理读者，在我回复她之后，给我发来了一条消息。

她说她开始写了，第一篇文章不长，就两千字，写的是她做过的一个功能，上线之后数据很好，但她一直有个说不清楚的不安，总觉得这个功能虽然让数据好看了，但对用户来说不是真正好的东西。

她用AI苏格拉底法追问了自己，写出了那个"说不清楚的不安"。

“原来我一直觉得这个功能是在优化指标，不是在优化用户。我知道这两件事不一样，但我一直说不清楚哪里不一样。写完才想明白：指标衡量的是用户做了什么，但用户真正想要的是他们做完之后的感受。这个功能让他们点击次数变多了，但他们点完之后感觉更焦虑了，不是更满足。”

她说，这篇文章发出去之后，她的产品经理同事私聊她说，这句话描述的就是他们团队一直有但从来没有说清楚的一个矛盾。

然后他们在下一次需求评审里，把这个矛盾放在了桌面上，正式讨论了一次。

一条两年前说不清楚的直觉，因为写作而被外化，因为被外化而被看见，因为被看见而改变了一次真实的决策。

这，才是知识管理真正应该产生的价值。

不是更漂亮的Graph View，不是更多的双链，不是更精密的系统。

是一个具体的人，在一个具体的场景里，因为想清楚了一件事，做出了一个不同的选择。

我想在最后留给你一个问题，一个我在写完这整个系列之后，开始认真想的问题：

我们这个系列从第一篇开始，一直在谈"如何更好地管理知识"。

但"更好地管理知识"，是为了什么？

是为了写出更多的文章，积累更大的影响力，建立更强的个人IP吗？

这些目标都不坏，但我越来越觉得，它们都不是最重要的答案。

最重要的答案，在那个产品经理的故事里。

一个人想清楚了一件事，然后在一个真实的场景里，做出了一个稍微好一点的决定。

这件事，很小，很具体，很难被量化，没有办法发进简历，没有办法出现在任何KPI里。

但这件事，是所有知识管理真正应该指向的地方。

不是更强的你，而是更好的决定。不是更大的IP，而是更真实的影响。

这两件事，有时候是同一件事，有时候不是。

能分清楚这两件事的人，才能真正平静地面对这件事：

某一天，AI会比你更擅长几乎所有可以被量化的知识工作。

但那个坐在会议室里，因为想清楚了一件事，说出了一句改变了这次讨论走向的话的人——

那个人，依然是你。

感谢你陪我走完这六篇文章。

如果你在这个系列里的任何地方，有任何一个时刻停下来，打开了Obsidian，写下了什么——

哪怕只是一句话——

这个系列，就没有白写。