AI 把前端代碼量翻了五倍後，我們給倉庫加了十道工程來防腐

近年來，生成式 AI 輔助程式開發已從實驗性工具逐步走向生產力核心，尤其在大型前端專案中，AI 自動生成程式碼的比例正以驚人速度攀升。然而，這股效率革命的背後，卻隱藏著一個令工程團隊日益頭痛的代價：程式碼庫的總量在短期內暴增，甚至出現五倍以上的膨脹。當大量由模型生成的程式碼湧入版本控制系統，原本依賴人為審查與經驗判斷的品質防線，開始出現結構性的鬆動。為此，一個專注於大型前端開發的團隊，近期在倉庫中一口氣導入十道工程防腐機制，試圖在自動化產出的洪流中，重新建立一道可驗證、可追溯的系統性防護網。

這十道工程機制並非單純的靜態掃描或 lint 規則補強，而是從資料流、副作用控管、架構依賴到測試完整性，構築出一個多層次的驗證框架。團隊在導入前便已意識到，傳統的 Code Review 流程在面對每日數百個由 AI 生成的提交（commit）時，已無法有效攔截潛在的邏輯錯誤或架構侵蝕。因此，這套防腐體系的設計初衷，是將「人為判斷」的負擔盡可能轉移到「自動化驗證」的關卡上，讓工程師能將有限的注意力集中在真正需要人類智慧的高階設計決策上。首先，最基礎也最關鍵的一層，是針對資料一致性的嚴格把關。

在過去的實戰經驗中，團隊曾多次遭遇 AI 生成程式碼時，憑空呼叫了根本不存在的欄位或 API 屬性，導致執行時期才爆發的錯誤。這類問題在靜態型別系統下雖能部分攔截，但在 JavaScript 這類動態型別語言中，往往需要仰賴執行時的監控。新的防腐機制中，團隊引入了深度型別檢查與資料結構契約驗證，確保每一筆從後端取得的資料、每一個從狀態管理庫中讀取的欄位，都必須在編譯或建置階段被明確宣告與驗證，杜絕任何「虛構欄位」的存活空間。其次，是對副作用（Side Effect）的嚴格控管。AI 模型在生成函式時，常會不自覺地加入不必要的全域狀態修改、直接操作 DOM 或發送非預期的網路請求。

這些隱性副作用，是導致前端應用程式難以除錯與維護的主要元兇之一。為此，團隊在倉庫中設定了副作用檢查器，透過靜態分析與測試隔離，強制要求所有函式必須是純函式（Pure Function）或明確標註其副作用。任何未經宣告的副作用行為，都會被視為建置失敗，直接阻斷合併請求。這項措施不僅提升了程式碼的可預測性，更讓單元測試的隔離性大幅提升。第三，是對「單向依賴架構」的強制執行。在大型前端專案中，模組之間的依賴關係若失控，很容易形成循環依賴或底層模組反向依賴高層模組的亂象。AI 生成程式碼時，往往只基於當下的需求進行局部補丁，缺乏對整體架構的宏觀視野，導致依賴方向被悄悄破壞。

新的防腐機制中，團隊利用依賴分析工具，在每次合併請求時自動繪製依賴圖，並與既有的架構規範進行比對。任何違反單向依賴原則的程式碼，都會被系統自動標記並阻擋，確保系統的底層核心永遠不會被上層的業務邏輯所污染。除了上述的結構性檢查，測試的完整性也是此次防腐工程的重中之重。團隊過去在一個考勤工時專案中，曾因為測試案例僅是「空殼」而吃足苦頭。當時，AI 生成的測試雖然通過了 CI，但實際上並未執行任何有效斷言，導致嚴重的邏輯缺陷被掩蓋。為此，新的機制特別強調「測試覆蓋率」與「測試有效性」的雙重驗證。

系統不僅會檢查測試程式碼是否覆蓋了關鍵的業務邏輯路徑，更會透過變異測試（Mutation Testing）來驗證測試本身的強度。如果測試無法在程式碼被刻意植入錯誤時失敗，該測試就會被視為無效，必須重新撰寫。這十道工程防腐機制，從程式碼生成的那一刻起，到最終合併至主線，形成了一道完整的防護網。在開發者提交程式碼時，預先提交的 Hook 會進行初步的語法與風格檢查；進入 CI 流程後，則會依序執行型別檢查、副作用掃描、依賴架構驗證、單元測試、整合測試以及變異測試。每一道關卡都設有明確的失敗標準，任何一關未過，程式碼都無法進入下一階段。

