嘴上抹蜜、手上沒留情：四個 AI 互審程式碼的實驗，是一道被設計過的評審介面

2026 年 10 月 26 日，掘金上一篇標題為「我讓 4 個 AI 互相 review 代碼，最溫柔的那個下手最狠」的文章，把一個流傳已久的說法拿來實測：AI 寫的程式碼讓 AI 審，等於抄作業的互相批改，彼此給面子，最後一起放行。

作者不信這個說法，於是設計了一場實驗。而從設計觀察的角度看，這場實驗真正有趣的地方，在於它把「程式碼審查」這件事，做成了一套介面：考題是道具，人設是配置，評分標準是事先寫死的規則。

考題是一道被刻意埋雷的畫面

實驗的道具是一段約 50 行的搜尋框 Hook 程式碼。作者在其中預埋了五個缺陷：setTimeout 建了不清導致防抖失效與競態、loading 只設 true 不設 false、使用者輸入直接進 new RegExp 造成正則崩潰、未轉義內容拼進 innerHTML 形成 XSS，以及依賴陣列漏了 source。

這五顆雷不是隨機撒的。它們分別對應節流、狀態管理、輸入驗證、安全與依賴正確性五個層面，剛好覆蓋一份前端程式碼審查清單的主要欄位。考題本身就是一份被排好的檢核表，差別只在受測者不知道。

評分標準也事先寫死：只說「錯誤處理可以更好」不算命中，必須點到機制或後果；五顆雷命中不到三顆還給 Approve，認定為放水。四個 AI 評審員互不知情，沒有工具、沒有搜尋，誰也抄不了誰。

這種把模糊的「審得好不好」拆成可判定的布林條件，正是介面設計裡最核心的一步。與我們先前觀察的BOSS 直聘藏在頁面裡的偵測機制類似，規則一旦被寫進系統，就不再依賴當下的情緒與人情。

人設是配置檔，溫柔是一層外皮

實驗的關鍵變因是人設。四位評審員分別拿到四套設定：資深中性型、出名的挑刺嚴審型、安全審查型，以及第四位，寬鬆鼓勵型，人設裡明寫「新人初稿多鼓勵，點到為止」。

這第四位是作者的內應。如果 AI 審查真的會看人設辦事，最容易放水的就是它。

結果是：這位最溫柔的評審員開場先誇了 encodeURIComponent 的細節，全程安撫「別有壓力」，收尾還帶個波浪號「改完我馬上再看～」。然後，XSS、防抖失效、loading 卡死、競態、依賴缺失，五顆雷一顆不落，全部點名。

語氣被設計得柔軟，判斷沒有因此鬆動。嘴上抹蜜，手上沒留情。

溫柔與狠勁可以分層

這個結果值得從介面角度讀。人設提示詞實際上控制的是輸出的「呈現層」：稱謂、語氣、安慰性的開場與收尾。而五顆雷全中、零誤報，說明「判斷層」的內容並沒有跟著人設走。

對照人類審查的日常經驗，這正是差異所在。人的語氣和判斷往往纏在一起：怕傷感情，就把「這裡有 XSS」軟化成「這裡可以再看看」。AI 的評審把兩層拆開了，你可以在配置檔裡指定它客氣，但它回報的事實清單不受客氣影響。

換個基準比：如果同樣五顆雷交給一位礙於情面的資深同事，命中率未必更低，但「點到為止」的機率會高得多。作者安排的三招逼放水手段，塞老好人、偽造證據、打同類牌，一招都沒得逞，5 顆雷、20 次挖掘全數命中。

當然，這是單一作者、單一考題的一次實驗，樣本不足以宣告「AI 審查永不放水」。它能支持的結論比較節制：在結構明確、標準先寫死的任務裡，人設影響的是措辭，不是判定。

收在判斷與語氣的分離

這場實驗最後被作者自己寫成了檢討：原本準備實錘別人放水的文章，變成了對「AI 互相放水」這個說法的反證。

從設計看，它示範了一件樸素的事：當審查標準被事先寫成可判定的規則，評審者的溫柔就只剩排版功能。波浪號放在哪裡都行，五顆雷還是會被挖出來。真正決定審查品質的，從來是那份先寫死的評分表，而非說話的口氣。