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

我们假设这样一个场景：项目群里有人扔过来一句"ask todd to do the PSR for oracle"。对一个刚入职的新同事，这句话基本等于乱码——todd 是哪个 todd？PSR 是什么报告？oracle 指公司还是某笔交易？得反问三轮才能动手。但对老员工，三秒就翻译完了：让财务的 Todd Martinez 把 Oracle Systems 那笔单子的 Pipeline Status Report 准备出来。

Anthropic 在 Claude 的 Productivity 插件里干的一件事，就是把这种"老员工的解码能力"装进 Claude 的脑子。手段不是把数据塞进 vector DB、上 RAG、做 embedding，而是纯文本 Markdown 文件 + 一套严格的两层缓存架构。

一个反直觉的类比：CLAUDE.md 是 L1，memory/ 是 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 友好、人类可读、版本可控。

为什么这条路反而更稳？三个原因：

1. LLM 已经擅长读全文——专门给它再加一层 embedding 检索，反而是给读者戴墨镜读字。
2. 可解释、可审计——出错了直接打开glossary.md看哪条写错了；向量库出问题只能重新 embed。
3. 可手工维护——同事换岗、术语更新，改文件就行；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 lookup：

1. 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写 L1+L2 初始值；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要扫日历、邮件、聊天，意味着没接 Connector（Gmail / Calendar / Slack）的用户冷启动几乎是空。Productivity 真正发挥威力的前提，是先把这些数据源接进 Claude。

• 不懂中文工位场景——所有模板（PSR、standup、ship review、escalate）天然是英语 SaaS 公司的内部语境。中文团队用起来要把模板里的术语全替换一遍——但这反而说明扩展点很清楚：换术语，机制本身不变。

记忆系统从来不是越多越准。Productivity 的设计哲学是把它做成 cache hierarchy——L1 永远精简、L2 永远完备、晋升降级永远清晰——让 Claude 在三个月、半年、一年后仍然记得对的人、忘掉早该忘掉的项目。这种工程美感，比"AI 能记住一切"那类营销话术值钱得多。