TL;DR: Obsidian 加 Claude Code 是我们见过的最适合 FDE 工作的单人第二大脑，本文如实描述了这套配置。一旦团队存在，它会在四个地方出问题：共享（所有协作者都获得库所有者的权限）、第二编辑者（同步合并冲突）、不在 Obsidian 里的读者（销售、管理者），以及漂移（没人负责对账）。知识工作者每周已经浪费 5.3 小时等待或重建知识。将客户状态迁移到共享大脑的团队，在 Spendesk 的上线周期缩短了 3 周。

Obsidian 第二大脑是 FDE 工作最接近民间传统的东西。一个库、每个客户一个文件夹、Granola 会议记录自动导入、Claude Code 读写 markdown。运行这套配置的人不是为了折腾而折腾。他们因此交付得更快，而且当我们与前沿部署工程师交流时，这套配置比其他任何技术栈都更常被主动提起。

所以这不是一篇批判文章。单人使用时，这套配置是有效的，我们会先讲清楚为什么，再谈别的。麻烦恰恰从麻烦总是开始的那一刻出现：当第二个人需要你库里的东西时。一家垂直金融科技公司创始 FDE 毫不掩饰地告诉我们：“最重要的问题是，我无法把 Obsidian 大脑分享给其他人。”

接下来是这套配置的真实面貌、它在团队场景中失效的四个地方（附 Obsidian 官方文档对每一处的说明），以及团队级版本的工作流是什么样的。

真正有效的单人配置

在讲断点之前，先讲配方。如果你是单人 FDE，读完这一节就停下，你也会有所收获。

  • 一个库，每个客户一个文件夹。 每个客户的每个承诺、决策和待解决问题都放在其文件夹里。每日笔记充当记录何时发生何事的账本。
  • 把会议记录导入进来。 Granola 或你选择的录音工具把通话记录放进客户文件夹，让原始记录与你的解读放在一起。
  • 让 Claude Code 读写这个库。 把它指向 markdown，它就能总结通话、起草跟进内容，并从你自己的笔记中回答“关于 API 迁移我们跟他们说过什么”。
  • 在上下文用尽之前进行压缩。 会话中的经验会作为迁移笔记写回库里，让下一次会话带着热身状态开始。

本地优先、纯 markdown、没有供应商介入。这些是真实的特性，也是人们喜爱它的原因。但每一个特性在构造上都是单人模式的，这正是四个断点的来源。这就是共享上下文问题所源自的个人大脑技术栈。

断点一：与团队共享 Obsidian 库可行吗？

Obsidian Sync 具有共享库功能，其官方文档也坦率地说明了它的局限。根据协作文档，目前尚不支持细粒度权限，所有协作者获得的权限与库所有者相同。你邀请的每个人都可以编辑、重命名或删除任何内容。同一页面还规定共享库最多支持 20 名协作者。

对于个人知识库来说，这是一个合理的取舍。但对于记录对付费客户的承诺而言，对所有笔记全有或全无的写入权限则是另一回事。没有办法让销售读取承诺内容而不让他们也能编辑。大多数团队的应对方式是干脆不共享库，这也正是大脑始终停留在个人层面的原因。

断裂点二：第二个编辑者

假设你还是共享了。第二个 FDE 加入该客户，打开库，开始写内容。Obsidian Sync 不支持实时编辑，并发更改会在库同步时合并。两个人在同一天下午编辑同一条客户笔记，就会产生一次合并，而关于客户状态的合并后的文字，谁也不能代表事实真相。

更深层的问题不在于合并机制，而在于所有权。在单人库中，每句话都是你写的，所以你完全信任它。一旦出现两个作者而又没有核对步骤，你就无法完全信任其中任何内容。一家约 50 人的 AI 公司的 FDE 团队负责人描述了这条路的尽头：“我搭建过，比如说，Obsidian、一个 Wiki，还有 Git […] 而这随之带来了维护成本。”自建还是购买共享上下文层的账，主要就是这笔成本——只要诚实地计算。

断裂点三：不在 Obsidian 里的读者

你的经理没有你的库。销售没有 Obsidian。接手构建工作的工程师拿到的是代码仓库，而不是你的日常笔记。那位无法共享大脑的金融科技 FDE 还指出了问题的另一半：销售人员不用 Claude Code，所以任何藏在你工具背后的东西对他们来说都形同不存在。

