做一个第二大脑 App：什么才是真正重要的

我一直在思考第二大脑应用这个问题——既作为一个对现有工具不满的用户，也作为一个想自己动手做一个的工程师。

经过几个月的实验（给自己做原型、也给团队做内部工具），我总结出了一个思考框架。一个第二大脑其实只有四层，而大多数应用在优先级上搞错了。

四个层次

1. 输入（Capture）   →  快速记录想法
2. 存储（Storage）   →  数据放在哪
3. 渲染（Rendering） →  展示效果
4. 检索（Retrieval） →  怎么找回来

大多数笔记应用都在第 2 和第 3 层（存储和渲染）上死磕。Notion 有漂亮的数据库，Obsidian 有炫酷的关系图。但这些都不是应该最先优化的层。

我两个都深度用过，说说它们各自的问题：

Notion 太精致、太臃肿了。它试图成为一切——wiki、数据库、项目管理、文档——结果就是一个打开慢、记录更慢的庞然大物。我最近发现 Notion 在我电脑上占了 100GB+ 的磁盘空间，而我存的笔记不到 20 条。显然是个 bug，但这也说明了一个问题：当你的笔记应用比大多数游戏还大的时候，工程优先级肯定出了问题。
Obsidian 的问题正好相反：太多可定制性了。它是极客和插件爱好者的乐园，但服务的也正是这群人——花时间折腾配置而不是捕捉想法。插件生态确实厉害，但也让人眼花缭乱。在追求无限可配置的过程中，简洁被丢掉了。

两个都是好工具，但都没有做好最重要的事：让你零摩擦地把脑中的想法记下来。

真正重要的是第 1 层和第 4 层：输入和检索。 如果输入不够快，你就不会用。如果找不回来，那就是个坟场。

第一层：输入——速度就是一切

输入最重要的设计原则：消除一切摩擦。

当一个想法闪过，你大约有 5 秒钟的窗口。每一次点击、每一个加载页面、每一个"这个应该放哪个文件夹"的决定，都是让这个想法消亡的机会。

这意味着要做刻意的取舍：

牺牲结构换速度。 不要在输入时让用户选分类、标签或文件夹。先扔进收件箱，之后再整理（或者让 AI 来整理）。
牺牲在线依赖。 输入必须支持离线。如果保存一条笔记需要等网络请求返回，你已经输了。
牺牲格式。 输入界面应该就是一个文本框。不要富文本编辑器，不要 markdown 工具栏，不要模板选择器。就是文字，最多加上语音。
牺牲完整性。 记了一半的想法，比没记下来的想法有价值无限倍。允许用户写片段、单句话、甚至只是几个关键词。

黄金标准：掏出手机，App 打开就是输入框，打字或说话，10 秒内搞定。其他一切都是下游问题。

第二层：存储——简单胜过聪明

我在尝试两种方案：

方案 A：纯 Markdown 文件 + Git

~/brain/
  inbox/
    2026-04-13-随手想法.md
  projects/
    kioku/
      notes.md
      architecture.md
  references/
    llm-context-windows.md

用 git 做版本控制。每条笔记是一个文件，文件夹是唯一的组织方式。

优点： 可移植、可 grep、兼容任何编辑器、零厂商锁定、diff 有意义、永远离线可用。

缺点： 不支持关系查询、多设备实时同步需要额外工具、多端编辑可能有合并冲突。

方案 B：数据库 + Markdown 列

把 markdown 内容存在数据库行里，按需渲染成文件。用 Supabase/Postgres 做后端。

优点： 实时同步、关系查询、容易做搜索、天然适配移动端。

缺点： 有厂商依赖、需要服务器、内容被 API 锁住。

我的结论

个人工具：文件 + git。简单无敌。我可以用 VS Code、vim、Obsidian 或任何文本编辑器。数据永远是我的。

团队/公司工具：数据库。你需要实时同步、权限控制，以及跨用户知识库的查询能力。

