驗證中…

GTW AI Hub

這個站只給 Gamania 內部使用。
請用你的公司 Google 帳號登入。

這個帳號沒有權限

只有 @gamania.com 的帳號可以進入。
你剛才用的是 。

請用瀏覽器開啟

你現在是從別的 App 內建的瀏覽器打開這一頁（Telegram、LINE、Facebook 這類）。
那種瀏覽器會擋住登入，轉一圈回來就失敗。

做法：按這個頁面的「⋯」或分享鈕，選「在 Safari 開啟」或「用瀏覽器開啟」。

登入失敗

錯誤代碼：
把這個代碼給平台處，不要自己重試很多次。

AI 種子交流平臺

Deployment // for vibe coders

工具做好了,
但同事點不開你的網址

用 AI 做出來的小工具跑在自己電腦上很正常,傳給別人就一片空白。這頁講三件事:部署到底在搬什麼、怎麼判斷自己需要哪種平台,以及在公司實際上要走哪一條路。

為什麼 localhost 傳給別人一定打不開

這是第一個大家都會踩的坑,而且錯的不是程式,是那串網址本身。

你看到的

http://localhost:3000 — localhost 就是「我現在坐著的這台電腦」。瀏覽器根本沒有連上網,它只是問自己的電腦:3000 號窗口有東西在跑嗎?有,就是 AI 剛幫你在終端機裡跑起來的那支程式。終端機一關,它就不見了。

同事看到的

同一串網址,他的瀏覽器也照做同一件事:問他自己的手機或電腦有沒有東西在 3000 號窗口。他手機裡沒有你的程式,所以只會跳「無法連線」。

把整個資料夾寄給對方也不算解法:那要對方自己裝環境、裝套件、還要跟你要 API 金鑰。要的是「點一下連結就能用,什麼都不用裝」。

部署就是把家裡的廚房搬到街上開店

在自己電腦上寫程式像在家煮私房菜——很好吃,但只有你吃得到。開店要搞定三件事,加起來就叫部署。

STEP 01

租一間不打烊的店面

你的筆電會闔上、會帶出門,但客人可能半夜或從國外連進來。所以要一台永遠醒著的雲端電腦。

＝ 雲端伺服器

STEP 02

把廚具、醬料、食材搬進去

程式碼、執行環境、API 金鑰全部搬到那台機器上,而且要確認在店裡煮得出跟家裡一樣的味道。

＝ 部署與環境設定

STEP 03

門口掛一個好記的招牌

給那台機器綁一個固定的公開網址,別人才找得到門在哪。

＝ 網域

選平台之前,先回答三個問題

直接去比較各家平台的規格只會越看越亂。平台只是工具,先搞清楚自己的專案是什麼形狀。

  1. 需不需要後端幫你算東西?

    前端是外場(看得到的畫面),後端是內場(記帳、驗密碼、拿金鑰去呼叫 AI)。作品集、活動頁、瀏覽器裡的小遊戲通常不用開內場,那叫純靜態網站。

    自問:要不要登入?要不要存資料?有沒有金鑰不能給人看到?三個都沒有 → 純靜態。

  2. 是全端還是前後端分離?

    全端是外場內場寫在同一個專案裡(例:Next.js);分離是兩個獨立專案,前端呼叫後端的 API 拿資料。

    自問:平常要開幾個終端機才跑得起來?一個 → 全端;要開兩個 → 前後端分離。

  3. 那台機器需要 24 小時醒著嗎?

    常駐伺服器適合長時間任務(影片轉檔、定時爬蟲、多人聊天室),沒人用也在計費。Serverless 平常不開機,有人按按鈕才啟動幾秒,按次數計費。

    自問:功能都是「按一下、幾秒內算完」嗎?是 → Serverless 就夠,而且通常有很大的免費額度。

市面上的平台地圖(以及公司能不能用)

先認識分類,因為看懂分類才知道別人在討論什麼。但最後一欄才是我們的重點。

公司限制那一欄是我方規定,不是平台本身的限制。
類型常見平台適合什麼公司能不能用
靜態託管 + CDN Cloudflare Pages、GitHub Pages、Netlify 純前端頁面。CDN 把檔案複製到全球機房,誰連都快 只能放完全公開的內容;有公司資料一律不行
Serverless 全端託管 Vercel(Next.js 首選)、Netlify 全端框架、短運算(登入、記一筆、呼叫一次 AI) 不行——機敏資料會離開公司可控範圍
常駐伺服器 / 容器 Railway、Render、Zeabur 要一直開著的任務:爬蟲、即時聊天、獨立後端 不行(同上)
雲端巨頭 AWS、Google Cloud、Azure 什麼都能做,但要自己組裝維護 公司有正式流程,但個人小工具用它是殺雞用牛刀
公司內部路線 Google Apps Script、Firebase 表單自動化、內部工具、儀表板、要登入的頁面 這就是我們要走的兩條路,見下一節
為什麼公司不走 Vercel 那條路

那些平台本身沒問題,問題是資料落在哪裡。我們的工具幾乎都會碰到玩家資料、營運數字或內部流程,一放上去就離開了公司可控範圍。所以規則很簡單:要給同事用的東西,部署到公司可控的 Google 生態;想練手的純公開小遊戲才考慮外部平台。

公司的兩條路:輕量走 GAS,要框架走 Firebase

兩條都用同一套習慣:程式碼放 GitLab,推上 main 由 CI 自動部署,不用手動點後台。範本在 GitLab 的 ai-seeds/sharing 群組,fork 一份就能開始。

