另一個 AI 做 code review：XDA 實驗揭示的盲點
XDA Developers 作者把 Codex 生成的編採日曆 web app 交給 Claude Code 審查，要求後者以資深開發者檢閱初級開發者作品的方式，找出設計不一致、隱藏 bug 和易用性問題。Claude Code 的回報包括程式碼可讀性、文字與色彩對比等可及性問題，以及瀏覽器儲存與多分頁覆寫資料的風險。
這個案例對使用 coding agent 建立網站或 app 的人有一個直接啟示：能順利開啟、介面吸引的成品，未必已經適合日常使用。不過，測試只反映一名作者、一個項目與未披露模型版本、prompt 和完整測試方法下的結果；它不能證明「由另一個 AI 做 code review」普遍可靠，也不能當成兩款工具能力高下的定論。
表面完成，未必代表可交付
據報道，Codex 為作者建立了編採日曆網站，初步具備響應式版面、手機導覽、基本可及性設計和完整視覺介面。作者其後沒有繼續要求 Codex 反覆修正，而是把既有 codebase 交給 Claude Code。
Claude Code 指出部分檔案存在過長行數，其中一份 41KB 的樣式表被壓縮成只有 19 行，令日後閱讀和維護更困難。它亦發現小字及部分配色未達標準對比要求。這些問題未必會阻止網站載入，卻會影響有視覺需要的用戶，以及後續接手修改程式的人。
較實際的發現是資料處理方式：整個工作區會在每次按鍵後寫入瀏覽器儲存空間，而同時開啟多個分頁時，修改有機會互相覆寫。對日曆這類需要持續輸入資料的工具而言，這類回歸或同步問題比畫面小瑕疵更重要，因為可能直接造成資料遺失或混亂。
第二個 agent 可作初篩，但不能取代驗證
把建立者與審查者分開，概念上接近開發團隊的同儕審查：後來接手的一方毋須重新搭建架構，可集中閱讀現有實作、檢查邊界情況，並提出針對性修改。作者亦認為，這樣可把後續工作聚焦於分析與修正，理論上比由另一個 agent 從頭重建更省 token 和時間。
但這個流程的可靠度取決於審查範圍，而不是只取決於換了另一個工具。AI 能指出問題，不等於它已經準確重現、修好並驗證每一項問題；同樣地，審查 agent 自己提出的改動也可能帶來新 bug。來源沒有交代 Claude Code 實際改動了甚麼、修正後是否經功能、可及性或多分頁情境測試，也沒有量度耗時、token 用量或錯誤率。
因此，若要把這種做法發展成可重現的工作流程，較合理的做法是先把要求寫成可驗證清單：核心功能能否完成、鍵盤操作和色彩對比是否合格、輸入資料在重整及多分頁情況下會否衝突，以及修正後有否令原有功能退步。同時記錄每次 agent 的任務、改動、耗時和成本，才可判斷第二輪審查究竟帶來多少實際收益。
下一步看測試紀錄，而非單看介面
這次實驗支持一個有限但實用的結論：以不同 coding agent 交叉檢視，可能有助揭開首輪生成程式中不易從介面察覺的問題。對非技術用戶尤其有參考價值，因為他們往往較容易被可運作的畫面說服。
下一步值得觀察的，是工具使用者會否把功能、可及性、資料安全與回歸測試納入固定驗收流程，並保留可比較的結果。只有在這些條件下，第二個 AI 的意見才較接近 code review，而不只是另一輪看似合理的建議。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- XDA Developers — I asked Codex to build a website, then let Claude Code fix everything it got wrong — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
