一名署名 kyriewen 的開發者於2026年9月24日在技術社羣平臺掘金發表文章，說明自己在程式碼審查（code review）中打回AI生成PR（pull request）的三條規矩。文章張貼當日閱讀量為31次。文章核心主張是：AI寫的程式碼在速度與整潔度上已超過作者本人，打回的原因並非品質差，而是沿用審查人寫程式碼的舊標準，評不出重點。
三條規矩的內容如下。
第一條，前端元件的載入、錯誤、空值三種狀態（loading、error、empty）未補齊者，直接打回，不商量。第二條，AI對需求的理解未隨PR一併提交者，打回並要求先補材料。第三條，diff中混入任務範圍外的「順手改動」者，打回。
爭議集中在第一條。作者自述，質疑者的理由相當一致：人寫的元件若三態不齊，通常只留一則評論提醒後就合併，為何AI寫的就要直接打回。作者承認這是雙重標準，並提出理由：打回人的程式碼，對方一下午的工作作廢，還要多一次不愉快的溝通；打回AI的程式碼，它重跑只需三分鐘。他認為修正動作變便宜了，標準卻停留在原地，才是浪費，並由此推論對AI的PR要求應比對人更嚴。
在第一條的技術論證上，作者以React Query的資料列表元件為例：AI預設只產出「happy path」，亦即在請求成功情境下的程式碼。請求成功前data為undefined，介面一旦抖動，data.map一行會直接導致白屏；介面報錯時使用者看到的仍是白屏，沒有任何提示。作者的說法是，這不是AI的能力問題，而是開發者提供的上下文裡本來就只有成功路徑。補齊三態後，載入中顯示骨架屏、錯誤顯示可重試的錯誤狀態、空資料顯示空狀態元件，才算完成。
第二條規矩針對的是需求理解。作者的比喻是「盲盒評審」：看不到AI以為的需求是什麼，這個PR就無法評審。他將PR描述固定為三段：產品人員的需求原文原樣貼上、AI代理的計畫輸出原樣貼上、以及自己糾正過的理解。作者認為第三段最有價值，並指出Claude Code、Codex這類代理工具都有計畫模式，先列方案再動手，該份計畫輸出即為現成的評審材料。評審流程也因此改變：先比對AI的理解與需求原文的落差，再決定程式碼要看到多細。
第三條規矩處理範圍外改動。作者描述的典型情境是：AI修一個按鈕對齊問題，會順手用prettier重排半個目錄、刪掉兩個它判定沒人使用的匯出、再悄悄升級某個依賴的小版本。作者的區分方式是：人做這種事叫順手，機器做這種事叫越權，因為人會為自己的改動負責，機器不會記得。來源文章在此處截斷，後續論述無法核實。
需要說明的是，本篇來源為個人部落格性質的經驗分享，三條規矩為作者個人的審查標準，並非任何公司或社羣的正式規範。文中所稱「打回AI的PR越來越勤」屬作者自述的工作情境，其具體專案背景、團隊規模與使用的AI工具組合，文章均未交代。截至目前，可核實的事實僅止於：該文於9月24日發表於掘金，內容為一名開發者的個人審查準則與其對爭議的回應。所謂「第1條就有爭議」，依文章自述是指其在社羣內部交流中收到的質疑，貼文平臺上目前未見具名的公開反對意見可供對照。