在 AI 輔助開發(Lovable、Bolt、Cursor、Copilot 等)成為常態的今天,效能測試的本質沒變,但問題的形態、來源、和檢測方式都發生了結構性的轉變。以下從幾個關鍵維度切入。
一、程式碼產出速度遠超測試速度的「效能債爆量」
過去一個工程師一天寫 200 行,現在 AI 一小時就能產出 2000 行。但效能測試的設計、執行、分析速度並沒有同步加速,結果就是:
- 大量「看起來能跑」的程式碼進入 codebase,但沒有人壓測過
- Vibe coding 出來的功能往往在 demo 環境(單一使用者、小資料集)表現良好,一上 production 遇到並發或大資料量就崩潰
- 技術債從「程式碼可讀性」轉變為「隱性效能債」——你不知道哪裡會炸,因為沒人真正讀過那段程式碼
舉例:Cursor 生成一個資料查詢功能,語法正確、邏輯正確,但內部用了 N+1 query。功能測試 100% 通過,直到 production 資料筆數破萬才發現 API response time 從 200ms 飆到 15 秒。
二、AI 偏好「能動」而非「跑得快」的程式碼
LLM 的訓練資料來自網路上的程式碼樣本,而網路上大多數範例程式碼是教學導向、不是效能導向。這導致 AI 系統性地產生幾類效能反模式:
- 過度使用同步呼叫(明明可以平行處理)
- 在迴圈內做 I/O 或資料庫查詢
- 預設使用最直觀但非最佳的演算法(例如 O(n²) 的雙層 loop 而不是 hashmap)
- 不必要的深拷貝、重複序列化
- 偏好「看起來乾淨」的抽象層,但實際上多了好幾層函式呼叫開銷
這意味著效能測試不能只測終端使用者體驗,還要測「AI 慣性反模式」——你需要針對熱路徑(hot path)做 profiling,而不是只看 P95 latency。
三、Performance Baseline 漂移得更快
傳統做法:每個 sprint 結束跑一次 load test,跟上一版比較。
但在 AI coding 環境下,一天可能 merge 30 個 PR,效能基準的漂移速度遠超人工監控頻率。挑戰變成:
- 必須把 performance test 整合進 CI/CD,而且要快(不能跑 30 分鐘)
- 需要自動化的 regression detection——例如同樣的 endpoint 從 50ms 變 80ms 算不算回歸?
- 需要可信的 baseline 管理機制,否則噪訊會淹沒真正的問題
四、可觀測性的訊號變雜了
當人寫程式時,效能問題的根因通常集中在幾個熟悉模式(資料庫慢查詢、快取失效、記憶體洩漏)。AI 寫的程式碼會產生更分散、更非典型的效能瓶頸:
- 奇怪的字串處理迴圈
- 莫名其妙的遞迴
- 不必要的 polling
- 多層 wrapper 累積的微小開銷
傳統 APM 工具的「常見問題」儀表板可能抓不到這些,需要更細緻的 tracing 和 flame graph 分析。
五、測試本身也是 AI 寫的——信任問題
如果效能測試腳本也由 AI 生成,你怎麼知道:
- 測試覆蓋的場景是真實業務場景,還是 AI 想像的場景?
- Load 模型的參數(QPS、ramp-up、思考時間)合理嗎?
- 斷言條件(assertion)是有意義的門檻,還是 AI 隨手填的數字?
這是新的 meta-testing 問題:測試 AI 生成程式碼的測試,本身也需要被審查。
六、多 Agent 協作下的「分散式效能責任真空」
當不同 Agent(或不同 AI 工具)分別負責 frontend、backend、database layer,沒有任何一方對 end-to-end performance 負責。Frontend Agent 不知道它的請求模式會壓垮 backend;Backend Agent 不知道它回傳的資料量會讓前端 render 卡頓。
這呼應了你在做的測試框架方向——多 Agent 協作的效能驗證需要被視為一個獨立的測試層,而不是各自為政。
給非工程師的比喻
可以把它想成「廚房效率檢查」:
過去廚師人少,每道菜上桌前都會試吃,有問題立刻發現。現在 AI 讓你一小時能出 100 道菜,但沒人有空試吃了——客人吃下去才知道哪道菜火候不對、哪道菜份量不夠快。效能測試的角色,就是那個系統化的「上桌前品管員」,在 AI 時代必須變得更自動、更頻繁、更聰明。
發表迴響