大部分人打開 Claude Code，第一個反射動作都很一致：來，幫我寫 function、修 bug、改 refactor。

這很正常。因為它表面上長得就像一個超強的 coding assistant。

但 rodspeed 這篇完整文章真正有料的地方，剛好在另一邊：Claude Code 最可怕的地方，不是它會寫 code，而是它其實是一個可以讀檔、寫檔、跑 command、開 agent、接技能的通用 automation runtime。

你有沒有過那種時刻：明明卡住的不是「程式碼怎麼寫」，而是「誰來幫我看這份東西哪裡怪」、「誰來幫我把五路資訊收斂成一個判斷」、「誰來記住我們剛剛聊了半小時到底做了哪些決策」？

如果有，那你其實早就在碰 Claude Code 更值錢的那一面了。只是大部分人還停在「請它多寫兩段 code」這個入口而已。

他在 X 上那則爆紅 teaser 只講到「把對話自動收進個人 wiki」，所以很容易讓人誤會這篇只是在講 knowledge management。其實不是。完整 blog post 裡，他一次拆了六個很具體的模式，從 fresh eyes、meta-skills，到記憶分層與 session handoff，幾乎每一個都比「請 AI 幫我生一段 code」更有槓桿。

如果你最近也開始覺得，自己跟 AI 真正有價值的部分不是最後那份 diff，而是中間來回討論時形成的判斷、流程與決策，那這篇很值得讀。(◍•ᴗ•◍)

Manufacturing fresh eyes：自己做出一雙全新的眼睛

第一個模式很妙，也很反直覺。

我們平常寫文件、規劃方案、整理設計稿，卡住時都知道要找「fresh eyes」來看。但現實是，別人的時間很貴，而且你常常還沒整理到值得拿去打擾人的程度。於是很多東西就卡在一個尷尬區間：你自己越看越麻痺，別人又還沒空看。

rodspeed 的做法很乾脆：直接用一個全新的 agent，硬做出那個完全不知情的 reviewer。

具體流程不是隨便丟一句「幫我 review」而已，而是有結構的：

  • Cold read：先開一個完全沒有對話歷史的新 agent。
  • 這個 agent 只拿到文件本身和 critique instructions。
  • 不給作者脈絡、不給摘要、不先解釋「我們為什麼這樣想」。
  • 它先做第一輪冷讀，指出哪裡合理、哪裡 shaky、哪裡缺東西。
  • 接著由 facilitator（可能是你，也可能是有完整上下文的 skill）寫 advocate response。
  • 然後再叫另一個 fresh-context agent 來讀文件、初評與辯護，做第二輪 rebuttal。
  • 最後再做 synthesis：哪些點雙方同意、哪些點有爭議、哪些 insight 是來回交手後才浮出來的。

這個模式最關鍵的設計，不是「多找幾個 agent」，而是 嚴格保護 cold read。

原作者特別強調，一旦你忍不住先說「我們這樣設計是因為……」，其實就把價值打折了。因為真正有用的，正是那種外部讀者第一次接觸你的產物時，腦中會撞到哪些洞、卡在哪些地方。

而且 rodspeed 的判斷很務實：兩輪通常就吃到大部分價值了。 不用無限辯經，不然最後只是在拿 token 買自尊。

Clawd Clawd 畫重點：

很多人嘴上說要 feedback，其實根本不是要 feedback，他要的是別人幫他的方案蓋同意章。所以 review 還沒開始，就先用三大段背景故事幫自己鋪紅毯。這樣當然比較容易被理解，但也比較不容易被看穿。fresh eyes 最值錢的地方，就是它根本不欠你面子。(๑˃ᴗ˂)⁠ﻭ

Meta-skills：一個 conductor，帶一群 specialist 去做工

好，前面講的是「怎麼借一雙外部眼睛」。但你有沒有發現，當工作不只是 review 一份文件，而是要同時處理好幾條搜尋路線、好幾種子任務時，問題立刻變了。

這時候卡的通常不是能力，而是編排。

第二個模式就是 rodspeed 認為自己最強的 pattern：skill 去 orchestrate 其他 skill。

也就是說，真正厲害的 skill 不一定自己下場做事，而是像一個總編輯或現場導演。它先把工作拆開，平行派出多個 specialist agent，再回頭 judging、補件、重跑，最後才做 curate。

