ldm-memory-system：认知资产统一治理

定位：交接skill让你的AI不失忆，本skill让它不失智。
哲学：Memory是指针，不是数据库；治理是统一的，不分类目。

一、统一治理四问（外壳）

所有类目——Memory条目、文档、Skill、指针——过同一套四问：

① 住哪层？   该在 Skill / 文档 / Memory 哪层？住错层 → 降级或上收
② 真源在哪？ 唯一真源是哪个文件？副本失效 → 删副本；真源失效 → 修真源
③ 还准吗？   指向的东西还在吗？计数对吗？项目还活着吗？→ 当场验证
④ 有索引吗？ 所在目录有README吗？长文档有##章节吗？skill有description吗？
             没有 → 黑数据，补索引

为什么四问能统一？ 治理的本质就这四件事，不分类目。同一套问题，换个对象而已。

四问 × 类目矩阵

二、内核：三层架构 + SOT链 + B级分级（原创，重构不动）

三层架构（地图：知识放哪个仓库）

红线：对话原文→聊天记录存档；临时状态→会话搜索；完整key/完整路径→配置文件。都不许进Memory。

SOT链（法律：每条知识只有一个真身）

Skill > 本地md文档 > 聊天存档 > Memory

1. 一条知识只能住一层（真源层），其他层最多留指针
2. 更新时改真源层，禁止平行开副本
3. 写入前先问：这知识最后会不会被纠正？会 → 放能被纠正的那层

B级分级（包装：Memory条目写成什么样）

• B级为标准格式：结论 + 关键数字 + 推导逻辑概要
• 不存纯结论（缺推导，未来无法判断还适不适用）
• 不存完整表格（放项目目录，Memory只留一行指针）
• 进度数字A级即可（无歧义的纯数字）；铁律/指针/环境配置用B级

容量红线（预算驱动，2026-09-01补）

四问是逐条判定（这条该不该留），容量红线是预算驱动（memory总共只准住多少）——两者配合，缺一压不动：

• 70%黄线：新知识进memory前，必须先淘汰等量旧知识（有进有出），禁止只进不出
• 85%红线：触发深度治理——教训类条目一律上收进对应skill（SOT链强制：教训真源=skill层），memory不留教训全文副本，只留半句指针"教训已进XX skill"。淘汰判据：①已上收进skill/文档 ②30天未再触发 → 进删除候审单
• 深度治理顺序：先写入skill（教训搬家）→ 用户拍板 → 删memory副本 → 验证水位报告

三、两阶段

阶段一【搭建】：从零建这套系统

适用：新用户第一次搭建；或系统混乱（无索引/无分类/不知道哪些该升级）。

先问3个问题（决定结构深度和毕业判断）：

1. 你有哪几个长期项目？（决定文档层怎么分文件夹）
2. 哪些文件最常被引用？（决定哪些要建索引）
3. 哪些操作反复做过3次以上？（决定哪些该毕业成skill）

然后按五步搭建（详见 references/setup-guide.md）：

1. 画三层结构图（用用户自己的项目举例）
2. 建文档层：按项目建文件夹 + 每目录一个README + 长文档##章节
3. 建Memory层：清点现有条目 → 四问归类 → B级格式重写 → 不存key/完整路径
4. 定毕业标准（见第四章）
5. 试跑验证：搭完跑一次维护扫描，确认结构能用

最小可行版：怕复杂的新用户，只搭 Memory 分类 + 根目录README，文档层和skill层用到再建。不强制一次搭完。

阶段二【维护】：日常/定期扫描

适用：用户说「清理memory」「memory体检」「跑一遍项目」；或新增memory条目时按写入铁律执行。

先跑机械扫描脚本（确定性检查，只读不改）：

python3 scripts/scan.py <目标目录> [--depth 2] [--compact]

脚本检查6类问题：无README目录 / 根目录散落文件 / 同名文件跨目录（冗余或分叉）/ 同名目录跨位置 / 空目录 / 目录内同名文件。借鉴 claude-obsidian wiki-lint：引擎只报告，AI负责解释发现、判断意图、产出三张清单。

然后五步（详见 references/scan-workflow.md）：

1. 逐条判定：每条内容过四问（脚本结果作为输入，AI不重复机械劳动）
2. 验证指针：fetch/stat/cronjob list 当场验证
3. 三张清单：待删除候审单 / 待降级归档单 / 指针失效单
4. 用户拍板：说删才删，说留就留（硬卡点，不能跳）
5. 踩坑记录本：新坑写回本skill

文件夹整理规范（项目归属/归位/归档/模式选择）见 references/folder-rules.md。

四、毕业标准（什么时候文档→skill）

一个内容从文档层毕业成skill，必须同时满足4条：

① 重复性：同一流程出现过3次以上（不是一次性的）
② 换人能跑：别人/别的Agent拿到也能执行（不含只有你懂的隐含信息）
③ 有触发条件：能写清楚"什么时候该用它"（description可自动发现）
④ 用户确认：用户亲口说"这个以后常做"（Agent不能自己判断）

不满足 → 留在文档层，别急着做成skill。

五、执行边界

• 本skill是心法+检查清单，不内置自动化定时任务
• 所有维护动作由人发起或经人确认后才执行
• 定时任务如果读取文件，prompt必须加容错：文件不存在时输出提示然后正常结束，不报错崩掉
• 结项只认用户亲口说（「XX项目不做了/完结了」），Agent不得自行推断（离职≠项目结束、停更≠结项）
• 不处理：代码/部署/运行态一致性（neat-freak）、对话存档（ldm-session-handoff）、内容创作质量

六、踩坑铁律（全量案例见 references/pitfalls.md）

高频铁律，每次维护前过一遍；具体案例、场景细节在 pitfalls.md（当前17条），按需读取：

1. 严格按流程，用户拍板是不可跳过的硬卡点——三张清单没过目就动手=重大事故（pitfall 1）
2. 降级≠删除——详情搬到能查到的低层+memory留指针；删除只用于已上收进skill/文档的重复条目（pitfall 17）
3. 结项只认用户亲口说——离职/停更/不活跃只能进候审单，不能直接删（pitfall 5）

其他高频教训速查：真源必须是git仓库（11）、扫描时验证skill内文件路径（12）、同名跨位置=旧副本（16）、环境信息不进memory（4）。

七、附录

• references/setup-guide.md — 阶段一搭建工作流（3问→五步→最小可行版）
• references/scan-workflow.md — 阶段二维护工作流（逐条判定→验证指针→三张清单→执行→写踩坑记录本）
• references/folder-rules.md — 文件夹整理规范（模式选择+五条原则+归档规范）
• scripts/scan.py — 机械扫描脚本（只读，6类检查，AI解释结果并出清单）