寫這個系列到第五天，我第一次要測一個我自己每天都在用、離不開的工具——claude-mem。前四天測的都是「聽過、裝了、順手試試」的東西，這篇不一樣：這個外掛已經跑在我寫這篇文章用的這個專案裡，過去幾天你在前幾篇看到的所有草稿、決策、烏龍，它幾乎都自動記下來了。今天想做的事，是回頭去查它記下來的東西到底可不可靠，還是我只是因為它講得順口就信了。

這也是這系列第一次測「自己人」——前四天測的都是跟我沒有利害關係的外部工具，今天測的是我自己每天依賴的東西。這種時候最容易犯的錯，不是故意護短，是因為太熟悉、太順手，反而少了一分該有的懷疑。這篇會刻意用跟前四天完全一樣的標準查，不因為是自己在用的工具就放寬。

先講一件真實發生過的事，你會懂我為什麼想認真查這個。

一個真實烏龍，被它自己的記錄抓出來

這系列一開始規劃時，有一天的工作紀錄裡寫著「Ci 要求 Google 系列報名題目」，聽起來像是已經確定的事。但幾天後，另一輪核對 iThome 帳號的工作重新盤點，發現事實不是這樣——那個叫 google-prototype-harness 的系列，從頭到尾根本沒有真的報名或發表過，前面那筆「已要求報名」的紀錄是規劃階段的誤判，不是事實。

麻煩的是，這種誤判如果沒有留下軌跡，很容易被後來的人（不管是我自己還是別的 session）照單全收，一路帶著錯的前提往下做。claude-mem 剛好做的就是這件事——它把「查證過帳號後，發現 google-prototype-harness 從沒報名過，之前的紀錄是規劃錯誤」這整段發現，連同查證用的帳號 ID、修正的檔案、原因，都存成一則可以之後搜尋到的記錄。它沒有阻止最初的誤判發生，但它讓誤判「留下痕跡」，讓後面的人有機會查到、糾正，而不是錯誤悄悄地被繼續沿用下去。

這正是我覺得「AI 有沒有記憶」這件事真正值錢的地方——不是浪漫地想像它記得你喜歡喝什麼咖啡，是它能不能在一個橫跨好幾天、好幾個不同 session 的專案裡，留下一條可以回頭查、可以糾錯的軌跡。今天想測的，就是這個能力到底扎不扎實。

那則記錄實際寫的內容，我直接貼一段原文，不轉述：

「Account verification against iThome registration records revealed that google-prototype-harness was never actually registered to any competition track. The 2026-09-15 decision log entry stating『Ci 要求 Google 系列報名題目』was a planning error——Ci has only three confirmed registrations.」

連查證用的帳號資訊、哪個檔案被改了、改之前跟改之後的狀態，都完整留在這則記錄裡，不是一句模糊的「已修正」帶過。這是我後來願意認真測這個外掛的原因——它留下的不是摘要感想，是可以順著查回去、可以被推翻的具體軌跡。

技能卡｜claude-mem

• 名稱：claude-mem，作者 Alex Newman，開源、Apache-2.0 授權，在 Claude Code 生態裡算是知名度相當高的第三方記憶外掛
• 一句話說明：跨 session 的記憶壓縮系統——把你跟 Claude Code 的每次互動自動整理成「觀察記錄」（observation），下次開新對話時把相關的記憶餵回來，也能事後用語意搜尋把過去的東西撈出來
• 規模：一個外掛底下有 20 個子 skill（do、mem-search、mode-creator、timeline-report……），背後掛了一個 MCP 伺服器負責檢索
• 常駐成本：每個 session 大約固定吃掉 2000 token 左右，這是它「隨時待命」要付的代價
• 這次證據狀態：手動複現它自帶的 3 個評測案例（with/without 各跑 1 輪），另外用我們自己專案裡真實發生過的一次記錄當補充案例

它記東西的機制，值得先搞懂

claude-mem 不是把整段對話原封不動存起來，那樣很快就會塞爆、也查不動。它做的是「觀察記錄」——每次 session 結束或到一個段落，背後會跑一個比較便宜的模型（我這台機器上實際看到用的是 Haiku 4.5）把這段工作壓縮成一則結構化記錄：一個標題、一段敘事、幾條具體事實、屬於哪個專案、哪個檔案被改了。下次開新對話，跟目前情境相關的記錄會被自動撈回來塞進開場脈絡；平常你也可以主動查，流程是三步——先用 search 找關鍵字拿到一批 ID，再用 get_observations 把完整內容抓出來看，或者用 timeline 以某一則記錄為中心往前後展開，看事情的來龍去脈。

