前言¶

做 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