1. Git + Wu + Hermes + Ego Lite：我的个人知识库方案

[!abstract] 速览
市面上叫得上名字的工具我几乎都重度用过一段时间，但每次用到后面，都会撞上一两堵绕不过去的物理墙。最后我把真正刚需的指标收敛成五条：数据必须完完全全掌握在自己手里、AI 必须能通过开放协议自由读写、必须有清晰的版本管理和异地容灾、冷启动压到毫秒级、移动端一两秒钟的无感抓取。

落地组合是 Git + Wu + Hermes + Ego Lite，配合 Telegram 作为移动端的输入通道。手机上点一下分享，后台自动抓取一手全文、清洗格式、打上元数据并提交 Git。

1.1. 很多人的知识库最后为什么放着吃灰

搭建个人知识库这件事情，很多人刚开始的时候兴致都很高。

我自己以前也是这样，新下载一个笔记软件，先花两三天时间去研究别人的工作流：在根目录下建好工作、学习、生活三个大文件夹，下面再细分出技术栈、项目复盘、读书笔记，甚至还会去挑一套好看的字体和暗黑磨砂主题。刚开始记的那两三天，看着文件列表慢慢变长，总觉得自己的知识体系马上就要建立起来了。

但实际情况往往是，热情很难维持过一个月。随着日常工作忙起来，打开笔记软件的次数越来越少，最后整个库就停留在最初建好的几十个空文件夹里，彻底放着吃灰。

现在回头看，这真不是坚持不坚持的问题，而是传统记笔记的搞法，打一开始就卡在了几个很别扭的地方。

第一个卡点，是收藏太容易，但根本没时间读。

现在获取信息的成本太低了。在手机上刷推特或者技术社区，看到别人分享了一篇几千字的 Postgres 性能调优实战，或者一个刚开源的自动化工具，手指点一下收藏，也就是一秒钟的事情。

但你真要把那篇文章读懂、把里面的配置参数在本地跑一遍，至少得花三四十分钟。日常工作本身就很消耗精力，下班或者午休的时候，很少有人能静下心来去啃长篇的技术文档。

结果就是收藏夹里的链接越积越多。今天存三篇，明天存五篇，一个月下来积了几百条待读内容。每次打开待办列表，看到密密麻麻的未读标题，心里只会觉得是一笔还不清的债，到最后干脆连看都不想看了。平时用不上的资料，哪怕存得再多，本质上也只是一堆占硬盘空间的死数据。

第二个卡点，是整理规矩太多，把随手记的冲动给磨没了。

很多笔记方法论非常推崇规范化：新建一篇笔记，顶部必须写好日期、标签、来源和分类，正文要总结出三条要点，末尾还要在库里找到相关的旧笔记打上双向链接。

这套规矩在写长篇大论时或许有用，但在日常干活时根本走不通。

比如下午线上排查一个网络超时问题，折腾了半个小时，最后发现是某个服务的 keepalive 参数配短了，或者某个端口被别的进程占了。这时候你最需要做的，就是把这两行关键命令和排查结论随手贴下来，前后花不了十秒钟。

但如果软件逼着你先去想这个坑应该归到基础设施目录，还是属于某个具体项目的业务目录，再让你选几个标签，你记录的思路立马就被打断了。大部分人遇到这种情况，心理反应都是多一事不如少一事，顺手记在终端历史或者草稿纸上，转头就扔了。

记录的阻力一旦大于灵感或者踩坑的一瞬间，知识库就失去了最核心的捕获能力。

第三个卡点，是把大把时间花在排版和分类上，真遇到问题时反而指望不上。

有一段时间很流行双链图谱，很多人热衷于把所有笔记连成一张复杂的拓扑网，看着屏幕上的圆点互相连接，很有成就感。

但我后来问自己，平时写代码或者做技术选型的时候，真正用得上的东西到底是什么？无非就是某段调通了的代码片段、某个配置文件的避坑参数，或者是某次线上排障的记录。找这些内容，最有效的手段永远是全局关键词搜索，而不是顺着图谱去一级一级点开。

