AI 越强，越需要一套由自己掌握的第二大脑｜我的 Obsidian 搭建逻辑

如果你是一家公司的创始人、CEO，或某个业务的1号位，你一定熟悉下面这些moments：

每天读了很多行业新闻、报告、论文和 AI 对话。值得保存的内容越来越多，真正能在项目里持续用起来的却很少。过一段时间再回头看，已经找不到了。

一个持续几个月的项目，会经历调研、讨论、决策、推翻、重做和复盘。最后交付的文件可能还在，当时为什么这样判断、哪些方案已经验证失败，常常留在聊天记录和参与者的记忆里。

你可能已经在同时使用好几个 AI 应用参与同一个项目，需要不断对齐上下文。如果整个过程都靠自己手动切换窗口、复制粘贴，会很麻烦。

虽然，AI 让这些已经积累的内容有了新的使用方式。它可以帮我们阅读、提炼、连接和复盘，也可以从真实项目中抽象经验。

但真正麻烦的不是教会这些AI写你认为合格的方案，而是它们彼此并不知道你为什么这样判断，公司现在最重要的目标是什么，哪些事情已经试错过，哪些边界不能再碰。

这些信息过去主要存在于你的脑子、会议室纪要和少数核心管理者之间。AI加入之后，一个新的问题出现了，你的要求和思考，一次次散落在给AI的口喷中，你怎样让它们持续理解这家公司和你的业务，又不越权下判断？

这就是我搭建 Obsidian 的原因。

它不仅是一套由我持有的本地长期知识库 OS，也逐渐成为我和 AI 共同遵循的长期记忆与规则底座。

Obsidian 负责长期保存和结构化。项目历史、知识、经验、判断以及 Agent 的行动规则，都留在同一批本地文件里。Claude、Codex、Kimi 、WorkBuddy 等 Agent 可以按任务接入，参与阅读、提炼、推理和执行。我负责确定目标、做价值判断，并保留最终裁决权。

再加上 IPO 模型、总纲、安全协议和反馈机制，这些部分共同构成了我所说的“人机协同第二大脑”。

所以，这篇文章中的“第二大脑”指的是整套人机协同系统。下来我想讲清楚两件事：为什么长期脑力工作越来越需要这样一套系统，以及我怎样用「IPO」模型和「System」规则把它一步步搭出来。

一、AI 很聪明，长期协作仍然需要可持续的上下文

通用型 AI 的理解和执行能力已经很强。它可以在几分钟内读完大量资料，整理观点，写方案，甚至直接进入本地项目完成工作。

但一个新 Agent 刚进入项目时，很像一位能力很强、刚加入团队的同事。

它可能看得到项目文件，却不了解当初为什么选择这条路；它可能搜到一份写得很完整的旧方案，却不知道这份方案已经作废；它也可能读到很多讨论记录，却分不清哪些属于脑暴，哪些已经成为正式决定。

模型能力决定它能完成多难的任务。进入任务前拿到的上下文质量，决定了它能把这件具体任务实现到什么真实、可用程度。

对长期项目来说，真正需要保存的内容至少包括：

• 项目为什么开始，目前最重要的目标是什么；
• 当前进展、关键决定和已经否决的方案；
• 哪些结论已经验证，哪些仍在测试；
• 哪份文件代表当前版本，历史版本保留在哪里；
• 上一次执行留下了什么结果和教训；
• 这次任务允许 Agent 读到哪里、操作到什么程度。

如果这些内容散落在聊天窗口、网盘、电脑文件夹和不同 AI 产品里，每一次协作都需要重新拼接背景。Agent 增加以后，这项隐形成本也会一起增加，甚至可能“传话”失真走样。

所以，为什么需要一个本地长期知识库？因为只有当单次、随机对话变成可持续发展、迭代的长期记忆时，AI 才正式成为你的“活人感” team member。

二、知识库要保存信息，也要帮助知识继续生长

知识库首先解决外置记忆的问题。

David Allen 在 GTD 方法里有一句很有名的话：

“Your mind is for having ideas, not holding them.”

大脑适合持续创造，无须长期留所有待办和信息。

