如何用 Fable 5 搭建第二大脑（译）

如何让 AI 真正理解你的业务、你的语气、你的历史判断和你的知识资产？

这篇文章不仅是停留在“第二大脑”这个概念上，而且把它拆成了一套可以执行的系统：用 Obsidian 存放原始材料，用 raw / entities / concepts / INDEX.md 搭出结构，用 agent 持续编译、更新、清理，再把这套知识库接进你的工作流里。

我尤其喜欢它强调的一个判断：模型能力当然重要，但很多时候，真正拉开差距的不是模型本身，而是模型读到了什么。一个没有上下文的强模型，可能只能产出普通内容；一个接入你长期积累知识库的模型，才有机会变成真正懂你的人和业务的助手。

所以这篇文章值得看，不是因为它介绍了某个新工具，而是因为它提供了一种新的 AI 使用范式：不要把 AI 当成一次性问答工具，而是把它接到你持续增长的知识系统里，让每一次输入和输出都变成未来输出质量的一部分。

原文：https://x.com/EXM7777/status/2073045719020343705

作者：Machina

我会一步一步给你看，怎么把 Fable 5 变成一台真正懂你业务的机器。它最后交付出来的东西，会和别人拿到的完全不是一个档次。

这个工具，就是一个建在 Obsidian 里的第二大脑。已经有一小群人在跑同一套系统了：模型一样，但输出结果差得很远。

市面上最聪明的模型，为什么一天到晚产出平庸内容？原因很简单：它根本不了解你。

它不知道你的业务，不知道你的受众，也不知道你过去做过哪些决定。于是它只能猜。猜出来的东西，当然就很普通。

把它接到你自己的知识库上，同一个模型就会变成另一台机器。

代码会顺着你的架构写，内容会像你本人说的话，文章会建立在你自己的研究积累上。从第一天开始，你就能看出差别。

这对任何工作流都成立：写代码、做营销、做内容、做销售、做研究。

没有第二大脑就去跑 AI agent，就是在浪费时间。而且差距只会越拉越大，因为这个大脑每多吃进一个文件，之后每一次运行都会更聪明。

我每天都在用这套系统。我的每一篇文章、每一份指南、每一个产品，背后都有它。

下面是完整系统：第二大脑到底是什么；agent 能自己读懂的文件夹结构；如何用目标把它填起来；如何用循环让它持续更新；如何在它上面跑一台真正的研究机器；如何不烧钱地读取它；以及如何把它接进你正在构建的一切东西。

同一个模型，不同的段位

先看数据。

在会计场景里，一个不了解客户历史的模型，准确率大概在 70% 左右。

给它客户的交易历史之后，起点就会来到 85%，随后还能爬到 90% 以上。

模型本身没有变，变的是知识。

写作也是同一个道理。

一个中等水平的模型，只要配了一份足够好的声音档案，写出来的东西就会比裸跑的 Fable 5 更像你。

很多时候，决定结果的不是模型等级，而是它读到了哪些文件。

而且这个模型本身，对这件事的回报比过去任何模型都更强。

Anthropic 自己的测试里，让 Fable 带着基于文件的记忆去玩一整局卡牌构筑游戏，它的进步幅度是上一代旗舰模型的三倍多。

只是一个游戏，还是厂商自己的测试，目前也还没人复现。但这个数字指向的动作，成本不过是建一个 markdown 文件夹，所以不管怎样都值得做。

开始搭建之前，我必须先说清楚一件事：模型不会神奇地翻出你笔记里的每个细节。

它真正做的是，调用对话之外的知识，并标明每条信息来自哪里。

记忆属于你。它在你的硬盘上，是你能打开、能阅读的纯文本。

跑上几个星期，agent 就会开始引用一些你自己都忘了的旧决定。

第一个问题是：这份记忆应该放在哪里？

答案不要钱，而且你可能已经装好了。

一分钟讲清楚 Obsidian 是什么

