风险从哪来
AI 编程助手倾向于生成「能跑就行」的代码，而安全往往不是它的默认目标。当提示里没有约束时，它可能写出拼接 SQL 的查询、明文存储的密码、或暴露内部错误的接口。便利与漏洞之间，常常只差一句没有明确的要求。
三个常见陷阱
- 注入类漏洞：直接拼接用户输入到 SQL / 命令 / HTML，缺少参数化与转义；
- 硬编码密钥：把 API Key、数据库密码写进源码，随后被提交到仓库；
- 依赖投毒： blindly 接受 AI 推荐的冷门第三方包，未核验来源与维护状况。
用提示把安全前置
与其事后修漏洞，不如在提示里写明约束：使用参数化查询、密钥走环境变量、输入做白名单校验、错误不暴露内部细节。
把安全规则写进 CLAUDE.md 或 .cursorrules，让每次生成都默认遵守，比靠记忆更可靠。
人工审查清单
- 所有外部输入是否都经过校验与转义？
- 是否有密钥被写死在代码或配置里？
- 依赖是否来自可信、活跃维护的源？
- 错误信息是否泄露了堆栈或内部路径？
小结
AI 降低了写代码的门槛，但没有降低安全的门槛。把安全当成提示的一部分、审查的一项、习惯的一种，便利才不会变成漏洞。