Plan Review 雙模式：CEO 思維 + 工程師架構，為什麼要分開用

很多工程師在設計功能的時候，會跳過兩個最重要的問題：

「這個功能值得做嗎？」——大多數人假設答案是「當然值得，需求都來了。」
「這個架構有沒有隱藏的 failure mode？」——大多數人假設寫完跑起來就算過了。

這兩個問題，Gstack 的 Plan Review 各管一個。

兩個 Skill，兩種完全不同的思維頻率

/plan-ceo-review 和 /plan-eng-review 看起來都是「計畫審查」，但它們問的問題截然不同——

/plan-ceo-review 是 Founder / CEO 視角：

/plan-eng-review 是 Engineering Manager / Tech Lead 視角：

一個往後退、問「值不值得」；一個往前推、問「怎麼做才對」。混在一起，兩件事都做不好。

假設你跟 Gstack 說：「我想幫電商平台加一個商品比較功能，讓用戶可以同時比較三個商品的規格。」

用一般 AI 助手，大概會直接給你一個比較表格的設計方案。

用 /plan-ceo-review，它會先問你：

這些問題，你的 PM 可能問過，可能沒問過——但 Gstack 一定會問，每次都問。它不讓你在錯的問題上蓋正確的解法。

同樣的功能，切換到 /plan-eng-review 之後，Gstack 的輸出格式會有很大的差異：

Architecture diagram（sequence diagram 或 component diagram）——把你的設計視覺化，強迫隱藏的假設浮出水面
Async boundary 分析——這個功能的哪些部分可以非同步？哪些必須同步？
Failure mode 清單——如果資料庫慢了、API 失敗了、用戶同時開兩個分頁——會發生什麼？
Test matrix——需要 unit test 的地方、integration test 的地方、E2E 的地方分別是哪些？

這些東西你不一定每次都需要全部跑過，但有一份清單告訴你「這些問題值得考慮」，比從零開始想要省很多時間。

標準流程：先 CEO，再 Engineer。

這個順序是有邏輯的——如果 /plan-ceo-review 之後你改變了功能的定義或範圍，/plan-eng-review 就要重新跑；反過來的話，你可能在一個不值得做的功能上花了大量架構設計的時間。

先確認「值得做」，再確認「怎麼做才對」。

對於小功能：可以只跑其中一個。

不是每個功能都需要 CEO 思維壓力測試——改一個按鈕顏色不需要問「這值不值得做」。
也不是每個決策都需要 Engineering Manager 深挖——新增一個設定欄位的架構通常很直觀。

判斷標準很簡單：這個決策做錯了會有多痛？ 越痛，越值得花時間跑 Plan Review。

Gstack 的 Plan Review 最常見的誤用是：在程式碼都寫完之後才跑。

這個時候跑 Plan Review，CEO 如果說「這個功能的定義應該不一樣」，你怎麼辦？砍掉重練還是無視它？兩個選項都不好。

Plan Review 的時機是決策尚未鎖定、程式碼還沒動之前——就是字面意義的「計畫階段審查」。把它當成動手前的強制思考流程，而不是事後的 checklist。

你不需要即時跟 Gstack 對話來描述功能。可以直接把你的需求文件、user story、或設計稿描述貼進去，然後用指令觸發：

/plan-ceo-review

[你的需求文件或 user story]

它會從你提供的材料出發，按照 CEO 的思維框架分析——跑起來快很多，也不容易漏掉細節。

Plan Review 做好了，下一步：程式碼寫完之後，怎麼做出 production 級的審查，以及怎麼一鍵交付。

這篇是 Gstack 系列的第三站，聚焦 Plan Review 雙模式。完整閱讀路線與其他篇主題，請回到 Gstack 入門課。