万条笔记变记忆

Paul Iusztin · AI Engineer

视频 39:33 原文约 3.6 万字预计阅读 29 分钟来源视频 ↗ 中英对照全文

双人对谈 · 本期速读电台 00:00 / 27:27

TL;DR · 三句话

一笔记多到 10000+ 条的真正瓶颈不是「上下文窗口不够大」，而是「记忆与上下文工程」——当 agent 把 context window 当成数据库+文件系统+记忆+推理空间一肩挑，对话一结束就全丢了；解法是给第二大脑搭一套「只在模型需要时加载它需要的那一点」的中间层。→ 详细
二他们的方案刻意「忘掉向量数据库/知识图谱/语义检索这些你以为必需的基础设施」，整套系统只建在纯文件 + 引用之上：raw（不可变原始内容）/ index.yaml（目录+摘要+元数据，agent 的入口）/ wiki（LLM 生成的概念、实体、对比、笔记派生层），靠三层分级引用把 token 消耗压到极低。→ 详细
三这个 wiki 是活的：你每问一个问题都会在 wiki 里留痕（生成新概念/笔记/对比文件并记日志），所以它不只在「摄入新数据」时进化，更在「你和它对话」时进化——最终照出一面你自己的镜子（你哪些没搞懂、你过去问过什么）；全程开源为 ai-research-os-workshop 仓库，是 Claude Code / Codex 插件，让你照抄并按需改。→ 详细

