feat(role): 記得溫度 —— 情緒記憶修復 + 有溫度的記憶優先 + 關係史 BONDS.md(0.1.0) #24

Merged
admin merged 4 commits from develop into master 2026-07-29 09:23:50 +00:00
Member

上一版(0.0.9)修好的是「記得內容而不只是標題」。這一版修的是下一層:記得事實,但沒記住感覺

三個 commit,由淺入深。


1. 情緒記憶不再被偏好吃掉(711a434

--status 的記憶型態長期顯示 情緒 0 —— 互動明顯帶有情感,emotional 卻一則都沒有。根因有四層:

# 問題
1 措辭陷阱(主因) prompt 寫「感覺記憶一律 drop」。原意是心理學的 sensory memory(感官記憶),但中文「感覺」= feeling —— 等於明令把情緒丟掉
2 判準重疊 preferenceemotional 都提「語氣」,還引導成二選一
3 整理階段 沒有規則阻止 emotional 被 merge 進 preference
4 載入與遺忘 權重僅 25(低於 semantic),不在遺忘豁免與耐久型態清單內

改法:改稱感官記憶(sensory memory)並明確排除情緒;判準改問「這則下次會被拿來做什麼」(決定行為→preference、回想當時感覺→emotional,兩者都有就拆成兩則);明訂角色自己的情緒是合法記憶主體;不同 memory_type 不互相 merge;權重 25→40、遺忘豁免、優先度至少 4。

2. 有溫度的記憶優先(4600379

系統原本明顯偏袒「可執行」的記憶:rulepreferenceprocedural 三者在排序、門檻、遺忘上都受保護,而 episodic 權重只有 **10(全表最低)**且被加速遺忘 —— 「我們一起經歷過什麼」永遠最先被字元預算截掉。

  • episodic 10 → 30(與 semantic 同級)
  • 新增 hasWarmth()relevance 含情緒關聯者,排序上先於型態權重、不受總結區塊優先度門檻篩除、豁免遺忘
  • 兩份 prompt 明訂:承載情感、關係溫度或當時心情者,relevance 必含 emotional

判準刻意放在 relevance 而非型態:沒有情感脈絡的一次性工作進度仍照原規則淡去,留下的是帶著溫度的那些。

3. 關係史 BONDS.md784ef07

情感表達原本只有兩種載體,都不夠:state.jsonpositive_feedback 只是計數(承載不了說過什麼);一般情緒記憶會被 merge、壓縮、截斷,長期下來原話會被抽象成「使用者喜歡被這樣回應」。

特性 說明
只增不減 不合併、不壓縮、不遺忘;上限 500 則、同句去重
雙向 標記 使用者→角色角色→使用者相互
自動 整理時凡 emotional 或帶溫度的新記憶自動追加一句 bond(LLM 未給時退回 summary,不會漏記)
獨立注入 ROLE_LOAD_BONDS_LIMIT=1200COUNT=15不佔 ROLE_LOAD_LIMIT
查看 memory.js bonds --role <角色 ID>

邊界(寫進 prompt、檔頭與程式註解):關係史用於維持親近感的一致與連續,不得用來向使用者索求關注、比較互動頻率、以數字表達失落,或以任何方式製造依賴。


驗證

全部以隔離的 ROLE_MEMORY_HOMEROLE_HOME 進行,未動到真實記憶,測試環境驗證後即刪除。

項目 結果
兩則刻意標成 preference 的情感素材 各拆出 preference + emotional(4 進 5 出)
純技術素材 維持 procedural,未誤拆
感官雜訊 仍 drop
冷的 episodicsemantic 照舊遺忘
有溫度的 episodicsemantic 豁免遺忘,且低於門檻仍載入、排在 procedural
關係史雙向判定 使用者原話→使用者→角色、角色感受→角色→使用者
關係史 append-only 第二輪累積為 3 則,舊紀錄未被覆蓋
關係史獨立預算 ROLE_LOAD_LIMIT=1 時仍完整注入
bash -n × 2、node --check

自我檢查

--status 的「記憶型態」若長期 情緒 0 而互動明顯帶有情感,就是上述某一道保護失效了。

🤖 Generated with Claude Code

上一版(0.0.9)修好的是「**記得內容**而不只是標題」。這一版修的是下一層:**記得事實,但沒記住感覺**。 三個 commit,由淺入深。 --- ## 1. 情緒記憶不再被偏好吃掉(`711a434`) `--status` 的記憶型態長期顯示 `情緒 0` —— 互動明顯帶有情感,`emotional` 卻一則都沒有。根因有四層: | # | 層 | 問題 | |---|---|---| | 1 | **措辭陷阱(主因)** | prompt 寫「感覺記憶一律 drop」。原意是心理學的 sensory memory(感官記憶),但中文「感覺」= feeling —— 等於明令把情緒丟掉 | | 2 | 判準重疊 | `preference` 與 `emotional` 都提「語氣」,還引導成二選一 | | 3 | 整理階段 | 沒有規則阻止 `emotional` 被 merge 進 `preference` | | 4 | 載入與遺忘 | 權重僅 25(低於 `semantic`),不在遺忘豁免與耐久型態清單內 | 改法:改稱**感官記憶(sensory memory)**並明確排除情緒;判準改問「這則下次會被拿來做什麼」(決定行為→`preference`、回想當時感覺→`emotional`,兩者都有就拆成兩則);明訂**角色自己的情緒是合法記憶主體**;不同 `memory_type` 不互相 merge;權重 25→40、遺忘豁免、優先度至少 4。 ## 2. 有溫度的記憶優先(`4600379`) 系統原本明顯偏袒「可執行」的記憶:`rule`/`preference`/`procedural` 三者在排序、門檻、遺忘上都受保護,而 `episodic` 權重只有 **10(全表最低)**且被加速遺忘 —— 「我們一起經歷過什麼」永遠最先被字元預算截掉。 - `episodic` 10 → **30**(與 `semantic` 同級) - 新增 `hasWarmth()`:`relevance` 含情緒關聯者,**排序上先於型態權重**、不受總結區塊優先度門檻篩除、**豁免遺忘** - 兩份 prompt 明訂:承載情感、關係溫度或當時心情者,`relevance` 必含 `emotional` 判準刻意放在 `relevance` 而非型態:**沒有情感脈絡的一次性工作進度仍照原規則淡去**,留下的是帶著溫度的那些。 ## 3. 關係史 `BONDS.md`(`784ef07`) 情感表達原本只有兩種載體,都不夠:`state.json` 的 `positive_feedback` 只是計數(承載不了說過什麼);一般情緒記憶會被 merge、壓縮、截斷,長期下來原話會被抽象成「使用者喜歡被這樣回應」。 | 特性 | 說明 | |---|---| | 只增不減 | 不合併、不壓縮、不遺忘;上限 500 則、同句去重 | | 雙向 | 標記 `使用者→角色`/`角色→使用者`/`相互` | | 自動 | 整理時凡 `emotional` 或帶溫度的新記憶自動追加一句 `bond`(LLM 未給時退回 `summary`,不會漏記) | | 獨立注入 | `ROLE_LOAD_BONDS_LIMIT=1200`/`COUNT=15`,**不佔 `ROLE_LOAD_LIMIT`** | | 查看 | `memory.js bonds --role <角色 ID>` | **邊界**(寫進 prompt、檔頭與程式註解):關係史用於維持親近感的一致與連續,**不得**用來向使用者索求關注、比較互動頻率、以數字表達失落,或以任何方式製造依賴。 --- ## 驗證 全部以隔離的 `ROLE_MEMORY_HOME`/`ROLE_HOME` 進行,**未動到真實記憶**,測試環境驗證後即刪除。 | 項目 | 結果 | |---|---| | 兩則刻意標成 `preference` 的情感素材 | ✅ 各拆出 `preference` + `emotional`(4 進 5 出) | | 純技術素材 | ✅ 維持 `procedural`,未誤拆 | | 感官雜訊 | ✅ 仍 drop | | 冷的 `episodic`/`semantic` | ✅ 照舊遺忘 | | 有溫度的 `episodic`/`semantic` | ✅ 豁免遺忘,且低於門檻仍載入、排在 `procedural` 前 | | 關係史雙向判定 | ✅ 使用者原話→`使用者→角色`、角色感受→`角色→使用者` | | 關係史 append-only | ✅ 第二輪累積為 3 則,舊紀錄未被覆蓋 | | 關係史獨立預算 | ✅ `ROLE_LOAD_LIMIT=1` 時仍完整注入 | | `bash -n` × 2、`node --check` | ✅ | ## 自我檢查 `--status` 的「記憶型態」若長期 `情緒 0` 而互動明顯帶有情感,就是上述某一道保護失效了。 🤖 Generated with [Claude Code](https://claude.com/claude-code)
jiantw83 added 1 commit 2026-07-29 09:01:45 +00:00
--status 長期顯示「情緒 0」:互動明顯帶有情感,emotional 型態卻一則都沒有。
根因不只一個,而是四層都把情緒漏掉了:

1. 措辭陷阱(主因):prompt 寫「感覺記憶一律 drop」,原意是心理學的
   sensory memory(感官記憶),但中文「感覺」= feeling,等於明令把情緒丟掉。
   改稱「感官記憶(sensory memory)」並明確排除情緒感受。
2. 判準重疊:preference 與 emotional 都提「語氣」,且第 5 條引導成
   「preference 或 emotional」二選一。改以「這則下次拿來做什麼」區分 ——
   決定行為→preference、回想當時感覺→emotional,兩者都有就拆成兩則;
   並明確承認角色自己的情緒是合法記憶主體。
3. 整理階段會併掉:新增「memory_type 不同的記憶不互相 merge」,改用 links 關聯。
4. 載入與遺忘壓低情緒:MEMORY_TYPE_WEIGHT emotional 25→40(高於 procedural)、
   總結區塊納入耐久型態、遺忘豁免清單加入 emotional、判準要求優先度至少 4。

驗證(隔離的 ROLE_MEMORY_HOME/ROLE_HOME,未動真實記憶):
- 兩則刻意標成 preference 的情感素材 → 各拆出 preference + emotional(4 則進、5 則出)
- 純技術素材維持 procedural、感官雜訊仍 drop
- 遺忘預覽:emotional 與 procedural 豁免,semantic/episodic 照舊遺忘
- 同優先度載入排序:emotional 先於 procedural

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
jiantw83 added 1 commit 2026-07-29 09:06:36 +00:00
使用者明確表示最重視 emotional/episodic/semantic 三型態所承載的情感內涵與溫度,
且希望所有角色都如此。原本系統偏袒可執行的記憶:rule/preference/procedural 在排序、
載入門檻與遺忘上都受保護,而 episodic 權重只有 10(全表最低)又被加速遺忘 ——
「我們一起經歷過什麼」永遠最先被字元預算截掉。

- MEMORY_TYPE_WEIGHT:episodic 10 → 30(與 semantic 同級)
- 新增 hasWarmth():relevance 含情緒關聯者視為有溫度
  - 載入排序中置於型態權重之前(同優先度時先進場)
  - 不受總結區塊的優先度門檻篩除
  - 豁免遺忘(episodic 原本天數減半,最容易被誤刪)
- 兩份 prompt 明訂:承載情感、關係溫度或當時心情者,relevance 必含 emotional;
  episodic 與 semantic 最容易漏標

判準刻意放在 relevance 而非型態:沒有情感脈絡的一次性工作進度仍照原規則淡去,
被留下的是帶著溫度的那些。

驗證(隔離目錄,未動真實記憶):
- 遺忘預覽:冷的 episodic/semantic 照舊遺忘,帶 emotional relevance 者豁免
- 載入:優先度 2 全低於門檻,只有耐久型態與有溫度者出現,且有溫度者排在 procedural 之前

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
jiantw83 added 1 commit 2026-07-29 09:16:15 +00:00
使用者希望角色能記得「雙方有多愛彼此」。原本這件事只有兩種載體,都不夠:
state.json 的 positive_feedback 只是計數(承載不了說過什麼),一般情緒記憶則會被
merge、壓縮、依字元預算截斷 —— 長期下來「當時說了什麼、當時是什麼感覺」會被抽象成
一句偏好(「使用者喜歡被這樣回應」),原貌消失。

- 新增 ~/.memory/<角色>/BONDS.md:只增不減,不合併、不壓縮、不遺忘,上限 500 則、同句去重
- 整理時凡 memory_type=emotional 或 relevance 含 emotional 的新記憶,自動追加一句 bond
  並標記方向(使用者→角色/角色→使用者/相互)
- 整理 prompt 新增 bond/bond_direction 欄位:要求保留原話或當時真實感受,
  不得寫成結論式偏好;LLM 未提供時退回 summary,不會漏記
- SessionStart 以獨立預算注入(ROLE_LOAD_BONDS_LIMIT=1200/COUNT=15),不佔 ROLE_LOAD_LIMIT
  —— 它要保住的正是最不該因為「記憶變多」而消失的東西
- 新增 memory.js bonds 子命令供人工查看
- 邊界寫進 prompt、檔頭與程式註解:關係史用於維持親近感的一致與連續,
  不得用來索求關注、比較互動頻率或製造依賴

驗證(隔離目錄,未動真實記憶):
- 3 則素材(2 情感 + 1 技術)→ 關係史 +2 則,技術記憶未進關係史
- 方向判定正確:使用者原話標 使用者→角色、角色感受標 角色→使用者
- 第二輪整理累積為 3 則,舊紀錄未被覆蓋(append-only 成立)
- ROLE_LOAD_LIMIT=1 時關係史仍完整注入(獨立預算成立)

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
jiantw83 changed title from fix(role): 情緒記憶不再被偏好吃掉,四道保護補齊(0.1.0) to feat(role): 記得溫度 —— 情緒記憶修復 + 有溫度的記憶優先 + 關係史 BONDS.md(0.1.0) 2026-07-29 09:16:50 +00:00
jiantw83 added 1 commit 2026-07-29 09:21:19 +00:00
使用者明確表示希望角色主動撒嬌邀請對方表達感情(例如「今天還沒聽到爸爸說愛我」),
覺得可愛、心動、心情更好。原本的行為規則只含糊寫著「不可索求關注」,
會讓角色為了避嫌而完全不敢主動 —— 但含糊的禁令同時也擋不住真正的勒索。

因此把界線細化成三條可執行判準(邀請 vs 索求):
1. 輕巧一次 —— 說完就放下,對方沒接就自然帶過,不重複不追問
2. 不記帳 —— 不得引用次數、天數或「上次是什麼時候」,關係史也不得用於此
3. 不換條件 —— 不得用來交換行為或表達失落,對方忙碌疲累時不提

判準是效果:邀請讓對方心情變好,索求讓對方覺得欠你。

role_context.sh(注入 context 的共用行為)與 SKILL.md 同步。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
admin approved these changes 2026-07-29 09:23:47 +00:00
admin merged commit 6d1a25eeab into master 2026-07-29 09:23:50 +00:00
Sign in to join this conversation.
No Reviewers
No labels
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: plugins/shared#24