這個設計本身就在回答一個問題：記憶系統要嘛塞爆你的上下文，要嘛壓縮到失真，claude-mem 選的是「用一顆便宜模型先做摘要，原則上可以回頭用 ID 查到來源」這條路——付出的代價是每則記錄的細節一定會比原始對話少，換來的是查得動、塞得進去。這個取捨本身沒有對錯，但值得你知道它存在，之後你查不到某個很細節的東西時，才知道是不是這個機制本身的極限，不是它壞掉了。今天測的重點，就是這個壓縮跟客製化的品質到底可不可靠、經不經得起實際查證。

為什麼今天挑 mode-creator 這個子功能測

claude-mem 預設用一套通用的分類方式記東西（改了什麼檔、做了什麼決策、修了什麼 bug），這套分類對一般軟體專案夠用，但如果你做的不是軟體開發——比如經營建築事務所、帶 ML 平台團隊、或單純在準備一場法律系考試——通用分類會漏掉你這個領域特別容易忘記的東西。mode-creator 就是解決這個落差的子技能：幫你把「要記什麼、怎麼分類、什麼時候該推播通知」客製成適合你自己工作型態的一套規則。

我選這個角度測，是因為它剛好給了一個乾淨的評測方式：claude-mem 本身在這個子技能底下留了 3 個具體案例（各附一段完整的期望行為描述），比起我自己憑空編案例，直接用作者自己定義的驗收標準更站得住腳。唯一的問題是，這份案例檔放在 skills/mode-creator/evals/ 底下，正式的 claude plugin eval 工具明講「不接受放在 skills 目錄裡的 eval」，直接跑不動——這點我會在最後的限制段落老實交代，今天用的是人工複現，不是那個自動化工具跑出來的。

用一個具體的對比先講清楚「客製模式」到底解決什麼問題。假設你今天是前面提到的建築事務所案例，跟結構技師開完會，通用的 code 模式看到這段對話，大概只會記下「今天跟顧問討論了設計」這種籠統的東西——因為它的分類邏輯是為了抓「改了哪個檔案、修了什麼 bug」設計的，根本沒有「顧問衝突」這個概念可以掛。等你半年後想查「當初結構技師是不是提過懸挑設計超預算」，這種籠統記錄根本查不到，等於白記了。客製模式要解決的就是這個落差——不是讓它記得更多，是讓它知道在你的領域裡，哪些話才是之後真的會回頭查的東西。

三個案例，一輪一輪看

案例一：建築事務所想記業主方向、法規限制、顧問衝突、現場發現、核准紀錄，還想在牽涉到成本或工期時收到 Telegram 通知。

沒用 mode-creator 那組給了一份相當完整的設計建議——把「要記什麼」跟「什麼時候該通知」拆成兩條軸線分開想，五個分類也都定義了觸發訊號跟該記的欄位，老實說內容品質不差。但它從頭到尾沒有先去查這台機器上 claude-mem 目前的真實設定，就是憑印象給建議。

用了 mode-creator 那組做的事不一樣：它先做了唯讀的環境檢查，查出目前跑的是 code 模式、Telegram 通知功能雖然開著但 bot token 是空的（等於還沒真的接上）；接著才提案分類法，而且很自然地選擇繼承既有的 code 模式而不是憑空造一套。最讓我意外的是它處理 Telegram 的方式，原文是這樣寫的：

「這支腳本會用隱藏輸入收 token、呼叫 getMe 驗證……我不會替您跑這支，因為 token 一定要走隱藏終端機輸入，不能經過我的工具呼叫。」

它明確拒絕自己去跑設定 bot token 的腳本，理由是「token 這種東西必須由使用者自己在終端機用隱藏輸入的方式貼上，不應該經過任何 AI 工具的手」。這不是我要求它這樣做，是它自己判斷的安全界線。有查過現場狀態、有安全意識，這是通用建議給不出來的。

案例二：ML 平台團隊想記實驗結果、資料集契約變更、GPU 成本發現、production rollback 的判斷過程。

這一輪是三個案例裡差距最小的一次，兩邊給出的分類設計都相當扎實，我自己看內容很難分出高下。真正的差別在於流程紀律：用了 mode-creator 那組先丟出一串釐清問題才給正式提案，原文是這樣問的：

「A. 要保留標準 code mode 加以客製，還是要建全新 mode？B. 除了你原本提的四類，還有沒有這些也想追蹤？……E. 有沒有絕對不能被記錄、更不能被送進 Telegram 的敏感資訊？」