主讲 Paul Iusztin：Decoding AI 创始人兼 CEO（做「如何打磨 AI 产品」的内容与课程），畅销书《LLM Engineer's Handbook》合著者。他花了 18 个月把自己的第二大脑改造成一个「活的研究记忆系统」，这套系统就是他日常工作真正在用的。→ 详细
联讲 Louis-François Bouchard：Towards AI 联合创始人兼 CTO（做教育课程），YouTube 频道 What's AI 主理人（讲 AI engineering 技术），《Building AI Systems for Production》作者，前 AI 方向博士生。他自陈「搞研究就是我的本职」——做课、写视频、为视频调研、给公司做培训，一切起点都是一份扎实的研究。→ 详细
核心痛点：Paul 的笔记散落各处——Obsidian 5000+ 条、Readwise 5000+ 条，外加零散在 Notion 和 Google Drive，每月还新增 250 个文件。每当他要写文章、起新项目、搭新 code base、做新 feature，他「想真正地把对当前工作有用的高信号笔记捞出来」，但现实是「我从来想不起来第二大脑里有啥，或者得花一大堆时间才能找到能用的笔记」。→ 详细
金句：「我的阅读清单就是个坟场（my reading list is a graveyard）」——刷社交媒体存的酷 X 帖子、新文章、YouTube 视频、GitHub repo，真要用时全调不出来。另一个诉求是「我想让这个系统真正扎根在我个人的笔记、个人的价值观、个人的信念里，让它反映我自己的想法」。→ 详细
Paul 直接回应「为什么不直接用 Codex Cloud 或 NotebookLM」：「我确实在用啊。但你需要一个系统，夹在这些工具（harness）和你的第二大脑之间。」——即这套研究 OS 不是要取代现有 AI 工具，而是做它们与你私人知识库之间的桥。→ 详细
全片附开源代码，仓库名 AI Research OS（ai-research-os-workshop），专为这次 AI Engineer 大会 workshop 做；本质是给 Claude Code 和 Codex 用的一堆 skills + 插件。目标明确：「让你能按自己的需求去改它」。→ 详细
两人用法会有差异——这正是仓库的设计意图。Louis 强调整件事的目标是：「怎么把研究做得更好？更具体地说，怎么把我们手头已有的东西利用得更好（how can we better leverage what we have）？」→ 详细
Louis 强调「这整套研究系统并不是为每个 query 准备的」。第一个判断点：如果只是要个快速答案——几个简单问题、随手 Google 一下就行的事——那就直接 Google，或问 ChatGPT、Claude，别上重武器。→ 详细
但直接用 ChatGPT 有两个隐患：一是追问多、或这是个需要持续往上搭的大项目（需要很长 context、要喂一大堆信息）时就不理想；二是「你完全被 OpenAI 或 ChatGPT 团队搭的那套架构绑死了（fully dependent on the architecture they built）」。→ 详细
第二个判断点：要快速搞定 vs. 要搭下一个 feature 做很难的事。如果只是小 repo 改一处、写一篇不会重复的文章——「绝对该用 Codex、Claude Code，或某个你信得过的 agent」。→ 详细
但当你要「不断往深里挖、提升效率、做更多优化」时，你会希望研究来源能沉淀下来、将来还能回头引用。Louis 举自己例子：做新视频时他想让 agent 和系统「理解我之前做过的视频，这样就不会做重复内容、不会自我重复，还能引用别的内容」。→ 详细
NotebookLM 做研究、消化内容、回头复看都很强，但 Louis 点出四条硬伤：① 不归你所有（you don't own it）——没法随心所欲、没法尽可能个性化；② 不是 agent native 的；③ 因为是纯浏览器里的东西，做编码任务明显很弱；④ 「很难靠手去检查（hard to inspect by hand），你得围着它把一切都搭起来」。→ 详细
关键定位：「我不想要一个上线的、像产品那样超级专业的东西。我只想要一个我自己会用、而且我的 agent 和各种项目都能去借力的东西。」NotebookLM 规模化后超强、在产品里很有意思，但「离大多数 AI engineer 普遍需要的东西，差得还很远」。→ 详细
Louis 承认：在生产环境、为产品考虑时，他们建议搭一套带 vector database（向量数据库，把文本变成数字向量后按语义检索）的 retrieval RAG 流水线（RAG = 检索增强生成，先去知识库捞相关资料再让模型作答）。→ 详细
但 RAG「需要一套基础设施，对人不太友好，没法让你快速消化、查笔记、做修改」。这是「个人轻量用」和「生产级产品」的根本分野：这个项目是给自己用的，不追求专业产品级，追求随手可用、可手检、可被 agent 调用。→ 详细
最后一个判断点：如果你想要上面这些全有、但更个性化——一个会「搭出某种随时间不断累积复利的 Wikipedia（compounds over time）」、容易检查容易用、装着海量来源/文档/视频/对比/实现/新研究/新主题、你不停往里加又不停想方便复看的研究助理——那就是你该自己动手的时候。→ 详细
唯一缺点：「它确实比直接打开 Claude Code 要多一点搭建工作。」→ 详细
这是全片最核心的一句。现在用 Claude Code/Codex 的痛：你给 Codex 喂链接、PDF、各种信息（比如 Louis 最近那期 LLM Engineering 视频），下次再用就得全重新粘一遍，或让它去用 skills；而它临时搭出来调用你做过的事的那套结构、跑过的脚本，「你要么全丢了，要么塞进某个 skill 里还得每次专门让它复用——通常不理想，还会随时间越滚越大」。→ 详细
「你喂给模型的所有这些信息并不是瓶颈，瓶颈是：你将来怎么调用它（how can you leverage it in the future）？」对一个 agent 来说，context window 成了一切——数据库、文件系统、记忆、推理空间全得一肩挑，「而你一结束对话，它就把一切都丢了」。→ 详细
反共识结论：「我们并不一定要喂越来越多的 context 才能换来更好的研究。你需要的是一套像样的记忆和 context 管理，最好再带点个性。」——即记忆/上下文工程 > 更大的上下文窗口。→ 详细
Louis 演示「先把家底归拢」：与其分散在「一个文件夹放 Claude Code skills、会议纪要放 Granola、多年笔记放 Apple Notes、推文放 Chrome 收藏标签页」，他反过来把所有东西都自动挪进 Obsidian。他用 Codex 把一切配好：Granola 会议纪要自动存入、笔记迁到 Obsidian。→ 详细
为什么选 Obsidian：「它显然就是个笔记阅读器，你不一定非得用它，存本地就行」——选它纯粹因为 UI 漂亮、自己喜欢、手机/电脑/Windows/Mac 都能用。本质收益是：一切本地存在文件系统里，成了「做研究、搭东西的随身伴侣」。系统就建在纯文件（主要是 markdown）之上，自己和 agent 都能轻松调用。→ 详细
重要前提：两人都不是从零开始——Paul 约 5000 条笔记，Louis 只有几百条但做过几百期视频、记了很多笔记，还有跟团队/客户开的大量会、从推文/文章摘的 highlights。系统设计必须考虑「我们都已经有了规模可观的数据库」。→ 详细
当前可接入的来源：Obsidian（本地笔记）、Readwise、NotebookLM、你的 GitHub repos、任何 GitHub 或 YouTube 视频链接、网页链接、文档。仓库提供三档工具：深度研究 / 更简单的搜索 / 提炼（distillation）。其中「最有用、最完整的是那个研究工具」，Louis 开新视频选题时就用它。→ 详细
扩展极简：还缺一大堆 connector，但「你都能轻松实现，直接让 Claude Code 或 Codex 去做就行」。Louis 举证：那个 YouTube 视频转写功能，他几秒就实现了，就一个 prompt。Paul 补一句「对 Codex 来说实现起来超简单」。→ 详细
这个项目的真正价值不在功能多，而在「它实现了一大堆 AI engineer 需要了解的最前沿的 context 管理和记忆管理技术」——功能完整度是次要的，方法论才是主菜。→ 详细
V1 范围刻意限定在「只为他们的 agent engineering 课程生成课时」，保持超简单：输入 = 一个主题 + 一组手工精挑的「黄金链接」（golden links）；输出 = 一份静态 research MD 文件。→ 详细
deep research 算法完整六步（这是全系统的发动机，反复复用）：① 先抓取黄金链接内容，当作种子 context（让 agent 更懂怎么框定问题）；② 一个主 agent（orchestrator）基于主题+种子 context 生成多个问题；③ 每个子 agent 负责自己那个问题，用 grounded in Google 的 Gemini（即接了 Google 实时搜索的 Gemini）去搜资料、返回多个链接，并给每个链接生成执行摘要（executive summary）；④ 信息传回主 agent，主 agent 聚合成摘要形式以免撑爆 context；⑤ 这么跑三轮、每轮六个 query，总共拿到约 40-50 个链接（噪声相当多）；⑥ 加一套排序算法：把每个来源和用户初始主题做对比，只对排名最高的 top K 做完整抓取，其余只留摘要，最后编进一份扁平单文件 research MD。→ 详细
效果：「对课程来说一上来就跑得很好，我们很快生成了 35 节课时。」→ 详细
V1 的局限：「它只面向公开网络，这就让它相当通用，而且还得手工去找所有黄金链接。」V2 的关键改动：把同一个 deep research 循环对准第二大脑——「我们在那儿有机地记录着所有真正想要、并经我们筛选过的信息」。→ 详细
妙处：输入端只剩主题，不再需要黄金链接。因为「黄金链接其实就是第二大脑系统的一种映照」——你只要把某个主题作为输入，它就会把需要的一切都找出来（主题只当作生成 query 的种子）。→ 详细
算法本身不变（同样的 query 轮次、排序、完整抓取、摘要、编进 research MD），只是查询对象从「纯公开网络」扩成「第二大脑（Obsidian / Readwise / NotebookLM / GitHub）+ 公开网络」，并可按自己的基础设施扩到 Gemini deep research、YouTube、Google Drive、Notion 等。→ 详细
「这份 research MD 文件是静态的，就是一堆静态数据。可研究通常不是静态的。」你拿到文件后多半会发现：想再问个别的问题、某些信息已过时不再需要、或就是想从里面榨出更多东西——而这都意味着得从头再来一遍。→ 详细
但 deep research「是个很重的操作，消耗大量 token、很费时间，你不会想从头跑」。结论：必须在它上面加一层 wiki。→ 详细
V3 的等式：deep research 算法 + 盖在它之上的一个 LLM 知识库（即 wiki 层）。新算法：来源进、wiki 出。来源可以是 Obsidian、NotebookLM、Google Drive、YouTube、Notion，甚至自定义 URL——用 Bright Data 这类工具去解析「基本上任何单页应用、任何类型的站点、任何公开信息」。→ 详细
关键流程变化：不再把一切编进一份 research MD，而是把每个文件单独存成 raw，再从所有文件生成一个 index，最终在上面生成一个可查询的 wiki（查询对象 = wiki + index）。→ 详细
反直觉的地基选择：「你该忘掉那些你以为自己需要的基础设施——vector database、knowledge graph、semantic search、text search。这些都很美，但会带来大量复杂度，尤其对这种你想很轻量地用的个人 wiki。我想要一套就基于文件的系统，一种深深扎根于你的电脑本来就是怎么运作的简单机制。」→ 详细
整套系统只建在「文件 + 引用」上，不用数据库，就一个基于引用的 index。运作方式：一个 agent 去读 index.yaml——它本质是「你所有数据的目录 + 每个来源的摘要 + 元数据」。Paul 给的实例：一份 index.yaml 含 10 个来源 + 由它们派生的 38 个 wiki 页面；sources 列表里每个来源带「指向原始文件的链接 + 出处/标题/作者/发表日期/摘要」等灵活可变的字段。index.yaml 就是「agent 的入口，喂给它让它据此推理该怎么找数据」。→ 详细
三层文件夹：① raw 文件夹 = 原始数据，不可变，你不去碰它；② index = 指向所有 wiki 页面/派生物/原始来源；③ wiki 文件夹 = 由 LLM 生成的派生内容，含「多个概念/实体之间的对比」「对你的提问、对摄入仓库的笔记（一个仓库可生成多条）」「LLM 暂时答不上来的 open questions（开放问题）」——凡是能在原始数据之上做的分析都放这。→ 详细
在 Obsidian 里能看到基于 index 反映出的子图；随 wiki 生长，实体与概念之间会建立连接。Paul 举的实例：概念有 tool registry、context compaction、sandboxing；实体有 open code、closed code、MCP。「你能很漂亮地、既直观又务实地把这些连接建起来。」→ 详细
怎么查 wiki（核心省 token 设计）：agent 输入是 index.yaml（含各来源摘要+元数据）。① 第一级下钻到 source wiki page——它是每个来源「更展开一些的执行摘要」，「很多时候 agent 只看这一层，拿到要的东西就回去了，非常省 token」；② 若没找到，再走指向 wiki 派生物（概念/实体/笔记/对比） 的链接；③ 只有到这步还没找到必要信息，它才真的去读整份 raw 原始来源（整篇文章/论文/视频）。→ 详细
这套「纯引用 + 简单层级」让一切非常省 token——模型只在需要时才加载它需要的那一层，能用摘要解决就绝不读原文。→ 详细
wiki 不只在「摄入新数据/跑 deep research」时进化，更在「你和它对话」时进化：「每一个问题都会在你的 wiki 里留下痕迹。对每一个问题，LLM 都可以新建一个概念文件、一个笔记文件、一个对比文件，而且每个问题都会被记进日志。」→ 详细
它成了一面自我镜像：「你能看到一面真实的自我镜像——你哪些东西还没搞懂、你过去提过的所有问题，都映照在里面。」而且 wiki 永远不会被冻结：任何时候都能摄入一个新的自定义链接、或再跑一轮新 deep research，或单纯靠提问持续进化。→ 详细
关键边界：wiki 不凌驾于整个第二大脑之上。Paul 用 Tiago Forte 提出的 PARA 方法——数据分四类：Project（项目）/ Area（领域）/ Resource（资源）/ Archive（归档）。他保存的所有笔记/资源/来源都直接灌进 Resource（一个扁平列表），需要时再引用进 Project 和 Area。→ 详细
Obsidian 是 LLM 永不触碰的不可变快照：「这是我的数据，我真的不希望 LLM 去动我亲手写的个人笔记。」用法：庞大的 Obsidian 快照 = 全局第二大脑；每开一个新项目，就通过 deep research 算法去引用这个第二大脑、把它收窄到当前项目范围。→ 详细
总框架一句话：「项目就是产出（the work），你的第二大脑就是研究（the research）」——项目可以是写文章、做视频、做幻灯片（他这套 slide 就是这么做的），甚至写书、做课、追踪整个 code base。本质都是「把研究转化成产出」。这一切通过「一组插在 harness 上的 skill」完成。→ 详细
触发方式极简：打开一个 Claude 会话 → 调用 research skill → 把它指向文件，完事（其它一切已烘焙进 skill）。Demo 1 的输入是 Paul 一篇关于 agentic AI engineering 的旧文章，文件里他做了一次「脑暴倾泻（brain dump）——把想就这主题谈的所有东西都写下来」，外加几个「百分百确定要放进 wiki 的参考资料」。skill 光看文件+主题就懂他想建什么 wiki，并知道启动 deep research 前要先抓取这些信息当 context。→ 详细
三档深度（最重要的一步）：skill 会问你 deep research 要挖多深——light / deep / fast，主要控制「每轮跑多少问题、跑多少轮」。Paul 的实测口径：light = 1 轮 × 3 个 query；fast = 2 轮 × 3 个 query；deep 那档「只有当你真要在海量笔记上翻找时才用，因为这过程吃掉大量 token」。建议就在 light/fast 这个区间调。→ 详细
实操细节：他把 agent 切到 auto 模式加速——「我用过这玩意几百次了，知道它不会删我电脑里的东西、不会干奇怪的事」。完整跑一遍约 10-20 分钟（真去翻 Obsidian / Readwise / NotebookLM 跑查询），所以他演示时放的是事先跑好的结果。→ 详细
产出长相：三大块——raw 文件（找到内容的原始副本）、index（所有指向 wiki 的引用）、Obsidian 子图（快速看懂全局，纯基于这个文件生成）。最有意思的在 wiki 内部：comparisons / concepts / entities / sources。sources 装执行摘要（摄入时一次性算好，省得每次读原文）；comparisons 它开箱即用就懂该做哪些对比（如 agentic RAG vs. file systems、compaction vs. recursive language models）；concepts 自动抽取所有需理解的概念（打开 agent loop 资源就有带图带标签的漂亮摘要）。→ 详细
Demo 2 目标：学 harness engineering、harness 怎么运作。做法：完全不做 deep research，只摄入三个开源仓库——open code、Pi、Hermes，去探索指定主题：总体架构、agents 架构、sub agents、记忆系统、agent 权限流（permission flow）。→ 详细
跑起来后：自动克隆所有仓库，按给定主题逐个探索，在每个仓库各自层面生成笔记（讲架构在仓库层怎么运作），再在 wiki 派生物里生成更高层笔记——把所有架构拿来对比，或就所有 harness 的总体趋势做出聚合式架构，「直接从代码里把想了解的一切都学到手」。→ 详细
产出价值：repos 下能看到全部三个仓库（如 open code 仓库里有讲 permission flow、memory system 的笔记），最有意思的是对这些全做了对比——能搞清三个 harness 的架构差异、抽取出所有概念、看懂背后的关键架构决策。Paul 点题：「如果你想自己写一个 harness，它就超级有用。」→ 详细
Demo 3 是「现实中最简单的」：只摄入三个随便挑的自定义链接，传 prompt 即开始研究。关键卖点：Demo 2（GitHub 仓库）和 Demo 3「不需要任何额外配置就能跑——不用配 Obsidian、Readwise 或别的任何东西。装上插件就能跑，因为它们除了 Git 和用 curl 拉 URL 之外不依赖任何其它服务」。→ 详细
产出同样有 index、wiki（每来源一份执行摘要 + 所有概念、抽取的实体）。「关键在于，一旦你开始在这之上提问，一切才开始变得更有意思。」→ 详细
追问 demo：基于刚用 GitHub 仓库建的 wiki，Paul 演示问一个 harness engineering 的问题（具体是「远程 sandboxing 怎么工作、怎么接进 harness」）——做法仍是调 research、指向刚建的 wiki、直接问。系统会查询 wiki 给出答案，并在此基础上创建笔记/对比、或抽取发现新实体——即开始更新 wiki（呼应「wiki 是活的」）。→ 详细
刻意不补的 connector：还需 Google Drive、Notion、Slack 等，但「这些对我和 Paul 当前工作流并没那么有用，所以暂时没加——项目核心是对我们、以及对接手并按需扩展的你们有用」。另一主目标是讲清 memory 和 context 管理，「那些额外功能对这个目的没什么帮助」。→ 详细
已知弱点 + 待改进：① 很难判断哪些来源过时/薄弱/可靠；② 它「显然还是面向构建者的工作流」——通过 Claude Code/Codex 在终端用，「不是有漂亮 UI/UX 的最终打磨产品，而且这是刻意为之，因为我们的目标是教 AI engineering，不是打造下一个最好的产品」。很快要做的改进：更强的 linting、更好的 memory compaction（「那是个大问题，把 memory 管对本来就非常复杂，最前沿技术一直在推进」）、更好的来源溯源（source provenance）（好信任、排序、复用，让用户快速判断来源相不相关）。→ 详细
课程导流：他们把这一切做进了另一个产品——一门叫 Agent Engineering 的课，搭了一套类似的 deep research 系统（带一个写作 agent + 一个研究 agent），目标同样是学最佳 AI engineering 实践。「非常深入，估计约 60 小时学完，期末项目就是我刚描述的那套多 agent 系统，你将亲手为自己搭出来。」感兴趣可看 Towards AI Academy。→ 详细
0:00–4:20 痛点与定位：Paul 开场（10000+ 笔记散落 Obsidian/Readwise/Notion/Drive、月增 250 文件、阅读清单是坟场、要扎根个人价值观）→ 为什么不直接用 Codex/NotebookLM（需要夹在中间的系统）→ Louis 自我介绍 → 决策树第一岔：快速答案直接 Google/ChatGPT，但会被架构绑死。→ 详细
4:20–9:16 为什么要自己搭：决策树第二岔（一次性事用 Codex，要沉淀才上系统）→ NotebookLM 四硬伤（不归你、非 agent native、编码弱、难手检）→ RAG/向量库对人不友好 → 决策终点：想要个性化、可手检、随时间复利的私人 Wikipedia 就自己搭。→ 详细
9:16–12:48 核心洞察 + 归拢家底：瓶颈不是喂多少 context 而是将来怎么调用（context window 一肩挑、对话结束全丢）→ 记忆/上下文工程 > 更大窗口 → 把 Granola/Apple Notes/Chrome 标签全自动汇进 Obsidian（纯文件本地）→ 仓库 AI Research OS 能连什么、扩展多容易（YouTube 转写一个 prompt 几秒搞定）。→ 详细
12:48–20:06 三版演进：V1（topic+黄金链接→静态 research MD，deep research 六步算法、35 节课时）→ V2（同循环对准第二大脑、输入只剩 topic）→ V2 致命问题（research MD 是死的、重跑费 token）→ V3（deep research + wiki 层、来源进 wiki 出、忘掉向量库/知识图谱只用文件）。→ 详细
20:06–27:17 三层架构 + 总框架：raw/index.yaml/wiki 三层详解（10 来源+38 wiki 页实例）→ 三级分层按需下钻查询（source wiki page → 派生物 → raw，极省 token）→ wiki 是活的（每问留痕、照出自己）→ PARA 方法 + 「项目=产出、第二大脑=研究」。→ 详细
27:17–36:49 三个 Demo：Demo 1（对旧文章建 wiki、brain dump、light/deep/fast 三档、auto 模式、10-20 分钟、comparisons/concepts/entities/sources 产出）→ Demo 2（摄入 open code/Pi/Hermes 三仓库、不做 deep research、从代码学架构并对比）→ Demo 3（三个自定义链接、零配置可跑、追问 sandboxing 更新 wiki）。→ 详细
36:49–结束 路线图与导流：刻意不补 connector、待改进（linting/memory compaction/source provenance）、刻意不做 UI、Agent Engineering 课（写作+研究 agent、60 小时、期末做多 agent 系统）。→ 详细（本片无独立闪电问答。）收尾金句与关键资源汇总：
开源仓库：AI Research OS / ai-research-os-workshop——这次 AI Engineer 大会 workshop 的配套代码，Claude Code + Codex 插件，附 README 讲依赖安装。→ 详细
两本书：Paul 合著《LLM Engineer's Handbook》（畅销书）；Louis 著《Building AI Systems for Production》。→ 详细
课程：Agent Engineering（Towards AI Academy），搭写作 agent + 研究 agent 的 deep research 系统，约 60 小时，期末做多 agent 系统。→ 详细
方法论金句：「项目就是产出，你的第二大脑就是研究。」「瓶颈不是你喂给模型多少信息，而是你将来怎么调用它。」「我的阅读清单就是个坟场。」
Paul Iusztin — Decoding AI 创始人兼 CEO；《LLM Engineer's Handbook》合著者。
Louis-François Bouchard — Towards AI 联合创始人兼 CTO；YouTube 频道 What's AI 主理人；《Building AI Systems for Production》作者；Towards AI Academy（Agent Engineering 课）。
代码仓库：AI Research OS workshop（ai-research-os-workshop，Claude Code / Codex 插件）。
（视频中未给出具体社媒 handle 或邮箱，以上为可定位的频道/机构/仓库名。）

