你的笔记是不是也这样：
- 收藏了 1000+ 篇文章，再也没打开过
- 看到好的观点就截图，图库满了知识还是零
- 每次写方案都要从零开始搜资料，过去的积累用不上
- 明明整理了很多笔记，真正输出时却想不起来
问题不是你不够勤奋——是知识库只是个"收藏夹"，不是个"能自动帮你干活的系统"。
0xShimei 给了 Obsidian + Codex 方案：10 分钟搭出来，让知识库自己生长、自己整理、自己输出。
核心理念：消化系统 vs 收藏夹
传统知识库 = 收藏夹——只进不出，越堆越乱。
自生长知识库 = 消化系统——
吃进原料（网页 / 论文 / 截图 / 会议纪要）
↓ AI 消化
抽出概念（核心观点 / 数据 / 案例 / 方法论）
↓ 任务调用
输出产物（文章 / 报告 / 方案 / 代码）
关键是"消化"这一步——Codex 定期读你的原料库，结构化整理进概念库，再抽取方法论到 Skill 库。
4 文件夹闭环
整个系统分成 4 个文件夹：
📁 A. 原料库（未处理原始资料）
- 网页、论文、截图、视频字幕、会议纪要
↓ Codex 定期消化复盘
📁 B. 概念库（处理后的结构化知识）
- 核心观点、数据、案例、方法论
↓ 根据任务/场景调用
📁 C. Skill 库（可复用的方法论模板）
- 选题判断标准、写作风格、周报模板、分析框架
↓ 任务触发
📁 D. 输出库（任务产物）
- 写完的文章、做完的报告、产出的代码
↓ 反馈学习
📁 B. 概念库（更新方法论）
↻ 闭环
每个文件夹功能清晰，不混淆：
- A 原料库 = 你日常"吃进去"的东西，不整理，只进不出
- B 概念库 = Codex 消化后的"知识肌肉"，可 query、可调用
- C Skill 库 = 可复用的方法论，触发即用
- D 输出库 = 任务产物，反哺 B 的方法论
没有 Codex——这套系统就是 4 个文件夹，你手工整理。有了 Codex——它定期跑 ETL，把 A 消化成 B，从 B 抽取 C。
Codex 在知识库里的具体工作
任务 1：消化原料（A → B）
每天/每周 Codex 定时跑：
扫描 A 原料库所有新文件
↓
按主题分类（技术 / 设计 / 商业 / 个人）
↓
每篇提取 3-5 个核心观点
↓
写入 B 概念库，附上原文链接
不是"全文复制"——是结构化抽取。B 概念库里是结构化的知识卡片，不是文章。
任务 2：抽取方法论（B → C）
每月底 Codex 跑：
扫描 B 概念库所有新概念
↓
按"可复用方法"vs"单次案例"分类
↓
可复用方法 → 提取成 Skill 模板
↓
写入 C Skill 库
Skill 不是 prompt 模板——是触发条件 + 操作流程 + 验收标准的完整方法论。
任务 3：按任务生成（D 从 C 调用）
每次你要做任务时：
告诉 Codex："我要写一篇关于 X 的文章"
↓
Codex 查 C Skill 库："X 主题的写作 Skill 是什么？"
↓
Codex 查 B 概念库："X 主题的核心观点、案例、数据有哪些？"
↓
按 Skill 模板 + B 概念 → 生成 D 输出
↓
写入 D 输出库
D 输出库的所有产物都附带"使用了哪些 B 概念 + 触发了哪些 C Skill"——可追溯。
关键工程细节
文件夹隔离很重要
A / B / C / D 必须物理隔离——
- A 不能引用 B 的内容（避免循环）
- D 不能修改 A（保护原始资料）
- C 是 Codex 唯一能写入 + 读取的"方法论真理之源"
Obsidian 的 vault 分文件夹 + Codex 通过 MCP 限定文件路径——这是工程基础。
Codex 不是"一个 agent"是"多个角色"
0xShimei 提到：Codex 在知识库里跑 3 个不同 role：
- 消化员（A → B）：专注提取结构化观点
- 方法论提炼员（B → C）：专注抽象可复用模式
- 执行员（C + B → D）：专注按 Skill + 概念生成产物
每个 role 调不同的 model：
- 消化员 + 执行员 = Sonnet（成本甜点）
- 方法论提炼员 = Opus（需要 judgment）
反馈循环
D 输出库不是"扔掉"——产物完成后 Codex 回头评估：
- 这篇用了哪些 Skill
- 哪个 Skill 在这次用得不对
- 哪个概念被错误引用
评估结果写回 B 概念库 + C Skill 库——Skill 库会自我迭代。
跟传统 Obsidian 笔记的区别
| 维度 | 传统 Obsidian | 0xShimei 方案 |
|---|---|---|
| 笔记量 | 越多越乱 | Codex 自动整理 |
| 检索 | 手工搜索 | Codex 按任务调用 |
| 复用 | 凭记忆 | C Skill 库显式沉淀 |
| 输出 | 重新开始 | D 输出库有完整素材 |
| 反馈 | 没反馈 | Codex 评估 → 更新 Skill |
核心区别：传统 Obsidian 是"死的笔记"，0xShimei 方案是"活的系统"。
适合谁 vs 不适合谁
适合
- 每天产生大量信息（研究者、咨询、投资、内容创作者）——消化系统是刚需
- 重复类型任务（每周写报告、每月复盘）——Skill 库的价值最大化
- 跨项目复用方法论（同一套方法做不同行业）——C Skill 库抽象对
- 愿意花 10 分钟搭系统——一次性成本，永久受益
不适合
- 每天任务都是新类型（探索性研究、创意工作）——Skill 库价值有限
- 信息量小（每周 1-2 篇文章的输入）——overhead 大于收益
- 不愿意维护——Codex 跑 ETL 需要监督，"扔进去不管"会乱
0xShimei 没说的两件事
1. Codex 在 B/C 写入的"判断错误"很难发现。Codex 提炼的 Skill、写回 B 的概念，有错误时只有用错时才暴露——比如"这个 Skill 适用 X 场景"被错标成"Y 场景"，所有按 Y 调用 Skill 的任务都会失败。Skill 库越大，错误标签的"爆炸半径"越大。需要定期人工 review C Skill 库——这是隐藏的运维成本。
2. A 原料库的"消化优先级"决定知识库质量。Codex 扫 A 提炼 B 时，它不知道哪些原料"重要"——你截图的一张图、你收藏的一篇水文、你精心研读的论文，在 Codex 眼里都是"新文件"。结果可能是：次要内容被消化成概念，主要内容被跳过。实操需要给 A 文件加 priority 标签（Obsidian frontmatter），Codex 按 priority 决定消化顺序。
结论
0xShimei 的 4 文件夹闭环方案把"知识库"从"收藏夹"变成"消化系统"——这是个人知识管理的范式转移。
关键洞察：
- Codex 不是"帮你写"，是"帮你消化"——它跑 ETL
- Skill 库（C）是核心资产——不是 B 概念库
- 反馈循环让 Skill 库自我迭代——飞轮效应
SOTA Sync 的判断：未来 12 个月，"自生长知识库"会成为 AI 重度用户的标配——Obsidian + Codex/Claude Code 组合会成为个人知识管理的事实标准。Notion / Roam / Logseq 这些传统工具会被冲击——它们没原生支持 agent 跑 ETL。
但 "消化优先级"是知识库质量的关键变量——垃圾进、垃圾出。给原料打 priority 标签是这套方案的工程基础，不是可选项。