Superpower vs Crew — 兩套 Claude Code 技能架構，企業到底該選哪一套

回頭看 Claude Code 的 skill 機制剛出來那陣子，大家其實沒人知道該拿它幹嘛。

那時候的 skill 就是一個資料夾、一個 SKILL.md，裡面寫幾句「遇到 X 你就照 Y 做」。聽起來很美好，實際上呢？多數人裝了三五個 skill，跑了兩天，發現它們各自為政，沒有一條主線把它們串起來。你叫 AI 寫功能，它有時候記得用 TDD，有時候又忘了；有時候會先 brainstorm，有時候直接動手寫一坨。skill 是有了，但「什麼時候該用哪個 skill」這件事，還是塞在工程師自己腦袋裡。

一年後的今天，這個混沌期結束了。市面上演化出兩種完全不同的解法，而且兩種都很成熟。一種是 Anthropic 自己下場做的 Superpower，一種是企業內部長出來的 Crew。它們解的是同一個痛，路線卻徹底分岔——分岔到你幾乎可以說，它們對「AI 該怎麼幫人寫程式」這件事的世界觀根本不同。

今天就把這兩條路攤開講清楚。如果你正在幫團隊評估要導入哪一套，這篇就是寫給你的。

先講最關鍵的那一刀：通用方法論 vs 領域工作流

決定一套架構長什麼樣的，從來不是它有多少功能，而是它選擇不做什麼。

Superpower 選擇不碰領域。它的定位是「如何工作」——brainstorm 怎麼做、計畫怎麼寫、TDD 紅綠燈怎麼跑、code review 怎麼進行。它教的是一套放諸四海皆準的開發紀律，Python 能用、Rust 能用、TypeScript 也能用。它身上只有一個硬依賴：Git。除此之外什麼外部服務都不要。

Crew 選擇不做通用。它的定位是「做什麼事」——從 /plan-start 建任務、/plan-spec 寫規格、/plan-db 設計資料表、/plan-build 多 Agent 產碼，一路到 /plan-close 結案同步知識庫。它整條管線是為了真實的企業開發流程量身打的，背後綁著 Notion、Git、Agent Teams、Playwright 一整串依賴。

這一刀切下去，後面所有的差異都是它的延伸。一個刻意把自己做薄，薄到任何專案都能套；一個刻意把自己做厚，厚到能接住一個功能從需求到上線的每一步。哪個比較好？這問題問錯了。該問的是：你的痛在哪一端。

第二條時間線：從「一個人寫」到「一隊人寫」

skill 機制早期有個隱藏假設——所有事都是一個人（或一個 AI）線性做完。Superpower 完整繼承了這個假設，而且做到極致。

它的設計就是讓一個人跑完整個開發流程：brainstorm → plan → execute → verify → finish，各個 skill 按 SDLC 階段排好，彼此獨立又有隱式串接。沒有中央調度器，靠的是 session 啟動時注入的一段心智模型，引導 AI 自己在對的時機選對的 skill。設計文件就丟在 docs/superpowers/ 底下，用 git commit 一路追蹤。乾淨、輕、好懂。

但企業開發從來不是一個人的事。Crew 走的是另一條時間線——它假設你有一隊人，而且這隊人需要互相看見對方在幹嘛。

於是 Crew 長出了 .spec/ 這個本地單一真理來源，Notion 當協作視圖，Git 當版本記錄，三方同步。更狠的是它支援 Agent Teams 多 Agent 模式，最多五個分身並行：一個顧資料表、一個寫後端、一個拉 API、一個刻前端、一個補測試，Leader 在上面調度。一個完整的 CRUD 功能——八個 Java 類別、兩個 JSP、一個 SQL——從架構文件到產出大概三到五分鐘。同樣的東西人工大概要兩到四小時。

這裡要誠實說一句：Agent Teams 還是實驗功能，API 隨時可能變。你押這條線，得接受它偶爾會翻車。但方向是對的——當產碼變便宜，瓶頸就從「寫得多快」移到「協調得多好」，而協調這件事，單人模式天生做不到。

第三條時間線：可觀測性，從 git log 到一整面儀表板

東西做出來了，怎麼知道它對不對？這是第三個分岔點，也是企業最容易忽略、上線後最容易出事的地方。

Superpower 的可觀測性基本上就是 git history 加上 TodoWrite 即時清單。你想知道剛剛發生了什麼，去翻 commit。簡單、夠用，但它沒有結構化的驗收結果，沒有審查報告，沒有「這次到底通過了哪些檢查」的明確狀態。團隊成員想看進度？只能從 commit 訊息腦補。

