Google Antigravity + Gemini 3 實戰：從 Scaffolding 到部署，一人開發團隊的一條龍工作流
☰ 目錄 table-of-contents.md
Google Antigravity + Gemini 3 實戰：從 Scaffolding 到部署，一人開發團隊的一條龍工作流
嗨，我是 Eric，浪花科技的資深工程師。這篇文章要回答一個問題：當你身兼前後端、DevOps、又是專案唯一的人手時，如何用 Google Antigravity 搭配 Gemini 3，把「建專案、寫邏輯、串前端、做部署」這條冗長流程濃縮成一條龍？
直接給結論：關鍵不在於「叫 AI 寫程式」，而在於善用 Antigravity 的上下文感知（Context Awareness）與代理人工作流（Agentic Workflow），讓 AI 讀懂你「整個專案」而非單一檔案，再靠 Gemini 3 的長上下文與推理能力補完細節。你負責決策與審閱，AI 負責那 90% 重複性的髒活。以下我會走一遍實戰流程，並在每一步點出「為什麼這樣做、人該守住哪條線」。
Antigravity 跟一般 AI 補全工具差在哪？
很多工程師誤以為 Antigravity 只是一個 IDE 外掛，這是最大的誤解。它的核心是兩件事：
- 上下文感知（Context Awareness）：它直接讀取你的整個 Project Workspace，知道你的資料庫結構、API 路由設計，而不是只看你貼上去的那一段。
- 代理人工作流（Agentic Workflow）：它不只回你一段程式碼，而是能規劃、跨檔案產生、並串起多個步驟。
以前用對話式 AI 寫程式，最大的痛苦是反覆複製貼上：「我的 User.php 長這樣，現在幫我寫 UserController.php。」每換一個檔案就要重新餵一次上下文。Antigravity 把這層摩擦拿掉了——而搭配 Gemini 3 這個 Google 最新的多模態模型，它的強項在於「極長窗口的記憶力」與「邏輯除錯能力」，能記住你稍早隨口提的需求，並在後續階段幫你補上遺漏的設定。
一句話總結差異：補全工具補的是「下一行」，Antigravity + Gemini 3 補的是「下一個任務」。
第一階段：Scaffolding——讓 AI 幫你蓋地基
假設我們要開發一個「SaaS 訂閱制發票管理系統」。若是以前，建立 Laravel 專案、設定 Vue/React 前端、調整 docker-compose.yml，光是這些就得花掉半天。
在 Antigravity 介面中，我們只需要下一道指令。這裡有個關鍵原則：指令必須同時定義「專案架構」與「技術棧」。模糊的指令會得到模糊的結果，把邊界講清楚，AI 才不會自由發揮。
Eric 的黃金 Prompt 範例
Project: InvoiceSaaS
Stack: Laravel 11 (Backend), Vue 3 + Tailwind (Frontend), MySQL 8, Redis.
Goal: Create a full scaffolding for a subscription-based invoice system.
Requirements:
1. Setup standard Laravel directory structure.
2. Include a docker-compose.yml with Nginx, PHP-FPM, MySQL, Redis, and Mailpit.
3. Create a basic domain modeling for 'Tenant', 'Invoice', 'Subscription'.
4. Use PHP 8.3 features.
Execute scaffold generation using Gemini 3 logic.按下 Enter 後，Antigravity 會開始產生檔案。它不是瞎編：會依 Gemini 3 的知識確保 composer.json 的依賴合理、Docker 各容器之間的網路設定互通。產出的也不只是空殼，連 Model 之間的關聯（Relations）都幫你寫好，例如 Tenant hasMany Invoices 這種無聊但必要的程式碼。
這一步該怎麼讀懂它的產出？
Scaffolding 省下的是打字時間，不是「思考時間」。我的習慣是把產出當成「資深同事的初稿」來審：
- 看關聯方向對不對：
hasMany/belongsTo的兩端有沒有寫反，外鍵欄位命名是否符合 Laravel 慣例。 - 看容器邊界：MySQL、Redis 是否只在內部網路曝露、有沒有把不該對外的 port 開出去。
- 看領域模型粒度：
Tenant、Invoice、Subscription的職責是否清楚，避免一開始就把邏輯全塞進 Model。
第二階段：邏輯實作——Gemini 3 的推理能力
地基蓋好，接下來是核心邏輯。我們要實作「根據訂閱等級限制發票開立數量」的功能。
在較早的模型上，你可能得一步步引導它寫 Middleware。但在 Gemini 3 搭配 Antigravity 的環境下，你只需要說：
「在
InvoiceController的 store 方法加入檢查，如果 Tenant 的SubscriptionPlan限制已達，拋出 403 錯誤。請參考config/subscription.php中的限制設定。」
Antigravity 會自動去「看」你的 Config 檔案（即使你沒貼給它），然後 Gemini 3 會生成包含 Service Layer 呼叫的完整程式碼。
自動生成的程式碼範例
// App\Services\InvoiceService.php
public function canCreateInvoice(Tenant $tenant): bool
{
$plan = $tenant->subscription->plan;
$currentCount = $tenant->invoices()->thisMonth()->count();
// Eric 註：Gemini 3 甚至自動加上了 'thisMonth' 的 Scope，這就是推理能力
if ($currentCount >= config("subscription.plans.{$plan}.limit")) {
return false;
}
return true;
}注意那個 thisMonth()。我原本的 Prompt 沒說要限制「本月」，但 Gemini 3 從「訂閱制」的語意推理出限制通常按月計算，自動補上了 Query Scope。這就是為什麼我說它是「資深開發副駕」，而不是實習生。
但這段程式碼，人一定要看的兩件事
推理能力強，不代表可以盲信。上面這段我會特別檢查兩點：
- 把邏輯放對位置：判斷「能不能開發票」屬於商業規則，放在 Service 層是正確的；Controller 只負責呼叫並把結果轉成 HTTP 回應（這裡是 403）。AI 自動選擇了 Service Layer，這個方向值得肯定——但你仍要確認 Controller 沒有又把同一段邏輯抄一份。
- 確認「本月」的定義與時區：
thisMonth()是 AI 的推理，不是你的規格。它到底是依伺服器時區、UTC、還是租戶所在時區計算？跨月臨界點會直接影響計費正確性，這種地方必須由人拍板，不能讓 AI 替你決定商業定義。
第三階段：前端整合與 Vibe Coding
後端搞定，前端 Vue 的整合通常最煩人：API 格式對不起來、CORS 問題等等。
在 Antigravity 裡可以開啟「Split View」，左邊是 Laravel Controller，右邊是 Vue Component。選取後端的回傳結構，直接拖曳（或下指令）到前端檔案，對 Gemini 3 說：
「Generate a Tailwind table component to display these invoices, handle pagination meta provided by Laravel Resource.」
它會讀取 Laravel API Resource 的 JSON 結構，把 Vue 的 Props 和 v-for 迴圈寫好，連 Tailwind 的 class 都配得有模有樣。我們只負責「審美」：覺得間距太窄，說一句「Make it more spacious」它馬上改。這就是 Vibe Coding——你描述意圖，AI 收斂成具體實作。
不過前後端串接這一段，有一個容易被 Vibe 掉的細節值得提醒：API 回傳契約（contract）要先定下來。Laravel API Resource 的欄位命名、分頁 meta 的結構，一旦前後端各自被 AI 生成、卻沒有共同的真實來源，日後改一邊就會悄悄拆掉另一邊。我的做法是讓 Resource 結構成為單一事實來源，前端永遠以它為準。
第四階段：自動化部署——最後一哩路
寫完程式碼是一回事，讓它在 Server 上跑起來是另一回事。部署通常是全端工程師的惡夢：Nginx 設定寫錯、權限不對、Debug 模式忘了關。
我們用 Antigravity 生成部署腳本，這裡我推薦結合 GitHub Actions 與 Docker。指令如下：
「Based on the current docker-compose setup, generate a production-ready Dockerfile and a GitHub Actions workflow to deploy to a VPS via SSH. Ensure assets are compiled with Vite.」
Gemini 3 會考量 Production 環境的安全性（例如不以 root 執行容器、關閉 Debug mode），產出一份高品質的 Dockerfile。這替我省下大約 2 小時查資料的時間。
部署產物的人工檢查清單
部署是「錯了會出大事」的環節，AI 產出後我一定逐項對照這份清單：
- 機密不要進映像檔：資料庫密碼、API 金鑰應走環境變數或 Secret，不該被
COPY進 Image，也不該寫死在 workflow 裡。GitHub Actions 的敏感值要放 Repository Secrets。 - Debug 模式確實關閉：Laravel 正式環境的
APP_DEBUG必須是false，避免例外頁面把堆疊與環境資訊洩漏出去。 - 最小權限執行：容器以非 root 使用者執行，SSH 部署金鑰只給必要的權限範圍。
- 建置產物與快取：Vite 編譯確實在部署流程中跑過，並視情況執行設定快取（如 config/route 快取）讓正式環境更快。
結語：從 Worker 到 Director
使用 Antigravity + Gemini 3 這套流程，讓我從「寫程式的工人（Worker）」轉變為「軟體導演（Director）」。我不再糾結括號有沒有閉合，而是專注於「這個架構合不合理？」「使用者流程順不順暢？」
但要說清楚一條底線：AI 產出的程式碼仍然需要人工審閱（Code Review），尤其是資安與權限相關的邏輯。AI 幫我們解決了 90% 的重複性勞動，剩下那關鍵的 10%——架構決策、商業規則定義、安全把關——才是工程師真正的價值所在。如果你還在手刻 CRUD，是時候升級你的軍火庫了。
需要協助導入這套工作流？
覺得這套 AI 工作流太複雜，想導入企業內部卻不知從何下手？或者你的專案卡在技術瓶頸？歡迎聯繫浪花科技，讓我們幫你打造專屬的自動化開發解決方案。
延伸閱讀
常見問題
Google Antigravity 和一般 AI 補全工具差在哪？
用 AI 做 Scaffolding 後，工程師應該重點檢查什麼？
AI 自動補上的程式邏輯可以盲目信任嗎？
用 AI 做前後端整合時，最容易被忽略的細節是什麼？
訂閱免費電子報
把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。