這個現象已經有了一個名字:勞務轉移(toil shift)。AI 不是消除工作,而是把工作從生成階段推移到驗證、測試與修復階段 。Black Duck 的說法很直白:「大多數組織產出 AI 生成碼的速度,已經超過他們審查、保護與治理的能力」
。
這裡所謂的治理,不是指繁文縟節,而是有明確定義的政策:哪些工具可以用、AI 生成碼如何審查、必須通過哪些安全檢驗關卡、誰對產出負責。它代表從「開發者愛用什麼就用什麼」,轉變為「開發者使用有批准、有審查軌跡、有結構化管線的工具」。
讓治理更棘手的是 影子 AI(Shadow AI) 的興起——開發者違反或繞過公司政策使用 AI 工具。Black Duck 發現,18% 的組織將影子 AI 視為重大的無管理風險 。當 Cursor、Windsurf 或 Claude Code 這類工具在個別開發者層級導入,卻未經過採購或資安審查,組織便對自身的攻擊面失去能見度
。
治理缺口,最終會轉化為具體的弱點。供應鏈的意涵正是如此。Black Duck 的研究——包括其相關的《2026 OSSRA》報告——揭露了三項 AI 編碼助手特有的、彼此交織的風險:
授權洗白(License laundering):AI 助手基於開源程式碼倉庫訓練,能從 Copyleft 來源生成程式碼片段,卻不帶原始授權資訊 。2026 OSSRA 報告指出,三分之二的受稽程式碼庫存在授權衝突——這是報告史上最高比例
。組織可能在不知情中,交付了自己根本沒有權利使用的程式碼。
依賴爆炸(Dependency explosion):每個程式碼庫納入的開源元件數量年增 30%,而平均每個程式碼庫的漏洞數更飆升 107% 。AI 編碼助手加速了這個趨勢,因為它從更廣大的訓練資料庫組合解決方案——這意味著每個 AI 生成的函式,可能拉進開發者自己壓根沒選過的依賴套件。
Black Duck 的發現並非孤立現象。多份約略同期發布的獨立調查,用更細緻的數據印證並延伸了這幅信任圖像:
這些調查的共識極其一致:開發者不能沒有 AI 工具,但也無法全然信任它們。生成與驗證之間的鴻溝,已成為新的瓶頸。
Black Duck 給出的藥方並非抽象概念。報告點出幾項具體措施,區隔了那 30% 完整治理的組織與其他團隊:
Black Duck 報告並非反對使用 AI 編碼助手。它反對的是,用 AI 卻不給予對等的治理。當 97% 團隊以前所未有的速度生成程式碼,卻只有 30% 擁有管理它的監管基礎架構,這個產業等於是在集體開出自己無法兌現的支票。
治理與效率增益之間的相關性——90% 對比 44%——讓商業決策毫無模糊空間。先蓋好護欄的組織,才能抓住 AI 承諾的生產力。而那些不做的人,將反覆發現:在鍵盤前省下的時間,終究要在審查佇列中償還。
Comments
0 comments