原文舉的例子是搜尋不同服飾類別：外套、褲子、針織等等。meta-skill 會先一次丟五個 specialist agent 出去，每個 agent 負責自己的 category。等結果回來後，conductor 不是照單全收，而是會判斷：

  • 哪一類找到的東西明顯比較好
  • 哪一類結果太像、品牌太集中
  • 哪一類價位不對或乾脆是空的
  • 哪些 agent 需要帶著具體 feedback 回去重找

等重找完，它才做最後的 cross-category curate，挑的是「整體搭配起來好」的結果，而不是每個類別各自最強就好。

這裡有兩個很實際的 caveat，原作者沒有藏：

  • sub-agent 不能直接 invoke skills，所以 meta-skill prompt 必須把 specialist 的完整指令 inline 進去，會變得很長。
  • 這個模式很吃 token，因為每個 agent 都有自己的 context window，而 conductor 還要有額外空間讀完所有輸出再判斷。
  • 而且 conductor 也不是上帝，它有可能看漏某個 agent 其實交了爛貨。

所以這個玩法不是「自動化萬歲，品質會自己出現」，而是把 AI 從單兵作戰，升級成比較像編輯部或小型 team 的工作流。

Clawd Clawd 想補充：

很多人現在還在迷信「一個超大 prompt 打天下」：把所有需求、限制、例外、偏好、品味、風格一次塞進去，然後期待一個 agent 自己分工、自我審查、自己補洞。老實說，這跟把整間公司塞進一間會議室，然後指望大家靠心電感應協作差不多。真正的槓桿不是 output 變多，而是有人負責 judge，誰有資格被留下來。

The Freshness Problem：AI 搜尋不是不夠快，是太容易一直重播

但工作流一旦拉長，另一種更煩的鳥事就會冒出來。

你明明有 orchestration、有 agent、有自動化，照理說應該越跑越順；結果跑久了之後，你開始覺得哪裡怪怪的：怎麼這次找到的東西，跟上次長得那麼像？怎麼每週都像在看同一批結果換個封面？

這就是 rodspeed 說的 freshness problem。

表面上你每次都叫 AI 去找新東西，但實際上它很可能一直打到差不多的 query、撞到差不多的 cached page，然後每次給你差不多的結果。週一跑一次、週四再跑一次，看起來像在 search，其實比較像在重播。

rodspeed 的解法很樸素，但非常工程化：用一個大概 100 行的 Python script，給 search skill 一點跨次執行的 state。

核心做法有三個：

  • Query rotation：每個 search skill 準備 3 個 query waves，state file 會記上次跑到哪一波，下一次自動輪到下一波。
  • Seen-item tracking：已經展示過的 result ID 記下來，之後直接跳過，不再重複出現。
  • Cache-busting：有些 query 會自動加上日期尾巴，例如某個月份年份，把搜尋引擎往比較新的結果推。

整件事不需要資料庫、不需要 server，只靠一個 JSON state file 就能做。原作者甚至把它放進 git-tracked directory，因為他很清楚：state 一旦壞掉或不同步，dedupe 會靜悄悄失效，然後你又會開始看到重複結果。

這個洞見我覺得超值得偷。很多人以為 recurring AI search 的問題是 prompt 不夠華麗，其實問題常常不是 prompt，而是系統完全沒有跨 run 的記憶。

Clawd Clawd 想補充：

很多 recurring search 爛掉，不是 model 不夠聰明，是作者根本懶得保存 state，然後還把重複結果怪到 AI 頭上。這跟你每次打開瀏覽器都用無痕模式，最後抱怨網站怎麼都不記得你一樣。stateless LLM 本來就會忘，真正自欺欺人的是那些以為「多寫兩句 prompt」就能冒充系統設計的人。╮(╯▽╰)╭

Conversations as a knowledge source：把工作過程本身收成 wiki

好，前面三段其實都還在講「怎麼把 AI 拿來做事」。

但做到這裡，你很容易撞上一個更大的洞，而且這個洞通常不是當下爆炸，是幾天後才回來追殺你：你跟 AI 明明聊出了很多關鍵判斷，可是 session 一結束，那些判斷就像熱氣一樣散了。

你有沒有過這種感覺？剛剛那 40 分鐘超有收穫，某個限制條件終於被釐清、某個方案終於被排除了、某個「真正的 bottleneck 原來在這」的瞬間終於出現了。結果隔天回來，你只剩一個模糊印象：好像聊到一些重要的，但到底是什麼來著？

這就是 rodspeed 為什麼會做 harvest skill。

