審查問題

對 AI 生成程式碼的標準建議是「仔細審查它」。

這建議正確但在規模化時毫無用處。

開發者在警覺、熟悉領域且沒有時間壓力時，審查 AI 輸出能發現問題。在其他所有情況下——也就是大多數情況——問題會溜過去。

用 AI 審查者抓 AI 生成的問題更不可靠。你在要求一個機率系統驗證另一個機率系統的輸出。失敗模式是相關的。

唯一可擴展的模式是確定性 enforcement。在每次提交時檢查的規則，無法被疲勞或樂觀所覆寫，違反時讓建置失敗。

確定性的意思

確定性意味著檢查每次都產生相同的結果，無論是誰執行或何時執行。

  • Linter 規則是確定性的。
  • 型別檢查是確定性的。
  • Boundary 匯入限制是確定性的。
  • Contract test 是確定性的。
  • 人類審查者的注意力不是。
  • LLM 的評估不是。

在 AI 生成的 codebase 中，這個區別更為重要，因為生成的程式碼量超過任何團隊能手動審查的範圍。你無法讓審查速度線性跟上生成速度。你可以輕而易舉地擴展確定性檢查。

防護機制堆疊

對於 AI 生成的 codebase，防護機制堆疊有四層：

第一層：型別系統

型別系統是第一道防護。嚴格的型別能捕捉一類任何審查流程——人類或 AI——都無法一致捕捉的錯誤：

  • 空值違規
  • Interface 不匹配
  • 缺少的情況處理
  • 錯誤的參數型別

如果專案使用 TypeScript，strict: true 是不可妥協的。如果使用沒有強型別系統的語言，透過工具加入一個，或選擇不同的語言。

第二層：架構規則

架構規則 enforce boundary 紀律：

  • 沒有畫面從另一個畫面的內部匯入。
  • 沒有領域邏輯直接匯入基礎設施。
  • 沒有 module 繞過 composition root 來存取依賴。
  • 沒有廠商 SDK 出現在其轉接器 module 之外。

Semgrep、ArchUnit、dependency-cruiser 或自訂 ESLint 規則等工具可以靜態 enforce 這些。關鍵是它們在 CI 中執行且讓建置失敗。開發者可以忽略的警告不是防護機制。

第三層：Contract Tests

Contract tests 驗證 module 滿足其 interface，而不需要執行完整系統：

  • 驗證轉接器滿足驗證 interface。
  • 分析轉接器滿足分析 interface。
  • 儲存轉接器滿足儲存 interface。

這些執行速度快，測試整合 boundary，並捕捉 AI 生成程式碼滿足型別簽名但違反行為 contract 的特定失敗模式。

第四層：確定性整合檢查

在整合層級，檢查驗證系統層面的屬性：

  • Composition root 解析所有依賴時沒有執行時錯誤。
  • 依賴圖不包含循環。
  • 所有必需的環境變數都已宣告。
  • 設定在建置時有效，而不僅在執行時。

Semgrep 用於 AI 生成程式碼

Semgrep 值得特別提及，因為它擅長將架構規則表達為程式碼：

  • 對 AST 結構進行模式匹配，而非字串匹配。
  • 每個專案自訂規則，而非僅通用 linting。
  • 快到足以在每次提交時執行。
  • 表達力強到足以編碼 boundary 違規。

大量使用 AI 生成的團隊應維護一套 Semgrep 規則集，編碼其架構 boundary。當 AI 生成違反 boundary 的程式碼時，建置在合併之前失敗。不需要人類注意力。

這不是要抓 AI 輸出中的 bug。這是讓結構性違規無論如何產生都不可能被合併。

AI 程式碼審查實際上能抓到什麼

AI 程式碼審查工具適用於：

  • 風格一致性
  • 文件缺口
  • 明顯的邏輯錯誤
  • 建議替代方案

AI 程式碼審查工具不可靠的地方：

  • 架構 boundary 違規
  • 跨 module 引入的微妙耦合
  • 行為 contract 違規
  • 需要全系統推理的安全屬性

失敗模式不是 AI 審查偶爾遺漏東西。失敗模式是它不可預測地遺漏東西，而你無法知道它何時遺漏了。這就是為什麼它無法取代確定性 enforcement——只能補充它。

經濟效益

確定性防護機制執行成本低但初始建構成本高。

撰寫架構規則需要幾天。維護 Semgrep 設定需要持續關注。設置 contract tests 需要先定義 interface。

但一旦存在，它們在每次提交時以近乎零的邊際成本執行。它們不會疲勞。它們不會在週五下午跳過檢查。它們不會因為資深程度或社會壓力而退讓。

對於程式碼量高且生成速度快的 AI 生成 codebase，這個經濟特性是決定性的。替代方案——讓人工審查速度跟上 AI 生成速度——是不可行的。

與 AI-Native 架構的關聯

我在 Stanford CS146S 對 AI 程式開發的見解是對的——缺少的科目是架構 中討論了這個更廣泛的模式。確定性防護機制是讓可替換架構成為現實的 enforcement 機制。

沒有防護機制，架構 boundary 只是願望。有了防護機制，boundary 是結構性的。「我們盡量保持 module 隔離」和「如果 module 隔離被違反建置就會失敗」之間的差異，就是能承受 AI 速度迭代的架構與在其下崩潰的架構之間的差異。

現代軟體開發者不僅需要 AI 工具熟練度。他們需要一套防護機制堆疊，讓 AI 生成的程式碼在速度下交付時結構上是安全的。

常見問題

對 AI 生成程式碼 enforce 架構規則的最佳工具是什麼？

Semgrep 是自訂架構規則最靈活的選項。它支援對 AST 結構的模式匹配，在 CI 中執行速度快，並讓團隊編碼專案特定的 boundary。對於 JavaScript/TypeScript 專案，dependency-cruiser 和自訂 ESLint 規則也很有效。

AI 程式碼審查能取代人工程式碼審查嗎？

不能。AI 程式碼審查在風格和文件方面補充人工審查，但對架構 boundary enforcement 和安全屬性不可靠。確定性檢查（型別系統、linter、架構規則、contract tests）是注意力依賴型審查唯一可擴展的替代方案。

如何在不拖慢團隊的情況下設置防護機制？

從型別系統開始（嚴格模式，無例外）。為三個最高風險的 boundary 新增架構規則。為外部整合新增 contract tests。每層需要一天設置，執行只需幾秒。拖慢的是違規，而非檢查本身。

防護機制和 linter 有什麼區別？

Linter 建議改進。防護機制讓建置失敗。區別在於 enforcement。在 AI 生成的 codebase 中，建議在規模化時被忽略，因為數量太大，無法保持一致的手動注意力。只有建置失敗能保證合規。