我搭建了自己的 Obsidian。然后加入了 Kimi Work
把它变成了第二大脑。
以下是我的发现
太长不看;如果你不想读 3000 字的长文,直接把这个给你的 AI 助手
Familiar 使用时的直观感受
引言
问题是,大多数尝试构建第二大脑的开发者,最终得到的只是一个第二文件柜。
有些人搭建了 Obsidian,因为在 YouTube 演示里,它的图谱视图看起来太酷了。
有些人尝试将 Claude Code 接入自己的知识库,却永远卡在初始设置的摩擦上。
还有些人直接跳进了 RAG 流程和向量数据库的坑,却没有理解真正的问题在于「捕捉」,而非「检索」。
结果总是一样的:一个漂亮的、躺着 12 条笔记的知识库,一个坏掉的定时任务,以及一堆废弃的插件。
如果你的目标是建立一个真正能产生复利的知识系统,你不需要 RAG。你不需要向量数据库。你不需要云订阅。
你需要学习的是:
- 如何构建一个知识库结构,让任何 AI 助手都能无需额外指令就自由导航
- 编写技能文件,让可重复的工作流按计划自动运行
- 利用 KIMI Work 的 AI 助手,在你睡觉时自动将研究资料拉取到知识库中
- 将你的知识库连接为 MCP 服务器,让你使用的每个 AI 助手都读取同一个大脑
- 构建一个每日桌面页面,每天早晨呈现最重要的内容
这篇文章是完整的构建指南。包含了每一个技能文件。每一条 cron 表达式都是精确的。每一个架构决策背后都有其原因。
我的知识库目前有 347 条笔记。一个 50 文件的收件箱批处理任务,使用 KIMI Work 的 Agent Swarm 只需不到 4 分钟。这个系统已经运行了 11 周。
现在,让我们开始构建。
这就是我在 Kimi Work 中使用的具体配置,它是一个免费的桌面端工具,可以替代 Claude Code
在理论之前,先看看它实际能做什么
一条原始笔记被丢进 inbox/ 目录:
1---2source: https://arxiv.org/abs/2506.042913captured: 2026-06-114---5关于 MoE 模型在超过 200k tokens 后长上下文性能下降的新论文。6注意力坍塌问题在 256k 时加剧。可能的修复方法:带动态步长的滑动窗口注意力。7作者声称可减少 40% 的性能下降。
KIMI Work 的 AI 助手写回 notes/wiki/ 的内容:
1---2title: MoE 模型中的长上下文性能下降3last_updated_by: agent4confidence: medium5linked_sources:6 - resources/arxiv-2506.04291.pdf7related: [[混合专家架构]], [[注意力机制]], [[Kimi K2.6]]8---910## 提出的修复方案11带动态步长的滑动窗口注意力。声称减少 40% 的性能下降。1213## 与现有笔记的冲突14> [冲突] — [[Kimi K2.6]] 的 wiki 页面指出 K2.6 在 256K 上下文下表现良好。15> 需要人工复核。1617## 待解决的问题18- 40% 的数据是基于困惑度还是下游任务基准?19- 动态步长是否会增加推理成本?
AI 助手创建了一个结构化的 wiki 页面,将其链接到你现有的知识图谱中,并揭示了一个你从未注意到的矛盾。你丢进一条杂乱的笔记。你收获结构化的思考。
这就是循环。下面的内容解释了这一切是如何运作的。
为什么我要构建 Familiar
Claude Code + Obsidian 的组合在 2026 年 4 月初爆火。一周内获得超过 5 万个赞。想法很简单:让一个 AI 助手指向一个 Markdown 知识库,被动的笔记存储就变成了主动的基础设施。
但它有上限。
- Claude Code 需要你在场。你调用它,它运行,你得到输出。它不会在你睡觉时的早上 7 点自动运行。
- 它不会按计划从网络上拉取研究资料。它无法协调 300 个并行子助手来批处理你的文档积压。
我想要一个知识库,任何 AI 助手都能从中读取、写入,并能按计划维护。本地优先。繁重工作自动化。我把它叫做 Familiar。