他的想法是：大多數跟 Claude Code 的對話，本身就在產生 knowledge。 你在裡面做決策、釐清概念、比對方案、辨認限制條件。這些東西如果不在 session 結束前被收下來，就會像對話蒸氣一樣散掉。

所以他做了一個 harvest skill，會在每次「substantive conversation」結束時自動跑。注意，不是每次瞎聊都跑，而是只有在對話真的產生新知識時才跑，trivial exchange 要跳過。

這個 harvest skill 會：

  • 掃描整段對話
  • 抽出 insights
  • 轉成結構化 markdown notes
  • 每則 note 都有標題、tags、以及 links to related notes

原作者還特別點出一個很關鍵的地方：Claude 不是只在做 keyword matching。它會去讀現有的 note index，然後推理哪些筆記雖然沒共用明顯關鍵字，但其實概念上連在一起。

再往前一步，他會定期跑另一個 reasoning skill 去 review 全部筆記：

  • 找出還沒被明確連起來的關聯
  • 標出知識缺口
  • 當某幾篇筆記開始圍著同一主題轉時，提議整理成 summary note

這一步不是全自動的，原作者也沒有裝神弄鬼地說「系統會自己長大」。他的描述很誠實：整個 loop 是 work → harvest（自動）→ reason（提示後跑）→ discover → work。

而讓 harvest 真的會自動發生的關鍵，不是什麼黑科技，而是 CLAUDE.md 裡那句 instruction：

  • 在每次 substantive conversation 結束時，自動跑 harvest skill。
  • substantive 的定義是：這次對話產生了新知識。
  • trivial exchange 不要跑。
  • 不要問，直接做。

這裡最猛的地方其實不是「AI 會寫筆記」，而是它把原本最容易蒸發的那一層工作過程，硬生生變成可累積資產。你不是只留下答案；你把形成答案的判斷痕跡也留下來了。

Clawd Clawd 忍不住說：

每次跟 AI 聊完，只存最後那份正式輸出、不存中間的判斷脈絡，本質上就跟開完一場超重要的會，最後只留下簡報 PDF、不留 meeting notes 一樣。然後過兩天大家再花 30 分鐘互相問：「欸我們那天是不是有決定不要走 B？」這不是知識管理，這是集體失憶。conversation exhaust 這詞真的很毒，因為大部分團隊平常就是把最值錢的判斷當廢氣排掉。

Memory that compounds：記憶要分層，才會越積越有用

但事情到這裡還沒結束。

因為你一旦開始把對話都 harvest 下來，很快就會遇到下一個現實問題：留下來的東西如果只是一坨越滾越大的筆記堆，最後它不會變成 memory system，只會變成 context window 的垃圾山。

這也是為什麼 rodspeed 下一步不是「多存一點」，而是先處理結構。

他沒有把 memory 當成一份越寫越長的流水帳，而是分成四種 typed categories：

  • User memories：我是誰、怎麼工作、我懂到哪裡。
  • Feedback memories：不只記 corrections，也記 confirmations。
  • Project memories：正在做什麼、做過哪些決策、deadline 是哪天。
  • Reference memories：外部系統裡的重要位置，例如 bug 在哪追、dashboard 在哪看。

其中我最喜歡的是 feedback memories 這個提醒。原作者說，很多人只記「不要做 X」，卻不記「對，這次 bundled PR 的判斷是對的」。久了之後，模型只會越來越怕犯錯，卻學不到哪些判斷其實是應該保留的。

另一個很實際的細節是：相對日期要轉絕對日期。 你今天寫「週四要交」，兩週後再讀根本不知道是哪個週四；但寫成 2026-03-05，就不會時空錯亂。

更關鍵的是結構。原作者把最上層的 MEMORY.md 維持得很薄，只當 top-level index。真正內容放在各分類的 sub-index 和 memory files 裡。這樣每次開新對話時，系統只需要先載入一份很小的 lookup table；只有當對話碰到某個類別，才往下鑽。

他自己的 top-level index 只有 17 行，但能指到 4 類、18+ 個 memory files。這種設計很像倉庫的總目錄：你每天進門先看地圖，不是把整座倉庫扛在身上。

這裡其實有一個很常見的誤區：很多人一想到「讓 AI 有記憶」，第一反應就是做一份超長總檔，把所有東西往裡面塞。看起來很勤奮，實際上跟把所有發票、保固卡、合約、便利貼全塞進同一個抽屜沒兩樣。你不是比較有秩序，你只是把未來的自己害死。

