安全審查關卡
下面這一個習慣，能把上面所有這些從一樁憂慮變成一道流程：在你上線之前，讓 AI 去攻擊它自己的程式碼。 那個寫出這個功能的模型，通常自己就能找出其中的漏洞——只是你不問，它就不找。把它從建造者翻轉成對手：
你寫了這個介面。現在扮演一個試圖攻破它的攻擊者。
列出一個惡意使用者可以用來達成下列目的的每一種方式：
- 讀取或修改他們不該碰的資料（授權漏洞）
- 通過輸入注入程式碼（SQL injection、XSS、命令注入）
- 濫用缺失的校驗或速率限制
對每一種，給出能利用它的確切請求，然後給出修復辦法。
不要安慰我——假定這裡就是有一個漏洞，把它找出來。
最後那一行很關鍵：放任不管的話，AI 傾向於說“看起來很安全！”。被要求假定缺陷存在時，它才會真的去找。把這一次對抗性審查，和一份你對任何面向使用者的東西都跑一遍的簡短上線前清單配套使用：
- 每個介面都檢查了授權，而不只是使用者已經登入
- 所有資料庫查詢都是引數化的——沒有字串拼出來的
- 渲染到頁面上的使用者輸入都做了轉義（沒有原始 HTML 注入）
- 客戶端程式碼裡沒有金鑰，也沒有任何金鑰被提交進倉庫
-
.env已被 gitignore；任何洩露過的金鑰都已輪換 - 檔案上傳會校驗型別和大小、並使用生成的檔名
- 新依賴都被親眼核對過是否真實存在、口碑如何
把這道關卡想像成一個不通過就什麼都發不出去的流程。AI 從建造者切換成攻擊者的帽子，然後自動掃描兜住人工那一遍可能漏掉的東西：
功能程式碼
│
▼
┌──────────────────┐ "假設確實存在漏洞,去找它"
│ 對抗式審查 │ 授權漏洞 · 注入 · 輸入校驗問題排查
│ (AI當攻擊者) │
└────────┬─────────┘
│ 發現問題? ── 是 ──▶ 修復 ──┐
│ 否 │
▼ │
┌──────────────────┐ ◀─────────────────── ┘
│ 自動化關卡 │ 金鑰掃描(gitleaks) · npm audit
│ (CI, 每次push) │ 是否已引數化? · 金鑰是否在客戶端之外?
└────────┬─────────┘
│ 全部綠燈
▼
SHIP ✓ ── 任何紅色都會攔截本次推送 ──
並且在 push 之前跑一個金鑰掃描器——像 gitleaks 這樣的工具（或者你平臺內建的掃描）會在你的程式碼和歷史裡搜尋形似金鑰的東西。它是一道一條命令就能就位的安全網，對應的正是這份清單上代價最昂貴的那個錯誤；你還可以讓 AI 把它接進 （Continuous Integration，持續整合——那個在你每次推送程式碼時自動替你跑各項檢查的機器人），這樣每次 push 都會自動跑。