AI 寫 Code 不只是自動補全！Antigravity『任務導向』開發實戰：讓 AI 幫你規劃、實作、驗證一條龍

對話式 AI 寫程式的瓶頸，出在溝通的顆粒度：你給的是零碎指令，AI 回的是零碎片段，於是雙方陷入無止盡的擠牙膏修正。任務導向開發（Task-Oriented Development）換了一個思路——給 AI「目標 + 約束」，讓 Antigravity 這類具備規劃、執行、自我修正能力的 Agentic IDE，把整個功能「做完」而不只是「寫幾行」。

做法可濃縮成三個階段：先讓 AI 規劃（不要急著寫 Code）→ 帶著完整上下文執行撰寫 → 要求它自己寫測試、自己跑測試並修正。本文用 WordPress REST API 與 AJAX 表單兩個情境，帶你把 prompt 從「怎麼寫⋯」升級成「請規劃並實作⋯」，並說明為什麼工程師的角色會從 Coder 轉成 Reviewer。

嗨，我是 Eric，浪花科技那個總是被新技術追著跑的資深工程師。說實話，這幾年寫程式的感覺變了很多。以前我們是「建築工」，一磚一瓦地敲 if-else；現在有了 AI，我們更像是「工頭」，負責指手畫腳。但你一定遇過這種狀況：用對話式 AI 寫一段複雜功能，結果邏輯是對的，但變數名稱亂取、忘了加安全性檢查，甚至根本跑不起來。這就是傳統開發模式的真正痛點，也是任務導向開發想解決的事。

什麼是『任務導向』開發？為什麼你需要它？

傳統的 AI 輔助開發通常長這樣：

• 你：「幫我寫一個 WordPress 的 REST API 端點。」
• AI：「好喔，這是程式碼⋯（丟出一坨 Code）」
• 你：「呃，忘了加權限驗證。」
• AI：「抱歉，這是加了驗證的版本⋯」
• 你：「那個，變數名稱跟我的專案不合⋯」

這種「擠牙膏」式的來回其實很累人，因為每一輪都只補一小塊，AI 也缺乏對整體目標的把握。任務導向開發的核心轉變在於：我們不再給指令（Instructions），而是給目標（Intent）與約束（Constraints）。

「指令」與「目標 + 約束」差在哪？

• 指令（舊）：「寫一個查積分的函式」——AI 只能回應字面要求，缺漏的安全性、命名、測試都得你事後補。
• 目標（新）：「建立會員積分查詢功能」——告訴 AI 要達成什麼。
• 約束（新）：「必須做權限驗證、遵守專案命名慣例、回傳固定 JSON 格式、附上測試」——把你原本要反覆補的要求一次講清楚。

Antigravity 這類 Agentic IDE（代理人開發環境）最強大的地方，在於它具備「規劃」、「執行」與「自我修正」的能力。簡單說，我們不是請 AI 寫 Code，而是請 AI 「完成一個任務」。

Antigravity 實戰三部曲：規劃、撰寫、驗證

要在 Antigravity 中實踐任務導向開發，你的 Prompt Engineering（提示工程）思維必須升級。我們不再只是貼上錯誤訊息，而是要扮演「產品經理」與「技術總監」的角色——前者定義要解決什麼問題，後者定義它必須符合哪些工程標準。

第一階段：讓 AI 代為規劃（Planning）

在寫任何一行 PHP 之前，先讓 Antigravity 幫你擬定計畫。這一步是避免「幻覺 Code」的關鍵。你應該要求 AI 輸出一個 todo.md 或架構說明，而不是直接給你成品。

工程師 Eric 的小囉嗦：別急著叫它寫 Code！相信我，讓 AI 先吐出「偽代碼（Pseudocode）」或「步驟清單」，你會發現它的邏輯漏洞直接少一半。在還沒有任何程式碼的純文字階段挑出問題，修正成本幾乎是零；等到一坨 Code 都生出來才發現方向錯了，重來才是真的浪費時間。