Crew 在這塊堆得很重。log.md 追全流程、files.md 記產出清單、verify.md 存 Playwright 驗收的 Health Score 加截圖證據、review.md 放三人 Agent 審查報告。最關鍵的是它有結構化的退出驗證——S1~S7、E1~E7 這些檢查點，每一步通過或失敗都有明確狀態，而且全部即時同步到 Notion，DBA、SRE、PM 打開頁面就看得到。

我自己踩過一個坑特別有感：有一次新功能上線，忘了執行對應的部署 SQL，結果功能上去就是不能用，連夜 hotfix 重新部署。Crew 的退出驗證會自動把 deploy.sql 生出來，還同步到 Notion 讓資料庫負責人也看得到。這種「上線遺漏」的成本，遇過一次就再也不想遇第二次。

不過反過來說，這套重型可觀測性是有代價的——維護成本。Notion 欄位對照、技術棧定義、團隊組成規則、四層 context 策略，每次 Notion 改個欄位或新增一個技術棧，你都得回來更新設定。Superpower 那邊壞了就一句 claude plugin update 重裝，乾淨俐落，代價是你完全不能客製化，skill 內容由 Anthropic 說了算。

那些只有一邊有的東西

把獨門武器列出來，選型的輪廓就清楚了。

Superpower 獨有的，是那些「怎麼把開發做對」的硬紀律：TDD 的紅綠燈循環、Git Worktree 隔離開發、通用 brainstorming 框架。這些是 Anthropic 認為「官方推薦做法」的東西，你拿來當學習 Claude Code 最佳實踐的教材，再適合不過。

Crew 獨有的，是那些「把開發接到組織」的工程：Notion 任務生命週期管理、Agent Teams 多人產碼、Playwright 自動驗收加 Health Score、deploy.sql 自動產出、跨 session 的知識庫累積、三層安全掃描。最後這個知識庫累積特別值錢——每個功能結案自動進功能設計庫，每個 Bug 結案自動進 Bug 知識庫。新人 onboarding 不用再去找「當初做這功能的那個人」，搜知識庫就有歷史決策。知識不隨人走，這是組織最難買到的東西。

所以，到底選哪個

我不打算給你「各有優缺點，看需求」這種廢話。有立場才有用。

如果你是這幾種情況，選 Superpower： 你在做快速 prototype 或 side project，一個人就能搞定，不需要 Notion 追蹤；你的專案不是 Java/Spring（Crew 的技術棧支援目前還是以這條線為主）；你的團隊根本還沒在用 Notion，不想多吞一層整合成本；或者你只是想學 Claude Code 的最佳實踐——那 Superpower 就是教科書本身。

如果你是這幾種情況，選 Crew： 你在帶一個企業內部的 Java/Spring 團隊，技術棧完全對齊；你需要 Notion 做任務管理，要自動建立、更新、結案；你是多人協作而且必須追蹤進度；你被部署安全咬過，想要 deploy-checklist 加 deploy.sql 加三層安全掃描這種多重防線；或者你的 Bug 需要結構化處理，要假說驅動調查加知識庫回饋。

但這裡有個多數人沒想通的點：這兩個根本不是二選一。

Crew 不覆寫 Superpower 的 skill，它們各自觸發。你完全可以用 Crew 管任務生命週期跟產碼管線，同時用 Superpower 的 TDD 跟 brainstorming 補開發紀律。對企業 Java 團隊，我的實際建議是 Crew 為主、Superpower 為輔：拿 Crew 當端到端的工作流引擎，拿 Superpower 當開發紀律的內功心法。

推不動團隊的時候，從哪裡下手

選好了還有最後一關——保守型團隊不會因為你說「這個很潮」就買單。平均年資五年以上、習慣 IntelliJ 加 GitLab 加人工 review 的後端團隊，你得用他們的誘因說服他們，不是用你的熱情。

阻力最小的切入點是 Bug 流程。你不要一上來就喊「我們全面導入 AI 工作流」，你就問一句：「我們上個月有三次 hotfix 是因為忘了跑部署 SQL，如果有個指令能自動建追蹤、自動結案同步，要不要試一個 sprint？」——這是他們真實的痛，不是你的願景。

跑順了再 demo 產碼能力，讓他們親眼看到從規格到可編譯程式碼只要十五分鐘。等到團隊習慣了 Notion 追蹤跟 .spec/ 目錄，驗收跟安全掃描自然會被他們自己撿起來用。至於那句經典反對——「AI 產的 code 我不信任」——答案很簡單：Crew 從來不取代 code review，/plan-review 只是 review 前的自動預檢，抓掉八成低級問題，讓人工 review 專心看架構跟業務邏輯。最終要不要合，還是人決定。

skill 從一個沒人知道怎麼用的資料夾，走到今天兩條成熟卻完全不同的路線，才一年。下一年會怎麼分岔，沒人知道——但有件事已經很清楚：贏的不會是功能最多的那套，而是最清楚自己「不做什麼」的那套。