Garry Tan 開源 Claude Code 工具包

6 天，超過 20,000 個 GitHub stars。這個數字放在開發工具 repo，很少見。講白了，大家追的已經不是「哪個模型最會寫」，而是「哪套流程真的能讓我週一上班就開始交付」。

Garry Tan 開源的 gstack，就是踩中這個點。它不是另一個聊天機器人包裝，也不是賣夢的提示詞合集，而是一套給 Claude Code 用的工作流骨架，讓你少踩幾次坑，快一點把程式碼推進 repo。

我覺得這件事有意思的地方，不在於 Garry Tan 本人有名。真正有意思的是，開發者現在願意為「可重複的方法」按星星，遠多過只看模型跑分。這代表 AI 寫程式的重點，正在從模型能力，轉到流程設計。

為什麼 gstack 會紅這麼快

先講現實面。Garry Tan 是 Y Combinator 的 CEO，自帶流量。這當然有幫助。但如果內容空洞，流量通常撐不過兩天，stars 也不會在 6 天內衝到 20,000。

gstack 吸引人的地方，在於它給的是一個「我平常怎麼用 Claude Code」的可檢查版本。你不是聽一堆抽象建議，而是直接看到檔案怎麼放、提示怎麼寫、工作方式怎麼拆。這比任何「AI 最佳實踐」簡報都更有用。

很多開發者卡住的點也很單純。模型很強，但每次開新專案都要重想一次上下文、規則、指令格式、檢查方式。搞到最後，時間不是花在寫功能，而是花在跟 AI 對齊。gstack 幫忙做的，就是把這些重複勞動收斂成一套模板。

• 專案名稱：gstack
• 作者：Garry Tan
• 平台：GitHub
• 用途：Claude Code 工作流工具包
• 早期成績：6 天超過 20,000 stars

GitHub stars 當然不是完整指標。有人會收藏不會用，這很正常。但 20,000 這個量級，已經不是小圈圈互捧。這代表它有跨出 Claude 使用者社群，打到更廣的開發者注意力。

你可能會想問，大家真有這麼缺工作流嗎？答案大概是有。現在多數人都摸過 Copilot、Cursor、Claude 或 ChatGPT，但能穩定把 AI 放進日常開發流程的人，沒有想像中多。工具很多，方法很亂，這就是 gstack 有市場的原因。

gstack 到底提供了什麼

核心概念不複雜。gstack 把 Claude Code 的使用方式，整理成一套偏實戰、帶立場的 workflow。它不是要你從空白聊天框開始亂問，而是先給你結構，再讓你照著專案需求去改。

這種工具包的價值，通常不在神祕感，而在一致性。你有一個固定起點，就比較容易讓模型在同樣規則下工作。少一點即興，多一點可預測，輸出品質通常會穩很多。

說真的，AI 寫程式常常不是模型不夠強，而是上下文太亂。專案資料夾沒整理、提示詞沒紀律、需求拆解太含糊、review 沒流程，最後得到一堆看起來能跑、實際上難維護的程式碼。gstack 這類 repo 的作用，就是把這些隱性流程明文化。

“People often ask me, ‘What are the secrets to YC?’ The answer is there are no secrets. The best founders are relentlessly resourceful.”

— Garry Tan, quoted on Y Combinator

這句話本來不是在講 Claude Code，但套在 gstack 很貼切。它傳達的意思很直接：沒有什麼藏起來的祕技，重點是把有效的方法整理出來，讓別人可以檢查、複製、修改。

也因為這樣，gstack 比很多「神級提示詞」更有參考價值。提示詞很容易被截圖轉貼，但通常脫離原本情境就失效。工作流 repo 不一樣，它把情境、規則、組織方式一起包進去，別人才能真的拿來用。

• 提供可重用的專案結構
• 把提示與規則放進可追蹤檔案
• 讓 Claude Code 有更明確的工作邊界
• 方便 fork 後改成自己的團隊版本

為什麼可重複工作流比單次提示更重要

前一波 AI coding 熱潮，很多人迷的是 prompt engineering。今天寫一段神 prompt，明天貼到 X 上，大家轉來轉去。這種玩法有趣，但很難維護。你換個 repo、換個團隊、換個需求，效果常常直接掉一截。

團隊真的需要的東西比較樸素。要能 onboarding、新人看得懂、出問題能追、規則能修改、版本能管理。這些事情，單一 prompt 幾乎做不到。repo 化的 workflow 反而比較像真實軟體工程。

你把個人習慣寫進 repo，就等於把經驗轉成基礎設施。這很重要。因為 AI coding 的瓶頸，越來越不是「模型會不會寫」，而是「團隊怎麼用才不會亂」。

