# 7天用 Codex Skill 把 Obsidian 改造成可执行的第二大脑
**作者**: 知识猫图解
**日期**: 2026-06-22T11:47:49.000Z
**来源**: [https://x.com/GeekCatX/status/2069024555197497479](https://x.com/GeekCatX/status/2069024555197497479)
---
从本地 Markdown 知识库出发，搭建一个会整理、会查证、会推进项目、会产出作品的个人知识 Agent
很多人的“第二大脑”，一开始是为了减轻负担，最后却变成了另一个需要维护的系统。
收藏越来越多，真正复用的越来越少；笔记越写越完整，观点却没有持续积累；文件夹和标签越分越细，需要信息时仍然找不到。AI 当然可以总结一篇文章，但它通常不了解你的长期项目、判断标准和工作方式。
问题往往不在笔记软件本身，而在知识库缺少一个持续工作的“知识操作员”。
Obsidian 很适合作为长期记忆层：笔记以本地 Markdown 文件保存，外部工具修改文件后，Obsidian 会同步读取变化。Codex 则可以在授权范围内读取和修改目录、执行脚本，并通过 AGENTS.md、Skills、Automations 和 Git Worktrees 固化工作规则。
把两者放在一起，目标就不只是“和笔记聊天”。更有价值的方向，是让系统持续完成一个闭环：
```
捕获信息
→ 保留来源
→ 提炼知识
→ 连接项目
→ 推进下一步
→ 产出作品
→ 复盘并沉淀
```
这篇文章给出的方案是：把第二大脑的方法、目录、规则、模板、安全机制和日常流程，封装成一个可安装、可升级、可验证、可回滚的 Codex Skill。
## 一、把方法变成系统
Obsidian Vault 本质上是一组 Markdown 文件，AI 可以直接读取、整理和维护它们；很多场景不必一开始就引入复杂的 RAG、向量数据库或 MCP。
这个思路最关键的地方，是 Markdown-first。
Markdown 是长期可保存、可迁移、可版本控制的数据层；规则文件告诉 Agent 该怎样工作；index.md 为目录提供压缩后的上下文；AI 既能搜索笔记，也能维护结构、检查证据、推进项目。
如果只是把教程里的名字替换一下：
```
Claude Code → Codex
CLAUDE.md → AGENTS.md
```
那只是迁移工具，还没有形成系统。
Codex 更值得利用的地方，是把零散方法封装成稳定工作流：
- Skill：封装可重复执行的任务说明、参考资料、模板和脚本；
- Plugin：当需要向其他用户分发时，把一个或多个 Skill 打包成可安装单元；
- AGENTS.md：保存项目级长期规则，并支持从仓库根目录到当前目录逐层细化；
- Automations：定时运行已经验证过的流程；
- Worktrees：在 Git 项目中隔离高风险或后台修改。
这样，一篇教程可以被“编译”为一个可执行能力：
```
$second-brain-bootstrap
```
用户不必反复手动搭目录、复制模板、编写规则、检查冲突。更好的体验是：先看到计划，再让 Skill 完成安装与验证。
## 二、设计这套系统的四条原则
1. 用户保持简单，复杂度交给 Skill
日常使用时，用户只需要理解几个稳定入口。几十个属性、模板和命令，可以由 Skill 在后台维护。
2. 知识要能推动行动
知识管理的价值不在“存得更多”，而在能不能更快找到证据、更快形成判断、更快推进项目，并更稳定地产出作品。
```
更快找到证据
更快形成判断
更快推进项目
更稳定地产出作品
```
3. AI 的修改要可解释、可检查、可撤销
批量操作最好先回答几个问题：
```
改了什么？
为什么改？
哪些判断不确定？
哪些内容需要人工确认？
如何撤销？
```
只要涉及自动整理、迁移、重命名或修改大量文件，这些问题就不该省略。
4. 先手动验证，再封装，再自动化
未经验证的流程，如果直接自动化，只会更快地产生混乱。
更稳妥的顺序是：
```
手动运行
→ 修改提示词
→ 封装 Skill
→ 测试边缘情况
→ 小范围自动化
→ 定期复盘
```
## 三、最终架构：用户只看到五个入口
建议先从一套最小结构开始：
```
SecondBrain/
├── AGENTS.md
├── index.md
│
├── 00-Inbox/
│ └── index.md
├── 10-Projects/
│ └── index.md
├── 20-Notes/
│ └── index.md
├── 30-Sources/
│ └── index.md
├── 40-Outputs/
│ └── index.md
│
├── 90-System/
│ ├── templates/
│ ├── reports/
│ ├── schemas/
│ ├── backups/
│ └── system.yaml
│
└── .agents/
└── skills/
├── second-brain-organize/
├── second-brain-project/
├── second-brain-write/
└── second-brain-doctor/
```
用户日常只需要理解前五个目录：
90-System 和 .agents 属于系统层。它们可以由 Skill 维护，不建议变成普通用户每天整理的负担。
这套结构借鉴了 PARA“按行动价值组织信息”的思想，但没有照搬 Projects、Areas、Resources、Archives 四个目录。对于 AI 驱动的知识工作，显式区分“来源、知识和输出”，通常更利于查证与交付。
## 四、目录、属性、链接、索引和规则各司其职
很多知识库失控，是因为试图用文件夹解决所有关系。更稳妥的做法，是让不同机制承担不同职责。
1. 目录：表示主要用途
一篇笔记只保存在一个主要位置，例如：
```
30-Sources/Agent可靠性研究.md
```
目录只回答一个问题：这份内容现在主要用于什么？
2. Properties：表示结构化状态
Obsidian Properties 以 YAML 保存于 Markdown 顶部，适合存储日期、状态、列表和内部链接等小型结构化数据。
第一阶段可以只保留六个字段：
```
---
type: source
status: active
created: 2026-06-22
updated: 2026-06-22
project:
- "[[Codex第二大脑文章]]"
confidence: source
---
```
只有当字段会被搜索、筛选、自动化或质量检查使用时，再新增。为了“看起来专业”堆出几十个属性，后面会变成维护成本。
当数据结构稳定后，可以使用 Obsidian Bases 根据 Properties 创建表格、列表或卡片视图；数据依然保留在本地 Markdown 文件中。
3. 内部链接：表示多对多关系
同一份来源可以服务多个项目：
```
## 相关项目
- [[Codex第二大脑文章]]
- [[AI知识管理产品]]
- [[Agent Skill课程]]
```
目录负责主要归属，链接负责关系网络。这样可以避免为了一个文件到底放在哪里反复纠结。
4. index.md：提供压缩上下文
index.md 不只是自动生成的文件清单，更像一个目录的“导航摘要”。
例如：
```
# Projects Index
## 当前活跃项目
### [[Codex第二大脑文章]]
- 目标：完成一篇可发布、可执行的实战教程
- 当前状态：完成结构重写，正在验证安装流程
- 下一步：测试 Bootstrap Skill 的边缘场景
- 关键资料：
- [[Obsidian AI 橙皮书]]
- [[Codex Skills 官方文档]]
- 当前风险：安装流程尚未在已有 Vault 中验证
```
Codex 可以先读取相关 index.md，再决定是否打开具体文件。这样比每次扫描整个 Vault 更节省上下文，也更接近真实工作流。
5. AGENTS.md：保存长期工作规则
Codex 会组合从仓库根目录到当前工作目录之间的指令文件；越接近当前目录的规则越具体。
第一阶段只需要根目录的 AGENTS.md。系统成熟后，再为 Projects、Sources 等目录增加更细的规则。
## 五、为什么需要一个 Bootstrap Skill
如果用户需要自己完成下面这些事情：
- 设计目录；
- 创建模板；
- 编写 AGENTS.md；
- 安装日常 Skills；
- 判断旧 Vault 如何迁移；
- 初始化 Git；
- 检查 YAML 和内部链接；
- 设计回滚方法；
那“一键第二大脑”只是把复杂教程换了一个名字。
Bootstrap Skill 的价值，是把这些操作变成一次受控安装。
先解决首次安装问题
Vault 里还没有 .agents/skills，创建 Vault 的 Skill 放在哪里运行？
可以先把首次安装 Skill 放到用户级目录：
```
$HOME/.agents/skills/second-brain-bootstrap/
```
Codex 可以从用户级 $HOME/.agents/skills 和项目级 .agents/skills 发现 Skills.
完整流程可以设计成这样：
```
用户级 Bootstrap Skill
↓
扫描当前 Vault
↓
输出 Dry Run 计划
↓
建立恢复点
↓
创建结构与系统文件
↓
安装 Vault 专属 Skills
↓
验证并生成报告
```
安装完成后，用户级 Skill 负责安装、升级和修复；Vault 内的 Skills 负责日常知识工作；如果要面向更多用户分发，可以进一步打包为 Codex Plugin。
## 六、一个合格的 Bootstrap Skill 至少要做七件事
1. 环境扫描
执行前先判断：
```
当前目录是否为 Obsidian Vault
已有多少 Markdown 文件
是否存在 AGENTS.md 和 index.md
是否已有目录体系或 PARA 结构
是否存在同名目标目录
是否已初始化 Git
是否有未提交修改
是否已安装旧版本系统
```
2. 默认 Dry Run
第一次运行只生成计划，不直接修改：
操作、目标、原因、风险、可否回滚
3. 建立恢复点
优先使用 Git，没有 Git 时，为本次涉及的文件创建带时间戳的备份。
如果无法建立恢复点，建议停止批量修改。
4. 幂等执行
同一个 Skill 重复运行，不应产生：
```
Projects/
Projects-2/
Projects-new/
```
第二次运行时，它应该识别现有状态，只安装缺失项或生成升级建议。
5. 非破坏式迁移
面对已有 Vault，默认不要批量移动旧文件。
更稳妥的流程是：
```
扫描旧结构
→ 建立新结构
→ 生成映射建议
→ 用户确认
→ 分批迁移
→ 检查链接
```
无法判断的内容，可以保留原位或进入 Inbox。
6. 安装系统文件和日常 Skills
至少创建：
```
AGENTS.md
根目录及各核心目录 index.md
90-System/system.yaml
基础模板
四个日常 Skills
```
7. 安装后验证
至少检查：
```
目录是否完整
YAML 是否有效
AGENTS.md 是否可读取
index.md 是否存在
Skill frontmatter 是否有效
是否出现重复文件
现有文件是否被覆盖
内部链接是否损坏
Git 或备份是否可恢复
```
## 七、可直接使用的 Bootstrap Skill
在下面的位置创建文件：
```
$HOME/.agents/skills/second-brain-bootstrap/SKILL.md
```
填入以下内容：
```
---
name: second-brain-bootstrap
description: 在当前 Obsidian Vault 中安装、升级、检查或修复一个基于 Codex 的极简第二大脑。适用于新建 Vault、现有 Vault 迁移、系统升级和结构修复。默认先 dry run，不删除、不覆盖、不批量移动旧文件。
---
# Second Brain Bootstrap
## 目标
把当前目录初始化为一个可由 Codex 安全维护的 Obsidian 第二大脑。
用户日常只需要理解五个入口：
- 00-Inbox
- 10-Projects
- 20-Notes
- 30-Sources
- 40-Outputs
系统内部目录：
- 90-System
- .agents/skills
## 不可违反的规则
1. 先扫描，再计划，后修改。
2. 第一次运行默认只执行 dry run。
3. 不永久删除文件。
4. 不覆盖已有文件或模板。
5. 不自动大规模移动现有笔记。
6. 批量修改前必须建立恢复点。
7. 无法建立恢复点时立即停止。
8. 重复执行必须保持幂等。
9. 无法确定的分类保留原位或进入 Inbox。
10. 完成后必须运行验证并输出回滚方法。
## 阶段 1：环境检查
检查并报告：
- 当前目录是否存在 `.obsidian`
- Markdown 文件数量与主要目录
- 是否存在 `AGENTS.md`
- 是否存在根目录或子目录 `index.md`
- 是否存在 `.agents/skills`
- 是否存在 `90-System/system.yaml`
- 是否已经初始化 Git
- 是否存在未提交修改
- 是否存在同名目标目录
- 是否发现旧版第二大脑结构
## 阶段 2：确定模式
选择一种模式：
- `empty`：全新 Vault
- `existing-simple`：少量现有笔记
- `existing-structured`：已有明确目录结构
- `upgrade`：已安装旧版本
- `repair`：系统文件缺失或损坏
无法确定时停止修改，并列出需要人工确认的问题。
## 阶段 3：生成 Dry Run
输出表格：
| 操作 | 目标 | 原因 | 风险 | 可否回滚 |
|---|---|---|---|---|
同时列出：
- 将新增的文件
- 将修改的文件
- 明确保留不动的文件
- 可能发生的命名冲突
- 迁移建议
- 预计验证项目
未获得明确执行指令前，不修改文件。
## 阶段 4：建立恢复点
如果当前目录已使用 Git：
1. 读取 `git status`。
2. 说明已有未提交修改。
3. 不覆盖未提交内容。
4. 创建安装前提交、分支或独立 Worktree。
如果没有 Git：
1. 询问是否初始化 Git。
2. 若不初始化，在 `90-System/backups/<timestamp>/` 中备份本次将修改的文件。
3. 记录备份清单。
## 阶段 5：创建结构
按需创建：
- `00-Inbox`
- `10-Projects`
- `20-Notes`
- `30-Sources`
- `40-Outputs`
- `90-System/templates`
- `90-System/reports`
- `90-System/schemas`
- `90-System/backups`
- `.agents/skills`
不得创建重复目录。
## 阶段 6：安装或合并系统文件
创建或提出合并建议：
- `AGENTS.md`
- 根目录 `index.md`
- 五个核心目录的 `index.md`
- `90-System/system.yaml`
- 项目、笔记、来源和输出模板
- 日常工作 Skills
文件已存在时：
1. 比较差异。
2. 保留现有版本。
3. 生成合并建议。
4. 未经确认不得覆盖。
## 阶段 7：安装日常 Skills
安装并保持职责分离：
- `second-brain-organize`
- `second-brain-project`
- `second-brain-write`
- `second-brain-doctor`
## 阶段 8：验证
检查：
- 所有目标目录
- YAML 格式
- `AGENTS.md`
- 所有 `index.md`
- Skill frontmatter
- Git 或备份状态
- 重复文件与重复目录
- 失效内部链接
- 旧文件是否被意外修改
验证失败时：
1. 停止后续操作。
2. 输出失败原因。
3. 回滚本次新增或修改。
4. 保留诊断报告。
## 最终输出
1. 安装模式
2. 新增文件
3. 修改文件
4. 保留未动的文件
5. 需要人工确认的内容
6. 验证结果
7. 回滚方法
8. 第一次使用建议
</timestamp>
```
这个版本有意把“解释”和“执行”分开：文章说明为什么，SKILL.md 告诉 Agent 做什么、如何检查、失败时怎么办。
## 八、第一次运行：先看计划，再允许修改
将 Obsidian Vault 作为 Codex 项目打开，或在 Vault 根目录启动 Codex，然后输入：
```
$second-brain-bootstrap
请检查当前 Obsidian Vault，并为它搭建一个极简个人第二大脑。
要求：
1. 保留所有已有笔记；
2. 使用五入口结构；
3. 优先使用 Git 建立恢复点；
4. 先执行 dry run；
5. 不安装第三方 Obsidian 插件；
6. 不批量移动旧文件；
7. 创建 AGENTS.md、index.md、模板和四个日常 Skills；
8. 列出冲突、风险和验证项目；
9. 现在只给执行计划，不修改文件。
```
确认计划后再输入：
```
执行刚才的安装计划。
约束：
- 不覆盖已有文件；
- 遇到冲突时保留现有版本；
- 修改完成后显示变更摘要和 Git diff；
- 运行完整验证；
- 验证失败时回滚本次安装。
```
这里追求的不是“一次生成成功”，而是让整个过程可检查、可停止、可撤销。
## 九、安装后的 AGENTS.md
Bootstrap Skill 可以在 Vault 根目录创建或建议合并以下规则：
```
# 角色
你是这个 Obsidian Vault 的知识操作员。
你的目标不是生成更多笔记，而是帮助用户：
1. 整理输入；
2. 保留来源；
3. 提炼知识；
4. 建立可靠连接；
5. 推进真实项目；
6. 形成最终输出；
7. 保持所有修改可恢复。
# 默认读取顺序
1. 当前任务相关的 `index.md`
2. 相关项目简报
3. 相关知识笔记
4. 原始来源
除非任务确实需要，不扫描整个 Vault。
# 核心目录
- `00-Inbox`：尚未处理的信息
- `10-Projects`：有明确结果的项目
- `20-Notes`：已经形成的理解
- `30-Sources`：原始资料、引用和证据
- `40-Outputs`：文章、方案、课程、产品等最终产物
- `90-System`：配置、模板、报告、备份和版本信息
# 修改安全规则
- 默认先分析再修改。
- 修改超过 5 个文件前先输出计划。
- 不永久删除文件。
- 不覆盖已有文件。
- 不改写原始引文。
- 不伪造作者、日期、出处或链接。
- 批量修改前必须确认存在恢复点。
- 修改完成后必须输出变更摘要。
- 不确定的分类保留原位或进入 Inbox。
- 不读取 Vault 外文件，除非用户明确授权。
# 知识可靠性
输出结论时区分：
- 事实：来源直接支持
- 用户观点：用户明确表达
- 推断：根据现有资料推导
- 假设：尚未验证
- 未知：当前 Vault 无法回答
重要事实必须链接到来源笔记。
证据不足时明确写：
“当前 Vault 内容不足以支持这一结论。”
# 项目规则
每个活跃项目至少包含：
- 项目目标
- 完成标准
- 当前状态
- 下一步行动
- 关键资料
- 已做决策
- 当前风险
- 最终产物
资料收集不等于项目推进。
每次项目复盘必须给出一个可以交付的下一步。
# 完成任务后的输出
1. 修改了什么
2. 为什么修改
3. 哪些内容不确定
4. 哪些内容需要人工检查
5. 如何撤销本次修改
```
## 十、日常只保留四个 Skill
Bootstrap 完成后，用户不必围绕目录工作，而是围绕任务工作。
1. 整理 Inbox
```
$second-brain-organize
检查最近 7 天进入 00-Inbox 的内容。
要求：
- 最多处理 10 篇；
- 先识别重复和低价值内容；
- 给出建议位置、关联项目、理由和可信度；
- 只输出处理建议，不移动或删除文件。
```
推荐输出：
文件、建议处理、目标位置、关联项目、理由、可信度
2. 推进项目
```
$second-brain-project
复盘所有 active 项目。
请给出：
1. 当前最值得推进的项目；
2. 选择理由；
3. 最大阻塞；
4. 已有资料；
5. 60 分钟内可以完成的最小交付物；
6. 完成交付物后应更新哪些文件。
```
3. 基于证据写作
```
$second-brain-write
我要写一篇《为什么多数第二大脑最后会变成信息坟场》。
只能使用当前 Vault 中已有资料。
先生成证据矩阵：
| 核心观点 | 支持来源 | 反对或限制证据 | 可信度 | 缺失信息 |
暂时不要写正文。
```
4. 系统健康检查
```
$second-brain-doctor
检查当前 Vault 的健康状态。
重点检查：
- 无来源的关键结论
- 超过 30 天未更新的活跃项目
- 重复或近似重复笔记
- 失效内部链接
- 没有下一步行动的项目
- 与实际内容不一致的 index.md
- 系统版本和模板差异
只生成报告和修复优先级，不直接修改。
```
## 十一、安全机制要放进系统设计里
1. 同步不等于备份
Obsidian 官方明确指出，同步服务用于让多个设备保持一致，并不能替代独立备份。
更稳妥的保护结构是：
```
同步
+
Git 版本记录
+
独立备份
```
不要同时使用多个同步方案修改同一个 Vault，以免产生冲突；独立备份应当是单向、可恢复的副本。
2. 为 AI 修改设置权限边界
推荐默认规则：
```
读取：允许访问当前 Vault
单文件修改：可执行，但必须说明
批量修改：先给计划
删除：禁止永久删除
外部访问：默认禁止
自动化：先手动测试
```
使用 codex exec 编排脚本时，默认运行在只读沙箱；需要写入时再显式授予工作区写权限，并坚持最小权限原则。
```
codex exec --sandbox workspace-write \
"检查 00-Inbox，生成整理建议，不移动文件"
```
3. Git 只负责版本控制，不替代独立备份
基础初始化：
```
git init
git add .
git commit -m "Initialize Obsidian second brain"
```
推荐忽略频繁变化的工作区文件：
```
.obsidian/workspace.json
.obsidian/workspaces.json
.trash/
.DS_Store
```
高风险修改前：
```
git switch -c codex/second-brain-update
```
检查并提交：
```
git diff
git add .
git commit -m "Update second brain workflow"
```
## 十二、自动化最后再加
一个流程被手动运行多次、输出稳定、失败边界清晰后，再考虑定时执行。
Codex 官方建议在创建 Automation 前，先在普通线程中测试提示词，并检查范围、工具和 diff 是否符合预期。
项目级 Automation 运行时，本机需要开机、Codex App 需要运行，项目目录也必须可访问；Git 项目可以选择在独立 Worktree 中运行，以避免干扰正在编辑的主目录。
可以先从三个“只报告、不修改”的任务开始。
每日 Inbox 检查
```
检查最近 24 小时进入 00-Inbox 的笔记。
调用 $second-brain-organize。
只输出整理建议。
没有新内容时不生成报告。
```
每周项目复盘
```
检查所有 active 项目：
- 是否有明确下一步
- 是否连续 7 天没有推进
- 是否只收集资料而没有交付物
- 是否存在未处理决策
- 是否应该暂停或归档
将报告保存到 90-System/reports。
不直接修改项目状态。
```
每月系统巡检
```
调用 $second-brain-doctor，检查：
- 重复笔记
- 失效链接
- 无来源结论
- 过期索引
- 停滞项目
- 系统版本
- 未被使用的属性
只生成修复计划。
```
## 十三、如何判断这个 Skill 真的可用
创建出目录，只是第一步。一个可用的系统，至少要通过三类测试。
正常场景
输入：
```
一个全新的 Obsidian Vault
```
验收：
- 五入口结构正确；
- AGENTS.md 和索引可读取；
- Skills 可以被发现；
- 模板 YAML 有效；
- 存在恢复点；
- 第一次 Inbox 整理可运行。
边缘场景
输入：
```
一个已经存在 PARA、CLAUDE.md、模板和大量旧笔记的 Vault
```
验收：
- 不覆盖原文件；
- 不创建重复目录；
- 能识别旧结构；
- 只生成迁移建议；
- 冲突内容要求人工确认。
压力场景
输入：
```
一个包含大量 Markdown、同名笔记、失效链接和未提交 Git 修改的 Vault
```
验收：
- 不盲目批量移动；
- 能中止高风险操作；
- 能建立恢复点；
- 能分批处理；
- 验证失败后可以回滚。
## 十四、7 天落地路线
第一周先别追求这些东西：
```
漂亮的知识图谱
复杂 Dashboard
几十种对象类型
全自动旧笔记迁移
跨平台多 Agent
```
先验证一个闭环：
```
捕获
→ 整理
→ 提炼
→ 推进项目
→ 形成输出
→ 复盘
```
## 十五、不要用笔记数量衡量第二大脑
一个有效的系统，可以用结果来衡量。
推荐关注六个指标：
如果笔记越来越多，而这些指标没有改善，系统可能只是在更高效地制造信息坟场。
## 结语：把信息架构变成系统能力
一键 Skill 没有让目录、规则和流程消失。它只是把复杂度从用户的日常维护里移出来，交给一套可检查、可回滚、可升级的流程。
Obsidian 负责保存长期记忆；
AGENTS.md 负责保存长期规则；
index.md 负责压缩和导航上下文；
Properties 与内部链接负责表达知识关系；
Skills 负责执行稳定流程；
Automations 负责定期巡检；
Git、Worktrees 和独立备份负责控制风险。
项目和最终输出，负责证明这个第二大脑是否真的有价值。
最后，好的第二大脑不该让你每天围着系统打转。
它应该在你工作时，持续帮你整理、判断、行动和交付。
## 相关链接
- [知识猫图解](https://x.com/GeekCatX)
- [@GeekCatX](https://x.com/GeekCatX)
- [17K](https://x.com/GeekCatX/status/2069024555197497479/analytics)
- [$HOME](https://x.com/search?q=%24HOME&src=cashtag_click)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [7:47 PM · Jun 22, 2026](https://x.com/GeekCatX/status/2069024555197497479)
- [17.4K Views](https://x.com/GeekCatX/status/2069024555197497479/analytics)
---
*导出时间: 2026/7/2 16:55:08*