目录一、为什么「看起来对」更危险二、5 分钟自查清单1. 密钥与敏感信息约 1 分钟2. 注入面约 1 分钟3. 鉴权与越权约 1 分钟4. 错误信息与日志约 1 分钟5. 依赖与默认配置约 1 分钟可跳过三、可复制审查 Prompt四、三个假阳性坑五、什么时候不用走全套小结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拼 WHEREShellos/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、verifyFalseCORS 是不是*还顺便带了 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 生成后必看」的检查项欢迎评论区补充。 AI 生成代码后的安全自查清单（5 分钟版）+ 可复制 Prompt
目录一、为什么「看起来对」更危险二、5 分钟自查清单1. 密钥与敏感信息约 1 分钟2. 注入面约 1 分钟3. 鉴权与越权约 1 分钟4. 错误信息与日志约 1 分钟5. 依赖与默认配置约 1 分钟可跳过三、可复制审查 Prompt四、三个假阳性坑五、什么时候不用走全套小结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拼 WHEREShellos/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、verifyFalseCORS 是不是*还顺便带了 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 生成后必看」的检查项欢迎评论区补充。