给 AI 搭一套第二大脑：数百篇笔记自动同步并每日反思

作者：袖梨 2026-09-21

把数百篇 Markdown 笔记交给 AI 管理，真正困难的并不是生成几段总结，而是让同步、索引、检索和反思长期稳定运行。这套系统通过 Obsidian、Git 仓库、云服务器与定时任务串起完整链路，同时也暴露出索引遗漏、搜索失灵和笔记孤岛等工程问题。下面从实测数据出发，拆解它的配置与边界。

我给 AI 装了个第二大脑：281 个文件、233 篇笔记，它每天 7 点自己写反思

我的知识库磁盘上躺着 281 个 Markdown 文件，索引里只有 233 篇。差的 48 篇不是丢了，是它们从来没"办过身份证"。

更离谱的是另一头：这 233 篇里最近 8 天的反思，没有一篇是我手写的。每天 07:00 整，一个定时任务自己拉数据、自己写、自己 commit、自己 push。240 次 git 提交里，最近 8 天全是它一个人干的。

这篇不聊概念，只摊开一台最便宜的云服务器上的真实配置：多少篇、多少延迟、哪些坑。

一、15 天后的真实体检（数据来自本机实测）

在服务器上敲这一条：

python3 ~/second-brain/99-系统/脚本/vault_tools.py scan-vault

返回（实测 0.053 秒扫完 233 篇）：

{
  "total": 233,
  "by_type": {"reflection": 139, "log": 61, "insight": 10, "concept": 8,
              "fact": 6, "project": 4, "moc": 4, "design-doc": 1},
  "by_status": {"evergreen": 208, "sapling": 19, "seed": 6},
  "total_links": 269,
  "avg_links": 1.2
}

配套的硬数字：

指标实测值
磁盘上的 .md 文件281
进入索引的笔记233
未进入索引（工程文件）48
git 提交总数240
全库 Markdown 文本1,383,537 字节
仓库体积 / .git5.2 MB / 16 MB
自动反思已执行18 次（最新一次 07:03 ok）
知识孤岛（链接数 0）3

注意最后两行。自动化不是"配好了就一劳永逸"——233 篇里 208 篇标了 evergreen，看起来很美，但平均链接数只有 1.2，意味着绝大多数笔记只被自己链着。

二、三向同步：链路短到只有三跳

真实拓扑（不是示意图）：

  1. Windows 本地 Obsidian：Obsidian Git 插件每 10 分钟 commit + push 到私有仓库；
  2. GitHub 私有仓库：只当中转站，不解析、不渲染、不加工；
  3. 服务器每 30 分钟 pull 一次，拉完重建索引。

crontab 里就一行：

*/30 * * * * /home/ubuntu/brain-engine/99-系统/脚本/sync.sh pull

sync.sh 里有三处是踩过坑之后才加的：

  • stash 保护：pull 前 git stash --include-untracked，pull 后 git stash pop。服务器上有本地改动的服务端脚本，不加这一步会被远端直接覆盖；
  • SSH 端口降级：22 端口拉不动就自动切 ssh.github.com:443 重试，失败就放弃并保护本地数据（--ff-only，绝不强推）；
  • 文件锁：/tmp/brain-engine-sync.lock。30 分钟一次的任务遇到慢 pull 会重叠，不锁就是叠罗汉。

顺带说一句：服务器只读，不写。所有内容在本地或由定时任务写入后提交，服务器负责拉取和索引。同步方向单一，冲突面直接归零。

三、281 → 233：索引白名单才是关键

这是全文最值得抄的一段。扫描器不是"扫全库"，而是目录白名单制：

SCAN_DIRS = [VAULT/"01-项目", VAULT/"02-领域", VAULT/"02-自然科学",
             VAULT/"03-资源", VAULT/"03-思维模型"]
# 另外单独挂三个：00-Inbox、05-AI反思、99-系统/MOC

被排除的那 48 个文件，全部落在工程目录：

目录未索引文件数内容
99-系统27系统提示词、脚本说明、日志
06-模板10各类笔记模板
04-归档6历史归档
07-仪表盘4统计面板
根目录1README

反过来说：索引里那 233 篇，一篇模板都没混进来。

模板被检索进来，是第二大脑最隐蔽的污染源之一。你搜一个概念，返回的第一条是一张空白模板——这不是搜索坏了，是你把模板放进了扫描路径。

四、反直觉 1：多词搜索会静默返回 0

我想找"字体子集化 性能优化"，接口直接给我 0 条：

curl -s -X POST http://127.0.0.1:8765/search 
  -H 'Content-Type: application/json' 
  -d '{"query":"字体子集化 性能优化"}'
# {"count": 0, "results": []}

换成单个词，立刻有结果：

# -d '{"query":"字体"}'  → count = 6
# -d '{"query":"掘金"}'  → count = 18

翻实现就明白了：它做的是整串子串匹配——if kw_lower in title or kw_lower in content。不分词、没有 AND/OR、没有相关性排序。

教训：自建检索接口返回 0 条时，先怀疑查询语法，再怀疑数据。我当时差点因为一次 0 结果去重建整个索引——那才是真正的浪费。

五、反直觉 2：反思越写越长，不等于质量提高

自动反思生成的日报，体量在涨：

日期行数字节
09-10818,855
09-1410816,563
09-1713021,982
09-2114719,895

行数 +81%，字节 +125%。看着像"成长曲线"，但真正让它稳定在 140 行上下的，不是模型变强了，是我后来给它加了强制结构：三件做得好 / 三个待改进 / 明日一件最重要的事。

没有结构的自动化写作，只会把流水账越写越长。结构，才是它的刹车。

六、孤岛：自动化解决不了的那一半

/orphans 接口实测返回 3 篇零链接笔记。

自动化索引解决的是**"能找到"，解决不了"连得上"**。前者是工程问题，一行路径白名单就能解决；后者是认知问题，得靠人（或者一个专门做连线的任务）去想"这条和那条到底什么关系"。

这也是我给这套系统定的边界：机器负责搬运和归档，关系的发现留给人。

七、可抄清单

  1. 同步链路只做单向搬运：本地 → 仓库 → 服务器，服务器只读，冲突面直接归零；
  2. pull 必配 stash + 文件锁：慢网络下的并发 pull 会互相踩，set -e 也救不了；
  3. 索引白名单制，绝不扫全库：模板、系统文案物理隔离，别靠命名规范去躲；
  4. 自动化任务必须带强制结构模板：没有结构，输出会随天数膨胀成流水账；
  5. 自建搜索先验证查询语法：count: 0 不等于数据丢了；
  6. 每天固定一个时间点做自检 + 自写：比零散巡检可靠得多，也更容易被验证。

这套东西跑在一台最便宜的云服务器上，全库文本 1.38 MB，重建一次索引 0.08 秒。规模很小。

但它是活的——每天 07:00，我不用动手，它自己更新一次自己。

Solara · 出品 ｜ 用代码驱散迷雾 · 用设计温暖人心

相关文章

精彩推荐