Tier 1 — Google Apps Script

表單自動化、Sheets 加工、定時抓資料、小工具。$0,不用開專案。

GitLab 上的 gas-template repo 畫面 
# 1. 裝 clasp(一次)
npm install -g @google/clasp && clasp login

# 2. fork ai-seeds/sharing 的 gas-template
# 3. 把 Script ID 填進 .clasp.json
# 4. 寫 code → git push → CI 自動部署
  • Code.gs 是主程式,範本裡已有 Gemini API 與 Sheets 的例子
  • .gitlab-ci.yml:merge 到 main 就自動 clasp push 並部署
  • 網址是 script.google.com/macros/...,可設成只有公司帳號打得開

Tier 2 — Firebase

要前端框架、要登入、要資料庫的頁面(這個學習平台本身就是這樣蓋的)。

Firebase Hosting 的專案畫面 
# 1. 裝 Firebase CLI(一次)
npm install -g firebase-tools && firebase login

# 2. fork ai-seeds/sharing 的 firebase-template
# 3. 開自己的 Firebase 專案(Spark 免費方案),ID 填進 .firebaserc
# 4. 寫 code → git push → CI 自動部署
  • 每個人用自己的 Firebase 專案,不要共用——Hosting 權限是專案層級,共用等於彼此的 CI 都能覆蓋對方的站台
  • Spark 免費方案不用綁信用卡,網址是 <你的專案ID>.web.app
  • Spark 沒有伺服器端(Cloud Functions 要升級付費方案),所以金鑰不能寫進前端,權限要靠 Firestore 規則擋

兩條路都要設一次的:CI 變數

到 GitLab 的 project → Settings → CI/CD → Variables 設定,設一次之後每次 git push 就自動部署。

截圖為實際操作畫面。完整指南(含從 Vercel 搬家、Cloud Functions 改寫)在 GitLab ai-seeds/sharing/docs 的 deployment-guide.md。
走哪條要設的變數用途
GASCLASPRC_JSON(型別選 File)、DEPLOYMENT_ID讓 CI 有權限推上你的 Apps Script 專案並部署到固定版本
FirebaseFIREBASE_TOKEN、FIREBASE_PROJECT讓 CI 有權限部署到你自己的 Firebase 專案
GitLab CI/CD Variables 設定畫面

上線之後,要看哪四個地方

「部署成功」不等於「網站打得開」。這四件事每個平台都有,只是名字不一樣——最常出事的是第二個。

要確認什麼GAS 看哪裡Firebase 看哪裡
部署狀態
這次推上去到底成功了沒		 GitLab 的 pipeline 綠燈,再看 Apps Script 的部署版本號 GitLab 的 pipeline 綠燈,再看 Hosting 的發布紀錄
金鑰與設定值
本機 .env 裡的東西雲端拿不到,程式就當機		 Apps Script 的 指令碼屬性(Script Properties),程式用 PropertiesService 讀 Spark 沒有後端,金鑰不要進前端;要用金鑰就得改走 GAS 或申請正式後端
網址
要好記、要能限定誰打得開		 script.google.com/macros/...,存取權可設「僅公司網域」 <專案ID>.web.app,可綁自訂網域;要限公司登入得自己加閘門
日誌
同事說「壞了」的時候看這裡,不要猜		 Apps Script 編輯器的執行項目(Executions),含錯誤堆疊 Firebase 的 Hosting 請求記錄 / 瀏覽器 Console;有後端才有 Functions 日誌

出錯的時候不用自己瞎猜:把日誌裡那段紅字複製給 AI,或讓 AI 直接透過 MCP 去讀日誌,它會照證據找原因。這也是為什麼「看得懂後台在講什麼」比「會不會操作」重要。

可以交給 AI 的,和不能交給 AI 的

流程上真正需要你親自做的其實只有幾件事,其餘都能派給 AI。

交給 AI
裝好對應平台的 MCP(例:Firebase MCP),讓 agent 直接幫你上傳、部署、讀日誌、修錯。指令與設定檔它比你熟。
交給 AI:判斷專案形狀
不確定自己是純靜態還是有後端、是全端還是分離,直接問它:「我這個專案有沒有後端運算?要開幾個終端機才跑得起來?」
你自己決定
資料落在哪裡(公司 Google 生態 vs 外部平台)、誰能打開這個網址、要不要收集使用者資料。這些是責任問題,不是技術問題。
你自己動手
註冊帳號、開自己的 Firebase 專案、在 GitLab 設 CI 變數(金鑰不要貼進對話裡)。

上線才是資安風險的開始

公開的網址等於全世界都能敲門

能點開連結就能用,對同事是方便,對外人也是。三件事最少要做到:內部工具一律加登入限制(GAS 設僅公司網域;Firebase 要自己加閘門與 Firestore 規則)、金鑰不要放前端(前端的東西使用者都看得到)、不要把公司資料放進外部平台。

這頁只把流程講到「能安心分享給同事」;正式對外的產品等級資安是另一個專業領域,平台上另有資安主題的資源可以接著看。

觀念框架(localhost 為什麼打不開、部署的三件事、選平台的三個判斷、上線後看四個地方)蒸餾自公開的中文教學影片 〈用 AI 寫程式之後,怎麼把作品部署上線〉;平台地圖的「公司能不能用」、GAS / Firebase 兩條路的實作步驟、CI 變數與後台對照表是我方依公司規範與 ai-seeds/sharing 的範本整理,原影片沒有這部分。 截圖為實際操作畫面。