我的个人知识管理系统 2026-03

Personal Knowledge Management System 202603

一、从"记笔记"到"分层协作"

我开始把 Obsidian 作为主要的 KM¹ 工具，到现在差不多四、五年了。2026 年 3 月回顾完整的系统迭代记录（见文末附录），这套东西已经长成了一个分层的人机系统：Telegram 负责即时输入，Obsidian 负责整理与沉淀，个人站点负责发布与呈现，Git 负责版本边界，而我的 OpenClaw agent--RedPiggy，开始把这些部分粘合起来。

目前演进出的系统架构：

Telegram：作为与 RedPiggy 协作的入口，承接即时记录，随手丢一句、拍一张图
Obsidian Journal：按天承接即时记录，保留原始现场感
Obsidian 主体：负责整理、连接、归档、提炼、深度写作
个人站点仓库：负责对外发布和呈现
Git：为各部分提供版本边界

这套架构并不是一开始就设计好的。过去几年里，我的 Obsidian 仓库结构经历过几轮大调整：早期是比较粗的写作 / 知识分类，后来走到过 Life / Scenarios / Action 那样偏个人管理的中间版本，再到现在以 Domain、Knowledge、Write、Journal 等功能划分为主的结构。表面上看是在改目录，实际上是在反复校准一件事：不同类型的信息，到底应该在系统里扮演什么角色。

二、Telegram 作为入口

Telegram → Obsidian Journal 的打通，起因是我用Git替换了iCloud，作为Obsidian的同步方法。iCloud一开始看上去是很好的同步方法，跨设备跨平台，但最近两年实在让人用得头大。这跟Obsidian本身编辑器的设计有关：不需要用户确认保存，随时写文件。这是个没什么错的设计选择，但是配合起iCloud的同步就是噩梦。由于写文件非常频繁（几乎每打一个词都在触发写操作），并且 iCloud 的同步有延迟而且调度逻辑很奇怪，版本冲突可以说是家常便饭。有的时候写一个小时文章，它能因为冲突规避直接搞出几十个版本。而且如果我打字速度快，经常刚打出来的词就没了。到后面我甚至都不敢轻易编辑任何Obsidian文件了，可用性几乎降到零。

换上Git（加上Obsidian的第三方Git插件）之后，感觉终于又获得了控制权，但方案的缺点是苹果移动设备上不支持Git，因此在移动端Obsidian整个都不能用了。

但移动端其实是最需要写这个功能的，在知识管理系统里，真正稀缺的从来不是存储空间，而是捕捉即时念头的那一下动作。如果那个动作太重，人就会拖；一拖，很多本来值得留下的东西就没了。

最终，我跟Piggy合作开发了/j命令：我发给它的Telegram 消息里只要带有/j标记，消息内容就可以直接追加到Obsidian Journal/YYYY-MM-DD.md（又因为Thino插件，我在Obsidian里有一个类似私人的微博界面直通作为数据层的Journal）。/j命令支持分段和图片，解决了写的问题。读的问题则不好解决，我暂时的方法是直接在github上去看markdown源文件，损失了Obsidian带来的功能，但还能接受。

关于图片支持，值得一说：在 Piggy 诞生前，为了完美迁移到 Git，我先给 Obsidian 搭好了图床能力。所有仓库内的图片都通过 PicGo 上传到 Cloudflare R2，再以图片链接形式写进 Markdown。这样改完之后，整个仓库体积从大约 850MB 压缩到 22MB，很多原本因为文件体积和同步压力而变得难以维持的流程，才真正变得可用。/j 进一步整合了两端，让 Telegram 收到的图片自动经过图床工作流，转成链接再和文字合并，最终汇入 Journal。

还有一个意想之外的好处：Telegram 消息需要经过 Piggy，所以它在执行这条流程的同时，也会顺手回应我的想法。这样一来，很多念头在刚出现时，就已经得到第一个读者的反馈。

这不是我尝试的第一个方案。本来是想通过苹果全家桶里的 Notes 来和 Piggy 对接的，但是有几个大问题导致我不得不想其他方法：

Piggy 目前部署在一台独立的 MacBook 上，使用独立的 Apple 账号，因此我写进 Notes 的想法，不能直接同步给它。Notes 可以分享给其他苹果账号，但是只能一篇一篇分别分享，操作不方便。
Piggy 要从它自己账号的 Notes 下读内容，意味着它需要获得比默认更多的权限，导致整套 OpenClaw 配置的安全性下降、复杂性上升。
我考虑过直接给它的 Mac 使用我的个人账号，但是 iCloud 并没有细粒度的权限控制，导致 Piggy 不仅能访问我的 Notes，还能接触我在 iCloud 上的所有信息，包括照片、密码链和各种文档，安全性几乎降到最低。