Prompt 範例：
「我需要在 WordPress 建立一個『會員積分查詢』的 API。
請不要直接寫程式碼。先幫我規劃這個功能的架構：
1. 需要哪些檔案？
2. API 的路由與回傳格式（JSON Schema）。
3. 安全性考量（Nonce, Capability）。
4. 請列出實作步驟清單。」

拿到計畫後，你要審的是「方向」：檔案切分合不合理？回傳格式有沒有漏欄位？權限模型對不對？這些在規劃階段定案，後面的撰寫才會穩。

第二階段：讓 AI 執行撰寫（Execution）

確認規劃無誤後，就是 Antigravity 大顯身手的時候。在任務導向開發中，我們會利用它的多檔案上下文（Context）能力，讓它一次生成或修改多個檔案，而不是逐段拼湊。

這時候的重點是「上下文的完整性」。AI 寫出來的東西像不像「你的專案」，取決於你餵進去多少約束。如果你的 WordPress 專案有特定的 Coding Style（例如 PSR-12 命名與排版規範），就把它當成「系統指令」一開始就交代清楚，而不是等它寫完才一條一條挑。

下面是任務導向模式下，AI 為積分查詢 API 生成的端點骨架。注意它在註冊路由時就一併帶上了 permission_callback——權限不是事後補的，而是規劃階段就被列為約束、撰寫階段就落地：

// 這是 Antigravity 生成的範例結構
add_action('rest_api_init', function () {
    register_rest_route('roamer/v1', '/points', [
        'methods' => 'GET',
        'callback' => 'get_user_points',
        'permission_callback' => function () {
            return current_user_can('read');
        }
    ]);
});

這裡用到的 register_rest_route 是 WordPress 註冊 REST API 端點的標準函式，而 permission_callback 是 WordPress REST API 內建的權限關卡：回傳 false 時，請求會被擋下並回傳對應的權限錯誤。把驗證寫在註冊路由的同一處，是讓 AI 不容易「漏掉權限」的好習慣。

第三階段：讓 AI 自我驗證（Verification）

這是最關鍵的一步，也是大多數開發者忽略的。Antigravity 具備在沙箱中執行終端機指令的能力，你可以要求它「自己寫測試，自己跑測試」，形成一個「寫 → 跑 → 看結果 → 修」的閉環。

我們可以要求 AI 產生測試腳本（例如 PHPUnit 測試檔），或用 curl 指令模擬請求，驗證剛剛寫的 API 是否如預期運作。重點是把「驗收條件」寫成可以被機器判定的情境：

Prompt 範例：
「現在，請幫我寫一個簡單的測試腳本，使用 wp_remote_get 模擬請求該 API。
驗證以下情境：
1. 未登入使用者是否回傳 401？
2. 登入使用者是否回傳正確的積分格式？
如果有錯誤，請自行修正程式碼。」

當你把驗收條件講得夠具體，AI 的「自我修正」才真正有意義——它能拿測試結果當回饋，自己判斷哪裡沒過、回頭改 Code，而不是等你把錯誤訊息貼回去才動作。

實戰案例：打造一個具備驗證功能的 AJAX 表單

讓我們用一個實際的 WordPress 情境來看看 Antigravity 的威力。假設我們要透過 Shortcode 插入一個「回報問題表單」，並透過 AJAX 送出。

在傳統模式下，你可能要分別問 HTML 結構、JavaScript 送出寫法、PHP 後端處理，再自己把三塊兜起來。但在任務導向模式下，我們只需要把任務與約束一次定義清楚。

定義任務（Task Definition）

建立一個 Shortcode [roamer_report_form]。包含標題與內文欄位。透過 AJAX 提交到 admin-ajax.php。必須包含 Nonce 驗證。資料存入自訂資料表 wp_reports。

