為什麼 AI 助手需要「角色切換」？Gstack 的核心邏輯

有一個場景你可能不陌生：

你叫 Claude 「幫我 review 這段程式碼」。它回了一大段，看起來很完整——架構建議、命名規範、幾個小 bug。你照著改了，commit 上去，隔兩天 production 出問題，追了一個小時才發現是個 race condition，就在那段它「review 過」的程式裡。

不是 Claude 不夠聰明。是你讓它用「通用助手」的腦袋在做「偏執型資深工程師」的工作。

這兩件事，差很遠。

一個對話打天下的代價

大多數人用 Claude Code 的方式，是把所有問題扔進同一個 context：

「幫我設計這個功能的架構。」
「好，現在幫我寫實作。」
「寫完了，幫我 review 一下。」
「review 完，幫我開一個 PR。」

每一步都在同一個對話裡，AI 每一步都用同一個「模式」在回應。表面上很流暢，實際上是——

架構設計的時候，它沒有充分問你「這個功能值得做嗎」。
程式碼審查的時候，它看的是語法和風格，不是 production 級的 failure mode。
開 PR 的時候，它沒有確認 tests 有沒有跑、主分支有沒有 sync。

每個環節都做了，每個環節都只做了七分。

Gstack 的核心思維：認知模式是可以切換的

Garry Tan 在設計 Gstack 的時候，問的是一個很根本的問題：

「如果我今天有一個真實的開發團隊，每個角色在思考什麼？」

CEO 在想的是：這個功能值不值得做？使用者真正的問題是什麼？有沒有更好的 10 倍解法？
Engineering Manager 在想的是：這個架構有沒有隱藏的 failure mode？async 邊界在哪裡？test coverage 夠嗎？
資深工程師在 review PR 的時候在想的是：N+1 query、race condition、trust boundary violation——那些能過 CI 但會在 production 爆掉的問題。
Release Engineer 在想的是：branch 有沒有跟 main sync？tests 有沒有都過？PR 描述完整嗎？

這些角色，思考的「頻率」完全不同——你不能用一個通用提示詞把它們全部召喚出來，效果一定是稀釋版。

Gstack 做的事很簡單：把這些認知模式，各自包裝成一個 skill，用 slash command 明確切換。

九個 Skill，九種認知模式

Gstack 目前提供九個核心 skill：

Slash Command	角色	在問什麼
`/plan-ceo-review`	Founder / CEO	這個功能值得做嗎？有沒有更好的解法？
`/plan-eng-review`	Engineering Manager	架構、資料流、edge case、test coverage
`/review`	偏執型資深工程師	能過 CI 但會在 production 爆的問題
`/ship`	Release Engineer	Sync、test、push、PR 一條龍
`/browse`	QA Engineer（有眼睛版）	用真實瀏覽器點你的 app，截圖驗證
`/qa`	QA Lead + 修 bug	找問題、修問題、驗證修好了，輸出健康分數
`/qa-only`	QA Reporter	只報告，不動你的程式碼
`/setup-browser-cookies`	Session Manager	把你的真實 cookies 匯入 headless session
`/retro`	Engineering Manager（回顧版）	分析 commit 歷史、出貨速度、PR 規模

每一個 skill 背後，都是一份精心設計的 system prompt，讓 AI 在那個認知模式下，問的問題、檢查的面向、輸出的格式——都是那個角色應該有的。

為什麼不是「一個超級提示詞」就搞定

這是最常見的問題：「我直接在 system prompt 裡告訴 Claude『你同時是 CEO、工程師、QA、Release Engineer』不行嗎？」

不行，原因很具體：角色之間有認知衝突，混在一起會互相稀釋。

CEO 思維是「大膽假設，往最好的解法走」；偏執型工程師思維是「假設所有事情都會出錯，找最壞的情況」。這兩個模式同時開著，你得到的是一個既不夠大膽、又不夠偏執的妥協版——對你沒有幫助。

就像你不會叫同一個人在同一個會議裡，既負責 pitching 給投資人、又負責法律風險審查——這兩件事需要的思維截然不同，分開來才有品質。

Gstack 與一般提示詞的差別

用一個很直接的對比：

一般做法：「幫我 review 這段程式碼，找找有沒有 bug。」
→ Claude 用通用助手模式掃一遍，找到幾個明顯問題，可能漏掉 race condition 和 N+1 query。

Gstack /review：
→ AI 切換到「偏執型資深工程師」模式，系統性地查：N+1 query、race condition、trust boundary violation、missing index、broken retry logic、stale read——有一個清單，逐項檢查，不漏。

差別不是 AI 的聰明程度，而是被問的問題不同。好的認知模式，就是問對問題的能力。

Gstack 不是萬靈丹

說到這裡，也要說清楚 Gstack 解決不了什麼：

它不幫你決定做什麼產品——你還是得知道自己在解什麼問題
它不取代程式設計能力——你還是得看懂它給的建議
它全開的時候token 消耗很高——每個角色都有自己的 context，複雜任務燒得很快

Gstack 適合的使用場景：你已經在用 Claude Code 寫生產程式碼，你想要更穩定的品質保證——而不是第一次接觸 AI 輔助開發的人。

心智模型建好了。下一步：讓這九個 skill 真的跑起來。

→ Gstack 安裝與快速上手：10 分鐘讓九個 skill 就位

回到系列總覽

這篇是 Gstack 系列的第一站，負責建立「為什麼需要角色切換」的核心概念。完整閱讀路線與其他篇主題，請回到 Gstack 入門課。