安全审查关卡
下面这一个习惯，能把上面所有这些从一桩忧虑变成一道流程：在你上线之前，让 AI 去攻击它自己的代码。 那个写出这个功能的模型，通常自己就能找出其中的漏洞——只是你不问，它就不找。把它从建造者翻转成对手：
你写了这个接口。现在扮演一个试图攻破它的攻击者。
列出一个恶意用户可以用来达成下列目的的每一种方式：
- 读取或修改他们不该碰的数据（授权漏洞）
- 通过输入注入代码（SQL injection、XSS、命令注入）
- 滥用缺失的校验或速率限制
对每一种，给出能利用它的确切请求，然后给出修复办法。
不要安慰我——假定这里就是有一个漏洞，把它找出来。
最后那一行很关键：放任不管的话，AI 倾向于说“看起来很安全！”。被要求假定缺陷存在时，它才会真的去找。把这一次对抗性审查，和一份你对任何面向用户的东西都跑一遍的简短上线前清单配套使用：
- 每个接口都检查了授权，而不只是用户已经登录
- 所有数据库查询都是参数化的——没有字符串拼出来的
- 渲染到页面上的用户输入都做了转义（没有原始 HTML 注入）
- 客户端代码里没有密钥，也没有任何密钥被提交进仓库
-
.env已被 gitignore；任何泄露过的密钥都已轮换 - 文件上传会校验类型和大小、并使用生成的文件名
- 新依赖都被亲眼核对过是否真实存在、口碑如何
把这道关卡想象成一个不通过就什么都发不出去的流程。AI 从建造者切换成攻击者的帽子，然后自动扫描兜住人工那一遍可能漏掉的东西：
功能代码
│
▼
┌──────────────────┐ "假设确实存在漏洞,去找它"
│ 对抗式审查 │ 授权漏洞 · 注入 · 输入校验问题排查
│ (AI当攻击者) │
└────────┬─────────┘
│ 发现问题? ── 是 ──▶ 修复 ──┐
│ 否 │
▼ │
┌──────────────────┐ ◀─────────────────── ┘
│ 自动化关卡 │ 密钥扫描(gitleaks) · npm audit
│ (CI, 每次push) │ 是否已参数化? · 密钥是否在客户端之外?
└────────┬─────────┘
│ 全部绿灯
▼
SHIP ✓ ── 任何红色都会拦截本次推送 ──
并且在 push 之前跑一个密钥扫描器——像 gitleaks 这样的工具（或者你平台内建的扫描）会在你的代码和历史里搜寻形似密钥的东西。它是一道一条命令就能就位的安全网，对应的正是这份清单上代价最昂贵的那个错误；你还可以让 AI 把它接进 （Continuous Integration，持续集成——那个在你每次推送代码时自动替你跑各项检查的机器人），这样每次 push 都会自动跑。