当每天接触的信息超过大脑能够稳定记住的范围，我们需要把有价值的内容放到外部系统里。这一步通常被称为“认知卸载”：让外部工具承担一部分记忆和提醒任务，把注意力留给理解、判断和创造。

不过，外置记忆的价值远远超过“以后还能找到”。

比如我读到一份新的 AI 行业报告，我会关心它和 INVERT 当前产品判断有什么关系；看到一个投资案例，我会比较它是否修正了自己原来的估值逻辑；完成一轮 Vibe Coding，我会把架构漂移、验证方法和修复经验写回项目复盘。

信息经过这样的加工，才会逐渐形成与我有关的知识。

1945 年，Vannevar Bush 在《As We May Think》中写道：

“The human mind … operates by association.”

人的思维依靠关联运行。

他设想的 Memex 可以保存个人的书籍、记录和通信，并通过“关联路径”把不同内容连接起来。今天 Obsidian 里的双链、索引和知识图谱，延续的也是这条思路。

当一套知识库持续积累，我们可以逐渐看见：自己在哪些问题上形成了稳定判断，哪些知识频繁连接，哪些领域长期空白，哪些新证据正在挑战旧结论。

AI 的加入又把这项能力向前推进了一步。它可以跨越大量文档寻找相关信息，比较不同阶段的判断，整理项目经验，发现人一时没有注意到的冲突和关联。

这也是我希望 Obsidian 长期承担的几种角色：

• 保存每天进入的信息，并记录它为什么值得保留；
• 连接业务、AI、产品、品牌和个人投资、兴趣等长期领域；
• 保存项目目标、过程、决定、产出与反馈；
• 从真实项目中持续抽象经验；
• 承接文章、方案、产品和研究等输出；
• 为不同 Agents 和 Sessions 甚至人类合作方提供共同上下文；
• 记录内省 self-reflection 和长期认识自己的线索。

这套系统保存了讨论过程，也需要清楚标明当前有效的结论。

三、# 我用「IPO 模型」设计了知识加工闭环

只把资料保存到 Obsidian，知识库很容易变成一个越来越大的收藏夹。

Obsidian 联合创始人 Erica Xu 曾经说：

“I think ‘note-making’ is probably a better name.”

她更愿意把这件事称为“做笔记”或者“生成笔记”。这个区别很重要。资料进入系统只是开始，后面的理解、连接、表达和使用，才决定它会不会形成长期价值。

我在设计自己的知识库时，用了一套 IPO 模型：

Input → Process → Output
输入 → 加工 → 输出

后来，我又在前后加入 Goal 和 Feedback：

Goal → Input → Process → Output → Feedback

为什么做
→ 收到了什么
→ 怎样理解和加工
→ 最终形成了什么成果
→ 真实结果怎样改变下一轮

我举一个具体例子。

假设我读到一篇脑科学论文，把 PDF 或文章链接保存下来，这一步属于 Input。

接下来，我需要判断论文是否可靠，核心发现、洞察、观点、沉淀，哪些内容会改变我日后的判断。这是 Process。

加工以后，它可能变成一篇知识笔记、一个创作设定、一篇公众号文章，或者某个产品项目里的研究结论。这是 Output。

等文章发布、项目落地或判断接受现实检验以后，我还会回来记录：哪里有效，哪里理解错了，下一轮需要修正什么。这是 Feedback。

我的 Goal 就是我开篇（第一章之前表达的部分），这也决定了知识库的框架如何设计。

用「IPO模型」设计知识库的好处是，让这件事的重点从“存了多少”转向“哪些内容真正进入了思考、项目和结果”。

四、为什么我选择 Obsidian 承载长期记忆

我选择 Obsidian，首先看重数据控制权和长期可读性。

本地！本地！本地的 Markdown 文件。这件事对一个需要经常移动（出差）和多端（多手机电脑）的脑力体力工作者来说太友好了。它能让我的所有 Agents无障碍接入、持续输入、提取。以后即使更换再多应用，这些文件仍然可以被其他工具打开和迁移。所以，即便我之前的文档习惯是在飞书上，即便我也努力尝试用 Notion（现已放弃），即便我也用 Flomo、Get 笔记等多端进行信息留存，但最终我都会把重要信息定期整合进 Obsidian 里。