Obsidian 是一个免费 app。它本质上是给你电脑上的一整个 markdown 文件夹套了一个界面。

没有数据库，也不会把你锁在某个云服务里。你的笔记就是你自己拥有的纯文本文件，Obsidian 只是一个好看的窗口。

你只需要用到它的两个功能：

wikilinks：在任意笔记名外面输入双中括号，两篇笔记就连接起来了。

graph view：Obsidian 会把每篇笔记画成一个点，把每条链接画成一条线，于是你能直接看到自己的知识网络。

它也非常适合 agent，因为 vault 本质上就是一个文件夹。Fable 可以通过 Claude Code 直接操作它，也就是模型在你电脑上运行时用的那个终端 app。

不需要插件，不需要连接器，也不需要特殊设置。agent 负责读写 markdown 文件，Obsidian 负责把变化展示给你看。

你用 app，agent 用文件夹。你们看的其实是同一个大脑。

在你开始担心这会不会是个大工程之前，我先说结论：这篇文章里的东西，做一个启动版大约一小时就够了。一旦读取规则设置好，跑起来也花不了几个钱。钱的问题后面单独讲。

真正把“大脑”和“一堆文件”区分开的，是结构。而结构，正是大多数人最容易搞错的地方。

结构：四个部分，就这些

这个思路来自 Karpathy 的 llm-wiki：把你的知识库当成一个代码库来维护。

Obsidian 是编辑器，模型是程序员，wiki 是代码。

我看了很多公开 setup、代码仓库、爆款模板和失败案例，最后反复出现的只有四个部分：

raw - 你捕获的一切都原封不动放在这里：文章、转录稿、会议记录、竞品页面。这里是只读历史，agent 永远不改写。

entities - 每一个具体事物一页：一个客户、一个竞争对手、一个工具、一个人。

concepts - 每一个想法一页：一个策略、一个模式、一个教训。

INDEX.md - 入口页：每一页都列在这里，并配一句话说明。这样 agent 不用打开所有文件，也知道库里有什么。

agent 的工作就是编译：读取 raw/ 里的新材料，更新 entity 和 concept 页面，并顺手把它们链接起来。

写作规则也简单到四行就能说完：

一个文件只放一个教训，顶部写一句话总结。

更新已有页面，不要创建重复页面。

发现错误的笔记就删除。

永远把原始来源和编译后的页面分开。

为什么 raw/ 必须保持原样？因为当同一个 agent 一遍又一遍读取、改写同一批笔记时，细节会慢慢变糊，错误会一层层叠上去。

raw 文件夹是你的原始凭据。wiki 则是在这些凭据之上不断变聪明的知识层。

而页面只是一半价值。真正的优势藏在页面之间的链接里。

知识图谱：为什么它会越长越强

agent 写下的每一个 link，都是图谱里两页之间的一条连接。

这就是 vault 和一堆笔记的区别：靠搜索的知识库，会随着规模变大越来越吵。文件越多，每次搜索混进来的噪音也越多。

带链接的 wiki 则会随着增长变得越来越强。每个新页面都会接入网络，也会让周围页面变得更有用。

当 agent 需要回答问题时，它不会把所有文件扫一遍。它会沿着链接走。

从客户页面走到活动策略，再走到竞品页面。它顺着连接前进，就像你自己顺着记忆往下想。

Karpathy 自己的 vault 大约有 100 篇文章、40 万字，全部由模型编译，全部互相连接。

这样跑两周之后，打开 graph view，你会看到自己的业务变成一张活地图。光是那张图，就会改变你理解自己知识资产的方式。

那么，怎样填充它，而不用花一个月复制粘贴？

用目标填充它

第一步是回填。Fable 的 goal system 正是为这类工作准备的。

Claude Code 里的 /goal 允许你写下一个终点，然后模型会自己持续工作。同时，另一个更小的模型会在旁边当裁判，边读边判断这个终点是否已经达成。

关键在于，裁判只能看到对话里的内容。所以这个 goal 必须要求 agent 给出它能读到的证据：

