本文是「智慧體軟體工程」系列的一部分。上一篇：智慧體軟體工程 ｜ 別再用人類的尺子量 AI 的活了：智慧體原生工作估算。
「人工古法編程死於 2025 年。人工肉眼程式碼審查將死於 2026 年。」 — Ankit Jain, Latent Space, 2026.03.02
一場註定失敗的戰爭
2026 年 3 月，Latent Space 發表了一篇標題極其激进的文章：《How to Kill the Code Review》[1]。文章援引 Faros AI 對超過 10,000 名開發者、1,255 個團隊的數據分析，畫出了一張令人不安的圖表：
- 高 AI 採納率團隊的任務吞吐量提升 21%
- PR 合併率暴漲 97.8%
- 但Review 中位時間也暴漲 91.1%
這組數據描述的是一個經典的生產 - 消費失衡：AI 把程式碼生產速度拉到了指數曲線上，而人類 Review 能力仍然趴在線性甚至固定的水平線上。兩條曲線必然交叉，而交叉點就是系統崩潰點。
GitHub 的Octoverse 報告[2]進一步證實了這個趨勢：到 2025 年底，月度程式碼推送突破 8200 萬次，合併 PR 達 4300 萬，約 41% 的新程式碼由 AI 輔助生成。與此同時，Addy Osmani 的研究顯示，AI 生成的 PR 體積增長約 18%，每個 PR 的事故率上升約 24%，變更失敗率上升約 30%。
問題的嚴重性不僅在於量的失衡，更在於質的惡化。CodeRabbit[3] 對 470 個 PR 的分析發現，AI 編寫的程式碼平均每個 PR 產生 10.83 個問題，而人工編寫的只有 6.45 個。AI 生成的程式碼在邏輯錯誤上的發生率是人類的 1.4-1.7 倍，在可讀性問題上的差距更大。AI 程式碼看起來整潔一致，但經常違反本地程式庫的命名約定、架構模式和慣例。
換句話說：AI 生成了更多、更大、更難審查的程式碼變更，而人類 Review 的能力並沒有相應增長。這是一場註定失敗的戰爭。
但大多數人對此的反應是錯誤的。他們要么試圖「用 AI 輔助人做 Review」（本質上還是人在讀程式碼），要么試圖「用 AI 做第一輪篩選，人做最終審批」（瓶頸只是略微後移）。這些方案都沒有觸及問題的根本。
要真正解決這個問題，我們需要回到第一性原理。
第一性原理拆解：Code Review 到底在解決什麼問題？
Code Review 不是目的，是手段
Code Review 從來不是一個「目的」，而是一個實現手段。它真正要解決的問題只有一個：
「怎麼確保進入生產環境的變更不會搞砸系統？」
但在幾十年的實踐中，這個簡單的目的被附加了越來越多的功能。今天的 Code Review 實際上同時承載著五個完全不同的職能：
| 職能 | 本質問題 | 典型表現 |
|---|---|---|
| 正確性驗證 | 程式碼做的對不對？ | 審查邏輯、邊界條件、錯誤處理 |
| 安全性檢查 | 有沒有漏洞？ | 審查認證、授權、輸入校驗 |
| 架構一致性 | 符不符合系統設計？ | 審查模組邊界、依賴關係、設計模式 |
| 知識傳遞 | 團隊成員互相了解程式碼庫 | 通過 Review 學習其他人的程式碼 |
| 規範合規 | 風格、命名、約定 | 程式碼格式、命名規範、文件要求 |
第一性原理的核心洞察是：
這五個功能並不需要綁在同一個流程裡，更不需要綁在「人眼逐行讀 diff」這個特定動作上。
這就像早期的手機把電話、相機、音樂播放器、導航儀捆綁在一起是因為便利，但每個功能的最優解是獨立演進的。Code Review 把五個功能捆綁在一起，只是因為在人工編碼時代，這是成本最低的妥協方案。
三個隱含假設的瓦解
傳統 Code Review 建立在三個隱含假設之上，而這三個假設在 AI Coding 時代正在同時瓦解：
假設一：「讀程式碼是驗證正確性的最佳方式」
這個假設從來就不太站得住腳。人眼 Review 發現缺陷的能力大約在 60-70%，而且 Review 品質隨 diff 大小急劇衰減。當 diff 超過 400 行時，Review 效果趨近於零。我們只是因為沒有更好的替代方案而接受了這個現實。
但現在我們有了更好的替代方案：形式化驗證、屬性測試、模糊測試、合約檢查。這些確定性手段的驗證能力遠超人眼掃描。
假設二：「程式碼是需要長期維護的核心資產」
當一個模組需要三個月編寫、半年維護時，每一行程式碼都是投資，當然需要仔細審查。但當 AI 能在 30 分鐘重寫整個模組時，程式碼的性質發生了根本變化。它從「需要精心維護的長期資產」變成了「可隨時重新生成的一次性製品」。
真正的長期資產不再是程式碼本身，而是規格說明（Spec）。這正是 StrongDM Attractor[4] 框架的核心哲學：
「Code must not be written by humans. Code must not be reviewed by humans.
程式碼變成了 Spec 的編譯產物。你不會去逐行審查編譯器輸出的組合語言，同樣的道理。
正如 Obsidian 團隊在 2023 年的承諾一樣：軟體易逝，檔案比應用程式更重要的理念進行開發。
「Obsidian 對外承諾永遠不發展到超過 12 個人，永不接受風險投資，永不收集個人數據和分析數據。持續秉持軟體易逝，檔案比應用程式更重要的理念進行開發，使用開放且持久的格式。」
這套 File over App 的哲學，在 AI 時代正好和我們的理念不謀而合。這套承諾本身很加分，但它最厲害的地方不在「他們保證永遠怎樣」，而在於「就算他們將來不怎樣了，你（用戶）也能體面撤退」。
這才是「檔案優先/ Spec 規格」真正的優勢。
假設三：「品質檢查必須發生在程式碼完成之後」
這是傳統「事後檢驗」思維的典型表現。第一性原理告訴我們一個製造業早已證明的真理：品質應該內建（built-in）而不是檢測出來（inspected-in）。
W. Edwards Deming（現代品質管理之父）在半個世紀前就說過："Cease dependence on inspection to achieve quality"。軟體行業在 CI/CD 上已經接受了這個思想，但在 Code Review 上卻還停留在「事後審批」模式。
驗證非對稱性：被忽視的根本性質
在我上一篇關於 [AI Native 任務估算] 的文章中，我提出了一個核心概念：人工時間錨定偏差。經驗豐富的開發者（和在人類內容上訓練的 LLM）會不自覺地用人類時間線來錨定 AI 任務估算。
在 Code Review 領域，存在一個完全類似的偏差，我稱之為 "審查時間錨定"：
「我們假設審查一段程式碼所需的時間應該與編寫它所需的時間成正比。當人類花一天寫的程式碼，人類花兩小時審查，比例大約 1:4 到 1:8。但當 AI 花 5 分鐘生成同等量級的程式碼時，我們的直覺仍然告訴我們應該花兩小時審查。這不是效率問題，這是度量框架錯誤。」
但更深层的洞察是驗證非對稱性（Verification Asymmetry）：
驗證一個結果是否正確的成本，在本質上遠低於生成該結果的成本。
這個性質在數學中表現為 P ≠ NP 猜想，在密碼學中表現為哈希驗證 vs 碰撞攻擊，在軟體工程中表現為：運行一組測試（毫秒級）遠比編寫被測程式碼（小時級）快。
理解了這個非對稱性，Code Review 的未來方向就清晰了：我們不應該讓人（或 AI）去「理解」程式碼然後判斷它是否正確，而應該構建確定性的驗證系統，讓正確性成為一個可以被機器快速檢驗的屬性。
從 Review Code 到 Review Intent：範式遷移
審查點上移：從程式碼層到意圖層
傳統 Code Review 的審查點在程式碼層：
人寫程式碼 → 人 Review 程式碼 → 合併 → 部署在 AI Coding 時代，正確的審查點應該上移到意圖層：
人寫 Spec → AI 生成程式碼 → 機器驗證程式碼滿足 Spec → 人驗收最終結果這個遷移不是「讓 AI 幫人做 Review」，而是根本性地改變了人類在流程中的角色：
- 舊角色：程式碼的審查者（Did you write this correctly?）
- 新角色：意圖的定義者（Are we solving the right problem with the right constraints?）
人類的判斷力不應該浪費在「這個 for 迴圈的邊界條件對不對」這種機器可以完美驗證的問題上，而應該聚焦在「我們是否在解決正確的問題」、「約束條件是否完備」、「驗收標準是否覆蓋了關鍵場景」這些只有人類才能判斷的高階問題上。
Latent Space 文章中的核心觀點與此完全一致：
「Human-in-the-loop approval moves from "Did you write this correctly?" to "Are we solving the right problem with the right constraints?" The most valuable human judgment is exercised before the first line of code is generated, not after.
Spec 成為控制面
在智慧體軟體工程的框架中，我們需要重新定義三個平面的角色：
- 控制面（Control Plane）：Spec，定義「做什麼」和「怎樣算對」
- 數據面（Data Plane）：Code，Spec 的編譯產物
- 執行面（Execution Plane）：Agent，將 Spec 轉化為 Code 的執行者
在這個架構下，Review 的對象從程式碼變成了 Spec。為什麼這是合理的？因為 Spec 具有程式碼不具備的幾個關鍵特性：
Spec 的資訊密度遠高於程式碼。 一條 "所有金額必須使用 Money 類型，精度為小數點後兩位" 的 Spec 規則，對應的程式碼實現可能分散在幾十個檔案、幾百行程式碼中。Review 一條 Spec 規則比 Review 它對應的所有程式碼實現高效得多。
Spec 的驗證可以自動化。 一旦 Spec 被形式化（哪怕只是半形式化），它就可以變成自動化驗證規則。程式碼是否滿足 Spec，可以通過測試、靜態分析、合約檢查等確定性手段來驗證，不需要人類的主觀判斷。
Spec 的變更頻率遠低於程式碼。 業務規則和架構約束的變化頻率遠低於實現程式碼。這意味著人類 Review 的工作量與系統複雜度之間保持了可管理的比例關係。
BDD 的第二春
這裡有一個有趣的歷史迴環。行為驅動開發（BDD）在 2003 年被 Dan North 提出時，理念非常超前：用自然語言描述預期行為，然後自動化為測試。但 BDD 從未真正普及，核心原因是在人工編碼時代，寫 Spec 被視為「額外工作」。你已經要寫程式碼了，還要先寫一遍 Spec？
這其實也是我之前不看好 Spec 驅動 AI 編程的原因之一。但當我意識到這是我用之前到經驗來評判新的變化產生的誤解。
但在 Agent 時代，等式徹底翻轉：
- 舊等式：寫 Spec（額外成本）+ 寫程式碼（主要工作）= 總成本上升
- 新等式：寫 Spec（唯一人工工作）+ AI 生成程式碼（近零邊際成本）= 總成本大幅下降
Spec 不再是「額外工作」，而是唯一的人工工作。BDD 曾經解決不了的問題，"誰來寫那些 Spec？" 現在有了明確答案：人類工程師的核心職能就是寫 Spec。
而且，用自然語言寫 Spec 這件事，恰好是 LLM 最擅長理解和執行的。這創造了一個完美的分工：
Given 用戶登錄時輸入了錯誤密碼超過 5 次
When 用戶再次嘗試登錄
Then 帳戶應被鎖定 30 分鐘
And 系統應發送安全通知郵件人寫 Spec。Agent 實現。BDD 框架驗證。你不需要讀實現程式碼，除非驗證失敗。
AI Native Code Review：五層信任模型
理解了範式遷移的方向後，具體的替代方案是什麼？
答案不是找到「一個」替代 Code Review 的銀彈，而是構建多層確定性驗證體系：瑞士乳酪模型（Swiss Cheese Model）。每一層都不完美，但當你把足夠多的不完美層堆疊起來時，漏洞就不會對齊。
（此圖來自於 latent.space 部落格文章，但我這裡的五層模型跟它的有所區別）
Layer 0 編譯時護欄：類型系統與靜態分析
這是最便宜、最快、最可靠的一層。類型系統不會疲勞，不會遺漏，不會被 diff 大小嚇到。
在 AI Coding 時代，類型系統的價值不是降低了，而是極大地提升了。因為 AI 生成的程式碼最常見的問題恰好是類型系統擅長捕獲的：介面不匹配、類型轉換錯誤、空值處理遺漏。
有的人說，AI 都會寫程式碼了，程式語言不重要了。但我認為，程式語言恰恰更加重要了，原因就是因為，有些語言天生就自帶編譯時護欄。這也是我選擇 Rust 語言的原因之一
實踐建議：如果你的專案還在用動態類型語言且沒有類型標註，現在是遷移的最佳時機。除了 Rust，TypeScript 之於 JavaScript，mypy 之於 Python，都是在為 AI 生成的程式碼提供第一道確定性防線。
Layer 1 合約驗證：前置條件、後置條件、不變量
// 合約定義（人類編寫）示例
@contract
def transfer_money(from_account, to_account, amount):
# 前置條件
require(amount > 0, "Amount must be positive")
require(from_account.balance >= amount, "Insufficient funds")
# 不變量
total_before = from_account.balance + to_account.balance
# ... AI 生成的實現程式碼 ...
# 後置條件
ensure(from_account.balance == old.from_account.balance - amount)
ensure(to_account.balance == old.to_account.balance + amount)
ensure(from_account.balance + to_account.balance == total_before)合約驗證的核心價值在於：它把「正確性」從一個需要人類主觀判斷的模糊概念，轉化為可以被機器精確檢驗的形式化屬性。 AI 可以生成任何實現方式，只要它滿足合約，我們就不關心具體實現細節。
Layer 2 BDD 驗收測試：人類定義「什麼是正確」
這一層是人類審查点的核心錨定位置。人類不再審查程式碼，而是審查和編寫驗收標準：
Feature: 支付風控
Scenario: 異常大額交易觸發風控
Given 用戶歷史月均消費為 5000 元
When 用戶發起單筆 50000 元的交易
Then 交易應被暫時凍結
And 系統應發送簡訊驗證
And 交易應在人工審批佇列中出現
Scenario: 正常消費不觸發風控
Given 用戶歷史月均消費為 5000 元
When 用戶發起單筆 3000 元的交易
Then 交易應立即完成這些驗收標準由人類編寫，它們本身就是需要「Review」的核心製品。但 Review Spec 比 Review Code 高效一個數量級。因為 Spec 是人類可理解的業務語言，而不是實現細節。
Layer 3：對抗性多 Agent 驗證
這一層引入了智慧體軟體工程的獨特優勢。傳統 Code Review 的一個核心問題是：寫程式碼的人和審查程式碼的人共享相同的認知偏差。當 Review 者知道實現意圖時，往往會不自覺地「腦補」程式碼的正確性。
多 Agent 對抗性驗證通過架構設計消除了這個問題：
┌─────────────────────────────────────────────────┐
│ Arbiter Agent │
│ （綜合所有信號，做出最終判斷） │
└──────────┬──────────┬──────────┬────────────────┘
│ │ │
┌──────▼──┐ ┌─────▼────┐ ┌──▼───────────┐
│Blue Agent│ │Red Agent │ │ Audit Agent │
│（實現程式碼）│ │（破壞程式碼）│ │（獨立審計） │
└─────────┘ └──────────┘ └──────────────┘- Blue Agent：實現功能程式碼
- Red Agent：嘗試破壞程式碼，生成攻擊性測試用例和邊界條件
- Audit Agent：獨立檢查安全、性能、合規性，不了解實現過程
- Arbiter Agent：綜合所有信號做出最終判斷
關鍵設計原則是關注點分離 + 互不信任。這和傳統財務審計的邏輯一樣，做帳的和審計的必須是不同的主體。放到 Agent 世界裡，使用不同的模型實例、不同的 system prompt、不同的上下文視窗，來保證審查的獨立性。
這裡有一個 Latent Space Engineering 部落文章中提到的有趣技巧：給 Review Agent 設定競爭框架，告訴每個子 Agent，發現最多合法問題的那個可以「獲得獎勵」。這個技巧利用了 LLM 在競爭性 prompt 下更加仔細的特性。
Layer 4 權限沙箱：最小權限原則的架構化
大多數 Agent 框架對權限的處理是全有或全無。Agent 要么有 shell 訪問權限，要么沒有。但粒度至關重要。
# 任務級權限定義
task: fix-date-parsing-bug
permissions:
files:
read: ["src/utils/dates.py", "tests/test_dates.py"]
write: ["src/utils/dates.py", "tests/test_dates.py"]
network: deny
env_vars: deny
escalation_triggers:
- pattern: "auth|authentication|authorization"
action: require_human_review
- pattern: "schema.*migration|ALTER TABLE"
action: require_human_review
- pattern: "dependency.*add|requirements.*txt"
action: require_human_review權限沙箱的價值在於：即使前面所有層都失敗了，Agent 也無法觸碰它不應該觸碰的東西。 這是縱深防禦的最後一道實質性屏障。
Layer 5 生產環境的最終防線：可觀測性 + 快速回滾
即使前面五層全部失效，系統仍然需要能夠在生產環境中快速發現和修復問題：
- 金絲雀發布：新變更先在 1% 的流量上驗證
- 實時可觀測性：錯誤率、延遲、資源消耗的實時監控
- 自動回滾：異常指標觸發秒級自動回滾
- 特性開關：任何新功能都可以在不部署新程式碼的情況下關閉
這一層的哲學是承認一個現實：無論你的驗證體系多麼完善，bug 都會進入生產環境。傳統 Code Review 試圖在部署前消滅所有 bug，這在 AI 時代是不現實的。
正確的策略是：讓 bug 的影響範圍最小化，讓修復速度最大化。
AI Native Review 的估算範式
在之前的 AI Native 任務估算文章中，我們提出了兩個核心度量單位：
- 輪次（Rounds）：單 Agent 順序執行的疊代次數
- 波次（Waves）：多 Agent 併發執行的批次數
對於 Code Review，我們可以用同樣的框架來重新定義 Review 的成本度量：
傳統度量（已过時）
Review 成本 = 人數 × 每人 Review 時間
≈ 2 人 × 1.5 小時 = 3 人時 / PR這個度量方式假設 Review 是人力密集型活動，其成本與程式碼量成正比。在 AI 時代這個假設徹底失效。
AI Native 度量
驗證成本 = Σ(各層驗證波次 × 每波次計算成本)
Wave 0: 靜態分析 + 類型檢查 → ~10 秒，零人工
Wave 1: 合約驗證 + 單元測試 → ~30 秒，零人工
Wave 2: BDD 驗收測試 → ~2 分鐘，零人工
Wave 3: 多 Agent 對抗性審查 → ~5 分鐘，低 Token 成本
Wave 4: 人工 Spec/結果驗收 → 僅在必要時，~15 分鐘注意這個結構的關鍵特徵：
- 成本遞增：越往後的層成本越高，但觸發頻率越低
- 確定性優先：前三層完全確定性，不涉及人工判斷
- 人工兜底：人工只在最後一層、且僅在前面的層無法確認時介入
- 總成本與程式碼量解耦：AI 生成 100 行還是 10000 行程式碼，Wave 0-3 的成本幾乎不變
這就解決了 Latent Space 文章中描述的根本矛盾 "if the code review takes longer than the AI took to write the feature, the math doesn't make sense to higher ups"。在新範式下，驗證成本與生成成本保持了合理的比例關係。
遷移路徑：從傳統到 AI Native
範式遷移不會一夜之間發生。以下是一個漸進式的遷移路徑：
階段一：增強（Augment）
在現有 Code Review 流程中引入自動化層：
- 部署 AI Code Review 工具（CodeRabbit、Graphite Diamond 等）作為第一輪篩選
- 在 CI 中增加靜態分析和合約檢查
- Review 者只關注 AI 工具未覆蓋的高層問題
人的角色：仍然是程式碼的最終審批者，但工作量減少 30-50%。
階段二：分離（Separate）
將 Review 的五個職能顯式分離，各用最優手段處理：
- 規範合規 → 自動化 linter（零人工）
- 正確性驗證 → 合約檢查 + BDD 測試（零人工）
- 安全性檢查 → 專用安全掃描 + 對抗性測試（零人工）
- 架構一致性 → AI Agent 審查 + 架構約束配置（低人工）
- 知識傳遞 → 程式碼庫文件自動生成 + 變更摘要（低人工）
人的角色：從「審查所有程式碼」轉變為「審查架構決策和異常情況」。
階段三：上移（Elevate）
徹底將人的審查點從程式碼層上移到 Spec 層：
- 建立 Spec 驅動的開發流程
- 所有新功能從 BDD Spec 開始，而非從程式碼開始
- AI Agent 在 Spec 約束下生成程式碼，多層自動驗證
- 人只 Review Spec 和最終驗收結果
人的角色：意圖的定義者和最終結果的驗收者，不再接觸程式碼 diff。
階段四：自治（Autonomize）
構建完全自治的驗證流水線：
- 多 Agent 對抗性驗證替代所有人類審查
- 人只在特定觸發條件（安全敏感、架構變更、異常指標）下介入
- 系統具備自愈能力——發現問題後自動生成修復、驗證、部署
人的角色：系統的架構師和異常的處理者，日常流程中不出現。
尚未解決的問題
坦白來說，這個範式遷移還有幾個關鍵問題還沒有很好的答案：
問題一：誰來 Review Spec？
我們把審查點從程式碼上移到了 Spec，但 Spec 本身也會有錯誤。寫一個完備的 Spec，其實並不比寫程式碼簡單。正如 Latent Space 評論區中一位讀者指出的，"spec driven development 的倡導者對寫出完整 Spec 的難度過於天真"。這是真實的挑戰。
不過，Spec 錯誤和程式碼錯誤有一個關鍵區別：Spec 錯誤通常在驗收測試階段就能暴露（因為系統行為不符合預期），而程式碼級別的 bug 可能在 Spec 維度上看起來完全正確但在實現中引入了微妙的問題。Spec 錯誤的反饋迴圈更短，這部分緩解了這個問題。
問題二：Agent 的知識邊界
當前的 AI Agent 缺乏對業務上下文的深度理解。它不知道你上週和客戶開會做了什麼決定，不知道你的產品路線圖剛剛發生了轉向。正如 Graphite 的 Greg Foster 所說，"Real code review demands domain expertise"。
這個問題的解決方向可能是更好的上下文注入機制，將業務決策、架構決定記錄（ADR）、產品路線圖等結構化為 Agent 可消費的上下文。但目前的上下文視窗和檢索增強技術還不足以完全解決這個問題。隨著記憶系統的逐漸成熟，我覺得這很快將不會是一個問題。
問題三：責任歸屬，誰來背鍋？
如果 AI 生成的程式碼導致了安全事故，誰負責？傳統 Code Review 有一個樸素但有效的機制，Approve 按鈕背後是一個真實的工程師，他/她為這個決定承擔責任。
在全自動驗證流水線中，責任歸屬變得模糊。這不僅是技術問題，更是組織和法律問題。在這個問題得到解決之前，完全消除人工審批在很多組織中是不可能的。特別是在金融、醫療、航空等受監管行業。
但，如果問題一的答案是人類開發者負責 Review Spec 的話，那第三個問題就自然迎刃而解。而第二個問題也會隨著 AI 生態發展而很快被解決。
結語：不是讀得更快，而是不再需要讀
讓我們回到開篇的那組數據：PR 合併率暴漲 97.8%，Review 時間暴漲 91.1%。
面對這個數據，錯誤的反應是「我們需要更快的 Review 工具」。正確的反應是「我們需要重新思考 Review 本身的存在形式」。
Code Review 不是二十年前就有的傳統。Latent Space 的文章提醒我們，程式碼審查直到 2012-2014 年才真正普及。在此之前，大量軟體團隊不做逐行程式碼審查，但也在成功交付軟體。他們依賴的是什麼？測試、漸進式發布、快速回滾，這些至今仍然有效的機制。
Code Review 的檢查點之前也發生過遷移。我們從瀑布式簽審遷移到了持續整合。我們可以再次遷移，從審查程式碼遷移到審查意圖，從事後檢驗遷移到內建品質，從人眼掃描遷移到確定性驗證。
智慧體軟體工程的核心公式在這裡再次得到驗證：
Spec 是控制面，Code 是數據面，Agent 是執行面。
Review 的未來不是 "AI 幫人讀程式碼"，而是「人根本不需要讀程式碼」。
人類最寶貴的認知資源：判斷力、創造力、對業務的深度理解，應該用在定義「什麼是正確的」（Spec），而不是檢查「這段程式碼寫得對不對」（Review）。
未來是：快速發布，全面觀測，極速回滾。
而不是：緩慢審查，遺漏 bug，在生產環境調試。
我們不可能在閱讀速度上超過機器。我們需要在思考品質上超越它們，在上游，在決策真正重要的地方。
[1] 《How to Kill the Code Review》: https://www.latent.space/p/reviews-dead
[2] Octoverse 報告：https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/
[3] CodeRabbit: https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
[4] StrongDM Attractor: https://github.com/strongdm/attractor