Claude Code 自身的记忆模型也救不了这一点。文档明确指出自动记忆是机器本地的，文件不会跨机器或云环境共享。你的会话中了解到的客户信息只留在你的笔记本电脑上，我们在 Claude Code 团队记忆一文中拆解了这一限制。而且还有一个开放的功能请求，要求 Anthropic 提供跨 Claude Code、Cowork 和 Claude.ai Projects 的共享层，正是因为目前并不存在这样的东西。结果是，你的设置之外的每个读者都得通过你来获取答案。2018 年 Panopto 研究统计的每周 5.3 小时等待或重建知识的时间，在 FDE 团队上，大部分就耗在这种转接上。

断裂点四：漂移，或者说库与现实

最安静的一种断裂。笔记描述的是你写下它们时的实现状态，而实现仍在继续演进。一位在保险理赔平台工作的 FDE 从内部描述过这一点：“Obsidian 里的内容和真实实现所代表的东西开始渐行渐远。”

没有任何东西会标记这种情况。检索仍在“正常工作”——也就是说，Claude Code 依然自信地从知识库中给出回答。一项针对 RAG 系统的从业者分析发现，概念验证之后 60% 的失败都源于数据新鲜度，而非检索质量，而且一个系统可以在标准指标上得分很高，同时返回的信息早已过时数周。知识库也有同样的失败模式，只是指标更少。

我们自己从合作团队中得到的观察是：一个常规的大脑（Obsidian 之类）会在 500 到 1,000 条事实之间开始漂移。低于这个规模，一个人可以在头脑中记住笔记与现实之间的 Delta；超过这个规模就记不住了，而且没有人会注意到这一刻的发生。我们在自建大脑中的上下文漂移一文中写明了其中的机制。

Obsidian、共享知识库与项目大脑的对比

  • 谁能读取。电子表格 + Slack：理论上所有人。Obsidian 单人知识库：只有你。Obsidian 共享知识库（Sync）：最多 20 位协作者。项目大脑（如 Tandem）：整个团队，外加通过 Tandem MCP 接入的 Agent。
  • 权限。电子表格 + Slack：混乱但熟悉。Obsidian 单人知识库：仅你所有。Obsidian 共享知识库（Sync）：所有人拥有与所有者相同的权限。项目大脑（如 Tandem）：可配置，天生支持多人协作。
  • 并发编辑。电子表格 + Slack：Slack 讨论串会分叉。Obsidian 单人知识库：不需要。Obsidian 共享知识库（Sync）：没有实时编辑，同步时合并。项目大脑（如 Tandem）：多人同时向同一个大脑写入。
  • 工具外的读者。电子表格 + Slack：可以，这正是它的吸引力所在。Obsidian 单人知识库：不行。Obsidian 共享知识库（Sync）：不行。项目大脑（如 Tandem）：Claude 聊天、Slack、随处交付简报。
  • 新鲜度。电子表格 + Slack：在手动更新之间会过时，因团队而异。Obsidian 单人知识库：取决于你的自律程度。Obsidian 共享知识库（Sync）：没有人负责对账。项目大脑（如 Tandem）：从通话、Slack、会话中同步，漂移会作为风险浮现出来。
  • 维护成本。电子表格 + Slack：隐藏在每个人的时间里。Obsidian 单人知识库：由你承担，且无法量化。Obsidian 共享知识库（Sync）：由你承担，外加合并清理。项目大脑（如 Tandem）：由产品维护，你只需审阅。

公平地把各方案摆在桌面上。电子表格加 Slack 完全不需要任何采用成本，这是任何工具都无法比拟的真实优势。Obsidian 的本地优先、纯 Markdown 模式带来了任何托管方案都无法比拟的可移植性和隐私性，对于单人使用者来说，这些优势可能足以盖过上述所有断裂。基于 Notion 或 Airtable 的自建大脑则介于这几列之间。

团队级版本保留了什么

你搭建的工作流方向是对的：记录一切，把解读放在证据旁边，在工作的位置直接查询。一个项目大脑保留这些习惯，并改变存储方式。在 Tandem 的客户大脑中，事实都带有来源链接，多人可以同时向同一个大脑写入，并配有可配置的提醒，而且大脑通过 AI 聊天界面来编辑，而不是靠手动维护 markdown。Claude Code 依然参与其中，因为同步会把你在会话中选择的内容推送过去，而风险检查会把同一份记忆读取为一份风险清单，每条风险都附带说明、原因和来源。

