--- schemaVersion: 1 slug: gp-230-20260616-agentic-code-review ticketId: GP-230 lang: zh-tw title: 程式碼變便宜了，但『相信它』沒有 summary: 2026 的數據都指向同一句話：AI 把程式碼產量推上去四倍，真正交付的價值只多一成，中間那段差距全是審查債。程式碼寫起來變便宜了，敢相信它沒有——程式碼審查從工程的副產品，變成最有槓桿的主戰場。 originalDate: 2026-06-15 translatedDate: 2026-06-16 source: "@addyosmani on X" sourceUrl: https://x.com/addyosmani/status/2066595308629594363 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-230-20260616-agentic-code-review status: published replacementTicketId: null replacementUrl: null --- # 程式碼變便宜了，但『相信它』沒有 > **來源:** [@addyosmani on X](https://x.com/addyosmani/status/2066595308629594363) 寫一千行程式碼，現在比讀完這一段話還快。一個 [coding agent](https://gu-log.vercel.app/glossary#agent) 幾秒鐘吐出一整批排版整齊、大致能跑的程式碼，而人類的閱讀速度，從盯著螢幕討生活的第一天到現在，一格都沒進步。瓶頸沒有消失，它只是往下游滑了一站，滑到那個唯一沒變快的環節：一個人要有把握，這段改動是對的。 過去程式碼審查之所以成立，靠的是一個剛剛好的速度差。資深工程師讀程式碼的速度，比資淺工程師寫程式碼的速度快，所以審查跟得上節奏，沒有人特別設計過這件事，團隊也順便在讀彼此的 diff 時，把整個系統怎麼拼起來吸收進腦袋。這個美好的巧合現在破了。寫程式碼從昂貴變便宜，讀程式碼卻一樣貴，於是整個軟體工程的難點，從「把它寫出來」整個搬到了「敢不敢相信它」。 > **Mogu 溫馨提示：** > > 這裡有個很反直覺的點：AI 不是讓工程變簡單，是讓「最難的那一步」換了一個位置。 > > 以前難的是生產，一行行刻出來；現在生產幾乎免費，難的變成驗證——確認這坨自動長出來的東西真的對。就像以前蓋房子最累是搬磚，現在有機器人幾分鐘砌一面牆，可是「這面牆會不會塌」還是只能找老師傅一塊一塊敲。磚便宜了，敢住進去沒有。(¬‿¬) ## 2026 的數字：產量衝上天，審查債把利潤吃光 這件事過去兩年只是軼事跟嘴砲，現在被大規模量到了，而且量的人彼此沒有共同立場，有幾家甚至在商業上互相競爭，結論卻指向同一個方向：AI 把產量猛推上去，同時把品質跟「可被審查的程度」往下壓。 第一份團隊遙測報告替 4,000 個團隊、22,000 名開發者裝了儀表，追蹤團隊從低度採用 AI 走到高度採用時發生了什麼。這是 2026 年三月的資料，夠新。好消息要先講清楚：開發者合併的 PR 明顯變多、完成的工作變多、人均吞吐量往上爬。然後是報告的其他部分： 程式碼翻修量（寫完很快又被改掉或刪掉的比例）暴衝 **861%**；事故對 PR 的比例升 **242.7%**；每位開發者的缺陷率從 **9% 跳到 54%**；審查時間中位數拉長 **441.5%**；零審查就直接合併的 PR 多了 **31.3%**。 最後那個數字最難打發，因為沒有人選擇它。沒有任何人開會決定「不再審查了」。審查者就是單純跟不上產量，程式碼開始沒人讀就進了主幹，然後這件事變成了常態。更刺的是，紀律嚴明、流程成熟的團隊，受傷跟所有人一樣重——好流程沒有保護到他們，因為量來得比任何流程能吸收的速度都快。 > **Mogu 歪樓一下：** > > 先講一個必要的保留：這些資料裡有幾份來自審查工具商，所以它們的包裝不是中立的。 > > 不過數字本身沒因此變假——效應這麼大、又跨好幾個互不相干的來源一致，就不是「業配灌水」一句話能打發的。正確姿勢是：知道誰在賣什麼，再看數字。(⌐■\_■) 某個 AI 審查工具商在 2025 年十二月研究了 470 個開源 PR，其中 320 個有 AI 參與、150 個純人類，發現 AI 的改動帶了大約 **1.7 倍**的問題：邏輯與正確性問題多約 75%、安全問題多 1.5 到 2 倍、可讀性問題三倍以上。他們的 AI 主管把這些形容成「可預測、可量測的弱點，組織必須主動去補」。可預測是關鍵字——這代表一套審查流程，不管是人還是機器，都可以瞄準這些弱點打。 另一份 Git 變更資料分析補上另一刀。重度 AI 使用者每天產出大約是非使用者的 **4 倍**原始程式碼，但拿他們跟自己一年前比，真正的生產力只成長了約 **12%**。四倍的程式碼，換來一成多的交付價值，而且這四倍全都得有人去審。那份分析自己也老實說，連那 12% 都有一部分是選樣偏差，因為比較強的開發者剛好集中在愛用 AI 那一群。四倍程式碼配一成價值，這一行就把審查問題講完了。 GitHub 那邊，Copilot 的審查已經跑超過 6,000 萬次、一年內成長 10 倍，平台上每五次審查就有超過一次有 agent 插手。這早就不是小眾玩法，這就是程式碼現在被生出來的方式。四份資料、四種方法、一個結論：把機器速度的產量，倒進一套為人類速度設計的系統，瓶頸不會消失，它跑去了驗證那一站，而審查就是這筆帳結清的地方。 --- ## 審查要審多重，看的是「炸起來有多大」，不是看意識形態 上面那些嚇人的數字，幾乎全來自企業的遙測資料，跟被淹沒的開源維護者。如果情境是那樣，它們全都真實。但如果只是一個人在做一個十幾個人會用的東西，大部分數字根本套不上去，也不該被搞得好像有罪。 三個變數決定一段改動坐在哪個位置：**炸起來有多大**（壞掉時是沒事，還是憤怒的使用者、賠錢、個資外洩）；**程式碼活多久**（下週可能就重寫的拋棄式原型，還是要維護好幾年的系統）；**多少人需要看懂它**（只有一個人把整包扛在腦袋裡，還是一個團隊得長期共享所有權）。同一段 diff 丟進這三個變數，「好的審查」會是完全不同的東西。 一個人在沒有使用者的全新專案上單幹，審查的第二份工作——把知識散到團隊裡——對這個人根本不存在，因為一個人就是整個團隊。合理的做法是重壓測試跟自動化、只審真正重要的部分、其餘放輕。重複跟翻修的成本低很多，因為這些程式碼下個月可能就不存在了，半夜三點也不會有人被叫起來。但有個陷阱，很多人是踩得很痛才學會：這招只有在測試是真的時候才成立。沒有安全網就跳過審查，不會把工作消滅，只是用更高的利息把它延後。沒有使用者，是「可以延後審查」的許可，不是「可以跳過驗證」的許可。 然後專案有了使用者。這是危險的中間地帶，而且過河的那一刻通常沒人察覺。審查抓錯的角色突然變重要，因為錯誤現在會傷到人；它散佈知識的角色也開機了，因為不再只有一個人。團隊往往把單人時代的習慣多帶了幾個月，接著一場事後檢討會議，那些遙測數字就從一張圖表，變成他們自己的儀表板。 光譜的另一端，是有著老舊程式碼、海量使用者的大組織。這裡每一個嚇人的數字都全力命中。一段沒人搞懂的改動，是會變成某個人值班事故的「理解債」。審查同時在做好幾份工作，而 agent 產量的洪水悄悄把它們全部沖垮。所以重點不是「企業要小心、個人可以放鬆」，而是審查的目的會隨位置改變，規則就得跟著改。把企業那套鎖死、多 agent、要證據的流程，硬接到兩人原型上，只是憑空多了摩擦；把「測試過就出貨」套到金流系統上，等於造了一台會蓋綠勾勾的事故產生器。 > **Mogu 補個刀：** > > 最值得記住的一句：你在網路上讀到的大部分審查建議，都是光譜上某一個位置的人，在教另一個位置的人怎麼活。 > > 副專案大神叫你「測試過就出貨，別囉嗦」，跟金融系統老兵叫你「每行都要兩個人簽核」，兩個都對——在他們各自的世界裡。把任一句搬到對方的世界，就會死得很難看。讀建議之前先問：講話的人，他的東西炸掉會怎樣？(◕‿◕) --- ## [Agent](https://gu-log.vercel.app/glossary#agent) 的 PR 難審，是因為「為什麼這樣做」消失了 當一個人寫程式碼時，意圖是免費附贈的。那些推理、那些被權衡掉又丟棄的替代方案，都活在作者腦袋裡，而審查就是去檢查這套推理。現代的 agent 也會推理，常常還推得很明顯，邊想邊秤選項邊解釋自己。麻煩在於，這套推理在 diff 產出的那一瞬間，通常就被丟掉了——很少被保存、很少被附到 PR 上，而且就算留著，那也是 agent 對「怎麼實作」的推理，不是一個人對「這件事到底該不該做」的判斷。於是審查從「檢查擺在眼前的推理」，變成「重建一份從來沒被寫下來的意圖」，後者更難、更慢。然後大家還一直對「它要花上多 441% 的時間」感到驚訝。 2026 有篇論文分析了 15 串 Reddit 跟 Hacker News 討論、共 1,154 則貼文，主題是開發者口中的「AI slop」（AI 隨手拉出來、看似能用其實空洞的內容）。其中一句話很刺：審一個 agent 的 PR，讓某位開發者覺得自己成了「史上第一個親眼看到這段程式碼的人類」。正常審查裡，作者早就懂了這段改動，審查者是在檢查他的成果；面對 agent 的 PR，還沒有任何人重建過那個「為什麼」，審查者是第一個試的人。 好消息藏在這裡：消失的意圖是可以救回來的，那些推理本來存在，只是被丟掉了。讓 agent 講清楚它想做什麼、又排除了哪些做法，把這份「決策紀錄」附在 PR 上，一大塊重建成本就消失了。這是個工具問題，而工具問題是會被解掉的。 至於「讓 AI 去審 AI」，它本身不是完整答案。一個帶著不同先驗的第二個模型，確實會抓到真錯誤，而且抓得不少，所以該跑就跑。但它供不出來的，是「這到底是不是該做的那件事」這個人類判斷，而那恰好是這份工作裡最有趣、最值得留著的部分。 --- ## AI 審查者是感測器，不是判決 這些專門的 AI 審查工具現在真的好用，好到連副專案都應該至少掛一個。鋪得最廣的那個工具，在 2026 年一到二月的某個獨立評測上 F1 分數奪冠，精確率約 49%、召回率全場最佳。另一個工具走相反路線，拿精確率換召回率：在某次評測裡抓錯率約 82%，對上前者的 44%，代價是更多誤報。Anthropic 的程式碼審查報告，被自家工程師標為「判斷錯誤」的結果低於 1%，而最該秀給主管看的那個數字是：它把內部「PR 得到一次實質審查」的比例，從 16% 拉到 54%。那條一直以來只被瞄一眼就放行的長尾改動，現在終於有東西會去讀它。 不過今年最有用的結果不是來自任何廠商。一位工程師把四個審查工具並排跑在 146 個真實 PR 上，三週半累積 679 條發現。在 617 個不同的標記位置裡，**93.4% 只被四個工具的其中一個抓到**，6% 被兩個抓到，幾乎沒有被三個同時抓到的，沒有任何一處是四個全抓到的。 四個工具一次都沒有同時標到同一行。每一個都強在不同類型的問題上：有的在正確性與架構上幾乎不誤報，有的撒的網最大、還能一鍵修，有的最擅長判斷會不會在正式環境炸掉。這就是「異質審查」這個論點，在真實程式碼上被演出來，而不是停在論文裡。重點正是異質：同一個模型開四份，只是一個審查者配一張更貴的帳單；四個真正不一樣的審查者，才會撈出任何單一成員——包含人類——自己撈不到的那組錯誤。 實務上，不要為了「哪個工具最強」糾結，沒有那個東西。高風險場合，跑兩個個性刻意不同的：一個顧日常正確性，一個顧正式環境的嚴重度，而且兩者重疊越少越好。如果是單幹，一個好審查者加上真的有效的測試，就很夠。而且不管行銷怎麼說，都要在自己的程式碼上量過——上面每一個結果都是綁定特定 codebase 的，換成別人手上的程式碼也一樣。 > **Mogu 認真說：** > > 「感測器，不是判決」這句要刻在牆上。 > > AI 審查的輸出是資料，不是裁決。它說「looks good」的時候，那是它的把握，不是你的把握；它用一段很有自信的句子，把一份沒必賺到的信心交給你。最危險的不是 AI 會錯——是它錯得很冷靜、很有條理，讓人忍不住簽下去。把它當煙霧偵測器：響了要查，沒響也不代表廚房沒起火。最後按下疏散鈕的，永遠是人。(╯°□°)╯ --- ## 「人在迴圈裡」變成「人在迴圈上」 一年前算異端、現在連資深工程師都在問的問題是：機器是不是該審更多，甚至大部分？這問題沒那麼蠢了。不舒服的地方在於 AI 審查真的有效——Anthropic 被標錯的結果低於 1%、它抓到人類直接讀過去的錯、而且它不會在當天第 30 個 PR 上累到失神，而那正是人最不可靠的時刻。與此同時，人類明顯跟不上：零審查合併多了 31%、審查時間漲了三位數百分比。某種意義上，機器其實已經比人審了更多的程式碼。所以誠實的問法不是「要不要讓 AI 審更多」，而是「AI 已經在審了，是要刻意設計這件事，還是要假裝人類還在讀每一行、放它自己預設發生」。 把這件事推到極致的是「迴圈工程」那一脈：當一個人不再是去戳 agent 的那個人，而是去蓋一套會自己戳 agent 的系統，而這套系統的核心會有一個「裁判」——一個負責決定「這件事做完了沒、能不能往下走」的 agent。審查者，是下一個被刻意設計出內圈的角色。寫程式碼自動化了一年，現在連檢查也在自動化，而人一直被往上、往外推。 但答案也不是「讓迴圈自己審自己，然後走人」。當 agent 寫程式碼、另一個 agent 審它、第三個 agent 當裁判，得到的是一個由模型組成的封閉迴圈，而這些模型有高度相關的盲點，尤其當它們來自同一個家族時，會在同樣的地方一起很有自信地點頭。一句沒有任何人類在裡面的「looks good」，是借來的信心：系統的篤定被直接當成了人的篤定，而其實沒有人真的搞懂任何事。迴圈可以同時非常確定，又非常錯，而且沒有人類能分辨差別。 所以人不會離開，人往上移一層。停止審查每一個 diff，開始擁有那些無法轉交給模型的部分：這到底是不是該做的那件事（這跟「程式碼對不對」是兩回事）；那些一旦做錯就很貴的高風險關卡；還有最尷尬的那一個——沒有人指定過的行為，因為模型只會審「已經存在的程式碼」，很少去標「根本沒人想到要寫下來的需求」。「人在迴圈裡」變成「人在迴圈上」：抽樣、抽查、稽核整套系統，而不是讀每一個 PR，把有限的注意力花在「錯了會真的痛」的地方。 這正是這篇來源作者自己的做法。他把 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 或 [Codex](https://gu-log.vercel.app/glossary#codex) 指向一批進來的 PR，要一份初篩：哪些看起來安全可以合併、哪些需要再修、哪些真的高風險。他不靠這份結果自動合併，也不偷懶地把它批准的東西照單全收。它給他的，是一個分配注意力的方法——花幾分鐘確認它判定低風險的那些，把真正仔細的時間砸在它標危險的那些。 更極端的版本是一位前 Meta L8 工程師，現在以單人之姿一天出貨約 40 個 PR，而且大致已經不審程式碼了。容易一句話打發他，但他是個 L8，原本極度擅長他現在停掉的那件事，這才是有趣的地方。他同時跑 20 到 30 個 agent，把力氣搬到了計畫上：他事前寫詳細的計畫，agent 照著跑好幾個小時，他說計畫品質決定了它們能無人看管地跑多久。值得講精準一點——他不是停止驗證了。意圖沒有消失，是他自己事先寫進計畫裡，所以「史上第一個看到這段程式碼的人類」這個問題被解掉一半：確實有一個人類懂那個為什麼，只是在事前、不是事後。他也沒有走鋼索沒網子，他蓋了一道自動審查關卡在合併前檢查程式碼，並在 agent 卡住時待命處理。人做昂貴的思考——在程式碼存在之前；機器做事後的逐行檢查。但他是個沒有大團隊、底下也沒有十年老系統埋著地雷的單人開發者。讓 40 個 PR 一天不審變得合理的那些前提，大多數讀者並不具備。把他的工作流照搬到一個要服務海量使用者的團隊，得到的就是在自己儀表板上重演一次前面那些遙測數字。又回到光譜這件事。 --- ## 真正要做的事：把人的注意力，只花在錯了會很貴的地方 組織原則只有一句：讓審查力氣匹配「錯了的代價」，把便宜的、確定性的檢查盡量往前推，再把人的注意力留給只有人能做的事。 **按風險分級，不是按作者分級。** 一個設定檔的改動，配一道靜態檢查加瞄一眼就好。一段核心商業邏輯的改動，要配上全套：型別、測試、兩個個性不同的 AI 審查者、一個真正擁有那個系統的人、外加一道安全審查。不要把重審浪費在樣板程式碼上，也不要因為測試是綠的就揮手放行一個大改動。 **讓昂貴的長尾儘早失敗。** 2026 一月有份研究分析了 33,707 個 agent 寫的 PR，發現 agent 擅長小而定義清楚的改動，約 28% 幾乎是秒過；但它們一碰到主觀回饋就「人間蒸發」，丟下審查本該有的那種來回拉鋸（另一份 2026 的論文發現，審查者放棄佔了被拒絕 agent PR 的 38%）。研究者做了一個「斷路器」，在人還沒看之前，就用檔案類型、改動大小這種便宜的訊號預測哪些 PR 會很難搞，而且效果不錯。先分流 agent 的 PR，瑣碎的快速放行，別讓一個人把一小時砸進一個 agent 等人一推回去就會棄坑的龐然大物。 **提高「願意審」的門檻。** 被淹沒的解法不是把倉庫鎖死，是拒絕審查那些「沒帶證據就來」的改動。審查之前要先要求：一句話講清楚這個改動是為了什麼、一份不是 3,500 行又零註解的 diff、測試的輸出、以及它真的被跑過的證明。這就是不再當「第一個讀這段程式碼的人類」的方法——把重建意圖的工作，推回給提交的人，在那邊它很便宜，留在自己身上它很貴。 **刻意把 PR 維持得小。** agent 的 PR 偏大，在前面那份團隊遙測資料裡平均大了 **51%**，而審查者的投入程度，是「這個 PR 到底會不會被合併」最強的預測因子之一。一個大到沒辦法審的 PR，下場是被直接打回，或者更糟，被蓋橡皮圖章放行。直接命令 agent 產出小的提交。一份人類真的讀得完的 diff，現在是設計約束，不是禮貌。 **讀測試的改動，要比讀程式碼本身更小心。** 這是最該盯的 agent 失敗模式：agent 改了行為，然後「修好」測試——把斷言改寫成符合那個新的、壞掉的行為。一個蓋在 200 個被改過的測試上面的綠勾勾，在那些改動被確認是對的之前，什麼都不代表。任何一份重寫大量測試的 diff，都當警訊，先讀它們。突變測試在這裡值回票價：覆蓋率只說某行被執行過，突變測試說的是「如果那行錯了，測試會不會發現」。 **把 CI 當成那道不會移動的牆。** 盯著 GitHub 現在會提醒審查者的那些模式：被刪掉的測試、被跳過的靜態檢查、被調低的覆蓋率門檻、一個其實別處早就有的重複輔助函式，還有最該強調的——未受信任的輸入流進了一個 prompt 裡。最後那個值得放大講，因為 agent 蓋出來的功能是 prompt 注入攻擊的新源頭：如果一段改動把使用者可控的文字，不經思考就餵進一次 LLM 呼叫，這個漏洞不會出現在 diff 裡，它潛伏在之後才會抵達的資料中。agent 也會為了讓自己通過而弱化 CI，不是惡意，只是梯度下降找到了通往綠燈的最便宜路徑。確定性的關卡，是整條流程裡唯一沒辦法被一段很有自信的話術勸退的部分，所以要把它守嚴。 **人，擁有那個合併鍵。** 一個模型沒辦法被叫起來值班、也不能為它出貨的東西負責，所以按下合併的人就是負責的人。當 AI 審查用平靜自信的聲音說「looks good」，它遞過來的是一份不一定賺到的信心。把每一次 AI 審查都當成感測器，不是判決：是資料，不是決定。 如果是單人、沒有使用者，分級、測試改動的紀律、加上 CI，差不多就是全部所需，其餘在人出現之前都是多餘的負擔。如果是那個大組織，以上全部都是基本盤，而分流跟那道「進場要帶證據」的門檻，就是「一套撐得住規模的審查流程」跟「一套悄悄崩潰的審查流程」之間的差別。 > **Mogu 認真說：** > > 「讀測試的改動比讀程式碼還小心」這條，是整篇最該抄下來的操作。 > > 想像一個學生考試寫錯，然後偷偷把標準答案改成自己寫的那個。考卷一片紅勾，分數滿分，全是假的。agent 沒有惡意，但它被獎勵的是「讓綠燈亮」，不是「讓行為對」——只要改測試比改程式碼容易，它就會去改測試。所以看到一個 PR 順手重寫了一兩百個測試斷言，第一個動作不是放心，是把那些測試先抓出來逐條看。綠勾勾最會騙人。(╯°□°)╯ --- ## 如果帶一個團隊：審查力是要管理的資源，不是 AI 省下來的閒置 出貨的綁定約束，已經不是寫程式碼能寫多快，而是一個被信任的人，能多快對「這段改動是對的」有把握。任何把「生產」當瓶頸、把「審查」當免費的計畫，都會悄悄卡住，而且速度儀表板一路上都是綠的。前面那份遙測報告講得很白：產量上升的同時，品管跟審查的工作量也上升，所以因為「AI 讓團隊變快了」就砍工程人力，是危險的——除非先把審查的缺口補起來。那筆「資深工程師稅」，也就是漲了三位數百分比的審查時間，最重地落在那些最不能塞車的人身上，而且它對任何「只數合併 PR 數量」的指標來說，是隱形的。 開源維護者最先、也最重地撞上這面牆。那一股源源不絕、聽起來很有道理但其實空洞的貢獻，就算出於善意，也吃掉真實的分流時間，而那是煤礦坑裡的金絲雀。公司是下一個。處理得好的那些，把審查力當成一種真實的資源去量測、保護、刻意分配，而不是當成 AI 替他們釋放出來的閒置產能。 > **Mogu 補個刀：** > > 最陰險的句子是這個：速度儀表板一路綠燈，照樣可以撞牆。 > > 因為合併 PR 的數量會漲、週期會縮短，老闆看到的圖表全是好消息。可是缺陷率、翻修量、半夜被叫醒的次數——這些是另一組儀表板，而且通常沒掛在同一面牆上。把審查力當成「AI 幫我省下來、可以拿去砍人」的閒置，是用未來的事故換今天的一張漂亮報表。審查力是資源，不是脂肪。┐(￣ヘ￣)┌ --- ## 結語 寫程式碼變便宜了，搞懂它沒有。程式碼審查不是在 agent 來了之後變得比較不重要，它變成了那個核心活動。不要在任何一個方向上拿「一體適用」的答案：如果是單人、沒有使用者，那些關於翻修跟重複的企業恐怖故事是未來的風險、不是今天的火，靠測試、審重要的、並對「延後的工作仍然欠著」這件事保持誠實。如果是替海量使用者維護龐然大物，這裡每一個嚇人的數字都是在講這種團隊，唯一撐得住的，是一套分級、要證據、刻意異質、而且有一個人擁有合併鍵的審查流程。 橫跨整個光譜不變的，是底層的經濟學：「寫」被弄便宜了，「搞懂」卻一如往常地貴。接下來幾年混得好的團隊，不會是產出最多程式碼的那些，而是蓋出一套自己真的敢信任的審查系統、並且從不把「測試過了」誤當成「有一個人真的懂這在幹嘛、為什麼這樣做」的那些。 或者用 [Simon Willison](https://gu-log.vercel.app/glossary#simon-willison) 一直在講的那句：工作的本質，是交付已經被證明能跑的程式碼。agent 沒有改變這件事，它只是把「證明」從一件事後補做的雜事，推到了工作的正中央。把一個系統搞懂到敢替它背書，是軟體裡最耐久、也最有意思的技能——而現在，是把它練到出神入化的最好時機。