04-把 Codex 變成你的一人公司：gstack 完整實戰，從想清楚到上線
我們在上個章節介紹了 Codex——做一個 AI 對話工具，它既可以是你的工程師，也可以是你的設計師。但這個章節，我們要來講怎麼把這個 AI 對話工具，變成你真正創業路上的作戰夥伴。
這就是這篇文章的主題：gstack。
這是一個巨大的技能系統，它把「一個人用 AI 做產品」這件事，拆成了一間有分工的公司——CEO、設計師、工程主管、QA、資安長、發版工程師，各做各的事。
如果你還不知道「AI 技能」是什麼，可以先讀這篇：Agent Skill 完整教學：從入門到進階，提升你的 AI 生產力。
那先來介紹 gstack 是什麼。
gstack 是 Y Combinator CEO Garry Tan 個人開源的 AI 技能框架。這個框架瘋狂的地方在於：它不是讓 AI 當你的助手，而是讓 AI 變成一整間屬於你的一人公司。
這篇文章會一步一步拆解：怎麼裝、怎麼用、實戰工作流怎麼上手。
安裝
安裝方式非常簡單，直接把下面這段話貼給 Codex 就好：
請你閱讀 garrytan/gstack 這個專案，並根據專案的說明，把整個技能框架安裝到 Codex 中。
安裝完成後，重開 Codex。試著在輸入框打 /gstack，應該就能看到一大排快捷指令。
這樣就裝好了。你可以想像，安裝完成後，你的 Codex 瞬間多了一大堆超好用的指令，來幫你完成工作。
核心心法：不同階段，要不同的方法論
gstack 的整個設計，只建立在一句話上：軟體開發的不同階段，需要完全不同的思考模式。
你寫 code 前需要的是「會逼問你的 YC 合夥人」，寫 code 時需要的是「偏執的資深工程師」，發版時需要的是「不囉嗦的發版工程師」。一個通用的 AI 沒辦法同時是這三種人——它只會給你一個四平八穩、什麼都對一點、什麼都不夠狠的回答。
所以 gstack 把這些角色拆開，每個技能就是一個帶著特定人格、特定職責的專家。它強迫你照一條線走：
想清楚 → 規劃 → 做 → 審 → 測 → 發 → 復盤
（office-hours → plan → build → review → qa → ship → retro）
為了更好地跟大家解釋我是怎麼用 gstack 的，我直接舉例說明。
我目前正在開發一個新的 AI 產品，叫做 Orbivo。它解決的問題很簡單：讓任何人都能更輕鬆地賣出自己做的 Agent Skill。
我會用我怎麼做 Orbivo 的整個流程，把每個階段拆解給你看。
① 想清楚：/office-hours
office-hours 扮演一個 YC 辦公室時間的合夥人，職責很明確：診斷，不是鼓勵。 它的產出只有兩種——一份設計文件，或者一個結論：這個點子該放棄。
它會從六個維度來逼問你：
- 需求真實性——最強的證據是什麼，證明真的有人要？不是興趣、不是註冊，是真實的需要。
- 現狀替代——使用者現在用什麼爛方法在硬解？那個替代方案的代價是什麼？
- 絕望的具體——講出那個最需要它的真人：職稱、什麼讓他升職、什麼讓他半夜睡不著。
- 最窄的切口——這禮拜就有人願意付錢的最小版本是什麼？
- 觀察與意外——你有沒有看過某人在你不出手幫忙下使用它？他做了什麼讓你意外的事？
- 未來契合——三年後世界變了，你的產品會變得更必要、還是更不必要？
它的操作原則更狠。我直接引幾條：「具體是唯一的貨幣」「興趣不等於需求」「使用者的話勝過創辦人的說詞」「你覺得舒服，就代表你逼得不夠深」。它甚至有一份反推銷清單，禁止自己說「這個方向很有趣」「也許可以考慮」這種話——它被要求對你的每個答案直接表態。
我把 Orbivo 丟進去跑了一遍。下面是真實的診斷節錄：
你有發現重點嗎？
這個 AI 並不是幫我做決定，而是幫我把問題問對，幫我找到目前這個產品的想法裡，真正的卡點是什麼。這就是它的價值。
它不會讓你躲進「我想多寫一點程式、多做一些功能」這種太舒服的陷阱裡，而是把你抓出來，丟到大太陽底下去面對真實的世界。
在 Office Hours 裡，AI 會問你很多問題，確保你真的把產品的核心問題想清楚了。接著，我們就進到下一個階段。
② 規劃：四個 plan 系列
當這些問題都想好以後，AI 會幫你生成一份設計文件（Design Doc）。
基於這份文件，我們就進入下一個階段——用不同的視角，來審視這個產品。
/plan-ceo-review（CEO / 創辦人模式）
顧名思義，就是用產品創辦人的視角來審視計畫。
它的目的，是在實作前先檢查：這個產品到底值不值得做？規模夠不夠大？會不會踩坑？同時把各種風險、要追蹤的指標、長期路線都先想清楚。簡單說，就是用 CEO 的高度來思考這個產品。
濃縮成一句話，這個模式是用來問：
- 這個計畫值不值得做？
- 是不是做對了方向？
- 未來會不會變成「長期負債」？
- 能不能變成一個更好的產品？
它比較適用於新功能、商業策略、產品方向這類比較大的戰略決策。
/plan-eng-review（工程主管模式）
CEO 很重要，因為戰略的成敗，決定了後面的戰術跟戰技有沒有意義。方向定了，下一步就換成工程主管（也就是技術長）的視角，來審視這個專案。
你可以想像：你現在準備要開發產品了，但在真的找工程師動工之前，先請一位非常資深的技術顧問，幫你把方案鎖牢。他會幫你檢查真正可行的工程方案，等於是替這個產品確認一個站得住的地基。
/plan-design-review（資深設計師審你的計畫）
戰略視角定位好了，技術地基也打好了，下一步當然是「品味」。我覺得品味是產品裡非常重要的一環——尤其在現在這個人人都能做產品的 AI 時代，品味更是關鍵。
這個階段相當重要，這個技能會讓一位資深設計師來審核你的計畫，把所有「一看就是 AI 做的」的風險提早壓下來。
/autoplan（自動跑完三審）
簡單講，autoplan 會把前面的「三審」自動幫你跑完。如果你懶得一個指令一個指令慢慢打，直接輸入 autoplan，它就會一口氣把剛才提到的 CEO、資深工程師、資深設計師這三個視角的審查全跑完。
它不只會自動幫你做決定，還會幫你篩選，只把那些真正需要你「用品味拍板」的決策，留到你面前。
③ 設計：把「沒美感」這件事外包掉
/design-consultation
當你什麼都還沒有（沒設計系統、沒選字、沒配色），它會像一位資深設計師跟你對談，從零幫你建一套設計系統。它甚至會先去看你這個領域現有的網站長什麼樣（截圖分析它們的字體、配色），然後告訴你「哪些選擇能讓你看起來夠專業，哪些是我建議你冒的險」。
最後，它會根據你的決定，產出一份真正的設計系統文件。之後所有的 AI 開發都會照著這份文件走——這樣每次新增功能時，美感才會一致。不然你可能 A 頁面是賽博龐克風、B 頁面是質感簡約風，整個就很怪，對吧？所以一份統一的設計文件可以鎖住風格，這很重要。
接下來這兩個在實務上比較少用，但因為框架裡有，我就快速介紹一下；至於再剩下的，我覺得有點太刁鑽，平常就比較少碰。
/design-shotgun——「給我看幾個版本」。它一次生 3 個視覺變體，在瀏覽器開一個比較板，你挑一個方向、或要求重生。它還會跨對話記住你的品味。
/design-html——把核准的稿子變成真的能跑、會隨視窗大小自動排版的網頁。
④ 審查：偏執狂上場
這是 gstack 最硬的一塊，也是多篇實測公認「真的有用」的部分。
/review（偏執的工程師）
很多時候我們會遇到這種狀況：vibe coding 做出來的產品，明明在自己電腦上跑得好好的，一丟上線就直接爛掉。
這時你可以試試這個指令。它比較適合用在產品正式上線前，做一次全面的檢查。它會扮演那種最偏執的工程師，幫你把整個系統翻過一遍，看有哪些最邊緣的情況會出事，確保系統撐得住。遇到明顯的問題，它會直接幫你修好；比較模糊的部分，則會按決策流程來問你的意見。
/investigate（系統性除錯）
當你發現某個問題或 bug 的時候，可以試試這個技能。它會用一套系統性的方式幫你排錯：
- 收集症狀
- 閱讀程式碼、判斷邏輯
- 檢查最近的改動
- 嘗試重現 bug
- 鎖定問題範圍、開始修正
它的重點在於，像一個真正的工程師一樣，從最底層收集線索、一路找到問題的真正根源，而不是亂猜亂修。
/cso（資安長）
顧名思義，這個技能讓 AI 扮演你的資深資安長。vibe coding 這種開發方式最常被詬病的，就是容易留下資安漏洞——有時我們會因為懶得細看 AI 寫的東西，而忽略了風險。這個技能就讓 AI 用資安長的角度，幫你的程式碼做一次全面的安全體檢。
⑤ 測試：給 AI 一雙眼睛
/browse
這個技能讓 AI 能去操作一個簡潔版的瀏覽器，實際去操控你的網頁。
在過去，AI 開發程式時就只能寫程式，沒辦法打開瀏覽器、看這個程式在網頁上實際跑出來的樣子。這個技能正好補上了這雙眼睛。
/qa（QA 主管）——/browse 給眼睛，/qa 給方法論。最常見的用法：你剛寫完一個功能，直接打 /qa，它會自動判斷你改動的地方影響到哪些頁面，打開瀏覽器一頁一頁測，每修好一個 bug，還會自動補一條測試，防止它以後又壞掉。
/canary（上線後監控）——上線後，它繞著你的關鍵頁面一圈圈地巡，盯著有沒有跳錯誤、有沒有變慢、有沒有頁面壞掉，並截圖跟上線前的樣子比對。
⑥ 發版與上線
/ship（發版機器）
當你的功能都做完、準備要正式上線時，這個指令幫你把上線前那一堆瑣碎雜事一次處理掉——自動檢查程式有沒有問題、補上該有的測試、把這個版本整理好、送進上線流程。
很多產品都死在一個很微妙的時刻：好玩的部分做完了，只剩無聊的收尾工作。人會拖延那一段，但 AI 不會。Garry Tan 有句話戳得很準：「很多分支死在『有趣的部分做完、只剩無聊的發版工作』那一刻。人類會拖延，AI 不該。」
/land-and-deploy（真的把它推上線）
/ship 幫你把功能整理好、準備上線；這個指令負責真正把它推上線，並在上線後自動檢查網站有沒有正常運作。一個指令，從「準備好了」到「確認線上一切正常」。
/retro（每週復盤）
到了週末，它幫你回顧這一週到底做了哪些事、進度如何，寫成一份誠實的復盤報告，讓你清楚看見自己的節奏。
⑦ 安全護欄：碰重要東西時的保險
這幾個小工具，特別適合一個人創業的人——當你身邊沒有同事幫你踩煞車時，這就是你的煞車。
/careful——當 AI 要做那種「做了會回不去」的危險動作（例如一次刪掉大量檔案、清空整個資料）之前，先跳出來警告你、等你確認。至於日常那些無害的清理，它不會誤報、不會煩你。
/freeze——把 AI 能改動的範圍，鎖在某一個資料夾裡。舉個例子：我在處理 Orbivo 的「金流」問題時，就可以把 AI 鎖在金流那一塊，避免它一個順手，去動到完全不相干的「登入」功能、結果改出新的問題。
/guard——把 /careful 跟 /freeze 兩個合在一起。碰到最重要、最不能出錯的部分時，就開這個最高安全模式。
/learn——管理 AI 跨對話累積下來的記憶：你的專案習慣、踩過的坑。之後它在給你建議前，會自動翻這些筆記。當你看到它說「Prior learning applied（套用了過去的經驗）」，就代表它在你的專案上越用越聰明、越來越懂你。
Office Hours 為什麼是這套東西的靈魂
把所有指令看完，你會發現一個模式：gstack 真正稀缺的價值，不在那些會寫 code 的技能，在那些逼你想清楚的技能。
/review、/qa、/ship 這些，老實說很多 AI 重度使用者早就自己寫過類似的指令。但 office-hours 跟 plan 系列不一樣——它們把「YC 合夥人怎麼逼問創辦人」這種藏在頂尖加速器裡的判斷力，壓成了你隨時叫得出來的東西。這是中文圈幾乎沒有人有的資源。
而且它對個人創業者特別狠、也特別準。因為我們最容易犯的錯，就是「躲進寫 code 的舒適區」——做產品很爽、被市場拒絕很痛，所以我們會一直做、一直做，逃避那個「到底有沒有人要」的問題。office-hours 的存在，就是不讓你逃。
最後，它不是萬靈丹
雖然剛剛一口氣介紹了這麼多指令，但實際上你最後真正會用的，大概就五六個。
說實話，你大致看過去、對「什麼階段需要什麼」有個概念就好。你可以把這篇文章收藏起來，等真的需要的時候再回來翻。
千萬別去背這些指令。別忘了，它們的本質也只是一連串的提示詞而已。它提供的是一套方法論，幫你去思考——但真正的判斷力、真正的品味、真正的決策，仍然在你自己手上。
還有一點要提醒：它帶著很重的矽谷創業偏見，對受監管的產業、對已經有既有流程的團隊，會有點水土不服。
你該怎麼開始
別想著 52 個指令都學。照那篇用了一個月的實測結論，加上我自己的用法，先抓這條主幹就好：
/office-hours——任何新點子、新功能，動手前先被它逼問一輪。這是你投資報酬率最高的一個。/review——寫完 code，讓偏執狂掃一遍那些平常測不出來的 bug。/qa——讓它開真瀏覽器，把你改的頁面跑一遍。/ship——收尾、檢查、準備上線。
把這四個用熟，你就已經拿到 gstack 八成的價值了。其餘的（設計系列、資安長、上線監控那些），等你真的遇到那個場景再叫出來就好。
對一個想用 AI 做產品的個人創業者來說，gstack 最大的意義不是「它幫你寫 code」——AI 本來就會。它的意義是：把「一個人＝一間公司」這件事，從一句口號，變成了一條你真的能照著走的流水線。 你不再只是一個對著 AI 下指令的人，你是一個有 CEO、有工程主管、有 QA、有資安長替你把關的團隊——只是這個團隊，全都住在你的電腦裡。
而我自己最大的收穫，反而是被 office-hours 逼著承認：Orbivo 該做的不是再寫一個功能，是去賣出第一筆錢。
下一篇，我會把這條「先賣再做」的線講透。我們下個單元見。