知识库本质上就是一个干活的工作台，它的核心目的是在你需要的时候，能以最快的速度把之前踩过的坑、收集到的原生事实调出来，以及给现在的 AI 助手提供清晰准确的上下文。

把那些多余的流程和形式主义全砍掉，让记录没有负担，让搜索足够快，一个系统才有可能真正长期跑下去。

1.2. 为什么我把主流笔记软件全给删了

在彻底放弃传统的分类方法之后，我开始重新梳理自己对工具的底线要求。

过去这几年，市面上叫得上名字的工具我几乎都重度用过一段时间：Notion、Flomo、飞书文档、苹果备忘录，再到后来的 Obsidian 和 VS Code。但每次用到后面，都会撞上一两堵绕不过去的物理墙。

最后我把真正刚需的指标收敛成了五条。拿着这五条标准去挨个对照，现成的单体软件基本全被我删干净了。

1.2.1. 数据必须完完全全掌握在自己手里

很多人觉得纯云端笔记省事，网页打开就能写，手机电脑自动同步，排版还很精致。但把所有的文字存在商业公司的云端数据库里，本质上是在用自己的长期资产去赌一家公司的经营状况。

很多前几年口碑很好的小而美笔记软件，突然某天创始人发一则公告宣布团队解散、停止维护，只给用户留两周时间去导出数据。导出来的往往还是一堆格式错乱的 HTML 或者私有 JSON，光是清洗格式就得折腾好几天。更别提大厂的在线文档，哪天机房网络故障或者光缆被挖断，整个下午你连自己昨天写的系统架构图都打不开。

真出了极端故障，平台最多发个致歉声明，甚至送你一张代金券或者退几十块钱年费。但你几年积累下来的代码片段、排障记录和业务思考，花钱是买不回来的。

所以我的第一条底线非常干脆：排除所有纯云端工具。知识资产必须是本地硬盘上的普通 Markdown 文件。拔掉网线能看，哪怕哪天某家软件公司倒闭了，我用系统自带的文本编辑器依然能直接打开读写。

这里可以把 Markdown（.md）这个格式的来龙去脉说清楚。很多人只把它当成一种给文字加粗、加标题的排版标记，但从软件演进史来看，Markdown 是计算机领域极少数能长期通用的纯文本规范。

2004 年，约翰·格鲁伯（John Gruber）和亚伦·斯沃茨（Aaron Swartz）创造 Markdown 的初衷很简单：让人们能用易读易写的纯文本格式写文档，同时能直接转成标准的 HTML。格鲁伯给它定下的原则很朴素：即使不经过任何渲染，未加工的源文件本身也必须能被人类直接当成普通文本读懂。

在它出现之前，想要写一份带样式的结构化文档，要么用 Word 这类富文本工具，底层塞满了专有的二进制或复杂 XML 结构，离开特定的商业软件就打不开；要么手动写 HTML 标签，满屏的标签干扰阅读。而 Markdown 借鉴了早期电子邮件和 Usenet 新闻组里约定俗成的标点习惯：用 # 代表标题层级、用 * 或 - 代表无序列表、用数字代表有序编号、用反引号包裹代码。敲出来的字符不靠复杂解释器，裸眼就能看清层次。

更关键的是，Markdown 天生非常适合作为大模型输入输出的格式，主要原因在三点：