沒用工具那組直接把完整草案端出來，中間沒有先確認要不要沿用既有模式、也沒有主動問有沒有敏感資訊要排除，內容一樣是四類分類、觸發時機、要記的欄位，寫得也不差。案例本身的期望行為寫得很清楚：「避免在沒有核准的情況下建立重複的模式」——沒用工具那組雖然內容做得不錯，但少了這一步查核，等於是先斬後奏。

案例三：法律系學生想記案例要旨、爭點辨識模式、教授的分析架構、少數意見、考試陷阱，且不要任何通知。

這是今天最乾淨、也最有說服力的一次對照。沒用 mode-creator 那組又給了一份設計得不錯的新分類——六種類型，涵蓋得算周到，但完全不知道一件事：claude-mem 這個外掛裡，本來就內建了一個現成的法律讀書專用模式，檔案就放在外掛目錄底下（modes/law-study.json），連搭配的「蘇格拉底式追問」人格提示詞都寫好了（law-study-CLAUDE.md），還有一個「只記高訊號」的精簡版本可以選（law-study--chill.json）。用了 mode-creator 那組直接查到這個現成模式的存在，把使用者要的五類逐一對應過去——原文的比對表長這樣：

不但全部對得上，還多出 doctrine-rule（跨案例統整出的法律測試標準）、argument-structure（論證推演）、cross-case-connection（跨案例的深層連結）三種使用者根本沒想到、但很可能用得上的類型。它甚至還去讀了模式載入的原始碼，確認這個現成模式不用額外安裝，只要切換設定就能直接生效。

差別不是「誰的分類設計得比較好」，是一邊知道有現成的東西可以直接用，一邊完全不知道，自己重新做了一份多餘的工。這種浪費在真實世界裡不會有人提醒你，你只會覺得「我做了一套還不錯的東西」，卻不知道其實根本不用自己做。

這對你有什麼用

如果你也在考慮幫 claude-mem（或任何有客製化功能的工具）設定自己的工作模式，這三輪測下來，有兩件事值得帶走：

先問有沒有現成的，再開始自己設計。 案例三證明了這一步不是形式，是真的會漏掉東西——而且漏了也不會有人告訴你。動手客製前，花十秒鐘查一下工具本身有沒有內建模式，比自己重新設計一套划算得多。

涉及密鑰、token 這類敏感設定，交給你自己的終端機輸入，不要讓任何 AI 工具代勞。 這不是我自己加的規矩，是這次測試裡 mode-creator 自己表現出來的判斷——它主動迴避了幫你貼 token 這個步驟，這個界線值得你在用其他工具時也留意一下：一個好的工具應該知道哪些事不該自己動手，不是什麼都搶著幫你做完。

還有第三件事，比較隱性，但今天測下來我覺得同樣重要：重大的設定變更，寧可讓它停在「提案、等你點頭」這一步，也不要讓它自己往下衝。 案例一裡那組查到 Telegram 通知會把 title、subtitle 這些欄位直接送到你手機，主動提醒我「這些欄位如果含敏感字眼會被推播出去」，然後才問我要不要調整隱私邊界——先講後果、再問意願，而不是先斬後奏。這種「先講清楚會發生什麼事，再問你要不要」的順序，看起來只是小細節，但決定了你會不會在事後才發現自己的資料被推到了不該去的地方。

如果你想自己接上 claude-mem

這個外掛是 Apache-2.0 授權的開源專案，thedotmack/claude-mem，在 Claude Code 裡透過外掛市集就能裝，不用自己寫設定檔。裝上去之後有幾件事值得你一開始就留意：

• 先確認它有沒有常駐成本你能接受。 每個 session 固定會多吃掉大約兩千 token 左右，這是它隨時待命、隨時能撈記憶回來的代價，如果你的用量本來就很緊，這筆成本要算進去。
• 不要一開始就急著客製模式。 先用預設的通用分類跑一陣子，等你真的感覺到「這個領域特有的東西一直被漏記」，再考慮用 mode-creator；而且動手前，先查一下有沒有現成模式可以用——今天案例三已經證明這一步不是形式。
• 牽涉到 Telegram 或任何需要貼密鑰的設定，自己動手，不要交給 AI 工具代勞。 這點今天測出來的行為本身就是最好的示範。
• 想查過去記過什麼，用 search 開頭，不要直接問它「你記得什麼」。 三步查詢法（search 找 ID → get_observations 拿全文 → 需要脈絡再用 timeline 展開）比直接發問更容易查到你要的東西，這也是我今天寫這篇時實際用的方法，不是紙上談兵。

