Productivity 的核心不是任务管理：拆解 Claude 的 L1/L2 记忆缓存

我们假设这样一个场景项目群里有人扔过来一句ask todd to do the PSR for oracle。对一个刚入职的新同事这句话基本等于乱码——todd 是哪个 toddPSR 是什么报告oracle 指公司还是某笔交易得反问三轮才能动手。但对老员工三秒就翻译完了让财务的 Todd Martinez 把 Oracle Systems 那笔单子的 Pipeline Status Report 准备出来。Anthropic 在 Claude 的 Productivity 插件里干的一件事就是把这种老员工的解码能力装进 Claude 的脑子。手段不是把数据塞进 vector DB、上 RAG、做 embedding而是纯文本 Markdown 文件 一套严格的两层缓存架构。一个反直觉的类比CLAUDE.md 是 L1memory/ 是 L2学过计算机体系结构的人对这套结构应当一眼能识破CLAUDE.md L1 cache。容量小≤ 100 行、命中快、放最热门的 ~30 个人 ~30 个术语 当前活跃的 5–15 个项目目标覆盖 90% 日常解码需求。memory/ L2 / 主存。容量无限可以放公司全员、所有术语、所有项目档案、所有人际偏好。L1 没命中时再往里翻。熟悉 CPU 缓存的人立刻就能理解为什么这样设计让 Claude 每次解码请求都完整加载几百号人的画像等于让 CPU 每次取数都直接走主存——慢且费 token。让 90% 的请求只读 100 行 CLAUDE.md、剩下 10% 才下钻 memory/跟 L1 hit rate ~90% 是同一种工程取舍。但真正反直觉的一点在这里整个系统没有用 vector DB、没有 embedding、没有相似度匹配。业界做给 LLM 加记忆几乎全在卷向量数据库——chunk、embedding、cosine similarity、ANN 检索一整套。Productivity 偏偏走另一条路用 Markdown 表格做哈希表、用文件名做主键、用 LLM 自己的长上下文当全文检索引擎。memory/glossary.md就是一张大查表memory/people/todd-martinez.md这种命名就是 key→value 结构要用谁就加载谁全程 grep 友好、人类可读、版本可控。为什么这条路反而更稳三个原因LLM 已经擅长读全文——专门给它再加一层 embedding 检索反而是给读者戴墨镜读字。可解释、可审计——出错了直接打开glossary.md看哪条写错了向量库出问题只能重新 embed。可手工维护——同事换岗、术语更新改文件就行vector DB 要重新构建索引。拆开看4 个 skill 怎么形成闭环打开 Productivity 的插件页会看到它一共 4 个 skill。光看名字像各管一事合起来其实是一个完整的记忆生命周期/start—— bootstrap 冷启动第一次安装 Productivity 时跑这个 skill。它会扫日历、邮件、聊天记录把最常出现的人、项目、术语提取出来写一份 CLAUDE.md 和 memory/ 的初始版本。它解决的是上一秒 Claude 还是空白纸、下一秒就要懂公司黑话的冷启动问题——没有它第一周 Claude 会被反复打断who is todd?。memory-management—— auto-trigger 的解码主力注意它的 frontmatter 里写着user-invocable: false——这意味着它不是斜杠命令而是每次 Claude 接到请求都会被自动加载。每条用户输入进来都先走一遍 tiered lookup1. CLAUDE.md (hot cache) → 90% 命中 2. memory/glossary.md → 兜底全量 3. memory/people/, projects/ → execution 时拉详细资料 4. Ask user → 真不认识就主动问第 4 步是关键当所有缓存都 miss它不是猜是反问X 是什么我学一下——学到的内容沉淀回 glossary下次就不再问。这是一个会自我成长的解码器。/task-management—— 简到离谱的 TASKS.md整个 skill 就维护一个TASKS.md文件纯 Markdown 任务列表。功能极简显然是设计选择复杂任务管理已经被 Linear、Asana、Jira 吃透了重做没有意义。Productivity 只想成为 Claude 视角下的我手头还剩什么——一个轻量侧栏不抢主路径。/update—— 周期性同步跑/update时Claude 会重扫最近的对话、邮件、日历事件把新冒出来的人、项目、术语合并进记忆库。这个 skill 是 L1 hot cache 的晋升 / 降级动作触发器最近频繁出现的人 → 升进 CLAUDE.md上季度结束的项目 → 降回 memory/。如架构图所示4 个 skill 各管一段/start写 L1L2 初始值memory-management每次对话读两层并按需补 L2/update周期性维护两层之间的内容流动/task-management是独立侧栏不参与解码主路径。整个系统的聪明不在任何一个 skill 里而在它们之间的协作——这才是 Productivity 做成一个 plugin 而不是单一 skill 的原因。它不解决什么边界比能力更重要了解一个工具的边界比了解它的能力更值钱。Productivity 在以下场景不够用或根本不适合不替代向量检索 / RAG——如果记忆库不是几百号人 上百个术语而是十万份合同条款或百万个产品 SKU纯 Markdown 就跑不动了。Productivity 针对的是工位社交语境这种数千条以内的离散事实规模超出后向量库才是正解。不能跨设备 / 跨团队同步——CLAUDE.md在 working dir 本地memory/也是本地目录。换台电脑就丢了团队成员之间也不共享。要团队级共享得自己接 git 或 NAS。不会自动决定什么该 promote 到 L1——SKILL 里写“When something’s used frequently, promote it to CLAUDE.md”但谁判断frequently目前是人工或/update时半自动判断没有滑动窗口频次统计。如果懒得维护CLAUDE.md 会逐渐失去 hot cache 性质——变成上次塞进来就再没出去的死库。bootstrap 强依赖外部接入——/start要扫日历、邮件、聊天意味着没接 ConnectorGmail / Calendar / Slack的用户冷启动几乎是空。Productivity 真正发挥威力的前提是先把这些数据源接进 Claude。不懂中文工位场景——所有模板PSR、standup、ship review、escalate天然是英语 SaaS 公司的内部语境。中文团队用起来要把模板里的术语全替换一遍——但这反而说明扩展点很清楚换术语机制本身不变。记忆系统从来不是越多越准。Productivity 的设计哲学是把它做成 cache hierarchy——L1 永远精简、L2 永远完备、晋升降级永远清晰——让 Claude 在三个月、半年、一年后仍然记得对的人、忘掉早该忘掉的项目。这种工程美感比AI 能记住一切那类营销话术值钱得多。