Google Antigravity 不是科幻片！『組建 AI 開發團隊』，用多代理人工作流重塑 WordPress 開發
☰ 目錄 table-of-contents.md
這篇文章要回答一個問題：如何把 Google「Project Antigravity」洩漏文件所揭示的「多模型並行」概念，落地成一套你今天就能用的多代理人（Multi-Agent）開發工作流。
結論先講：你不需要 Google 內部的系統，也能用現成的 AI Agent 框架（如 LangGraph、Autogen）把開發拆成「PM、開發者、QA、文件撰寫」四個專職代理人，由你扮演技術總監負責設定目標與審核產出。本文用一個 WordPress 短代碼（Shortcode）需求，從規格、實作、測試到文件，完整走一遍這套流程，並誠實談它目前的限制。
什麼是 Google Antigravity？跟多代理人有什麼關係？
先把概念講清楚。所謂「Google Antigravity」，並不是一個你可以下載安裝的軟體。根據洩漏的資訊，它是 Google 內部一個 AI 系統構想，核心精神在於「多模型並行（Multi-model Parallelism）」。
白話講就是：不要再把 AI 當成一把萬能瑞士刀，而要把它看成一個工具箱，裡面有各式各樣專精的工具。
這個概念延伸到開發流程，就誕生了「多代理人系統（Multi-Agent System）」。你不再是對著一個聊天視窗下一個籠統指令、然後期待它給你完美答案；取而代之的是，你建立一個由多個「AI 代理人」組成的團隊，每個代理人都有自己的角色與專長。
一個多代理人團隊裡有哪些角色？
- 專案經理 Agent：負責解析你的初步需求，拆解成具體的技術規格與執行步驟。
- 資深開發者 Agent：專注於根據規格撰寫高品質、有效率的核心程式碼。
- QA 測試工程師 Agent：為程式碼產生單元測試（Unit Test），確保穩定性與正確性。
- 技術文件撰寫員 Agent：產生清晰的註解與 README 文件，讓未來的自己或同事能快速上手。
你，身為人類開發者，扮演的是「技術總監」或「指揮官」：設定目標、分配任務、審核每個 Agent 的產出，並在關鍵時刻做出決策。
它跟單一聊天視窗有什麼根本差異？
差別在於「分工」與「交接」。單一視窗裡，一個模型要同時兼顧需求理解、寫程式、寫測試、寫文件，注意力被稀釋，容易顧此失彼。多代理人則把任務切成數個邊界清楚的子任務，每個 Agent 只專注一件事，上一棒的產出（規格、程式碼）成為下一棒的輸入。這讓每個步驟的輸入更聚焦、輸出更可審核，也讓你能在任何一棒「攔截」並修正，而不是等到最後才發現整體走偏。
實戰：組建一支 WordPress 短代碼 AI 開發團隊
理論講完，來點實際的。假設客戶有一個簡單需求：「我希望在文章中插入一個短代碼（Shortcode），可以自動顯示目前的年份。」
傳統作法是我們自己打開編輯器從頭刻到尾。今天我們改用多代理人工作流。雖然我們沒有 Google 的 Antigravity 系統，但可以用現在常見的 AI 框架（如 LangChain 的 LangGraph 或 Microsoft 的 Autogen）來模擬這個流程。為了方便理解，以下用文字描述與範例來呈現整個工作流。
第一步：對「專案經理 Agent」下達指令
身為指揮官，第一個任務是下達一個清晰的指令給 PM Agent。
你的指令（Prompt）：
請為一個 WordPress 專案規劃一個新的功能。需求如下：
1. 功能：建立一個名為 [current_year] 的短代碼。
2. 作用：當文章或頁面中出現這個短代碼時，它會被替換成目前的西元年份（例如：2024）。
3. 產出：請提供一個清晰的技術規格，包含建議的檔案名稱、函數名稱、以及核心的 WordPress Hook。PM Agent 的回覆（模擬產出）：
好的，收到需求。以下是技術規格：
- 專案類型：WordPress 輕量級外掛。
- 檔案名稱：
roamer-current-year-shortcode.php - 核心函數：
- 函數名稱：
roamer_tech_current_year_shortcode_handler - 功能：回傳當前的四位數年份。
- 函數名稱：
- WordPress Hook：使用
add_shortcode()函數來註冊current_year這個短代碼，並將其綁定到核心函數上。 - 執行流程：
- 建立外掛主檔案。
- 在外掛檔案中定義處理函數。
- 使用
add_action('init', ...)在init階段呼叫add_shortcode()進行註冊。
一個清晰的開發藍圖就出來了，我們不必再自己傷腦筋想這些命名與結構。
為什麼把註冊掛在 init 而不是直接寫在檔案頂層？
短代碼的註冊本身在外掛載入時就能完成，但把 add_shortcode() 包進掛載到 init 的函數裡，是一個比較穩健的習慣：此時 WordPress 核心已大致初始化完成，行為更可預期，也方便日後在同一個註冊函數內擴充更多短代碼，集中管理。這正是一份好規格該幫你想到的細節。
第二步：把規格交給「資深開發者 Agent」
現在拿著這份規格，交給 Coder Agent。
你的指令（Prompt）：
根據以下技術規格，請撰寫完整的 WordPress 外掛 PHP 程式碼。
[貼上 PM Agent 產出的技術規格]Coder Agent 的回覆（模擬產出）：
這段程式碼可以直接存成 roamer-current-year-shortcode.php，放到 wp-content/plugins/ 目錄下啟用即可。
<?php
/**
* Plugin Name: Roamer Tech Current Year Shortcode
* Plugin URI: https://roamer-tech.com/
* Description: Adds a [current_year] shortcode to display the current year.
* Version: 1.0.0
* Author: Eric from Roamer Tech
* Author URI: https://roamer-tech.com/
* License: GPL v2 or later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
* Text Domain: roamer-tech-cy
*/
if ( ! defined( 'ABSPATH' ) ) {
exit; // Exit if accessed directly.
}
/**
* Handles the [current_year] shortcode.
*
* Returns the current 4-digit year.
*
* @return string The current year.
*/
function roamer_tech_current_year_shortcode_handler() {
// 確保我們回傳的是字串，這是短代碼的最佳實踐
return date( 'Y' );
}
/**
* Registers the shortcode.
*/
function roamer_tech_register_shortcodes() {
add_shortcode( 'current_year', 'roamer_tech_current_year_shortcode_handler' );
}
// 在 WordPress 初始化時註冊我們的短代碼
add_action( 'init', 'roamer_tech_register_shortcodes' );
?>這段程式碼藏了哪些「資深」細節？
身為審核者，你應該看得懂它好在哪、又該注意什麼：
if ( ! defined( 'ABSPATH' ) ) exit;：防止外掛檔案被直接以網址存取，是 WordPress 外掛的基本安全慣例。- 短代碼回傳值（return）而非直接輸出（echo）：短代碼處理函數應該「回傳」字串，讓 WordPress 把它插回內容的正確位置；若直接
echo，輸出會跑到頁面最上方，這是新手最常見的坑。註解裡那句「確保回傳字串」正是在強調這點。
這也凸顯了一個重點：Agent 產出的程式碼仍需要你用專業眼光把關。它幫你省下打字與查文件的時間，但「這樣寫對不對」的最終責任在你身上。
第三步：呼叫「QA 測試工程師 Agent」進行驗證
程式碼寫好了，但身為資深工程師，我們都知道「在我電腦上可以跑」是多麼不靠譜的一句話。這時 QA Agent 就要上場，負責確保程式碼在各種情況下都能正常運作。
你的指令（Prompt）：
針對以下 PHP 函數 roamer_tech_current_year_shortcode_handler，
請使用 PHPUnit 框架撰寫一個基本的單元測試，驗證它是否正確回傳當前年份。
[貼上 Coder Agent 產出的 PHP 函數程式碼]QA Agent 的回覆（模擬產出）：
好的，這是一個基本的 PHPUnit 測試案例：
<?php
use PHPUnit\Framework\TestCase;
// 假設外掛主檔案已經被引入
require_once 'path/to/roamer-current-year-shortcode.php';
class CurrentYearShortcodeTest extends TestCase {
public function test_shortcode_handler_returns_correct_year() {
// 獲取預期的年份
$expected_year = date('Y');
// 執行函數
$actual_year = roamer_tech_current_year_shortcode_handler();
// 斷言函數的回傳值是否與預期相符
$this->assertEquals(
$expected_year,
$actual_year,
'The shortcode handler should return the current 4-digit year.'
);
}
}
?>有了這個測試案例，就可以把它納入 CI/CD 流程，確保未來任何修改都不會意外搞壞這個功能。
提醒：這個範例測試直接比對
date('Y')，因為被測函數本身也用同一個函數取年份，本質上是驗證「行為一致、不拋錯」。要做更嚴謹的測試，通常會把時間來源抽離（注入一個固定時間），讓斷言不依賴執行當下的系統時間——這也是你在審核 QA Agent 產出時，可以追問它「能不能讓測試更穩定」的好問題。
第四步：讓「技術文件撰寫員 Agent」完成最後一哩路
程式碼與測試都完成了，最後一步是撰寫文件。這通常是工程師最不愛的環節，但交給 AI Agent 就輕鬆許多。
你的指令（Prompt）：
根據已完成的外掛程式碼，請撰寫一份簡潔的 README.md 文件，
說明這個外掛的功能、如何安裝及如何使用。Documenter Agent 的回覆（模擬產出）：
# Roamer Tech Current Year Shortcode
**Contributors:** roamer-tech
**Tags:** shortcode, year, date
**Requires at least:** 5.0
**Tested up to:** 6.5
**Stable tag:** 1.0.0
**License:** GPLv2 or later
**License URI:** https://www.gnu.org/licenses/gpl-2.0.html
A simple plugin that provides a shortcode `[current_year]` to display the current year on your WordPress site.
## Description
This plugin is perfect for footers, copyright notices, or anywhere you need to dynamically display the current year without manually updating it every January.
## Installation
1. Upload the `roamer-current-year-shortcode` folder to the `/wp-content/plugins/` directory.
2. Activate the plugin through the 'Plugins' menu in WordPress.
## Usage
Simply place the `[current_year]` shortcode in any post, page, or widget where you want the current year to appear. It will be automatically replaced with the 4-digit current year (e.g., 2024).至此，一個規格完整、程式碼健壯、有測試覆蓋、文件清晰的 WordPress 小外掛，就在我們「指揮」之下完成了。整個過程，我們專注在最高層次的決策與審核，而不是陷在繁瑣細節裡。
這套工作流的真實挑戰是什麼？
看起來很美好，對吧？但身為務實的工程師，還是得囉嗦幾句。多代理人工作流目前並不完美，會面臨幾個現實挑戰：
- 狀態與上下文管理：如何讓多個 Agent 共享同一個專案的上下文（Context）與狀態，是目前最大的技術難點。前一棒的決策、命名、檔案結構，必須被後續 Agent 精準接收，否則就會出現「QA 測的函數名稱跟 Coder 寫的對不上」這類錯位。
- 溝通成本：Agent 之間的任務交接需要精密設計，否則會像一個效率低落的團隊一樣，不斷來回溝通、空轉。
- 成本考量：每個 Agent 的運作都在消耗 API Token，對於複雜專案，這可能是一筆不小的開銷。
- 可控性與幻覺：AI 仍然會有「幻覺」（Hallucination），產出不符預期的程式碼。最終的審核與把關，還是得靠人類開發者的專業經驗。
那我該怎麼開始，又該如何控制風險？
務實的起手式，是從一個邊界清楚、容易驗證的小需求開始（就像本文的短代碼），先把「四個角色、四個提示、四份產出」的節奏跑順，再逐步擴大到較複雜的功能。三個降低風險的原則：
- 每一棒都人工審核：把 Agent 當成資淺隊員的草稿，而不是最終答案。
- 把規格與測試當成護欄：清楚的規格約束開發者 Agent，自動化測試攔截行為退化，兩者一起壓低幻覺造成的損害。
- 從小範圍試成本：先在低風險任務上估算 Token 消耗與品質，再決定要不要放大規模。
儘管挑戰不少，我仍相信這代表了軟體開發的方向。我們的角色正在從「實作者」轉變為「架構師」與「系統設計者」：要學的不再只是新語言或新框架，更是如何設計、管理與優化這些 AI 工作流，讓 AI 團隊發揮最大潛力。與其擔心被 AI 取代，不如開始學習如何駕馭它——從今天起，試著為你的下一個專案，組建一支專屬於你的 AI 開發團隊。
延伸閱讀
常見問題
Google Antigravity 是什麼？
多代理人（Multi-Agent）開發工作流有哪些角色？
多代理人工作流和單一聊天視窗有什麼根本差異？
WordPress 短代碼處理函數為什麼要 return 而不是 echo？
用 AI Agent 產生的程式碼可以直接上線嗎？
訂閱免費電子報
把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。