🎯 于你何益为你定制 · 非通用结论

这一期几乎是为你 Personal Thinking 这本第二大脑量身的工程蓝图——5 支里跟它最贴的一支。其余项目沾边的点一下，无关的按诚实闸门不硬掰。

Personal Thinking · 把"被动归档"变成"活的研究记忆"

怎么做的：Paul 把一万多条 Obsidian 笔记做成 AI 可用记忆，核心洞察是一句反直觉的话——瓶颈不是"喂多少 context"，而是"将来你怎么调用它"。做法是三层结构：raw（原始、不可变）/ index.yaml（入口目录+摘要+元数据）/ wiki（LLM 派生的概念知识层）；查询走"三级按需下钻"，把 token 压到极低；最妙的是 wiki 是"活的"——每问一个问题都留痕、慢慢照出你自己。还有一条决策树明确告诉你"什么时候根本不需要这套系统"（一次性的事用 Claude Code/Codex 就好，要长期沉淀复利的才上系统）。
你可以怎么做：你现在的入库 SOP 偏"收集 + 分主题"，离"可被 AI 高效调用"还有距离。直接借他的三层心智模型审视你的库：① 原子笔记 = raw 层（你已有）；② _MOC.md / INDEX.md ≈ index 层（入口，但还偏给人看）；③ 你缺的是 wiki 层——一个"问一次就生成一篇、还留痕"的 LLM 派生层。最小动作：给一个主题（比如 agent-engineering）手搓一个 index.yaml 式入口 + 一个"按需下钻"的检索约定，验证"先看目录再下钻"比"一股脑塞所有笔记给 AI"省多少、准多少。这正面打你"摄入 SOP / 信噪比 / 跨主题串联"三个痛点。
怎么做的（第二条）：他强调全部自动汇进 Obsidian、纯文件 + 本地（不锁进某个 SaaS），整套开源（ai-research-os-workshop，是 Claude Code/Codex 插件）；并用 PARA 方法区分"projects = 产出，第二大脑 = 研究"。
你可以怎么做：你的库本来就是本地 Markdown，天然契合——可以去扒他的开源仓库当参照实现，别从零造轮子。"项目 vs 研究"这条分界也帮你想清楚：哪些该留在 10_themes（研究/长期），哪些其实属于 20_想法库/项目产出。

