AI 寫程式大普及，治理卻嚴重脫節：一場吞噬生產力的新危機

AI 編碼助手在不到兩年內，從實驗性玩具變成業界標配。Black Duck 發布的《2026 年 AI 驅動軟體開發現狀》報告拋出一個令人瞠目的數字：97% 的軟體開發團隊已經在使用 AI 編碼工具 。但在這個亮眼數字背後，藏著一個遠更令人不安的發現——用來審查、保障安全與治理這些程式碼的基礎架構，根本沒跟上腳步。

只有 30% 的組織對 AI 的使用採取完整治理措施 。對其餘 70% 來說，AI 正在用現有工作流程無法消化的速度產出程式碼。Black Duck 稱之為「不斷擴大的治理赤字」——而這個赤字，正悄悄吞噬 AI 工具原本應該帶來的生產力提升 。

三大瓶頸正將程式碼生成的紅利消耗殆盡

報告清楚描繪出一種模式：AI 工具加速了程式碼的「撰寫」，但這個速度卻在別處製造出巨大的壓力點。高達九成團隊反映，AI 生成的程式碼在工作流程中出現問題 。這些問題並非隨機出現，而是集中在三個下游環節，共同吸走開發前端省下的時間：

• 人工審查（52%）——審查者現在要處理比人類手寫程式碼更多的 AI 生成碼，量體還在持續成長
• 安全測試（51%）——AI 生成碼引進手寫時代不存在的新弱點類型，特別是依賴注入（dependency injection）、硬編碼機密（hardcoded secrets）與過時函式庫建議
• 重工修改（48%）——近半數團隊花費大量時間修復、重構或改寫 AI 產出，才能上線

這個現象已經有了一個名字：勞務轉移（toil shift）。AI 不是消除工作，而是把工作從生成階段推移到驗證、測試與修復階段 。Black Duck 的說法很直白：「大多數組織產出 AI 生成碼的速度，已經超過他們審查、保護與治理的能力」 。

治理：真正的 ROI 乘數

報告中如果有一個工程主管必須拿來行動的發現，那就是：治理是 ROI 乘數 。有治理與沒有治理的團隊之間，差距不是邊際性的——它是「真正抓住效率回報」與「眼睜睜看著回報從旁邊流失」的差別。

Black Duck 發現，具備完整治理框架的組織，有 90% 回報從 AI 編碼工具獲得顯著效率提升。缺乏結構化監管的團隊？數字驟降到 44% 。

這裡所謂的治理，不是指繁文縟節，而是有明確定義的政策：哪些工具可以用、AI 生成碼如何審查、必須通過哪些安全檢驗關卡、誰對產出負責。它代表從「開發者愛用什麼就用什麼」，轉變為「開發者使用有批准、有審查軌跡、有結構化管線的工具」。

影子 AI 的潛在危機

讓治理更棘手的是 影子 AI（Shadow AI） 的興起——開發者違反或繞過公司政策使用 AI 工具。Black Duck 發現，18% 的組織將影子 AI 視為重大的無管理風險 。當 Cursor、Windsurf 或 Claude Code 這類工具在個別開發者層級導入，卻未經過採購或資安審查，組織便對自身的攻擊面失去能見度 。

供應鏈風險：AI 生成碼繼承了什麼？

治理缺口，最終會轉化為具體的弱點。供應鏈的意涵正是如此。Black Duck 的研究——包括其相關的《2026 OSSRA》報告——揭露了三項 AI 編碼助手特有的、彼此交織的風險：

授權洗白（License laundering）：AI 助手基於開源程式碼倉庫訓練，能從 Copyleft 來源生成程式碼片段，卻不帶原始授權資訊 。2026 OSSRA 報告指出，三分之二的受稽程式碼庫存在授權衝突——這是報告史上最高比例 。組織可能在不知情中，交付了自己根本沒有權利使用的程式碼。

依賴爆炸（Dependency explosion）：每個程式碼庫納入的開源元件數量年增 30%，而平均每個程式碼庫的漏洞數更飆升 107% 。AI 編碼助手加速了這個趨勢，因為它從更廣大的訓練資料庫組合解決方案——這意味著每個 AI 生成的函式，可能拉進開發者自己壓根沒選過的依賴套件。

合規缺口：只有 24% 的組織對 AI 生成碼進行全面的智慧財產、授權、安全與品質評估 。這表示四分之三的組織，根本無法可靠地回答：「我們剛承諾了哪些法律與安全義務？」

開發者信任危機：用愈多，信愈少

Black Duck 的發現並非孤立現象。多份約略同期發布的獨立調查，用更細緻的數據印證並延伸了這幅信任圖像：

• Sonar 2026 年代碼現況開發者調查（超過 1,100 位開發者）發現，96% 開發者不完全信任 AI 生成碼的功能正確性 。但只有 48% 的人在提交前必定驗證——代表連開發者自己都不信任的程式碼，正規律地被送上線 。
• Stack Overflow 2025 年開發者大調查（49,009 份回覆）顯示，對 AI 準確性的信任度在一年內從 40% 掉到 29%。主動不信任的人升至 46%，正向好感度從 72% 跌到 60% 。
• Harness 2026 年 AI 驅動軟體發布報告（500 位工程主管）發現，57% 仍要求對 AI 生成碼的每一行程式進行「人機迴圈（human-in-the-loop）」審查，29% 現在花在程式碼審查的時間比導入 AI 助手前還多 。

這些調查的共識極其一致：開發者不能沒有 AI 工具，但也無法全然信任它們。生成與驗證之間的鴻溝，已成為新的瓶頸。

Noma Security 資安長 Diana Kelley 一語道破核心張力：「更快的程式碼，不等於更安全的程式碼」 。

治理實際上是什麼模樣

Black Duck 給出的藥方並非抽象概念。報告點出幾項具體措施，區隔了那 30% 完整治理的組織與其他團隊：

1. 結構化的 AI 治理框架——不是非正式的指引，而是書面紀錄且確實執行的政策，涵蓋工具核准、產出審查與問責機制
2. 管線整合的審查關卡——脫離仍有 46% 企業採用的「人工把程式碼丟進安全測試佇列」模式，走向每次 AI 輔助提交都自動執行的品質與安全檢查
3. 部署後持續監控——Black Duck 指出，「只靠左移（shift-left）策略已不再足夠」，因為風險在整個軟體開發生命週期中被引入、被發現，也必須在整個生命週期中被管理
4. 安全工具鏈的精簡化——超過 71% 受訪者指出工具蔓延（tool sprawl）是重大摩擦來源，要安全地擴展 AI 應用，必須先整合到更少、更整合的工具上

結語

Black Duck 報告並非反對使用 AI 編碼助手。它反對的是，用 AI 卻不給予對等的治理。當 97% 團隊以前所未有的速度生成程式碼，卻只有 30% 擁有管理它的監管基礎架構，這個產業等於是在集體開出自己無法兌現的支票。

治理與效率增益之間的相關性——90% 對比 44%——讓商業決策毫無模糊空間。先蓋好護欄的組織，才能抓住 AI 承諾的生產力。而那些不做的人，將反覆發現：在鍵盤前省下的時間，終究要在審查佇列中償還。