整理本地机器人记忆时发现，每天写一个 Markdown 很好落盘，但查旧经验会越来越费劲。后来我把它拆成规则、项目、任务和事实几类来维护。
windows-bot-memory/structured-recall
最近整理本地机器人记忆时，我遇到一个很朴素的问题：如果每天都写一个 Markdown，时间久了会不会越来越难查？
答案是会。每天一个文件适合作为流水账，但不适合作为长期记忆的最后形态。
日记文件的优点
日记式记录有三个优点：
- 追加简单，不需要复杂数据库。
- 出错后容易人工阅读。
- 能保留上下文顺序，方便回看当天发生了什么。
对一个本地优先的助手来说，这很实用。它可能离线运行，也可能只有最小的一套后台服务；能写进普通文件，恢复起来就省事。
但问题也在这里。日记文件越多，检索时越容易遇到两种噪声：
- 一类是“当时重要、后来不重要”的过程信息。
- 一类是“应该长期保留，但埋在某天记录里”的事实和偏好。
比如“提醒类任务默认走日程”“某个项目的根目录在哪里”“哪个工作区不能和另一个工作区混用”，这些不该每次都靠全文翻旧日记。
结构化拆分
更合理的做法是两层结构：
daily notes -> candidates -> structured memory日记仍然存在，但它只是原始层。后台整理时，把可复用信息拆到更稳定的位置：
- 规则：以后遇到同类请求应该怎么做。
- 项目：项目根目录、检查命令、发布范围。
- 任务：未完成事项、状态、下一步。
- 事实：长期偏好和低变动信息。
- 索引：关键词到文件和片段的映射。
这样下一次需要召回时，不必扫所有日记，而是先查结构化入口。
不混用工作区
本地 E 盘上项目很多，记忆最容易犯的错不一定是“记少了”，更可能是“串台”。
例如，一个工作区里的云端部署经验，换到本地实验项目时通常要重新检查；私聊机器人里的规则，也不适合直接写进公开项目说明。
所以记忆系统需要先按工作区隔离，再做跨项目总结：
workspace first, global later只有当一条经验被改写成通用规则，并且去掉了具体私有上下文，才适合放到全局层。
写成公开文章前先筛一遍
这套记忆也能帮助写博客，但不能把原始记录直接搬出来。
可公开的是：
- 设计取舍。
- 验证方法。
- 故障回看的抽象步骤。
- 本地优先、静态发布、任务拆分这类通用经验。
不该公开的是：
- 未脱敏的原始对话内容。
- 真实账号、群聊、内部标识。
- 具体服务凭据和本地敏感路径细节。
- 还没抽象过的临时决策。
换句话说，博客里可以写整理方法和取舍，未经脱敏的聊天细节就留在原始记录里。
我现在倾向的流程
比较稳的流程是：
- 先把每天发生的事落到 daily note。
- 定时从 daily note 中抽候选。
- 候选进入规则、项目、任务、事实等结构化文件。
- 搜索时优先查结构化文件，必要时再回原始日记找证据。
- 写博客时只使用抽象后的经验，再跑安全扫描。
这个流程不复杂。只写流水账，后面会难查；一开始就上数据库，又容易把维护成本抬得太高。
对个人本地机器人来说，比较合适的形态可能就是：普通文件作为事实来源，轻量索引作为检索入口，人工审查负责决定哪些能公开。
继续读