gstack 完整解析：YC 總裁如何每天利用 AI 編寫 10,000 行程式碼

TL; DR 重點摘要

gstack 是 YC 總裁 Garry Tan 開源的 Claude Code 工程系統，擁有 18 個專家角色和 7 種工具，涵蓋從產品構思到程式碼發布的整個衝刺週期。

核心理念不是「讓 AI 寫更多程式碼」，而是讓 AI Agent 進行角色扮演：CEO 負責產品方向，工程經理鎖定架構，QA 用真實瀏覽器測試，發布工程師一鍵部署。

Garry Tan 聲稱，在使用這套系統的 60 天內，他寫了 60 萬行生產程式碼（其中 35% 是測試），每天產出 1 萬到 2 萬行可用程式碼，同時還擔任 YC CEO。

所有技能都是純 Markdown 檔案，在 MIT 授權下開源，30 秒內即可安裝，並支援 Claude Code、Codex、Gemini CLI 和 Cursor 等多個平台。

該專案在發布一週內獲得超過 33,000 個 GitHub 星星，也引發了「這不就是一堆提示詞嗎？」等激烈爭論。

一個人，60 天，60 萬行程式碼

2026 年 3 月，YC 總裁 Garry Tan 在西南偏南（SXSW）對 Bill Gurley 說了一句話，讓全場鴉雀無聲：「我現在每天只睡四小時，因為我太興奮了。我想我得了網路精神病（AI 狂熱症）。」1

兩天前，他在 GitHub 上開源了一個名為 gstack 的專案。這不僅僅是一個普通的開發工具，而是他過去幾個月使用 Claude Code 進行程式設計的完整工作系統。他提出的數據令人震驚：過去 60 天內寫了超過 60 萬行生產程式碼，其中 35% 是測試；過去 7 天的統計數據顯示，增加了 140,751 行程式碼，提交了 362 次，淨增約 115,000 行程式碼。所有這些都發生在他全職擔任 YC CEO 期間。2

本文適合正在使用或考慮使用 AI 程式設計工具的開發者和技術創始人，以及對「AI 如何改變個人生產力」感興趣的企業家和內容創作者。本文將深入剖析 gstack 的核心架構、工作流程設計、安裝和使用方法，以及其背後的「AI Agent 角色扮演」方法論。

gstack 的核心架構：將 Claude Code 轉變為虛擬工程團隊

gstack 的核心理念可以用一句話概括：不要將 AI 視為萬能助手，而是將其分解為一個虛擬團隊，每個成員都有特定的職責。

傳統的 AI 程式設計涉及打開一個單一的聊天視窗，同一個 AI 負責編寫程式碼、審查程式碼、測試和部署。問題在於，在同一個會話中編寫的程式碼由同一個會話審查，這很容易導致「自我肯定」的循環。Reddit r/aiagents 上的一位用戶精確地總結道：「斜線指令強制在不同角色之間切換上下文，打破了在同一個會話中編寫和審查程式碼的奉承螺旋。」3

gstack 的解決方案是 18 個專家角色 + 7 種工具，每個角色對應一個斜線指令：

產品和規劃層：

/office-hours：YC 合作夥伴模型，使用 6 個強制性問題，幫助你在編寫程式碼之前釐清產品方向。

/plan-ceo-review：CEO 級別的提案審查，提供四種模式：擴展、收縮、維護和策劃。

/plan-eng-review：工程經理鎖定架構，輸出 ASCII 架構圖、測試矩陣和故障模式分析。

/plan-design-review：資深設計師對每個設計維度進行 0 到 10 的評分，並解釋 10 分是什麼樣子。

/design-consultation：設計合作夥伴，從頭開始建立完整的設計系統。

開發和審查層：

/review：資深工程師角色，專門尋找通過 CI 但會在生產環境中爆炸的錯誤。

/investigate：系統性根本原因偵錯，鐵律是：「不調查，不修復。」

