寫 Code 還是管 AI？Vibe Coding 與 Google Antigravity 實戰：用「AI 代理人」重塑你的開發流

把語法外包給 AI、把決策權留給自己——這才是 Vibe Coding 的正確打開方式，而不是憑感覺亂寫然後祈禱能跑。配上 Google 的 Project Antigravity（反重力計畫），開發者的工作重心正從「逐行撰寫程式碼（Syntax）」轉向「定義意圖、審查邏輯、做產品決策（Semantics）」：標準化、重複性的 Code 交給 AI 代理人（Agent）產出，你當那個把關全局的人。

本文用一個真實會發生的需求情境——「WooCommerce 滿額且含特定顏色商品才打折，並排除特價品」——帶你走完一遍「定義意圖 → AI 產出 → 人工決策修正」的完整工作流，並說清楚在這個模式下，資深工程師的價值到底在哪裡。

嗨大家，我是 Eric，浪花科技的資深工程師。如果你的瀏覽器分頁還停留在 Stack Overflow，或者還在為了一個漏掉的分號 Debug 半小時，這篇文章可能會稍微顛覆你對「寫程式」的認知。我們這群碼農正在從「手工業者」轉型為「工廠廠長」——而這篇文章不聊虛的哲學，直接來點硬核的實作。

什麼是 Vibe Coding？為什麼它不只是「憑感覺」？

當 Andrej Karpathy 說出「I just vibe code」的時候，很多資深工程師（包括一開始的我）都翻了個白眼：「這不就是隨便寫寫，然後祈禱它能跑嗎？」

但深入實踐後，我發現 Vibe Coding 其實是一種「高階抽象化」的開發模式。它的核心邏輯是：

• 放棄對語法（Syntax）的執著：你不需要記得 PHP 的 array_map 參數順序是先 callback 還是先 array，那是 AI 的事。
• 專注於意圖（Intent）：你只需要清楚描述「我要什麼功能」、「資料流怎麼跑」、「安全性限制是什麼」。
• 人機協作的「氛圍」（Vibe）：你與 AI 之間形成一種持續的對話流，你拋出想法、它拋回程式碼，你負責審視邏輯漏洞（Review），而不是除錯語法（Debug）。

在 WordPress 開發中，這意味著我們不再手刻 add_action 或 WP_Query 的標準格式，而是專注於「這個 Hook 到底該不該掛在這裡？」以及「這會不會影響到資料庫效能？」

Vibe Coding 與「直接複製貼上 ChatGPT」差在哪？

關鍵差別在於「閉環」。複製貼上是一次性的、開環的：丟問題、拿答案、結束。Vibe Coding 是持續對話的閉環：你拋出意圖、AI 產出、你以「審查者」身分回饋邏輯層級的修正，再讓 AI 迭代。換句話說，你始終握著方向盤，AI 只是替你踩油門。當你失去了審查能力，Vibe Coding 就會退化成「祈禱式開發」——這也是它最大的風險所在。

Google Antigravity 與 Agentic Workflow：從「助手」到「代理人」

如果說 GitHub Copilot 是你的「副駕駛」（助手），會幫你補全下一行程式碼；那麼 Project Antigravity 代表的就是一種「多代理人系統」（Multi-Agent System）。在這種架構下，AI 不再只是被動等待你的游標移動，而是擁有更強的主動性與全局觀。

想像一下，在這類進化版的 IDE（或者像 Cursor 這種現有工具）中，你不只是一個工程師，你指揮著一個團隊：

• 架構師 Agent：負責規劃檔案結構，決定 Service Layer 和 Repository Pattern 怎麼切。
• 實作 Agent：負責生成具體的 PHP / JS 程式碼。
• 測試 Agent：自動根據實作程式碼撰寫 PHPUnit 測試案例。
• 除錯 Agent：當報錯時，自動分析 Log 並提出修復方案。