消费级 App（也就是我要发布的产品）：用数据库存储，但随时可以导出为 markdown。不要锁住用户。

第三层：渲染——看你的受众

一个可能有争议的观点：对大多数第二大脑场景来说，渲染几乎不重要。

对消费级 App，是的——需要好看。用户期待精美的 UI，漂亮的阅读体验有助于留存。Obsidian 的主题生态做得很好。

对团队或内部工具，渲染几乎无关紧要。工程师和知识工作者只关心两件事："我能找到吗？"和"内容准确吗？"没人在欣赏内部 wiki 文章的排版。

所以我的建议：不要在早期过度投入渲染。用标准 markdown 渲染器就好。把时间花在检索上。

第四层：检索——这才是真正的战场

这是我最兴奋的部分，也是我认为整个第二大脑品类即将被颠覆的地方。

旧方式：搜索、标签、文件夹

传统笔记应用给你三种检索方式：

文件夹 —— 你得记住放在哪了
标签 —— 你得记住打了什么标签
全文搜索 —— 你得记住用了什么词

这三种方式都假设你还记得关于那条笔记的某些信息。但第二大脑的全部意义就是替你记住事情。

RAG 时代（2023–2025）

第一波 AI 笔记应用用的是 RAG（检索增强生成）：把笔记向量化，找语义相似的片段，传给 LLM。

RAG 能用，但复杂且有损：

你需要 embedding 模型、向量数据库、分块策略
检索质量严重依赖分块大小和 embedding 质量
LLM 只能看到片段，看不到你的完整上下文
又是一个需要维护、调优和调试的系统

新方式：把所有东西直接扔进上下文窗口

这是 Andrej Karpathy 最近发推提到的想法，而我在做原型时独立得出了同样的结论。

现代 LLM 的上下文窗口已经超过 100 万 token。大约相当于 75 万字——或者大约 1500 篇完整笔记。对大多数人的个人知识库来说，这就是……全部了。

做法：

用户提出问题
把他们的整个知识库（或大量相关子集）加载到上下文窗口
LLM 带着完整的上下文感知来回答

不需要 embeddings。不需要向量数据库。不需要分块。不需要调优检索管道。

为什么这比 RAG 更好：

LLM 能看到笔记之间的联系，而检索管道会遗漏
不会因为分块边界而丢失信息
可以问复杂的、跨领域的问题（"我学到的关于 X 的东西里，有什么和 Y 矛盾的？"）
构建和维护都简单得多

明显的限制： 成本和延迟。每次查询发送 100 万 token 不便宜。但上下文窗口的成本在快速下降——今天花 10 美元的事情明年可能只花 0.1 美元。而对于一个月收 10-20 美元的订阅应用来说，如果用户每天的查询量合理，这笔账已经算得过来了。

对产品的启示

如果检索就是"把所有东西扔给 LLM"，那应用架构会极大简化：

输入（快速记录）
  → 存储（简单的文件或数据库）
    → 检索（加载上下文 + LLM 查询）

不需要 embedding 管道。不需要向量数据库。笔记改了也不需要重新索引。硬核的工程问题消失了，剩下的纯粹是产品设计：怎么让输入无摩擦？怎么呈现 LLM 的回答才有用？

我在做什么

我正在做 Kioku —— 一个基于这些原则的知识应用：

10 秒内完成输入 —— 文字或语音，不需要分类
简单存储 —— 兼容 markdown、可导出、不锁定
AI 优先的检索 —— 不需要手动搜索、不需要翻文件夹。问一个问题，得到基于你自己知识的回答
端侧 AI —— 使用 Google Gemma 4 等端侧大模型，你的知识留在你的设备上。不需要云端请求、没有隐私顾虑、即时响应
学习整合 —— 不只是存知识，还通过间隔重复帮你记住

如果你觉得有意思，可以订阅下方邮件列表——我会分享构建过程。

最好的第二大脑是你真正会用的那个。其他一切都是装饰。