gq's avatar
gq's blog

从知识管理到个人数字基建

学习

AI

很久没有发新的文,近期也主要在于着手回顾自己的工作、技术和学习,整理重组我自身的知识体系,思考可能的方向和规划,以及 AI 浪潮冲击下的应对。

能感觉到自己能量逐渐高涨,无论是技术还是生活,很多有意思的想法在爆发,以及我在 MoeGo 期间在 Web App Dev 领域有许多很成型的、但由于各种因素未能对外输出的思考,需要更多落地。

虽说 AI Agent 生成长篇大论轻轻松松,但写文章这件事,我认为更重要的是人在背后的思考和锻炼,它并没有什么东西能够取代或者外包。AI 更大的意义是,让我们更容易进入这个思考状态。

一切的一切,我想可以先从个人的数字基建体系的重组过程开始,其他主题的话,只能说来日方长,再慢慢更新吧。

重新思考知识管理

在 2022 年的时候,我写过一篇 基于 Logseq 重构个人知识管理体系,后来在 0xFFFF Wiki 也进一步写了 知识管理项目与任务管理 相关的一个教程和扩展。在多年实践之下,我也慢慢形成使用场景,结合 Logseq / Notion 的思路,主要按照一个个人日志、知识整理、项目记录的场景去做。

总的来说,抽象的模型和方法论,几年来没有发生大的变化,始终立足于让思考与行动、表达能在一套体系下承载,这样的方法也支撑着我工作的日常,有不少的收获。

对于知识体系构建而言,关注点是 DIKW 模型的思考转化流程,从信息固定、组织内化、交流碰撞的角度,去实现对应的信息承载。行动视角则是一个项目管理的思路,辅助跟踪项目执行的过程的信息收集,辅助规划。两者之间的融合下,也在形成对某些领域,方向的持续积累和规划。个人日志在其中则构成了知识与行动的原料,一切的体系和框架,一旦离开日常行动积累,就成了空中楼阁。

大目标还是立足于个体有限性下的聚焦。一方面是注意力的聚焦,认知是发散的,但行动力的有限,意味着当下的行动一定要聚焦;一方面是知识的聚焦,学海无涯,我们不追逐所有信息囊括在自己身上,核心是锚在自身的知识网络;然后是对外影响的聚焦,无论是生活日常、职业发展、人际关系等方面,影响可以聚焦到一定的领域,而不是东一棒西一锤,缺少一个稳定的支撑。

对于实现而言,当下最大的一个变数也在于,LLM 逐渐强大,Agentic AI 走向成熟,冲击了许多应用场景,以前觉得不可能的假设成为了可能,也让我开始思考,这一套体系应该如何进一步结合 AI Agent 去做重塑。

AI Agent 对笔记场景的影响

过去我们对于笔记软件的讨论,通常关注点会在 Block 粒度 ID 链接的机制,还有产品设计、交互界面在操作友好性上的比较。它立足的点在于“计算机程序无法理解非结构化自然语言”这一大假设,然后围绕着这一大假设去实现一系列机械结构化操作机制,语义层面的信息整理,还是强依赖于人工的处理,对于处理成本而言可以说是居高不下,没有统一标准和稳定的预期。

但 LLM 的出现,可以说是打破了这个假设,外加 Agent 背后强大的上下文工程和 Harness 体系设计,让这一自然语言处理更具备实用性,两者互相配合,也形成了当前 AI Agent 的大致格局。机械体制下的内在语义关联、跨文件编辑能力、摘要和一致性检查等,AI Agent 已可以很好地辅助完成,而不需要太多的人工干预。并且结合 Agent Skill,我们甚至可以把非结构化的自然语言和结构化的代码发生互相联动,在灵活性和准确性之间能取得很好的平衡。

