Back to Blog

仓库间的信息流转

需求

我现在所有重要的数字材料，基本都放在三个文件夹里：Blogs、Papers 和 Journal。

这三个地方各管一摊。Blog 放已经成型、愿意公开的写作。Papers 放学术项目、论文草稿和研究材料。Journal 则更像我的个人操作台，里面堆着零散想法、任务上下文、行政要求，还有那些暂时还没有整理好的东西。

问题也正出在这里。

东西分开管当然有好处。边界清楚。不会乱。 但一旦我要真正开始做事，麻烦也立刻出现了。

比如我想搭一个 AI 通识课的内容体系。这个任务绝不可能只靠一个文件夹完成。它需要我过去写过的博客文章，需要 Papers 里的学术材料，也需要 Journal 里那些零散但关键的想法、笔记和要求。

如果还按原来的方式做，我就得自己在三个仓库之间来回翻。翻旧文章。翻项目笔记。翻那些我明明记得写过、但一时根本想不起标题的草稿。光是把材料找齐，精力就先被耗掉一半。

我真正想要的不是这个。

我想要的是：我在 Journal 里唤起 知识库管理 智能体，把任务直接交给它。比如我说，我要准备一门 AI 通识课。它就应该能自动去读我以前写过的相关博客，去找 Papers 里能支撑这个主题的研究材料，再把 Journal 里零散的想法和要求一起收进来，最后汇总成一个可以直接开工的看板文件。

再比如另一种场景。我只是模糊地记得，自己以前好像写过某个问题的草稿，但完全想不起题目，也不记得它到底放在哪个仓库里。

这时候我也不想手动去翻。我只想直接问它一句：我以前是不是写过这个问题？

然后它就应该把相近的、相关的、甚至只是方向上类似的内容都找出来。最好不只是列给我看，而是顺手告诉我，这些材料彼此之间有什么差异，有什么连结，哪些其实已经能拼出一个新的想法。

所以说到底，我想解决的不是存储问题，而是调度问题。

我需要设计一套信息流转机制，让这三个仓库既保持各自的边界，又能在真正做事的时候，像一个系统那样协同起来。

这个设计非常有意思，它把我累计了十几年的东西全部都打活了。我就不用在脑袋里面记说我到底写过些什么，我直接去问 AI，它帮我梳理，帮我总结，然后启发我的下一次思考。

我之后还打算在信息与知识的摄入上下功夫，就是能够让我直接看最高效、最优质的信息来源，然后将其转化为我自己将其转化为知识之后，沉淀在我的个人知识库中。

先看整体思路

如果完全不懂技术，其实可以把这套东西理解成很简单的分工。

Blog 和 Papers 负责各自保存内容。一个保存已经写成的表达。一个保存学术项目和研究材料。Journal 不负责替它们保管原文，Journal 负责的是调用。

也就是说，平时东西还是放在原来的仓库里。真正要做某个任务时，我从 Journal 发出指令，Journal 先去看另外两个仓库给它准备好的摘要；如果摘要不够，再继续往下读更具体的内容；等它把材料整理好了，再把结果汇总成 Journal 里的看板或者知识页面。

换而言之，信息不是在三个仓库里乱窜，而是按一条很清楚的路线流动：

  1. Blog 和 Papers 各自维护自己的内容。
  2. 它们把最重要的信息整理成对外可读的摘要。
  3. Journal 读取这些摘要，并在需要时继续深入。
  4. 最后由 Journal 把结果组织成我能直接使用的东西。

先看到这里，其实就够了。后面的「方案」部分，写的就是这条路线具体是怎么落地的。

方案

想来想去，这套系统真正要解决的，不是「怎么让 AI 变聪明」，而是「怎么让不同仓库之间的信息流动有边界，而且这个边界足够稳定」。

如果边界不稳定，今天能读的东西明天就换地方了。今天生成的结论，明天就不知道该去哪里追溯。那最后整个系统一定会变成一团糟。