/design-review：設計師和程式設計師，審查後直接使用原子提交修復問題。

/codex：呼叫 OpenAI Codex CLI 進行獨立程式碼審查，實現跨模型交叉驗證。

測試和發布層：

/qa：QA 主管，打開真實的 Chromium 瀏覽器，點擊並測試所有流程，查找並修復錯誤，並生成回歸測試。

/qa-only：純報告模式 QA，只報告錯誤，不修改程式碼。

/ship：發布工程師，同步主分支，運行測試，審核覆蓋率，推送程式碼，打開 PR – 一個指令即可完成所有操作。

/document-release：技術文件工程師，自動更新與當前發布相關的所有文件。

/retro：工程經理領導每週審查，輸出個人貢獻、發布節奏和測試健康趨勢。

安全和工具層：

/careful：危險指令警告，在執行 rm -rf、DROP TABLE、force-push 之前彈出警告。

/freeze：編輯鎖定，將檔案修改範圍限制在指定目錄。

/guard：/careful + /freeze 的組合，最高安全級別。

/browse：賦予 Agent「眼睛」，一個真實的 Chromium 瀏覽器，每個指令約 100 毫秒響應。

這些不是一堆零散的工具。這些角色按照思考 → 規劃 → 建立 → 審查 → 測試 → 發布 → 反思的順序串聯起來，每個階段的輸出都會自動饋送到下一個階段。/office-hours 生成的設計文件由 /plan-ceo-review 閱讀；/plan-eng-review 編寫的測試計畫由 /qa 執行；/review 發現的錯誤由 /ship 驗證是否已修復。2

為什麼 gstack 點燃了整個開發者社群

在發布一週內，gstack 獲得了超過 33,000 個 GitHub 星星和 4,000 個分支，在 Product Hunt 上名列前茅，Garry Tan 的原始推文獲得了 84.9 萬次瀏覽、3,700 個讚和 5,500 次收藏。TechCrunch 和 MarkTechPost 等主流科技媒體都報導了它。1 4

但爭議也同樣激烈。YouTuber Mo Bitar 製作了一個名為「AI 讓 CEO 產生妄想」的影片，指出 gstack 本質上是「一堆文字檔案中的提示詞」。Free Agency 創始人 Sherveen Mashayekhi 在 Product Hunt 上直言不諱地說：「如果你不是 YC 的 CEO，這東西永遠不會出現在 Product Hunt 上。」1

有趣的是，當 TechCrunch 記者要求 ChatGPT、Gemini 和 Claude 評估 gstack 時，三者都給出了正面的評價。ChatGPT 說：「真正的洞察是，當你模擬一個工程組織結構時，AI 程式設計效果最好，而不是簡單地說『幫我寫這個功能』。」Gemini 稱其為「複雜」，認為 gstack「並沒有讓程式設計變得更容易，而是讓程式設計變得更正確。」1

這場辯論的本質其實不是技術性的。33,000 個星星和「一堆 Markdown 檔案」的事實可以同時成立。真正的分歧在於：當 AI 將「寫得好的 Markdown 檔案」轉化為可重複的工程方法時，這是創新還是僅僅是包裝？

從頭開始：gstack 安裝和實用工作流程

30 秒安裝

gstack 的安裝非常簡單。打開 Claude Code 終端機並貼上以下指令：

``bash git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup``

安裝後，將 gstack 配置區塊新增到專案的 CLAUDE.md 檔案中，列出可用的技能。整個過程不到 30 秒。如果你也使用 Codex 或其他支援 SKILL.md 標準的 Agent，設定腳本將自動檢測並將它們安裝到相應的目錄中。

先決條件：你需要安裝 Claude Code、Git 和 Bun v1.0+。

完整的實用工作流程

假設你想建立一個日曆簡報應用程式。這是一個典型的 gstack 工作流程：

