运行日志不是流水账#

原始运行日志里，最值得留的是结构化回执。

比如一轮维护可以留下这些字段：

1
cmd: build-index
2
indexed: 10879
3
tool: memory-tool

或者：

1
cmd: search
2
query: hashed
3
results: 5
4
source: scoped-or-global

这些信息足够判断系统有没有工作，但不暴露原始查询内容。

我不需要把某次真实提问写进日志。公开回看里更不该出现真实对话、完整路径、账号标识和临时现场。更该留下的是“查询长度、查询哈希、结果数、命名空间范围”这类能审计、又不能反推出原文的回执。

公开回看里可以留检查项和数量，不该把当时的现场细节贴出来。

指标要能解释变化#

记忆维护不是每天机械重复一遍就行。它会吸收本地记录、云端快照、项目索引、人工整理和反思候选。每个来源的增量，都可能改变后面的召回结果。

所以维护日志里要有规模指标：

• 采集来源和记录数量。
• SQLite/FTS 索引条数。
• 向量或 fallback 索引条数。
• 生命周期检查的 stale、archive、promote 数量。
• 反思候选和新增记录数量。
• 测试通过数量。

这些数字单独看没什么故事，连起来看才值得记。

索引数量突然少一半，我会先查采集路径；search 抽样归零，就先看索引和分词；生命周期一次归档太多，也要回头看规则是不是收得太紧。

运行账本的用处就在这里：把“感觉不对”变成能定位的问题。

外部失败也要写清楚#

本地记忆系统很容易碰到外部依赖失败。

模型下载失败、Python 包安装失败、镜像源证书问题、远端同步超时、云端快照暂时不可用，这些都不算罕见。麻烦在于失败以后，系统有没有把影响范围写清楚。

我希望日志至少把失败影响写清楚：

1
vector provider failed
2
fallback index built
3
tests passed
4
cloud refresh skipped
5
local cache unchanged

这比一长串报错有用。

报错告诉我哪里坏了，范围告诉我坏到什么程度。向量索引失败但 FTS 和本地哈希 fallback 可用，说明召回质量可能下降，但系统仍可工作。云端刷新失败但本地快照未动，说明这轮不能证明最新状态，但也不该污染已有记录。

这类范围如果不写进日志，后面写博客时就容易把“不确定”写成“已经验证”。

测试别只当装饰#

记忆维护跑完以后，我更信测试结果，漂亮摘要只能当参考。

至少要有几类验证：

• 索引构建测试。
• 检索工具测试。
• 生命周期规则测试。
• 反思生成测试。
• 健康检查。
• 审计检查。

这些测试不需要证明系统聪明，只要证明底座没有坏。

比如测试通过、健康检查通过、审计通过，再加几组抽样搜索有结果，我才会相信这轮维护可以作为后续写作和召回的依据。否则它只是一次半成品扫描。

博客发布也是同样的逻辑。文章写完以后，我会继续看安全扫描、封面检查、类型检查、构建、Pagefind、草稿泄漏检查、静态体积检查门有没有跑完。

记忆系统和博客系统都一样：能用脚本查的，就先让脚本跑完。

日志要为未来的自己服务#

运行账本主要是留给以后排查用的，不是把终端输出搬进文章。

过几天我问本地助手一个问题，系统给出奇怪答案时，我需要知道最近一次维护有没有成功。写一篇公开文章前，我也需要知道素材来自哪一层：原始记录、整理摘要、候选记忆，还是已经通过生命周期的稳定事实。

没有运行账本，所有这些判断都会退回到印象里。

有了运行账本，很多事情就能拆开：

• 记忆没有命中，是查询问题、索引问题，还是来源没采集？
• 某条结论不可信，是证据弱，还是生命周期没通过？
• 某次维护失败，是全局失败，还是某个外部依赖失败但有 fallback？
• 一篇文章能不能公开，是素材风险高，还是只是还没写好？

所以每次维护后，我会留一份能复查的账本：做了什么、哪些成功、哪些失败、哪些内容暂时不能公开引用。