这时候再看笔记工具,数据结构化程度显得有点过高,过度结构化的维护成本对于大脑而言也成为一个负担。以前没得选,人必须忍必须学,当 AI Agent 的实用性变强,可以保证在总信息量变化不大的情况下,能基于任意视角去翻译任意信息的时候,信息强结构化链接的必要性也随之降低,从「不得不完全依赖」降低到一个「辅助角色」的地位。

这也意味着,在笔记体系的设计上,我们应该尽量回归本源,以及在体系中 AI Agent 会上升到一个「一等公民」的角色存在。

放下 Block:新的信息原子结构

明确了 Block 笔记体系的强结构化的负担,还有 AI Agent 提供的出口,我们可以着手去定义新的笔记形态。在讨论笔记的体系的开始,需要关注的是我们会用什么样的原子结构去定义信息,然后能兼顾到人类友好、AI 友好、机器友好,并且能具备一定的 Unix 哲学下的透明性,降低使用的负担。

首先需要明确的是,我们现有的知识管理体系,会涉及到哪些原子数据,我能想到的主要有三类:非结构化文本 / 非结构化的二进制数据(图片,少量的视频,附件) / 结构化数据(metadata、图、关系数据)。

综合我过去的实践经验,对于原子单位而言,非结构化数据 + 结构化 metadata 的同时组合,是这里原子结构的一个重要的点,并且由于考虑 AI 的能力支撑,这一原子可以不用抽得太细,完全有机会基于一个“文档页面”为单位,去给 AI 模型做理解和操作。也就是说我 22 年所放下的 Page 粒度 的信息组织,在这里会需要捡回来。

用 GPT 的话来说,这里最顺的,自然就是 Markdown + Frontmatter 结构作为文本数据的载体,这也是静态博客圈子已经玩坏了的文档形式,相当于组合了 Markdown + YAML 这两种模型。文档中对内和对外的链接都可以直接复用嵌入 Link 的语法,并且不需要搞双链,让 Agent 维护就行;当然,如果文档中还需要表达一些特定的结构化内容,利用好 md 的缩进 bullet point,融合 mermaid 或者 dot 等绘图语言,也是一件顺其自然的事。

而对于图片附件等非结构化二进制数据,在这个思路下应该如何存活呢?我的想法是,把它分为 二进制 Blob + metadata 这两个部分去做,考虑到 AI 对多模态数据的理解会有负担,可以再给 Blob 去绑定一个,文本化的理解层。

对于关系数据而言,这里就更侧重于应用层,轻量的关系数据库便是一套好的解法,早年的 Anki,Logseq 等,已经把 SQLite 玩出了花,方案上其实直接复用就好,核心在于 db schema 的定义。

然后这个视角我们可以发现,类 Obsidian 的纯 Markdown 模型其实已经实现了部分形态,Obsidian 在这里属于是躺赚,搭上了 AI 时代的便车,现在也有很多 Git + OB 的解决方案。但这不意味着我会继续用它来做支撑,还是有很多差强人意的点(主要还是基本能力和跨平台同步方面)。另外我看 Notion AI 在这个场景已完成很大部分,但绑定平台并不是我喜欢的事情,以及我认为这里会有更大的想象空间,不局限于单一平台方案。

核心问题:溯源与可靠性传递链条

至此我们已经有了一个构造的重心,并且都是看似老生常谈的问题,在 AI 高速迭代带来的 Fomo 心态的影响下,准备拿着锤子找钉子之前,我觉得还是需要多问一下「为什么」。

这几个月 LLM Wiki 方法论一片火热,加上 OKF 的知识交换标准格式,还有谷歌 NotebookLM 的设计等,我这里的体系也受 LLM Wiki 启发不少。只是侧重点不同:LLM Wiki 关注知识维护那一层,我更关注从指导个人行动的视角出发的「知识 + 项目管理」体系。

知识与行动在思想上是同构的,AI Agent 本质上关注的也是同一件事——如何把知识体系融合进现实行动(代码 / 命令调用等)。核心就在于:设计一套能辅助行动的信息流动体系,并用好 AI Agent 的信息整合与转换能力,让它成为靠谱的帮手,而不是生产大量幻觉、干扰决策的捣乱分子。

