AI輔助開發中的前端驗證差距

AI輔助開發讓前端工作感覺快了很多。開發者可以要求一個表單、儀表板卡片、表格、模態框或響應式佈局，幾乎立刻就能得到一個像樣的初版。代碼可能編譯通過，頁面可能渲染出來，UI乍一看似乎已經完成。但前端開發者知道，“看起來完成”和“運行良好”是兩回事。

一個生成的表單可能視覺上顯示驗證錯誤，卻無法向屏幕閲讀器正確宣告。模態框可能打開，但焦點沒有移動到正確位置。下拉菜單可能用鼠標操作完美，但鍵盤無法使用。加載狀態在演示中可能沒問題，網絡慢時卻變得令人困惑。一個組件可能用示例數據表現良好，但一旦真實內容更長、缺失、延遲或出乎意料，就會崩潰。

這就是AI輔助開發中的前端驗證差距。這裏的驗證是指檢查界面在實際條件下是否真正為用户正常工作，而不僅僅是代碼編譯、頁面渲染或屏幕匹配設計。它涵蓋可訪問性、鍵盤行為、焦點管理、狀態變化、加載和錯誤處理，以及用户能否從頭到尾完成任務。AI可以幫助團隊更快地生成界面代碼，但團隊卻難以自信地回答這些問題。

這並非反對AI工具。它們確實有用，可以減少重複工作，幫助開發者突破瓶頸，加速功能初稿。但AI生成的前端代碼仍應被視為草稿。下一個挑戰不僅是更快地生成UI代碼，更是足夠仔細地驗證這些代碼。

前端正確性比看起來更難。某些代碼容易驗證——函數返回預期值，API返回正確響應，腳本成功完成。前端不同，因為界面是軟件與人交匯的地方。UI必須同時滿足多個要求：正確渲染、響應輸入、保持狀態、支持鍵盤導航、向輔助技術暴露正確信息、處理加載、錯誤、空狀態和意外數據。還要符合設計系統以保證體驗一致。

AI工具通常擅長產生可見部分。它們可以生成在默認狀態下看起來合理的表單、卡片或表格。當開發者需要起點時，這很有用。但問題在於默認狀態只是體驗的一部分。更難的問題出現在屏幕出現後：用户能否僅用鍵盤完成流程？請求失敗時會發生什麼？錯誤後焦點是否移到有用位置？字段標籤和錯誤消息是否正確關聯？沒有結果時UI是否仍有意義？生成的代碼是否使用現有設計系統模式，還是悄悄引入了新的？

這些不是小細節。它們關乎界面是否真正可用。

快速審查是不夠的。常見的AI輔助工作流程是：寫提示、生成代碼、審查結果、做一些修改、繼續前進。這對原型或內部實驗可能沒問題，但對生產級前端工作遠遠不夠。問題不僅是AI會犯錯——開發者也會犯錯——而是AI能讓不完整的工作看起來出奇地光鮮。代碼可能整潔，結構可能熟悉，組件可能遵循常見框架慣例。這種拋光會讓審查者更少質疑其行為。

前端問題往往就這樣被遺漏了。可訪問性問題、焦點bug、競態條件、缺失的空狀態和模糊的錯誤消息通常不會在快速視覺掃描中顯現。它們只在有人在不完美條件下與功能交互時才暴露。

AI生成的測試也可能造成同樣問題。測試可能確認組件渲染，但無法確認用户能完成任務。另一個測試可能檢查內部狀態變化，卻忽略了鍵盤行為、驗證消息、加載狀態或失敗路徑。

因此，工作流程需要比“提示、代碼、審查”更強。團隊需要對AI生成的前端工作進行更好的驗證。這不一定要變成繁重的流程，只是需要更有意識地檢查在UI被認為準備好之前必須檢查什麼。

更明確地定義“完成”的含義。改進AI生成前端代碼的最簡單方法之一是在它開始寫代碼之前給出更清晰的期望。有些期望不應在每個提示中重複。例如，使用現有設計系統組件、遵循可訪問性標準、優先使用原生HTML、處理加載和錯誤狀態等規則，可以放在持久化的項目説明文件中，比如CLAUDE.md，或者其他代理在開始工作時讀取的啓動文件。這為代理提供了整個項目的共享基線，減少了重要標準被遺忘的可能性。

然後任務特定提示可以專注於該功能的獨特細節。例如，不是簡單要求一個表單，任務可以解釋哪些字段是必需的，提交後應該發生什麼，驗證後焦點應該移到哪裏，以及用户如何在請求失敗時恢復。

持久化指令和任務特定提示扮演不同角色。前者記錄團隊的工程期望，後者解釋該特定功能需要做什麼。這也使審查更容易。審查者不再只是問屏幕是否接近原型，他們可以檢查功能是否遵循項目既定規則，以及特定流程是否按預期運行。