知识库架构
所有内容都以纯文本 .md 文件的形式存放在磁盘上。没有专有数据库。没有云同步。
Markdown 是唯一一种每个 AI 助手都能无摩擦读取和写入的格式。
1familiar/2├── notes/3│ ├── wiki/ <- 常青概念(更新,从不删除)4│ ├── journal/ <- 每日记录(不可变,AI 助手只读从不写入)5│ ├── projects/ <- 当前工作简报6│ └── crm/ <- 人、组织、关系7├── inbox/ <- 原始捕捉(AI 助手处理并归档)8├── resources/ <- 原始资料(不可变,只读)9├── skills/ <- KIMI Work 技能文件10└── AGENTS.md <- 工作区行为规则11└── index.md <- AI 助手导航地图
我是如何在 Kimi 中触发 Familiar 的
resources/ 文件夹永远不会被修改。原始资料只被摄入。
这防止了破坏大多数 AI 知识库的失败模式:
- wiki 内容引用其他 wiki 内容
- 原始来源随着每次生成而越来越偏离
- 知识库自信地相信它在第二周虚构出来的东西
AGENTS.md 是仓库中最重要的文件。
每个 AI 助手都会首先读取它。Claude Code、KIMI Work 的 AI 助手、Cursor,任何遵循此约定的工具。一个文件,可移植到整个技术栈:
1# Familiar 工作区规则23## 知识库地图4- /notes/wiki/ -> 常青概念。在创建新笔记前先检查更新。5- /notes/journal/ -> 只读。不要创建或修改过去的条目。6- /notes/projects/-> 当前工作。项目关闭时归档。7- /inbox/ -> 原始捕捉。处理后归档。不要留下未处理的内容。8- /resources/ -> 原始资料。不要修改。910## 行为规则111. 创建笔记前,检查是否应该更新现有页面。122. 每个 wiki 页面必须引用至少一个来自 /resources/ 或 /inbox/ 的来源。133. 始终添加 [[反向链接]] 到相关概念。144. 永不删除。将过时内容标记为 [过时],移动到 /notes/archive/。155. 当来源与现有 wiki 页面冲突时,添加 [冲突] 块。166. 每次会话后,用新增内容更新 index.md。177. 不要包含原始资料中没有的内容。不要合成声明。
第七条是最重要的。没有它,AI 助手会用听起来很合理但与你真实思考一模一样的信息来填补知识空白。你的知识库开始生成自信的虚构内容。
构建它:真正重要的决策
第一步:什么都别做,先搞版本控制
在任何 AI 助手挂载知识库之前,先运行这个:
1cd familiar/notes2git init3git remote add origin [email protected]:yourusername/familiar-notes-private.git4git add -A && git commit -m "init: vault scaffold"5git push -u origin main
- 早期我跳过了这一步。一次收件箱处理任务有一个含糊的指令:“在适当的地方合并相关概念。”
- AI 助手认为我关于 [[推理模型]] 和 [[思维模型]] 的独立笔记是同一个概念并合并了它们,丢弃了 800 字花了三周时间写的细微区别。一条 git revert 命令就搞定了。教训深刻。
第二步:分层记忆,或者为什么扁平知识库会变成噪音
一个扁平的知识库几周内就会崩溃。AI 助手会积累两个月前已关闭项目的假设,并从不再反映你实际优先级的上下文中进行综合。
层级
位置
节奏
存放内容
热
/notes/journal/
每次会话
今天的运行上下文
温
/notes/projects/
每周
状态、决策、优先级
冷
/notes/wiki/
当根本性变化时
永久知识
AI 助手会根据不同的问题类型读取正确的层级。过时的温层项目笔记永远不会污染冷层的综合。
第三步:YAML 前置元数据约定
每个 wiki 页面都包含 AI 助手写入和维护的元数据:
1---2title: 混合专家架构3last_updated_by: agent4confidence: high5linked_sources:6 - resources/moe-survey.pdf7---
last_updated_by 字段是你如何在每周 lint 检查中审计知识库的方法:
- 筛选
last_updated_by: agent且confidence: low的内容 - 手动阅读每个页面
- 修正、提升置信度或删除
每周二十分钟,保持系统清洁。
第四步:收件箱优先的捕捉循环
大多数笔记工具中最大的摩擦在于“我发现了有趣的东西”到“它已进入我的系统、链接好并可用”之间的差距。Familiar 的收件箱模式消除了这个差距:
- 任何未处理的内容都作为原始 Markdown 文件进入
/inbox/(网页捕捉、语音备忘录、粘贴或 PDF 拖放) - AI 助手按计划触发读取收件箱
- 对于每个文件:分类、分配到正确的知识库位置、提取关键概念、生成指向现有 wiki 页面的 [[反向链接]]、将原始文件归档到
/inbox/archive/ - 用新增内容更新
index.md
源文件保持不可变。AI 助手会创建一个对应的 wiki 页面,但原始来源始终可追溯。
Familiar 内部:图谱、快速捕捉及所有功能
知识库骨架是基础。那些让它感觉像一个真正的第二大脑(而不是一个 Markdown 文件文件夹)的功能,是在其上构建的层级。
图谱视图
Familiar 直接继承了 Obsidian 的 [[wikilinks]] 约定。AI 助手创建的每个反向链接都成为一个双向边。随着时间的推移,图谱反映了你思维的实际形状:哪些概念聚集在一起、哪些被大量链接、哪些孤立笔记从未与任何内容连接。
与普通 Obsidian 的区别:链接是由 AI 助手创建的,而不是由你手动创建。你写一条原始笔记,AI 助手处理它,图谱随之增长。11 周和 347 条笔记之后,形成的集群并非我刚开始时能预料的。这正是重点所在。
如何解读图谱:
- 密集的集群 是你持续在思考的主题
- 高度链接的单个节点 是所有其他内容都引用的锚点概念
- 孤立节点 是更有用的信号:你思考过但从未整合的内容
- confidence: low 的节点 是 AI 助手生成的页面,仍需要人工过一遍
Cmd+Shift+K:从桌面任何位置即时捕捉
这是改变我每天使用整个系统的功能。
KIMI Work 的 AI 助手有一个全局快捷键栏。在 Mac 上任何位置按下 Cmd+Shift+K,就会出现一个命令栏。你不需要切换窗口。你不需要打开 Familiar。你不需要碰终端。
你输入一个想法、一个问题或一个半成型的构思,然后告诉它放到哪里:
1保存到 familiar inbox: 滑动窗口注意力可能是解决2昨天看到的那个长上下文性能下降问题的办法
- KIMI Work 的 AI 助手获取输入,将其格式化为带有时间戳和来源标签的结构化 Markdown 笔记,并直接放入
~/familiar/inbox/。 - 下一次收件箱处理定时任务在早上 8 点触发时,它会被分类、链接到你现有的 wiki 页面,并像其他捕捉内容一样被归档。
- 从有一个想法到该想法进入你的系统,摩擦下降到大约四秒。
你也可以用这个栏即时查询知识库:
1ask kimi: 关于推理优化我写过什么?
KIMI Work 的 AI 助手通过本地文件挂载读取你的知识库,从你实际的笔记中回答,你可以告诉它将答案追加为一条新笔记或直接打开源文件。
我每天都使用的快速栏模式:
save to inbox: 会议中捕捉想法,无需切换上下文add to crm/[person]: 关于某人的一些需要记住的事,即时添加open project/[name]: 直接跳转到项目简报flag conflict in wiki/[topic]: 手动添加 [冲突] 块,无需打开文件
这个栏是模态的且原生键盘操作。对于任何生活在终端里的人来说,它感觉像是恰到好处的抽象。
功能:图谱健康检查技能
图谱健康检查技能是一个正在积极开发中的开放问题。它按周计划运行,并将完整的审计报告写回知识库:
1# 图谱健康检查技能23## 任务4扫描 ~/familiar/notes/wiki/ 并生成健康报告。56## 检查项71. 孤立页面(没有来自任何其他笔记的反向链接)82. 置信度为 low 且超过 14 天未复核的页面93. 超过 7 天未解决的 [冲突] 块104. 仍位于活动文件夹中的 [过时] 标记页面115. /wiki/ 中前置元数据没有 linked_sources 的页面1213## 输出14写入 ~/familiar/notes/journal/graph-health-{YYYY-MM-DD}.md1516## 格式17### 孤立页面(找到 X 个)18### 低置信度、未复核(找到 X 个)19### 未解决冲突(找到 X 个)20### 过时页面(找到 X 个)21### 无来源页面(找到 X 个)
与每周 lint 检查一起运行。健康报告会精确告诉你知识库在哪些地方发生偏移,以及在下次处理运行之前需要人工做出哪些决策。这是将静态图谱视图转变为主动维护循环的功能。
功能:语音备忘录摄入
通过本地 Whisper 实例的语音备忘录摄入是另一个正在积极开发中的开放问题。预期的流程:
- 将 .m4a 或 .mp3 文件放入 /inbox/voice/
- KIMI Work 的 AI 助手通过本地 Whisper 转录
- 转录内容被清理并保存为 /inbox/ 中的标准 Markdown 文件
- 收件箱处理技能会在下一个
0 8 * * *运行时将其拾取
这关闭了最后一个手动捕捉的缺口。目前,要在远离键盘的情况下将想法输入知识库,唯一的方法是录语音备忘录,然后稍后手动粘贴。Whisper 技能完全消除了这一步。结合 Cmd+Shift+K,所有捕捉场景都被覆盖了。
功能:WebBridge 阅读列表捕捉
目前正在开发中,作为一个开放问题。WebBridge 不是手动维护一个阅读列表文件,而是监控一个书签文件夹或共享 URL 列表,在早晨定时任务时自动爬取新增内容,并将完整的提取文本放入 /inbox/。阅读列表变成了一个队列。AI 助手每天早上清空它。
功能:MCP 服务器暴露
- 也是一个开放问题。一旦上线,完整的 Familiar 知识库将成为一个 MCP 服务器。任何兼容 MCP 的 AI 助手(Claude Code、Cursor、Windsurf、Hermes)都可以直接查询它,无需单独设置。
- 你配置一次。每个 AI 助手都读取同一个大脑。这是将 Familiar 从个人工具转变为基础设施的功能。
功能:Wiki 模板库
一套针对最常见笔记类型的预构建 YAML 前置元数据模板:
- 人物模板:姓名、组织、关系、最后联系时间、关联项目
- 概念模板:定义、相关概念、来源、置信度
- 项目模板:状态、负责人、截止日期、关联人员、关联概念
- 论文模板:标题、作者、发布日期、关键声明、关联 wiki 页面
AI 助手创建的每个新页面都将从正确的模板开始,而不是一个空白文件。一致的结构意味着从第一天起就有一致的图谱质量。
今天仓库中已经提供的内容
- 包含 AGENTS.md 模板和 index.md 导航地图的知识库骨架
- 分层记忆结构(journal / projects / wiki / crm)
- YAML 前置元数据约定(confidence, last_updated_by, linked_sources)
- 带有源完整性规则的不可变 resources 文件夹
- 全部三个定时任务技能文件(早晨捕捉、收件箱处理、每周回顾)
- 生成每日 HTML 简报的桌面页面技能
- 兼容 Git 的纯文件结构,无二进制格式
KIMI Work 不是聊天机器人。它是一个桌面端 AI 助手。
有一段时间,我在我的 Mac mini 上自托管 Kimi K2.6。通过 Ollama 拉取权重,完全离线运行,将我的知识库指向它。
零云。零 API 成本。它查询笔记时工作得很好,但仍然需要我每次想处理某些事情时手动调用它。
KIMI Work 改变了这一点。它是月之暗面在 K2.6 基础上构建的桌面应用程序,于 2026 年 6 月推出。
- 与我之前运行的模型相同。但现在它可以挂载我的本地文件夹、驱动我的浏览器、在后台执行 Shell 脚本,并且可以在无需我打开终端的情况下按 cron 计划运行。
- 自托管模型与运行 KIMI Work 之间的区别,是拥有一个工具与拥有一个系统之间的区别。
对这个构建来说重要的数字:
- 256K token 上下文窗口:整个项目文件夹都能放进工作记忆
- Agent Swarm:最多 300 个并行子助手,4000 个协调步骤,在大型并行任务上比单助手快 4.5 倍
- 修改版 MIT 许可下的开放权重:如果你希望完全离线,仍然可以通过 Ollama、vLLM 或 SGLang 自托管
- 原生多模态输入:文本、图片和视频
五大能力
- 本地文件助手
- WebBridge
- 定时调度器
- Agent Swarm
- 办公输出
技能:KIMI Work 的 AI 助手如何实际运行你的知识库
KIMI Work 使用技能系统。一个技能文件定义了一个工作流。定时任务是计划。技能文件是剧本。你编辑技能文件。定时任务保持不变。
今天 Familiar 运行三个技能。
技能 1:早晨捕捉 (0 7 * * *)
1# 早晨捕捉技能23## 任务4使用 WebBridge 访问 ~/familiar/inbox/reading-list.md 中的每个 URL。5对于每个 URL:61. 提取完整的文章文本72. 保存为 Markdown 到 ~/familiar/inbox/YYYY-MM-DD-{slug}.md83. 添加 YAML 前置元数据:source, captured date, word count910## 规则11- 如果 URL 返回 404 或付费墙拦截,则写入一个带有 [失败] 标签的存根12- 不要总结。保留完整文本。13- 不要修改 reading-list.md
技能 2:收件箱处理 (0 8 * * *)
1# 收件箱处理技能23## 任务4处理 ~/familiar/inbox/ 中所有未归档的文件。5对于每个文件:61. 按主题分类72. 检查 ~/familiar/notes/wiki/ 中是否有关于该主题的现有页面8 - 如果存在:更新该页面,在带日期的标题下添加新信息9 - 如果不存在:使用 ~/familiar/templates/wiki.md 创建新的 wiki 页面103. 添加至少 2 个相关 wiki 页面的 [[反向链接]]114. 检查与现有 wiki 内容的冲突。如果发现,添加 [冲突] 块。125. 将源文件移动到 ~/familiar/inbox/archive/YYYY-MM/1314## 处理之后15更新 ~/familiar/index.md,为每个新的或更新的页面添加一行条目。1617## 硬性规则18- 不要合成源文件中不存在的声明19- 不要修改 ~/familiar/resources/ 中的文件20- 不要触碰 ~/familiar/notes/journal/
技能 3:每周回顾 (0 18 * * 5)
1# 每周回顾技能23## 任务41. 读取 ~/familiar/notes/journal/ 中过去 7 天的所有日记条目52. 识别:前 3 个主题、前 5 个被记录但未采取行动的洞察、待解决的问题63. 扫描 ~/familiar/notes/projects/ 中上次更新超过 7 天的项目74. 将输出写入 ~/familiar/notes/journal/weekly-review-{YYYY-MM-DD}.md89## 输出格式10### 本周关键主题11### 尚未采取行动的洞察12### 待解决的问题13### 需要关注的项目14</code-selection>1516**Cron 参考:**1718<code-segment id="seg_12" lang="markdown">190 7 * * * <- 每天早上 7:00 (早晨捕捉)200 8 * * * <- 每天早上 8:00 (收件箱处理)210 18 * * 5 <- 每周五下午 6:00 (每周回顾)
通过 MCP 连接一切
KIMI Code CLI 支持 MCP。你可以将你的 Familiar 知识库暴露为 MCP 服务器,使其可从 Claude Code、Cursor 以及任何支持该协议的 AI 助手查询。一个知识库。所有 AI 助手。
步骤 1:启动 notes-mcp 服务器
1export OBSIDIAN_VAULT_PATH="/path/to/familiar/notes"2deno task start
步骤 2:在 KIMI Code CLI 中注册
1kimi mcp add --transport stdio familiar-vault -- deno run \2 --allow-read=$OBSIDIAN_VAULT_PATH \3 /path/to/notes-mcp/src/server.ts
步骤 3:验证连接
1kimi mcp list2# familiar-vault stdio tools: search_notes, read_notes
步骤 4:从任何 AI 助手会话查询你的知识库
1> 过去 90 天里,关于推理优化我写过什么?
AI 助手调用 search_notes,读取相关的 wiki 页面,并从你实际的思考中(而非其训练数据)给出答案。知识库变成了你技术栈中所有工具共享的基础设施。
真正产生复利的东西
这是那些 60 秒演示视频永远不会展示的。
第 1 周
- 40 条笔记
- AI 助手从你的第一批收件箱批次中创建结构
- 有用,但不神奇
第 4 周
- 120 条笔记
- AI 助手对你的思考有了真正的上下文
- 当它处理一篇新论文时,会交叉引用四个现有 wiki 页面,发现三周前的一个矛盾,并标记出来
- 你从输出中了解到自己的一些信念
第 3 个月
- 340 条笔记,数百个交叉链接
- 每周简报揭示了你没有有意识注意到的模式
- 反复出现的待解决问题,你不断回归的主题
- 孤立视图精确显示了你哪些思考尚未整合
三个规则让知识库持续复利而不是腐烂:
- 每个 wiki 页面至少引用一个来自 /resources/ 的来源。没有可追溯来源的综合。
- 每周 lint 检查:筛选
last_updated_by: agent且confidence: low的内容并手动复核。 - 绝不让任何 AI 助手写入 /journal/。你自己带时间戳的思考是所有其他内容构建的基础事实。
获取仓库
Familiar 是开源的。知识库骨架、AGENTS.md 模板、所有技能文件、桌面页面技能以及 cron 配置都已准备就绪,可直接使用。
github.com/codejunkie99/familiar-second-brain
完整的技术栈:
- KIMI Work(本地桌面端 AI 助手):kimi.com/products/kimi-work
- Kimi K2.6 开放权重:huggingface.co/moonshotai/Kimi-K2.6
- notes-mcp 知识库服务器:github.com/edvardlindelof/notes-mcp
- Kimi Code CLI MCP 文档:moonshotai.github.io/kimi-cli
如有疑问请在回复中提出。我会阅读每一条。
结论
本文根据作者对原始提示的笔记制作,并由 Kimi 2.6 编辑完成。








![成田悠輔的天才 AI 應用技巧 [保存版]](https://youmind.club/__ym/cms-assets/media/1784137658627_u4bwry_HNMS89bbsAAUPJI.jpg)