当AI开始写代码，谁来为安全兜底？

在Salt的调查中，29%的受访者将“不安全的编码模式”列为首要风险，另有15%的人表示最担心生成的代码与内部安全政策不一致 。这两种担忧实则同源：AI编码助手是基于海量的公开代码训练的，而不是基于某个企业自身的安全政策、行业框架或合规要求训练的 。

安全漂移：当漏洞在无人察觉中上线

“安全漂移”是Salt报告用来解释这种“普及悖论”如何演变成真实风险的机制。原理很直接：一家企业把自己的安全规则写在Wiki、PDF和开发者的头脑里，而AI助手从未读过这些。它生成的代码语法正确、功能管用，但却悄无声息地违反了内部的安全策略。因为人工审查流程根本追不上AI生成代码的速度，谁也没发现 。

这让Salt得出了报告中最具操作性——也最令人警醒——的发现之一。38%的组织仍然主要依赖人工代码审查来应对AI编码助手的输出。如今AI生成的代码量已远超人工审查员能承受的合理负荷，而Salt对2027年的预测表明，这个缺口只会越来越大 。只有极少数的组织将自动化的安全护栏整合到了AI编程的工作流中 。

Salt Security的CEO Roey Eliyahu对此的总结毫不留情：安全治理完全跟不上AI编码助手改变软件开发方式的步伐。传统的静态和动态分析工具（SAST/DAST）只能在开发管道后期发现问题，那时每一次修复都意味着一次重写，每次重写都是一次延期 。

METR的认知鸿沟：感觉更快，实则更慢

安全治理并非感知与现实产生背离的唯一领域。Salt报告着重提及了一项外部研究的发现，它已成为开发者工具圈争论的风向标：这项研究，就是AI安全研究机构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工具一无是处——使用场景至关重要。在帮助新人上手项目、生成常规样板代码，以及处理开发者不那么熟悉的代码库任务时，确实能观察到效率提升。但对于在复杂、高度依赖代码库上下文的任务中工作的资深工程师而言，证据显示这些工具引入了一种开发者主观上意识不到的“摩擦力” 。

Salt Code：在源头制定规则，而非管道末端补救

Salt Security几乎在发布报告的同时，推出了一个旨在填补这一治理缺口的全新产品。2026年6月1日，该公司发布了Salt Code，作为其“智能体安全平台（Agentic Security Platform）”的新组件 。

Salt Code的策略是，在安全漂移发生前就将其阻断。它不是在AI生成代码之后进行扫描，而是在开发者使用AI编码助手生成代码的那一刻，直接将企业内部的安保与合规规则嵌入到工具中。该产品覆盖了当前企业主流的AI编程助手：Claude Code、Cursor、GitHub Copilot、Windsurf、Codex以及Gemini CLI 。

其目标是，让生成符合安全策略的代码成为AI助手的默认行为，而不是一件需要下游扫描、耗时返工的事情。对安全团队而言，它提供了一个贯穿代码创建、管道检查和运行时监控的统一策略层——这代表了一种从“捕捉错误”到“预防错误”的思维转变 。

Salt Code或同类工具能否以AI普及的速度填补治理缺口，目前仍是未知数。但前进的方向是明确的。如果预测成真，即未来18个月内AI将编写超过一半的企业代码，那么安全策略就必须从现在“审查阶段的一道工序”，转变为AI的“出厂默认设置”。否则，Salt报告所警告的，将是在整个行业范围内、工业化量级上演的“安全漂移”。