@TOC
AI 写完一段代码，最危险的不是「写错了」，是「看起来很对」。
类型能编译、命名也规范、注释还像那么回事——于是你直接提交。一周后审计或线上事故，才发现注入、越权、密钥硬编码这类问题，早就埋进去了。
这篇不讲完整安全体系，只讲一件事：AI 刚生成完代码的那 5 分钟，你该按什么顺序看。 附一份可复制 Prompt，以及我踩过的假阳性坑。
一、为什么「看起来对」更危险
人写代码时，危险操作往往会犹豫一下：这串 SQL 要不要参数化？这个接口要不要鉴权？
AI 不会犹豫。它按训练里的「常见写法」往外吐，常见写法里既有正确范式，也有大量半成品样例。结果是：
| 现象 | 后果 |
|---|---|
| 代码风格整齐 | 降低你的警惕 |
| 能跑通 happy path | 边界和失败路径常缺 |
| 注释写得很自信 | 容易把假设当成事实 |
所以安全审查不能等「感觉不对」才启动，得当成生成后的固定步骤。
二、5 分钟自查清单
按优先级排，别从上扫到下平均用力。时间紧就只做前三项。
1. 密钥与敏感信息（约 1 分钟）
搜这些模式（按你语言改一下即可）：
password|secret|api[_-]?key|token|private[_-]?key
AKIA[0-9A-Z]{16}
-----BEGIN (RSA |OPENSSH )?PRIVATE KEY-----
重点看：
- 有没有把真实密钥写进源码或测试夹具
- 有没有把
.env内容粘进注释「方便调试」 - 日志里有没有打印完整 token / 身份证号 / 手机号
AI 特别爱在示例里写 sk-xxxx、password123。示例可以留，真值不行。
2. 注入面（约 1 分钟）
按技术栈扫一类即可：
| 栈 | 优先看 |
|---|---|
| SQL | 字符串拼接查询、fmt.Sprintf 拼 WHERE |
| Shell | os/exec、Runtime.exec、拼接命令行 |
| 前端/模板 | innerHTML、未转义的模板插值 |
| 路径 | filepath.Join 后直接打开用户可控路径 |
判断标准很简单：用户可控输入有没有直接拼进解释器语句。 有，就改成参数化 / 白名单 / 转义。
3. 鉴权与越权（约 1 分钟）
对每个新增/改动的接口问三句：
- 谁可以调用？（匿名 / 登录用户 / 管理员）
- 资源 ID 从哪来？（路径参数、body、还是 session）
- 有没有校验「这个资源属于当前用户」？
典型翻车：AI 写了 GET /orders/{id}，查库用了 id，但没校验 order.UserID == currentUser。功能测看起来正常，换个账号就能拖别人的单。
4. 错误信息与日志（约 1 分钟）
看返回给客户端的错误：
- 是否把堆栈、SQL、内部路径直接回给浏览器
- 认证失败是否区分「用户不存在」和「密码错误」（便于撞库）
- 是否在日志里记录了请求体里的密码字段
5. 依赖与默认配置（约 1 分钟，可跳过）
- 新引入的包是不是冷门、很久没更新的
- 有没有关掉 TLS 校验（
InsecureSkipVerify、verify=False） - CORS 是不是
*还顺便带了 credentials
三、可复制审查 Prompt
自查做过一轮后，把 diff 或相关文件丢给 AI，用这段（按需改语言/框架）：
你是代码安全审查员，不是功能评审员。
只根据我提供的变更检查安全问题，不要建议重命名、格式化或「优化可读性」。
检查范围（按优先级）：
1. 密钥/凭证硬编码与敏感日志
2. 注入（SQL / 命令 / 模板 / 路径穿越）
3. 鉴权缺失与水平/垂直越权
4. 不安全的反序列化、SSRF、开放重定向（如相关）
5. 错误信息泄露与危险默认配置
输出格式：
- 严重程度：高 / 中 / 低
- 位置：文件 + 函数/行附近特征
- 问题：一句话说明风险
- 利用前提：攻击者需要什么条件
- 修复建议：最小改动，给出改法要点，不要整文件重写
规则：
- 没有证据不要猜；不确定就标「需人工确认」
- 不要为了凑条数输出风格类意见
- 若某类问题未发现，明确写「未发现」
用法注意：
- 一次只喂相关 diff，别把整个仓库砸进去
- 改动超过约 400 行就拆批，否则后半段会敷衍
- 它说「高」不等于真高，对照第二节清单人工过一眼
我在 wescode 里通常是：生成代码 → 自己过清单前三项 → 把 staged diff 丢进 Chat 跑上面这段 Prompt。顺序别反：先人后机，机器负责补漏，不负责拍板。
四、三个假阳性坑
坑 1：把测试夹具当成生产密钥
AI 常报：testdata/config.json 里有 api_key。若明确是假值且不进发布包，可以标低或忽略；真要管的是「假值模板被复制进生产配置」的流程问题。
坑 2：把「未用 ORM」当成注入
有的审查会看到手写 SQL 就喊注入。手写 SQL + 占位符是安全的；危险的是拼接。看有没有 ? / $1 / named param，别只看「写了 SQL」。
坑 3：业务规则被当成安全漏洞
「管理员可以删任意用户」可能是产品设计，不是越权。安全审查要分清：身份校验缺失 vs 权限模型本身就很大。后者该找产品确认，不该让 AI 擅自改成「谁都不能删」。
五、什么时候不用走全套
纯文案、注释、CSS 微调。 扫一眼有没有误贴密钥就行。
已有完善 SAST + 依赖扫描的流水线，且本次改动极小。 机器扫描过了，你补「鉴权语义」那一分钟即可。
明确的 spike / 一次性脚本，不进主分支。 仍建议搜一下密钥，其他可放宽——但别把 spike 代码合并进主干时忘记补查。
小结
AI 生成代码的安全问题，核心不是「模型会不会写漏洞」，而是生成物会降低你的警惕。
固定动作就三步：
- 5 分钟清单（密钥 → 注入 → 鉴权优先）
- 用约束过的 Prompt 让 AI 补漏
- 人对「高」级别结论做最终判断
把安全审查做成生成后的肌肉记忆，比追一个「绝对安全的 AI」现实得多。
上面的清单和 Prompt 我是在日常 AI 编程流程里用的，工具侧用的是 wescode，官网是 weisyn.com。你们还有哪些「AI 生成后必看」的检查项，欢迎评论区补充。
