信息该放哪：七个存放位置与一条晋升阶梯

《WorkBuddy 七层实操笔记》系列第 2 篇 · 作者：当月光落下 · 首发于腾讯云开发者社区。 全系列基于一台真实机器的逐条实测，记录哪些机制符合直觉、哪些相反，以及每条结论是在踩过什么坑之后才成立的。 系列目录：

1. 七层能力模型：把 AI 助手从「能用」拆到「会搭」
2. 信息该放哪：七个存放位置与一条晋升阶梯 ← 本篇
3. 技能装了却不被调用：触发机制与四十条清单上限
4. 让 AI 够得着外部数据：连接器、MCP 与一次自建实践
5. 资料库不是网盘（上）：七种节点、三层 block 与 database
6. 资料库不是网盘（下）：page 发布、检索与 doc 修订流
7. 到点自己干活：自动化的三条执行链与五条军规
8. 专家是角色滤镜，不是记忆分片：兼谈多设备同步的盲区
9. 四十一条实测踩坑清单：每条都标了根因和正解
10. 按收益排序的上手路径，与五份可直接复制的模板

L0 记忆层：七个存放位置与一条晋升阶梯

本篇是全系列的地基。「一条信息该放哪」这个问题，比任何功能的使用方法都重要——因为放错了位置，后面所有的自动化、同步、协作都建立在错误的前提上。

本篇要解决的事

不是让你记住更多，而是让每条信息只在一个地方、以正确的形式存在一次。

七个存放位置全景

一条信息在系统里可能落到 7 处，性质各不相同。先看全表，再逐条拆。

这张表里最容易被忽略的一列

「加载时机」这一列才是全系列的主线索。能不能跨会话续上，取决于「会话启动时会不会被读进来」，而不是取决于「我写没写下来」。

七个位置里，只有 ② ③ ④ 是自动进来的；⑤ 日志写再多也不会自动出现在下次对话里。

云端记忆档案：能管什么，不能管什么

每次会话启动，服务端会把一段自动生成的画像文本注入上下文。它有三个硬属性：

三个必知特性

① 选择性归纳 —— 不存在「人为定向编辑」，但确实存在「算法的选择性归纳」。它按近期性 + 高频性加权，天然偏向「最近反复出现的」，天然忽略「重要但只说过一次的」。

实测证据

某次实测中，当天已彻底删除某个外部知识库技能的技能包、凭证、连接器配置，并改掉了启动巡检里的调用。

但云端档案里仍然写着「深度使用该知识库」「订阅 N 个知识库」。

一次性宣告改变不了它，重复表达才可以。 这就是「只能通过大量信息调整方向」这条体感的机制来源。

② 跨项目混合 —— 历史会话检索是按语义相关度排序的，不按项目隔离。一次检索里返回的三条会话可能分属三个完全不同的项目。说明云端层是全局单一画像——它不知道你此刻是在干哪一摊事。

③ 它在起作用，不是躺着的 —— 它每轮都进上下文，会实际影响 AI 的初始判断。这是最容易被忽略的一点。

检索能力：7 天窗口（实测）

结论：超过 7 天的历史会话，现在检索不到。 半年前的讨论，云端接口拿不回来。

你能管的三件事

一句话定性

它是印象，不是事实。 印象可以被更新但不能被精确指定；事实必须来自可控文件。

所以分工是：印象交给云端，事实交给本地 + 同步。 它的定位是兜底通道，不是主力通道——价值在于「你在任何设备登录，AI 立刻知道你大概是干什么的」。

用户级记忆：唯一精确且跨项目的东西

误解一：位置

「用户级记忆 = 用户目录下所有的 md 文件。」

真相

用户级记忆 = 根目录四件套。实测从会话实际注入的内容看，进入上下文的只有根目录下的四个文件： SOUL.md / IDENTITY.md / USER.md / MEMORY.md。

memory/ 子目录下的日志与专家记忆不在其中——实测该子目录 51 KB 内容，一个字节都没进上下文。

误解二：写入方式

「用户级记忆是受对话慢慢熏出来的。」

真相

是显式写入，不是自动熏染。 这是它与云端档案的分水岭：

一句话：云端是「熏」出来的，用户级是「写」出来的。 这个可控性是它的全部价值。

体量约束：所有记忆里最严

原因是它是 100% 每次会话加载的：

它是怎么涨起来的（实测）

某次实测中，用户级 MEMORY.md 在一天之内从 3.1 KB 涨到 7.5 KB，增长约 140%。当天加进去的三段内容都通过了「跨项目通用」判据，所以加得没错——但这正好演示了它是怎么涨的：每一次「这条很重要，记下来」都在加码。

没有淘汰机制的话，半年后它会变成第二个失控的巨型日志。

唯一判据

判据

换任何项目、任何设备，这条还成立吗？

污染代价

放进用户级的东西，对所有项目生效。放错一条，会在不相关的对话里持续误导判断。

项目级记忆：项目的法条

误解一：权限优先级

「项目记忆的权限低于用户记忆，冲突时听用户级的。」

真相

这是约定，不是机制。 实际机制是：两者都进上下文，没有仲裁层。冲突时取决于模型解读，通常「更具体的优先」，但没有硬保证。

所以正确做法不是去记「谁听谁的」，而是让两层不写同一件事：