1. Token 消耗少，信息密度高：Word、PDF 或富文本在线文档包含大量的字体、颜色、对齐和节点属性等样式代码。如果把带复杂样式的文档喂给大模型，很多 Token 都消耗在无效的样式标记上；而 Markdown 几乎全是纯文本语义，模型能把上下文窗口留给实际的内容和逻辑。
2. 层级结构清晰，方便切片检索：大模型处理长文档需要做切片（Chunking）。Markdown 依靠 # 到 ###### 的标题层级，段落边界清晰。做本地检索（RAG）时，程序很容易按章节做结构化切分，召回上下文更准。
3. 语法规则统一，主流模型理解稳定：Markdown 的核心语法很少，五分钟就能理清楚，主流大模型在预训练时也学习了海量的 Markdown 语料，解析非常稳定。
   1. 标题分级：行首写 ## 二级标题 或 ### 三级标题，理清正文层级；
   2. 强调与高亮：用双星号 **重要论点** 加粗，单星号 *倾斜*，行内标记用反引号 command；
   3. 代码块：用连续三个反引号包裹，并标明语言类型（如 python 或 bash），自带清晰边界；
   4. 列表与任务：数字加点表示有序，短横线 - 表示无序，待办直接写 - [ ] 和 - [x]；
   5. 链接与引用：格式为 [显示文字](链接地址)，段落引用直接在行首加 >；
   6. 表格与分割：用简单的管道符 | 字段 | 说明 | 拼表格，用 --- 划分割线。

这套格式经过二十年验证，在 GitHub、各类开源技术社区和大模型交互里成了事实上的通用标准。把 Markdown 当作底层格式，不用担心格式过时，也能顺畅对接到任何 AI 工具链里。

1.2.2. AI 必须能通过开放协议自由读写

在这个年代，知识库首要的服务对象其实已经不是人类的肉眼了，而是你的个人 AI。写代码、写方案或者做技术选型的时候，最核心的动作是把相关的背景资料和历史笔记作为上下文喂给模型。

这就要求知识库的底层必须完全对外开放。外部脚本和模型可以通过标准接口、Model Context Protocol（MCP）或者本地目录直接挂载，毫秒级读取全文。

按照这个标准，微信收藏和苹果备忘录就被排除了。平时在手机上随手存个快递单号或者会议室密码确实方便，但它们是完全封闭的私有系统。没有开放的标准 API，外部的大模型根本进不去这个黑盒。存再多技术资料在里面，也只是一座与世隔绝的信息孤岛，无法参与到现代的工作流里。

1.2.3. 必须有清晰的版本管理，还要能狡兔三窟

把数据放在本地磁盘，只是解决了服务商停运的风险，但没解决单点故障。本地硬盘会坏，电脑也有进水或者丢失的可能。

但如果只靠普通网盘去同步几千个小文件，经常会遇到恶心的问题。比如在两台电脑之间切换工作，只要有一台断网重连稍微慢了几秒钟，网盘就会判定产生冲突，在文件夹里自动复制出一堆带计算机名的冲突文件。

更关键的是版本回溯。技术笔记是一个不断修改的过程，比如写一个复杂服务的部署配置，上个月调试通过了一版，上周优化了一下参数，今天线上突然报错，你想知道上个月那个稳定版本的某一行参数到底是怎么写的。普通网盘只有粗糙的文件快照，根本看不到具体哪一行代码被修改了。

软件工程用了几十年的 Git 就是解决这个问题的终极工具。每一次修改都是一个确定的 commit，每一行变动都有清晰的 diff 对照。配合远端私有仓库，既做到了多端同步永不冲突，又顺手完成了异地容灾备份。

1.2.4. 冷启动速度必须压到毫秒级，大量小文件绝不能卡顿

这一点在日常使用中尤为致命。很多人选工具只看功能多不多，却忽视了启动延迟对记录冲动的消耗。

Obsidian 和 VS Code 都是非常优秀的软件，但它们的底层都背着整个 Chromium 浏览器和 Node.js 运行时。库里只有几十篇笔记的时候感觉不出来，一旦积累了一两万个 Markdown 文件，后台再多挂两三个插件，冷启动延迟就会直线上升。

很多时候你脑子里冒出一个灵感，或者在终端排查线上问题急需记下一行刚试通的排错命令，点击图标后，窗口白屏转圈等上好几秒。等它慢悠悠把整个浏览器引擎拉起来，手头的思路早就凉了。甚至很多时候我就去倒杯水，水都接完了，笔记还没打开。

