如何构建一套 Opus 5 + Obsidian 研究系统，每周节省数小时的手动阅读时间

大多数研究工作并非思考，而是阅读、提取和交叉引用，这些工作都是手动完成的，一次处理一个来源，吞噬了本应用于实际思考的时间。

Opus 5 之所以能改变这一局面，正是因为它专为此而生。Anthropic 将其定价与 Opus 4.8 相同，每百万输入 token 5 美元，每百万输出 token 25 美元，同时在 Frontier-Bench v0.1 上的得分比 Opus 4.8 翻了一倍多。它明确不定位为 Anthropic 最智能的模型——那仍然是 Fable 5——而是定位为日常使用的模型，其效率在数千次调用中不断累积，这是单个基准测试标题永远无法体现的。法律 AI 公司 Harvey 独立报告称，在达到与 Opus 4.8 最大推理输出质量相当的情况下，平均使用的 token 减少了 26%。

这种效率特性正是研究流水线所需要的。你不是在运行一次深度、昂贵的查询，而是每周都在不断增长的大量来源中运行数十次提取和合成遍历，如果使用的模型不是为高吞吐量而设计的，那么每次遍历的成本会迅速累积。

这是一个完整的系统：Obsidian 作为永久存储，Opus 5 作为处理引擎，以及一个特定的流水线，将原始阅读材料自动转化为可链接、可查询的知识，这样你过去手动提取和交叉引用所花费的时间就能返还给你。

为什么 Opus 5 特别适合这项工作

在开始构建之前，有必要精确说明为什么这个系统使用 Opus 5 而不是 Fable 5，因为为此特定工作选择错误的模型是人们在这种系统上超支的最常见原因。

每周摄入来源的研究流水线会运行大量单独的模型调用：对每个新来源进行提取，与你现有笔记进行交叉引用，定期合成遍历，生成摘要。这是数量驱动的工作，而非单次深度工作。Opus 5 的整个定位正是围绕这种模式构建的——在相同价格下，Frontier-Bench 得分比 Opus 4.8 高出一倍以上，并且 Harvey 在重复的、类似的任务上独立验证了 token 效率提升。

Fable 5 仍然是处理真正最困难单一研究问题的更好选择——那些微妙、高风险的合成，一个细微的错误可能产生实际后果，并且其更高的 SWE-Bench 相关推理深度值得大约 2 倍高的每 token 价格。对于构建和维护研究系统的常规重复工作——每周摄入、持续提取、摘要生成——Opus 5 的效率优先设计是正确的默认选择，而 Fable 5 则保留给系统偶尔提出的、值得额外仔细审查的深度探究问题。

基础：Obsidian 作为永久存储

系统需要一个永久存储知识的地方，完全属于你，且永远不依赖任何单一模型或提供商。Obsidian 仓库中的纯 Markdown 文件正好做到这一点。如果明年出现更好的模型，你只需将其指向同一个文件夹，其他一切都不变。

适用于研究系统的特定结构，基于通用的 raw 和 wiki 模式：

• 一个 raw 文件夹，用于存放完全按原样摄入的源材料：PDF、文章文本、视频转录、未处理的内容。
• 一个 wiki 文件夹，用于存放处理后的、已链接的、永久版本的知识，按主题而非来源组织。
• 一个 questions 文件夹，专门用于研究系统，存放阅读中浮现但尚未解决的开放问题，这样真正重要的问题就不会在处理过程中丢失。
• 一个 digests 文件夹，存放 Opus 5 生成的每周摘要，带有时间戳，这样你可以回顾任何一周的重要信息，而无需重新阅读所有内容。
• 根目录下一个 CLAUDE.md 文件，精确定义该系统应如何运行，下一节将详细介绍。

运行系统的 CLAUDE.md

这是整个设置中杠杆率最高的单个文件，因为 Opus 5 在每次会话开始时都会自动读取它，这意味着你只需编写一次指令，而无需每次使用时重新解释系统。

