second-brain

/second-brain — Karpathy LLM Wiki 工作流

将现有的 Obsidian Second Brain（或任何基于 Markdown 的知识库）封装起来。Wiki 知识库的架构文档（CLAUDE.md 或 AGENTS.md）是权威架构；此技能负责协调用户一直在手动执行的操作。

心智模型

三层，各自职责明确：

raw/      →  wiki/         →  outputs/
sources      compiled         generated
                              artifacts

• raw/ — 尚未处理的源材料。文章、摘录、想法、随手记录、推文。以类型为前缀（article-、idea-、highlights-、braindump-、note-、resource-、tweet-）。绝不删除——这是事实来源。
• wiki/ — AI 编纂的主题页面。每个概念对应一个页面，而不是每个来源对应一个页面。通过 [[wikilinks]] 互相链接。根目录下有 INDEX.md。
• outputs/ — 根据查询生成的产物：研究摘要、分析、幻灯片。使用描述性名称。

Wiki 操作期间不要改动以下文件夹和文件：Projects/、Daily/、Templates/、Inbox/、Notes/、Tasks.md、Kanban.md、Home.md。

第 1 步 — 加载知识库配置和架构

1. 阅读 references/vault-config.md，获取知识库路径（默认值：${SECOND_BRAIN_VAULT:-$HOME/Documents/SecondBrain}/）
2. 阅读知识库的架构文档——<vault>/CLAUDE.md 或 <vault>/AGENTS.md，存在什么就读什么（如果两者都存在，则都读取）——了解权威架构。如果存在，应以它为准，而非 references/schema.md——用户的知识库才是事实来源。
3. 如果两者都不存在，则使用 references/schema.md。

第 2 步 — 解析模式

调用方式	模式
/sb capture / /second-brain capture / "capture this" / "save this to my brain"	capture
/sb compile / "compile the wiki" / "process raw notes"	compile
/sb query <question> / "ask my brain X" / "what does my brain say about Y"	query
/sb lint / "lint the wiki" / "health check my brain"	lint
/sb connect / "find connections" / "suggest wikilinks"	connect
/sb search <term> / "search my notes for X"	search

第 3 步 — 执行模式

capture

输入：URL、粘贴的文本、文件路径或屏幕截图。

1. 根据内容判断类型：
   • URL → article-
   • 带有引用摘录的粘贴文本 → highlights-
   • 用户自己的想法 / 头脑风暴内容 → braindump- 或 idea-
   • 单条推文 / X 帖子 → tweet-
   • PDF、视频、播客 → resource-
   • 快速参考内容（食谱、命令、事实）→ note-
   • 如果无法判断，请询问。
2. 生成描述性文件名：<type>-<kebab-case-topic>.md（例如，article-andrew-wilkinson-tiny-manual.md）。使用来源标题或主题，而不是 URL 路径片段。
3. 在顶部添加元数据：

   source: <URL if applicable>
   captured: YYYY-MM-DD
   

4. 保存到 <vault>/raw/。
5. 如果来源是 URL，则获取文章内容（使用 Agent 的 URL 抓取功能，或对需要身份验证的页面使用 agent-browser），并保存可读文本，而不只是 URL。
6. 报告路径以及一行保存内容摘要。

不要在此处将内容编纂到 Wiki 中——capture 用于快速收集。编纂是单独进行的、有意为之的处理流程。

compile

成本高但很有价值的操作。将未处理的原始文件整理成维基页面。