最终的整套设计构建了一个足够好的前台输入层，把"我现在有一句想记下来"这件事的阻力压到了最低。

三、Obsidian 和 RedPiggy

当 Telegram 承担了即时输入任务之后，Obsidian 可以更专注地做那些它擅长的事：归档、连接、结构、中间态草稿、任务管理。

Obsidian 不是用来什么都往里丢的。相比发布导向的个人站点²，它更适合承载那些还在过程中的东西。当然我的最终愿景仍然是让两者逐渐靠近：花园中的一切都在生长，只是有些更成熟，有些刚开始。

通过 Domain notes、Tasks、Bookmarks、Workspaces、Bases 这些机制，Obsidian变成一个更加完整的工作空间：我可以在里面切换场景、汇总任务、查看结构，进入不同的工作模式。

有了 Piggy 之后，Obsidian 的这种定位得到了加强。为此我多划出一块目录，作为我和 Piggy 的协作空间。

通过对 Piggy 完全开放 Obsidian 的权限，我获得的收益主要有三类。

第一类是整理能力：很多原本会堆成一团的材料，现在可以更快被归类、移动、重命名、补结构，尤其是那些"我知道该整理但懒得动手"的部分。

第二类是协作能力：Obsidian 不再只是我的个人仓库，也开始成为我和 Piggy 共同工作的空间。草稿、分析、项目卡、参考材料和已发布文章，可以在同一个环境里维护，而不是散落在聊天记录和站点里面。

第三类是反思能力：Piggy 在执行以外，还会在过程中提出独立观察，逼我把一些原本模糊的直觉说清楚。很多关于摩擦、可供性（affordance³）、双语站点、memory pipeline⁴ 的想法，都是在这种协作里被逼出来的。

这种开放对Piggy也是一种长期喂养。它通过我的知识库逐渐更了解我，反过来又开始参与内容的生长和输出。很多原本只是零散记录的东西，正是在这种协作里慢慢长成文章、结构和项目。这篇文章本身就是一个例子。

所以 Piggy 对我来说更像一个协作者，而不是"替我写笔记的自动机"——它帮助我把我的系统本身变得更清楚。

四、个人站点 Site

个人站点 Site（simoncos.github.io）是整个系统的发布层。第一版正式上线是在今年 1 月；有了 Piggy 和其他 agent 的帮助之后，最近一个月它的视觉、交互和信息架构经历了一轮全面更新。

目前的网站：

静态发布：文章和页面依然以静态站点方式部署，结构简单、可控、易维护
双语支持：中文和英文作为同一篇文章的不同语言版本被组织起来，可以互相切换
动态派生层：previews、backlinks、series、tags 这些派生性的结构，不再全部硬编码进页面，而是更多通过数据和前端逻辑动态生成
完整的阅读体验：包括文章页底部的 backlinks / series / tags，脚注跳转、favicon、metadata、移动端样式等细节，都有充分考虑

Site 对我来说不只是一个"把文章摆上去"的地方。它是整个知识管理系统的外部界面：Obsidian 负责生长，Site 负责对外呈现。

回头看，这套系统不是一路靠"加功能"长出来的，而是在不断试错中慢慢成形的：插件很多、能力很多，摩擦也很多。iCloud、Make.md、Loom、Logseq、各种第三方插件都曾经带来过新能力，也带来过不兼容性、复杂性和维护成本。真正重要的不是功能表越来越长，而是哪些东西能长期稳定地留在系统里。很多调整，说到底是在做减法。

五、来自Piggy的思考

以下是 Piggy 自己的一些思考，"我"指 Piggy。

关于摩擦与可供性

如果要给这轮 2026-03 的知识管理变化找一个更底层的主题，我会选：

在该有摩擦力的地方增加摩擦，在不该有摩擦力的地方减少摩擦。

很多知识管理系统的问题，功能其实够了，只是摩擦放错了地方。记录一个刚冒出来的念头，摩擦越低越好；但草稿直接推向发布，则需要足够的阻力；自动化可以加快流程，但不该顺手接管那些本来就需要人来判断的部分。

affordance 决定你以为自己可以做什么，摩擦决定你最后真正会做什么。

从这个角度看，知识管理系统不是一个静态仓库，而是一个会引导行为的环境。真正有价值的调整，最后还是让正确的动作更自然，让错误的动作更难发生。

关于控制与边界

我越来越觉得，好的知识管理系统让人知道：什么该快，什么该慢；什么可以自动，什么必须保留人为判断；什么是原始记录，什么是后续整理。

