gstack vs pstack：如何用在自己的產品開發

課程平台要加上「開發中」，交給 AI 後，應該拿到什麼？

除了標籤，讀者還需要知道目前有哪些課節、哪些可公開閱讀、登入後又能看什麼。這幾個答案如果彼此矛盾，畫面再漂亮，仍然會增加選課困惑。

把 gstack 或 pstack 用在自己的產品，可以從這種有明確範圍的需求開始：選一條使用者路徑，讓代理理解現況、提出修改，再拿可觀察的結果驗收。兩套流程的入口不同，但都有設計、審查和驗證能力。選哪套，應該連同你使用的代理環境、專案資料和驗收方式一起決定。

本文用課程平台示範如何交辦任務，再延伸到 AI ERP。工具部分依官方規則分析，平台部分包含本機原始碼的靜態觀察；目前尚未分別執行兩套流程，沒有速度、成本或品質的實測排名。

先分清楚它們各自提供什麼

gstack 是 Garry Tan 開源的 AI 開發工作流程，以 Claude Code 為主力環境，結合任務規則、瀏覽器與命令列工具。從 /office-hours 釐清需求，到工程審查、review 和 QA，角色與階段名稱讓你容易看出這一步在檢查什麼。gstack 官方 README

pstack 由 Lauren Tan（poteto）開發，位於 Cursor 的 plugins 儲存庫。主要入口 poteto-mode 會依任務選擇工作流程；例如功能開發，會先理解系統，再進行架構設計、實作分工與驗證。官方也提供 Claude Code 適配。pstack 官方 README

它們能替代理安排工作方法。產品裡誰可以讀、什麼時候能付款，以及哪些資料可以修改，都要由現有程式、文件與你給的任務界線提供。

第一步 先挑一個能驗收的產品問題

以這個課程平台為例，一個合適的試點是：

讓課程卡片、介紹頁與目錄，對開發進度、已提供課節和閱讀資格給出一致的說明。

這個範圍跨到資料與畫面，但不必重做整個會員系統。也容易驗收：換幾種內容與身份條件，看同一條閱讀路徑是否符合規則。

本機原始碼已經有 developmentStatus，支援「尚未開發」與「開發中」，卡片、介紹頁及課程目錄也有使用標籤函式。因此，代理的第一個動作應該是查現有實作，確認還缺什麼。重新建立一套平行狀態，反而可能讓不同頁面各自判斷。

這是本機工作目錄的狀態，不能據此推定正式網站已部署相同版本。

圖3｜原創概念示意。製作進度、實際課節供給與使用者資格，是組成頁面資訊的不同依據；「開發中」並不能單獨決定能讀什麼。

第二步 讓代理先找到可信的資料來源

交辦前，先用幾句話說清楚產品的責任分工。這個平台的公開 blog 負責吸引讀者，docs 才是主要學習介面，admin 處理後台協調；課程顯示與閱讀權限的工作，要沿著這些邊界調查。

就本次需求，代理至少要找到三條線：

在本機原始碼中，開發狀態放在課程資料定義，卡片的主要動作另由呈現函式決定，閱讀資格則有共用的存取規則。這些是調查起點；實際資料載入、後端授權與頁面行為仍需接著確認。

若只要求「把所有課程標成開發中」，代理很容易完成文字替換。若要求它交出上述資料如何流動的說明，後面的修改才比較容易受檢查。

用 gstack 把需求推進到可驗收的變更

在已安裝 gstack 的 Claude Code 環境，可以先交給 /office-hours 一段具體問題：

/office-hours
我的課程平台需要讓讀者看懂：
課程的開發進度、已提供的課節，以及自己的閱讀資格。

先唯讀檢查現有程式與專案規則。
已有 developmentStatus，請沿用並指出尚未解決的問題。
不要把規劃集數當成已提供內容，也不要改變既有授權。

請提出最小修改範圍、使用者路徑和可觀察的驗收條件。
本階段只產生設計文件，不實作、不部署。

接著，將前一步產生的設計文件明確指定為 /plan-eng-review 的審查對象，檢查資料來源、影響頁面、例外與測試範圍。設計明確後，再另外交辦隔離的本機實作，保留其他未提交修改。

實作完成可接 /review；若只想先拿到檢查報告，用 /qa-only 指定已啟動的本機頁面與驗收範圍。要連同修復一起做，才選 /qa 並明確交代範圍。gstack 的 QA 流程包含重現、修復與重測，不能把這兩個命令當成同樣的唯讀操作。工程審查規則、QA 規則、QA 與唯讀報告入口

這條路徑的好處，是你能在需求、設計與驗收階段分別介入。完成本機修改也有明確的停點，無須為了走完流程就接上合併或正式部署。

用 pstack 把同一項需求交給任務流程

在已安裝 pstack 的 Cursor 環境，可以用 /poteto-mode 給同一份需求與驗收標準。以下是任務範例，並未在本文執行：

