第二大脑跑了一年：我的wiki现在自己长知识

Tue, 13 Oct 2026 08:40:00 +0800

我试过Notion、语雀、Obsidian，每次都是同一个结局：热情维持两周，然后笔记软件变成墓地。这次不一样——一年了，我的wiki还在自己生长，而我一条笔记都没手动写过。

先说结论

我的wiki现在确实在"自己长知识"。

不是我玄学吹牛，是刚刚在本机跑了一遍统计：

项目	实测数据
Obsidian wiki 页面	37 个（实体19 + 概念17 + 对比1）
原始素材	11 篇文章 + 11 个归档记录
向量知识库	50,054 条（ChromaDB 本地存储 681MB）
自动归档定时任务	4 个，全年无休
我手动写的笔记	0 条

整个链路跑了快一年。这篇文章把我怎么搭的、真实数据长什么样、踩了哪些坑，一次讲清。

我试过的所有笔记法，都死于同一个问题

不是工具不行，是记录成本太高。

看到一篇好文章，要自己判断：记什么？放哪个目录？和已有的哪条笔记是重复的？要不要建链接？这一套下来十分钟，而"正在做正事"的冲动早就凉了。

传统笔记法对此的回答是"坚持"。我的回答是：让AI来记。

设计目标只有一条：我只负责对话和阅读，其余全部自动化。

三层架构：对话 → 提取 → 存储

整个系统分三层，各干各的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


┌─────────────────────────────────────┐
│ 对话层：日常使用，不提任何要求 │
│ （和AI助手正常聊天、干活、搜资料） │
└──────────────┬──────────────────────┘
 ↓ 自动触发
┌─────────────────────────────────────┐
│ 提取层：4个定时任务，各管一段 │
│ 会话挖掘 / wiki扫描 / 记忆整理 │
└──────────────┬──────────────────────┘
 ↓ 自动归档
┌─────────────────────────────────────┐
│ 存储层：双写策略 │
│ ① Obsidian wiki（人可读，可浏览） │
│ ② 向量数据库（语义检索，给AI查） │
└─────────────────────────────────────┘

关键认知：知识库不是"我写的笔记"，而是"对话的沉淀物"。 我和AI每天产生大量对话——调研、排障、做决策。这里面藏着大量值得留存的结论，只是以前对话一关就蒸发了。

现在它们不蒸发。

实测数据：一年后的真实规模

先看Obsidian wiki这边。37个页面不是一次性导入的，看归档日志的时间线：

1
2
3
4
5


2026-07-01 wiki初始化，首批导入 29 页
2026-07-19 扫描历史对话，补入部署/方法论 3 页
2026-08-17 Stripe收购OpenRouter大新闻入库
2026-09-28 自动lint：补18个缺失链接、修孤页
2026-10-12 最新一轮：公众号流量优化机制入库

每周一上午11点，wiki扫描任务自动跑：扫描近7天的AI会话，识别候选知识点。

值得入库的就走完整流程——建原始素材文件、创建或更新页面、更新索引、追加归档日志。

注意"更新"和"创建"的区别：wiki里每个页面有updated字段。

举一个真实例子：一个记录开源Agent框架的页面，8月份被自动更新——版本信息落后了5个大版本，扫描任务发现后自己补齐了。

“页面过期自动修正"这个动作，手写笔记的人几乎从来不会做。

再看向量库那边，规模大得多：50,054条记录。按来源分布：

来源	条数	说明
会话记录索引	28,637	对话全文的语义索引
对话轮次	19,661	逐轮归档的问答对
事件记忆	863	“做过什么事”
指令记忆	501	“怎么做事的规则”
用户画像	301	“我是谁、偏好什么”

月度增长曲线也能看出习惯的演变——6月刚迁移时冲了一波2.2万条，那是历史数据一次性灌入。

之后每月稳定新增1千到7千条不等。最近一个月7,263条，是除迁移月外的最高峰——最近做的事多，沉淀得也多。

这些数据都是刚刚在本机实测的，一个一个数的。

自动归档是怎么跑起来的

4个定时任务，分工明确：

任务	时间	干什么
会话挖掘	每周一 03:00	扫近期对话，提炼新知识入向量库
wiki扫描	每周一 11:00	判断哪些知识点值得进wiki，执行入库
记忆整理	每天 07:00	审计热记忆，超标的下沉到向量库
健康检查	每周一 04:00	查数据库健康、清漂移目录