• 單一 prompt 容易複製，但難維護
• 文件化流程比較容易 audit
• repo 式做法比較適合團隊協作
• 固定結構可降低導入成本
• 規則寫成檔案後，才方便版本控制

我覺得這也是 gstack 爆紅的根本原因。多數開發者現在手上都摸得到強模型。缺的不是模型入口，而是能穩定用在真實 codebase 的工作方式。

再講白一點，大家不想再看 AI demo 了。你可以在 30 秒內產生 todo app，沒人在乎。大家在乎的是，一個 3 年歷史、200 個資料夾、多人協作的專案，AI 到底能不能幫你少改壞 2 個檔案、少浪費 30 分鐘。

放到市場來看，gstack 卡在什麼位置

現在 AI coding 市場很擠。GitHub Copilot 早就把「自動補全」變成基本盤。Cursor 把編輯器層做得很深。Claude Code 則吸引一批喜歡在 terminal 裡工作、想要 agent 式互動的開發者。每家都在搶同一件事：讓開發者少花時間處理重複工作。

gstack 沒有要跟這些產品正面對打。它不是完整平台，也不是新模型。它比較像工作流層。這點反而聰明。因為很多開發者不在乎品牌口號，只在乎從 issue 到 merged pull request，中間到底少繞幾圈。

這種定位還有一個優勢。平台要做很重，工作流可以很輕。你今天用 Claude Code，明天換別的 agent，只要核心方法有價值，很多結構還是能沿用。對開發者來說，這比被綁死在單一產品舒服得多。

• gstack：工作流模板，主打 Claude Code 使用方法
• GitHub Copilot：強在 IDE 內補全與整合
• Cursor：強在編輯器體驗與多步操作
• Claude Code：強在 terminal 內 agent 式互動
• 一般 prompt 包：上手快，但可維護性差

如果只看數字，6 天 20,000 stars 已經很夠看。多數開源開發工具 repo，一年都碰不到這個量級。這說明市場對 Claude Code 專屬工作法有明確需求，也說明「把個人 workflow 開源」這件事，確實有人要。

還有一個文化層面的因素。這兩年大家對 AI 生產力宣傳越來越有戒心。廣告文案說得天花亂墜，實際打開來常常一堆限制。相較之下，公開 repo 反而誠實。檔案都在那裡，規則都看得到，你 fork 下來跑一遍，值不值得自然有答案。

這股趨勢背後的產業脈絡

AI coding 工具這一年明顯往「系統化」走。早期大家重視模型本身。現在大家開始重視 context management、檔案結構、任務拆解、review loop、權限控制。因為實務上真正拉開差距的，常常是這些周邊設計。

對台灣團隊來說，這點特別有感。很多公司不是從零開始做新產品，而是在維護既有系統、串老 API、接內部伺服器、處理混雜資料。這種環境最怕 AI 自作聰明亂改。沒有流程，模型越積極，風險越高。

所以你會看到越來越多團隊開始做自己的 AI 開發規範。像是哪些資料夾能碰、哪些檔案先別動、需求要怎麼描述、產出前要跑哪些測試。這些東西過去靠資深工程師口耳相傳，現在慢慢變成文件、腳本、模板。

從這個角度看，gstack 的意義不只是某個 repo 很紅。它像一個訊號。高知名度工程領域人物，開始把自己的 AI coding 方法公開。接下來很可能會有更多 CTO、Staff Engineer、創業者，把自己的 setup 直接丟到 GitHub 給大家研究。

這也會讓競爭方向改變。以前比誰模型新，現在會慢慢變成比誰流程穩、誰更容易導入、誰在真實專案裡省下的時間更多。你如果是工具開發者，這件事最好現在就看懂，不然很容易一直在做 demo 產品。

開發者現在可以怎麼看這件事

如果你有在用 Claude Code，gstack 很值得讀。就算你最後不會整套採用，也可以拆開看。哪些規則適合你的團隊，哪些結構太重，哪些提示寫法能直接拿來測，都有參考價值。

如果你是團隊管理者，我會建議別只問工程師「有沒有用 AI」。這問題太空。你應該問的是：有沒有固定流程、哪些任務適合交給 AI、出了錯怎麼回溯、程式碼 review 要不要加新規則。這些問題才真的影響交付品質。

我的判斷是，接下來 3 到 6 個月，會有更多知名工程師公開自己的 AI coding setup。真正會被留下來的，不是聲量最大那個，而是能在真實專案裡，穩定省下 20% 到 30% 重複工作時間的那種做法。你現在就可以做一件事：挑一個小專案，試著把自己的 AI workflow 文件化。寫成 repo，跑兩週，再看哪裡最卡。那會比收藏 50 個 prompt 有用得多。