无论 NotebookLM、LLM Wiki 还是我在构建的体系,落到根上都是同一个问题:信息的溯源与可靠性如何有效传递。

结构化推理

在 AI Agent 出现之前,有条理乃至结构化的数据生产成本极高,且往往立足于具体场景、有充分的人类参与和背书。那时判断信息可靠性,绝大部分时候依赖逻辑推理——想判断一段表达靠不靠谱,就看它是否逻辑自洽,自洽通常也就意味着可靠。LLM 因为概率模型的缘故,输出时也可能产生幻觉;Harness 的应对策略之一,就是用接近形式化的语言、强结构化的逻辑推理去校验——这也是 AI Agent 写代码时依赖 Test 和 Linter 保障交付可靠的原理。

当 LLM + Harness 把逻辑上的可靠性做得足够强大,到了一个大家默认 AI Agent 已经能产出很多逻辑自洽靠谱内容的时候,是否意味着我们可以无脑相信 AI 的输出,进而是人类要被取代?实则不然,因为 AI Agent 在生产输出内容的过程,其实是非常缺乏使用者当时的上下文的,消息的真真假假混在一起,发展到极端,就有可能会带着一种无病呻吟的意味。

强结构的输出,它的可靠性来源于一个大家觉得是共识的“大前提”,然后基于此去做推理和演绎,只要符合规则,那我们是可以去继承这一上层的可靠性去选择相信它。这里的漏洞则在于,当这个大前提不可靠的情况下,理论上这些输出也会对应地失去立足之点。

这也是 AI Agent 的出现对于这里信任格局的影响,“逻辑自洽的胡说八道”在它面前已经是“洒洒水”,原来基于逻辑是否自洽的判断方式也会随着 AI 内容浓度的增加而逐渐失效。这也就是我们所提到的“溯源”的重要性,NotebookLM / LLM Wiki 强调 raw sources 流的固定,也是来源于此。

熵减原则与可靠性传递

逻辑推理是很重要的一条线,随着 AI Agent 变强,这部分能获得很好的自动化;另一条线,是让 AI 推理的过程保持“熵减”。这里的“熵减”是借用了香农信息熵的概念,但不严格用它做精确度量。核心在于 AI 处理信息的方向:LLM 善于对输入做摘要、去重、归并和结构化梳理,且不出现大的失真。从信息量的角度说,如果这个过程只是压缩信息、改变形态,可靠性就能被继承——处理的材料来源如果充分可信,它总结出的结论大概率也可靠。

但对于最终是否可靠,我们无法全然相信,还是得保留一个可检查、可批判、可撤回的结构,这也是符合波普尔的科学证伪主义的认知基础。另一个视角来看也是溯源的存在,我们得以从一个公共的底层认知,通过演绎推理来确认某个结论的可依赖性。

但对于个体而言,我们不可能事事都完全能把一整套科学理论推导过程都拉进来,人类生命有限,我们总要有一些预设相信的判断;另外人在做事,学东西的时候,也会有一些对于事物的观察认知与自身的思考,知识管理体系更大程度是要服务于这个过程。

由此而言,基于个人的认知,这里 “熵减过程” 处理的信息源,可以是 ta 充分参与生产、采纳的那部分信息,还有在执行项目过程中的一些思考记录。我们可以认为是,一段数据只要被使用者所认可和纳入,它都属于其中“可靠性”的一个来源点,然后基于它去推理,摘要出来的东西,也默认会被 ta 信任,为 ta 所用。

熵增场景与效率提升的限度

但我们用 AI 并不只是摘要总结,和 AI 聊天会涉及一个演绎过程,很容易脱离这套隐含的可靠性传递体系,就比较微妙。基于统计模拟生成的内容默认缺少验证,意味着需要注入新的信任,而这份注入是否可靠,很受制于使用者的认知积累、以及参与上下文见证的充分程度;基础模型本身的数据质量有一定可靠性,但无法简单度量,只能说宏观的大水漫灌。

