来源清单不是备注#

来源清单要回答几个问题：

• 这个来源叫什么。
• 它是本地来源还是云端来源。
• 它的根目录在哪里。
• 只允许采集哪些文件。
• 明确排除哪些文件。
• 同步后落到哪个命名空间。

这件事主要是为了以后查得清。脚本多扫了哪个目录、哪条记忆从哪里来、为什么会出现在结果里，都应该能回头找到。

我会先把入口规则写死。

1
source manifest -> allowed files -> normalized records -> search index

入口规则清楚以后，后面的索引、查询和写作候选才不会乱跑。

白名单比全量扫描更稳#

很多采集脚本默认喜欢递归扫描。对普通资料夹这还可以，对机器人工作区就危险了。

机器人目录里通常有几类文件：

• 文档和模板。
• 结构化记忆。
• 运行日志。
• 本地配置。
• 私聊或群聊原始事件。
• 下载的文件和临时成果。

这些文件不该拥有同样的采集权限。

更稳的方式是先写 include 白名单。例如只采集入口文档、公开说明、知识库、整理后的记忆摘要、项目索引。即使目录里出现了新的临时文件，默认也不会进入聚合记忆。

白名单让系统慢一点，但能避免“目录里有什么就同步什么”的失控。

黑名单是第二道门#

只有白名单还不够。因为有些目录结构会变化，有些通配规则会比预期更宽。

所以还需要 exclude 黑名单，把明显不该进入记忆中心的东西挡掉：

• 本地真实配置。
• 日志。
• 运行成果。
• 临时文件。
• 原始事件快照。
• 私有目录。
• 下载文件。
• 大型依赖目录。

黑名单不能替代白名单，只适合兜底：有些文件就算被通配规则扫到了，也要最后挡下来。

对个人自动化来说，这个双层规则比后面再做脱敏更可靠。脱敏应该存在，但最好别指望它替你清理所有不该采集的数据。

来源要保留命名空间#

聚合记忆不是把所有来源合并成一堆文本。

每个来源都应该保留自己的命名空间。云端机器人、本地私聊助手、项目工作区、个人配置记忆，它们即使最后进入同一个检索中心，也不能失去来源标签。

原因很简单：同一句话在不同来源里的含义不一样。

一个群聊机器人的安装经验，不一定适用于本地私聊助手。一个项目工作区里的规则，也不该自动变成全局偏好。一个个人配置里的说明，更不能随便混到公开项目文档里。

所以聚合时，我更关心的是把范围结构化，别把来源标签抹平。

原始层不能成为默认召回层#

来源清单里可以允许保留原始材料，但默认召回层最好别直接扫 raw。

原始层主要用来回查和重建。排查问题时可以翻它，也可以拿它重新生成整理后的记录，但日常回答、执行任务和写博客不该直接吃 raw。

默认召回应当面向整理后的记录：

• 结构化项目索引。
• 明确的事实和规则。
• 已归档的摘要。
• 经过来源标注的 normalized 记录。

这样查出来的是整理过、能直接判断来源的记忆，不是一股脑塞进来的历史文本。

只读召回要再收窄#

即使已经做了来源清单，聊天入口里的全局召回也要继续收窄。

我更倾向于把全局召回做成只读查询：查询别太长，来源要指定，返回数量和大小要有限制，结果出来前再过一遍脱敏。

这样记忆中心更像一个图书馆索引，不会变成随意翻私密仓库的万能入口。

对博客写作尤其重要。写作候选可以来自记忆中心，但草稿必须只使用抽象后的经验。来源清单能告诉我“这篇文章覆盖了哪个素材”，安全扫描则负责再拦一次明显风险。

采集范围要能验证#

来源清单写完不代表系统安全，必须能验证。

我会检查几件事：

• 本地来源和云端来源是否都有名字。
• 每个来源是否有明确 include。
• exclude 是否覆盖配置、日志、运行成果和私有目录。
• 聚合后的记录是否保留来源名称。
• 全局召回是否不会直接扫 raw/private/runs 这类目录。
• 健康检查能否说明索引是从允许来源生成的。

这些检查不需要复杂，但要进入维护流程。否则来源清单会慢慢变成过期文档。

先列来源，再谈聚合#

本地记忆系统不是同步得越多越好。

来源变多以后，我会先确认哪些目录能进、哪些必须排除、进来后归到哪里。raw 只留作回查，日常查询只读整理后的记录。这样后面写文章或做任务时，才不容易把私人配置、日志和项目规则混在一起。