AI 知識
React 的完成標準不能只剩 tests passed
AI coding agent 最容易讓人放心的一句話，可能就是 tests passed。
它代表測試沒有報錯、CI 顯示綠燈，表面上看起來也像是可以合併了。但 ReactBench 公開的評估結果提醒我們：對 React 專案來說，行為測試通過和程式碼真的修對，中間仍有很大的落差。
截至 2026 年 7 月 22 日查閱當下，ReactBench 官網目前榜單最高組態的整體分數約為 53.3%。更值得注意的不是模型名次，而是一個具體現象：在 3,219 次失敗的 React 修復嘗試中，有 1,956 次，也就是 60.8%，其實已通過行為測試，卻沒有通過 React 品質檢查。
換句話說，功能看起來能用，並不代表修復已經合格。
ReactBench 不只問能不能跑
ReactBench 以 51 個來自真實開源 React repository 的任務評估 coding agent。它把任務分成新增功能與修復既有問題兩類，並要求解答同時跨過兩道門檻。
第一道是行為測試。它確認指定功能是否能運作、原有行為是否被保留。
第二道是 React Doctor 的 deterministic checks。這些檢查涵蓋 React 常見的 correctness、state 與 effect 使用、render 效能、無障礙、安全與可維護性問題。
這個設計很重要，因為它沒有把測試綠燈當成終點。
一段程式可以通過有限的輸入輸出測試，卻仍然違反 Hooks 規則；也可以讓畫面正常更新，卻引入不必要的重新渲染。它甚至可能保留眼前功能，但留下無障礙缺口、安全風險或未來很難維護的結構。
60.8% 說明了什麼
ReactBench 的 Fix React 任務要求 agent 移除指定的 React 問題，同時保留原有行為。
在失敗的 Fix React trials 中，有 60.8% 通過行為測試，卻沒通過 React Doctor。這不是說 60.8% 的所有 AI 修復都失敗，而是說：在已經判定失敗的那一群修復裡，多數並不是因為功能測試直接爆掉，而是因為 React 品質問題仍然存在。
這個分母不能偷換，但它揭露的工程問題非常實際。
很多團隊的自動化流程，最擅長檢查需求有沒有被做出來，卻比較不擅長檢查做法是否符合框架規則、是否帶來隱性退化。當 agent 以通過測試為目標，它很可能找到一條能讓測試變綠的路，卻不一定找到最正確、最穩定的實作。
新功能也可能把 bug 一起帶進來
ReactBench 對 Write React 任務的統計同樣值得注意。
在 4,455 次新增 React 功能的嘗試中，模型總共引入 1,194 個被計分的 React Doctor 問題，其中 925 個，也就是 77.5%，被歸類為 bug。常見類型包含 list rendering 與 Hook correctness。
這表示 AI 不只可能沒把舊問題修乾淨，也可能在交付新功能時創造新的結構性問題。
對人類開發者來說，這些問題未必會立刻出現在畫面上。它們可能要等到資料量增加、元件重複掛載、effect 觸發條件改變，或產品進入更複雜的互動情境後才浮現。
綠燈因此很容易製造一種過早的完成感。
測試不是沒用，而是不能只剩一種測試
ReactBench 的結果不代表測試失去價值。相反地，它說明測試需要分層。
第一層仍然是行為測試，確認需求是否成立、既有功能是否退化。沒有這一層，程式連基本功能都無法被信任。
第二層是框架與靜態品質檢查，針對 Hooks、effect、render、無障礙、安全與可維護性建立更具體的規則。
第三層是實際畫面與互動驗收。ReactBench 自己也說明，deterministic checks 不保證視覺結果完全正確。版面位移、文字重疊、狀態切換與真實瀏覽器行為，仍需要 browser smoke、截圖或人工檢查。
第四層則是變更範圍與回歸風險。AI 可能完成指定任務，卻順手修改不相關檔案，或把局部問題擴大成跨模組變更。這種風險不能只靠單元測試發現。
面對 AI 產出的 PR，至少多問四個問題
看到 tests passed 之後，可以再問：
- 行為測試涵蓋了哪些情境，哪些根本沒被測到？
- 框架專屬規則、靜態分析與安全檢查是否也通過？
- 真實瀏覽器裡的畫面與互動是否驗過？
- diff 是否只改必要範圍，沒有藏著非預期變更？
這四個問題不是要把 AI coding 變慢，而是避免把產出很快誤認成交付已完成。
真正的完成，不是一排綠燈
ReactBench 衡量的是 agent 與 harness 的組合，不是抽離工具環境後的純模型能力；它目前也主要以開源 React 任務為主，不能直接外推成所有程式語言與所有軟體專案的共同結論。
但它提供了一個很清楚的提醒：當 AI 開始大量產生與修改程式碼，驗證系統必須比以前更完整。
真正值得信任的完成，不是 agent 自己說完成，也不是 CI 只亮一排綠燈，而是行為、框架規則、效能、安全、實際畫面與變更範圍都留下可核對的證據。
AI 可以讓程式寫得更快。至於能不能更放心地合併，答案取決於我們用什麼方式驗它。
查證來源
- ReactBench：https://www.reactbench.com/
- ReactBench 分析：https://www.reactbench.com/blog
- ReactBench GitHub：https://github.com/millionco/reactbench