1研究系统协议
2
3该仓库是一个研究系统。结构：
4
5/raw - 源材料，完全按原样摄入，绝不编辑
6/wiki - 处理后的、已链接的知识，按主题组织
7/questions - 尚未解决的开放问题
8/digests - 每周摘要，带时间戳
9
10当新来源被放入 /raw 时：
11
121. 提取具体、真正新的主张和发现，而非整个文档的摘要。
132. 检查 /wiki 中已有的关于同一主题的笔记。如果该主题已有笔记，则扩展现有笔记，而非创建重复。
143. 使用 [[wikilinks]] 将每个新主张与相关现有笔记链接。
154. 如果某个主张与 /wiki 中已有内容相矛盾，不要静默覆盖。在两个笔记中明确标记矛盾。
165. 如果某个来源提出了一个你无法从仓库中其他已有材料解决的真正开放问题，则将其添加到 /questions，而不是猜测答案。
17
18当被要求合成或生成摘要时：
19
20从 /wiki 中提取，而非直接从 /raw 中提取。wiki 是经过处理的可信层。原始源可能包含后来被发现错误或已被取代的主张，这就是上面第 4 步存在的原因。
21
22在报告任何提取完成之前，确认你确实检查了 /wiki 中现有的相关笔记，而不是假设这完全是新材料。

这个文件是区分一个由互不关联的笔记组成的文件夹与一个实际系统的关键。其中的每条指令都是为了防止特定的、真实的失败模式——重复笔记、静默覆盖的矛盾、悄然丢失的未解决问题——这些模式在使用数月后会在不知不觉中累积。

摄入流水线

有了仓库结构并编写好协议后，以下是实际的每周工作流程。

• 在一周内遇到任何来源时，将其放入 /raw：你阅读的一篇文章、一篇研究论文、播客转录、视频转录、竞争对手的博客文章。这应该只需几秒钟，而不是几分钟——关键在于消除捕捉时的摩擦，这样你才能真正持续地做到。
• 摄入 /raw 中尚未处理的新文件。

对于每个文件，提取真正新的主张，检查 /wiki 中已有的相关笔记，根据需要扩展或创建笔记，并标记与已有记录的任何矛盾。将未解决的问题添加到 /questions，而不是猜测。

• 按照你实际阅读模式适合的频率运行此操作：如果你经常阅读，则每天运行；如果你的输入更零散，则每几天运行一次。关键在于处理发生在你实际捕获来源之后不久，因为一次性将十个来源的批次分解为单独的提取和交叉引用遍历，正是 Opus 5 效率特性所擅长的重复、相似形状的工作。

每周摘要，自动化

这是实际节省时间最明显的地方，值得将其设置为定时任务，而不是你记得手动运行的东西，因为整个系统的目的在于将你从机械性部分中解放出来。

1生成本周的研究摘要。从 /wiki 中提取，特别关注过去 7 天内添加或更新的内容，而不是整个仓库的历史。
2
3结构：
4
51. 本周 3 到 5 个最重要的新发现，附有 /wiki 中完整笔记的链接。
62. 本周标记的新材料与现有笔记之间的任何矛盾，因为这些值得你直接关注。
73. 本周添加到 /questions 但仍未解决的开放问题。
84. 一句话说明本周任何活动异常频繁的主题，因为一个主题快速累积许多相关笔记通常值得更深入、有意识的关注，而不是被动积累。
9
10将结果保存到 /digests，并附上本周日期。整个摘要保持在 500 字以内。这是指向完整笔记的指针，而非替代阅读它们。

安排此任务在每周开始时自动运行，这样在你亲自打开任何笔记之前，就已经有一份简洁的、关于所有重要事项的结构化摘要等着你。这是系统替代数小时手动阅读的直接机制——你不再需要重新阅读一周的原始材料来记住自己学到了什么，而是阅读一份 500 字的指针，只需两分钟，而不是相当于手动审查所需的两小时。

跨所有内容查询，而不仅仅是记住的部分

另一个主要节省时间的地方（与摘要分开）是能够针对你整个累积的知识库提出真正的问题，而不是试图记住哪个具体笔记有答案。

1根据 /wiki 中的所有内容，关于 [特定主题] 我学到了什么？引用每个主张所依据的具体笔记。如果仓库中的来源在该主题上存在分歧，请明确说明，而不是选择一个并呈现为共识。

这是系统运行时间越长，复利效应越大的回报。第一个月，你的 wiki 很薄，这种查询只返回少量笔记。第六个月，经过数十个来源的处理和交叉链接，同样的查询会揭示你永远无法手动建立的真正联系——你在第二周读到的一篇论文中的想法，直接与第二十周完全不同的来源中的某个东西相关联，因为两者都被归入相同的基础主题并相应链接。

诚实地处理矛盾

这个系统相对于简单地凭记忆重新阅读自己笔记的一个特定且被低估的价值在于，它主动揭示了你对某个事物的理解随时间发生的变化，而不是让一个过时的信念因你忘记曾经持有它而一直不受挑战。