Obsidian 联合创始人 Erica Xu 把它称为：

“Obsidian is the IDE for thought.”

也就是“思考的 IDE”。她在访谈里解释，IDE 可以打开本地的一组纯文本文件，也允许使用者按自己的工作方式扩展环境。更换 IDE 后，同一批文件仍然可以继续使用。

Obsidian CEO Steph Ango 提出的 “File over app” 也表达了类似的长期主义：

“In the fullness of time, the files you create are more important than the tools you use to create them.”

把时间拉长以后，我们创造的文件会比当时使用的工具更重要。

这也是本地知识库 OS 对我最重要的基础：文件由我持有，应用负责提供使用界面，Agent 围绕同一批文件参与工作。

对于经常出差、需要多端查看的人，文件放在哪里也很重要。

我主要使用 Apple 设备，所以把 Obsidian Vault 建在 iCloud。家里的 Mac mini、随身携带的 Mac 和手机都可以访问同一批文件。只要文件已经同步到本地，并且获得相应权限，本地 Agent 也可以继续读取和处理。

其他设备组合可以根据实际情况选择 Obsidian Sync、Google Drive、OneDrive 或其他同步方案。不同方案对桌面端、iOS 和 Android 的支持条件并不相同，选择前需要确认自己的设备路径。

这里有三个需要提前注意的细节：

1. 同一个 Vault 避免同时混用两套同步服务；

2. 需要让常用文件保持在本地可用，避免只留下云端占位符；

3. 同步和备份承担不同职责，重要知识库仍然需要独立、可恢复的备份。

同步让同一批文件跨设备可用，备份负责在意外发生后把它们找回来。

五、# 建目录简单，关键是给所有Agents一份行动说明书

很多人第一次搭 Obsidian，会先寻找一套目录结构。

我现在使用的主体结构大致是：

00-Inbox      等待处理的输入
01-Projects   正在推进的项目
02-Areas      长期积累的知识领域
03-Outputs    已成型或接近成型的成果
04-Daily      日常记录与时间痕迹
99-System     整个知识库的系统规则

Actually，当Agent 真正进入以后，还会继续遇到很多具体问题：

• 一段高质量 AI 对话应该放在哪里？
• 一篇论文摘要属于待处理素材还是长期知识？
• 项目旧方案如何处理？怎么区分？
• 哪份文件代表当前规则？
• 整理原文以后能不能移动或删除？
• 不同类型的笔记应该写成什么结构？

如果这些问题没有共同答案，每个 Agent 都会按照自己的理解行动。时间一长，同一个知识库里就可能出现几套互相冲突的逻辑。

所以我在 99-System 里建立了一套所有 Agent 进入知识库后都要遵循的行动说明书。

第一，定义这个知识库的角色和边界

当前总纲对它的定义是：

它是长期知识、项目认知、方法模型、经验反馈和 Agent 共用上下文的本地知识系统。

项目运行继续留在对应的运行仓和代码仓。Obsidian 保存项目的目标、判断、决定、经验和可复用认知。

第二，规定知识怎样流动

素材先进入 Inbox。正在推进的工作进入 Projects。经过加工、可以长期复用的知识进入 Areas。对外成果进入 Outputs。规则、操作手册和系统说明进入 System。

这种路由让每类内容都有下一步，也让 Agent 知道处理完成后应该写回哪里。

第三，规定 Agent 的阅读顺序

任何 Agent 进入知识库，先读唯一的全局总纲；任务属于某个项目，再读项目总纲；涉及一种具体操作，再读对应的操作手册；需要追溯原因时，最后查看历史设计稿。

知识库使用久了，一定会留下很多旧方案。明确“当前规则优先于历史文档”，可以避免 Agent 找到一份写得很完整的旧设计，又认真地把系统改回过去。

第四，规定不同笔记应该长什么样

资料笔记需要保留来源、核心论点和自己的评论；长期知识笔记需要说清核心判断、推导过程和适用场景；项目笔记需要保留目标、决定、当前状态和下一步；输出笔记还要留下发布后的反馈。