差别体现在其他人的早晨。在 Spendesk，一位工程师接手任何客户账户，五分钟内就能知道承诺了什么、哪些有风险，用 Mathilde Hamy 的话说，“没有人需要维护任何东西”。在 Aircall，工程团队先经历过自建版本。资深工程师 Paul Yi 说：“我们试过自己搭建，但没能撑住。”这个故事，包括最终什么方案撑住了，见 Aircall 如何在共享大脑上运行交付。

仍然需要手动完成的部分

一份诚实的账目，因为知识库用户对“魔法般的宣称”理应保持警惕。

进入大脑的内容仍由你决定。从 Claude Code 会话同步时，只推送你选择的内容，而 Agent 提议的更新在写入记录前需要人工批准。你对客户的理解，以及判断延期是风险还是节奏，这类判断无法从任何系统迁移过来，我们的系统也不例外。如果你保留一个用于思考的个人知识库，团队大脑并不能取代它，我们的许多用户两者都用。另外，迁移现有知识库是整理，而不是导入。持久的事实会在一两周的日常客户工作中迁移过来，而那两百条每日笔记仍然属于你。

保留第二大脑，也给团队配一个

Obsidian 在 FDE 工具栈中赢得了自己的位置，单独使用时它可能仍是正确的选择。四个断裂点其实是同一个断裂点的不同侧面：为一个人构建的大脑只对一个人负责。一旦有第二位 FDE、经理或工程师需要了解客户账户的状态，答案就是一个共享的、带来源链接的记忆，他们无需经过你就能查询——这正是 Tandem 为 FDE 团队所构建的。在演示中查看 Tandem 如何为你一个正在进行的实施项目标记风险。

常见问题

我可以和团队共享一个 Obsidian 知识库用于客户工作吗？

技术上可以，通过 Obsidian Sync 最多支持 20 人。但实际上，每个人都会获得知识库所有者的完整权限，没有实时编辑，并发编辑会在同步时合并。对于客户账户状态这种需要区分读写权限、且两人可能同时编辑同一账户的场景，大多数团队认为这些限制足以将其排除。Obsidian 的文档本身也说明了这些限制。

要获得团队记忆，我必须放弃 Obsidian 吗？

不是。我们观察到的有效模式是：个人思考用 vault，账户状态用共享大脑。Claude Code 可以把选定的会话成果推送到团队大脑，而 vault 仍保持为你的私人工作空间。改变的是：承诺、决策和风险不再只存在于你的 markdown 里。

我怎么知道我的 vault 已经出现漂移了？

大多数时候你不知道，这正是问题所在。信号是行为上的：你开始在向客户复述之前，先拿 Slack 上的信息反复核对 vault 的答案。根据我们的经验，这种情况大约在 500 到 1,000 条事实之间开始出现。团队大脑会把漂移以带来源的排序风险形式呈现出来，而不是等你自己去发现。

如果我是唯一的 FDE，这套设置还值得搭建吗？

值得，即使我们卖的是另一种方案，我们也会这么说。就单人而言，Obsidian 加 Claude Code 的设置快速、私密、完全属于你。需要重新考虑的时机是：当第二位 FDE 入职、有工程师需要你的上下文，或者经理开始要状态汇报时——因为事后给个人 vault 补上共享能力，恰恰是撑不住的部分。

关键术语

第二大脑：一种个人知识系统，在此语境下指存放 FDE 账户笔记、会议记录和决策的 Obsidian vault。

共享上下文：整个团队及其 Agent 都可以查询的账户知识。团队记忆是同一个概念。个人第二大脑是它的单人版前身。

前沿部署工程师：前沿部署工程师是指大约一半时间与客户在一起理解问题、另一半时间针对该特定客户构建解决方案的工程师。

上下文漂移：知识库所记录的内容与当前事实之间不断扩大的差距，其危险在于检索功能依然正常，而答案却已经过时。

项目大脑：由团队而非个人维护的、经过对账且附带来源链接的账户状态记录（已承诺、已决定、有风险、下一步）。

Tandem MCP：Tandem 的 MCP 服务器，让 Claude、Claude Code 或 ChatGPT 可以查询账户大脑，从而使 vault 工作流中最好的习惯（在你工作的地方查询你的笔记）在迁移到团队记忆后得以延续。