AI 辅助编码不能替代安全经验：一项 Gemini 编程研究的启发
arXiv 上一篇 2026 年 3 月的论文研究了 Gemini 对安全相关编程任务的影响。研究对象是 159 名开发者，任务是完成一个安全相关的编程问题，并比较不使用 AI、使用免费版 Gemini、使用付费版 Gemini 的差异。
论文的一个重要结论是：研究没有观察到使用 Gemini 在安全开发结果上的显著差异，而开发者自身的编程经验会显著改善代码安全性。换句话说，AI 可以辅助开发，但不能直接替代安全经验。
这项研究为什么重要
现在很多团队在引入 AI 编程工具时，会默认它能提高效率。但安全问题不是只看速度。
一个功能写得更快，并不代表更安全。AI 可能生成看似合理的代码，但遗漏边界检查、输入校验、权限判断、错误处理和日志保护。更麻烦的是，AI 生成的代码通常很流畅，容易让 review 者降低警惕。
这项研究提醒我们：AI 辅助编码的价值需要拆开看。它可能提高完成速度、降低入门门槛、帮助解释 API，但安全质量仍然依赖开发者是否知道该检查什么。
AI 在安全编码中的典型问题
第一，AI 容易给出“常见写法”，但常见写法不一定安全。例如直接拼接 SQL、弱校验输入、过宽的异常捕获、把敏感信息写入日志。
第二，AI 不一定理解业务风险。安全问题经常和业务语义有关，例如某个字段能不能被普通用户修改，某个接口是否允许越权访问。这些信息往往不在代码片段里。
第三，AI 可能漏掉环境约束。真实系统有框架版本、部署拓扑、认证方式、审计要求和合规边界。脱离这些上下文，生成的修复方案可能不完整。
团队应该怎么用 AI 写安全相关代码
不要把 AI 当成安全负责人，而要把它当成辅助执行者。
一个更稳妥的流程是：
- 先让 AI 明确列出潜在风险点，而不是直接写代码。
- 要求它说明输入、权限、异常、日志、加密、依赖版本这些检查项。
- 生成代码后，必须配套测试，包括正常路径和攻击路径。
- 对认证、授权、支付、个人信息、文件上传等模块保持人工 review。
- 对高风险改动运行静态扫描、依赖扫描和安全测试。
这样使用 AI，能把它的优势放在“辅助分析和生成候选方案”，而不是让它直接承担最终安全判断。
给个人开发者的建议
如果你经常用 AI 写代码，可以建立一个固定提示模板。
请从安全角度 review 这段代码。重点检查输入校验、权限控制、敏感信息泄露、错误处理、并发问题和依赖风险。不要直接修改代码，先列出风险、证据和建议测试方式。这类提示比“帮我看看有没有问题”更有效，因为它把检查方向说清楚了。
同时，不要只让 AI 写 happy path 测试。安全问题往往出现在异常输入、越权身份、重复请求、并发提交和边界值里。
我的判断
AI 辅助编码会继续提高研发效率，但安全质量不会自动提升。真正可靠的做法是把 AI 放进安全开发流程：让它帮助发现风险、生成测试、解释代码，但最终仍由工程规范、自动化检查和有经验的人来兜底。
对团队来说，AI 编程时代更需要安全基线，而不是更少的安全训练。
参考资料
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！