这些模板同时也是写给 AI 的结构化提示词。Agent 看到一种笔记，就知道应该读取哪些字段、补充哪些部分、保留哪些来源和判断。

第五，规定权限和冲突怎样裁决

总纲给出最重要的基础规则。命名、字段、标签、操作步骤和安全边界，再分别放进 Schema、Templates、Runbooks 和 Agent Governance。

目录告诉 Agent 解决 Where（什么内容在哪），System 解决 How （怎样行动）。

这里也是传统「人」用的知识管理与「 AI 原生」知识系统之间很关键的差别。最重要的是要让所有 Agents 懂的规则，一套明确、稳定、可读取的说明。

六、# 想要知识库与 Agents 默契协作，还需要一套契约

规则的数量不决定系统质量。有了总纲也不意味着你就能治理好“一家 Agents 公司”。为什么？我们可以这么理解「人」—— 「知识库」——「Agents」之间的关系：

所以，管理 Agents 就和管理一个真实公司的团队是一个道理，你希望自己的团队怎样与你沟通、提出异议和交付结果，日常工作行为有哪些准则与边界，就可以把这种风格写进协作契约。

在我的这套Agents治理契约当中，有一个非常有趣和一个非常重要的契约，想和大家强调。

第一份：Collaboration Charter，共事契约

这份契约可以很个性化。它也代表了你与人共事和团队管理的风格。

我把 Agent 当作协作伙伴。它可以提出不同意见，指出我的漏洞，提醒我看见风险，也可以在获得授权以后主动推进工作。最终业务边界、优先级、风险和发布决定仍然由我裁决。

我也会在契约里写清楚自己喜欢的协作方式：可以直接讨论问题，可以挑战我的判断，不能为了迎合而模糊风险，也不能把不确定的猜测写成事实。重要决定需要留下可以回看的痕迹。目前实践下来，“坚持己见”这一点，Claude执行的是最好的😁。

这份契约没有标准答案，它是知识库里很有人味儿的一部分。

第二份：Local Safety Protocol，本地文件安全协议

只要 Agent 可以接触本地知识库，就应该明确操作边界。

能读取本地文件，只代表具备能力；能否新建、移动、覆盖和删除，还要服从明确授权。

我把本地操作分成四个等级：

这些规则解决的都是很具体的问题。

我只说“帮我看一下”，Agent 无权自动扩展成“帮我全部修改”；它不能为了看起来整齐，顺手移动任务范围外的文件；涉及密码、密钥、私密聊天记录和其他敏感资料时，默认保持克制。

我现在设计 System 规则时，会遵守几个简单原则：

1. 先写人能读懂的大白话；

2. 同时给出正确做法、常见错误和反例；

3. 按风险区分阅读、新建、移动、覆盖和删除；

4. 明确当前规则与历史文档的优先级；

5. 真实使用中反复出现问题时，再增加新规则。

Agent 知道怎样做事，也要知道什么时候应该停下来问人。

前者影响效率，后者决定我们能否放心地把重要资料交给它长期协作。

七、这套系统可以和 Claude / Codex 一起从零搭出来

看到总纲、模板、IPO 和安全规则放在一起，很多人会觉得：这套系统太复杂了，我怎么可能自己写完？

我自己也经历了多轮迭代。

最早，我只想做一个 AI 知识管理助手，让它帮我扫描文章、提取信息、自动分类和生成笔记。那个版本把重点放在自动化上。后来我发现，只会自动整理仍然不够。书、视频和文章只是信息媒介。项目、长期领域、输出和系统规则承担着完全不同的功能。

第二版开始按知识主题和使用场景重新划分。到了第三版，整套结构才逐渐出现 IPO、笔记类型、标签手册、MOC、输出反馈和 AI Agent 的渐进式角色。它开始承接信息怎样形成知识、成果和下一轮经验。

真正运行以后，我又把复杂蓝图收敛成现在的形式：一份全局总纲作为入口，治理、模板、字段和操作手册按需读取；历史版本继续保留，当前规则拥有更高优先级。

