title: 注意力的回報：為什麼 AI 程式碼審查讓我們精疲力竭
published: true
description: PR 數量上升了，工單品質卻沒有，這個落差被雙方的 LLM 填滿了：機器人審查、機器人回覆、機器人偶爾還會和機器人爭論那些只存在於隊友腦中的優先順序。我們的 CEO 點出了真正的問題，而這個問題比程式碼審查本身更大。
tags: ai, codereview, productivity, softwareengineering
canonical_url: https://christine-seeman.com/return-on-attention-ai-code-review/
今年我們的團隊變大了，PR 的數量也跟著增加，當然，速度比工單產生得還快。新人變多，代表更多程式碼流經這條管線；但這不代表上下文也變多。很多大量的 PR 都需要認真思考才能看懂：它在解決什麼問題、為什麼要用這種做法、哪些才是真正重要的，哪些只是附帶的。那道落差——程式碼更多，大家共享的理解卻一樣多——正是我們麻煩開始的地方。
當審查變得更難、更慢時，人們自然會抓住能幫忙跟上節奏的工具。我們現在在每個 PR 上都跑一個 AI 程式碼審查機器人，另外也有不少人會在本機用自己選的 LLM 和寫碼代理人來起草審查留言。把這兩件事放在一起，你就會得到完全可以預期的場景：一個機器人在 PR 上留言，另一個機器人回覆它。有些 LLM 產生、被回報的 bug，最初就是由一個毫無保留、卻沒有任何方式知道自己其實弄錯了的模型先「創造」出來的。這正是 AI 寫碼輔助的一個真實缺點：自信地出錯。
感受起來像什麼
留言開始不再像是原本那些據說寫出它們的同事。冗長。把所有可能的參考資料和引用都塞進去，不管當下到底需不需要。我們是一個習慣用自己的話直接談程式碼的團隊，結果 PR 裡開始充滿 AI 垃圾內容。
有個抱怨不只一次被提到：不得不離開 PR 去找真正的上下文，因為留言本身不是資訊不夠，就是廢話太多。你得去 thread 外面 ping 一個人，或 ping 一個模型。可 pull request 留言的目的，本來就是你不該需要再去別的地方找答案。
另一個問題是重複，以及重讀的成本。花一分鐘直接讀程式碼就看得懂的段落，並不會幫你省時間；它只會花掉你的時間，還要再加上留言本來應該幫你省下的那一份。
團隊裡有人直接說得很明白：現在不太確定什麼才是對的平衡，但整個範式顯然已經變了。這說法很公平。比較不公平的是，假設我們現在這樣做，就是唯一可能的做法。
稀缺資源
幾週後，我們的 CEO 在 Slack 上說了一句話，真的一語中的，讓我看清了整個問題。PR 審查的抱怨都是真的，但它們只是症狀，不是病因。他的觀點是：真正的瓶頸不是 PR 審查本身，而是資深同事有限的注意力，很容易被 LLM 生成的內容淹沒。人類注意力才是最稀缺、最值得最嚴格守護的資源；把那些冗長、產製成本低但閱讀成本高的文字硬塞給彼此，應該被視為真正的反模式。他稱之為注意力回報率，Return-on-Attention，ROA：你要求別人讀的每一個字，都必須對得起他們閱讀它所付出的成本。
他用同一週的兩個例子來佐證。有些 ADR 裡面有大量重複內容，同事得把全部讀完。ROA 很糟。另一個 PR 只是在 .gitignore 裡加了一個目錄，只有一行程式碼、十個字元，卻附上長達 1,430 個字元的說明。對任何需要審查的人來說，ROA 都糟透了。
這兩個例子都不是在談程式碼品質，而是在談：你可以為了替自己省下三十秒編輯時間，讓別人得付出多少注意力成本。
同樣的概念也有一個公開版。noslopgrenade.com 把它稱作「slop grenade」：把一大段 AI 生成的回應貼到聊天或電子郵件裡，而原本人類只會寫一句話。它針對的是聊天，不是程式碼審查，但失敗模式完全一樣。LLM 可以免費產生比任務需要更多的字，而那個多出來的成本並不會消失；它只是轉嫁到最後要讀的人身上。
我不太想承認的部分
我也在自己身上注意到同樣的拉力，只是不是身為審查者，而是身為思考者。有些時候，我會在真正把問題想清楚之前，就先丟給模型，而我能感覺到自己的工作流程紀律變鬆了。不是因為答案錯了，而是因為我不再先自己把事情釐清，再來提問。
我也正在和 Claude 的一個特定習慣對抗：把設計決策敘述進註解和程式碼裡。像是「我們選了這個，而不是那個。」它會自己冒出來，根本不用你提示，而且對我來說一次也沒真正有用過。這種決策應該放在 PR 說明或 commit 訊息裡，因為那裡有上下文、有日期、也有作者。放在程式碼註解裡，它只是噪音；下一次有人改變主意時，這些內容就會錯，而沒人記得刪掉。我正在刻意培養一項技能，好阻止 Claude 把這種模式寫進程式碼庫。
真正的界線在哪裡
機器人審查不是問題，濫用它才是。
當它能提供審查者自己不會想到的角度，或抓出 bug、漏掉的邊界情況、diff 裡真正存在的問題時，它就很有用。那才是真正的第二雙眼睛，真的有幫助。
一旦它讓讀者付出的注意力比它幫忙省下的還多，它就開始失去價值了。審查的目的是把價值送出去，並在人與人之間傳遞知識。程式碼品質之所以重要，是因為它服務於這個目的，而不是反過來。如果某則留言讓程式碼變得稍微更好，卻讓審查者更疲憊，那就不是值得的交換。
算在你頭上
我有一個自己在用的規則。當你送出一則審查留言時，那是算在你頭上的。沒錯，寫碼代理人也許是共同作者……但之後需要跟進的人不是它。程式碼作者接下來要來問問題、或提出異議的，也不是它。是你。PR 作者無從知道這段話是怎麼寫出來的。當然，他們大概知道，尤其如果你把破折號到處亂灑的話。他們會把它當成你的判斷、用你的語氣來讀，並且照你親自逐字打出來那樣看待你。
所以，在按下送出之前，標準應該是這個：你會不會用這樣的長度、這樣的語氣，親自說出這些話？如果答案是否定的，問題不是提示詞不夠好，而是應該編輯。把不是你的部分刪掉。
原文出處：https://dev.to/cseeman/return-on-attention-why-ai-code-reviews-are-wearing-us-out-2hh0
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