所以我现在的方案，本质上是三句话：

  1. Blog 和 Papers 负责维护自己的内部结构，并各自提供一个对外接口 SUMMARY.md（给外部仓库读取的标准摘要文件）。
  2. Journal 作为总入口，只读取这些接口，不反向改写外部仓库。
  3. 只有当接口信息不够时，Journal 才按需深入读取原始文件。

换而言之，这不是一个「三个仓库互相乱连」的系统，而是一个单向读取、分层整理、按需深读的系统。

先把三个仓库的职责说清楚

Blog 是公开输出层

Blog 仓库里真正重要的内容，是 source/ 下面那些已经写成文章的 Markdown 文件（轻量标记语言文件，适合长期写作和版本管理），以及 data/wiki/（由 AI 维护的结构化知识 wiki，用来整理主题、作品和连接）。

它对外不是把整个仓库直接敞开，而是额外导出一个 SUMMARY.md（对外接口文件，只暴露外部需要知道的摘要信息）。
这意味着 Blog 内部怎么组织 wiki、怎么生成索引、怎么维护文章摘要，都可以自由演化，但只要 SUMMARY.md 的格式不乱，Journal 就还能继续读它。

除此之外，Blog 还有一份 data/markdown-summary-index.json（文章摘要索引，用结构化数据记录文章标题、标签、摘要和路径），它的作用是让 AI 不必每次都把七八十万字文章从头通读一遍，先靠索引做第一轮筛选。

所以 Blog 在整个信息流里做两件事：

  1. 保存最终公开表达。
  2. 提供可检索的知识出口。

Papers 是学术工作层

Papers 仓库负责管理论文项目、研究笔记和协作写作材料。它内部真正分散的信息，至少有四块：

  1. 各个论文项目目录。
  2. notes/projects/（项目总览与项目笔记）。
  3. notes/years/（按年份组织的科研日记）。
  4. ../overleaf/（Overleaf 协作论文目录，本质上也是 Papers 框架的一部分）。

Papers 也不直接把内部结构暴露给 Journal，而是维护自己的 SUMMARY.md。这个 SUMMARY.md 由 summarize skill（自动扫描仓库状态并生成摘要的工作流）统一生成，负责汇总当前活跃项目、协作状态、最近进展和研究方向。

所以 Papers 在整个系统里的角色也很明确：

  1. 自己管理学术材料。
  2. 对外只提供一个稳定摘要。

Journal 是总入口和调度层

Journal 是我真正发出任务、查看结果、组织日常工作的地方。它自己内部又分三层：

  1. sources/（原始素材层，放 PDF、截图、网页导出等原件，AI 只读）。
  2. wiki/（知识层，AI 维护的结构化知识库）。
  3. board/（视图层，围绕具体任务临时生成的看板文件）。

Journal 之所以能成为总入口，不是因为它掌握了所有原文，而是因为它掌握了「怎么去读别的仓库」这件事。

也就是说，真正的控制权不在存储，而在调度。

整个信息流是怎么流转的

下面我按一次完整任务，把整个过程从头到尾写清楚。

第一步：外部仓库先各自整理好自己的对外接口

这一步发生在 Blog 和 Papers 内部。

Blog 侧

  1. 我在 source/_posts/、source/journal/ 或 source/almanac/ 写文章。
  2. 仓库内部再生成 summary（文章摘要字段）、excerpt（对外展示的短简介）和 data/markdown-summary-index.json 这类索引材料。
  3. AI 持续维护 data/wiki/，把散落在很多文章中的主题、作品、连接关系整理成稳定页面。
  4. 最后通过 export skill（把内部知识层导出成外部可读摘要的工作流）生成根目录 SUMMARY.md。

这一步的结果是，Blog 对外给出一个稳定入口。Journal 平时优先读这个入口，而不是直接翻全文。