这种微小的卡顿摩擦力，是让人放弃记录的最直接元凶。日常记笔记的窗口必须像物理终端一样秒开。

1.2.5. 移动端必须支持一两秒钟的无感抓取

绝大多数高价值的一手碎片信息，根本不是端坐在电脑前时出现的。在地铁上刷推特、在群聊里看老工程师神侃、或者在刷短视频时撞见干货，全发生在手机上。

如果每次遇到好东西，都得复制链接、发到电脑端微信、在电脑上打开编辑器、再手动粘贴排版，这套流程没有任何人能坚持过三天。

必须在手机上随手点一下分享，剩下的抓取一手全文、格式清洗、落盘归档全由后台自动化跑完。

拿这五条硬指标一卡，市面上没有任何现成的单体商业软件能全部满足。唯一的解法，就是用最轻量的积木，自己拼一套完全解耦的极速流水线。

1.3. 我的版本答案：Git + Wu + Hermes + Ego Lite

市面上的现成软件顾不过来这么多具体细节，唯一的办法就是做模块化拆解，让每个工具只干它最擅长的事情。

经过反复实测和淘汰，我目前跑得最顺手的组合是：Git + Wu + Hermes + Ego Lite。

这四个组件各司其职，配合 Telegram 作为移动端的输入通道，拼出了一条完全解耦的流水线。

1.3.1. Git：真正的资产保险箱与多端底座

在这套体系里，整个知识库就是一个普通的本地 Git 仓库。所有内容全部用最通用的 UTF-8 编码 Markdown 纯文本存储。

很多刚接触的朋友容易把 Git 和 GitHub 搞混，这里可以先做个简单区分：

[!tip] Git 与 GitHub 不是一回事
Git 是跑在本地电脑上的版本管理工具，而 GitHub 只是一个远端的代码托管网站。

就算不连外网、不用 GitHub，Git 在本地硬盘上也一样能正常工作。它是去中心化的，只要在笔记目录执行 git init，本地的 .git 目录就会完整记录每一次提交的历史。

如果要多设备流转（比如在公司和家里电脑之间同步），或者需要异地备份，才需要找一个远端托管平台。除了 GitHub，国内也可以选 Gitee（码云）。如果在国内网络环境下遇到 GitHub 连接不稳、推送超时的情况，Gitee 的直连网络更稳一些，同步多文件速度也很快。

不过在把知识库推到远端时，有两个基础的安全习惯需要注意：

[!warning] 推送到远端之前的两条安全习惯

1. 仓库设为私有（Private）：不管是 GitHub 还是 Gitee，创建仓库时一定要选 Private，不要选 Public，避免把私人笔记和日常随手记暴露在公网上。
2. 不要把 API 密钥和账号凭据同步上去：平时写脚本或者调模型，经常会用到各种 Key（比如 OpenAI Key、Telegram Bot Token）。这些敏感配置不要明文写在要推送的笔记里。

解决这个问题的方法是在知识库根目录下建一个 .gitignore 文件，把 .env、临时配置文件和系统生成的垃圾文件（如 .DS_Store）填进去，Git 就会自动忽略它们，避免误提交。

如果不想自己手写配置，直接让本地 AI 帮忙写一个针对个人笔记库的 .gitignore 即可。

有了 Git 作为底座，改动有据可查，试错成本很低。写长篇文档或者整理技术方案是一个不断修改的过程，哪天改了哪一行，Git 的 diff 检查一目了然。如果想对某个模块做大规模调整，拉个新分支去改，改好了合并，改乱了随时切回原来的状态。

多设备流转也很省心。两台电脑切换工作，执行一次 pull 就能把内容同步齐，不会出现网盘同步延迟导致的文件冲突。手机端配合移动端 Git 工具也能随时查看搜索，顺手改个错别字就能同步回云端。

1.3.2. Wu：告别臃肿与捆绑，基于 Rust 的极速编辑器

电脑端日常看和写笔记，我把重量级编辑器换成了 Wu。

