在 AI 代理（Agentic AI）快速普及的今天，許多團隊陷入一種誤區：認為只要導入多代理（Multi-agent）自動化工作流，就能大幅提升開發速度。然而，現實是許多 AI 專案在投入巨資後仍無法達成預期的投資報酬率（ROI）。
Thoughtworks 的技術專家 Wes Reisz 提出了一套 AI-First 軟體交付（AI-First Software Delivery, AIFSD）的觀點。他強調，AI 不應該被視為取代工程師的工具，而是一個「放大器」——如果你原本的工程基礎很差，AI 會放大你的錯誤；如果你有紮實的紀律，AI 則能放大你的生產力道。
對於初入此領域的工程師來說，最重要的是理解：AI 驅動的開發並非一套單一的標準流程，而是一個根據風險與知識量調整的動態過程。
選擇 AI 代理模式的二維矩陣
我們不能對所有任務都採取相同的 AI 自動化程度。Wes 建議使用一個二維矩陣來決定該使用「監督式（Supervised）」還是「非監督式（Unsupervised）」的 AI 代理模式。
這個矩陣的兩個維度是： 程式碼壽命（Longevity）：這段程式碼是短暫的實驗（如 POC），還是會長期運行在生產環境中的核心邏輯？ 自動化驗證程度（Automated Verification）：我們是否擁有足夠的測試案例或驗證機制，能立刻判定 AI 產出的結果是否正確？
根據這兩個維度，開發模式可分為四類： 探索性開發（Vibe Coding）：低壽命、低驗證。適合快速原型開發，重點在於透過快速試錯與客戶確認方向，而非追求程式碼品質。 領域感知（Domain Sensing）：低壽命、高驗證。利用深度研究代理（Research Agents）分析舊有程式碼庫或複雜文件，幫助工程師快速理解業務邏輯。 監督式編碼（Supervised Coding）：高壽命、低驗證。當團隊對業務領域不熟悉時，必須由工程師全程監督 AI，將 AI 視為配對開發的夥伴，確保每一步都符合預期。 非監督式編碼（Unsupervised Coding）：高壽命、高驗證。當領域知識充足且驗證機制完善（如強大的測試套件）時，可以讓 AI 代理在背景獨立執行任務。
RIPER-5：將 AI 納入工程流程的結構化框架
為了避免 AI 產生過度設計或脫離需求的程式碼，Wes 提出了 RIPER-5 框架。這不是一個工具，而是一種與 LLM 互動的「心智模式」，要求 AI 在不同階段扮演不同角色，並嚴格禁止其跨階段操作。
RIPER-5 的五個階段如下：
研究（Research）：目標是收集上下文。指令要求 AI 閱讀檔案、提出澄清問題，但禁止寫程式碼或做計畫。 創新（Innovate）：目標是探索方案。要求 AI 提供三種不同的實作選項，由工程師選擇最合適的一項。 計畫（Plan）：目標是拆解任務。將需求分解為原子級的任務清單，定義依賴關係與成功標準，但禁止開始實作。 執行（Execute）：目標是編寫程式碼。根據計畫實作，禁止擅自偏離計畫。 審查（Review）：目標是驗證結果。比對實作結果與最初的契約（Specification），檢查是否存在偏差（Drift）。
這種做法的核心在於建立「開發者與 AI 之間的契約」。透過詳細的規格文件（Specification），將需求、驗證方式（如 BDD 行為驅動開發）與邊界條件明確化，避免 AI 在不確定的情況下隨機生成程式碼。
AI 時代的工程紀律：為什麼基礎建設更重要？
許多人認為有了 AI 就不需要測試驅動開發（TDD）或持續交付（CD），但事實恰恰相反。AI 生成程式碼的速度遠快於人類審核的速度，如果缺乏紀律，缺陷將會呈指數級增長。
在 AI-First 的環境中，以下傳統工程實務變得更加關鍵： 配對開發（Pair Programming）：AI 是工具而非夥伴。即使有 AI，依然需要人類工程師進行配對審核，以減輕單一審核者面對大量 AI 生成碼時的心理疲勞。 主幹開發（Trunk-based Development）：透過快速整合與持續交付，將品質檢測左移，確保 AI 產出的變更能立即被驗證。 規格驅動開發（Spec-driven Development）：將規格書視為契約。在實作前定義好 Pre-conditions（前置條件）與 Post-conditions（後置條件），讓 AI 有據可依。
實務啟發：從 MCP 伺服器看 AIFSD 的落地
Wes 以實作一個 MCP（Model Context Protocol）伺服器為例。MCP 是一種允許 AI 代理安全訪問外部數據源的標準協議。
在實作過程中，他發現規格定義與計畫階段的投入與最終產出的程式碼比例高達 10 比 1。這告訴我們：軟體工程的本質不在於寫 for-loop，而是在於思考如何正確地建模與拆解問題。當我們花更多時間在研究、創新與計畫時，AI 產出的程式碼才會精準且具備生產等級的品質。
總結
AI-First 軟體交付的核心不在於追求全自動化，而是在於根據對領域的掌握程度，靈活切換監督模式。透過 RIPER-5 這種結構化流程，將 AI 限制在正確的階段，並用紮實的工程紀律（如 CD、TDD、Pairing）來對沖 AI 的非確定性，才能真正實現開發效能的提升。
來源：infoq.com - AI-First Software Delivery: Balancing Innovation with Proven Practices
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。