這意味著，AI 生成的程式碼必須通過比人類開發者更嚴格的標準，才能被接納。然而，團隊也清醒地認知到這套機制的真實能力邊界。這十道工程防腐機制，雖然能有效攔截資料不一致、副作用濫用、架構破壞與測試空殼等問題，但它們無法替代對產品邏輯與使用者體驗的人為判斷。例如，AI 生成的程式碼可能完美地通過所有技術檢查，但在使用者流程上卻設計得極度不合理，或者與產品的商業目標背道而馳。這類高階的抽象思考與同理心，是任何自動化工具都無法提供的。因此，這套機制被定位為「基礎防護」，而非「品質保證」的全部。團隊強調，導入這十道工程機制，並非為了限制 AI 的生產力，反而是為了釋放其真正的潛力。

當工程師不再需要花費大量時間在審查那些低階的、重複性的錯誤時，他們就能將更多的精力投入到 AI 無法觸及的領域，如系統架構設計、演算法優化以及使用者體驗的打磨。這套機制，實際上是在 AI 與人類工程師之間，建立了一種新的分工模式：AI 負責快速產出，而工程師則負責制定規則、審查方向與確保最終品質。然而，這套機制也帶來了新的挑戰。最直接的是建置時間的延長。由於增加了多道嚴格的驗證關卡，尤其是變異測試與依賴圖分析，整個 CI 流程的耗時從原本的幾分鐘延長至十幾分鐘甚至更久。對於追求快速迭代的團隊而言，這是一個需要權衡的取捨。

團隊目前正在嘗試透過分散式運算與測試分片技術，來縮短建置時間，同時也在評估是否能透過機器學習模型，來預測哪些程式碼變更需要更嚴格的檢查，以達到效率與品質的平衡。此外，這套機制的維護成本也不容小覷。架構規範需要隨著系統演進而更新，資料型別契約需要與後端 API 的變更保持同步，而變異測試的規則也需要不斷調整以適應新的程式碼模式。團隊必須指派專人負責維護這套防腐系統，並將其視為一個持續演進的產品，而非一次性的專案。這也意味著，團隊的工程文化必須從「追求功能交付」轉向「追求系統健康」，將品質視為第一優先順位。

## 從「生成」到「合併」的全面防護 回顧整個導入過程，團隊認為最關鍵的成功因素，在於將這十道機制視為一個整體，而非孤立工具。例如，資料一致性檢查的結果，會回饋給副作用控管模組，而副作用控管的結果，又會影響測試完整性的評估。這種系統性的整合，使得每一道防線都能互相支援，形成一個有機的整體。如果只是單獨導入某個工具，很容易被 AI 生成的程式碼找到漏洞，無法形成有效的防護。團隊也分享了導入過程中的一些實戰經驗。初期，當這些嚴格的檢查機制剛上線時，AI 生成的程式碼合併成功率一度大幅下降，甚至引發了開發者的反彈。但團隊透過建立完善的錯誤訊息提示與自動修復建議，讓開發者能快速理解失敗原因並進行修正。

同時，團隊也提供了「例外申請」的流程，讓開發者在特殊情況下可以暫時繞過某些檢查，但必須提出充分的理由並進行事後追蹤。這種彈性與嚴格的平衡，是這套機制能夠被團隊接受並持續運作的關鍵。最終，這套十道工程防腐機制，已成為該團隊維持倉庫健康的必要基礎。它不僅攔截了眼前可能出現的錯誤，更建立了一種「系統性信任」——讓團隊成員相信，只要程式碼通過了這些檢查，就代表它具備了基本的品質水準。這種信任，讓團隊在面對 AI 大量產出程式碼的規模化風險時，不再感到恐慌，而是能從容地將 AI 視為一個強大的協作夥伴，而非一個需要時刻提防的失控源頭。然而，這並非終點。

團隊坦言，AI 技術的演進速度遠超預期，未來的 AI 模型可能具備更強的推理能力，甚至能生成出更複雜的架構設計。屆時，現有的防腐機制可能將再次面臨挑戰。因此，團隊將持續投入資源，不斷演進這套系統，並將「品質意識」深植於每一位開發者的心中。因為他們深知，無論 AI 多麼強大，最終的品質責任，永遠在於人類工程師的判斷與承擔。