真實開發場景：從新功能到 production 的 Gstack 完整工作流

前五篇分別介紹了 Gstack 的每個 skill——但看完之後，你可能還有一個問題：

「這些 skill 實際上要怎麼串起來？」

光知道 /plan-ceo-review 問產品決策、/review 找 production 級 bug，還不夠——你需要知道在一個真實的開發週期裡，每個 skill 在哪個時間點介入，以及跑完之後該做什麼。

這篇用一個具體的場景示範完整流程。

場景設定

你在做一個 SaaS 工具，要加一個新功能：用戶可以把多個報告合併匯出成一份 PDF。

需求來自 10 幾個用戶反饋，你認為這是高優先級——但還沒開始動程式碼。

第一步：`/plan-ceo-review`——先問值不值得做

打開 Claude Code，輸入：

/plan-ceo-review

我想加一個「合併匯出 PDF」的功能。用戶可以選擇多份報告，系統把它們合併成一份 PDF 下載。
需求來自大概 15 個用戶的 feedback，主要是需要定期把報告交給客戶的 consultant 類型用戶。

Gstack 的 CEO 模式會問你幾個問題：

這 15 個用戶，他們現在是怎麼解決這個問題的？自己手動合併 PDF？用其他工具？
「合併匯出」是他們的解法，還是他們的問題？他們真正的痛點是「把報告交給客戶很麻煩」嗎？
有沒有可能，在「合併匯出」之外還有更根本的解法——比如直接讓報告有「分享連結」給客戶？
如果合併 PDF 的需求真的成立，合併順序、報告封面、浮水印這些是 v1 就要做，還是先出最簡單版本？

這些問題迫使你在動手之前，確認一件事：你在解用戶真正的問題，不是解你以為的問題。

假設跑完之後，你確認：合併 PDF 確實是他們的核心需求，v1 先做最簡單版本（選擇報告 + 合併下載），進階功能之後再加。

第二步：`/plan-eng-review`——把「做什麼」轉成「怎麼做才對」

決策鎖定之後，切換到工程師模式：

/plan-eng-review

功能確認：用戶可以在 dashboard 勾選多份報告（最多 10 份），點「合併匯出」後系統在背景合併，完成後通知用戶下載。
用戶每份報告平均 5-20 頁，最大單份 50 頁。
我們的 backend 是 Node.js + PostgreSQL，reports 儲存在 S3。

Gstack 的工程師模式會輸出：

Sequence diagram——用戶觸發 → backend 收到請求 → 背景 job 啟動 → 從 S3 抓各份報告 → 合併 PDF → 存回 S3 → 通知用戶。圖會把 async boundary 畫出來。

Edge case 清單：

合併過程中某一份報告的 S3 URL 失效怎麼辦？
用戶在 job 還沒跑完時就重新觸發會怎樣？
合併後的 PDF 要存多久？有沒有清理機制？
10 份報告的合併大約要多長時間？timeout 設多少？

Test matrix：

Unit test：PDF 合併邏輯
Integration test：背景 job 的完整流程
E2E：從用戶選報告到下載的完整路徑

這份輸出就是你動手之前的架構設計文件。拿著它開始寫程式，遇到問題查它，比直接問 Claude「怎麼寫」要清晰得多。

第三步：實作

這個階段 Gstack 退場，你（和 Claude）寫程式。

用 Claude Code 按照 /plan-eng-review 的設計實作。遇到技術問題可以繼續對話，但不需要用特定的 Gstack skill——這個階段就是純粹的 implementation。

寫完之後，確認：

核心功能跑起來了
基本的 unit test 有寫
本地測試過，大概沒有明顯問題

第四步：`/review`——找那些能過 CI 但在 production 爆的問題

/review

不需要加其他說明，Gstack 會讀你的 git diff，找這次改動引入的問題。

假設這次它找到了：

Critical：PDF 合併在並發請求下有 race condition——如果用戶快速點兩次，可能會觸發兩個 job，產生重複的費用和結果
High：S3 的 presigned URL 在背景 job 跑超過 1 小時時會過期，但 timeout 設了 2 小時
Medium：合併後的 PDF 沒有清理機制，S3 費用會持續增長

你修掉 Critical 和 High，Medium 開一個 issue 下一個 sprint 處理。

第五步：`/qa`——讓 AI 用真實瀏覽器測試功能

/qa

Gstack 分析 git diff，找出受影響的頁面——主要是 dashboard 的報告列表頁和匯出狀態頁——然後開瀏覽器測試：

選三份報告，觸發合併，確認背景 job 啟動
等 job 跑完，確認通知有出現、下載連結有效
下載 PDF，確認內容正確
測試只選一份報告的 edge case
測試選報告然後取消的流程

跑完輸出一個健康分數。假設是 87——代表主要流程沒問題，有幾個 UX 小問題（比如 loading 狀態的文字不夠清楚），但不是 blocker。

第六步：`/ship`——一鍵交付

/ship

Gstack 跑完整的 release checklist：

✅ Sync main — branch 跟 main 是同步的
✅ Run tests — 所有 tests pass
✅ Push branch — push 到 remote
✅ Open PR — PR 建好了，附上清楚的描述，包括這次改動的範圍、測試方式、和已知的 medium issue

你去 review PR，merge。

完整流程一覽

新功能需求
    ↓
/plan-ceo-review   ← 確認「值不值得做」，定義清楚範圍
    ↓
/plan-eng-review   ← 設計架構，識別 edge case 和 failure mode
    ↓
實作（Claude Code + 你自己）
    ↓
/review            ← 找 production 級問題，修掉 critical / high
    ↓
/qa                ← 瀏覽器實測，確認功能在 UI 層面是通的
    ↓
/ship              ← Sync、test、push、PR 一條龍
    ↓
Merge，上線

這個流程要花多少時間

一個完整週期，六個步驟，不算實作時間：

/plan-ceo-review：10-15 分鐘（對話 + 思考）
/plan-eng-review：10-20 分鐘（複雜功能需要更多輸出時間）
/review：5-10 分鐘（讀結果 + 修 critical issue）
/qa：5-15 分鐘（視受影響頁面數量）
/ship：2-3 分鐘

加起來 30-60 分鐘，不算實作。聽起來不少，但這六個步驟防掉的問題，通常要花更多時間善後。

不是每個功能都要跑完整流程

規模小的改動可以跳過部分步驟：

修一個小 bug：直接 /review + /ship，跳過 Plan Review
改 copy 或樣式：直接 /qa 確認視覺，然後 /ship
加一個設定選項：/plan-eng-review（快速確認架構）+ /review + /ship

判斷標準就一個：這次改動如果出問題，要花多少時間和精力收尾？ 答案越大，越值得跑完整流程。

Gstack 系列到這裡就完整了。一個人，九個認知模式，一套可以重複跑的開發節奏——從「值不值得做」到「上 production」，每個環節有對應的工具，不靠記憶力和運氣。

→ 回到 Gstack 入門課系列總覽

場景設定

第一步：/plan-ceo-review——先問值不值得做

第二步：/plan-eng-review——把「做什麼」轉成「怎麼做才對」

第三步：實作

第四步：/review——找那些能過 CI 但在 production 爆的問題

第五步：/qa——讓 AI 用真實瀏覽器測試功能

第六步：/ship——一鍵交付