运行之前，先把你已有的东西全倒进 raw/：旧聊天记录、收藏过的 thread、笔记 app 导出、客户文件夹、过去的研究。

然后你可以走开。回来时，就会看到一个已经编译过的第二大脑。

两条规则可以让回填保持诚实：

每一次改动都必须以 diff 交付，也就是精确的前后行变化，而不是一句口头声明。agent 如果说它更新了某个页面，diff 必须能证明它确实更新了。

任何没有 source link 指回 raw/ 的页面，都要先标记起来，不要直接相信。

回填会交给你一个编译好的大脑。但让它持续活着，是另一件事，也是大多数人会跳过的那件事。

用循环让它活着

一个只有在你想起来喂它时才增长的第二大脑，三周后基本就废了。

所以维护要靠日程，而不是靠记忆：

每次会话结束后：一个 hook，也就是一个小脚本，会在会话结束时自动触发，挖出刚刚发生的事：做过的决定、发现的错误、确认过的模式，然后把它们写成带日期的笔记放进 vault。你已经做完的工作，会在不需要手动归档的情况下变成记忆。

每天晚上：用便宜模型跑一次 compile pass，读取当天新增的 raw material，更新 wiki 页面。常规工作，就用常规档位。

每周一次：跑一次 lint pass，寻找矛盾、重复页面和死链接。这个循环负责保持图谱干净，因为没人维护的 wiki 一定会烂掉。

每周一次：用大模型跑一次 synthesis pass，横向读完整个 vault，写下这一周发生了什么变化、哪里开始跑偏、什么值得关注。

最后这一项，是唯一一个真正值得让高级模型上场的环节。

其他事情都应该跑在便宜档位上，因为更新笔记只是常规工作。把常规工作丢给 Fable 做，就是很多人白白烧钱的方式。

维护能让 vault 保持干净。但真正有价值的材料从哪里来？

喂养它的研究工作流

从这里开始，vault 不再只是存储工具，而会变成你的优势。同时，这也是垃圾最容易混进来的地方。

默认的 AI research 是丢给聊天机器人一个 prompt，然后答案就埋在聊天记录里。

更糟的是，它往往建立在过时知识之上。尤其在 AI 领域，六个月前的建议可能已经完全错了。真正的一线实践信息，也就是大家现在在跑什么、哪里会坏、什么真的有效，通常在社交平台上，而不是官方文档里。

所以研究机器应该这样工作：

输入一个问题，然后把它拆成 3-5 个子问题。

并行 agent 分头出去找，每个 agent 负责不同渠道：社交平台负责一线实践，网页负责文档和价格，scraper 拉取所有值得阅读内容的全文。

每个发现都要变成一张收据：结论、来源链接、日期。

然后经过真正的关口：一个 skeptic agent 会攻击每一条结论，试图把它推翻。单一来源的 hype 会被标记出来，互相矛盾的说法会被摆到桌面上，只有经得起攻击的内容才能通过。

经过验证的发现，会作为页面落进 vault。每一页都有日期和链接，每一页都带过期时间。这样知识一旦过时，会自己冒出来提醒你。

我自己跑的具体技术栈是：

last30days powered by ScrapeCreators (scrapecreators.com)：一个 skill，可以在 reddit、X、youtube、instagram 和 tiktok 上扫描任意主题过去 30 天的一线讨论。

官方 X MCP (api.x.com/mcp)：直接从源头获取实时帖子、threads 和 bookmarks。

用 yt-dlp 获取 youtube transcripts (github.com/yt-dlp/yt-dlp)：任何 walkthrough 或 tutorial 都能变成 agent 可以挖掘的文本。

通过 ScrapeCreators 获取 instagram 和 tiktok 内容，因为短视频平台往往是新工作流最早冒出来的地方。

Perplexity deep research (perplexity.ai)：做一轮带引用的全网长文研究。

