最近和一个做后端的小伙子聊天，他说他们团队新功能有一半的样板代码直接让编程助手生成，人只负责 review。听起来效率拉满，但上周一次渗透测试，把三处明显的安全漏洞全标红——全都是 AI 写的。这事不是个例。随着 Cursor、Claude Code、GitHub Copilot 这类工具进到日常开发，一个被忽视的问题正在浮出水面：AI 帮我们写得越快，欠下的"安全债"可能越多。
表面看，编程助手只是把人从重复劳动里解放出来。但模型在生成代码时，优化目标是"大概率正确且符合上下文"，而不是"绝对安全"。它对常见的 SQL 注入、越权访问、密钥硬编码这类坑，并不总是主动规避——尤其是当你的需求描述里没提安全约束时，它会顺着最省事的写法走。举个例子，让助手"写个用户登录接口"，它很可能直接返回一个不带速率限制的 token，或者把密码明文写进日志，因为训练数据里大量现成代码就是这么干的。
更深一层，这和开发流程的变化有关。过去代码是人一行行敲的，出问题往往能追溯到具体的人和经验盲区；现在代码是批量生成的，review 的人反而成了瓶颈。人会本能地信任"模型生成的、能跑通"的代码，懒得逐行审计。可一旦这些代码进了生产，漏洞就跟着上线了。有预测说未来几年 AI 生成代码引发的安全事件会明显上升——这不是吓唬人，而是"产量翻倍的副作用"。
对普通开发者，最实在的影响是：别把编程助手当"免检通道"。两个动作现在就能做——第一，在给助手的需求里显式加上安全约束，比如"注意防 SQL 注入、不要硬编码密钥"；第二，把静态扫描（SAST）接进 CI，让机器去查机器写的代码。对个人来说，学会读 diff、查关键路径，比盲目信任生成结果重要得多。
对团队和决策者，这件事的代价会在明年集中体现。一个中等规模系统，假设三成代码由 AI 生成且未经严格审计，按漏洞密度估算，潜在修复成本可能是当初"省下"的开发时间的数倍。安全债和金钱债一样，拖得越久利息越高。所以现在的共识正在变：AI 写代码可以，但审计环节不能省，甚至要加码。
话说回来，编程助手本身也在进化，像 Claude Code 企业版已经开始把权限控制和审计日志做成标配。工具会变好，但"生成即信任"的习惯，得靠我们自己先改掉。下次让助手写完代码，先问一句：它有没有偷偷埋雷？