這段任務描述同時涵蓋了「目標」（一個可運作的回報表單）與「約束」（要用 Shortcode、要走 AJAX、要有 Nonce、資料落在指定資料表）。約束越明確，AI 越不容易自由發揮成你不要的樣子。

Antigravity 的自動化流程

1. 分析：AI 會告訴你它需要修改 functions.php（處理後端）和 assets/js/form.js（處理前端）。
2. 資料庫檢查：它會先檢查（或建議建立）wp_reports 資料表的 SQL。
3. 實作前端：生成帶有 wp_create_nonce 的表單 HTML。
4. 實作後端：建立 wp_ajax_roamer_submit_report action，並加入 check_ajax_referer。
5. 自我修正：如果你啟用了自動除錯模式，當它發現 JavaScript 變數 ajaxurl 在前台未定義時，會自動補上 wp_localize_script 把網址傳進去。

為什麼這個案例展示了任務導向的價值？

這串流程裡的每個 WordPress 機制都各有職責，而任務導向開發的好處，是讓 AI 把它們串成一條完整鏈路，而不是逐塊問你：

• wp_create_nonce 在前端產生一次性的安全權杖，check_ajax_referer 在後端驗證它——兩者必須成對出現，AJAX 請求才能防止 CSRF。任務導向模式下，AI 因為「看得到」前後端兩個檔案，比較不會只做一半。
• wp_ajax_{action} 是 WordPress 處理已登入使用者 AJAX 請求的標準 hook 機制，請求統一打到 admin-ajax.php。
• wp_localize_script 負責把 PHP 端的資料（例如 AJAX 網址、Nonce）安全地傳遞到 JavaScript，這正是第 5 步「自我修正」會補上的關鍵接縫。

工程師的新角色：從 Coder 變成 Reviewer

使用 Antigravity 進行任務導向開發，並不代表我們可以躺著睡覺。相反地，我們的責任更重了：必須從「寫 Code 的人」轉變為「審核 Code 的人」（Code Reviewer）。AI 能把活做完，但「做得對不對、安不安全、合不合理」仍要由人把關。

你需要盯緊的審核重點：

• 安全性審計：AI 有沒有漏掉 Sanitization（輸入消毒）或 Validation（驗證）？使用者送進來的資料在存入資料庫前，是否都經過處理？
• 效能瓶頸：它的 SQL 查詢有沒有加索引？有沒有造成 N+1 問題（在迴圈裡反覆查資料庫）？
• 業務邏輯：它是否真的理解你的規則？例如「積分不能是負數」這種領域知識，AI 不會自己知道，得你寫進約束、也得你在審核時確認。

結論：擁抱 AI，但別丟掉你的大腦

Antigravity 帶來的任務導向開發，讓我們可以跳過繁瑣的語法細節，專注於系統設計與使用者體驗。整個流程其實就回到本文開頭的三步：讓 AI 規劃、帶著完整約束撰寫、要求它自我驗證；而你，負責定義目標與約束、並做最後的審核把關。

這就像是從手排車換到了輔助駕駛——你不需要一直踩離合器，但手還是得放在方向盤上，看著前面的路。想讓 WordPress 開發效率翻倍嗎？試著把你的 prompt 從「怎麼寫⋯」改成「請規劃並實作⋯」，你會發現新世界。

想導入 AI 輔助開發流程，卻不知從何開始？

別讓技術債拖垮你的專案進度。浪花科技擁有 WordPress + AI 開發經驗，協助企業打造高效能的數位產品。立即填寫表單聯繫我們。

延伸閱讀

• Antigravity、Claude Code、Codex 三大 AI Coding Agent 完整比較
• AI 寫 Code 只是基本功？深度解析：AI Coding Agent 的真正價值是當你的『技術決策軍師』
• Cursor AI 其實不是 Copilot 的對手？錯！深度解析：它想當的是你的『大腦外掛』
• 客服不再崩潰！用 OpenAI Function Calling 打造能『查訂單』的 WordPress 智慧 Chatbot 實戰