輸入 /office-hours 並描述你的想法。 gstack 不會立即開始編寫程式碼，而是會像 YC 合作夥伴一樣詢問你：你的用戶是誰？他們有什麼具體的痛點？現有解決方案的不足之處在哪裡？它可能會告訴你：「你說的是日曆簡報應用程式，但你真正建立的是一個個人幕僚長 AI。」

執行 /plan-ceo-review。讀取上一步生成的設計文件，從 CEO 的角度挑戰你的範圍和優先順序，並執行 10 個維度的審查。

執行 /plan-eng-review。鎖定技術架構，輸出資料流圖、狀態機、錯誤路徑和測試矩陣。

批准計畫，開始編碼。 Claude 在大約 8 分鐘內編寫了 11 個檔案中的 2,400 行程式碼。

執行 /review。自動修復 2 個明顯問題，標記 1 個競爭條件以供你確認。

執行 /qa https://staging.myapp.com。打開真實瀏覽器，點擊並測試所有流程，查找並修復錯誤，並生成回歸測試。

執行 /ship。測試從 42 個增加到 51 個（+9 個新測試），PR 自動建立。

八個指令，從想法到部署。這不是一個副駕駛；這是一個團隊。

平行處理才是真正的殺手級功能

一個衝刺大約需要 30 分鐘。但真正改變遊戲規則的是，你可以同時運行 10 到 15 個衝刺。不同的功能、不同的分支、不同的 Agent，全部平行處理。Garry Tan 使用 Conductor 來協調多個 Claude Code 會話，每個會話都在獨立的工作區中運行。這是他每天產出 10,000+ 行生產程式碼的秘密。

結構化的衝刺流程是平行處理能力的先決條件。沒有流程，十個 Agent 就是十個混亂的來源。有了思考 → 規劃 → 建立 → 審查 → 測試 → 發布的工作流程，每個 Agent 都知道它需要做什麼以及何時停止。你像 CEO 管理團隊一樣管理它們：專注於關鍵決策，讓它們自己運行其餘部分。2

常見問題排除

技能未顯示？ 執行 cd ~/.claude/skills/gstack && ./setup

/browse 失敗？ 執行 cd ~/.claude/skills/gstack && bun install && bun run build

版本過舊？ 執行 /gstack-upgrade，或在 ~/.gstack/config.yaml 中設定 auto_upgrade: true

AI Agent 角色扮演：gstack 背後的方法論

gstack 最有價值的部分可能不是 25 個斜線指令，而是其背後的思維模式。該專案包含一個 ETHOS.md 檔案，記錄了 Garry Tan 的工程哲學。有幾個核心概念值得解構：

「煮沸湖水」：不要只是修補，而是徹底解決問題。當你發現一個錯誤時，不要只修復那一個；相反，要問「為什麼會出現這種類型的錯誤」，然後在架構層面消除整個類型的問題。

「先搜尋再建立」：在編寫任何程式碼之前，先搜尋現有解決方案。這個概念直接體現在 /investigate 的「鐵律」中：不調查，不修復；如果連續三次修復失敗，你必須停止並重新調查。

「黃金時代」：Garry Tan 相信我們正處於 AI 程式設計的黃金時代。模型每週都在變得更強大，那些現在學會與 AI 協作的人將獲得巨大的先發優勢。

這種方法論的核心洞察是，AI 能力的邊界不在模型本身，而在於你賦予它的角色定義和流程約束。一個沒有角色邊界的 AI Agent 就像一個沒有明確職責的團隊；它似乎能夠做所有事情，但實際上，它什麼都做不好。

這個概念正在擴展到程式設計之外。在內容創作和知識管理場景中，YouMind 的技能生態系統採用了類似的方法。你可以在 YouMind 中建立專門的技能來處理特定任務：一個技能用於研究和資訊收集，另一個用於文章撰寫，第三個用於 SEO 優化。每個技能都有明確的角色定義和輸出規範，就像 gstack 中的 /review 和 /qa 各有其職責一樣。YouMind 的技能市集也支援用戶建立和分享技能，形成一個類似於 gstack 開源社群的協作生態系統。當然，YouMind 專注於學習、研究和創作場景，而不是程式碼開發；兩者在各自領域相輔相成。

