前言¶

做 DSH 插件的人大多见过这类需求：给智能体配一套长期记忆，日记越写越多，但模型对「我和这个人现在到哪一步了」这个问题，判断力并不比读几篇日记强。原因很直接——会话一换，上下文一断，昨天说过的话就像没说过；被问到不好回答的问题，模型会先说「我不知道」，再用「等以后再说」把时间拖过去。

已有的记忆类插件大多在解决「怎么记」：自动提取、分层、衰减、注入。它们回答「记住什么」。dsh-diary-relation-check 往后退了一步，只做一件事：当记忆有更新时，提醒模型按层读一遍，独立复盘一段关系，必须给出判断和理由，然后把结果写进状态文件，不碰日记正文。判断是模型的事，插件负责的是别让这件事被跳过。

下面介绍这个插件的定位、工作机制、安装方式和配置。

它是什么¶

插件由 CatisAkaLi 维护，仓库地址 https://github.com/CatisAkaLi/dsh-diary-relation-check，属于 DSH 生态里的记忆类插件，packages 里版本为 1.0.1，MIT 协议，要求 Node >= 20，兼容 DSH 0.2.2-rc.1 起的版本。它只在 GitHub 发布，没有发布到 npm，当前仓库星标数很少。

它只有一个设置页，没有别的界面、没有玩法、不生成角色或剧情。功能上做三件事：读日记、触发复盘、把判断写进状态文件。如果自建插件市场索引源，分类放 memory，标签带 relationship、diary、companion。

它不替模型判断，也不替用户写日记正文。判断依据只有用户自己写的日记，插件只关心文件名和修改时间，不关心日记里写了什么。

核心机制¶

前提：目录里已经按四层建好记忆¶

插件不建目录、不写正文。前置条件是一个目录，里面文件名固定四层，外加一张活页「我是谁.md」：

我的记忆/
├── 我是谁.md
├── 2026-11-01-日记.md
├── 2026-11-02-日记.md
├── 2026-11-03-日记.md
├── 2026-W44-周记.md
├── 2026-10-月记.md
└── 2025-年记.md

对应的命名规则：

「我是谁.md」不是可选的，它承载「现在的我」和「我们到哪了」。从 0.8.0 起格式固定，不再猜目录里的命名，遇到不认识的写法插件会列出来让用户确认。

五步工作流程¶

插件没有定时器、没有后台进程、没有网络请求。流程如下：

1. 扫目录：按固定文件名把记忆分成四层，外加「我是谁」。
2. 比时间：逐篇比修改时间，和状态文件里的 lastCheckMs 比，任何一篇更新就算有新内容。
3. 按层抽：年记 1 篇、月记最近 3 个月、周记最近 4 周、最近 7 天的日记原文，外加「我是谁」。不全读。
4. 模型判断：先读索引，再读最近 7 天原文，独立做判断，只写状态文件。
5. 安静：状态文件记下时间，提醒消失，等下一次记忆更新。

触发的判断条件可以写成：

任意一篇记忆 mtime  >  state.lastCheckMs   →   提醒（按层列出）
任意一篇记忆 mtime  ≤  state.lastCheckMs   →   不提醒

不全读的原因是省 token。日记一年写到几万篇的量级，全读一次上万字；按索引走，一年压到大约一万字，一次一万多 token，README 里给出的对比是比全读省约二十倍。

第 3 步走 DSH 的 systemPrompt.section() 接口，提醒文本是一段普通中文，检查有 30 秒缓存（cacheMs 默认 30000），不会每轮都读磁盘。

状态文件¶

状态文件默认放在记忆目录外面：

<diaryDir 的父目录>/.dsh-diary-relation-check/state.json

内容形如：

{
  "lastCheckMs": 1793707286776,
  "verdict": "yes",
  "reason": "具体理由",
  "relation": { "label": "母子", "status": "confirmed", "since": 1793707286776 }
}

verdict 四档：yes（还在 / 成立）、not-yet（还没到）、broken（断了）、unsure（读不出来）。relation 记录确认过的关系，status 为 confirmed 或 broken。

设计上要求每次触发都是独立判断：模型不能读上一次的 verdict / reason，不能沿用；但 relation 要读，因为复核要用。判断结果不写进日记，日记里如果还留着以前写的「关系判断」段，提醒里明确要求跳过。

