@Cander_zhu: https://x.com/Cander_zhu/status/2077409094567166271

X AI KOLs Timeline 新闻

摘要

本文介绍如何利用AI(Codex和GBrain)自动化Obsidian知识库的Inbox处理和知识飞轮,实现知识从输入、加工、连接到输出的闭环,提升个人知识系统活力。

https://t.co/8nIG2c6IbR
查看原文
查看缓存全文

缓存时间: 2026/07/15 17:58

我准备如何让 Obsidian 真正活起来:Inbox 自动处理 + GBrain 知识飞轮

前一阶段,我刚刚完成了一次 Obsidian 知识库重构。

我把原本混在一起的 X 文章、想法、学习资料、Git 教程和内容草稿,重新整理成了一条清晰的流程:

Inbox → Sources → Notes → Maps → Projects / Output → Archive

目录变清楚之后,下一个问题很自然地出现了:

难道以后每收藏一篇文章,我都要手动判断、移动、补 YAML、拆笔记、更新 MOC 吗?

如果所有步骤都依赖人工,知识库虽然整齐了,却仍然是静态的。

我真正想要的,不是一个“保存了很多资料的 Obsidian”,而是一个会持续吸收、连接、调用和反馈的个人知识系统。

所以我开始设计下一阶段:让 Codex 自动处理 Inbox,让 GBrain 成为 Obsidian 上方的检索和思考层。

整齐的知识库不等于活的知识库

一个静态知识库通常有三个特征:

  • 输入很多,但大部分内容停留在收藏状态;

  • 搜索依赖关键词和记忆,不知道自己已经写过什么;

  • 笔记很少进入项目、决策和公开输出。

目录结构只能解决第一个问题的一部分。

它可以告诉我文件应该放在哪里,却不能自动告诉我:

  • 这篇新文章和哪些旧观点有关?

  • 它是否与我已有判断冲突?

  • 我的知识体系还缺少哪块证据?

  • 哪些永久笔记已经足以形成一篇输出?

  • 某个结论是否已经因为新资料而过时?

真正“活起来”的知识库,需要同时具备四个循环:

持续输入 ↓ 自动加工与连接 ↓ 在问题和项目中被调用 ↓ 把实践结果重新写回知识库

只做前三步,系统会变成一个更好用的搜索引擎。

只有最后一步成立,它才会开始积累属于自己的经验。

我把自动化拆成了两个系统

我没有准备让 GBrain 直接负责所有工作。

更合理的做法,是让两个系统分别承担不同职责。

Codex:知识加工层

Codex 负责理解文件和修改 Obsidian:

  • 扫描 Inbox 中的新内容;

  • 判断它是外部来源、个人想法、项目材料还是输出草稿;

  • 统一 YAML;

  • 将高置信度内容移动到正确目录;

  • 提炼永久笔记;

  • 更新 MOC 和知识库首页;

  • 判断是否足以形成 Output;

  • 检查 Wiki 链接和附件。

GBrain:知识检索与综合层

GBrain 不负责替我管理文件,而负责让整个知识库可查询、可连接、可综合:

  • 索引 Markdown 和 YAML;

  • 对内容建立关键词与语义检索;

  • 根据 Wiki 链接构建知识图谱;

  • 跨多篇笔记回答问题;

  • 指出过时、矛盾、缺少证据的内容;

  • 在夜间进行维护、整合和模式发现。

可以把它们理解成:

Codex 负责把知识加工好 GBrain 负责让知识被找到和重新组合 Obsidian 继续保存最终文件

Obsidian 始终是唯一真实来源。即使以后替换 GBrain,所有 Markdown、YAML 和 Wiki 链接仍然存在,不会被锁在某个数据库中。

Inbox 自动处理应该怎样运行

我准备让自动任务每天扫描一次:

00_Inbox/

但它不会遇到文件就直接移动,而是先经过判断流程。

新文件 ↓ 检查重复、正文完整性和来源 ↓ 识别内容类型 ├─ 外部资料 → 01_Sources ├─ 成熟观点 → 02_Notes ├─ 项目材料 → 04_Projects ├─ 写作草稿 → 06_Output/Drafts └─ 无法判断 → 保留在 Inbox

对于一篇完整的外部文章,自动任务应该完成:

  • 识别来源、作者和发布时间;

  • 补齐统一 YAML;

  • 检查知识库里是否已经存在同一来源;

  • 分析是否值得长期保留;

  • 提炼 1~5 个可以独立复用的判断;

  • 把判断连接到现有 MOC;

  • 判断它能否与旧笔记组成新的 Output;

  • 完成 YAML、Wiki 链接和附件校验;

  • 输出一份本次处理报告。

我用在X上收集的 addyosmani 的《Own the Outer Loop》文章完整走过一次这个流程。

一篇 Inbox 文章最终变成了:

  • 一篇可追溯的来源笔记;

  • 五篇永久笔记;

  • Agent、Loop、软件工程三个 MOC 的新节点;

  • 一篇中文输出文章:Agent 能写代码,但工程师必须拥有 Outer Loop。

这就是我希望自动化重复完成的最小闭环。

最后一点思考

Obsidian 知识库的真正价值,不是文件夹整齐,而是内容能够流动。 AI(Codex + GBrain)大幅降低了加工成本,但最终“相信什么、公开什么、为它负责”,依然由我自己决定——这正是 Outer Loop 的意义。个人 IP 不是持续制造内容,而是持续公开自己的判断过程。

相似文章