AI編碼助手贏咗場仗，但安全之戰先啱啱開始

喺Salt嘅受訪者入面，有29%認為唔安全嘅編碼模式係最大風險，另有15%就話最擔心嘅係生成代碼同公司內部安全政策唔夾 。兩種擔心都源於同一個根本原因：AI編碼助手嘅訓練素材係公開代碼，而唔係任何一間公司自己嘅安全政策、行業框架或者合規要求 。

安全漂移：冇人知自己出咗咩貨

報告入面提出咗「安全漂移」呢個概念，解釋點解速度同監控嘅脫節會變成實際嘅安全漏洞。個邏輯好簡單：公司將安全規則寫晒喺Wiki、PDF文件同埋老臣子嘅腦入面，但AI助手從來唔會去睇。於是個助手就生成咗一堆語法冇錯、功能正常，但靜靜雞違反晒內部政策嘅代碼。因為審查流程根本追唔上生產速度，結果冇人發現到問題 。

呢度帶出咗Salt報告入面其中一個最實用、同時亦都最得人驚嘅發現：有38%嘅機構，仍然主要依賴人手代碼審查去處理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%。做完晒任務之後，佢哋估計呢啲工具令佢哋快咗大約20%——但客觀嘅量度數據就顯示佢哋係慢咗。覺得自己快咗同實際上係慢咗之間，個差距超過39個百分點 。

METR嘅發現並唔代表AI工具冇用——要睇情況。喺新人上手、例行嘅樣板代碼生成，或者開發者對個代碼庫冇咁熟嘅任務入面，確實見到生產力提升。但對於要處理複雜、極度依賴對代碼庫理解嘅任務嘅資深工程師嚟講，證據就話畀我哋知，呢啲工具可能會帶嚟一啲開發者自己都唔為意嘅阻力 。

Salt Code：直接喺輸入提示階段就做好把關

Salt揀喺發布研究報告嘅同一時間，推出咗一個專為解決報告所講嘅治理缺口而設計嘅產品。2026年6月1號，佢哋推出咗Salt Code，呢個係佢哋更大型嘅「智能體安全平台」嘅一個新組件 。

Salt Code嘅做法係喺安全漂移出現之前就阻止佢。佢唔係事後先掃描AI生成嘅代碼，而係直接喺開發者用AI編碼助手生成代碼嗰一刻，就強制執行公司內部嘅安全同合規規則。呢個產品可以喺現時企業主流採用嘅工具上運作，包括：Claude Code、Cursor、GitHub Copilot、Windsurf、Codex同Gemini CLI 。

個目標係令到符合政策嘅代碼成為預設輸出，而唔係要靠下游嘅掃描同重寫先做到。對安全團隊嚟講，佢提供咗一個單一嘅政策層，可以貫穿代碼創建、流程檢查同執行期間監控——由「捉錯誤」轉變成「預防錯誤」 。

Salt Code或者類似嘅工具，係咪可以快到追得上AI採用嘅速度，去修補呢個治理缺口，而家仲係一個未知數。不過個大趨勢已經好清楚。如果個預測係啱嘅——AI喺十八個月內將會編寫超過一半嘅企業代碼——咁安全政策就一定要由「審查關卡」，進化到成為「預設配置」。Salt報告警告，如果唔係咁，就係一場工業規模級別嘅安全漂移。