2026年的 Claude Code：層次比工具更重要

我在同一週裝了 gstack、Superpowers 和 Compound Engineering。三個口碑不錯的 Claude Code 擴充功能，各有一批忠實用家。我的預期是生產力會累加式地提升。結果換來的，是功能重疊、覆蓋缺口，以及一種揮之不去的感覺——我在收集工具，卻沒有任何評估框架。

同時跑了幾天之後，我找到了真正的問題所在。不是我不擅長選工具，而是我看不見層次。

層次在實踐中的樣子

AI 編程已經把人類的角色從寫程式碼轉移到協調代理。協調需要一套心智模型，而最終讓我豁然開朗的，是一個三層結構：決策層、流程層、知識層。我看過的每一個工具，都在某一層很強，在其他層很弱。一旦看清楚這件事，那些重疊和缺口都說得通了。

決策層

gstack 的 /plan-ceo-review 從產品角度審視工作，/plan-eng-review 從架構角度審視。兩者都在你寫下第一行程式碼之前執行。目的是把壞主意扼殺在萌芽階段。

我原本以為編程階段才是瓶頸，事實並非如此。最大的時間黑洞，是在開發那些根本不應該啟動的功能。用了 gstack 的關卡兩週之後，我發現品質的差距不在於寫出更好的程式碼，而在於寫了更少不必要的程式碼。Garry Tan 據報在這套設定下，60天內交付了60萬行程式碼。/qa 指令會開啟真實瀏覽器，像用家一樣點擊應用程式，能捕捉到單元測試完全遺漏的問題。

gstack 的不足之處：它沒有跨對話的記憶，每次審查都從零脈絡開始。

流程層

Superpowers 把工作結構化為腦力激盪、計劃、執行、審查的循環。12萬個 GitHub 星是實至名歸的。從「直接叫 AI 去做」到一套可重複的工作流程，輸出的一致性立竿見影。

我以為這就夠了，但並不。工作流程在單次對話內運作流暢，但第二天開新對話的那一刻，昨天學到的一切全部消失。子代理式的規格審查和程式碼品質審查都包含在內，運作也不錯。但系統的任何部分都沒有記錄昨天發生了什麼，以便影響今天的工作。

知識層

Compound Engineering 的 /ce:compound 指令在你完成一項任務之後執行。五個子代理並行啟動：追蹤對話脈絡、提取解決方案、檢查重複文件、生成預防策略、分類結果。所有內容都存入 docs/solutions/。

用了一週之後，我碰到一個跟之前修復過的問題相似的錯誤。在規劃階段，系統找到了之前的記錄並把解決方案呈現出來。一個本來可能耗費數小時的除錯工作，幾分鐘就解決了。/ce:review 會並行啟動至少六個獨立審查員，/ce:plan 在提出任何建議之前都會先查看 git 日誌和專案歷史。

如果說 Anthropic 的進度文件是輪班工人之間的交接記錄，Compound Engineering 的 docs/solutions/ 就是整個團隊每天都在翻閱的食譜資料夾。

找出你的空缺層

重點不是你應該裝這三個特定的工具。重點是一旦你能看見這三個層次，就能評估任何工具，或者自己搭建。

我把三個工具同時跑了一週，才意識到冗餘集中在流程層，而知識層空置了好幾個月。找出那個缺口，比任何工具裡的任何單一功能都更有價值。

審視一下你自己的工作流程。有沒有一道決策關卡，能在壞主意變成程式碼之前把它擋下來？有沒有一套每次都以同樣方式執行的定義流程？有沒有一套記得你上週學到什麼的知識系統？先找到空缺的那一層，然後填上它，哪怕那意味著自己寫一個 SKILL.md 文件，而不是安裝別人的框架。

看見層次的能力，比生態系統裡的任何具體工具都更為長久。