97% 企業開發者使用 AI 編程工具——但僅 30% 建立了治理框架

AI 編程助手完成了企業軟體幾乎從未做到的事：在大約三年內達到近乎全面的採用率。根據應用程式安全公司 Black Duck（前身為 Synopsys 軟體完整性部門）的最新研究，97% 擁有 500 名以上員工的企業軟體工程師和 DevOps 專業人員，現在每天的工作都會用到 AI 編程工具。

這個數字來自 2026 年 3 月對 831 名開發者的調查，所呈現的不是緩慢攀升的過程，而是一個實際上的終點。剩餘的 3% 可能反映了特定工作流程的例外情況、合規受限的環境，或個人偏好——而非真正意義上的抗拒。在企業環境中，AI 編程輔助已是軟體開發的常態。

更值得深思的問題是接下來會發生什麼：68% 的同一批開發者表示，建立一套清晰的自動化系統來追蹤 AI 生成程式碼「極其重要」——但實際上不到三分之一的團隊（30%）真正建立了完整的治理框架。

生產力數據

生產力的提升是真實的、顯著的，且在調查中保持一致。92% 的開發團隊表示因 AI 編程工具而提升了生產力和發布速度；58% 描述這種提升是「重大的」。一個具體的量化指標令人印象深刻：開發者每週平均節省八小時——大約一整個工作天——透過 AI 在程式碼補全、測試生成、文件撰寫和重構等任務上的協助。

超過半數受調機構（53%）在 AI 採用以來，整體程式碼產出量增長了 25% 以上。這個數字捕捉到了超出純粹生產力提升的重要變化：AI 編程工具不只是在加速原有的工作——它讓開發團隊得以承接以往會推遲或拒絕的工作範疇。

在這個時間點，AI 編程採用的商業理由已無需再論證。如此量級的生產力提升，在 92% 的採用團隊中得到一致呈現，是近年企業軟體最清晰的投資回報故事之一。討論已向前推進。

治理缺口

數據所揭示的問題，不是是否採用 AI 編程工具——這個決定已在全產業規模上做出。問題是，當採用率遠遠超前管控所需的機制時，會發生什麼。

68% 的開發者認為追蹤 AI 生成程式碼的自動化系統「極其重要」，但只有 30% 的團隊建立了完整框架。這是一個超過 38 個百分點的差距——在所表述的重要性與實際運作現實之間——而這個差距正是安全風險和法律責任持續累積的地方。

後果在數據中有所記錄。根據 Black Duck 的另一項發現，隨著 AI 加速程式碼創作，開源漏洞暴露已翻倍。AI 編程工具經常從訓練語料庫中提取包含已知漏洞的依賴套件、過時 API 和可能造成合規問題的授權條款的程式碼。如果沒有能在提交（commit）環節識別 AI 生成程式碼——並依照安全策略、授權要求和架構標準加以評估——的治理框架，這些風險就會無聲地進入程式碼庫。

投資回報的連結並非抽象：Black Duck 的數據顯示，建立了完整治理框架的團隊，比沒有治理框架的團隊有 55% 更高的概率報告效率重大提升。這個反直覺的發現在於：治理不是生產力的阻力——它是 AI 所帶來之生產力的倍增器。

資安面向

64% 的受調開發者對 AI 編程助手引入安全缺陷或漏洞表示中度或高度憂慮。對於 97% 的同一批人每天在使用的工具而言，這是一個很高的比例——它反映了一種真實的運作矛盾：團隊在使用他們知道並不完美的工具，以他們知道監控不足的方式，因為生產力效益大到無法放棄。

這份擔憂並非多餘。AI 編程工具從包含安全和不安全程式碼模式的公開儲存庫訓練資料中學習。如果沒有針對安全專屬語料庫的微調和明確的安全護欄，這些工具會把不安全的模式與安全的模式並排建議，而處於生產力壓力下的開發者未必能察覺差異。Black Duck 的研究發現，開源漏洞數量翻倍與 AI 採用時間線呈相關關係——儘管在整體程式碼量同步增加的情況下，因果關係難以確立。

資安廠商已注意到這個趨勢。專門設計用於掃描 AI 生成程式碼漏洞、追蹤 AI 生成程式碼來源，並在提交層面執行政策的市場正在快速擴張。Black Duck 本身已推出專門針對 AI 生成程式碼的能力；GitHub Advanced Security 平台也增加了 AI 專屬掃描功能。市場正在回應一個採用數據令人難以忽視的問題。

治理框架的實際樣貌

建立了完整治理框架的 30% 團隊，正在做幾件同業尚未做到的事。他們在提交層面追蹤哪些程式碼是 AI 生成的，以便套用差異化的掃描政策；他們使用成分分析工具識別 AI 生成程式碼可能無意間引入的有漏洞依賴套件；他們對開發者可以使用哪些 AI 模型、在什麼條件下、用於什麼類型的工作，制定了明確政策——認識到並非所有程式碼在安全要求上都是等同的。

關鍵的一點是，最有效的治理框架是自動化的，而非仰賴人工判斷。要求開發者在提交訊息中自我申報 AI 生成程式碼，或在使用 AI 輔助時套用獨立審查流程，隨著採用正常化而效果會持續退化。報告了最佳安全和生產力成果的團隊，是那些將治理整合進開發流水線本身的——AI 生成程式碼在流水線中自動被標記、掃描和政策檢查，無需任何個人的主動判斷。

對大多數企業工程組織而言，這是可以達到的狀態，但需要有意識的投入。尚未做出這種投入的團隊——即那 70% 沒有完整治理框架的團隊——正在積累資安業界所稱的「AI 技術債」：審計暴露、漏洞面，以及隨著每個開發衝刺週期不斷增大的授權合規問題。

產業背景

Black Duck 的研究發布在一個自 2023 年以來已圍繞 AI 大規模重組的開發者工具市場中。GitHub Copilot 仍是採用率最高的工具，但整個市場已分裂成數十款不同價位的競爭助手。Cursor 曾是成長最快的付費工具，直到上週 SpaceX 的 600 億美元收購改變了其走向。OpenCode、Claude Code 和 Amazon Q 爭奪企業市場。每款 AI 編程工具都有略微不同的訓練資料、略微不同的程式碼建議模式，以及略微不同的安全特性——這些都是治理框架需要考量的變數。

這項研究更廣泛的發現——97% 的企業採用率在沒有相應治理基礎設施的情況下就已到來——並非 AI 編程工具獨有的現象。它映照了早期企業軟體轉型的模式，包括雲端採用、開源依賴套件採用和行動開發。AI 採用的不同之處在於速度：以往那些轉型花了十年才達到相近的飽和度；AI 編程工具在大約三年內就達到了 97% 的企業採用率，這意味著治理基礎設施幾乎沒有時間追上。

對技術長、工程副總裁和應用程式安全團隊而言，Black Duck 的數據既是市場研究報告，更是一份問責文件。生產力效益是真實的，已被量化；治理缺口是真實的，已被記錄；治理團隊的 55% 效率溢價是真實的，可以被衡量。接下來如何，是一個選擇。