Firecrawl (firecrawl.dev)：把每个值得保存的页面全文拉下来，转成干净的 markdown。

MPH_MARKER_6

skeptic 才是把研究和谣言收集区分开的东西：一个带着新上下文进来的检查者，通常比模型回看自己的工作更可靠。所以攻击永远来自一个没有参与前面研究的 agent。

每周在你的 niche 上跑一次，vault 里就会不断积累经过验证、有日期、有来源的情报。这些东西，正是竞争对手缺的。

不过，如果读取 vault 的成本超过它带来的回报，一切都没有意义。

不烧钱地读取它

一个 vault 想长期运转，读取成本必须足够低。而这正是几乎所有 setup 都在漏钱的地方。

你可以这样理解：context window 是一个很贵的房间，所有被搬进房间的东西，都要按 token 付费。token 就是 AI 账单里用来计数的文本块。

你的 CLAUDE.md，也就是 agent 每次会话开始时读取的 instruction file，会自动加载，而且每次都会加载。这就是永远要交的税。把它控制在 200 行以内，让它指向 vault，而不是把 vault 本身塞进去。

其他所有东西都是 pay-per-read：agent 检查 INDEX.md，沿链接走，用关键词 grep，只打开线索指向的页面。整文件夹扫描，是绝对不该发生的动作。

遇到大问题，就派一个 worker：让一个 subagent 在它自己的独立 context 里读取 50 页，然后只把一段结论返回到你的会话里。那个很贵的房间，应该用来装决策，而不是装整座图书馆。

MPH_MARKER_7

把它接进你构建的一切

一个只负责存东西的 vault，只是文件整理爱好。这里说的这个，会反过来喂养你正在做的每个项目。

在任意项目的 CLAUDE.md 里加三行，就能让项目读到它：

knowledge

• before starting, read the relevant pages from ~/vault/entities/ and ~/vault/concepts/
• ground every claim about our business, clients or audience in a vault page

输出会立刻变样：

marketing：campaign brief 会建立在你真实的受众页面和竞品历史之上，而不是泛泛而谈的人设。

content：草稿会引用你过去的研究，也会贴合你的 voice profile。

coding：agent 会为每个项目持续维护 living architecture notes，所以每次新会话都不必从零开始摸索。

client work：每一份交付都会带着完整的客户关系历史展开。

然后还有另一半：vault 本身会变成产品。

research pages 可以变成文章和指南，concept pages 可以变成课程，client pages 可以变成案例研究。你不再从空白页开始创作，而是在包装这台机器已经验证过的东西。

最后一个提醒，能救你的 vault：同步，往往就是 vault 出事的地方。

只用一个同步系统。如果 agent 写文件的时候 iCloud 也在同步，你很可能会得到一堆冲突副本和被打乱的文件夹。

git，也就是程序员用的 save-point system，可以作为 checkpoint layer。它只会在你明确告诉它的时候锁定一个版本，这种 setup 才扛得住。

卡片

整套构建流程，按顺序来。直接复制：

创建 vault：raw/、entities/、concepts/ 和一个 INDEX.md。

把四条规则写进你的 CLAUDE.md：一个文件一个教训；更新而不是重复；删除错误内容；永远不要碰 raw/。

把你已有的一切倒进 raw/：转录稿、收藏、笔记、客户文件夹。

运行 /goal backfill，要求它粘贴证据，并写清楚停止条件。

安排循环：session hook、便宜档位的 nightly compile、weekly lint、一次 premium synthesis pass。

跑每周研究扫描：分头搜索，让 skeptic 攻击，把经得起攻击的内容作为带日期的页面落库。

给每个项目的 CLAUDE.md 加上那三行 knowledge 规则。

掌舵的模型以后还会继续换。vault 会扛过每一次更换，而写进其中的反馈，会让它每周都变得更聪明，不管最后是谁在跑。

最小版本只需要一小时：一个文件夹，十个关于你业务的文件，再告诉 agent 先读它们。

你的输出会告诉你剩下的答案。