如何建立自己的PKMS(个人知识系统)

Share
学习的本质就是记忆

纸笔模型

念书的时候很多人都有做笔记的习惯,我也不例外。上课的时候我习惯的会把课堂笔记写在书页的边角,课后再转抄到笔记本上。一方面重抄强化了记忆,另一方面我会在重抄的时候把散落的知识点整理一下,让它尽可能有条理。

课程在编写时有考虑到知识的连贯性,所以对于课程的知识图谱很容易被梳理出来。我把这种模型成为“纸笔模型”。它基于几个假设:

  • 每个知识节点在创建后基本趋于稳定,不会有过多修改。即便有修改,数字化后的纸笔模型也是“修改友好”的
  • 节点之间的联系稳定且有限
  • 完整的知识图谱内容有限,体积不会太大
  • 节点是随时间添加,检索起来也比较方便,比如按教科书章节检索
纸笔模型

纸笔模型的挑战

工作了之后,我也有尝试过很多次做工作笔记,却收效甚微。和学习笔记不太一样,工作中接触到的知识很散乱。更多的时候需要快速学到一个全新的领域知识,然后应用在工作中,然后再学习下一个领域知识,循环往复。学到的知识本身也会随着时间被更新,或者推翻。这些工具/知识之间并不甚相关,导致了知识的碎片化,并且很难被检索。

这时,纸笔模型的假设受到了挑战:知识点之间的联系微弱,需要大量的背景知识来建立,这些知识会导致没有一个完整的图谱,或者一个巨大的图谱;知识点本身会频繁的更新;检索困难,很多时候单纯的关键字检索很难找到所有相关的节点。这三个挑战推向同一个结论:传统的纸笔模型,甚至说数字化后(对更新节点更友好)的纸笔模型已经不适用于工作笔记了。

简言之,传统的纸笔模型更适合一个有主干,有直线,内容有限的叶脉结构——教科书等天然适合使用这种工具。

知识图模型

而如同之前所讨论的,工作之后接触到的很多领域知识是驳杂,正交的。这样的知识图谱就是很多细小碎屑的枝干,缺乏一个主干来统一。这种模型我称之为知识图模型。

知识图模型

知识图模型的一大挑战就是对节点的多维度,联想性检索。在检索节点时,目前绝大多数工具都只能做到关键字检索。很少,或几乎没有工具能够把“与XX”相关联作为条件来检索节点。

举个例子,假如我今天读到了一个知识,通胀与央行加息之间的关系是如何如何。除非我在这个知识节点内放了“通胀”“加息”“贷款”“利率”等等关键字,否则很难在未来的某天,我想了解”贷款利率”与“通胀”之间的关系。

Logseq

一个好的PKMS工具,需要有这种能力,将相关联的碎片信息进行整理,连接,并在我需要的时候,能够通过寥寥几个节点的检索,就能够将整个图谱的内容提取出来,比如能够帮助我从“贷款”联想到“利率”,到“加息”,一直到“通胀”。

这里介绍一个我自己在用的PKMS工具,logseq。logseq是一个markdown驱动的PKM软件。它通过节点间的双向连接生成知识图谱,并且可以通过关键字,标签,页面引用等来对节点进行多个维度的整理。比如上文的例子中,“通胀与央行加息之间的关系”节点中我可以通过#通胀,#加息,#经济 等不同标签使这个节点和不同的节点互通。当然在可视化时,它也能够从根据不同的维度,快速的建立不同的可视化结构。

除此之外,logseq 还可以通过不同的宏把pkms和各种不同的管理工具结合到一起,比如TODO,读书笔记,个人周报等。还可以在TODO中按优先级,ddl进行排序,永远把“最重要”的事项显示给你。也可以按需来添加不同的插件,进行强大的功能拓展。

它既是一个笔记本,也可以是一个日记本,一个知识图归纳器,一个PKMS,一个TODO,等等等等。更多与logseq相关用法,请参考这里

希望这篇文章能对同样挣扎在碎片化知识的小伙伴们提供一种思路,以期早日进入work hard, play hard的状态。

Read more

当代码不再稀缺 - 06

Prompt 不是新的 Source Code A prompt can generate an answer. It cannot, by itself, preserve why the answer should be true. 提示词可以生成一个回答,但它自己并不能证明这个回答为什么是对的 AI coding tools 刚开始流行时,有一个说法很有吸引力: Prompt 是新的 source code。 听起来很合理。 以前我们写 Python、Java、TypeScript;以后我们写自然语言,让模型完成 implementation。既然 prompt 决定 output,那就像管理代码一样把 prompt 保存、version、review,不就行了吗?

By andy
当代码不再稀缺 - 05

当代码不再稀缺 - 05

Code review 没有过时,但我们可能 review 错了对象 AI can produce a diff. Review decides whether the team is willing to own the change. AI会产出代码,但是团队应该决定是否拥有这个改变 上一篇:AI 时代还需要 Estimate 吗? 床位系统那个 bug 暴露以后,我反复想过一个问题: 我们明明做了 code review,为什么还是没有发现这个bug? 实现并不离谱。代码在判断查询时刻是否落在预约区间内,局部逻辑说得通,边界也长得像正常的时间处理。 只是业务真正问的是“这一天是否已经被占用”,代码回答的却是“当前这一秒是否落在区间”。 我们不是没看代码。我们看了一个错误问题的正确答案。 这件事让我意识到,AI 时代关于

By andy
当代码不再稀缺 - 04

当代码不再稀缺 - 04

AI 时代还需要 Estimate 吗? Don't estimate how long it takes to generate code. Estimate what it takes to trust the change. 不要只估算生成代码需要多久,要估算团队需要付出什么,才能相信这个 change。 上一篇:别再用更多 Ticket 衡量 AI Productivity 下一篇:Code review 没有过时,但我们可能 review 错了对象 如果现在有人问 engineer:“这个 ticket 要多久?”答案可能越来越像这样: “代码今天能出来。至于什么时候敢上线,我不知道。” 这不是

By andy
当代码不再稀缺 - 03

当代码不再稀缺 - 03

别再用更多 Ticket 衡量 AI Productivity Code is cheap. Verified outcomes are not. AI 可以廉价制造代码,但不能廉价制造可信结果。 上一篇:AI 没有消灭瓶颈:Slop 正在吞掉团队的注意力 下一篇:AI 时代还需要 Estimate 吗? 有一种项目周会,特别容易让 EM 心情愉快。 这个 sprint 完成的 ticket 比以前多了,PR 数量涨了,commit 也很活跃。自从团队开始用 AI,dashboard 上的每一条线都在往右上角走。管理层一看:不错,AI productivity 已经兑现了。 然后 reviewer 默默打开

By andy