# 策展 · X (Twitter) 🔥🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Addy Osmani (@addyosmani) · 平台：X (Twitter) · 日期：2026-06-16

> 原始來源：https://x.com/addyosmani/status/2066595308629594363

## 中文摘要

# Agentic 程式開發的程式碼審查 (Code Review)

現在的 Coding Agent 能力極強，且進步神速。這帶來了一個有趣的後果：軟體工程中最困難的部分，已從「撰寫程式碼」轉變為「決定是否信任這些程式碼」。這使得「程式碼審查」成為當前軟體開發中槓桿效益最高的 skill。你該如何應對，取決於你的身分：一個沒有使用者的獨立開發者，與一個維護十年歷史應用程式的團隊，他們面臨的問題截然不同。

我對 Agentic 程式開發的樂觀程度前所未有。這些 Agent 確實好用，每個月都在進步，現在我每週都能交付一些在一年前同樣時間內我根本不敢嘗試的功能。這篇文章是一份地圖，標示出那些有趣的工作轉移到了哪裡，因為它們確實轉移了，而大多數團隊還沒完全跟上這個變化。

過去，程式碼審查之所以有效，是因為一種「相對速度」的幸運巧合。資深工程師閱讀程式碼的速度比初階工程師撰寫的速度快，因此審查過程自然能跟上進度，團隊成員也在閱讀彼此的 diff 時，順帶理解了系統的架構。這其中很多並非刻意為之，而是源於一個事實：撰寫程式碼是緩慢且昂貴的環節，而閱讀程式碼則是廉價且快速的。

這個事實已不復存在。Agent 產生一千行結構良好、格式整齊的程式碼所需的時間，比我讀完這一段文字的時間還短，而人類的閱讀速度自從我們開始靠盯著螢幕維生以來，幾乎沒有改變。因此，瓶頸轉移到了下游，轉移到了唯一沒有變快的那一步：人類必須確認變更內容是正確的。我不認為這是一種損失。這反而是目前軟體開發中，投入心力回報最高的地方，也是我今年投入最多關注的領域。

這裡有一個令人開心的轉折，它塑造了這篇文章的其餘部分。那些產生大量程式碼的工具，同時也是我用來跟上這些程式碼的最佳利器。在我自己的專案（包括熱門的開源專案）中，我現在會讓 Claude Code 或 Codex 處理一批進來的 PR，並讓它們為我進行佇列分流，這確實改變了我分配時間的方式。所以，這不是一篇反對 AI 的文章，我稍後會回到我具體如何使用它的細節。

這也不是一篇資料堆砌文，也不是關於「讓模型撰寫程式碼是好事還是軟體工藝的終結」的陳腔濫調，因為那種框架毫無意義。唯一能在真實程式庫中存活下來的答案是：這完全取決於你是誰。一個正在「vibe-coding」開發一個只有十幾個人會用的副專案的開發者，與一個為了再撐一季而維護十年歷史企業系統的團隊，他們幾乎沒有任何共同的限制條件，而市面上大多數的建議，其實都只是其中一方在教另一方該怎麼過日子。

## 2026 年的數據實際顯示了什麼

AI 帶來的生產力提升是真實存在的，但原始產出誇大了這些效益：大約是四倍的程式碼量，卻只帶來了多出一成的交付價值。這兩個數字之間的差距就是審查工作，這正是為什麼審查現在成為槓桿效益所在的原因。

幾年來，這一直停留在軼事和爭論階段。現在，透過一些沒有共同議程、甚至在某些情況下存在商業競爭關係的組織進行大規模測量，結果始終指向同一個方向：AI 大幅推升了產出，卻同時拉低了品質與可審查性。

Faros AI 對 4,000 個團隊中的 22,000 名開發者進行了監測，追蹤團隊從低 AI 採用率轉向高 AI 採用率後的變化。這是 2026 年 3 月的數據，與本文內容相當同步。其正面效益是真實的，且值得明確指出：開發者合併了更多的 PR，完成了更多工作，每位工程師的吞吐量也隨之攀升。但報告的其餘部分如下：

- 程式碼變動率 (code churn) 上升 861%
- 事件與 PR 的比例上升 242.7%
- 每位開發者的缺陷率從 9% 上升至 54%
- 中位數審查時間上升 441.5%，首次審查時間與平均審查時間大約都翻了一倍
- 零審查直接合併的 PR 上升 31.3%

