AI編碼助理大獲全勝，但安全治理的硬仗才剛開打

在Salt的受訪者中，29%的人直指不安全的編碼模式為首要風險，另外有15%的人則將程式碼與內部安全政策不一致當成最大的隱憂 。這兩種恐懼其實源自同一個病灶：AI編碼助理是在公開程式碼上訓練出來的模型，它並不了解任何個別組織的內部安全政策、行業框架或合規要求 。

安全漂移：當程式碼悄悄「飄」進正式環境，卻沒人發現

Salt報告定義了「安全漂移」這個概念，解釋為何這個普及矛盾會演變成真實的曝險。原理很簡單：一家組織將安全規則寫在維基頁面、PDF檔案和口耳相傳的「部落知識」裡，而AI助理根本沒有閱讀過這些東西。當它生成出一段語法正確、功能合用的程式碼時，這行程式碼可能已默默地違反了那些內部政策。由於審查流程早已追不上程式碼產生的速度，所以根本沒人會抓出來 。

這帶出了Salt報告中最具行動意義、也最令人憂心的治理數字：當今仍有38%的組織，主要依賴人工程式碼審查（Code Review）來處理AI編碼助理產出的海量程式碼。AI程式碼的產量早已超過人類審查者能有意義檢視的規模，而Salt預測到2027年，這道產能與監督之間的鴻溝只會更進一步擴大 。目前只有極少數的組織，真正將自動化的安全護欄整合進AI編碼的開發工作流程之中 。

Salt Security執行長羅伊·埃利亞胡（Roey Eliyahu）對這個局勢下了個直接的總結：安全治理 完全跟不上 AI編碼助理改變軟體開發方式的步調 。傳統的靜態與動態分析工具（SAST/DAST）總是在開發的最後階段才發現問題，而那時候，每一次修補都是大規模的改寫，每一次改寫都代表進度延宕 。

METR的驚人發現：感覺變快，實測卻變慢

安全治理並非唯一出現「認知與現實脫節」的領域。Salt報告特別引述了一份來自外部、如今已成為開發者工具辯論重要參照點的研究：非營利研究組織METR在2025年7月發表的隨機對照試驗 。

這項研究找了16位經驗豐富的開源開發者，讓他們在自己長期維護的成熟程式庫上，進行246項真實世界的任務——這些程式庫平均擁有超過百萬行程式碼，並獲得上萬顆GitHub星星。參與者被隨機分配，一組能使用AI工具（主要是Cursor Pro搭配Claude 3.5/3.7 Sonnet），另一組則完全不能使用 。

這項研究最常被引用的結論，由於曝光度極高，已經快要變成一種背景雜音，但其數據依然相當驚人：能使用AI輔助的開發者，任務完成時間比完全沒用AI的開發者慢了19%。然而，在實驗開始前，這些受測者原本預測AI能讓他們快24%；任務完成後，他們則主觀估計AI大概讓自己快了20%。客觀碼表測出的結果與他們的感受之間，足足有超過39個百分點的落差 。

METR的這項發現，並不等於宣告AI工具一無是處——情境非常關鍵。在協助新人上手、產生重複性樣板程式碼（Boilerplate），或是開發者較不熟悉的程式碼區塊等場景中，確實能觀察到生產力提升。但是，對於在複雜、高度仰賴對既有程式庫理解度的任務上工作的資深工程師，證據顯示當前的AI工具可能帶來了一種他們自己並未察覺到的摩擦力 。

Salt Code登場：直接在提示階段就強制執行規則，而非等到測試階段才發現

Salt選在研究報告發布的同一時間，推出一款直面報告所指「治理鴻溝」問題的新產品。2026年6月1日，該公司正式發表了 Salt Code，這是其AI代理安全平台（Agentic Security Platform）中的一項全新組件 。

Salt Code的策略，是直接在安全漂移開始之前就阻止它發生。與其等到AI生成程式碼之後才進行掃描，它選擇在開發者使用AI編碼助理的當下，直接將組織的內部安全與合規規則，強制注入到程式碼產生的那一刻。這款產品能相容於當前企業陸續標準化的各大AI編碼工具：Claude Code、Cursor、GitHub Copilot、Windsurf、Codex以及Gemini CLI 。

它的目標，是讓產出「符合政策的程式碼」內建為AI助理的預設行為，而不是一個需要仰賴下游掃描與大翻修才能達成的目標。對安全團隊而言，它提供了一個可貫穿程式碼產出、開發管線檢查及運行時監控的單一政策層——這是一個從「抓Bug」轉向「預防Bug」的巨大思維轉變 。

Salt Code這類工具能否以AI普及的速度，成功填補這道治理鴻溝，仍是個懸而未決的問題。但未來的走向是清晰的。如果預測成真——AI將在未來18個月內寫出超過一半的企業程式碼——那麼，安全政策就必須從「審查階段」的守門員，進化為「預設強制執行」的出廠設定。否則，正如Salt報告所警告的那樣，人類將面臨的是，一場規模難以想像的「產業級安全漂移」。