写 Markdown 文本，为什么不用大家常用的 VS Code？或者既然看中性能，为什么不选 Zed，而要用它的开源分支 Wu？

主要是在实际使用中遇到过这几个问题：

先说为什么没用 VS Code。

VS Code 作为开发环境很强，但拿来做随手记笔记、看资料的日常工具，体量偏大。它底层是 Electron 套壳，每次冷启动都要加载后台服务和插件，窗口经常要等上几秒才显示出来。平时线上排错想顺手记个命令，或者脑子里冒出一句话，等待加载容易打断节奏。而且最近版本在界面里频繁捆绑推广自家的 Copilot 相关功能，对于只想安安静静读写本地 Markdown 纯文本的人来说，干扰项有些多。

再说为什么没法用 Zed，而选择了它的开源分支 Wu。

Zed 基于 Rust 打造，主打 GPU 渲染，性能底子很好。但它在中文输入法（IME）支持上一直存在问题：中文输入经常丢字、候选框漂移或者光标错位，且官方团队在社区反馈中表示短期内不会优先解决多语言输入法适配。对于需要频繁记录中文笔记的场景，打字不跟手很难长期用下去。

而开源分支 Wu 继承了 Zed 的 Rust 异步内核与 GPUI 硬件加速渲染，文字排版和渲染直接走显卡，冷启动速度很快，在终端输入 wu . 窗口基本秒开。

更重要的是，Wu 专门优化了中文输入法跟手度和本地排版体验，候选框跟随光标，汉字显示正常，补齐了原版的体验短板。

在处理海量小文件时，Wu 的异步文件索引效率也很高，库里放上万个 Markdown 文件，呼出搜索框模糊匹配或者全库正则搜索，反馈都足够即时，不会造成界面卡顿和电脑风扇狂转。界面本身也很简洁，没有多余的商业推送，打开就是纯粹的文本编辑。

1.3.3. Hermes：常驻本地的私人助理与智能调度器

有了纯文本底座和极速编辑器，Hermes 则是把整个库真正用起来的大脑。

Hermes 直接运行在我的本地宿主机上，和笔记库在同一个物理文件系统里。很多所谓的 AI 知识库产品，需要把文件一篇篇上传到远端服务器去建向量库，本地一修改两边就脱节。Hermes 是本地原生读写，我在本地刚存下一篇笔记，它下一秒就能直接检索调用，不需要上传，也没有格式损耗。

它不仅能回答问题，更能跑脚本调工具。当手机端发过来一个链接，Hermes 会自动判断链接类型，调度底层的 Ego Lite 抓取工具打开浏览器去提取原文，抓完自动打上 YAML 元数据并执行 Git 提交，整个过程都在后台静默跑完。

平时干活遇到任何问题，不用自己费劲去翻目录，直接向 Hermes 提问。它会在毫秒级检索全库，带着具体的文件名和行号把答案整理好端给你。过去存下的那些笔记不再是石沉大海的死档案，随时随地都能被唤醒。它还会在后台定期巡检目录，清理重复抓取的无效内容，把繁琐的维护脏活全包了。

1.4. 移动端剪藏实战：手机点一下，一手全文自动进库

搭建这套体系最顺手的地方，在于把复杂的技术逻辑全藏在了最简单的日常操作后面。

在手机上看到一篇好文章或者技术视频，点击系统分享，发送给自己的 Telegram 机器人，然后继续该干嘛干嘛。后台会自动把这行链接转化成一篇排版整齐、带元数据的一手 Markdown 文件存进本地。

而在支撑这套移动端闭环的工具里，Telegram 和 Ego Lite 各自解决了最关键的环节。

1.4.1. Telegram：移动端接入 AI 的极简入口

为什么移动端剪藏选 Telegram，而不是微信、邮件或者第三方的剪藏 App？

