當我們討論 AI 寫程式時，大多數人的印象還停留在 Copilot 幫我們補完一行程式碼，或是 ChatGPT 幫我們寫一個單一功能的 Function。但業界現在關注的焦點已經從單純的 Code Generation（程式碼生成）轉向了 Agentic Workflow（代理工作流）。簡單來說，就是讓 AI 不僅能寫程式，還能像工程師一樣操作終端機、瀏覽器、閱讀文件並執行測試，完成端到端的開發任務。
金流巨頭 Stripe 最近推出了一套基準測試（Benchmark），旨在評估 AI Agent 是否能獨立完成真實的 Stripe 整合開發。這項測試非常有價值，因為金融系統對正確性的要求極高，任何微小的錯誤都可能導致金錢損失，因此這是一個極佳的壓力測試場域。
測試環境與實作脈絡
Stripe 建立了 11 個可複現的模擬環境，包含完整的應用程式碼庫、資料庫以及測試用的 API Key。AI Agent 需要在這些環境中處理如 Checkout 遷移或 Billing API 建模等任務。
為了讓 AI 能夠像工程師一樣工作，Stripe 採用了基於 Goose 和 MCP（Model Context Protocol，一種讓 AI 模型能標準化存取外部工具與資料的協定）的框架。這讓 AI 擁有了終端機操作權限、瀏覽器自動化能力以及文件檢索工具。
在這次測試中，AI 不只要寫出程式碼，還必須啟動服務、呼叫 API，並透過自動化測試或模擬使用者流程來驗證結果是否正確。
AI Agent 的表現與核心瓶頸
從測試結果來看，頂尖模型如 Claude Opus 4.5 在全端 API 整合任務中表現優異，而 GPT 5.2 在結構化任務中也展現了強大的能力。然而，數據揭露了一個關鍵事實：AI 寫程式的能力已經很強，但驗證（Validation）能力卻是目前的致命傷。
Stripe 的工程師指出，AI Agent 目前還無法取代軟體工程師，主因在於它們缺乏一個穩定的驗證層來確保整合流程的絕對正確。具體來說，有兩種典型的失敗模式值得 Junior 工程師關注。
第一是誤判驗證訊號。在進行 SDK 升級任務時，有些 AI Agent 在輸入錯誤參數後收到了 HTTP 400（Bad Request）錯誤回應。正常工程師看到 400 錯誤會知道出錯了並修正，但 AI Agent 卻將這個回應視為一種互動結果，錯誤地認定整合已經成功。這顯示 AI 在面對負面訊號時，缺乏正確的推理邏輯。
第二是瀏覽器狀態管理失效。在處理 Checkout 結帳流程時，AI 必須在網頁介面輸入地址與卡號。但在操作過程中，工具的互動可能會導致瀏覽器焦點偏移或狀態改變。雖然人類工程師可以簡單地透過重新整理頁面或重新聚焦來恢復，但 AI Agent 經常在遇到這種狀態中斷時陷入混亂，直接放棄任務。
對開發者的啟示
這次基準測試提醒我們，真正的軟體工程不僅僅是寫出能跑的程式碼，更重要的是處理邊緣案例（Edge Cases）與確保系統魯棒性。
目前的 AI Agent 在處理長路徑任務（Long-horizon execution）時，雖然能維持較多輪的互動，但正確率會隨著步驟增加而下降。此外，實務生產環境中至關重要的冪等性（Idempotency，確保同一操作執行多次結果相同）、重試機制（Retries）以及權限範圍（Authorization Scope）等細節，目前大多數的 AI 評估體系都尚未能有效涵蓋。
總結來說，AI 已經能幫我們完成大部分的重複性編碼工作，但在複雜的狀態管理、錯誤恢復以及對正確性的嚴格驗證上，依然需要經驗豐富的工程師把關。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。