Vibe Deploying 小白也能把 AI 專案丟上雲端的那一天
其實還沒有 Cursor 這些開發工具的時候，我就嘗試過聽著那時剛出的 GPT-4，一步步複製貼上，把自己寫的程式丟到 AWS，聽了 AI 的指示開了一台 EC2。
結果下個月雲端代理商的帳單無情的發來。
對，因為差點被好奇心殺死的 CEO，公司浪費了三萬塊。
如果我當時選了有 GPU 的電腦，肖準可能已經滅亡了(?)
從此對於部署這件事情開始有了 PTSD，還是都交給專業的工程師完成我 Vibe 出來的 Prototype。
開始推廣：文組搞 Prototype，工程師部署的概念。
去外面講 Vibe Coding 的時候，通常也還是用 HTML + CSS + JS 這種靜態網頁三件套在 Demo，深怕。
目錄
周末我決定自己上雲
周末我決定宅在家尻程式碼，決定自己「上雲」的時候，其實超緊張。
程式在我電腦跑得好好的
一換成「雲端」三個字，腦袋就自動浮現這些畫面：
伺服器很貴
一定很容易設定錯
一不小心就燒錢
但 AI 發展就是這麼的士別三日，刮目相看。
我才發現一件事：
上雲已經你想像中那麼難以入手，並不再是你要買一堆線上課程，看很多印度人錄的 Youtube，上很多工作坊，拿一堆證照才能做的事情了。
以下正文，本文貢獻給發了好多 Credit 給我 GCP Startup Program。
先記住一句話：什麼叫上雲？
你眼前這台電腦，是一台地端的電腦。
如果你要做個網站，你可以去中華電信申請一個固定的 IP，別人就可以連過來你的電腦了。
但如果你要做一個網站，最好放在一個永遠開機、永遠有網路、別人可以用網址打開的電腦上。
因為你有時候在用你自己的電腦做別的事情，你也可能出門想把你電腦關掉。
所以，
上雲 = 把你的程式，搬到一台永遠開機、永遠有網路、別人可以用網址打開的電腦上。
就這樣而已。
本文用到的 GCP 組合
以下都用 GCP 的 term 來說明。
幾朵大雲其實都有相應的名詞，但因為 GCP 葛格給我最多 Credit，我用她的產品名稱做說明。
我打算解釋最適合 Vibe Deploying 的 Cloud Run + Firestore，搭配 gcloud / Gemini CLI。
Ch1. Cloud Run 是什麼？
沿著字面說，讓你的程式 Application 在雲上跑。
但你不用自己管伺服器，
所以 Cloud Run 是 Serverless 的應用執行平台。
傳統意義上的 Server 後端一定要：
開一台 VM
SSH 進去
裝系統、裝套件
Cloud Run 刻意把這些全部拿掉。
你只會看到一件事：
我丟了一個 container 上去，它給我一個網址。
Cloud Run 很適合還在做產品、還在試市場、還不確定流量什麼時候來的人。
因為你不用先為未來付錢，只要為現在正在發生的事情負責。
Ch2. 那 Firestore 又是什麼？
Firestore 是雲端的 NoSQL 文件型資料庫。
它非常適合 AI App、後端 API、產品型系統、權限與紀錄導向的資料。
SQL 是規則先行、結構嚴謹。
Firestore 是產品先行、結構彈性。
你可以先把資料存起來，
先讓系統跑起來，
規則可以邊跑邊修，邊用邊長。
在 Cloud Run + Firestore 的架構中：
Cloud Run 是無狀態的後端服務。
Firestore 是有狀態的系統記憶。
你可以一直換 Cloud Run，
Firestore 會幫你記得你走過哪些路。
Ch3. Vibe Deploying 的開發方式
以前我以為部署一定是：
本機寫完
開 GCP
開 Cloud Shell
丟程式
祈禱不要爆炸
Cloud Shell 的本質其實很單純。
它就是 Google 在瀏覽器裡幫你準備好的一台乾淨 Linux 電腦。
但真正改變我心態的是這件事：
我發現我可以在本機裝 gcloud。
我可以在 Cursor 裡寫程式。
然後在同一個視窗裡直接 deploy。
部署不再是一個儀式，
而是一個可以隨時發生的動作。
寫到一半可以 deploy。
改一行也可以 deploy。
不確定行不行就先 deploy。
Ch4. 真正的高手玩法：在 Cloud Shell 裡直接啟動 Gemini CLI
當我以為事情已經夠順了，
我又發現了一個更作弊的玩法。
真正的高手，其實是在 Cloud Shell 裡面直接啟動 Gemini CLI。
Gemini CLI 是什麼？
Gemini CLI 的全名是 Command Line Interface，
但它真正厲害的地方不在於「CLI」，
而在於這件事：
你不用學會指令，你可以直接用自然語言跟雲端說你要幹嘛。
你可以問：
幫我看哪裡權限沒開
幫我確認 Cloud Run 為什麼失敗
幫我檢查 Firestore 連線
甚至是直接在裡面說：
「請幫我用這台主機開發一個 OOXX」
因為它把一件原本很工程師取向的事情，
變成一個你「敢問、敢試」的過程。
以前的黑畫面是這樣的：
我不知道要打什麼
我也不知道錯在哪
我只知道它紅紅的很可怕
現在變成：
我直接問它：「現在哪裡不對？」
而且因為你是在 Cloud Shell（GCP 官方環境） 裡面問，
它給你的答案，通常是符合當下雲端狀態的，
不是網路上三年前的文章。
Ch5. 超級個體還是不出門的宅男?
Cloud Shell + Gemini CLI，
讓雲端這一側變得更容易接近。
但本機開發環境，
讓創作與體驗維持在你最熟悉的位置，你可以快速調整 UI/UX。
Vibe Deploying 不是把所有事情塞進同一個工具，
而是讓每個工具待在它最適合的位置。
這樣，你既不會為了部署犧牲創作體驗，
也不會因為害怕部署，而永遠停在本機，
而是可以真的開始做一個能被使用、能被驗證、能被商業化的軟體。
以前我把部署想成一個交接儀式。
寫完之後交給工程師，等他們回我一句「好了可以開」，
我再去把產品包裝成故事，去賣夢、賣願景、賣下一輪成長。
但那天我真的把它丟上去，
拿到那個網址的瞬間，
我突然懂了一個很殘酷、也很自由的事。
部署不是技術門檻，
它其實是一個心理門檻，AI 時代最怕的就是自己限制住自己，你要時時告訴自己，今夜的我，沒有極限。
你一旦跨過去，
就不會再用「我只是做個 Prototype」這種理由保護自己了，說服自己你不行你不能，你自己就是一個超級個體。
因為你的東西已經可以被點開、被使用、被嫌棄、被付費、被放大。
更重要的是，它也可以被你自己很快地推翻、重做、再上一次。
當部署變得足夠便宜、足夠快、足夠可逆，
你自然就會開始用「小步快跑」的方式思考產品。
不是一次做很大，
而是每一次都往前一點點。
不是怕犯錯，
而是讓錯誤盡早發生、盡早被看見、盡早被修掉。
台灣人習慣等一切都完美才上線，
而是先上線，勇敢的人先享受世界，
讓真實世界成為你最誠實的回饋系統。
那一天，你會發現在這個世界上，你需要的只是一個勇敢的自己，不用怕被別人情勒，不怕交保護費給別人，或許這是一種追求自由的過程。
抑或是一個沒有朋友，沒有出門的宅男周末 XDD
各位 CEO 們，Happy Coding。