# Memory Content Audit

> Use when 审计记忆内容质量：只读对照基线事实，找错误/过时/重复/矛盾条目，输出中文报告。

- Skill: `yyyyyhhhhh0639/memory-content-audit` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add yyyyyhhhhh0639/memory-content-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yyyyyhhhhh0639/memory-content-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: internal
- Author: yyyyyhhhhh0639 (https://skillmd.com/u/yyyyyhhhhh0639)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/yyyyyhhhhh0639/memory-content-audit

---


# 记忆内容质量审计（Memory Content Audit）

对记忆存储（scope-recall 独属条目，或内置 MEMORY.md/USER.md）做**只读**内容正确性审计：对照已确认的权威基线事实（路径/版本/端口/配置/状态），找出错误、过时、重复、内部矛盾、摘要失真的条目，输出结构化中文报告。与 memory-audit cron / 治理批次配套（对应 memory-storage-management 的「防豁免三联动」中的审计环节）。

## 触发条件

- 任务要求审计记忆条目内容正确性（给出基线事实清单时几乎必用）
- 治理批次 / 定期记忆质量检查
- 怀疑记忆库中存在过时或矛盾的条目

## 核心原则

1. **只读审计**：数据库用 `sqlite3.connect('file:<path>?mode=ro', uri=True)` 打开，**禁止任何写操作**；发现问题只进报告，修复另开治理流程
2. **基线对照**：审计价值来自与已确认事实逐条对照——路径、版本、端口、配置、状态五类最易错
3. **必须精读 content**：summary 可能截断、失真、或拼接多个 digest；summary == content 且只有问题无结论 = 空转条目（本身就是一个发现）
4. **任务给的数据路径可能错**：scope-recall 数据目录是 `$HERMES_HOME/scope-recall/`（memory.sqlite3 + lancedb/），**不是** `plugins/scope-recall/data/`（plugins/ 下只有源码+config.json）。先 find 定位再审计

## 审计步骤

1. **定位数据库**：`find <HERMES_HOME> -name "memory.sqlite3"`（注意 WAL/SHM 伴生文件）
2. **只读枚举**：`SELECT id, target, source, created_at, updated_at, content, summary FROM memories ORDER BY created_at`；先看表结构 `PRAGMA table_info(memories)` 与 source 分布 `GROUP BY source`
3. **source 语义判定**：`journal-digest` = 消化生成的独属条目（占绝大多数）；`tool-store` = 显式 store 条目；含 `curated` = MEMORY.md/USER.md 镜像（跳过或单独标注）
4. **基线关键词分组命中**：按基线主题分组（网络/代理、GPU/CUDA、venv/pip、STT、HF_HOME/模型目录、embedder、npm、junction 等）正则命中 → 缩小精读范围（实证 285 条命中 98 条，精读 ~50 条）
5. **重点条目全文精读**：与基线直接可对照的条目逐条核对（id 用完整值，前 8 位会查不到）
6. **自动化交叉检查**（脚本批量跑，见下节）
7. **输出结构化中文报告**（见报告结构）

## 自动化交叉检查清单

| 检查 | 方法 | 实证发现（2026-08-13） |
|:--|:--|:--|
| dedup_key 重复 | `GROUP BY dedup_key HAVING COUNT(*)>1` | 0 组结构性重复；内容级重复需语义判断 |
| 关键词分布（端口/模型名） | 统计 `7890`/`7898`/`harrier`/`gemini` 出现次数 | **0 次 = 基线事实在库内缺失**：7898/socks5 全库 0 条，失效端口 7890×6、7897×4 仍留存 |
| 曾被修正的条目 | `updated_at > created_at` | 67 条被更新过，其中 1 条更新后仍含旧环境状态（修正不到位） |
| 日期戳治理违规 | target=memory 且 content 含 `20\d{2}[-年/]\d{1,2}` | 锚点条目禁日期戳；**内容性年份可豁免**（模型发布日期、行业现状年份） |
| 内部矛盾对 | 同主题条目结论互斥 | 6 组：CUDA 12.4 vs 12.9；端口可用 vs 拒绝；venv 无 pip vs 有 pip；懒加载 vs 常驻显存；缓存 40KB vs 4.3GB 等 |

## 已知坑（2026-08-13 实证）

- **拼接式 digest**：journal-digest 条目常一条 content 塞 2~4 个 digest（summary 中多个"主题/意图/结论"块用 `/` 分隔）——摘要失真与内部矛盾高发于此
- **时点快照条目**（磁盘空间、cron 任务表、"模型缓存只有 40KB"）永久过时，且可能与其他条目矛盾 → 建议归档
- **测试残留**：tool-store 测试条目（"这是验证记忆读写功能的测试条目"）需人工清理
- **网络/代理条目过期最快**：历史端口失效后仍可被召回，当前端口反而可能完全缺失
- **embedder/工具换代遗留**：gemini/bge-m3 时代条目在换 harrier 后全部过时（API key 格式、定价、切换记录）→ 打"历史/已弃用"标记
- **质量分层规律**：新条目（近期）质量明显高于旧条目；7 月早期条目多为拼接式 digest，8 月条目多为凝练事实

## 报告结构（中文）

1. **审计方法**：查了多少条 / 抽样策略 / source 分布
2. **问题清单**：条目 id（前 8 位）/ target / 问题类型 / 内容摘要（前 100 字符）/ 证据（基线对照）
3. **按严重程度排序**：**高** = 事实错误 / 内部矛盾；**中** = 过时 / 重复；**低** = 摘要失真 / 治理违规 / 可疑
4. **总体结论**：质量分层 + 最需要修什么（按优先级）+ 正面条目清单（与基线一致、值得保留的）

## 关联文件

| 文件 | 内容 |
|:--|:--|
| `references/2026-08-13-scope-recall-audit.md` | 首次审计实证：285 条样本、6 组矛盾对、端口分布、完整发现清单（作范例） |