這就是 Antigravity 的願景：消除寫程式的「重力」（阻力），讓你飄在空中俯瞰整個專案。多代理人的精髓不在於「AI 變聰明了」，而在於任務拆解與角色分工——每個 Agent 只專注一件事、輸出可被下一個 Agent 接手的中間產物，整體可靠度因此遠高於「一個萬能 AI 一次寫完所有東西」。

Agent 模式與 Autocomplete 模式的本質差異

實戰演練：用 Agent 接手重複工，開發一個 WooCommerce 動態折扣模組

光說不練假把式。讓我們模擬一個場景：老闆（或客戶）突然說：「Eric，我們要一個功能，當使用者購物車滿 3000 元，且包含『紅色』商品時，自動打 9 折，但排除特價品。」

如果是以前，我會打開 functions.php 或建立一個新外掛，開始查 WooCommerce 的 Hook 文件。但在 Vibe Coding + Agent 的模式下，我的工作流是這樣的：

Step 1：定義意圖（The Vibe）

我不會寫一行程式碼，我會打開對話視窗（Prompt），輸入我的「產品決策」：

Prompt：我需要一個 WooCommerce 片段。邏輯是：檢查購物車總額是否大於 3000。如果是，遍歷購物車項目，檢查是否有產品屬性 'color' 為 'red'。如果有，給予總金額 10% 的折扣。注意：如果商品本身已經有特價（Sale Price），則該商品不計入折扣計算，也不觸發門檻判斷。請用 woocommerce_cart_calculate_fees hook 實作，並確保防呆（例如 cart object 是否存在）。

這段 Prompt 之所以「能用」，是因為它具備了好規格的三個要素：明確的條件（滿 3000 且含紅色）、明確的例外（排除特價品）、明確的技術約束（指定 hook 與防呆）。寫不出這樣的規格，就不是 AI 的問題，而是你還沒想清楚需求。

Step 2：AI Agent 執行（The Antigravity）

這時候，AI 代理人會接手。它不需要我告訴它 WC()->cart->get_cart() 怎麼用。它會直接生成如下的程式碼（這是模擬 AI 產出的結果）：

add_action( 'woocommerce_cart_calculate_fees', 'roamer_dynamic_red_discount', 10, 1 );

function roamer_dynamic_red_discount( $cart ) {
    if ( is_admin() && ! defined( 'DOING_AJAX' ) ) {
        return;
    }

    // 設定門檻與折扣
    $threshold = 3000;
    $discount_percent = 0.1;
    $target_color = 'red';

    $eligible_total = 0;
    $has_red_item = false;

    // 遍歷購物車
    foreach ( $cart->get_cart() as $cart_item ) {
        $product = $cart_item['data'];

        // 產品決策邏輯：排除特價品
        if ( $product->is_on_sale() ) {
            continue;
        }

        // 累加符合資格的金額
        $line_total = $cart_item['line_total'];
        $eligible_total += $line_total;

        // 檢查顏色屬性
        $color = $product->get_attribute( 'pa_color' );
        if ( strcasecmp( $color, $target_color ) === 0 ) {
            $has_red_item = true;
        }
    }

    // 最終判定
    if ( $has_red_item && $eligible_total >= $threshold ) {
        $discount = $eligible_total * $discount_percent;
        $cart->add_fee( '紅色商品滿額優惠', -$discount );
    }
}

Step 3：人類介入與決策（Product Decision）

這就是 Vibe Coding 的關鍵時刻。我不會去檢查分號有沒有漏，我看的是邏輯。

我發現一個潛在問題：「等一下，Prompt 裡說的是『總額大於 3000』，但 AI 的寫法是『符合資格的商品總額（排除特價品後）大於 3000』。」

這是一個產品邏輯的差異。是「全車滿 3000」還是「正價品滿 3000」？這就是工程師該介入的地方。如果我只是盲目複製貼上，這裡就會變成一個隱藏的 Bug。但我因為從語法工作中解放出來，我有更多腦力去思考這個商業邏輯。

