夜雨聆风当大家还在盯着 AI 编程助手能把开发速度提升多少时，这篇即将登上 SOUPS 2026 的研究，抛出了一个更扎心的问题：它们会不会正在改变开发者看待安全的方式？
答案有点出乎意料。研究团队采访了 15 名职业软件工程师，并观察他们在使用 AI 辅助完成安全相关编码任务时的真实行为，结果发现，AI 编程助手并没有简单地“削弱”安全意识，而是把安全思维从“写代码时顺手做掉”，推迟到了“代码写完以后再去检查”。
换句话说，安全从前是前置动作，现在越来越像补作业。
更关键的是，没有一位参与者在初始提示里主动提出安全要求，哪怕他们明明知道相关风险。论文把这种现象概括得很精准：安全意识和安全行为正在脱钩。
开发速度起飞了，安全却被落在了后面
AI 编程助手已经成了职业开发的日常工具，像 GitHub Copilot、ChatGPT、Claude 这类系统，正在快速进入工程师的工作流。大家都知道它们能提效，但问题在于，提效不等于更安全。
此前研究早就敲过警钟：
• GitHub Copilot 生成的代码，在高风险场景下约有 40% 存在可利用漏洞• 有了 AI 助手的开发者，写出的代码反而更不安全，而且他们还更容易高估自己代码的安全性
这就说明，风险不只在代码本身，也在开发者的认知和习惯里。
这篇论文想回答的正是这个更深的问题：AI 编程助手到底是怎么改变开发者的安全意识和安全行为的？
这不是“会不会用”的问题，而是“你在什么时候想起安全”的问题
研究团队没有只看代码结果，而是走进了真实开发场景，做了两件事：
1. 对 15 名职业软件工程师进行半结构化访谈2. 让他们在 AI 辅助下完成带有安全相关性的编码任务，并进行现场观察
这些参与者还被分成了三类：
• 前 AI 时代开发者：职业训练发生在大语言模型工具普及之前• AI 时代开发者：先接受传统训练，后来在工作中逐步拥抱 AI• AI 原生开发者：从职业起点开始就一直处在 AI 工具环境里
研究最有意思的地方在于，它不是问大家“你觉得安全吗”，而是观察大家到底在什么时候想到安全、怎么想到安全、有没有真的把安全写进提示词里。
结论很明确：AI 没有抹掉安全思考，但它重排了安全思考的出现时机。
安全不再是“写代码时的本能”，而变成了“评审时的补救”
论文里最核心的发现，可以用一句话概括：
AI 编程助手把安全思维，从创作阶段，推到了审查阶段。
以前，安全更像是开发者在动手写代码时就顺手纳入的习惯，比如输入校验、权限检查、数据清洗。 现在，很多开发者的工作方式变成了：
• 先让 AI 把功能写出来• 再回头检查有没有安全问题• 如果有，再修
这意味着安全从“预防型”变成了“反应型”。
这种转变不是偶然，而是 AI 编程助手的交互方式天然推动的。 因为这类工具通常把任务定义成“功能生成”，默认优先满足能不能跑、像不像样，而不是先问一句：这段代码安全吗？
于是，安全就被悄悄放到了最后。
最扎心的一刀：知道有风险，不代表会写进提示词
论文里有个非常值得企业安全团队警惕的现象。
不少参与者在访谈中明明能清楚说出安全风险，比如权限控制、敏感信息泄露、硬编码密钥之类的问题，但当他们真正进入编码任务时，没有一个人在最初提示里主动加入安全要求。
这说明什么？
说明很多开发者并不是“不懂安全”，而是安全知识没有顺利转化为提示习惯。
这就是论文所说的“提示鸿沟”。 开发者脑子里知道安全重要，但在和 AI 互动时，第一反应还是先让它把功能做出来。安全，等后面再说。
问题在于，后面往往就没那么多时间了。
开发者对 AI 的态度很像对一个“有点能干但不完全靠谱的同事”
研究里有个特别形象的比喻，几乎所有人都能理解：
很多开发者把 AI 当成“一个比我稍微初级一点的同事”。
这意味着什么？
• 不能完全信• 但也不能不用• 输出要看• 关键处还得自己兜底
这种认知其实很健康，但现实里它并不总能转化为真正的安全行为。
因为在访谈里，大家普遍都说自己会认真看代码、会复查、会测试。 但到了实际编码环节，很多人还是没有把安全显式写进提示词。
也就是说，开发者口头上很清醒，操作上却常常默认了“先生成，后检查”的流程。
真正会抓漏洞的人，往往不是“最资深”的那批人
这篇论文还有一个很反直觉的发现：
经验年限并不能可靠预测谁更能在 AI 辅助开发中守住安全底线。
在编码任务里，只有两位参与者主动识别出了未被提示的安全问题：
• 一位来自 AI 时代组• 一位来自前 AI 时代组
也就是说，不是谁更老练，谁就更会在 AI 场景下发现漏洞。
真正拉开差距的，是两件事：
1. 有没有扎实的安全知识2. 有没有主动追问 AI 的习惯
这就很现实了。 AI 时代的安全能力，不再只是“干了多少年”，而是“你会不会问对问题”。
有些开发者已经在自发“自救”了，但工具和组织还没跟上
研究里最有价值的一部分，不只是发现了问题，还挖出了开发者们自己发明的应对策略。
这些策略包括：
• 限制 AI 智能体权限• 先写提示模板，把安全约束放进去• 每次生成完后，专门追问 AI 还有没有安全问题• 不接受大段批量修改，而是一条条看
这些做法很朴素，但挺有效。 问题是，它们几乎都不是工具自带能力，也不是组织统一要求，而是开发者自己摸索出来的。
这意味着什么？
意味着安全责任正在被悄悄下放给个人的自觉性。 而在真实企业环境里，这种依赖个人经验的方式，往往最不稳定。
为什么开发者会越来越依赖 AI，却又越来越难守住安全？
论文给出的解释，不是“开发者变懒了”，也不是“大家不重视安全了”。 更准确地说，这是一个结构性问题。
因为当前 AI 编程助手的设计逻辑，本来就不是围绕安全展开的，而是围绕“快速生成可用代码”展开的。
于是开发者一旦进入这种交互模式，就很容易形成一种习惯：
• 先要功能• 再管安全• 能跑就行• 细节以后再补
这不是某个人粗心，而是整个工具交互方式在引导这种行为。
对企业安全团队来说，这篇论文最值得记住的三件事
1. 安全意识不等于安全行为
开发者知道风险，不代表他们会在第一时间把风险写进提示词。
2. 经验年限不是可靠护栏
老工程师不一定比新人更会在 AI 场景下识别漏洞。
3. 组织不能只催速度，还得补安全流程
如果企业只是推动大规模使用 AI 编程助手，却没有同步建立安全提示、审查和权限控制机制，那风险只会被更快地放大。
这项研究对行业的意义，不止是“提醒注意安全”
它真正有价值的地方在于，把讨论从“AI 会不会生成漏洞”推进到了更深一层：
AI 到底在怎样重塑开发者的安全习惯？
这会直接影响三类实践：
• 工具设计：安全应该在生成流程里前置，而不是等代码写完再补提醒• 培训体系：要教开发者如何在提示阶段就表达安全需求• 组织政策：要明确哪些信息不能随便喂给 AI，哪些场景必须人工复核
换句话说，未来真正需要升级的，不只是模型能力，而是人、工具、流程三者之间的安全协作方式。
结尾：AI 编程助手不是让安全消失了，而是让安全换了位置
这篇论文最重要的结论，并不是“AI 很危险”，也不是“AI 很好用”，而是：
AI 编程助手正在把安全从前置习惯，改造成后置补救。
这件事听起来只是流程变了，实际上会深刻影响软件质量、上线速度和企业风险暴露面。
如果开发者习惯了先生成再检查，安全就很容易变成“有空再说”。 而一旦这种习惯在团队里扩散，漏洞就不只是代码里的问题，而是工作方式里的问题。
你觉得，在你的团队里，AI 编程助手更像“提效神器”，还是正在悄悄改变大家对安全的重视方式？欢迎一起聊聊。
2026 RSAC 创新沙盒十强深度调研：智能体安全的颠覆者与奠基者
Token Security：8个月完成A轮，这家以色列公司凭什么？
AI安全周报：80%技能名不副实，智能体正沦为黑客“提线木偶”？
本周Arxiv论文深度解读：Agent安全三大“核弹级”漏洞曝光