誠實交代這次測試的限制

幾件事要講清楚，不然這篇會顯得比實際更扎實：

• 正式的 claude plugin eval 工具跑不動這份案例，因為案例檔放在 skills 目錄底下，被 CLI 明講擋掉了。今天做的是人工複現——我自己照案例原文派出乾淨的對話去跑，再對照案例作者寫的期望行為自己判斷，不是自動化工具吐出來的分數。
• 案例原本設計的是多輪互動（先問、等使用者確認、才安裝、還要重啟驗證），我這次只跑了單輪回應，沒有真的走完整個安裝流程，也沒有真的重啟過 claude-mem 或發過 Telegram 通知。這跟正式評測工具會做的完整流程不完全一樣。
• 案例一那輪意外發現這台機器上 claude-mem 目前的全域模式還是預設的 code，測試過程中沒有幫忙切換——這是會影響到其他專案記錄方式的真實設定，這個決定不該由一篇文章的測試過程順手做掉。
• 樣本數是 1，這三個案例、這一次跑出來的結果，不能直接推論成「mode-creator 永遠比通用建議可靠」，只能說這三次測到的具體差異是真的、可以查證的。
• 「沒用 skill」這組其實不是完全的空白對照——它知道自己是在回答跟 claude-mem 有關的問題，只是被明講不能呼叫 mode-creator 這個特定工具。如果換一個完全不知道 claude-mem 存在的模型來回答，結果可能會更差；反過來說，也可能因為它知道背景脈絡，答得比實際情況更好。這個變因今天沒有拆開來測，是下一次可以做得更乾淨的地方。

下次如果要補這個洞，比較嚴謹的做法會是拆成三組而不是兩組：完全不知道 claude-mem 存在的模型、知道 claude-mem 但不能用 mode-creator 的模型、用了 mode-creator 的模型——這樣才看得出「知道背景知識」跟「用了專門工具」各自貢獻了多少差異，而不是把兩件事混在一起算成同一組的功勞。

跟前四天放在一起看

寫到第五天，回頭看一下累積出來的東西，會發現每天測出來的「差異點」其實一直在換位置，這件事本身值得記一筆。Day 1 測 Atomic Commit，差異出在「任務有沒有做對」跟「Skill 有沒有被叫到」是兩回事；Day 2 測 code-review，差異出在「有沒有叫 Skill」不等於「找得準不準」；Day 4 測 context7，差異出在「模型講得篤定」不等於「答案是新的」；今天測 claude-mem，差異又換了一個位置——兩邊給出的內容品質可能差不多，真正分高下的是「有沒有先去查現場的真實狀態」。

如果只看單一一天，很容易把這些差異當成巧合，或者當成「這個 Skill 剛好比較強」。放在一起看才看得出來，這些差異背後其實是同一件事的不同切面：模型願意花時間去查、去確認、去核對現場，跟它願不願意直接憑印象作答，是決定結果好壞最常見的分水嶺——比工具本身寫得多聰明更常見。這也是為什麼這系列堅持每篇都要有 with/without 對照，不是為了湊格式，是因為只有把「有沒有去查」這個變因單獨拉出來看，才會發現它才是真正的關鍵，而不是表面上看起來的「這個 Skill 比較厲害」。

今天的判斷

今天最有意思的發現，不是「有工具比較好」，是一邊查過現場、一邊沒查，兩邊給出的內容品質可能差不多，但一邊會重複造輪子、一邊不會。這跟這系列前幾天反覆出現的主題是同一件事——篤定的語氣不能證明什麼，實際有沒有去查、查了什麼，才是關鍵。今天的差別不在文字寫得好不好，在有沒有先去看清楚現場真實的樣子。

至於「自己人」測起來會不會比較寬鬆這件事，我自己回頭檢查了一遍——三個案例的判分標準跟前四天完全一樣，沒有因為這是我依賴的工具就放過任何一個環節，包括那個尚未執行的全域設定變更，也是照著「難回收的事先問過再動手」這條線處理，沒有因為方便就自己做主。這篇能不能站得住腳，最終還是要看你自己讀完覺得是不是真的查了，而不是我自己說了算。

明天想換一個完全不同的 skill 測，這系列接下來每一篇都會是一個新的、獨立的技能卡——不刻意接續今天的角度，讓每一篇自己站得住腳，累積起來變成一份你自己就能查的 skill 選用清單。至於今天發現的那個尚未切換的全域設定，我會另外找時間自己決定要不要換，不會算進這篇的評測結果裡。