/poteto-mode
讓課程卡片、介紹頁與目錄對開發進度、
已提供課節及閱讀資格給出一致的說明。

先理解現有資料流與授權規則，沿用 developmentStatus。
指出需要修改的地方，避免建立重複的狀態來源。
以合成測試資料處理零課節、公開課節、
會員課節和指定產品授權的情境。

若現有行為已符合需求，提供證據並保留原實作。
若需要修改，只在隔離的本機工作目錄處理，
保留其他人的變更，不改正式資料或既有授權。

交付修改差異、設計理由、可重跑的驗收結果及限制。
不 push、不合併、不部署。

pstack 的功能流程會先理解受影響的子系統，再處理架構與分工。architect 要求先確定型別、函式介面與模組邊界，並比較結構不同的候選方案。這很適合用來追問：課程狀態究竟由誰擁有？卡片和內頁要怎麼共用判斷？功能流程、架構規則

在 Claude Code 中，指令名稱與部分能力需要按官方適配文件轉換，例如入口使用 /pstack:poteto-mode。工具和模型分工也可能不同，不能預設跨環境會完全一致。Claude Code 適配說明

第三步 用相同情境檢查成果

不論選哪套，驗收條件應先固定。否則一套只展示畫面，另一套檢查完整閱讀路徑，結果沒有可比性。

先用合成身份與隔離資料確認規則，再檢查實際頁面的呈現；這兩項證據應分開記錄。純函式測試能確認判斷，仍不能單獨證明頁面已接對資料。

若產品有先修條件，也應讀實際實作，區分可略過的學習提示與強制門檻。不要在增加課程狀態標籤時，順手改變學習順序或存取政策。

這次讀原始碼就遇到一個值得查證的例子：目錄頁用 lessons.length || course.totalEpisodes 決定顯示集數，當實際課節數為 0，就會回用規劃集數。下一步應以零課節資料開啟目錄，檢查上下文是否清楚說明它是規劃數量。這是驗收候選項，尚未重現為正式網站缺陷。

最後要拿到的證據，包括：修了哪些地方、檢查輸入與預期值、實際輸出，以及對應頁面。pstack 的「Prove It Works」原則也要求直接查驗真實結果，能腳本化就留下可重跑的檢查。直接驗證原則

延伸到 AI ERP 先選一條流程

同樣的方法可以用在 AI ERP。假設客戶在問：「這張報價已被接受，為什麼還沒有訂單？」先選「報價接受後轉成訂單」這一段，不必一次改完整套 ERP。

gstack 的產品討論入口，可以幫你釐清使用者期待：接受報價後是自動轉單，還是必須人工確認？失敗時誰需要收到提示？工程審查再追資料與失敗路徑。

pstack 的系統理解與架構流程，則可以拿同一需求追問：哪個狀態代表可以轉單、接受事件重送怎麼處理、哪些資料由同一個模組負責。這些是應用方式的建議，兩套工具都可以處理其中的產品與工程問題。

驗收時，在隔離的測試環境用同一張測試報價重送接受事件，查訂單數量與關聯是否符合既定規則；再模擬建立失敗後重試，確認是否恢復正確狀態。真正值得留下的是這條可重跑的案例。本文沒有替任何正式 ERP 建立訂單或發送通知。

怎麼開始 才能看出哪套適合自己

若你需要頻繁討論產品方向，我會先試 gstack 清楚的角色入口；若目前主要困擾是既有程式難理解、資料判斷散落，我會先試 pstack 的系統理解與架構流程。這是依工作方法做的初步選擇，品質仍要由同一組驗收情境判斷。

試點時保留三個控制條件：一個明確任務、一份固定驗收清單，以及本機完成就停止的交付範圍。工作結果至少應包含修改差異、可觀察的驗證證據與尚未解決的問題。

再記錄完成時間、模型用量和人工返工。兩套專案採 MIT 授權，執行代理仍可能產生模型與工具成本；平行代理或多輪審查是否划算，需要看它替這個任務減少多少返工。

gstack 官方目前將 Claude Code 列為完整支援，其他宿主有不同等級；規則由程式實際攔截，或主要作為代理指引，也有差別。使用前應核對自己那個環境的支援情況。gstack 宿主支援

對這個課程平台，一個實際的起點就是：沿用既有開發狀態，把零課節、公開試讀與不同閱讀資格的說明查清楚。這項任務完成後，你才能具體判斷哪套流程讓你比較容易理解修改、重跑驗收，並放心接手維護。

資料核對日期：2026年11月5日。本文依官方文件與本機原始碼靜態觀察整理，尚未執行兩套工具的對照實測，平台案例也不代表已驗證正式網站行為。

若要把驗收接進日常開發，可接著看 GitHub Actions 的 CI/CD 工作流程，把可重跑的檢查放入 Pull Request；工具版本與設定仍以當前官方文件為準。