1. 查找未处理的原始文件：在 wiki/*.md 中搜索 Sources 章节；未列出的原始文件即为未处理文件。
2. 阅读每个未处理的原始文件以及现有的 wiki/INDEX.md。
3. 针对每个原始文件：
   • 提取关键概念、事实和见解
   • 默认：如果主题有重叠，就合并到现有维基页面中。 只有当概念无处可归时，才创建新页面。
   • 每个概念对应一个页面，而不是每个来源对应一个页面。
   • 对每个相关概念使用 [[wikilinks]]
   • 在维基页面的 ## Sources 章节中添加原始文件，并用一行说明提取了哪些内容
4. 更新 wiki/INDEX.md：
   • 将新页面添加到对应分类下（Creative / Health & Longevity / Faith & Personal Growth / Business / Personal Growth / Tech / Hobbies / Sci-Fi / Pets——或按需新建分类）
   • 每个条目占一行：- [[Page Name]] — brief description
5. 每个维基页面都必须有 Connections 章节。 如果新页面没有任何关联，请先找到一个再保存。
6. 质量重于数量。 如果页面不足 100 个单词，暂时保留原始文件，并询问用户是否应将内容合并到相邻页面中。

输出：列出新建/更新的页面、内容合并到了哪里，以及为澄清而暂留的任何内容。

query

仅使用维基/原始文件语料回答问题。与 deep-research 不同（后者会检索外部信息）。

1. 阅读 wiki/INDEX.md，找出可能相关的页面
2. 阅读这些页面，并沿 [[wikilinks]] 遍历 1–2 层
3. 撰写答案：
   • 按页面名称引用维基页面：“根据 [[Microplastics Detox]]……”
   • 如果维基内容自相矛盾，请指出双方观点
   • 如果维基中没有答案，请说明这一点，并提出运行 /deep-research 来扩展内容
4. 将答案保存到 outputs/<YYYY-MM-DD>-<question-slug>.md，其中包含：
   • 原始问题
   • 答案
   • 查阅的维基页面列表
5. 在聊天中展示答案，并提供已保存输出的路径
6. 可选渲染：如果传入了 --render pdf 或 --render html，请使用共享样式表通过 pandoc 处理输出。命令参见 references/schema.md → “Publishing alternatives”。

lint

对维基进行健康检查。

检查：

1. 孤立页面——未收录在 INDEX.md 中的 wiki/*.md
2. 连接孤立页面——没有指向其他页面的 [[wikilinks]] 的页面
3. 未处理的原始文件——未列在任何维基页面 Sources 下的原始文件
4. 过时页面——最新来源已超过 6 个月，且主题具有时效性（AI、营销、金融、健康方案）
5. 主题缺口——在 3 个或更多页面中提及、但没有专属页面的概念
6. 矛盾——维基页面提出相互对立的观点，却未标注矛盾
7. 缺少关联——主题明显相关、却没有 [[wikilink]] 相连的页面（建议运行 /sb connect）

输出：按优先级排列的列表，最重要的排在前面（结构损坏比内容过时更严重）。

connect

查找应当相互链接、但目前没有链接的页面。

1. 根据 INDEX.md 和页面摘要构建主题图谱
2. 为每个页面找出 2–5 个主题重叠的其他页面
3. 检查每个候选页面是否已建立链接
4. 建议补充缺失的链接；如果用户批准，则编辑页面，将链接添加到各自的 ## Connections 章节中

search

在 wiki/ + raw/ 中快速搜索某个词。返回匹配文件，并附上匹配内容前后各 2 行的摘录。用户知道要找哪个页面时，这比 query 更快。

多写入者 Git 同步（远程 Agent）

当知识库由 Git 管理并连接到托管的远程仓库（GitHub/GitLab）时，远程仓库就成了无法访问文件系统的 Agent 的内容捕获 API——例如云端 Agent、定时任务和其他机器。任何能够访问 Git 托管平台 API 的 Agent（直接访问，或通过 Executor 这样的 MCP 集成层），都可以读取知识库，并通过向默认分支提交内容，将内容捕获到 raw/。

以下规范可以避免写入者各自为政：

1. 本地会话写入前先拉取：开始任何知识库工作时，先运行 git pull --rebase --autostash，提交后再推送。切勿假设本地内容是最新的——远程 Agent 可能已在上次会话后提交内容。
2. Obsidian 用户：安装社区插件 Git，设置定时自动拉取（约每 10 分钟一次）并在启动时拉取，但关闭自动提交和自动推送——提交由会话和 Agent 负责，这样提交历史更有意义，不会充斥着“知识库备份”之类的杂乱记录。
3. 远程 Agent 尽量只追加提交：在 raw/ 中创建新文件，并使用描述性提交消息。向不同文件追加内容不易产生冲突；即使写入交错，rebase 也能轻松处理。

设置时，请端到端验证一次整个流程：通过 API 远程提交 → 本地拉取 → 文件出现在知识库中。

配合使用

• deep-research — 当 query 发现知识库中存在空白时，将任务交给 deep-research，从外部来源补充内容。deep-research 的输出可以捕获回 raw/，供日后编纂。
• paste — 将内容整洁地捕获到 raw/（尤其适用于终端/CLI 捕获）。
• business-brainstorm — 在头脑风暴前，检查 Portfolio of Businesses 和 Entrepreneurship & Startups 知识库页面，获取相关背景。
• decide — 在评估 Q34（“我们正在违背哪些原则”）时，从 Personal Philosophy / Productivity & Systems 知识库中获取原则。新增：Decision Log 知识库页面会逐步记录决策叙事；decide 归档保存结构化内容，该知识库页面则记录故事。
• jab-hook — Content Ideas 知识库页面汇集了跳转点、框架和故事。/jab-hook 会从中起草可选内容。
• slide-deck — 在 outputs/ 中起草的内容可作为演示文稿来源；演讲者备注可以引用相关知识库页面。
• pm — 知识库中的 Projects/ 文件夹不允许 second-brain 使用，由 pm 负责。但 Workflow Docs 知识库页面会记录多个项目中反复出现的运营模式。

同类实现（参考）

另外两个系统也采用 raw → wiki → outputs 模式，值得关注，可作为升级方向。

• Hermes 的 llm-wiki skill — 开箱即用的三文件夹模式实现。内置 compile / query / lint 工作流，可用于比较架构设计。
• Gbrain，由 Garry Tan 开发 — 功能复杂得多。它将大脑视为数据库（Postgres 或 PGLite），具备综合、图遍历、空白分析、定时 cron 维护和 MCP 集成能力。它支持一个拥有 146K 个页面和 24K 个人物实体的部署。如果用户的知识库超出纯 Markdown 模式的承载能力，Gbrain 是可考虑的升级方向。即使不迁移，也值得借鉴以下做法：将人物作为实体（使用 person- raw 类型和 People 知识库页面）以及定时维护（通过 loop 或 compound-engineering:schedule skill，将 compile 和 lint 配置为定期运行）。

质量说明

• 质量胜过数量。 少量彼此联系紧密的 Wiki 页面，胜过大量内容单薄的页面。如果编译后会形成单薄的页面，就先保留原始文件，以待澄清。
• 不要抹平细微差异。 如果两个原始来源相互矛盾，Wiki 页面应注明分歧，而不是默默地选边站。
• “关联”部分为必需项——每个 Wiki 页面都必须至少链接到另一个页面。
• 编译后绝不要删除原始文件。它们是事实依据。
• 在第二大脑操作期间，绝不要修改 Projects/、Daily/、Templates/、Notes/、Tasks.md、Kanban.md、Home.md 或 Inbox/ 中的文件。这些文件属于其他工作流。