第 014 篇 ｜Codex 三層工作法：Plan 模式、Superpowers 與 gstack 怎麼配合
整理版優先睇
Codex 三層工作法：Plan 模式控制動手時機，Superpowers 控制思考質量，gstack 控制項目流程，三者按任務階段選最小夠用嗰層。
呢篇筆記係作者日常用 Codex 做軟件項目嘅經驗總結，講述三層協作方法：Plan 模式、Superpowers 同 gstack。作者想解決嘅問題係：喺 AI 編程過程中，點樣按任務階段選擇合適嘅執行方式，避免方向錯誤、範圍失控或者流程混亂。整體結論係呢三層唔係互斥，而係層級關係——Plan 模式負責踩剎車，Superpowers 負責扶正方向盤，gstack 負責跑完整流水線。
作者指出，Plan 模式係執行狀態，解決「而家可唔可以動手」嘅問題；Superpowers 係工作方法論，解決「應該跟咩思路推進」嘅問題；gstack 係軟件項目流水線 skill 套件，解決「由想法到驗證交付應該跑邊啲角色同關卡」嘅問題。三者各司其職，唔應該每次都全部用曬。
作者強調，真正成熟嘅用法係根據任務階段選擇最小夠用嘅嗰層。例如，細任務直接做，唔確定就行 Plan，複雜過程用 Superpowers，項目交付用 gstack。最終所有方法都要回歸到證據，例如命令、測試、截圖或報告。
- Plan 模式、Superpowers、gstack 係三層控制面，分別負責「做唔做」、「點樣做」同「完整流程」
- Plan 模式喺任務開始前或風險高時用，確保邊界、方案同回滾方式清晰
- Superpowers 適合拆解、調試、TDD 等需要工程節奏嘅場景，防止 AI 亂改
- gstack 係完整軟件項目 skill 套件，涵蓋 office-hours、review、QA、ship 等關卡
- 日常使用默認策略：細任務直接做、唔確定就 Plan、複雜用 Superpowers、交付用 gstack
三層方法嘅核心區別
Plan 模式、Superpowers 同 gstack 係三層唔同嘅控制面，唔係互斥關係。一句話記住：Plan 模式控制「做唔做」，Superpowers 控制「點樣做」，gstack 控制「完整流程」。
Plan 模式係執行狀態，唔係 skill
文章用一個表格清楚列出三者嘅本質、主要問題、適合階段同典型輸出。Plan 模式適合任務開始前、風險較高時，輸出方案、邊界、風險同執行步驟；Superpowers 適合需求澄清、調試、TDD，輸出分階段工作流、假設同驗證步驟；gstack 適合需求到交付嘅完整項目，輸出 office-hours、review、QA、ship 報告。
Plan 模式：控制動手時機
Plan 模式嘅核心判斷係：呢個任務如果直接做，會唔會造成方向錯誤、範圍失控或者難以回滾？適合用 Plan 模式嘅情況包括需求模糊、影響全局配置、涉及刪除遷移、架構未定、需要先確認成本風險，或者用戶明確話「先俾方案」.
先走 Plan 模式，唔好改代碼
作者建議可以直接對 Codex 講：「先走 Plan 模式，唔好改代碼。請先俾我邊界、方案、風險同驗證方式。」Plan 模式嘅目標係防止一開始就跑錯方向，唔係拖慢工作。
- 1 需求模糊：只知道想做一個嘢
- 2 影響全局：配置、權限、共享 skill、自動化、部署
- 3 涉及刪除、清理、遷移、批量改文件
- 4 架構方案未確定
- 5 需要先確認成本、風險、邊界
- 6 用戶明確話「先俾方案」「唔好鬱代碼」
Superpowers：控制思考質量
Superpowers 適合控制 agent 嘅工作方法，令佢按更可靠嘅工程節奏推進。適用場景包括任務需要拆解成多步、bug 原因唔清楚、希望先寫測試或定義驗收、需要防止 agent 亂改、需要階段性 checkpoint，或者需要系統性思考需求、假設同風險。
將「AI 直接俾答案」改成「AI 按工程方法推進」
例如可以講：「使用 Superpowers 方法處理呢個 bug：先調查，再提出假設，再驗證，最後先修。」或者「用 Superpowers 拆解任務，先寫清楚階段、驗收標準同驗證命令。」
gstack：完整項目流水線
gstack 係一組 skill 套件，適合完整軟件項目，而唔係單個小問題。佢將項目拆成產品、工程、設計、QA、安全、發佈、覆盤等角色同關卡。常用嘅 gstack skill 包括：
- gstack-office-hours：用喺想法模糊時，輸出產品判斷、範圍建議
- gstack-autoplan：用喺計劃評審，輸出綜合方案
- gstack-plan-eng-review：評審工程風險同實現建議
- gstack-review：檢查代碼改動，輸出 bug 同風險
- gstack-qa：用真實瀏覽器測試，輸出 QA 報告同截圖
- gstack-ship：準備發佈，檢查測試、文檔、風險
gstack 適合「由模糊想法到交付」嘅完整流程
使用時直接講出對應 skill，例如「用 gstack-review 檢查當前 git diff，重點揾真實 bug、遺漏測試同迴歸風險。」
組合方式同默認策略
作者提供咗四種常見組合，例如模糊需求到可執行方案：先 Plan 模式，再 gstack-office-hours，再用 Superpowers 拆階段，最後 gstack-plan-eng-review。複雜功能開發就係 Plan 確認後，用 Superpowers TDD 實現，再用 gstack-review 同 gstack-qa 驗證。
Bug 排查先用 Superpowers 調查，唔好直接修
作者推薦嘅日常默認策略係：細任務直接做；唔確定就行 Plan；複雜過程用 Superpowers；項目交付用 gstack。最後一定要返到證據，例如命令、測試、截圖或報告。
作者仲分享咗自己嘅調用模板：新項目先 Plan + gstack-office-hours + Superpowers；工程方案評審用 gstack-plan-eng-review；實現用 Superpowers 小步驗證；完成後用 gstack-review 同 gstack-qa；準備交付用 gstack-ship。
20
呢篇筆記係記錄緊 Codex 日常軟件項目工程嘅三層協作方法：Plan 模式決定「諗清楚先定直接鬱手」，Superpowers 負責「點樣思考同推進」，gstack 負責「將軟件項目行成完整流水線」。
一句話區分
Plan 模式唔係技能，而係執行狀態。佢解決嘅係「而家可唔可以鬱手」嘅問題。
Superpowers係工作方法論。佢解決嘅係「應該跟咩思路推進」嘅問題。
gstack係軟件項目流水線。佢解決嘅係「一個軟件項目由諗法到驗證交付應該行咩角色同關卡」嘅問題。
如果只係記一句：
先用 Plan 模式控制係咪鬱手，再用 Superpowers 控制思考質素，最後用 gstack 行完整軟件工程關卡。
三者各自負責啲咩
三者唔係互斥關係。佢哋似三層控制面：
• Plan 模式控制係咪進入執行 • Superpowers 控制執行方法係咪可靠 • gstack 控制軟件項目流程係咪完整
幾時用 Plan 模式
用 Plan 模式嘅核心判斷係：呢個任務如果直接做，係咪有可能造成方向錯誤、範圍失控或者難返轉頭。
適合用 Plan 模式嘅情況：
• 需求仲好模糊，淨係知「想做一個嘢」 • 會影響全局配置、賬號權限、共用技能、自動化、部署流程 • 涉及刪除、清理、遷移、批量改檔案 • 架構方案仲未確定 • 需要先同用戶確認成本、風險、邊界 • 用戶明確話「先畀方案」「唔好鬱代碼」
可以咁樣對 Codex 講：
先走 Plan 模式，不要改代碼。請先給我邊界、方案、風險和驗證方式。或者：
這個任務影響比較大，先不要動手。先判斷有哪些方案、哪個最穩、怎麼回滾。Plan 模式嘅目標唔係拖慢工作，而係防止一開始就行錯方向。
幾時用 Superpowers
Superpowers 適合用嚟控制 agent 嘅工作方法。佢唔係某個具體領域嘅工具，而係令 agent 跟更可靠嘅工程節奏工作。
適合用 Superpowers 嘅情況：
• 任務需要拆解成多步 • bug 原因唔清楚，需要先調查再修 • 想先寫測試或者先定義驗收 • 需要防止 agent 一邊修一邊亂改 • 需要階段性 checkpoint • 需要對需求、假設、風險做系統性思考
可以咁樣講：
使用 Superpowers 方法處理這個 bug：先調查，再提出假設，再驗證，最後再修。或者：
用 Superpowers 的方式拆解這個任務，先寫清楚階段、驗收標準和驗證命令。Superpowers 嘅價值在於將「AI 直接畀答案」改成「AI 跟工程方法推進」。
幾時用 gstack
gstack 更適合完整軟件項目，而唔係單個小問題。佢將一個項目拆成唔同角色同關卡：產品、工程、設計、QA、安全、發佈、覆盤。
適合用 gstack 嘅情況：
• 要由一個模糊諗法開始做軟件項目 • 想先由產品角度重新審視需求 • 想令工程方案俾系統 review • 想對而家嘅改動做高強度代碼審查 • 想用真實瀏覽器做 QA • 想將測試、文檔、發佈檢查串連
常用 gstack 技能嘅分工：
gstack-office-hours | ||
gstack-autoplan | ||
gstack-plan-eng-review | ||
gstack-review | ||
gstack-qa | ||
gstack-ship |
可以咁樣講：
使用 gstack-office-hours，幫我重新審視這個產品需求，不要直接寫代碼。使用 gstack-plan-eng-review，評審這個實現方案的架構風險和測試缺口。使用 gstack-review，檢查當前 git diff，重點找真實 bug、遺漏測試和發佈風險。使用 gstack-qa，打開 http://localhost:3000 做一輪真實瀏覽器 QA。
組合方式
1. 模糊需求到可執行方案
適合：用戶淨係有個大概諗法，仲未形成項目邊界。
推薦流程：
1. Plan 模式：唔好鬱手住，確認目標同邊界。 2. gstack-office-hours：由產品問題同用戶痛點重新審視。 3. Superpowers：將結論拆成階段、驗收標準同風險。 4. gstack-plan-eng-review：評審工程實現路徑。 5. 再決定係咪進入實現。
可以直接講：
先走 Plan 模式，不要改代碼。使用 gstack-office-hours 重新審視這個需求，然後用 Superpowers 把它拆成可執行階段和驗收標準。2. 複雜功能開發
適合：已經知道要做咩，但實現涉及多個模塊。
推薦流程：
1. Plan 模式：確認改動範圍、檔案邊界、驗收標準。 2. Superpowers：跟 TDD 或者分階段執行。 3. 實現代碼。 4. gstack-review：做代碼審查。 5. gstack-qa：如果有前端或者網頁服務，做真實瀏覽器驗證。
可以直接講：
先用 Plan 模式確認方案。確認後按 Superpowers 的 TDD 流程實現，完成後用 gstack-review 和 gstack-qa 驗證。3. bug 排查
適合：有明確錯誤、現象或者失敗測試。
推薦流程：
1. Superpowers：先調查，唔直接修。 2. 揾到可證偽假設。 3. 最少改動修復。 4. gstack-review：睇下有無引入迴歸。 5. 必要時 gstack-qa：重現用戶路徑。
可以直接講：
使用 Superpowers 的系統調試流程處理這個 bug。先不要修，先找證據鏈和根因；修完後用 gstack-review 檢查迴歸風險。4. 已完成代碼準備交付
適合：代碼已經寫完，準備提交、PR、上線或者交畀用戶。
推薦流程：
1. gstack-review：查真實 bug、邊界遺漏、測試缺口。 2. gstack-qa：對用戶路徑做瀏覽器驗證。 3. gstack-ship：跑發佈前檢查。 4. 普通 Codex 執行：根據 findings 做最少修復。
可以直接講：
使用 gstack-review 檢查當前改動。通過後再使用 gstack-qa 測試頁面，最後給我一份交付前風險報告。
快速決策表
唔應該點樣用
唔好將三者當成一串固定咒語。
錯誤用法：
使用 Plan 模式 + Superpowers + gstack 全部跑一遍。咁樣會令任務變重，甚至令 agent 將簡單事情複雜化。
更好嘅講法係：
這個任務現在還不清楚，先 Plan。或者：
這是 bug，按 Superpowers 調試。或者：
代碼已經寫完，用 gstack-review 和 gstack-qa 做交付前驗證。推薦默認策略
日常使用可以採用下面嘅默認策略：
1. 細任務直接做：查文件、改一個 bug、跑一個測試，唔需要 skill。 2. 唔確定就行 Plan：範圍、風險、架構、權限、清理、遷移，先行 Plan。 3. 複雜過程用 Superpowers：除錯、TDD、多階段任務、容易走歪嘅工作。 4. 項目交付用 gstack：需求評審、工程評審、代碼 review、瀏覽器 QA、發佈檢查。 5. 最後一定要返去證據：無論用咗邊個方法，最終都要有命令、測試、截圖、報告或者可重現路徑。
呢套方式嘅目標唔係令 Codex 叫更多 skill，而係令每次軟件項目工作都有清楚嘅邊界、穩定嘅推進節奏同可驗證嘅交付結果。
我自己嘅調用模板
新項目/新功能
先走 Plan 模式，不要改代碼。使用 gstack-office-hours 重新審視需求，再用 Superpowers 拆成階段、驗收標準和風險。工程方案評審
使用 gstack-plan-eng-review，檢查這個方案的架構邊界、數據流、失敗模式和測試缺口。實現任務
按上面的方案實現。用 Superpowers 的執行節奏推進：小步改動、階段驗證、不要無關重構。代碼完成後
使用 gstack-review 檢查當前 git diff，優先找真實 bug、遺漏測試、迴歸風險。不要只做風格點評。前端或者網頁服務完成後
使用 gstack-qa 打開本地頁面做真實瀏覽器 QA，記錄復現路徑、失敗截圖和剩餘風險。準備交付
用 gstack-ship 的思路做交付前檢查：測試、文檔、風險、回滾方式、下一步。最終判斷
Plan 模式、Superpowers 同 gstack 嘅關係唔係替代關係，而係層級關係。
Plan 模式負責踩 brake。
Superpowers 負責將軚盤扶正。
gstack 負責將整條軟件工程流水線行完。
真正成熟嘅用法，係根據任務階段揀最少夠用嘅嗰一層，而唔係每次都全部開曬。
20
這篇筆記記錄的是 Codex 日常軟件項目工程中的三層協作方法：Plan 模式決定"先想清楚還是直接動手"，Superpowers 負責"怎麼思考和推進"，gstack 負責"把軟件項目跑成完整流水線"。
一句話區分
Plan 模式不是 skill，而是執行狀態。它解決的是"現在能不能動手"的問題。
Superpowers是工作方法論。它解決的是"應該按什麼思路推進"的問題。
gstack是軟件項目流水線。它解決的是"一個軟件項目從想法到驗證交付應該跑哪些角色和關卡"的問題。
如果只記一句：
先用 Plan 模式控制是否動手，再用 Superpowers 控制思考質量，最後用 gstack 跑完整軟件工程關卡。
三者各自負責什麼
三者不是互斥關係。它們像三層控制面：
• Plan 模式控制是否進入執行 • Superpowers 控制執行方法是否可靠 • gstack 控制軟件項目流程是否完整
什麼時候用 Plan 模式
用 Plan 模式的核心判斷是：這個任務如果直接做，是否可能造成方向錯誤、範圍失控或難以回滾。
適合使用 Plan 模式的情況：
• 需求還模糊，只知道"想做一個東西" • 會影響全局配置、賬號權限、共享 skill、自動化、部署流程 • 涉及刪除、清理、遷移、批量改文件 • 架構方案還沒確定 • 需要先和用戶確認成本、風險、邊界 • 用戶明確說"先給方案""不要動代碼"
可以這樣對 Codex 說：
先走 Plan 模式，不要改代碼。請先給我邊界、方案、風險和驗證方式。或者：
這個任務影響比較大，先不要動手。先判斷有哪些方案、哪個最穩、怎麼回滾。Plan 模式的目標不是拖慢工作，而是防止一開始就跑錯方向。
什麼時候用 Superpowers
Superpowers 適合用來控制 agent 的工作方法。它不是某個具體領域的工具，而是讓 agent 按更可靠的工程節奏工作。
適合使用 Superpowers 的情況：
• 任務需要拆解成多步 • bug 原因不清楚，需要先調查再修 • 希望先寫測試或先定義驗收 • 需要防止 agent 一邊修一邊亂改 • 需要階段性 checkpoint • 需要對需求、假設、風險做系統性思考
可以這樣說：
使用 Superpowers 方法處理這個 bug：先調查，再提出假設，再驗證，最後再修。或者：
用 Superpowers 的方式拆解這個任務，先寫清楚階段、驗收標準和驗證命令。Superpowers 的價值在於把"AI 直接給答案"改成"AI 按工程方法推進"。
什麼時候用 gstack
gstack 更適合完整軟件項目，而不是單個小問題。它把一個項目拆成不同角色和關卡：產品、工程、設計、QA、安全、發佈、覆盤。
適合使用 gstack 的情況：
• 要從一個模糊想法開始做軟件項目 • 想先從產品角度重新審視需求 • 想讓工程方案被系統 review • 想對當前改動做高強度代碼審查 • 想用真實瀏覽器做 QA • 想把測試、文檔、發佈檢查串起來
常用 gstack skill 的分工：
gstack-office-hours | ||
gstack-autoplan | ||
gstack-plan-eng-review | ||
gstack-review | ||
gstack-qa | ||
gstack-ship |
可以這樣說：
使用 gstack-office-hours，幫我重新審視這個產品需求，不要直接寫代碼。使用 gstack-plan-eng-review，評審這個實現方案的架構風險和測試缺口。使用 gstack-review，檢查當前 git diff，重點找真實 bug、遺漏測試和發佈風險。使用 gstack-qa，打開 http://localhost:3000 做一輪真實瀏覽器 QA。組合方式
1. 模糊需求到可執行方案
適合：用戶只有一個大概想法，還沒形成項目邊界。
推薦流程：
1. Plan 模式：先不要動手，確認目標和邊界。 2. gstack-office-hours：從產品問題和用戶痛點重新審視。 3. Superpowers：把結論拆成階段、驗收標準和風險。 4. gstack-plan-eng-review：評審工程實現路徑。 5. 再決定是否進入實現。
可直接說：
先走 Plan 模式，不要改代碼。使用 gstack-office-hours 重新審視這個需求，然後用 Superpowers 把它拆成可執行階段和驗收標準。2. 複雜功能開發
適合：已經知道要做什麼，但實現涉及多個模塊。
推薦流程：
1. Plan 模式：確認改動範圍、文件邊界、驗收標準。 2. Superpowers：按 TDD 或分階段執行。 3. 實現代碼。 4. gstack-review：做代碼審查。 5. gstack-qa：如果有前端或網頁服務，做真實瀏覽器驗證。
可直接說：
先用 Plan 模式確認方案。確認後按 Superpowers 的 TDD 流程實現，完成後用 gstack-review 和 gstack-qa 驗證。3. bug 排查
適合：有明確錯誤、現象或失敗測試。
推薦流程：
1. Superpowers：先調查，不直接修。 2. 找到可證偽假設。 3. 最小改動修復。 4. gstack-review：看是否引入迴歸。 5. 必要時 gstack-qa：復現用戶路徑。
可直接說：
使用 Superpowers 的系統調試流程處理這個 bug。先不要修，先找證據鏈和根因；修完後用 gstack-review 檢查迴歸風險。4. 已完成代碼準備交付
適合：代碼已經寫完，準備提交、PR、上線或交付給用戶。
推薦流程：
1. gstack-review：查真實 bug、邊界遺漏、測試缺口。 2. gstack-qa：對用戶路徑做瀏覽器驗證。 3. gstack-ship：跑發佈前檢查。 4. 普通 Codex 執行：根據 findings 做最小修復。
可直接說：
使用 gstack-review 檢查當前改動。通過後再使用 gstack-qa 測試頁面，最後給我一份交付前風險報告。快速決策表
不應該怎麼用
不要把三者當成一串固定咒語。
錯誤用法：
使用 Plan 模式 + Superpowers + gstack 全部跑一遍。這會讓任務變重，甚至讓 agent 把簡單事情複雜化。
更好的說法是：
這個任務現在還不清楚，先 Plan。或者：
這是 bug，按 Superpowers 調試。或者：
代碼已經寫完，用 gstack-review 和 gstack-qa 做交付前驗證。推薦默認策略
日常使用可以採用下面的默認策略：
1. 小任務直接做：查文件、改一處 bug、跑一個測試，不需要 skill。 2. 不確定就 Plan：範圍、風險、架構、權限、清理、遷移，先走 Plan。 3. 複雜過程用 Superpowers：調試、TDD、多階段任務、容易跑偏的工作。 4. 項目交付用 gstack：需求評審、工程評審、代碼 review、瀏覽器 QA、發佈檢查。 5. 最後必須回到證據：不管用了哪個方法，最終都要有命令、測試、截圖、報告或可復現路徑。
這套方式的目標不是讓 Codex 調用更多 skill，而是讓每次軟件項目工作都有清楚的邊界、穩定的推進節奏和可驗證的交付結果。
我自己的調用模板
新項目/新功能
先走 Plan 模式，不要改代碼。使用 gstack-office-hours 重新審視需求，再用 Superpowers 拆成階段、驗收標準和風險。工程方案評審
使用 gstack-plan-eng-review，檢查這個方案的架構邊界、數據流、失敗模式和測試缺口。實現任務
按上面的方案實現。用 Superpowers 的執行節奏推進：小步改動、階段驗證、不要無關重構。代碼完成後
使用 gstack-review 檢查當前 git diff，優先找真實 bug、遺漏測試、迴歸風險。不要只做風格點評。前端或網頁服務完成後
使用 gstack-qa 打開本地頁面做真實瀏覽器 QA，記錄復現路徑、失敗截圖和剩餘風險。準備交付
用 gstack-ship 的思路做交付前檢查：測試、文檔、風險、回滾方式、下一步。最終判斷
Plan 模式、Superpowers 和 gstack 的關係不是替代關係，而是層級關係。
Plan 模式負責踩剎車。
Superpowers 負責把方向盤扶正。
gstack 負責把整條軟件工程流水線跑完。
真正成熟的用法，是根據任務階段選擇最小夠用的那一層，而不是每次都全量打開。