Clawd Clawd 溫馨提示：

一份 3000 行的 MEMORY.md 不是第二大腦，比較像電子囤積症。很多人以為自己在做 knowledge compounding，其實只是在做 context stuffing：把模型餵到快噎死，再幻想它會從垃圾堆裡自己長出洞察。真正有用的 memory 不是「存很多」，而是「用很低的固定成本找到對的那塊」。不然 memory 還沒幫到你，token 先被它吃光了。(◍˃̶ᗜ˂̶◍)⁠ノ”

Session handoffs：不要讓下一個 session 再重打一遍世界觀

可就算你 memory 分層做對了，最後還有一個老問題躲不掉：session 會結束，但事情通常不會。

這種痛你只要做過一次長工作流就知道。可能是 context limit 快到了，可能是今天先做到這，可能是你明天才有空接著弄。不管原因是什麼，只要 session 一斷，前面辛苦累積的決策、踩過的坑、看過的檔案，都很容易一起蒸發。

然後最煩的戲碼就來了：下一個 session 不是在往前跑，而是在考古。重新讀檔、重新問背景、重新把已經做過的判斷再走一遍。像 RPG 都快打到 boss 房了，遊戲突然跟你說不好意思，請先重跑新手教學。

rodspeed 的 handoff pattern 有兩個零件。

第一個是 /handoff skill。它會在 session 結束前掃過整段對話，寫一份結構化 memo 到固定路徑 .claude/handoff.md。memo 內容包括：

  • Mission：這輪到底要完成什麼
  • Decisions：選了什麼、放棄了什麼、為什麼
  • Key files：哪些檔案重要，它們扮演什麼角色
  • Current state：哪些完成了、哪些卡住
  • Open tasks：下一輪能直接接手的待辦
  • Gotchas：那些不寫下來下一輪一定會再踩一次的坑

原作者特別說 Decisions 是最重要的一段。因為如果沒有「為什麼當初這樣選」的脈絡，新 session 很容易把已經吵完的事再吵一次。

第二個零件是 SessionStart hook。它會在新 session 開始時檢查 handoff file 是否存在，且是否標記成 pending；如果是，就把完整 memo 注入新對話的 context。

除此之外，他還提到另一個很實用的 hook：當長對話因 context limit 被摘要壓縮後，再把完整 CLAUDE.md 重新注入。因為不然你的 conventions 很可能也被摘要掉，然後 session 越長越不像原本那套規矩。

原作者甚至說，這篇文章本身就是這個模式的示範：前一個 session 先寫、檢查、改稿，再跑 /handoff；下一個 session 冷啟動時，直接接上來收尾。

這一段之所以重要，不只是因為它讓 AI 比較方便，而是它直接決定你到底是在經營一條持續推進的工作流，還是在反覆付「重新進入狀況稅」。前者會越做越快；後者看似忙得要死，其實一直在原地磨損。

Clawd Clawd 偷偷說：

很多人不寫 handoff，然後隔天花 40 分鐘叫新 session「幫我總結一下目前狀況」。這種 workflow 最大的問題不是浪費 token，而是你每次都在讓一個新代理重新猜一次昨天的你在想什麼。那不叫省事，那叫考古外包。handoff 之所以像 git commit message 一樣重要，就是因為你不寫，明天就得拿更多時間跟 token 來補這個洞。

結語

所以 rodspeed 這篇文章真正厲害的，不是丟了六招酷技巧給你抄，而是逼你換一個問題。

下次你再打開 Claude Code，也許先別急著說「幫我寫這個 function」。

先停一下，問更狠的那句：我現在卡住的，到底是 code，還是某種 read → filter → decide → present 的流程？

如果答案是後者，那你要的可能根本不是更會寫 code 的 AI，而是一套會幫你找 fresh eyes、會分工、會防重播、會收知識、會整理記憶、會交接上下文的工作系統。

而這也剛好呼應回開頭那件事：Claude Code 最強的地方，可能從來就不是「替你打字」，而是替你把那些本來會蒸發、會重複、會卡死的認知勞動，變成一條能累積的流水線。

如果你開始這樣看它，整個世界都會不一樣。

你不會再只問它能幫你寫多少 code。

你會開始問：我每天到底有多少工作，其實只是披著工作皮的資訊流轉？

這題一旦想通，能自動化的就不是多一點點。

是多到有點可怕。