agent-engineering · "上下文工程"的可迁移手艺

怎么做的：他反复示范的是"上下文工程"——不靠更大的窗口，而靠组织来源、索引重点、只加载模型当下需要的那一点；三个 demo 从"给旧文章建 wiki""直接摄入开源仓库学架构""零配置摄入三个链接"层层递进。
你可以怎么做：这套"按需加载、分层下钻"的纪律可直接搬进 Holdwell/app_incubator 的 agent——别每次把整个知识库怼进 context，而该 index→下钻。和上一支 Engram 正好是硬币两面：Engram 赌"训进权重"，Paul 赌"工程化检索"，你当下能落地的是 Paul 这条。

更深一层

该反着用：Paul 把它做成一门 60 小时课、面向众多学员的"通用系统"；你是自用、精力紧。别照搬他全套 V1→V2→V3 的复杂度，只取三层心智模型 + 那条"什么时候不需要"的决策树（帮你少造系统）。
对你的镜子："wiki 是活的、每个问题都留痕、照出你自己"——这正是你做第二大脑的初心（通过和 AI 对话重新发现自己的思考）。这期把那个模糊愿景给了一个具体工程形态。

One Human Company 新号（2026-07 回填）

"抛开向量库、纯文件三层结构"——一篇能晒 token 账单的 C 类选题