如果出现「用户级说 A、项目级说 B」，说明其中一条放错了层。

误解二：拷贝即可完全复现

「把记忆文件拷到新设备，就能一模一样地继续用。」

真相

成立的前提是内容里没有绑死本机的东西。 实测某个环境的各项目 MEMORY.md 硬编码情况：

规则：项目记忆里写「在哪儿找」，不写「绝对路径」。

结构事实：只有 MEMORY.md 会被自动加载

一个项目的 memory 目录里可能有二十几个日志文件，但进入上下文的只有 MEMORY.md 一个。日志是主动去读才读到的。

推论（严重）

一个项目如果没有 MEMORY.md，换设备后它就是完全失忆的——不管你搬了多少日志过去。

实测某环境 8 个项目里有 2 个没有 MEMORY.md，意味着这两个项目一换设备就归零。

同步成本的量化

顺序不能反

先建立晋升机制（日志 → MEMORY.md）→ 再同步 MEMORY.md。 直接同步 341 KB，同步过去的是 292.7 KB 的流水。

团队项目里的「法条」属性

在团队项目里，项目记忆约束的不只是 AI，还有所有参与者。

判据：新成员第一天进项目，读这一份能不能上手？ 能 → 写对了。不能 → 写成日志了。

日期日志：它是暂存区，不是终点

误解（本节最重要的一条）

「日志越写越长，是因为每次加载它都要消耗巨量上下文。」

真相

日期日志不自动加载。 实测会话注入的内容里没有它，是主动读取才读到的。所以那 70 KB 平时并不消耗上下文。

膨胀的真实代价是另外三条：

1. 信息埋没 —— 有价值的知识混在流水里，需要时找不到
2. 检索成本高 —— 要读就得整文件读，或靠人工扫描
3. 同步时白搬 —— 绝大部分是流水，同步过去也没用

块级解剖：一个失控日志的实测

把一份 814 行、68.8 KB 的单日日志按标题切块：

也就是说：每次为了 19% 的有效信息，要把 81% 的流水一起搬走。

体量分布极不均匀

这条结论很省力

那 8% 的超线日志，占了总体量的 49.4%。

⇒ 问题不在日志多，在少数几个失控。管住这 8%，就解决了一半体量。 实测动手处理这 3 个之后，日志总量一次性降了 47%。

四段式写作规范

日志写的时候就用固定小节名分段，日后可以机械提取：

## 结论与约定   → 将晋升到项目 MEMORY.md
## 踩坑         → 将晋升到用户级记忆或技能
## 待办         → 进待办系统，不进记忆
## 过程         → 留在日志，供追溯

三条硬规则

1. 单日日志超过 20 KB，必须做一次晋升。 超过就是信号：有东西该搬走了。
2. 待办不写进记忆。 凡带「待决定 / 未实测 / 遗留」标记的，一律进待办系统——躺在 68 KB 日志里等于不存在，既不会被提醒，也不会被勾选，下次进项目也不会主动浮现。
3. 每月末抽一次。 把「结论与约定」「踩坑」小节抽出，合并进项目 MEMORY.md；判断是否跨项目通用，是则再晋一级到用户级。

别混：两个不同东西

把这两个搞混，会得出「临时日志存 C 盘不需要管」的错误结论。

晋升机制：一条四级阶梯，两次不同的晋升

「晋升」经常被理解成一个动作，实际上是两个判据不同的动作。

关键

L1→L2 与 L2→L3 是两次不同的晋升，判据完全不同。 把它们当成一件事，结果就是「什么都往上提」或者「什么都不提」。

三个实例（都取自真实日志）

第三个实例的要点

如果只写进记忆，下次还得让 AI 从记忆里读一遍再执行；写成技能则命中触发词即可直接执行。这是「固化成技能」与「记在记忆里」的实际差别。

判定规则与红线

信息类内容：四问决策链

① 换会话后还需要吗？             否 → 留在会话
② 以后进入这个项目还要用到吗？    否 → 日期日志
③ 换项目还成立吗？               否 → 项目 MEMORY.md
                                是 → ④
④ 是「怎么做」且已重复三次以上吗？ 是 → Skill
                                否 → 用户级 MEMORY.md

数据类内容：另一组问题

一句话：要「被访问」的进资料库，要「被计算」的留本地。

三条易混分界线

红线清单

学完本篇应当能立刻回答

1. 「我这次踩了个坑」→ 先看是不是跨项目通用；是 → 用户级，否 → 项目 MEMORY.md
2. 「这个字段改名叫 X」→ 项目 MEMORY.md
3. 「还剩两个问题要拍板」→ 待办系统，不进记忆
4. 「一张几万行的台账」→ 资料库（要被访问）/ 本地（要被计算）
5. 「做这类活儿的固定套路，已经做过四次」→ 技能

文中所有「实测」「xx KB」「xx 个」这类数量，均来自某一台真实机器的快照，请当作方法示范而非通用阈值；真正通用的是判据与因果关系。

原创声明

本文系「当月光落下」原创，首发于腾讯云开发者社区。内容来自作者在实际使用中的逐条实测整理， 所有结论均有本机实机验证或真实接口调用支撑；文中出现的数量均为特定环境下的实测快照， 仅作方法示范，不作为通用阈值。

如需转载，请注明作者「当月光落下」及首发出处，未经许可不得用于商业用途。