Papers 侧

  1. 我平时在各个论文目录、notes/projects/、notes/years/ 和 ../overleaf/ 里推进工作。
  2. summarize skill 定期扫描这些区域。
  3. 它把当前有哪些项目、项目走到哪一步、最近两个月有什么进展，统一写进 SUMMARY.md。

这一步的结果是，Papers 也把自己复杂的内部状态压缩成了一个可被 Journal 读取的摘要层。

第二步：Journal 把外部接口读进自己的投影缓存

Journal 不会每次接到任务都重新通读 Blog 和 Papers。那样太慢，而且没有必要。

所以它会在 wiki/外部投影/ 下面维护本地投影缓存（把外部接口在本地保存成一份摘要副本，方便重复读取）。

比如：

wiki/外部投影/
├── blog.md
└── papers.md

这里的意思不是把外部仓库完整镜像到 Journal，而是把当前任务最相关的那部分信息，投影成 Journal 自己知识层里可继续引用的页面。

这样做有三个好处：

  1. 读取快。因为先看缓存，不必反复扫外部仓库。
  2. 结构稳定。因为 Journal 内部引用的是自己的 wiki 页面，不是随时可能变化的外部细节。
  3. 可以记录同步时间。超过 7 天就重读接口，避免缓存过旧。

第三步：我在 Journal 中发出任务

任务入口一般有两种。

第一种，是我把零散想法先记进 temp.md，然后运行 /ingest（把新输入编译进知识层的导入流程）。
第二种，是我直接要求它生成一个任务看板，例如 /board AI通识课。

这两个动作的含义并不一样。

/ingest 负责把新材料沉淀成长期知识。
/board 负责围绕某个具体目标，把已有知识临时重新组织成一份能直接工作的视图。

一个偏「入库」。一个偏「调度」。

第四步：Journal 先在内部知识层和投影缓存中做第一轮检索

这里是整个系统最关键的一层。

当我说「帮我做一个 AI 通识课内容体系」时，Journal 里的知识库管理智能体不会立刻冲去读完 Blog 全文和 Papers 全仓库。它会先按下面的顺序做第一轮筛选：

  1. 先读 wiki/index.md，确认 Journal 自己已有的知识入口。
  2. 再读相关 wiki 页面，看看过去是不是已经整理过类似主题。
  3. 再看 wiki/外部投影/blog.md 和 wiki/外部投影/papers.md。
  4. 如果任务里出现明显的线索词，比如某篇文章标题、某个项目名、某个研究方向，再根据这些线索决定要不要深读外部仓库。

这一步其实就是「先用目录和摘要定位，再决定读原文」。

这么做很重要。因为如果一开始就全量读取，成本太高，而且很容易把真正有用的信息淹没掉。

第五步：如果摘要不够，就按需深度读取原始文件

当 SUMMARY.md 和投影缓存不足以回答问题时，Journal 才会进一步读取外部仓库的原始材料。