当摄入协议标记出一个矛盾——新来源所说的与现有笔记声称的相矛盾时——要抵制让系统仅仅选择看起来更新或更权威的那个并静默为你解决的冲动。暴露矛盾的价值在于它迫使你做出实际决定：是早期的来源错了，还是底层现实确实发生了变化，或者这是一个两者都对的案例，取决于需要添加到笔记中的上下文。将这种判断自动化会破坏建立一个使你自己思考更严谨的系统的目的。

一个月的实际示例

为了使复利效应更具体，以下是实际使用一个月的大致情况。

第一周，你放入六篇与你正在研究的项目相关的文章。摄入遍历在 /wiki 中创建了八条新笔记，因为有些文章涉及多个不同主题，所有笔记都在存在真正关系的地方相互链接。摘要很短，因为还没有太多先前材料可供交叉引用。

第二周，你添加了四个来源。其中两个扩展了第一周的现有笔记，而不是创建新笔记，因为摄入协议正确识别了主题重叠。一个标记了矛盾：第二周来源中的一个主张直接反驳了第一周来源中自信陈述的内容。摘要突出显示了这一矛盾，审查后你意识到第一周来源使用的是过时数据。你直接更新了那条笔记，注明了更正和原因。

第三周和第四周延续这种模式，到月底，对整个主题的查询返回了一个综合，追溯了你理解的实际演变，包括更正，而不是一个静态快照，仿佛你从一开始就知道正确答案。

这是具体陈述的实际价值主张。不是说系统替你做思考，而是它消除了机械性开销——提取、交叉引用、记住你已经知道的东西——这些过去每周都在与你实际思考的时间竞争。

破坏这个系统的常见错误

有几个特定错误在人们设置此系统时反复出现，值得提前了解。

跳过 CLAUDE.md 协议，只是将文件丢进 raw，希望 Opus 5 能自行理解正确行为。 没有明确的指令，特别是“检查后再创建重复”规则和“标记矛盾而非静默覆盖”规则，系统会退化为它本来要避免的无结构 AI 生成笔记堆。

对整个仓库而不是特定周的活动运行摘要。 这会产生一份每周都变得更长、更没用的摘要，因为它反复总结你已经阅读和处理多次的材料，而不是只呈现真正新的内容。

将 Opus 5 的合成视为自动正确，而非起点。 模型在这里做了真正的认知工作——在增长的知识库中进行提取和交叉引用——像任何认知工作一样，它受益于你自己的审查，特别是它标记的矛盾，这正是你判断力增加最大价值的时刻。

出于习惯使用 Fable 5 进行常规每周处理，假设更贵的模型总是更安全的选择。 对于系统每周生成的重复、相似形状的提取和合成工作数量，Opus 5 的效率特性是更合适的，并且成本差异在数月持续使用后会显著累积。将 Fable 5 专门保留给系统本身提出的罕见、真正困难的综合问题，这些值得额外仔细审查，而不是用于常规的摄入流水线。

直接连接仓库，而非复制粘贴

以上所有内容都适用于你手动打开 Claude 并粘贴文件内容，但这个系统的真正无摩擦版本将 Opus 5 直接连接到你的 Obsidian 仓库，这样摄入和查询就不需要任何复制粘贴。

实际的路径使用 Obsidian 的 Local REST API 插件，在 Obsidian 的社区插件设置中启用，它通过本地 API 端点暴露你的仓库，并带有认证密钥。然后 Claude Code 或 Claude Desktop MCP 连接可以直接读取和写入你仓库中的文件，这意味着本文前面提到的摄入提示直接针对你的实际仓库运行，创建和编辑真正的笔记，而不是你手动在聊天窗口和笔记之间来回复制内容。

设置一次。在 Obsidian 中安装并启用 Local REST API 插件，复制它生成的 API 密钥。在 Claude Code 中，配置一个指向你仓库的 MCP 连接，使用该密钥。通过要求 Claude 列出你 /raw 文件夹中的文件来测试它，如果返回准确列表，则连接正常。

一旦这个工作正常，之前的整个摄入和摘要流水线就变成了你只需发送一条消息即可触发的过程，而不是手动复制粘贴，并且这也是使调度真正自动化的原因，因为定时任务可以在你不在场的情况下调用相同的 MCP 连接。

扩展到多个研究主题

以上所有内容假设一个仓库中只有一个研究主题。大多数认真使用此系统的人最终会同时跟踪几个不同的领域：一个具体项目，一个你一般关注的行业，一个与之无关的长期兴趣。将它们混合到一个无差别的 wiki 中，恰恰会造成系统本应防止的噪音。