由此而言,如果用 AI 去完成“熵增”过程,使用者本身对自己的能力认识和判断力就会变得非常重要,以及聊天过程中需要有足够的谨慎和充分的思考,必要时候多引入更可靠的信息源头。但一旦过分追求所谓产出速度,使用者就很容易无脑地去强行确认一些自身能力之外的东西,AI 误认为这里是已被用户背书的共识,长此以往,作为大前提的信任基础就容易走向模糊乃至腐化。

当然我们也可以选择“抽卡式赌博”(所谓 vibe coding),但这本就是一场负期望的游戏,大数定律注定其长期必输。长期还应走正路,该啃的东西一个不能少——就如投资,短线可以赌,长线终究要靠真才实学的研究,收益也才会收敛到一个好的数学期望。

当下部分企业对于 AI 的效率焦虑,呈现的也是相似的抽卡式赌博带来的失控,大量生成内容没有被充分确认和验证就直接被无脑背书,变成正式知识且没有清晰溯源,AI 幻觉与正常内容混杂在一个空间难以辨认,当幻觉累积到某个阈值,某种意义上也是灾难的一个开始。

对于 AI 提效这件事,我的观点在于,AI 通过概念建模,通过强结构化的生产验证流程,能消除掉一些实现过程中因为概念不清,或者实现发生意外所带来的偶然复杂性;但对于事物本身的本质复杂性是无法消除的,这是它的上限所在。

一个可能的坑点,人对事物的认知会有一个混沌到清晰的过程,无法从一开始就完全概念化,事情还没落地有参考经验之前,我们没办法在一开始就能判断出哪些部分是偶然复杂性,哪些是本质复杂性。这里就需要一个尊重不确定性、思考和沉淀的空间,越着急反而会离看清它越远,进而导致动作的持续变形。

走向个人数字基建

明确了基本的原子结构和行动原则,进一步需要思考的是,我们可以构建什么样的知识管理体系乃至于个人的数字基建体系?如何让 AI Agent 能在其中发挥最佳的效用?

先明确目标,核心自然是,辅助支撑日常的信息处理和沉淀过程;进一步的目标是,让它能承接使用者自身能力圈内的任务自动化,减轻个人的负担。后者可以说是信息流稳定之后自然会带来的副产物,并且 ROI 肉眼可见的可观。

在设计上需要关注的是,一方面是能比较好做信息溯源,支持熵减推理,保留批判和改进的空间;另一方面是,尽量保证产生新信息的推理过程,有充分的人类见证。当然最关键的还是,AI 解放了机械性的杂活的情况下,可以不用有太多为了结构化而结构化的束缚,可以大胆一些。

改良后的新结构

进一步要做的是信息流的重新理顺过程,方法架构上没有大的变化,还是围绕着行动的积累和沉淀。但相比于之前只关注项目和知识的维度,这里的关注点会相对更上一层,并且在执行层有一部分任务其实已经可以 Agent 代劳了,考虑点可以多侧重于方法的完备性。

实践下来涉及到这几方面:

  1. 日常记录、信号的捕获。
  2. 行动跟踪与执行上下文的维护:小到单个 task(task + plan),大到 bounded project 粒度(目标更大或跨 scope 的,就在一个 project 里拆成多个 task / phase 推进)。
  3. 长线领域的承载(Domain):一面收束行动(零散可速修的小 bug 走 backlog task + plan,任务多、目标聚焦或跨 domain 的走 bounded project);一面沉淀 spec 与抽象设计、讨论计划与方向形成长短期目标,并用 roadmap 将短期产出与长期方向串起来。
  4. 通用知识的沉淀(Wiki):LLM Wiki 思路,raw sources、index + log,以及 ingest / query / lint 机制。
  5. 对外的输出(Works):个人作品(博客、自媒体、代码等)与职业价值叙事(工作、项目经历、简历等)。