Blog 侧，可能会深入读取：

  1. data/wiki/<页面>.md
  2. data/markdown-summary-index.json
  3. source/_posts/*.md 原文

Papers 侧，可能会深入读取：

  1. 某个项目目录下的 LaTeX 文件
  2. notes/projects/ 对应项目页
  3. notes/years/ 里相关时间段的科研日记
  4. ../overleaf/ 中对应协作文稿

这里的 LaTeX/TeX（学术论文常用的排版源文件格式，特别适合数学公式）很重要。因为对 Papers 来说，很多真正有价值的知识并不在一份最终摘要里，而在草稿、细节证明、协作过程和项目笔记里。

但是这个深读动作仍然是单向只读。Journal 可以读，可以摘录，可以在自己的 wiki 里形成理解，但不能反向改写 Blog 或 Papers。

第六步：Journal 生成任务看板，供我直接使用

当第一轮筛选和必要的深读完成之后，Journal 会把结果写进 board/<任务名>.md。

这个 board（围绕某个任务生成的临时看板）不是长期知识库，而是面向当前工作的工作台。它通常会聚合几类内容：

  1. 任务目标和拆解步骤。
  2. 来自 Journal 自身 wiki 的已有知识。
  3. 来自 Blog 的相关文章、主题页面和过往表达。
  4. 来自 Papers 的项目进展、理论材料和相关研究线索。
  5. ## 个人补充 区块，用来让我手工加判断、链接和临时草稿。

于是，一个任务就从三种不同来源被拼起来了：

  1. Journal 负责组织任务。
  2. Blog 负责提供过去已经成型的表达。
  3. Papers 负责提供研究与学术上下文。

第七步：我继续补充，系统再把新东西沉淀回 Journal

看板生成之后，我通常不会立刻就停。我会继续在 ## 个人补充 里写判断，或者往 board/<任务名>/ 子目录里放更长的草稿、清单和补充文件。

之后再运行 /ingest，Journal 会重新读取这些补充内容，把其中有长期价值的东西吸收进 wiki/。

注意，这里吸收的是「长期知识」，不是把整个看板原样保存。

换句话说：

  1. board/ 负责这次任务怎么做。
  2. wiki/ 负责以后还能不能复用。

这就是为什么我说 Journal 更像一个操作系统。它不只是记笔记，而是在不断把任务过程重新编译成长期知识。

两个典型场景是怎么跑通的

场景一：我要搭一个 AI 通识课体系

这类任务的信息流大致是这样的：

  1. 我在 Journal 中发起 /board AI通识课。
  2. Journal 先读自己的 wiki 和外部投影缓存。
  3. 它发现这个任务同时涉及博客中的历史文章、Papers 里的研究材料、以及我最近零散记在 temp.md 里的想法。
  4. 它进一步深读 Blog 的相关主题页和文章原文，也按需深读 Papers 的项目笔记或论文草稿。
  5. 它把这些内容聚合成课程看板，列出可能的模块、已有素材、缺失部分和下一步动作。
  6. 我在 ## 个人补充 里继续修正判断，必要时再运行 /ingest 把课程设计过程里的稳定知识沉淀回 Journal。

所以这里真正发生的不是「AI 帮我生成一份课程大纲」这么简单，而是三个仓库里的不同知识层，被 Journal 临时编排成了一条面向任务的工作链。

场景二：我只记得自己好像写过某个问题

这种模糊搜索，其实更能体现这个系统的价值。

它的过程通常是：

  1. 我在 Journal 里直接描述问题，不需要先记得准确标题。
  2. 智能体先查 Journal 自己的 wiki。
  3. 再查 Blog 的 SUMMARY.md、文章摘要索引和相关 wiki 页面。
  4. 如果还不够，再去读具体文章原文。
  5. 同时它也可以查看 Papers 里是否有相近的项目、笔记或研究日记。
  6. 最后把相近内容、相反内容、可能的连接关系都汇总到看板或回复里。

这里的关键不是关键词匹配，而是「先摘要定位，再原文核对」。
这样既能扩大召回范围，也能尽量避免胡乱联想。

为什么这个方案必须坚持单向读取

如果三个仓库互相读写，短期看很方便，长期一定出问题。

原因很简单。

  1. 责任会混乱。你会不知道某段知识到底应该维护在 Blog、Papers 还是 Journal。
  2. 冲突会变多。一个地方改了，另外两个地方未必同步。
  3. 可追溯性会下降。最后你甚至不知道某条结论来自原文、摘要，还是某次任务生成的临时看板。

所以我现在宁愿保守一点。

Blog 和 Papers 自己维护自己。
Journal 只负责读取、整合、投影和调度。
真正需要进入长期知识层的东西，只沉淀在 Journal 的 wiki/ 里。

这样整个系统的因果链条才清楚：

  1. 原始内容先留在各自仓库。
  2. 各仓库对外导出稳定接口。
  3. Journal 读取接口并形成投影缓存。
  4. 任务发生时，再按需深读原文。
  5. 任务结果沉淀回 Journal，而不是倒灌回外部仓库。

这才是一个能长期运转的结构。