於是，我對 Agent 說：「修正邏輯：門檻判斷應該基於『購物車小計（Subtotal）』，而不是『符合資格總額』。但折扣計算依然只針對正價品。」

AI 會瞬間修正程式碼。這就是反重力開發。

還有哪些「只有人看得出來」的決策點？

同一段程式碼，值得人類停下來追問的，遠不只門檻定義。這些都不是語法問題，而是商業與情境判斷：

• 折扣與其他優惠是否疊加？如果已套用優惠券，這筆折扣是加總還是擇優？規格沒講，AI 只能猜。
• 顏色屬性的判斷邊界：程式碼用 get_attribute( 'pa_color' ) 比對，但變體商品（Variation）的顏色取法可能不同，這需要你確認商品資料結構後再下判斷。
• 折扣金額顯示給誰看？add_fee 加的是負費用，會出現在結帳頁；文案、稅務計算方式是否符合你的需求，是業務問題不是技術問題。

看出重點了嗎？AI 把「怎麼寫」處理得很好，但「該怎麼算才對」永遠是你的責任。

工程師的新戰場：從 Syntax 到 Semantics

很多人擔心 AI 會取代工程師，但在我看來，AI 是把我們從「低階勞動」中解放出來。在 Antigravity 和 Vibe Coding 的時代，資深工程師的價值將體現在以下幾點：

1. 精準的規格定義能力：你能不能把模糊的需求（Vibe）轉化為 AI 聽得懂的精確指令（Prompt）？這正是上面那段 Prompt 為什麼要寫清楚條件、例外與約束的原因。
2. 架構與資安審查：AI 寫出的程式碼可能會有 N+1 的查詢問題，或者在處理表單與 AJAX 請求時忽略了 Nonce 驗證與權限檢查。你必須是那個把關的守門員。
3. 系統整合思維：WordPress 不再是孤島，你需要串接 CRM、ERP、Line Bot。AI 擅長寫單一函式，但「如何把這些系統串成一張藍圖」還是在你腦中。

審查 AI 程式碼時，我會特別盯著哪幾項？

把 AI 當成一位「速度極快但缺乏脈絡」的初階工程師，你的 Code Review 清單其實和帶新人差不多：

• 安全性：有沒有對外部輸入做消毒（sanitize）與逸出（escape）？涉及寫入操作的請求有沒有 Nonce 與權限驗證？
• 效能：有沒有在迴圈裡反覆打資料庫（N+1）？有沒有把可快取的結果重複計算？
• 邊界條件：購物車是空的、cart object 不存在、屬性抓不到值時，會不會出錯？（這也是 Prompt 裡特別交代「防呆」的原因。）
• 商業邏輯：程式碼跑得起來，不代表它算的是「對的東西」——這一條永遠優先級最高。

結論：不要抵抗重力，要學會反重力

未來的開發場景，就是你坐在指揮塔，看著多個 AI Agent 在螢幕上飛快地生成程式碼、跑測試、寫文件。你需要做的，是保持敏銳的「Vibe」，確保這些高速運轉的機器是往正確的方向前進。

不要害怕放手讓 AI 去寫程式，你該害怕的是：當 AI 把程式碼寫好了，你卻不知道這段程式碼背後的產品價值是什麼。Vibe Coding 真正考驗的從來不是打字速度，而是你的判斷力。

如果你的企業也想導入這種高效的自動化開發流程，或者想把 WordPress 打造成真正的智慧商業大腦，這就是值得投入的方向。

延伸閱讀

• Antigravity、Claude Code、Codex 三大 AI Coding Agent 完整比較
• AI 寫 Code 只是基本功？深度解析：AI Coding Agent 的真正價值是當你的『技術決策軍師』
• Cursor AI 其實不是 Copilot 的對手？錯！深度解析：它想當的是你的『大腦外掛』
• AI 官網不是夢！WordPress 智慧化實戰：從內容個人化到營運自動化，打造你的『AI 驅動引擎』