--- title: 从知识管理到个人数字基建 date: 2026-07-21T11:49:08+08:00 tags: - 学习 - AI --- 很久没有发新的文，近期也主要在于着手回顾自己的工作、技术和学习，整理重组我自身的知识体系，思考可能的方向和规划，以及 AI 浪潮冲击下的应对。 能感觉到自己能量逐渐高涨，无论是技术还是生活，很多有意思的想法在爆发，以及我在 MoeGo 期间在 Web App Dev 领域有许多很成型的、但由于各种因素未能对外输出的思考，需要更多落地。 虽说 AI Agent 生成长篇大论轻轻松松，但写文章这件事，我认为更重要的是人在背后的思考和锻炼，它并没有什么东西能够取代或者外包。AI 更大的意义是，让我们更容易进入这个思考状态。 一切的一切，我想可以先从个人的数字基建体系的重组过程开始，其他主题的话，只能说来日方长，再慢慢更新吧。 ## 重新思考知识管理 在 2022 年的时候，我写过一篇 [基于 Logseq 重构个人知识管理体系](https://zgq.me/posts/knowledge-base-refactoring/)，后来在 0xFFFF Wiki 也进一步写了 [知识管理](https://wiki.0xffff.one/general/knowledge-management) 和 [项目与任务管理](https://wiki.0xffff.one/general/project-management) 相关的一个教程和扩展。在多年实践之下，我也慢慢形成使用场景，结合 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 粒度](https://zgq.me/posts/knowledge-base-refactoring/) 的信息组织，在这里会需要捡回来。 ~~用 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](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) 方法论一片火热，加上 [OKF](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md) 的知识交换标准格式，还有谷歌 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 一起纳入个人的基建版图，以一个平等的态度去面对，以及分配注意力优先级。 在不同视角的共同参与下，大概形成一个如图的循环： ![个人数字基建的信息循环](https://cdn.zgq.me/assets/posts/2026/personal-digital-infrastructure/image.png) 至于归档层面，目前不单独设置，涉及到归档的大概是 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 工具，尝试碰撞和玩起来，有什么心得，我们可以再进一步交流。