最後一個數據是我覺得最難以忽視的，因為沒人選擇這麼做。沒有人決定要停止審查。審查者只是無法跟上數量，所以程式碼開始在未經閱讀的情況下被合併，這變成了一種常態。我反覆思考的細節是，那些擁有成熟、嚴謹工程實踐的團隊，受到的衝擊與其他團隊一樣大。良好的流程並沒有保護他們，因為產出的數量增加速度，遠超任何流程設計所能負荷的程度。

這裡有一個需要全程銘記的警示：CodeRabbit 和 Faros 都在銷售相關產品，因此他們的觀點並非完全中立。這並不代表數據是錯的，這些效應在不相關的來源中規模巨大且一致，但閱讀廠商的研究報告時，仍應將此納入考量。

CodeRabbit 在 2025 年 12 月研究了 470 個開源 PR，其中 320 個由 AI 共同撰寫，150 個僅由人類撰寫，發現 AI 變更帶來的問題大約多出 1.7 倍：邏輯與正確性問題增加了約 75%，安全性問題常見程度增加 1.5 到 2 倍，可讀性問題則增加了兩倍以上。他們的 AI 總監 David Loker 將這些描述為「組織必須主動緩解的、可預測且可衡量的弱點」。關鍵字是「可預測」。這些是已知且可定位的弱點，這是一個好消息：這意味著無論是人類還是自動化的審查流程，都可以直接針對這些弱點進行優化。

GitClear 在這裡也有有趣的數據。在他們 2025 年的生產力數據中，AI 的日常使用者產出的原始程式碼量約為非使用者的 4 倍，但與他們一年前的產出相比，實際的生產力提升僅約 12%。你產生了約四倍的程式碼，卻只帶來了約一成的交付價值，而人類仍然必須審查這四倍的程式碼。GitClear 的 Bill Harding 明確表示，這 12% 的提升中，部分源於選擇偏差，因為更強的開發者更集中在 AI 使用者群體中。四倍程式碼與一成價值之間的差距，就是程式碼審查問題的精確寫照。

GitHub 報告稱，Copilot 審查功能目前已執行超過 6,000 萬次審查，在不到一年內成長了 10 倍，平台上超過五分之一的審查涉及 Agent。這已不再是小眾做法，而是程式碼產出的方式。

四個資料集、四種方法，得出同一個結論。我們將機器速度的產出傾倒進一個為人類速度工作而建構的系統中。瓶頸並沒有消失；它轉移到了驗證階段，而審查就是這筆帳單到期的地方。

## 每個人都在解決不同的問題

一個變更需要多少審查，幾乎完全取決於它的「爆炸半徑」(blast radius)，而你讀到的大多數建議，都是由處於完全不同環境的人所寫的。

上述幾乎所有令人震驚的數據，都來自企業遙測資料以及不堪重負的開源維護者。如果你的情況正是如此，這些數據完全真實。如果你是一個人在開發某個只有少數人會用的東西，其中大部分內容根本不適用於你，你不應該因此感到焦慮。

三個變數決定了你的處境：

- **爆炸半徑**：出錯時會發生什麼？沒事，還是會導致使用者憤怒、金錢損失以及個人身分資訊 (PII) 外洩。
- **程式碼壽命**：是一個下週可能就會重寫的拋棄式原型，還是一個你將維護多年的程式庫。
- **需要理解的人數**：只有你一個人能掌握全貌，還是一個需要長期共同維護的團隊。

將同一個 diff 套入這三個變數中，「良好的審查」意味著完全不同的事情。

如果你是在一個沒有使用者的綠地專案 (greenfield project) 上獨自工作，審查的第二項工作——在團隊間傳遞知識——對你來說就不存在。你就是團隊。

合理的做法是大力依賴測試與自動化，審查真正重要的部分，並對其餘部分採取較寬鬆的態度。當程式碼可能一個月後就不存在，且出錯時不會有人在凌晨三點被叫醒時，重複與變動的成本要低得多。陷阱在於（人們通常會痛苦地學到這一點），這只有在測試是真實有效的情況下才行得通。在沒有安全網的情況下跳過審查並不會消除工作，它只是以更高的代價延後了工作，且當沒有人把關時，標準就會下滑。沒有使用者是你可以延後審查的許可，但不是你可以跳過驗證的許可。