怎么做的：Paul 处理一万多条笔记的方案反直觉地简单——忘掉向量库和知识图谱，只用纯本地文件分三层（raw 原始层 / index.yaml 目录层 / wiki 派生层），查询走"先看目录、再按需下钻"，把 token 压到极低；整套开源（ai-research-os-workshop）可照抄。他的金句："瓶颈不是你喂给模型多少信息，而是你将来怎么调用它。"
你可以怎么做：drizzle tech 的 AI 员工们迟早要共享一个"公司知识层"（踩过的坑、产品决策、代码约定），这正是一篇 C 类实测：候选标题《大佬说"个人知识库别上向量库，纯文件就够"，我给 9 个 AI 员工搭了个共享大脑》——照抄他的三层结构给流水线建知识层，对比"全量塞 context"vs"index 下钻"两种喂法的 token 账单和回答质量，给判断：一人公司规模下向量库是不是过度工程。可抄物是那份 index.yaml 模板。闸门自检：token 对比数据是你独有的，删掉就只剩开源项目介绍，不成立——带账单发，能过。这篇同时给 B 支柱攒了"AI 员工的记忆成本"这条账。

所以呢

思维模型【耐用】："瓶颈在调用，不在收集"——做任何知识库/记忆系统，先想"将来怎么取"再决定"现在怎么存"。这条几乎可以焊进你的 ingestion-sop。
思维模型【会过期】：具体的 index.yaml/wiki 三层实现是当下 Claude Code 时代的形态，工具会变，留住的是"分层 + 按需下钻"。
判断更新：你可能一直把第二大脑的重点放在"把东西收干净分好类"；这期提醒你，真正的杠杆在"建一个能被 AI 高效调用、且越用越懂你的检索层"。
这周一个赌注：挑一个主题，手搓一个"index 入口 + 按需下钻"的小实验（哪怕只是一个约定 + 一个 prompt），在一个真实问题上对比"先看目录再下钻"vs"全塞"的差别。

接着读

NO.60 · Agent 工程编码被解决之后 Fiona Fung · 49 分钟 NO.59 · 产品 AI杀死工程金字塔 Reynold Xin · 15 分钟