年燒上百萬Token養出的AI團隊免費開源！YC執行長Garry Tan在想什麼？

根據《TechCrunch》的報導，Y Combinator 執行長 Garry Tan 曾自嘲自己患上了「網路精神病」，因為和 AI Agent 一起工作太興奮，他幾乎睡不著覺。

近期，Garry Tan 在撰寫《賈伯斯傳》、《馬斯克傳》的傳記作家 Walter Isaacson 所主持的 podcast 節目《The Builders》中透露，他每年花在 AI token 上的費用約是 10 萬到 20 萬美元（新台幣 320 萬到 640 萬元），這些花費為的是執行替他工作、也替他打理生活的 AI Agent 們。

但比起帳單更值得細看的，是他公開在 GitHub 上的一套開發工具：gstack。

這是一組給 Claude Code 使用的「技能包」，Garry Tan 更稱它是自己的「開源軟體工廠」。它把 AI 寫程式助理，拆成一整支由 CEO、工程主管、設計師、QA 和資安長組成的虛擬團隊。

本文主要根據 Garry Tan 在 gstack 專案中的自述（README）和產品哲學（ETHOS）撰寫，並在實際安裝測試後，拆解這位在新創圈最有影響力的人之一，如何想像 AI 時代的軟體開發。

gstack：讓 AI 成為你的創業團隊

Garry Tan 曾把 gstack 描述為 23 個 Claude Code 技能，但專案成長得很快，本文實測下載的版本，安裝後註冊了 60 多個技能、內含約 4,800 個檔案，其中約 2,700 個是 TypeScript 程式，更新紀錄超過 900 則，開發與維護頻率極高。且此專案採 MIT 授權，完全免費。

安裝完成後，AI 跳出的第一個問題是：你想做什麼事？

有新點子想討論？輸入 /office-hour；把想法寫成規格再開工？輸入 /spec；已經有程式，想實際跑跑看哪裡有問題？輸入 /qa。

使用者只要輸入不同的斜線指令（Slash Command），AI 就會切換角色，從 YC 導師、執行長、工程主管，到資深設計師、資安長與發布工程師，分別執行不同任務。

這些指令並不是彼此獨立的工具，而是會串連成一套完整的軟體開發流程。

Garry Tan 強調，gstack 是一套流程，而不是工具集合。從構想、規劃、實作、審查、測試，到發布與回顧，每個階段都有對應的 AI 角色，而前一步的成果也會自動交給下一步。例如，/office-hours 產出的設計文件，就會成為 /plan-ceo-review 重新檢視產品方向時的重要依據。

換句話說，gstack 的價值不只是讓 AI 寫程式，而是透過明確的角色分工與工作流程，讓 AI 能夠像一組完整團隊般互相協作。

拆開來看，gstack 的主體其實更像是「寫給 AI 看的說明書」。每個技能都包含一份 Markdown 文件，詳細規定 AI 該怎麼想、怎麼問、何時停。除了提示文字，gstack 也包含大量實際程式。其中一項，是一個以 Playwright 為基礎的瀏覽器工具，讓 AI 能真的打開網頁、點擊、截圖操作介面。

此外，gstack 還會讓兩家不同的 AI 模型互相審查。在 Claude Code 裡進行審查時，預設會另外請 OpenAI 的 Codex 再看一次，反之亦然。Garry Tan 更分享到，有一次 Codex 找出了 15 個以上、4 次 Claude 的審查都沒抓到的問題，讓他撤回了一份擴張計畫。

對 Garry Tan 來說，gstack 真正能發揮威力的地方，在於讓多個 AI Agent 能夠「平行工作」。

他搭配可同時執行多個 Claude Code 工作階段的工具 Conductor，經常同時推進 10 至 15 個開發，有的正在討論新產品構想、有的負責審查程式碼、有的實作新功能，還有的進行測試。

他認為，如果沒有流程，10 個 AI Agent 就可能成為 10 個混亂的來源；但有了明確的工作分工與交接機制，便能像 CEO 管理一支團隊一樣，同時推進多項任務，自己只需要在關鍵決策上介入。

這或許也解釋了他為什麼會有這麼驚人的 token 帳單。畢竟，10 幾個 AI Agent 同時運作，每個 Agent 還都需要讀取數萬字的工作手冊，並反覆進行規劃、審查與測試。

為自己而建吧！屬於 2026 的軟體開發理念

Gstack 專案中另一項有趣的地方，是他的產品哲學，彷彿宣告了 Garry Tan 對於 AI 開發的世界觀。

這份文件也不只是寫給開發者看的工作原則，部分內容也被放進每個技能的開頭，直接影響著 AI 思考、執行任務與做出判斷的方式。

