# 我如何用 AI 把 Obsidian 从收藏夹改造成知识生产系统
**作者**: Cander
**日期**: 2026-07-12T07:56:41.000Z
**来源**: [https://x.com/Cander_zhu/status/2076214145922523304](https://x.com/Cander_zhu/status/2076214145922523304)
---
很多人开始使用 Obsidian 后，都会经历一个相似阶段：
收藏越来越快，目录越来越多，真正能重新使用的知识却没有同步增长。
我也一样。
我的知识库里已经有 X 长文、微信公众号文章、Git 教程、AI 工具资料、自己的想法和一些准备发布的内容。看起来什么都有，但真正打开目录时，我仍然会犹豫：
- 新收藏的文章应该放在哪里？
- “AI 相关”和“工具相关”有什么明确边界？
- Idea、Learning、Loop、Prompt 应该是文件夹还是标签？
- 一篇文章收藏之后，怎样才算真正进入了我的知识体系？
- 这些资料最终怎么变成我能发布的内容？
于是我让 AI 和我一起做了一次知识库重构。
这次重构最重要的结果，不是一套漂亮目录，而是一条真正可以持续运行的知识生产流水线。
## 我的知识库最初是什么状态
第一次盘点时，库里大约有：
- 25 篇 Markdown；
- 15 篇 X 原文剪藏；
- 2 篇经过思考的 Idea 笔记；
- 10 个基本为空的主题或项目目录；
- 一批散落在根目录的图片；
- 多套不完全一致的 YAML 字段。
表面上看，这已经是一个“知识库”。
但从内容比例来看，它更像一个资料仓库：外部来源很多，自己的观点很少；收藏入口已经建立，加工和输出机制还没有形成。
更明显的问题是，原来的目录混合了几种完全不同的分类逻辑：
- 00_Inbox 表示处理状态；
- 01_Sources 表示内容类型；
- AI 相关、工具相关、Loop 表示主题；
- Projects、Content、OPC 表示使用场景。
一旦这些维度混在同一层，每篇笔记都可能有三个合理去处。
问题不是文件夹不够多，而是每个文件夹回答的问题不同。
## 第一个改变：目录只负责知识流转
最后我保留了一套很克制的顶层结构：
00_Inbox 未处理入口
01_Sources 外部原始资料
02_Notes 自己形成的观点
03_Maps MOC 主题地图
04_Projects 有完成条件的项目
05_Areas 长期维护领域
06_Output 准备发布或交付的内容
07_Archive 不再活跃的内容
90_Attachments 图片和附件
99_System 模板与系统规则
这套结构不负责回答“这篇内容属于 AI 还是软件工程”。
主题交给 YAML 和 MOC，目录只回答更稳定的问题：
> 这篇内容现在处于知识生产流程的哪一环？
于是判断变得简单了：
- 刚刚收集、还没处理的内容进入 Inbox；
- 别人写的原文进入 Sources；
- 我自己形成的判断进入 Notes；
- 有明确目标的工作进入 Projects；
- 准备公开发布的内容进入 Output。
不知道放在哪里时，一律先放 Inbox。
## 第二个改变：把“来源”和“观点”彻底分开
过去我会在一篇收藏文章旁边写一点感想，然后认为自己已经处理过了。
但来源笔记和永久笔记承担的是两种完全不同的职责。
来源笔记保存的是：
> 作者说了什么，我以后怎样找到证据？
永久笔记保存的是：
> 我现在认为哪个观点成立，它为什么成立，能在哪里使用？
因此来源笔记可以很长，永久笔记应该围绕一个可以独立复用的判断展开。
例如，我收藏了一篇关于 Agentic Engineering 的长文《Own the Outer Loop》。如果只是保存原文，它仍然只是一个未来可能不会再打开的链接。
真正处理之后，它被拆成了五个属于我的判断：
- 工程师应拥有 Agent 的 Outer Loop；
- AI 软件工厂需要 Evidence、Verdict 和 Answerability；
- 自动化将瓶颈从生成转移到控制与问责；
- Agentic Engineering 的三类隐藏成本；
- Agent 自主性必须受到 Back Pressure 约束。
这些笔记不再依赖我重新阅读整篇英文原文。它们可以单独进入文章、项目、演讲或者下一次技术决策。
这时，收藏才真正变成了知识。
## 第三个改变：MOC 不是目录，而是问题地图
很多人使用 MOC 时，只是把同类笔记列在一起。
这当然有用，但还不够。
我现在更愿意把 MOC 理解成一个主题的“问题空间”。它不只告诉我已经有哪些内容，还应该告诉我：
- 这个领域的核心问题是什么？
- 我目前形成了哪些判断？
- 哪些来源支持这些判断？
- 哪些地方仍然存在冲突或空白？
- 下一步应该验证什么？
因此我的 Loop Engineering MOC 中，不只有来源列表，还包括：
- Verify、State、Stop 三个基本条件；
- 什么任务适合自动 Loop；
- 如何计算 accepted change 的真实成本；
- Maker 和 Checker 为什么应该分离；
- 为什么 Loop 必须设置预算和熔断器；
- 人类为什么必须拥有 Outer Loop。
目录解决“文件放在哪里”，MOC 解决“知识之间是什么关系”。
## 第四个改变：YAML 只保留真正会使用的字段
我一开始也想做一份“全局 YAML”，希望每篇笔记都拥有完整属性。
后来发现，属性越多不等于系统越好。
如果一个字段不会被搜索、筛选、复盘或自动化使用，它只是维护负担。
最后保留的核心字段很少：
```
type: source
status: processed
created: 2026-07-11
updated: 2026-07-11
topics:
- agent-engineering
source_type: x
source_url: https://x.com/...
related:
- "[[MOC - Agent 工程]]"
```
其中：
- type 表示它是什么；
- status 表示它处理到什么阶段；
- topics 表示它讨论什么；
- related 表示它和哪些知识发生关系。
文件夹、属性和链接各做一件事，不互相重复。
## 第五个改变：把 AI 放在正确的位置
这次改造中，AI 做了很多工作：
- 扫描目录和文件类型；
- 发现分类逻辑冲突；
- 统一 YAML；
- 创建模板和 MOC；
- 从长文中提炼候选观点；
- 检查链接和附件是否可以解析；
- 把永久笔记重新组织成输出文章。
但 AI 没有替我决定知识库最终为什么服务。
真正需要我负责的是：
- 哪些主题值得长期积累；
- 哪些来源值得相信；
- 哪个观点代表我的判断；
- 哪些内容准备以我的名字发布；
- 如果内容有误，我是否愿意为它负责。
这和 Agentic Engineering 的 Outer Loop 完全一致。
AI 可以运行知识加工的 Inner Loop，但个人知识库的 Outer Loop 必须属于我。
## 一篇收藏文章是怎样变成输出内容的
现在我的处理流程变成了：
收藏文章
↓
00_Inbox：等待判断
↓
01_Sources：保存原文和来源
↓
02_Notes：提炼自己的观点
↓
03_Maps：接入已有问题地图
↓
06_Output：重新组合成文章
《Own the Outer Loop》就是第一次完整走通这个流程的素材。
它从 Inbox 进入 Sources，产生五篇永久笔记，连接 Agent、Loop 和软件工程三张 MOC，最终又形成一篇中文输出文章：
Agent 能写代码，但工程师必须拥有 Outer Loop。
这条链路最重要的不是“一篇文章变成了六篇文章”。
真正重要的是，同一份输入在我的知识库里留下了不同层次的资产：
- 可追溯的原始来源；
- 可独立复用的观点；
- 可持续扩展的主题地图；
- 可以面向读者发布的输出内容。
## 个人 IP 不是持续制造内容，而是持续公开自己的判断
如果知识库只负责收藏，它和个人 IP 没有直接关系。
但当知识库开始记录你的选择、判断、验证过程和实践结果，它就会自然成为个人 IP 的内容基础。
个人 IP 最有价值的素材，并不是“我又看到了什么”，而是：
- 我为什么保存这篇内容；
- 我从中提炼出了什么；
- 我同意什么，不同意什么；
- 它怎样改变了我的工作方式；
- 我把它用在了哪个真实项目里；
- 实践之后，我的判断发生了什么变化。
这些内容很难被别人复制，因为它们来自你的连续过程，而不是一次生成。
## 最后的体会
一个知识库真正开始产生价值，不是从文件夹变得整齐开始，而是从内容能够流动开始。
Inbox 让输入没有压力，Sources 保存证据，Notes 沉淀判断，MOC 建立关系，Projects 让知识进入行动，Output 让经验进入公共空间。
AI 能够显著降低整理、提炼和重组的成本。
但知识库最后留下什么、相信什么、公开什么，仍然必须由自己决定。
因为这不只是你的笔记。
这是你长期判断力留下来的轨迹，也是个人 IP 最难复制的部分。
## 相关链接
- [Cander](https://x.com/Cander_zhu)
- [@Cander_zhu](https://x.com/Cander_zhu)
- [328](https://x.com/Cander_zhu/status/2076214145922523304/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [3:56 PM · Jul 12, 2026](https://x.com/Cander_zhu/status/2076214145922523304)
- [328 Views](https://x.com/Cander_zhu/status/2076214145922523304/analytics)
---
*导出时间: 2026/7/12 19:40:18*