導讀
這波 AI 工具熱最容易讓人搞錯的，不是名字太多，而是你很難一眼看出它們在補哪個洞。有人在談 MCP，有人主打工作流程，有人強調知識會愈用愈多，也有人專做第二次檢查。這篇文章只談 開發工作流程 相關的工具，不把所有聊天機器人、單功能外掛都混在一起，這樣比較看得清楚。
你最近是不是也有這種感覺？
打開社群，新的 AI 工具一排排冒出來。
每個都說自己能省時間。
結果你愈看愈亂。
問題通常不在「哪個最強」，而在另一件事：
它到底是在幫你接工具、管流程、存知識，還是做驗證？
只要把這件事想清楚，整個生態就沒那麼吵了。
我們可以把它拆成 三層：底層先解決連接，中層處理工作流程，上層再補上品質驗證。
第一層：先把工具接起來
MCP 是這波工具生態真正的底座，因為它把 AI 接外部工具的方式標準化了。
如果把 AI 助手想成一位新同事，它第一天最需要的不是華麗技巧，而是插座。
插得上，才做得到。
MCP（Model Context Protocol）可以把它想成 AI 時代的 USB。
在 USB 普及以前，每台裝置都有自己的接頭。很麻煩。
MCP 想解的，就是同一種混亂。
它把常見互動整理成三個核心概念：
- Tools：AI 可以做的動作，像是查資料庫、跑程式、送出請求。
- Resources：AI 可以讀的資料，像檔案、系統狀態、API 回應。
- Prompts：可重用的提示模板，讓反覆任務不必每次重講。
底層一旦標準化，整個生態才有機會長大。
不然每加一個工具，就要再寫一次接法。
那不是生態，是接線地獄。
MCP 現在常見的傳輸方式包括 stdio 和 HTTP+SSE。
你不一定要背規格，但可以記住一件事：標準化做得好，整合成本就會從「每次重接」變成「接上就能用」。
圖說：用插座、流程節點與檢查符號把三層生態疊成一座系統塔，從底部連接、中段流程，到頂部驗證，一眼看懂工具各自在補哪個洞。
第二層：真正拉開差異的，是工作流程
工具能連起來之後，差距就不在功能表，而在你怎麼把這些功能排成一條可重複的工作路徑。
真正拉開差距的，不是「會不會叫 AI 寫東西」，而是「你的流程能不能穩定重跑」。
這也是為什麼 2026 年的討論愈來愈像流程設計，而不是單點功能比較。
這一層可以先看三個代表方向：gstack、Superpowers、Compound Engineering。
它們不是誰打誰。
比較像不同工種。
gstack：幫你從不同角度做決策
gstack 的強項很明確：決策與測試。
像 /plan-ceo-review 看商業角度，/plan-eng-review 看技術角度，/qa 則把測試拉到真實瀏覽器環境。
這種工具很適合你正在評估功能、審產品、看風險的時候。
你不是要更多點子。
你要第二雙眼。
Superpowers：幫團隊把步驟踩穩
Superpowers 比較像流程紀律官。
它重視的是工作如何拆解、如何交接、如何讓不同人按同一套節奏前進。
這很適合有固定流程的團隊。
優點是穩。
代價也很明顯：如果團隊還在快速變形，流程過重時會讓人覺得卡手卡腳。
而且它比較像單次會話內的秩序管理，知識未必會自然沉澱到下一輪。
Compound Engineering：把每次工作變成下次的捷徑
Compound Engineering 最有意思的地方，是它把焦點放在 知識累積。
不是今天做完就算。
而是今天做完，明天能不能少走一段路。
它主打的流程是 5 階段：
- 判斷這是什麼問題型態
- 找到對應解法
- 連回相關文件
- 抽出預防策略
- 用
/ce:compound把脈絡存進可搜尋知識庫
差別就在這裡。
別的工具可能像每次都重寫一份報告。
Compound Engineering 比較像一邊解題，一邊把你自己的作戰手冊補厚。
三類工具放在一起看
| 向度 | gstack | Superpowers | Compound Engineering |
|---|---|---|---|
| 主要強項 | 決策、測試 | 流程紀律 | 知識累積 |
| 跨會話延續 | 有限 | 有限 | 完整 |
| 成長曲線 | 線性 | 線性 | 複利式成長 |
| 最適合誰 | 小到中型專案 | 流程固定的團隊 | 長期專案與知識密集團隊 |
為什麼大家愈來愈重視「知識會不會留下來」？
很多團隊卡住的，不是今天這題做不完，而是同一題下週又重做一次。
想像兩種情況：
- 第一種：每次碰到問題，都重新問一次 AI
- 第二種：每次解完問題，都能留下可搜尋、可延續的脈絡
短期看起來差不多，長期差很多。
前者像在反覆救火，後者像在慢慢搭一套自己的作業系統。
這也是為什麼 Compound Engineering 會被很多人單獨拉出來談。
它賣的不是某個指令，而是那條知識曲線。
| 時間拉長後會看到什麼 | 線性流程 | 複利型知識流程 |
|---|---|---|
| 第 1 次做任務 | 速度差不多 | 速度差不多 |
| 第 5 次做相似任務 | 仍靠個人記憶 | 開始能調用舊解法 |
| 第 10 次做相似任務 | 還在重講背景 | 已有可搜尋案例與預防策略 |
對個人工作者來說，這代表你不用每次都從空白頁開始。
對團隊來說，這代表成員更替、交接、專案切換時，資料不會整批掉進黑洞。
互動小問題
你現在最缺的，其實是哪一種？
是「工具接不起來」、還是「流程常常亂掉」、還是「經驗沒辦法留下來」？
想清楚這一點，比急著追最新工具清單更重要。
Compound Engineering v2.60.0 在補什麼？
這個版本最值得注意的，不是新名詞，而是把「知識型工具」往可落地的工程流程再推近一步。
先看最醒目的數字：49%。
根據專案簡報，v2.60.0 把誤判率壓低了 49%，做法是把強制程式碼審查和信心評分綁在一起。
換句話說，系統不只告訴你「哪裡可能有問題」，還會一起說「我對這個判斷有多確定」。
這有什麼差？
差在團隊終於能把警示分級。
你不用把每一條提醒都當火警。
第二個重點是 /ce:work 變得更靈活。
不同任務可以跑不同階段，順序也能調。
這很重要，因為不是每次都需要全套流程。
第三個重點是互動式規劃。
工具不再拿到需求就硬做，而是先往回問幾句，把邊界講清楚。
少走回頭路。
很實際。
第三層：最後還是要回到品質驗證
AI 產出變快之後，真正值錢的能力反而變成第二次檢查。
所以生態的第三層，通常會落在驗證。
不管名字叫 review、QA、handoff，核心都一樣：不要只看第一份答案。
Codex：讓不同角度來挑你的毛病
如果把工作交給另一位 AI 再看一次，甚至故意要求它唱反調，很多盲點會浮出來。
這就是 Codex 在驗證層的價值。
常見做法包括：
- 標準審查：看有沒有違反既有規範
- 對抗式審查：刻意找反例、找漏洞
- 任務交接驗證：確認別人接手時看得懂
- 多廠商驗證：不要永遠只信同一個模型
Claude Code + Stitch 2.0：把設計和實作接上
另一條路則是把設計與實作明確串起來。Stitch 2.0 能先產出 UI 與 design.md，Claude Code 再透過 MCP 接著實作。
這樣的好處是，你不是丟一句「幫我寫程式」就開跑，而是先有規格，再有實作。
流程可以很白話地寫成：
設計稿 → design.md → 程式實作 → 審查 → 驗證
這一層特別適合高風險專案。
像醫療、金融、基礎設施，少一次檢查都可能太貴。
不過，這也不是說每個小任務都要全套上陣。
寫一段小腳本、改一個內部工具標籤，未必值得拉整條驗證鏈。
驗證層最適合高風險、高交接、高成本失誤的工作。
這個邊界要講清楚，不然流程很快會變重。
對外行人來說，其實很好懂。
文書要校稿。
財報要複核。
AI 產出也一樣。
圖說：把 AI 生成、人工或多工具審查、修正調校與最終核可排成一條生產線，提醒讀者效率與品質其實可以一起設計。
Boris 還有 6 個常被忽略的進階功能
如果前三層是主戰術，Boris 的進階功能就比較像高手才會翻出來的暗器。
/loop：把同一個任務每 5 到 30 分鐘自動重跑一次，適合監控和長任務。git worktrees：讓你在不同工作樹並行開發，不必一直切 branch。/batch：把工作拆散後平行處理，適合大型專案。--bare：跳過一部分初始化流程，啟動更快。--agent：建立自訂代理角色，讓工具記住你的工作習慣。/voice：用說的，不用打字，適合腦中整理想法的時候。
這些功能不一定每天都用。
可是一旦用對場景，差很多。
那普通人該怎麼組自己的工具棧？
最實際的做法，不是一次買滿，而是照「連接 → 流程 → 驗證」的順序一層一層加。
最實際的方式，不是背工具名單，而是用三個問題來判斷：
- 它是在幫我接工具，還是在幫我管流程？
- 它有沒有讓我的知識留下來？
- 它有沒有補上品質驗證這一段？
如果一個工具只會讓流程更熱鬧，卻沒有讓工作更穩定，那它未必真的適合你。
反過來說，如果一套工具看起來不花俏，卻能讓連接更順、流程更清楚、知識能延續、品質可檢查，它往往更有長期價值。
你也可以用下面這張表先做第一輪判斷：
| 你的情境 | 最大痛點 | 先上哪一層 | 建議組合 |
|---|---|---|---|
| 個人開發者 | 背景常重講、知識散掉 | 連接 + 知識累積 | MCP + Compound Engineering |
| 3-10 人小團隊 | 決策分散、品質不穩 | 連接 + 流程 + 驗證 | MCP + gstack + Codex |
| 中大型研發團隊 | 規範、交接、知識資產 | 三層都要 | MCP + Superpowers + Compound Engineering + 驗證鏈 |
三種常見配置
| 配置 | 核心組合 | 為什麼這樣配 |
|---|---|---|
| 個人版 | MCP + Claude Code + Compound Engineering | 一個人最怕每次從零開始，先把知識留住最划算 |
| 小團隊版 | MCP + gstack + Compound Engineering + 視情況加 Codex | 決策要快，知識也要留，必要時再補第二次審查 |
| 企業版 | MCP + Superpowers + Compound Engineering + Codex + Claude Code + Stitch | 流程、合規、交接、驗證一起考慮，不能只拚速度 |
結語：真正值得觀察的，不是哪個工具贏，而是哪種能力留下來
AI 開發工具的變化速度很快，今天熱門的名字，半年後可能就換了。
但有些底層方向大概不會變：
- 工具之間需要更好的標準化連接
- 團隊需要更穩定的工作流程
- 知識需要能持續累積
- 重要輸出需要更可靠的驗證機制
所以，與其把這波工具潮看成一場排行榜競賽，
不如把它看成一個更成熟的訊號：
大家開始從「能不能做」走向「怎麼做得穩、做得久、做得可交接」。
你要追的，從來不是名單本身。
而是這些能力有沒有被你真的裝進工作裡。
這才是 2026 年 AI 工具生態最值得一般讀者關注的事。
延伸閱讀建議
- MCP 官方文件
- 各類 AI 開發工具的官方產品頁與更新紀錄
- Compound Engineering 與知識管理案例
- Claude Code、Stitch 2.0 與多代理驗證相關文件
常見問題
我是 5 人小團隊，該從哪裡開始？
先把 MCP 和核心開發工具接起來。如果你們現在最痛的是決策不一致，就先加 gstack；如果你們反覆踩到同一類問題，就把 Compound Engineering 拉進來。小團隊需要一些流程，但通常不需要最重的流程。
Compound Engineering 的學習成本會不會太高？
會有一點，因為它要求你在解題同時留下可重用脈絡。不過 v2.60.0 至少把上手門檻再壓低一些，像信心評分和互動式規劃，都是在減少第一次接觸時的摩擦。最穩的做法還是先拿小專案試。
我真的需要把三層都裝滿嗎？
不用。對很多個人開發者來說，先把底層標準化做好，再把知識留住，就已經很有用。驗證層通常是在品質風險高、跨人交接多，或錯誤代價很高的情況下，才從加分題變成必答題。