解决方法反映了适用于 Claude Projects 的相同范围界定纪律。为每个真正不同的研究主题赋予其自己的子文件夹结构，或者如果主题足够大且无关，以至于交叉污染会主动混淆合成（例如，一个行业的主张被错误地与另一个不相关的项目交叉引用，仅仅因为两者都位于同一个无差别的 /wiki 文件夹中），则使用完全独立的仓库。

1多主题范围
2
3该仓库涵盖多个研究领域，每个领域在 /wiki 下有自己的顶级文件夹：/wiki/topic-a、/wiki/topic-b 等。
4
5在摄入新来源时，首先确定它属于哪个主题。如果它确实跨越两个主题，则明确注明跨主题连接，而不是将其模糊地放入一个文件夹而不加解释。
6
7摘要应按主题生成，而不是作为一个综合摘要，除非明确要求跨主题合成。

这种结构让每个主题独立累积——自己的 wiki，自己一套连贯的交叉引用——同时仍然允许你在两个领域之间确实存在值得揭示的真正联系时，明确要求跨主题合成，而不是让每条笔记隐式地与不相关的材料在单个无差别的堆中竞争相关性。

何时分割成完全独立的仓库与在一个仓库内使用子文件夹的实际规则：如果你真的不希望针对一个主题的查询意外地浮现来自另一个主题的不相关材料，那么独立的仓库是值得的，尽管需要切换它们的小开销。如果主题之间的一些交叉授粉实际上是有价值的——例如，一个总体行业趋势通知一个具体项目——那么一个仓库内的子文件夹保留了这种联系，而上面明确的范围界定指令防止了常规摄入时的实际混淆。

衡量这是否真的在节省时间

这样的系统可能会让人感觉高效，却没有真正与它旨在替代的东西进行对比测量，并且定期进行诚实的检查是值得的，而不是仅仅因为系统存在并按计划运行就假设时间是真正节省的。

在设置后的两到三周内，大致追踪你旧的手动流程中周一审查通常需要多长时间——重新阅读你保存的所有内容，试图记住什么与什么相关，搜索你记得在某处读过的一个具体事实。诚实地将其与现在阅读生成的摘要并跟进任何标记为需要你注意的内容所需的时间进行比较。

真正重要的比较不是摘要本身节省的原始时间——因为一份 500 字的摘要显然比一周的原始来源读得快——而是摘要是否真的揭示了重要内容，意味着你不会在几天后单独发现某些重要内容被埋没在原始材料中，从未进入笔记或摘要。如果这种情况经常发生，那么摄入协议的提取步骤需要收紧，而不是添加更多你的手动阅读时间作为变通办法。

另一个值得追踪的诚实指标是，早期的查询功能是否真的被使用。一个生成干净每周摘要但从未被实际查询以获取交叉引用答案的系统，只提供了其预期价值的一半——被动摘要的一半——而没有主动的“关于这个主题，我从所有输入来源中真正学到了什么”这一半，而这正是复利价值在使用数月后显现的地方。如果你注意到自己没有查询它，这通常表明 wiki 尚未累积足够的交叉链接材料，使查询感觉值得，这在最初一两个月是正常的；或者这表明你已经养成了不提问的习惯，这值得有意识地纠正，因为系统实际价值的很大一部分就在那里。

本周设置

不要试图一次性构建完整的流水线。按照让每个部分在添加下一个之前证明自己的顺序来构建。

第一周，只构建仓库结构和 CLAUDE.md 文件，然后在你正在阅读的任何内容上手动运行摄入提示。在自动化任何东西之前，先熟悉提取质量。

第二周，添加每周摘要生成，最初手动运行而非按计划，以便验证它是否确实从正确的一周活动中提取，并保持适度简洁。

第三周，一旦两个部分都可靠运行，将摄入和摘要安排为自动运行，这样系统就真正无需你记得触发就能运行。

到第四或第五周，你应该会注意到这个系统旨在产生的实际转变。过去以试图记住你上周阅读和学习了什么开始的周一早晨，现在以一份两分钟的摘要开始，它已经替你完成了记忆工作，而过去用于手动重新阅读和交叉引用自己研究的时间，现在可用于研究工作中真正需要人类的部分：决定什么重要以及为什么。

关注 @cyrilXBT 获取本文中所有内容背后的确切 CLAUDE.md 模板和 Obsidian 仓库设置。