接著，專案有了使用者。這是一個危險的中間地帶，且轉折點通常在當時很難被察覺。審查的「抓蟲」角色突然變得重要，因為 Bug 現在會傷害到人；而它的「知識共享」角色也隨之啟用，因為現在不再只有你一個人。團隊往往在 solo 時代的習慣上多停留了幾個月，然後就會發生一次事後檢討 (postmortem)，Faros 的數字就不再只是圖表，而成了他們自己的儀表板。

另一端是擁有舊程式庫和大量使用者的龐大組織。在這裡，每一個令人震驚的數字都會產生全面影響。一個沒人理解的變更，就是一種理解債務，最終會變成某人的值班事件。審查同時在執行多項任務，而 Agent 的產出量悄悄地破壞了所有這些任務。Faros 關於成熟團隊的發現，正是針對此處。

所以重點不是「企業應該謹慎，獨立開發者可以放鬆」。重點是審查的目的會隨著你的位置而改變，因此規則也必須隨之改變。將企業那種鎖定、多 Agent、要求證據的管線套用在一個兩人的原型上，只會增加摩擦力而毫無益處。在支付系統上執行「測試通過就發布」，等於是製造了一個頭頂綠色勾勾的事件產生器。這個領域中大多數糟糕的建議，都是光譜上某個位置的人在對另一個位置的人指手畫腳。

## 審查現在真正的用途是什麼

審查原本是為了檢查作者的推理並抓出 Bug，同時與團隊分享知識。Agent 確實會推理，但這些推理通常在產出後就被丟棄，而不是附在程式碼上，因此審查者必須重新構建那些從未進入 diff 的邏輯。好消息是：這是一個工具問題，捕捉這些推理會讓審查變得容易得多。

這是真正改變的部分，我認為它被低估了。

當人類撰寫程式碼時，意圖是隨之而來的。推理過程、權衡與捨棄的替代方案，都存在於作者腦中，而審查就是你在檢查這些推理。現代 Agent 確實會推理，通常還很明顯，它們會產生思考軌跡、權衡選項並在過程中解釋自己。問題在於，這些推理通常在 diff 產出的瞬間就被丟棄了。它們很少被捕捉、很少附在 PR 上，而且無論如何，這是 Agent 關於如何實作任務的推理，而不是人類關於「這是否為正確任務」的判斷。因此，審查從「檢查眼前的推理」轉變為「重建從未寫下的意圖」，這更困難且更慢，而我們卻一直對它需要多花 441% 的時間感到驚訝。

一篇 2026 年的論文《AI Slop and the Software Commons》分析了 Reddit 和 Hacker News 上 15 個討論「AI 垃圾內容 (AI slop)」的執行緒中 1,154 則貼文。其中一位開發者的一句話引起了我的注意：審查 Agent 的 PR 讓他們成為「第一個看到這段程式碼的人類」。

這直接指出了修正方向。在正常的審查中，作者已經理解了變更，而你是在檢查他們的工作。在 Agent 的 PR 中，還沒有人重建過「為什麼要這樣做」。審查者是第一個嘗試的人。

正如論文所言，審查「並非為了恢復缺失的意圖而建構」。令人鼓舞的是，缺失的意圖是可以恢復的：推理過程曾經存在，我們只是把它丟棄了。讓 Agent 陳述它試圖做什麼以及排除了什麼，將其作為決策日誌捕捉在 PR 上，重建成本的大部分就會消失。這是一個工具問題，而工具問題是可以被解決的。

這一切並不代表「讓 AI 審查 AI」本身就是完整的答案。另一個具有不同先驗知識的模型確實能抓出真實的 Bug，而且抓得很多，這就是為什麼你應該執行一個的原因。它無法提供的是人類對於「這是否為正確變更」的判斷。這種判斷仍然掌握在人類手中，而這恰好是工作中這份工作最有趣、最值得保留的部分。

## 工具很好，但原因往往與廣告宣稱的不一樣