這很重要，因為許多前端質量期望很容易被忽視。可訪問性、焦點行為、加載狀態和錯誤恢復應儘可能成為代理工作上下文的一部分，而不是依賴開發者記住在每個提示中提到它們。

讓設計系統做更多工作。AI工具在清晰的邊界內最有用。對前端團隊來説，最好的邊界之一是強大的組件系統。如果每個生成功能都創建自己的按鈕、輸入、模態框、下拉菜單、警告和表格，團隊就得一遍又一遍地審查同樣的問題：這個按鈕可訪問嗎？這個模態框正確管理焦點嗎？這個錯誤消息與字段關聯嗎？這個下拉菜單支持鍵盤交互嗎？樣式與產品其他部分一致嗎？這造成了不必要的重複工作。

更強的模式是把這些決策放入可複用組件。按鈕組件應已處理變體、禁用狀態、焦點樣式和可訪問命名期望。模態框組件應已處理焦點移動、Esc鍵行為、標籤和焦點返回觸發元素。表單字段組件應已連接標籤、幫助文本、必需狀態和驗證消息。這樣AI就不需要從頭髮明模式，而是組合已攜帶團隊標準的部件。

提示“構建一個模態表單”和提示“使用現有的Modal、TextField、Button和FormMessage組件構建此流程”有很大區別。第二個請求給了工具更安全的路徑，也給審查者更少擔憂，因為最危險交互模式已經由共享組件處理。從這個意義上説，設計系統不僅關乎視覺一致性，還能成為驗證層。它縮小了可能輸出範圍，幫助團隊減少需要手動捕獲的問題數量。

測試用户實際依賴的行為。自動化檢查無法捕捉所有問題。它們不能告訴你流程是否直觀，不能替代深思熟慮的審查，也不能保證每個用户都有良好體驗。但它們能及早發現常見問題，因此是前端驗證的重要組成部分。可訪問性檢查可以標記缺失標籤、無效ARIA使用、一些地標問題和其他常見錯誤。組件測試可以檢查狀態變化和驗證行為。端到端測試可以確認用户能完成重要流程，而視覺測試可以捕捉某些佈局迴歸。重要的是測試行為，而不僅僅是結構。

例如，基本測試可能確認表單渲染。更有用的測試檢查用户是否能輸入值、觸發驗證、理解錯誤、糾正錯誤、提交表單並收到清晰的反饋。類似地，不是僅僅檢查模態框出現在DOM中，測試可以確認焦點移入模態框、鍵盤導航正常工作、Esc鍵關閉它、焦點返回原始觸發元素。

這時Playwright風格的用户流程測試特別有用。它允許團隊以更接近真實用户體驗的方式測試界面。問題不再是界面是否渲染，而是用户是否能完成任務。

AI可以幫助生成這些測試，但團隊仍需定義哪些行為重要。要求AI工具“為這個組件寫測試”留下太多解釋空間。要求測試鍵盤導航、驗證錯誤、加載行為、空狀態和失敗提交則給出了更清晰的目標。AI生成測試的質量仍然取決於其背後的驗證意圖。

審查體驗，而不僅僅是代碼。代碼審查仍然重要，但AI輔助前端工作需要稍微不同的審查心態。審查者需要超越代碼是否整潔以及屏幕是否與預期佈局匹配。他們還應該問：我們是否使用了現有設計系統組件？生成的代碼是否引入了自定義控件而原生HTML更好？標籤和錯誤是否正確關聯？能否用鍵盤完成流程？當數據為空、延遲或無效時會發生什麼？測試是覆蓋真實用户行為還是主要覆蓋實現細節？

這些問題幫助審查從語法轉向體驗。這不意味着每次拉取請求都需要長 checklist。流程仍可以輕量。但重要關切需要可見。如果可訪問性、焦點行為、加載狀態和錯誤恢復在審查中從不出現，它們將繼續被遺漏。

AI並不能自動解決這個問題。在某些情況下，它讓差距更容易被忽視，因為生成的結果看起來比實際更完整。

使用AI而不降低標準。目標不是讓AI輔助開發感覺有風險或緩慢。目標是利用AI擅長的事，同時不讓它悄悄降低質量標準。AI對初稿、重複性腳手架、替代實現、測試想法和重構建議很有用。它可以幫助開發者更快地完成常規工作。但它不應定義“足夠好”的含義。

前端團隊可以通過將AI與清晰的工程習慣結合來獲得更多價值。每次使用現有組件而不是生成新模式。在提示中包含可訪問性和交互行為。要求加載、空、錯誤和成功狀態。添加常見問題的自動化檢查。以用户的方式測試重要流程。