第一个原因是顺手。在 iOS 和 Android 系统里，Telegram 永远排在系统原生分享菜单的前排。看到好内容，点一下分享，点一下机器人名字，点击发送，前后一两秒钟，手指肌肉记忆就能完成，不需要打开专门的 App，更不需要手动复制粘贴链接。

第二个原因是 Telegram 接入 AI 非常丝滑。很多国内平台做 Bot 限制极多，要么需要企业资质认证，要么经常遇到接口风控或者网络白名单问题。而 Telegram 官方提供的 Bot API 开放且稳定，几分钟就能配好一个专属的私人机器人。

更关键的是它对交互体验的支持很到位。Telegram 原生支持流式传输（Streaming），平时在手机上让 AI 检索笔记库或者回答技术问题时，文字是像打字机一样顺滑吐出来的，不需要面对死板的加载中弹窗干等好几秒。

它的菜单命令也很整齐。底部的命令列表可以配置得井井有条，点开菜单就能看到清理、检索、速记等预设指令，不需要每次都手动敲一长串提示词。

再加上 Telegram 本身的多端同步特性，发出的消息在手机、电脑和平板上全部实时漫游。就算家里的电脑临时关机，发过去的任务也会在云端队列里排队，电脑开机后自动消费处理，不会丢掉任何一条灵感。

1.4.2. Ego Lite：浏览器自动化神器，拿下无可争议的一手真源

把链接送到后台之后，怎么把网页上的文字抓下来，是整个流程里最容易踩坑的环节。

市面上很多剪藏插件习惯调用大模型给文章生成一份几百字的摘要，然后把摘要存进笔记库。这种做法在建知识库时问题很大。大模型生成的摘要往往会丢失原文里的关键代码、实验数据、配置参数和逻辑推导。这种充满水分的二手总结存得再多，等到真正排错或者写代码要查细节时，根本起不到参考作用。

[!important] 入库的必须是一手原文
我们的底线只有一条：入库的必须是 100% 真实的一手原文。

但现在的技术长文和博客，很多都运行在单页面应用（SPA）上，内容是通过 JavaScript 异步加载出来的，还经常挂着各种人机验证防火墙。普通的爬虫脚本发个请求过去，拿到的往往只是一段白屏代码。

Ego Lite 就是专门解决这个问题的浏览器自动化神器。

它的底层是一个受控的真实 Chromium 浏览器。当后台接到抓取指令时，Ego Lite 会带着真实浏览器的环境指纹打开目标页面，等待动态脚本渲染完毕，自适应滚动页面把懒加载的内容全部刷出来，然后直接去提取文档节点的原生纯文本：

// Ego Lite 提取核心逻辑（伪代码示意）
const page = await browser.newPage();
await page.goto(targetUrl, { waitUntil: 'networkidle2', timeout: 30000 });
await autoScroll(page);
// 直接读取渲染完成后的真实纯文本节点，不走模型重写
const rawText = await page.evaluate(() => {
  return document.body.innerText;
});

这样抓下来的内容，去掉了网页上乱七八糟的侧边栏、广告和样式代码，原原本本地保留了作者的所有段落排版、技术参数、代码块和标点符号。

而且这个提取过程完全是在本地浏览器里执行，不需要调用商业大模型的 API，不产生 Token 账单，一两秒钟就能搞定。

1.4.3. 元数据与自动化闭环

抓取下来的原始文本，系统会自动打上规范的 YAML Frontmatter：

---
url: https://x.com/example/status/123456789
fetched_at: 2026-11-03T10:30:17+0800
fetched_via: ego-lite
chars: 8421
---

文件以原子写方式落盘在 002-references/raw/ 目录下，并自动触发 Git 提交。

随后，Telegram 机器人会向手机端回一条通知：已成功入库某某文章，全文 8421 个字符。人在外头走路，这篇高质量的一手资料就已经在电脑硬盘上整理好了。

1.5. 形成闭环的飞轮：用公开输出倒逼思考精进

工具链和自动化流水线搭好之后，还有一个最核心的心智转变：知识库不能是一个只有输入没有输出的死水潭。