常見問題

問：gstack 免費嗎？我需要付費才能使用所有功能嗎？

答：gstack 完全免費，採用 MIT 開源授權，沒有付費版本，也沒有等候名單。所有 18 個專家角色和 7 種工具都包含在內。你需要訂閱 Claude Code（由 Anthropic 提供），但 gstack 本身是免費的。安裝只需要一個 git clone 指令，耗時 30 秒。

問：gstack 只能與 Claude Code 搭配使用嗎？它支援其他 AI 程式設計工具嗎？

答：gstack 最初是為 Claude Code 設計的，但現在支援多個 AI Agent。透過 SKILL.md 標準，它與 Codex、Gemini CLI 和 Cursor 相容。安裝腳本將自動檢測你的環境並配置相應的 Agent。然而，一些基於 Hook 的安全功能（例如 /careful、/freeze）在非 Claude 平台上會降級為文字提示模式。

問：「60 天內 60 萬行程式碼」是真的嗎？這個數據可信嗎？

答：Garry Tan 已公開分享他在 GitHub 上的貢獻圖，2026 年有 1,237 次提交。他也公開分享了過去 7 天的 /retro 統計數據：增加了 140,751 行程式碼，提交了 362 次。值得注意的是，這些數據包括 AI 生成的程式碼和 35% 的測試程式碼，並非全部手寫。批評者認為程式碼行數不等於品質，這是一個合理的問題。但 Garry Tan 的觀點是，透過結構化的審查和測試流程，AI 生成程式碼的品質是可控的。

問：我不是開發者，gstack 對我來說有什麼價值？

答：gstack 最大的啟發不在於具體的斜線指令，而在於「AI Agent 角色扮演」方法論。無論你是內容創作者、研究員還是專案經理，你都可以從這種方法中學習：不要讓一個 AI 做所有事情，而是為不同的任務定義不同的角色、流程和品質標準。這個概念適用於任何需要 AI 協作的場景。

問：gstack 與普通的 Claude Code 提示詞有什麼根本區別？

答：區別在於系統性。普通的提示詞是一次性指令，而 gstack 是一個鏈式工作流程。每個技能的輸出會自動成為下一個技能的輸入，形成一個完整的思考 → 規劃 → 建立 → 審查 → 測試 → 發布 → 反思的閉環。此外，gstack 內建了安全防護措施（/careful、/freeze、/guard），以防止 AI 在偵錯期間意外修改不相關的程式碼。這種「流程治理」是單一提示詞無法實現的。

總結

gstack 的價值不在於 Markdown 檔案本身，而在於它驗證的範式：AI 程式設計的未來不是關於「更聰明的副駕駛」，而是關於「更好的團隊管理」。當你將 AI 從一個模糊的、萬能的助手分解為具有特定職責的專家角色，並將它們與結構化流程連接起來時，個人的生產力可以發生質的變化。

有三個核心要點值得記住。首先，角色扮演比泛化更有效：給予 AI 明確的職責邊界比給予它廣泛的提示詞更有效。其次，流程是平行處理的先決條件：如果沒有思考 → 規劃 → 建立 → 審查 → 測試 → 發布的結構，多個 Agent 平行運行只會造成混亂。第三，Markdown 就是程式碼：在 LLM 時代，寫得好的 Markdown 檔案是可執行的工程方法論，這種認知轉變正在重塑整個開發者工具生態系統。

模型每週都在變得更強大。那些現在學會與 AI 協作的人將在即將到來的競爭中擁有巨大的優勢。無論你是開發者、創作者還是企業家，考慮從今天開始：使用 gstack 轉變你的程式設計工作流程，並將「AI Agent 角色扮演」方法論應用到你自己的場景中。讓你的 AI 進行角色扮演，將其從一個模糊的助手轉變為一個精確的團隊。