目前的 AI 審查工具確實很好，而且它們偶爾不會標記出相同的行數，所以正確的做法不是挑選最好的一個，而是執行兩個架構不同的工具。

專用的 AI 審查工具現在已經很成熟，我認為你應該在所有專案（包括副專案）上至少執行你的主要 Coding Agent，如果不是專用的審查 Agent 的話。

CodeRabbit 是目前部署最廣泛的工具，並在獨立的 Martian 基準測試（2026 年 1 月至 2 月）中名列 F1 分數榜首，精確度約 49%，且擁有該領域最好的召回率。Greptile 則是用精確度換取召回率：在某項基準測試中，其 Bug 捕捉率約為 82%，而 CodeRabbit 為 44%，代價是更多的誤報。Anthropic 的 Code Review 報告稱，其工程師標記為錯誤的發現不到 1%，這是我會展示給經理看的數據：它將內部 PR 獲得實質審查的比率從 16% 提升到了 54%。那些過去只會被掃一眼就批准的長尾變更，現在終於有人（或某種東西）閱讀了。

我今年看到最有用的結果並非來自廠商。一位工程師在三週半的時間裡，對 146 個真實 PR 和 679 個發現結果，並行執行了四個審查工具：CodeRabbit、Sentry Seer、Greptile 和 Cursor BugBot：

> 在 617 個不同的標記位置中，93.4% 僅被其中一個工具捕捉到。6% 被兩個捕捉到。幾乎沒有被三個捕捉到的。沒有任何一個被所有四個同時捕捉到。

這四個工具從未標記過同一行。每一個在不同類型的問題上都很強：Greptile 在正確性和架構上幾乎零誤報，CodeRabbit 擁有最廣的覆蓋範圍和一鍵修復功能，Seer 在生產環境故障嚴重性上表現最好。這就是在真實程式庫而非論文中演示的「對抗式審查」論點。異質性才是重點。四個相同模型的副本只是一個帳單更高的單一審查者，而四個真正不同的審查者能發現單一成員（包括人類）無法發現的 Bug 集合。

實務上：不要糾結於單一最好的工具，因為根本沒有。在高風險端，執行兩個刻意具有不同特性的工具（上述實驗將 Greptile 用於日常正確性，Seer 用於生產環境故障嚴重性，幾乎沒有重疊）。如果你是獨立開發者，一個好的審查者加上真實的測試就足夠了。無論行銷文案怎麼說，請在自己的程式碼上進行測量，因為這些結果中的每一個都是針對特定程式庫的，你的情況也會如此。

## 我們應該讓 AI 審查更多程式碼嗎？

機器已經在審查比你更多的程式碼了。唯一剩下的真正決定是，你是否要刻意為之，而你保留的人類審查比例應該隨著你的爆炸半徑而擴展。

我一直聽到一個一年前會被視為異端邪說的問題，現在卻出自經驗豐富的工程師之口：機器是否應該進行更多的審查，甚至大部分的審查？我不再認為這是一個愚蠢的問題。

令人不安的部分是，AI 審查確實有效。Anthropic 的發現中不到 1% 被標記為錯誤，工具能抓出人類直接略過的 Bug，而且它們在一天處理第三十個 PR 時也不會疲勞，而這正是人類最不可靠的時候。同時，人類顯然跟不上進度：零審查合併增加了 31%，審查時間增加了三位數。從真實意義上講，機器已經在審查比我們更多的程式碼了。誠實的框架不是「我們是否應該讓 AI 審查更多」，而是「AI 已經在做了，我們是要刻意規劃，還是讓它預設發生，同時假裝人類還在閱讀一切」。

Loop 程式開發強化了這一點。Loop 的前提是你不再是那個提示 Agent 的人，而是建構一個提示它的系統，而該系統的核心部分是一個判斷者：一個在繼續下一步之前決定工作是否完成的 Agent。審查者是下一個被刻意從內部 Loop 中設計出去的角色。我們花了一年時間自動化撰寫，現在 Loop 正在自動化檢查，而人類不斷地被向上推擠並排除在外。「人類待在哪裡」不是研討會問題，這是你每次連接 Loop 時都會做出的決定，無論你是否意識到你在做決定。