以wiki扫描为例，它的执行规则值得展开讲，因为“往里存"容易，“存得有价值"难：

◆ 页面创建阈值：一个概念出现在2个以上来源才建页，单来源但足够核心也可以。随口一提的东西不建——这条规则挡掉了80%的垃圾页面。

◆ 去重靠页面更新：新素材提到已有页面覆盖的概念，不建新页，往老页面里加内容并更新updated字段。矛盾内容会显式标注（frontmatter里有contradictions字段），不悄悄覆盖。

◆ 强制互链：每个页面至少2个[[wikilinks]]指向其他页面，孤页会被lint揪出来。这保证了知识是网状的，不是一堆孤立文档。

◆ 标签受控：所有标签必须来自SCHEMA.md里定义的词表，想加新标签先改词表。自由打标签是知识库腐化的头号原因。

向量库那边另有去重机制：每条记录入库前先做向量相似度检查，和已有记录太像的直接跳过，避免同一个结论被存十遍。

手机也能看：Ignis部署

wiki光存在服务器上还不够，我想在沙发上用手机翻它。方案是用Ignis——一个开源的Web版Obsidian——Docker部署在主机8080端口：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


services:
 ignis:
 image: nobbe/ignis:latest
 container_name: ignis
 ports:
 - "8080:8080"
 volumes:
 - /root/wiki:/vaults/wiki  # wiki目录直接挂进去
 - ./data:/app/data
 - obsidian-app:/app/obsidian-app
 restart: unless-stopped

手机浏览器打开就是完整的Obsidian界面，双向链接、Graph View都能用。wiki目录是bind mount，AI在服务器上更新了页面，手机刷新就能看到，零同步成本。

容器已经跑了两个月，Up 7天（上周重启过一次），开机自动拉起，没管过。

踩坑实录：两个印象最深的坑

坑1：docker-compose挂载把软链接覆盖了。

最初的挂载写法是./vaults:/vaults，本意是把wiki目录通过vaults里的软链接挂进去。结果Docker挂载时直接把容器内的/vaults整个覆盖了，软链接尸骨无存，wiki根本看不见。

修复：不挂父目录，直接挂最终目录——/root/wiki:/vaults/wiki。挂载永远挂到最深层，别指望容器里保留宿主机的目录结构。

坑2：Docker机器文件系统只读。

第一版想部署在Docker服务器（一台Proxmox虚拟机）上，结果文件系统是只读的emergency模式，wiki写不进去。排查半天虚拟机文件系统问题，最后解决方案简单粗暴：换到主机上部署。基础设施出问题时，绕过去有时候比修好它更快。

另外还有条数据安全规则值得单独说：双写策略本身冗余，也是备份。wiki是纯Markdown文件，随时可以整体拷走；向量库丢了也能从会话记录重建。数据永远有一个"人能直接读"的副本，是我给自己定的底线。

一年了，它到底值不值

说真话：用得比我想象中少，但每次用都值回票价。

我查它的场景主要有三类：

“上次那个问题怎么解决的？”——排障结论最常见，命中最准
写文章时找素材——37个wiki页面就是37个现成选题库
“我之前对X的态度/结论是什么？”——画像类记忆，防止自我重复

检索体验的主观感受：排障类、决策类命中率很高，基本第一页就有答案；闲聊类的内容命中一般，但那些本来也不值得记。

最意外的收获是wiki成了写作资产。37个页面里的实体页（比如某个开源项目的分析）稍作扩写就是一篇公众号文章。知识库和内容生产打通了，这是当初没预料的。

给想复刻的人三条建议：

先定"不入库"规则，再定入库规则——拒绝的纪律决定知识库的寿命
Markdown是你永远的底牌——任何方案，数据必须是人能直接读的纯文本
别追求一次建全——我的wiki是37个页面慢慢长出来的，第一周只有29个，其中一半还是批量导入的旧料

一年前我的顾虑是"AI记的东西我能信吗”。现在的问题是相反的：翻着这份自己生长的wiki，我偶尔会忘了某个页面是"我知道的"还是"AI帮我记住的”。

后来想通了——这不就是第二大脑的本意吗。

（所有数据实测于2026-10-13，统计命令：find ~/wiki -name "*.md" | wc -l 和 ChromaDB 元数据查询，欢迎自己跑一遍验证。）

相关：Obsidian 知识管理、AI 自动归档、向量数据库检索、Ignis 自托管

AI实践 on Kalend's Blog