有点类似 P.A.R.A 的笔记管理方法论,但我会避免直接照搬 Project / Area / Resource / Archive 这样的机械四分结构,更像是无形中融入了这里的思想分工,比如说 Project 基本同构,Area 其实就是这里对应的 Domain;Resource 没有什么关系,可以不纳入系统,避免松鼠病囤积资源心态,即使要搜集和固定,它应该是放在类 LLM Wiki 在 raw sources 或者可能的 inbox 之类的地方存放,并需要及时做消化,否则不如丢掉。

Domain 是我这一波体系升级里最为核心的部分,理论上会接住所有需要 own 的长期方向,在这个体系里它可以纳入 Domain 的管理获得精力支持,并且不仅仅是工作学习或者开源作品等;生活日常比如说做饭、运动、理财、家务等,都可以成为一个个 domain,和工作学习的 domain 一起纳入个人的基建版图,以一个平等的态度去面对,以及分配注意力优先级。

在不同视角的共同参与下,大概形成一个如图的循环:

个人数字基建的信息循环个人数字基建的信息循环

至于归档层面,目前不单独设置,涉及到归档的大概是 bounded projects 执行结束后的记录存储,project 完成后基本上就改一个 metadata 状态做一个标记,就完成了 project archive 的过程;backlog 的 task 也自带归档能力,按需可以再挪出去到独立的 archive 文件。

保留纯人类空间

以上部分的设计前提,会强依赖 Agent 的自动化能力,但有时候其实并不需要总是让思维搭上高级智能的高速列车,要产生新东西,慢下来的思考反而是更重要的事,因此体系里也需要容忍作为纯人类的一个慢速思考发挥空间,那么这里核心还是一个信息快速固定,延后推理的方案。

具体而言一个是类 flomo 的 memo 闪念固定,类邮件收件箱的 inbox 队列;另一个是针对作品的索引,创造服务于纯人工的写作空间。核心是让思考速度按着人类的节奏去走,在写作的过程思维也会得到锻炼,AI 就退居幕后做一些信息整理的工作就好。

工具体系支撑

以上是一个相对抽象的设计方向,落地于现实而言,目前看都没有非常完美的解决方案,不可避免要涉及多个工具的联动。

最最基础的思路是,用一个 vault 目录维护,大概有这几部分:

  • 存储:固定的一个 vault 目录
  • 可视化阅读 / 编辑:Obsidian, 或 VSCode 这类支持 Markdown + 目录加载的 IDE
  • AI Agent:可以是 Claude Code / Codex / WorkBuddy 或者自己喜欢的 Agent Runtime
  • 备份:可以用 Git 来做,GitHub 私有远程仓库做同步

在日常使用中,跨设备操作是一个重要场景,如何做好跨平台的 UI 和数据同步,以及我提到进一步的非结构化二进制数据、关系数据在这种场景下,如何比较好管理、保证可靠性、减小使用摩擦,展开下来有一系列的课题还待解决。

再进一步的话题是,如何基于已有个人数据,去设计更多有意思的上层应用。当然做这些的前提,一定还是基础的原子协议和数据基座的收敛,收敛的完成,意味着可能性的发生。

一切的核心在于一整个 IT 基建层的支持,再进一步折腾会触及 HomeLab 相关的上层应用方案和体系,如何应用已有的本地/云端的算力/存储/网络资源去完成这一切。目前它们在我这已有初步雏形,在一步步完善中,看契机我再单独写和开源出来,也许会有进一步产品化供大家使用的可能性。

最后

写到这里,核心思想和行动策略基本走向稳健,具体的实现设计,目前还是一个开放的问题,不同的人有不同的答案,我也在寻找属于我自己的答案。这也是我接下来的一个比较大的工作重心,目前来说我能做的是,先沉淀下初步的思考框架。

如果你也在寻找属于你的答案,可以将本文加入你最趁手的 AI 工具,尝试碰撞和玩起来,有什么心得,我们可以再进一步交流。