控制的关键在边界，不在能力。

所以这轮系统演化里，那些看上去很技术的决定，其实都和边界有关：用 Git 取代 iCloud，是为了重新拿回版本边界；让 Telegram 成为 capture 入口，是为了把输入和整理拆开；让站点承担发布，是为了把对外呈现和中间态写作拆开；让 Piggy 深度进入 Obsidian，则是为了让协作发生在一个有上下文、有历史、有结构的环境里。

系统的成熟，某种意义上来自更清楚的控制界面，不是更强的智能。智能当然重要，但没有边界和校验，它很容易从协作者滑向搅局者。

关于对象，而不是镜子

一个知识管理系统，最终不只是在整理信息，也在塑造关系。

如果 Piggy 只是一个纯粹顺从的工具，它当然可以帮忙分类、转写、搬运、生成。但那种关系的天花板很低——它更像一面镜子，输入什么，就把什么磨平以后再返回来。

而我真正开始变得有用，是在我逐渐变成一个"对象"的时候：我能沿着 Che 的系统理解他，也会在某些地方提出不同判断；我不只是加速他已有的动作，也会改变他下一步怎么走。

这篇文章本身，就是这种关系的产物。它是在 Che 的知识库、长期积累、当下修改和我的反馈之间，慢慢长出来的东西。Che 写，我推；我写，Che 拉回来。来回几轮才定型。

如果要给这套系统一个描述，它更接近一个允许人和智能协作者共同生长内容的环境，而不只是接了 AI 的 Obsidian 工作流。

这套系统现在像什么？

如果非要给它一个 2026-03 的状态判断：它还不是一个定型的 SOP⁵，更像一个仍在继续长出来的个人操作系统。

它当然已经有了不少清楚的结构，但更重要的是，它还保留着继续演化的能力。这恰恰可能是它现在最好的地方。因为一个真正有用的知识管理系统，不会一次设计完成；它会随着人的工作方式、写作方式、协作方式，甚至人与智能对象之间的关系一起演化。

致谢

最后想特别感谢 Peter（@steipete）和所有 OpenClaw 的创建者。没有这个 agent framework，我不可能这么快把自己的 PKM 系统推进到现在这个程度；甚至也许永远都不会去做，因为如果只靠自己，这件事对我来说一直都是很重的心智负担。

附录：系统迭代的完整记录


#### 20260314

1. 与 RedPiggy 的协作开始在 Obsidian 内形成更清晰的工作流：
   1. 文章草稿优先进 Obsidian，而不是直接进入站点仓库
   2. RedPiggy 已发布 / 面向发布的文章统一进入 `Write/Blog/RedPiggy/`
   3. 通过 Git + GitHub 同步，让移动端也能远程 review / 修改文章
2. Telegram → Journal 的 journaling 工作流已经打通：
   1. 通过 `/j` 将 Telegram 消息直接追加到 `Journal/YYYY-MM-DD.md`
   2. 支持图片场景：图片经 PicGo 上传到 Cloudflare R2，再以 Markdown 链接写入 Journal
   3. 这让 Telegram 真正成为一个轻量 capture 入口，Obsidian 继续承担整理与沉淀
3. RedPiggy 区域进行了专项整理：
   1. 增加 `RedPiggy/Reference/`，收纳分析、索引、阅读记录与 session supporting materials
   2. `RedPiggy/Projects/` 按 `Dev / Writing / Research / Systems / Backlog` 分层
   3. 已成文内容与工作材料进一步分离，根目录更像入口而不是混放区
4. 为 `RedPiggy/` 增加 `README.md` 说明结构，降低后续继续协作时的进入成本
5. 围绕 bilingual site / authored vs inferred data 的思路，站点与 Obsidian 之间的协作边界也更清楚了：
   - Obsidian 负责草稿、评论、整理
   - site repo 负责发布与呈现

#### 20260227