其中所提出的第一條原則，便翻轉了一句軟體工程師們的俗諺「別想把海煮沸」（Don't boil the ocean），原本是用來提醒人們不要貪多、避免一次處理過多問題的意思，但當 AI 大幅降低開發成本，過去因為人力與時間有限而被迫放棄的完整性，如今可能不再需要妥協。

以下為 gstack 的 9 條原則：

1. 把海煮沸（Boil the Ocean）
以最少的程式碼完整的實現需求，不要留下「之後再補」的測試與功能。

2. 動手前先搜尋（Search Before Building）
先理解經過驗證的既有方法與最新趨勢，再從第一原理思考。真正有價值的突破，是理解主流做法後，找到它為什麼可能是錯的。

3. 使用者主權（User Sovereignty）
AI 可以提出建議，但最終的決定權仍在使用者手中。即使 Claude 與 Codex 都認同某個方向，只要可能改變使用者原本的決策，就必須先取得同意。

4. 誠實工作（Honest Work）
不允許 AI 自行宣告任務完成。如果必須刪除測試、放寬檢查或略過驗證，都必須詢問使用者來決定。

5. 質疑前提（Attack the Premise）
如果在同一個假設下，兩次修正都無法解決問題，就應該重新檢視假設本身，而不是持續修補。

6. 先拆分，再考慮排隊（Separate Before Serializing Shared State）
當不同任務同時操作同份資料，常見做法是上鎖、排隊或重試，但這些都只是管理衝突。與其如此，不如拆分讓不同任務負責不同檔案，不必共享資源，需要時再合併，從源頭降低衝突發生的機會。

7. 讓操作可以重複執行（Make Operations Idempotent）
設計時需假設任何操作都有可能被執行兩次，確保重複執行不會造成非預期結果。

8. 解釋數字（Explain the Number）
任何數字都應說明其成因、計算方式與誤差範圍，否則就只是沒有根據的「傳言」。

9. 有用才留下（Earn Its Place）
每個功能與流程都必須證明自己確實有幫助，否則就應該刪除。

這份文件也詳細的致謝。其中第 5 到 8 條原則 Garry Tan 標註是改寫自 Lauren Tan（Grok Bot 的幕後推手）的 pstack，一套放在 AI 編輯器 Cursor 外掛裡的開源技能。
「Build for Yourself」為自己而建吧，Tan 在這份文件的最後提到，gstack 之所以存在，也是因為它的創造者想要它。

「批評是對的，但這不重要。」

隨著 gstack 的公開，卻也引來了不少批評。

Garry Tan 曾在 Ｘ 發文分享自己 60 天內產出了 60 萬行正式環境的程式碼，回覆、評論便迅速湧入：那只是 AI 爛作品、程式碼行數本來就沒意義、行數越多反而越糟等。

為此，Garry Tan 在 gstack 專案裡另寫了一篇〈On the LOC Controversy〉（關於程式碼行數的爭議）回應。文章開頭先讓步：程式碼行數是個爛指標，每個資深工程師都知道。他引用電腦科學家 Edsgar Wybe Dijkstra 在 1988 年的觀點，程式碼行數應該計算成「花掉的行數」，而不是「生產出的行數」。

他也把批評拆成三個層次。他同意「行數不能衡量品質」，也同意「AI 會灌水行數」，但他不同意的是第三層「炫耀行數很丟臉」。

Garry Tan 進一步以詳細的數據回應質疑。他將程式碼行數扣除空行、註解，並假設 AI 產出的程式碼比資深工程師冗長一倍後，仍估算出每日產量約為過去的 408 倍。就算假設 AI 灌水 100 倍，成長幅度仍有 8 倍。

品質方面，Garry Tan 指出，gstack 351 個 commit 中有 7 個遭撤回，撤回率約 2%；測試數量也從 2026 年初約 100 個增加至 2,000 個以上。不過，他也坦承，gstack 曾在 AI 程式碼偵測工具 slop-scan 中拿下當時最差的分數。

因此，他認為真正重要的指標，不是寫了多少程式碼，而是從「想要一個工具」到「工具存在且有人使用」的時間。他表示，這段過程已從 3 週縮短至 3 小時。

為了說明 gstack 的實際使用情況，Garry Tan 也公布了使用者自願回傳的統計：上線 5 週獲得 7.5 萬顆 GitHub 星、約 1.5 萬次安裝，累計技能執行 30.5 萬次。不過，由於部分資料來自私有倉儲，外界仍無法完整重現這些結果。

這些數字有趣的也許不是「量」，而是「速度」。Garry Tan 認為，這場爭論真正關心的不該是他個人，而是 AI 是否真的改變了軟體開發的生產力基準。