方案 AZ：AI 编程安全与测试体检（交付前必做）

gitleaks / git log + .env

检查 API key、token、密码是否硬编码在代码里，是否进过 git 历史或日志。AI 模型有时会把示例密钥或环境变量直接写进源码，一旦进仓库就是后患。规范做法：一律用 .env + 环境变量注入，.gitignore 排除 .env，并把已进历史的信息从历史中清除。

💡用 git log -p | grep 或 gitleaks 扫一遍历史；密钥一旦外泄，旋转（重新生成）比删除 commit 更可靠。

npm audit / Snyk

跑 npm audit 或依赖扫描工具，查看已知漏洞与过期版本。AI 生成的依赖往往是最新版本或它「记得」的版本，可能带已知 CVE 或已 EOL。审计结果按严重程度分级处理：高/严重漏洞优先修，无修复方案的就评估风险或替换掉这个库。

💡别盲装新包——先看下载量、维护频率、作者信誉；锁定精确版本（lockfile），避免子依赖悄悄升级引入问题。

Vitest / Jest / Playwright

为关键逻辑写单元测试，为关键业务路径写端到端测试。不要只测 happy path——补上边界值、异常输入、权限不足、超时这些场景。让 AI 基于你的代码生成测试用例，但你要人工补「用户会怎么出错」的场景。

💡先写会失败的用例（红），再让它通过（绿），比事后补测试更能暴露真实问题。

review 清单 + 你

按清单逐项核对：输入校验、密钥管理、依赖审计、测试覆盖、权限控制、错误处理与日志脱敏。把每一项的结论写进交付说明——谁检查的、结果如何、遗留什么风险，都留痕。这一步让「体检」不是走过场，而是可追溯的交付资产。

💡把清单固化成模板放进仓库（如 checklist.md），下次直接复用，缺项一目了然。