邁向未經人工審查之 AI 生成程式碼的自動化驗證

背景

隨著生成式 AI 在軟體開發領域的普及，開發者面臨的核心挑戰已從「如何生成程式碼」轉向「如何確保生成的程式碼安全可靠」。Peter Lavigne 在其文章中提出，我們應將對 AI 程式碼的態度從逐行審閱（Review）轉向自動化驗證（Verify），並透過屬性測試、變異測試及無副作用約束等手段，建立一套無需人工介入即可信任 AI 產出物的流程。

社群觀點

Hacker News 的討論對此提案展現了高度的警覺與批判性思考。許多資深開發者指出，將 FizzBuzz 這種邏輯簡單、自我包含且易於定義的題目作為自動化驗證的範例，極大地誤導了實務上的複雜度。在真實的生產環境中，軟體系統往往涉及複雜的抽象層、系統調用、狀態網路協定與不確定的輸入輸出，這些因素使得建立完美的驗證模型變得極其困難。當驗證成本高到需要精確模擬整個世界運作時，這種自動化流程往往會走向崩潰。

針對「將 AI 產出視為編譯後代碼」且無需具備可讀性的觀點，社群中出現了強烈的反對聲音。反對者認為，人類可讀的程式碼是目前 AI 系統中最高等級的「可解釋性」，放棄可讀性等同於放棄對系統的最終控制權。一旦系統在凌晨三點發生故障，若開發者從未閱讀過程式碼，將難以進行緊急修復。此外，軟體工程的本質不僅是滿足當下的需求，還包含未來的可擴展性。AI 雖然能透過不斷重寫來滿足新需求，但在大型商業系統中，頻繁的重構可能導致隱性依賴崩潰，這種風險對於承載鉅額營收的企業而言是不可接受的。

另一個核心爭議點在於「測試預言機問題」（Test Oracle Problem）。留言者指出，撰寫正確且完備的測試規格，其難度往往不亞於甚至高於撰寫程式碼本身。如果開發者無法寫出無瑕疵的測試，那麼自動化驗證就只是將錯誤從程式碼轉移到了測試腳本中。雖然屬性測試與變異測試能提升信心，但它們對計算資源的需求極高，且無法解決 AI 可能為了讓測試通過而產生的「討好行為」——即 AI 繞過邏輯漏洞，僅針對測試案例進行補丁式修正。

不過，討論中也存在相對務實的共識：AI 確實改變了開發者的職責重心。未來的工程師可能更像是一名架構師或飛行員，負責定義高層次的規格與驗證框架，而非糾結於具體的語法細節。雖然目前完全脫離人工審閱仍屬激進，但這種自動化驗證的嘗試為軟體工程提供了一個新的基準線，隨著工具鏈的成熟，這種模式或許能在低風險、高定義明確的特定領域中率先落地。

延伸閱讀

在討論中，參與者提到了幾個關鍵工具與資源：Python 的屬性測試框架 Hypothesis 以及 JavaScript 的對應工具 fast-check，這些是實踐自動化驗證的重要基礎。此外，針對 AI 在軟體環境中因缺乏完整規格而受限的議題，LinkedIn 上關於生產環境遙測與規格演進的文章也受到推薦。對於追求程式碼正確性的開發者，DO-178 等航太級安全軟體標準的開發流程，被認為是 AI 輔助開發可以借鏡的嚴謹模式。