是時候清理“人類垃圾”了

隨着AI模型開始主導代碼編寫，討論焦點已轉向如何有效利用AI審查當前創建的代碼庫。如果共識是應將人類檢查點前移，那麼問題就來了：人類開發者到底應該在哪裏工作？

這是一個在團隊中常見的痛點：強制性的同行評審往往淪為橡皮圖章。一個拉取請求在同行評審渠道中擱置幾天，最終另一位對上下文知之甚少的開發者才出現，並説：“賭一把，合併吧。”

Groundcover軟件工程師Avital Tamir認為：“我們必須認識到，是時候清理‘人類垃圾’了——即人類比AI更常犯的一類錯誤。對於這些類型的錯誤，AI審查者比疲倦的人類可靠得多。”

大多數開發團隊仍在經歷這種場景，或許是因為人們樂觀地認為利大於弊，或許是因為這給軟件團隊帶來了一種標準化的秩序感。Tamir呼籲改變軟件團隊處理代碼審查的方式，他告訴The New Stack，他並非建議完全放棄秩序，而是認為過去二十年來的代碼審查方式需要與時俱進。

Tamir説：“關於AI垃圾（如幻覺、誤解上下文和自信的錯誤）有很多討論，這些都是真實的問題。但我們也必須認識到，是時候清理‘人類垃圾’了。對於這類錯誤，AI審查者比疲倦的人類可靠得多。”

他描述了一個典型場景：功能完成後，開發者發起拉取請求，然後等待。同事在Slack上被提醒，但第一天無人回應。48小時後，有人評論變量命名問題或提出代碼中已回答的問題。開發者修復這些瑣碎問題，因為爭論比修復更耗時。最終，有人回覆“LGTM”（看起來不錯）。

Tamir問道：“這完成了什麼？本可以週二上線的功能拖到了週五。你的競爭對手週二上線，週三發現真正的bug，週四修復。而你在審查地獄中浪費了兩天，優化了推諉責任的可能性，而不是迭代速度。”

他認為，審查時間真正捕捉到的是那些真正有害的bug嗎？“真正有害的bug，如競態條件、數據邊界情況或負載下的故障模式，很少被孤立閲讀代碼的人發現。通常的反饋是風格上的，比如‘使用提前返回’、‘提取函數’等——這些都是好的靜態分析應該自動捕獲的東西。”

如果將此過程乘以數十名工程師、每週多次拉取審查和多審查員策略，複合成本變得巨大，最終表現為錯失的發佈特性和學習週期。

Tamir提倡嚴格的自我審查流程：與AI緊密合作，閲讀每次編輯，測試套件，手動端到端驗證，打開拉取請求讓AI工具運行，迭代，合併，監控。他説：“這個過程比等待48小時獲得LGTM更嚴格。而且，它將責任置於最瞭解問題的人手中。不舒服的真相是，許多代碼審查只是走過場，製造了嚴格的假象，卻沒有可靠地交付。”

考慮到這些AI代碼審查工具的存在，問題最終可能歸結為軟件工程團隊結構和管理方法的本質。Tamir建議，如果領導層不信任工程師負責任地審查自己的工作，“這是一個招聘問題，而不是流程問題”。他認為，高績效團隊的信任是通過成果建立的，而不是通過審批隊列。

團隊可以考慮從低風險的內部工具或非面向客户的系統開始嘗試這些方法，同時衡量成功指標，保留同步人類協作用於更高風險決策。這樣，團隊協作才能真正發揮作用，從LGTM轉變為“真的看起來很優秀”。