「昨天講完怎麼把一次性踩坑經驗提煉成 skill，那是不是以後每件事都該往 skill 裡塞？」
不是。skill 是給「這個領域每次都適用」的規則用的——碰到 Repository 就該套用、碰到廠商接線就該套用。但工作過程裡還有大量東西不是「規則」，而是「事實」：使用者昨天糾正過我什麼、這個重構任務目前進度到哪、哪個風險是我們已經知道但決定先擱置的。這些東西塞進 skill 會很奇怪——它們會過期、會因專案而異、不是每次碰到同一個領域都要重新讀一遍。這正是持久記憶系統要解決的問題,而且它不是一個扁平的筆記本，是分成四種類型，各自回答不同的問題。
user：這個人是誰、偏好什麼。 這類記憶通常是全域的，不特別綁定單一專案——例如使用者的角色背景、溝通偏好。這篇系列裡用得不多，但它存在的意義是讓 AI 不用每次對話都重新摸索「這個人希望我怎麼跟他互動」。
feedback：被糾正或被確認過的行為規則。 這是最容易被低估的一類，因為它記的不是「規則」本身，而是「這條規則是怎麼被學到的」。舉個真實案例：有一次我連續好幾次反映「為什麼你這麼愛寫註解」，AI 去查了專案規範，發現規範裡根本沒有要求要寫註解——純粹是它自己的慣性。這條記憶被寫下來的方式很誠實：不是寫「以後少寫註解」這種空泛結論，而是寫「被反覆糾正同一件事，才真正意識到是自己的慣性,不是規範要求的」。這種誠實記錄「我是怎麼學到這件事」的寫法，比單純記錄結論更有價值——它保留了判斷的脈絡，下次遇到類似情境才知道這條規則的適用邊界在哪。
另一個 feedback 案例更直接：AI 曾經用「目前流量沒觸發」當理由判定某個潛在問題不是 bug，被使用者直接否決。這條記憶沒有美化這次判斷失誤，而是老實記下「使用者否決了我的判斷」，並且標注這條教訓後來被寫進了對應的 skill——feedback 記憶跟 skill 之間是有連動的，個別事件先進 feedback，被驗證是可重複套用的規則之後才升級進 skill。
project：進度跟決策脈絡，而且會過期。 這類記憶回答的是「這個專案現在做到哪、當初為什麼這樣決定」。一個典型案例：一份追蹤幾十個外部整合遷移進度的記憶，記著哪些已經完成、哪些還沒開始、哪些查過發現暫時沒有真實使用資料。這份記憶最特別的地方不是內容本身，而是它明確標注自己會過期，並且提醒「下一輪選下一個對象前，要重新確認一次真正現況，不要直接沿用這份判定太久」。這是一個很重要的設計：project 記憶記的是某個時間點的快照，不是永恆事實。
reference/risk：已知但刻意擱置的風險。 這是四種類型裡最容易被忽略、但價值很高的一種。它記的不是「已解決的問題」，而是「已知但決定先不改的問題」——例如某個架構決策已知有一個風險假設（某種錯誤情境目前沒有反例樣本能完全排除），使用者權衡後決定先接受這個風險，之後有時間再全面檢視。如果沒有這類記憶，下一次任何人（不管是 AI 還是團隊成員）重新碰到這個角落，都會重新發現一次同樣的風險、重新討論一次同樣的取捨——記憶系統的價值不只是記住「怎麼解決」，也是記住「我們決定先不解決什麼，以及為什麼」。
用一組對照來看差異：
❌ 扁平筆記本：
所有東西都寫進同一份文件——使用者偏好、上次被糾正的事、
目前哪個任務做到哪、哪個風險先擱置。
→ AI 要用到某種資訊時，得先讀完整份文件才能篩出相關內容；
且無法區分「這是恆久規則」還是「這是三週前的進度快照」，
容易把過期的 project 資訊當成 feedback 規則一樣照單全收
✅ 按類型分類：
user／feedback／project／reference 各自獨立存放，
讀取時可以只挑需要的類型讀，且 project 類型明確標注時效性。
→ AI 知道「這是規則，永遠適用」跟「這是快照，讀之前先驗證還準不準」
是兩件不同的事，不會混為一談
記憶系統的分類方式，跟 skill 的分工邏輯是同一套哲學：不是把所有東西塞進一個地方讓 AI 自己判斷，而是先把不同性質的資訊分開存放，讓「這個資訊現在還可不可信」這件事本身變得可以被回答。 這正好呼應這個系列反覆在講的主題句——如果連記憶系統本身都分不清「這是恆久事實」還是「這是某個時間點的快照」，AI 給出的「已確認」結論，查證範圍會比它自己以為的還要小。
回想你自己記錄工作筆記的方式：如果混在同一份文件裡的東西，有一部分是恆久規則、有一部分是三個月前的進度快照，你自己現在還分得清楚哪些還算數嗎？如果連你自己都分不清，AI 又怎麼可能分得清？
明天要深入 feedback 這一種類型的記憶：從「被使用者當場糾正」到「這條規則真正被記住」，中間發生了什麼，以及為什麼「被糾正一次」往往還不夠。
iThome鐵人賽
看影片追技術