很多人过去建知识库之所以半途而废，不仅是因为整理太繁琐，更是因为笔记记完之后就锁在本地，既不参与实际工作，也不面向外界交流。时间一长，这些笔记就失去了生命力。

一个真正能持续运转的系统，必须是有进有出的闭环。

1.5.1. 用费曼学习法做公开压力测试

最顶级的知识内化方式，从来都是费曼学习法：把你学到的新技术、刚踩完的技术坑，用最直白的大白话讲给别人听。如果你写不出来，或者写出来别人读不懂，说明你自己脑子里其实根本没想透。

很多工程师习惯把笔记当私房日记，觉得写得不完善就不敢拿出来。但我的经验是，最好的内化手段，就是直接把它发布在社交平台或者技术社区上。

公开发布会带来一种非常健康的外部约束力。当你意识到这篇文章或者这条推文要被同行看到的时候，你自然会逼着自己把那些模棱两可的代码跑一遍、把参数细节核对清楚、把假大空的套话全部删掉。这种为了向公众讲清楚而做的梳理，本身就是对知识最高强度的内化。

1.5.2. 收集真实反馈，让知识库自我进化

发出去并不是终点，而是闭环的真正开始。

把思考公开之后，最宝贵的收获往往来自于读者的评论和互动。

同行可能会在评论区指出你在某个特定架构下的边界漏洞，会补充另一种更优雅的配置方案，或者提出一些你从未考虑过的极端场景。甚至哪怕是挑刺和质疑，也能帮你快速发现自己思考里的死角。

这些来自真实世界的反馈，是坐在屋子里自己琢磨十天也换不来的。

把这些有价值的评论、指正和补充，重新整理回自己的笔记库里，修正之前的判断和技术选型。这时候，你的知识库就不再是一个静态的私人文件堆，而是一个能随着外部反馈持续迭代、自我进化的活系统。

1.5.3. 支撑闭环运转的极简四层目录

为了支撑这套“输入 ➔ 内化 ➔ 发布 ➔ 反馈”的飞轮，底层的目录结构必须极度轻量，绝不能让分类成为绊脚石：

knowledge-base/
├── 001-inbox/        # 临时收集池：随时冒出来的念头、未加工的碎片原话
├── 002-references/   # 外部输入层：通过 Telegram 与 Ego Lite 自动抓取的一手资料
│   └── raw/          # 原始文本库：带时间戳与元数据的一手原文
├── 003-notes/        # 核心内化层：自己想明白的论点、正在打磨准备输出的内容
└── 004-archive/      # 归档终点层：已经在社交平台发布的内容与项目快照

日常运转非常纯粹：

[!tip] 平时维护只需要守住两条底线
第一是别花时间维护复杂的标签字典，全局搜索完全够用；第二是严格把外部一手资料和自己的内化思考在目录上物理隔开，防止水分污染核心底座。

1.5.4. 结语

折腾了一大圈笔记软件，最后发现真正管用的系统，反而是最质朴的。

用最底层的 Git 守住数据所有权，用毫秒级秒开的 Wu 敲下文字，用 Telegram 和 Ego Lite 在手机端无感抓取一手事实，最后通过公开发布拿到真实世界的反馈。

让工具彻底退到幕后不刷存在感，把所有的精力和算力，留给真实的表达与思考。

1.6. 附录：一键初始化个人知识库 Prompt（复制发给你的 AI）

如果你想直接跑通这套方案，不需要手动一层层建文件夹、敲命令行或者配置规则，把下面这段指令复制发给你的 AI 即可（支持终端操作的 Agent 会直接在本地建好，对话模型会输出对应命令）：

你现在是我的个人知识库架构师。请在当前目录下帮我初始化一套极简且面向 AI 的个人知识库。