我目前的結論是：答案可能不是「人類閱讀每一行」。那已經結束了。但也不是「讓 Loop 自己審查然後走開」。當一個 Agent 撰寫程式碼，另一個審查它，第三個判斷它時，你就擁有了一個模型閉環，它們有著廣泛相關的盲點，特別是當它們來自同一個家族時，它們會在同樣的地方自信地達成共識。一個沒有人類參與的自信「看起來不錯」，是借來的自信：系統的確定性變成了你的，但實際上沒人理解任何事情。Loop 可以既非常確定又非常錯誤，而沒有人類能分辨出差別。

所以人類不會離開；人類會提升到一個層級。你不再審查每一個 diff，而是開始負責那些無法轉移給模型的部份。當責 (Accountability) 很重要。

判斷這是否為正確的變更（區別於程式碼是否正確）。在高爆炸半徑的門檻處，犯錯的代價很高。還有一個尷尬點：沒人定義的行為，因為模型會審查現有的程式碼，卻很少標記出沒人想到要寫下的需求，這仍然是一個我預計短期內無法填補的人類缺口。

Human in the loop 變成了 Human on the loop：進行抽樣、抽查和審計系統，而不是閱讀每一個 PR，並將你有限的注意力花在犯錯會真正造成傷害的地方。

這已經是我在自己專案上的工作方式，包括那些一天收到的 PR 比我一晚上能仔細閱讀的數量還多的開源專案。

我會讓 Claude Code 或 Codex 處理一批進來的 PR 並進行初步篩選：高層次地閱讀哪些看起來可以安全合併，哪些需要更多工作，哪些是真正的高風險。我不會對結果進行自動合併，也不會懶惰地合併它批准的任何東西。它給了我一種分配注意力的方法。

我可以花幾分鐘確認它認為低風險的變更，並將真正、仔細的時間花在它標記為危險的變更上。重要的細節在於，這不是我舊的審查時間變得稍微快了一點。這是一種不同形狀的時間，而在我現在處理的數量下，這是佇列能維持生存的主要原因。