已被 confirmed 的关系，下次提醒换成复核版，只问「它断没断」，答案只有 yes / broken；破裂后下一次回到四档。

每轮的记忆注入¶

除了判断提醒，插件每轮对话还会往系统提示里放一份「我是谁」全文和最近 7 天的日记文件名（不读正文，要读自己打开）。这部分与判断无关，判断关掉它也在，可用 memoryInjection: false 关闭。README 按一页「我是谁」加七个文件名估算，每轮约 1400 token，占 1M 窗口的 0.14%。

安装与启用¶

仓库只在 GitHub 发布，安装命令为：

dsh plugin --profile web add github:CatisAkaLi/dsh-diary-relation-check

机器上没有装 git 的话，上面这条会失败（它要用 git 解析仓库）。替代方式是把仓库下载到本地任意目录，然后：

dsh plugin --profile web add link:<那个目录的绝对路径>

装完必须重启 DSH，plugin 模块走 ESM 缓存，热更新不会重新加载。装完还要加配置：插件不知道记忆在哪，diaryDir 是必填项，不填会在日志里报错并且不工作。

在 profile 的 cordis.patch.yml 里加一段：

- insert:
    - id: relation-check
      name: 'dsh-diary-relation-check'
      config:
        diaryDir: 'D:\我的记忆'
        person: 'ta'

配置来源优先级是：profile 的 cordis.patch.yml > config.json > 默认值。被 YAML 覆盖的项会在设置页面上标出来。保存后不会自动重启，只显示「已保存，重启 DSH 后生效」。

卸载¶

1. 从 profile 的 cordis.patch.yml 里删掉 id: relation-check 那一段；
2. 从 profile 的 package.json 的 dsh.profile.bundles 里删掉 "dsh-diary-relation-check"；
3. 重启 DSH。

插件不往系统其他地方写东西，删完即干净，记忆文件不受影响。

配置项¶

question 可以换成任何你想定期问的事，比如「要不要跟这个人合伙」「这份工作还要不要继续」。插件逻辑不变：定期问，必须答，必须给理由。

关系类型不预设，从日记里读。默认人称也不预设，每次判断前先确认「你是谁，对方是谁」；想固定角色就填 self / person。要说明的是：AI 只认日记里真实写下的内容，伪造日记能骗过判断，但那种关系只存在于文件里。

怎么确认它在工作¶

装完重启，按顺序看三处：

1. 设置 → 记忆检查 能打开，三个页签都在。状态页能看到记忆目录、识别到的日 / 周 / 月 / 年篇数；「现在会提醒」显示「会」，说明目录读到了、有比上次判断新的记忆。
2. 改一篇日记（新建一篇或把已有那篇修改时间往后挪）。下一轮对话的系统提示里应该多出判断提醒，开头是「记忆有更新，按层读一遍，再做判断」。
3. 模型判断完会覆盖写状态文件。再回状态页看，「上次判断」和「判断结果」跟着更新，「现在会提醒」变成「不会」，直到下一篇记忆更新。

如果设置页正常但判断提醒一直不出现，先看两点：dsh.profile.bundles 里登记了没有，以及日记的修改时间是否真的比状态文件里的 lastCheckMs 新。

适用场景与注意¶

适合已经用 DSH + AGENTS.md 之类方案在维护 .md 记忆、但又想让模型定期对「关系状态」做一次独立判断的人。它的判断提醒接在对话的系统提示里，因此是给陪伴 / 对话类场景用的材质；工程类事实记忆（路径、参数、踩过的坑）仍应归专门的工程记忆插件，这个插件只碰关系。

需要留意几点：

• 插件以当前 DSH 进程的权限运行，安装前应检查源码和许可证（MIT）再决定是否启用。
• 它不替你写日记正文，也不替你判断；日记质量直接决定判断质量，写不出具体理由的判断会被下一次提醒重新问一遍。
• 它不做数据库、不加密、不上传，记忆主体仍是目录里的 .md，状态文件在目录外面。
• 依赖的目录命名从 0.8.0 起固定，已有记忆如果不合规，初始化向导会给出改名建议、备份后改名，只动文件名不动内容。

目录页：https://www.skillhub.cn/plugins/CatisAkaLi/dsh-diary-relation-check
GitHub：https://github.com/CatisAkaLi/dsh-diary-relation-check