核心原则：1. 数据所有权归我：使用本地 Markdown 纯文本，配合 Git 进行版本管理；2. 安全与隐私第一：做好敏感凭据过滤，配置好忽略名单，方便推送到 GitHub/Gitee 私有仓库；3. 扁平四层结构：不搞多层嵌套，只保留信息流转的四个关键节点；4. 一手资料隔离：外部参考资料与个人内化笔记在目录上分开，避免格式和内容混杂；5. 输出闭环导向：以公开发布和实践为目标，不做只进不出的死档案。

请帮我执行以下操作（如支持终端请直接创建，如不支持请输出完整命令与文件内容）：1. 初始化 Git 仓库（如果当前目录尚未初始化 git init）；2. 创建标准的 .gitignore 配置文件，包含以下规则：- 过滤系统与编辑器缓存：.DS_Store、Thumbs.db、*.swp、.idea/、.vscode/；- 过滤敏感密钥与配置文件：.env*、*.key、*.pem、credentials.json、tokens.json；- 过滤本地运行临时文件：*.log、tmp/、__pycache__/、.venv/；3. 创建四层核心目录结构：- 001-inbox/ （临时收集池：记录随手原话与碎片灵感）- 002-references/raw/ （外部输入层：存放抓取的一手资料原文）- 003-notes/ （核心内化层：自己梳理后的永久笔记与准备输出的草稿）- 004-archive/ （归档终点层：已公开发布的内容与结项快照）4. 在每个目录下生成一个简洁的 README.md，说明该目录的定位与记录建议；5. 在根目录 README 里注明提示：远端仓库（GitHub 或国内网络更稳的 Gitee）建议设置为 Private（私有仓库），仅限个人访问。

初始化完成后，简要告诉我目录和配置已经就绪即可。

1.7. 相关软件与参考文献

1.7.1. 核心软件与工具链

1.7.2. 本文参考与调研的一手文献

1. 老K：《如何用 X 高效学习：4 步打造高质量信息流与个人知识库》 https://x.com/X_Crypto110/status/2111720591841804403
2. Kyrie：《30 分钟搭好 Karpathy 同款知识大脑，让 LLM 替你维护笔记库》 https://x.com/KyrieCheungYep/article/2075045965371949439
3. 金尘马：《小白如何从 0 到 1 搭建自己的 AI 知识库》 https://x.com/jinchenma_ai/status/2082495802640080899
4. 金尘马：《一文讲清楚，普通人和中小企业如何搭建 AI 知识库》 https://x.com/jinchenma_ai/article/2074515412272996467
5. 金尘马：《告别手动整理：小白如何用 Obsidian 搭一个 AI 驱动的个人知识库》 https://x.com/jinchenma_ai/status/2059842551218422004
6. 金尘马：《一篇讲清楚，如何构建 AI 知识库的目录结构和配套的 Skills 工作流》 https://x.com/jinchenma_ai/status/2083218688795427111
7. Biteye：《连 AI 大神都在抄的作业：利用 LLM Wiki 构建高效个人知识库》 https://x.com/BiteyeCN/status/2041445011619975407
8. 超级个体｜柿子：《如何构建自己的内容知识体系》 https://x.com/yaohui12138/status/2013089523086065777
9. 木马人：《Karpathy 同款知识库 5 步上手梳理》 https://x.com/cnyzgkc/status/2039926431657124126
10. tychozzz：《从 0 到 1 搭建 AI 时代的外置大脑》 https://x.com/tychozzz/status/2043589625726541988
11. Cheery：《从零搭建「第二大脑」+ Obsidian Skills 相关》 https://x.com/cheery9998/status/2114601081598845227
12. 开源工具：《x-brain：把 X 转发变成本地知识库和思维导图的开源工具》 https://www.jxxy.net/ai/articles/a-gh-2026-10-18-4172-x-brain-local-knowledge-base/
13. helloianneo：《Obsidian + Claude AI 个人知识库完整搭建指南》（GitHub） https://github.com/helloianneo/obsidian-ai-second-brain
14. 掘金：《手把手教你用 WorkBuddy + Obsidian 搭建会自我进化的个人知识库》 https://juejin.cn/post/7699320318288117798