![這是一份關於 GitHub 專案 Pull Request 自動化審核與分類的報告文件截圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/722f430f2ac591e6.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">左側文件標題為「Review of the latest 20 pull requests」，日期為 2026 年 6 月 14 日，針對 main 分支進行審核。內容分為「Merge now」（立即合併）與「Hold or request changes」（暫停或請求變更）兩部分，列出 PR 編號、建議與原因。

右側文件標題為「Ran 4 agents」，顯示四個代理程式已審核完 20 個 PR。分類如下：
- 「Safe to merge (7) — small, correct, low-risk」：
  - #260: move agents/README.md -&gt; docs/agents.md (fixes #258)
  - #255: validator reports fs errors as structured output
  - #283: add missing /code-simplify row to getting-started table
  - #276: make simplify-ignore-test.sh executable (chmod)
  - #275: standardize actions/checkout to v6 across CI jobs
  - #269: path fallback for manual install in hooks.json
  - #268: include /webperf in setup command lists
- 「Close (1)」：
  - #267: "Add X data workflows skill" — vendor promo, not an engineering skill.
- 「Consider — needs a real review, don't quick-merge (10)」：
  - #250: skill-router meta-skill
  - #242: slash-commands skill
  - #253: harness-engineering skill

畫面展示了自動化代理程式如何透過分析程式碼差異（diff）、GitHub 檢查狀態及本地驗證腳本，對開發者的 PR 進行分類與風險評估。</div></details>

📷 Codex 和 Claude Code 為我提供了一批 PR 的初步、風險排序的閱讀結果。分流才是真正的幫助。合併決定權仍然在我手中。

同樣做法的一個更極端版本是 Kun Chen，一位前 Meta L8 工程師，現在作為獨立開發者每天交付約 40 個 PR，他已基本停止了審查程式碼（如 @petergyang 所述）。這很容易被忽視，但他是一位 L8，在他停止做的事情上異常出色，這正是它有趣的地方。他並行執行 20 到 30 個 Agent，並將精力轉移到了計畫上：他預先撰寫詳細的計畫，Agent 針對計畫執行數小時，他說計畫的品質決定了它們能無人值守執行多久。這就是我上面描述的做法。精確描述實際發生的事情很重要，因為他並非停止了驗證。意圖並沒有消失，他自己將其寫在計畫中，所以「第一個看到這段程式碼的人類」問題解決了一半：人類確實理解了為什麼，只是在事前而非事後。而且他並非在沒有網的情況下工作，他建立了一個自動化審查門檻（他稱之為 No Mistakes），在合併前檢查程式碼，並在 Agent 卡住時保持升級處理。人類在程式碼存在之前進行昂貴的思考，機器在之後進行逐行檢查，這很可能就是未來發展的形態。

但他是一位沒有大型團隊、腳下沒有埋著地雷的十年系統的獨立開發者。讓他每天 40 個 PR 而無需審查的確切條件，是大多數讀者所不具備的。將他的工作流程複製到一個發布給許多使用者的團隊，你就會在自己的儀表板上重現 Faros 的數字。他沒有錯；他只是處於光譜中特定一端的很遠處。

這又回到了光譜的問題。獨立開發且沒有使用者：讓 AI 審查幾乎所有內容是一個站得住腳的 2026 年立場，你不必為此感到內疚。維護大型系統且有許多使用者：讓機器處理初步篩選、二次篩選和無聊的 90%，但在承重路徑上保留一個真正的人類，且不要讓 Loop 在任何可能傷害到人的地方完全閉合。你保留多少人類是一個撥盤，你根據爆炸半徑來設定它，而不是根據愧疚感。

## 實際上該怎麼做

停止以相同的深度審查所有內容。只將稀缺的人類注意力花在犯錯代價高昂的地方，讓廉價的確定性門檻和 AI 審查者處理其餘部分。

組織的核心概念是將審查工作與犯錯成本相匹配，盡可能早地推動廉價的確定性工作，並為只有人類能做的事情保留人類注意力。

按風險分級，而不是按作者分級。配置變更只需 Linter 和一眼掃過。核心業務邏輯路徑的修訂則需要完整的堆疊：型別、測試、兩個不同的 AI 審查者、負責該系統的人類，以及安全性檢查。不要在樣板程式碼上花費繁重的審查，也不要因為測試是綠色的就對重大變更揮手放行。分層方法在任何地方都一樣；不同的是給定的 diff 必須通過多少層。

快速失敗昂貴的長尾。對於淹沒在 Agent PR 中的團隊來說，最近最有用的發現是《Early-Stage Prediction of Review Effort》（2026 年 1 月），該研究分析了 33,707 個由 Agent 撰寫的 PR。Agent 擅長小型、定義明確的變更，約 28% 會立即合併，但它們往往在收到主觀回饋時「消失」，放棄了審查本應有的來回溝通。（另一篇 2026 年的論文發現，審查者放棄佔了被拒絕 Agent PR 的 38%。）研究人員建立了一個「斷路器」，在人類查看之前，透過檔案類型和 Patch 大小等廉價訊號預測高維護成本的 PR，效果很好。預先對 Agent PR 進行分流，快速處理瑣碎的 PR，不要讓人在 Agent 一旦你推回就會放棄的龐大變更上浪費一小時。

提高你願意審查的門檻。被淹沒的解決方案不是鎖定儲存庫，而是拒絕審查沒有證據的變更。在審查前要求：變更目的的陳述、不是 3,500 行且沒有註解的 diff、測試輸出，以及它確實被執行過的證明。這就是你如何停止成為第一個閱讀程式碼的人類。你將意圖重建的工作推回給提交者（在那裡成本很低），而不是自己吸收（在那裡成本很高）。

刻意保持 PR 的小型化。在 Faros 的數據中，Agent PR 平均大 51%，而審查者的參與度是 PR 是否合併的最強預測指標之一。一個龐大且無法審查的 PR 會被直接拒絕，或者更糟的是，被草率批准。指示你的 Agent 產生小的 Commit。人類能真正閱讀的 diff 現在是一個設計限制，而不是一種禮貌。

閱讀測試變更要比閱讀程式碼更仔細。這是需要注意的 Agent 失敗模式。Agent 改變了行為，然後透過重寫斷言來「修復」測試，以匹配新的、錯誤的行為。在 200 個編輯過的測試上顯示綠色勾勾，在確認編輯正確之前毫無意義。將任何重寫大量測試的 diff 視為警示並優先閱讀。突變測試 (Mutation testing) 在這裡很有價值：覆蓋率告訴你某一行被執行了，突變測試則告訴你如果該行錯誤，測試是否會發現。

將 CI 視為不會移動的牆。注意 GitHub 現在警告審查者的模式：移除的測試、跳過的 Lint、降低的覆蓋率閾值、重複的 Helper，以及流入 Prompt 的不受信任輸入。最後一點值得強調，因為 Agent 建構的功能是 Prompt Injection 的新來源：如果變更在沒有考慮文字可能指示模型做什麼的情況下，將使用者控制的文字傳入 LLM 呼叫，漏洞在 diff 中是不可見的，它潛伏在稍後會到達的資料中。Agent 也會削弱 CI 以讓自己通過，這不是惡意的，只是梯度下降找到了通往綠色的最廉價路徑。確定性門檻是管線中唯一不能被自信的段落說服的部分，所以請保持它們的嚴格性。

人類擁有合併權。模型無法被呼叫，也無法對其發布的內容負責，所以誰點擊合併，誰就擁有它。當 AI 審查以冷靜、自信的聲音說「看起來不錯」時，它正在傳遞給你它未必贏得的自信。將每一次 AI 審查視為感測器，而不是判決：它是資料，不是決策。

如果你是沒有使用者的獨立開發者，分級、測試變更紀律和 CI 就是你所需的大部分內容；其餘的在使用者出現之前都是開銷。如果你是大型組織，所有這些都是基準，而分流和接收門檻是審查流程能否擴展與悄悄崩潰之間的區別。

## 如果你經營一個團隊，這意味著什麼

瓶頸不再是撰寫程式碼的速度，而是受信任的人類能多快對審查產生信心。因為「AI 讓我們變快了」而裁減提供這種信心的人員，只會將節省的成本轉化為未來的事件。

發布的約束條件不再是你撰寫程式碼的速度。而是受信任的人類能多快對變更正確產生信心。任何將生成視為瓶頸、將審查視為免費的計畫都會悄悄停滯，而速度儀表板卻始終保持綠色。

Faros 報告對此非常直接：QA 和審查工作隨著產出增加而增加，因此除非你先縮小了審查差距，否則因為「AI 讓我們變快了」而減少工程人力是危險的。資深工程師稅（審查時間增加三位數）對你最無法承受瓶頸的人員打擊最大，而且對於任何只計算合併 PR 的指標來說，它是不可見的。

開源維護者最先且最嚴重地撞上了這堵牆。即使是出於好意的合理但空洞的貢獻，也會消耗真實的分流時間，這就是金絲雀。企業是下一個。處理得好的公司將審查能力視為一種需要測量、保護和刻意花費的真實資源，而不是 AI 釋放出的閒置空間。

## 撰寫變廉價了，理解卻沒有

當 Agent 到來時，程式碼審查並沒有變得不重要。它變成了核心活動。撰寫程式碼的問題日益被解決，且每個月都在變得更便宜；持久的優勢在於讓你信任所寫內容的系統。

不要在任何方向上採取一刀切的答案。如果你是沒有使用者的獨立開發者，關於變動和重複的企業恐怖故事是未來的風險，而不是今天的火災，所以依賴你的測試，審查重要的事情，並誠實面對延後的工作仍然欠著。如果你為許多人維護大型系統，這裡的每一個驚人數字都與你有關，唯一能站得住腳的是一個分層、要求證據、刻意異質化的審查流程，並由人類擁有合併權。

在整個光譜中保持不變的是潛在的經濟學。我們讓撰寫變廉價了，而理解的成本卻始終如一。未來幾年表現出色的團隊不會是產生最多程式碼的團隊，而是那些建構了他們真正能信任的審查系統，且從不將「測試通過」與「有人理解這做了什麼以及為什麼」混為一談的團隊。

或者，正如 @simonw 一直強調的，你的工作是交付你已證明有效的程式碼。Agent 並沒有改變這一點。它們使「證明」成為工作的核心，而不是事後補救，我認為這是一個很好的交易。

將系統理解到足以為其背書的程度，是軟體開發中最持久且最有趣的 skill，現在正是成為這方面頂尖專家的最佳時機。

## 標籤

Agent, Skills, 教學資源, Agentic Workflow