这套系统经历了自动化助手、知识管理系统、IPO 第二大脑和本地知识库 OS 几个阶段。每一轮变化都来自真实使用中暴露的问题。

今天从零开始的人，可以直接让 Claude 或 Codex 成为共同设计者。

第一步，把你的真实生活和工作告诉它

包括你有哪些长期项目，关注哪些领域，日常会收到什么资料，希望形成什么输出，使用哪些设备，会让哪些 AI 参与工作，以及最担心哪些事情发生。

第二步，用 Goal 和 IPO 画出知识流

先列清楚输入从哪里来，经过什么加工，最终需要支持哪些项目或成果，真实反馈怎样进入下一轮。知识流确定以后，再讨论目录。

第三步，先比较方案，再创建文件

让 Agent 提出两到三套候选结构，并解释每一套的取舍。然后拿几个真实样本测试：一篇论文、一段 AI 对话、一个正在开发的项目、一篇准备发布的文章、一条梦境记录分别放在哪里，接下来怎样流动。

第四步，生成第一版 System

这套 System 至少应该包含：唯一总纲、目录职责、阅读顺序、几种核心笔记模板、当前规则与历史文档的优先级，以及 Agent 的协作方式和安全边界。

第五步，人确认以后，再让 AI 落盘

Agent 可以进入本地 Obsidian Vault，创建文件夹、模板和说明文档。移动旧文件、覆盖内容或删除资料需要单独确认。

你可以先用下面这段指令开始：

我想建立一套自己和多个 AI 都能使用的 Obsidian 知识库。

请先保持只读，不要创建、移动、覆盖或删除文件。

第一步，请访谈我：
1. 我有哪些长期目标和正在推进的项目；
2. 我长期关注哪些知识和兴趣领域；
3. 我日常有哪些信息输入；
4. 我希望形成哪些输出；
5. 我使用哪些设备和 AI 工具；
6. 哪些本地文件操作必须先向我确认。

访谈结束后，请用 Goal → Input → Process → Output → Feedback
画出我的知识流，再给出两套不同复杂度的目录和 System 规则方案。

每套方案请说明取舍，并用三个真实样本测试。
得到我的明确确认后，才可以创建文件。

未来，我也会把自己多轮讨论、踩坑和实际运行后形成的逻辑，整理成一个可以直接领取的 Skill。

这套 Skill 会先理解使用者的工作、输入、输出、设备和协作偏好，再生成适合个人的 IPO、知识库结构、总纲、笔记规则和安全协议。

总结：先为自己建立一份可持续的长期知识库系统

以上是我建立自己长期知识库OS的前10%进度分享。

如果你准备从零开始，可以先做一件很小的事：

把上面这段话喂给你的聪明模型，然后根据它的提问，逐个口喷。这样，就可以开始讨论出第一版结构。

人负责目标、意义和最终判断。Obsidian 保存长期知识、项目历史和共同规则。Agent 海量阅读、调研、加工和执行。「IPO模型」让每一次知识沉淀累积成长期经验与价值。

这几部分长期配合，形成你和你的AI军团们共享的长期上下文。只有拥有了这个人机协同的第二大脑，下一步才可能继续升级成一个真正的 AI-native 自我迭代的组织。

写到这，你会发现这样一套结构非常像公司组织的治理模式。一家公司的AI-native化，不只是给员工采购 AI 工具、做 AI 培训，更需要企业一号位自己先实现一次升级。

他要先把公司的目标、判断、规则和经验，从只存在于自己脑子里的东西，变成人和 Agent 都能理解、调用和持续修正的系统。

当这套系统先在一号位身上跑通，它才有可能进一步进入总经办，进入团队管理，最后变成整个组织的人机协同能力。

接下来，我会用三章九篇，继续拆解这条路径：

第一章，一号位怎样建立自己的第二大脑；

第二章，怎样把它升级成一套 Agent 总经办；

第三章，怎样让个人实践扩展成 AI-native 组织。

如果你是公司的创始人、CEO、总经理或业务一号位，也正在思考怎样让 AI 真正进入管理和决策，欢迎告诉我：

你现在最希望 AI 帮你解决的，是企业内部的信息过载、降本增效、决策支持，还是团队协同？