YC 總裁 Garry Tan 靠它 60 天寫出 60 萬行 code。gstack 不是一個工具，而是一套把 AI 組織成完整工程團隊的工作流。
目錄+
60 天、60 萬行 code、1 個人。
這是 Y Combinator 總裁 Garry Tan 在 2026 年初公開的數字。他一邊管理著全球最有影響力的創業加速器，一邊在 60 天內寫出了相當於一支中型工程團隊半年產出的程式碼——其中 35% 是測試。
這不是天才，這是系統。
那個系統叫做 gstack。
gstack 是什麼？
gstack 是一套開源的 skill 集合，目的在把 Claude Code 從「一個聰明的助手」升級成「一整支虛擬工程團隊」。
它不是 IDE 外掛，也不是新的 AI 模型。它解決的問題更根本：一個人獨立開發時，最大的瓶頸往往不是寫 code 的速度，而是沒有人幫你 review、測試、部署、反省。gstack 把這些角色全部補上。
安裝只需要一行：
git clone --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup
裝好之後，你就有了 23 個 skill，涵蓋從發現問題到上線反省的完整流程。
一條生產線，七個環節
gstack 的設計哲學是 Think → Plan → Build → Review → Test → Ship → Reflect。每個環節對應一組傳統開發團隊中的角色，也對應一個或多個 skill。
Think — 先釐清問題，別急著動手
傳統角色：PM、產品創辦人
對應 skill：/office-hours
很多開發者（尤其是獨立開發者）的毛病是還沒想清楚問題就開始寫 code。/office-hours 扮演的是一個產品顧問，逼你說清楚「你到底要解決什麼問題」。它會反問你、挑戰你的假設、幫你重新界定範疇，讓後面每個環節都建立在正確的基礎上。
Plan — 架構決策，而不是靠直覺
傳統角色：Tech Lead、架構師
對應 skill：/plan-eng-review、/plan-ceo-review
這個環節會產出一份具體的實作計畫：哪些檔案要動、用什麼技術方案、有哪些 trade-off。/plan-eng-review 以資深工程師的視角審查你的計畫是否合理，/plan-ceo-review 則從更高一層確認這件事值不值得做。
Build — 這才是 Claude Code 本體出場
傳統角色：工程師
對應 skill：Claude Code 本體（直接在 terminal 下指令）
這個環節是 Claude Code 最擅長的：依照計畫寫出真實可運行的程式碼。有了前兩個環節打底，這裡的輸出品質會明顯穩定得多——AI 不再需要猜你想要什麼。
Review — 終於有人幫你看 code
傳統角色：Senior Developer
對應 skill：/review
寫完就上線，是獨立開發者最常犯的錯。/review 會以挑剔的 code reviewer 視角掃描你剛寫的東西：邏輯漏洞、安全問題、可讀性問題，一次列出來。
Test — 真的開瀏覽器跑一遍
傳統角色：QA 工程師
對應 skill：/qa、/qa-only
這是 gstack 最令人印象深刻的一環。/qa 不是讓 AI 想像測試結果——它會啟動真實的 Chromium 瀏覽器，點擊、輸入、截圖，像一位真正的 QA 那樣操作你的應用程式，再把發現的問題直接修掉。
Ship — 從 commit 到上線
傳統角色：DevOps
對應 skill：/ship、/land-and-deploy
/ship 負責跑測試、建 CI、開 PR；/land-and-deploy 負責 merge 與部署。這兩個 skill 把「怎麼上線」這件事標準化，你不需要每次記一串指令。
Reflect — 回顧，不是逃避
傳統角色：週會、Engineering Manager
對應 skill：/retro
每週一次，/retro 會分析你的 GitHub activity、找出瓶頸、提出下週的改善建議。這是很多獨立開發者最容易跳過、也最需要的環節。
為什麼比「直接問 AI」更強？
很多人以為 AI 輔助開發就是「遇到問題問 ChatGPT」。gstack 的核心差異在於：它是流程設計，不是提示詞技巧。
每個 skill 都有明確的輸入與輸出定義。AI 不需要猜你現在在哪個階段、該做什麼事。每個環節都有人（或說，一個角色）負責，不會有事情「掉在縫裡」。
結果就是這張圖：
Garry Tan GitHub Contributions 對比
同一個人，相差 13 年。2026 的 Garry Tan 還得多管理 YC 的責任——但他的 GitHub contributions 比 2013 年高了 60%。
你的瓶頸在哪一個環節？
看完這七個環節，你可以問自己一個問題：你的開發流程卡在哪裡？
是想法還沒釐清就動手（Think）？計畫不夠具體導致實作一直返工（Plan）？沒人替你把 bug（Review）？不跑 QA 就上線（Test）？還是寫完就沒人反省（Reflect）？
gstack 不是要你把 23 個 skill 全用上。它的價值在於：讓你知道一條完整的工程流程應該長什麼樣，然後從你最痛的環節開始補。
原始碼在 github.com/garrytan/gstack，MIT 授權、無付費牆。