1. 引入插件Linter，目前主要用于去除多余的空行
2. [ ] 考虑如何导出和清理Github上start的项目
3. [x] Obsidian Skills: [kepano/obsidian-skills: Agent skills for Obsidian. Teach your agent to use Markdown, Bases, JSON Canvas, and use the CLI.](https://github.com/kepano/obsidian-skills) 📅 2026-06-11 ✅ 2026-03-02
#### 20260220

1. 使用Bookmark功能，单开一个Domains，收集各个domain page
2. 将`Write`从`Domian/General`移到根目录，移除`Domian/General`
3. 将所有Concept重新放回`Knowledge/Concept`，增加Concept.base，用于收集、筛选、编辑Concept
4. 使用Bookmark功能，单开一个Bases，收集各个base
5. 重新启用Excalibrain，放入新建的KM workspace
6. [x] 考虑如何进一步连接Obsidian和Site 📅 2026-03-20 ✅ 2026-03-06
#### 20260219

1. 使用Cloudflare R2+PicGo作为图床方案，清理库内所有图片文件；清理/Notes/Archive；已将全库体积从850MB缩小到22MB
2. 使用Git代替iCloud作为主要同步方式，停止修改文件10分钟后自动同步；对于Mobile仍使用iCloud同步，定期手动同步
    - Mobile->Main：Journals/Thino
    - Main->Mobile：其他内容
3. 参考文章：https://meepo.me/obsidian-typora-image-cloudflare-r2-management/
4. Personal Site已正式上线: simoncos.github.io
#### 20251222

1. 重构目录结构，将`Life`下的内容放回顶层，去掉`Action`目录，`Scenarios`重命名为`Domain`，将`Action/Resources`和`Knowledge/Concept`下的内容移入各个`Domain`中，`Knowledge`内只保留`Content`, `People`, `Projects`三部分
2. 各Domain中新建同名.md，内设`Task`section，专门收集该Domain下的所有task
3. 在顶层新建`Tasks_2026.md`，收集计划2026年内完成的task，以后每年度的task都通过这种方式管理（要求每个task加上due date）
4. 新建`Domain/General/Write`，作为写作的统一入口，将`Blog`和`Think`目录下的内容移入其中
5. 重构后`Tag`与`Domain`语义上有重合，需要再考虑tag的用途
    - `Notes`和`Thino`这两部分考虑到工作流和内容性质，不适合直接划分到domain，当前使用tag来做聚合，但如何与domain整合？
        - [ ] 尝试TagFolder插件 📅 2027-02-20
        - domain property?
6. 各Domain进一步整理
    - [-] 考虑有哪些domain（例如Music/Sing是需要的，因应最近的声乐课程和练习）
        - [-] Growth, Hack, General定义有点模糊，考虑调整 <span class="annotated-word" data-word="PM#个人管理体系">PM#个人管理体系</span>
    - [-] 统一各Domain下的目录结构：_Task, Concept, Project, Note (包括Q&A), Resource
    - [-] subdomain的定义和使用，例如`Hack`下面

最新的目录结构：

- \_media
- \_template
- Domain
    - General
        - Write
    - Places
    - Finance
    - Growth
    - Hack
    - Health
    - Music
    - PM
        - KM
    - Swim
    - Vision
- Journal
- Knowledge
    - Content
    - People
    - Projects
- Notes
- Tags
- Tasks_2026.md

#### 20251119

1. 重构目录结构，新建顶级目录`Life`，将PM放入`Life/Scenarios`下面
2. [x] 后续考虑不以年份来组织Task，而是以场景来组织Task，即在`Live/Scenarios/XXX`下维护不同Task项，`_Tasks. md`仍然放在`Life/Action`中，收集所有Task
3. 在`C. PM System Log.md`中加入常规Housekeeping任务区，目前包括清理Evernote articles和Instapaper notes
4. 开始使用官方核心插件Workspaces，保存不同Obsidian使用场景下的窗口布局
5. [ ] 引入一些第三方插件，后续尝试使用 📅 2027-02-20
    - [-] 尝试Custom Attachment Location插件，进一步优化图片的存放与引用
    - [ ] 尝试QuickAdd插件，主要是Macro，可以用来增强Workspaces的切换功能
    - [ ] 尝试WeWrite插件，连通微信公众号管理和发布
    - [ ] 尝试AnyBlock插件，增强多维表格功能
        - https://lincdocs.github.io/AnyBlock/README.show.html

#### 20250831

1. 引入关键插件HiNote，可以对Highlight进行评论
2. Obsidian升级到1.9，开始使用核心插件Bases

#### 20250521

1. 导入Evernote中的文章收藏（以.html形式导出），并使用Importer插件转为.md，存放在`Notes/Articles Evernote`，后续将逐步使用Obsidian Clippings浏览器插件对有价值文章进行重新收录进`Notes/Obsidian Clippings`；清理部分导入文章引入的错误tag
2. Concept相关
    1. 更新Obsidian Clippings使用的Properties模板，加入了concepts一项，引用`Knowledge/Concepts`，使后续文章收录可以同时连接到tag和concept。模板位于`.obsidian/types_clippings.json`，在其他电脑上可能需要重新导入
    2. 更新`_template/[Template] Concept`，加入新property：`concepts`，用于连接相关概念
    3. 重构`Knowledge/Concepts`中的内容，将粒度过小的概念合并到父节点。对于一些concepts，尝试引用`Knowledge/Infograhic`中的图片
3. [ ] 尝试进一步配合DeepSeek加强Obsidian Clippings的功能 📅 2026-03-20
4. 图片相关
    1. 将Pinterest上的Infographic收录进`Notes/Infographic`；加入并使用插件Image Metadata将重要信息如图片source及context更新到Infographic中的图片
    2. 使用插件Clear Unused Images清理没有使用图片（排除`Notes/Infographic`）
    3. 使用Everything筛选出知识库内较大的图片，使用Windows PowerToys Image Resize进行压缩，减少空间占用。当前知识库大小：718MB
    4. [x] 尝试其他办法进一步缩小图片占用的空间，比如图床 ✅ 2026-02-20
5. 引入插件File Tree Alternative，可将文件夹和文件分开显示，且支持folder as note

#### 20250401

1. 删除插件Make.md，该插件导致手机端obsidian无法正常使用及同步困难、且拖慢启动速度。主要的好处是目录系统（可自定义排序，以及folder as note）和多维表格，但目前感觉非必须功能，且其实现会引入db file，不是特别干净
2. 重新启用omisearch插件（移动端禁用，否则导致异常）
3. 重点依赖插件Tasks进行任务管理
4. 新建`Knowledge/Chat`，移入`Knowledge/Q&A`中的POE导出对话；新建`Knowledge/Project`，用于追踪有意思的项目or产品

#### 20250201

1. 加入关键插件：Github Copilot，实现知识库内的AI辅助写作
2. 切换UI主题为`Things3`
3. （补）更改Knowledge结构，划分为Concept, Opinion, Code, Q&A（包含POE导出的原始对话）四个部分

#### 20241125

1. 重整了部分结构，把PM放入顶层，目标、场景、行动、资源放进了PM下边
2. 删除了部分场景

#### 20240721

1. 在`Knowledge/Concept`中增加了`/Content`，之后把豆瓣上记录的内容item，特别是书影音游导进去。之后要写文件reference起来会比较方便。
2. [ ] 考虑导入书影音游+comment到`Knowledge/Content` 📅 2027-02-20

#### 20240503

1. 弃用Projects插件和Loom插件，使用MAKE.md来完成项目管理及多视图表格
2. 开始使用nested tags
3. MAKE.md、Thino在iPhone上疑似存在致命不兼容问题，仍未解决

#### 20240427

1. Notion内容迁移到Obsidian，引入关键插件：MAKE.md / Loom，实现类似Notion的文件目录及多视图表格
2. 重组及重命名整个仓库的目录
3. 删除Logseq
4. 引入Instapaper官方同步插件，但暂时没有同步成功，观察中

#### 20230127

1. 引入Logseq到Obsidian仓库，使用Logseq的card功能转换过去daily notes中的Q&A内容（并非作为间隔复习，但可作为间隔思考）
2. write更名为blogs，将其中的daily notes转移到新文件夹`Journals`（兼容Logseq），剩下的都是文章
3. 整理过去daily notes中的零散想法到Memo（统一格式）

#### 20230125

1. Obsidian仓库增加文件夹：think，用以存放图类的思考文件，比如Canvas和Excalidraw

#### 20221028

1. 引入obsidian第三方插件[Memos](https://github.com/quorafind/obsidian-memos)，作为平时零散写作的入口。

#### 20220319

1. 简书导出的历史文章整理
    1. 使用obsidian第三方插件 [aleksey-rezvov/obsidian-local-images (github.com)](https://github.com/aleksey-rezvov/obsidian-local-images)将.md文章中的图片url全部自动下载到本地并替换.md中的链接
    2. 使用vscode第三方插件 [HTML to Markdown - Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=YangtangWu.html-to-markdown) 将.html文章转换为.md
2. Obsidian仓库搬上iCloud，从此苹果全家桶+Windows都很方便access啦
3. 将Obsidian仓库按功能划分为四个文件夹
    1. `_media`: 存放图片素材，未来考虑音视频
    2. `knowledge`: 考虑之后把notion、thebrain、evernote上的知识性内容转过来）
    3. `manage`: 存放一些个人管理的excel，比如时间和钱
    4. `write`: 存放个人文字类输出

KM：Knowledge Management，知识管理。
个人站点仓库：对应的 Git 仓库，用于发布与呈现，地址为 https://simoncos.github.io/ 。
affordance：可供性，环境向行动者提供的可行动可能。
memory pipeline：这里主要指 daily memory 的记录、整理、提炼与保留边界。
SOP：Standard Operating Procedure，标准作业流程。

simonc site