独立开发和小团队基本没有专门的安全 / 性能 reviewer，问题就一直累积，直到上线那天一次性爆发。任何重要发版前跑一次 30 分钟的 AI 审计，能抓到大约 60-80% 的明显坑——CORS 配错、env 漏出来、N+1 查询、缺 rate limit、可访问性挡板——并给你一份分级修复列表。这是一份能产出可执行发现、而不是通用 checklist 的结构化 prompt 工作流。
这篇讲什么
一套上线前或每季度跑一次的可复用审计流程：贴项目结构 + 关键文件、跑三轮聚焦审计（安全 / 性能 / UX），离开时拿到一份分级修复清单。Stack 无关——例子用典型 Astro/Next.js + Firebase，prompt 适配任何现代 app。
这篇适合谁看
独立 App 开发者、小型产品团队。如果你没有专门的 SRE / 安全 review，并且上线过 1-2 个”早一点抓到就好了”的项目，特别相关。已经有正式 SOC 2 / 渗透测试的不太相关——这是从业者的飞行前检查，不替代真审计。
什么时候适合用
任何重要上线前（新公开 endpoint、新认证流程、新支付集成）。重要依赖升级后。即使啥都没改，每季度做一次健康检查。提交 AdSense / Google 审批前——它们会审 AI 能稳定抓到的具体 UX 模式。
开始前准备
- 项目结构（
tree输出或ls -R src/）、package.json、部署配置（firebase.json、vercel.json）准备好。 - 明说技术栈：框架、托管、数据库、auth、支付。AI 能猜一部分，没明说就漏。
- 决定审计范围：整 App，还是单个功能（新支付流程、新认证、新管理面板）。聚焦审计出的发现更尖锐。
- 准备一份 triage 文档（Google Doc、Notion、Markdown 文件），每条发现都进去 + 优先级 + 负责人。
具体步骤
- 提供上下文。 贴项目结构、
package.json、部署配置。加两句话说”这个 App 做什么、谁用”。 - 跑安全审计：
审计这个项目常见的安全问题。检查：
- 密钥 / env：是否暴露在客户端 bundle、是否提交进 repo、生产环境是否缺失
- AuthN/AuthZ：保护路由真的受保护吗、角色检查一致吗
- 输入校验：XSS、SQL 注入、文件上传限制
- CORS / CSRF：跟 auth 模型匹配吗
- Rate limit：公开 / 昂贵 endpoint 上有没有
- 依赖漏洞：npm audit / Snyk 标了没有
- 日志：日志里有没有密钥、PII
每条发现：严重度（block/warn/nit）、文件位置、修复。- 跑性能审计：
审计这个项目的性能问题。检查：
- 数据库：N+1、缺索引、大无界读
- Bundle 体积：无用依赖、可代码分割的地方
- 图片：未优化格式、没 lazy loading
- API 调用：waterfall vs 并行、有没有可缓存
- SSR vs CSR：误用
- Serverless 冷启动风险
每条发现：严重度、位置、修复、预期影响。- 跑 UX / 可访问性审计：
审计这个项目的 UX 暗模式和可访问性。检查：
- 表单：错误信息、校验时机、必填项清晰度
- Loading 状态：缺骨架屏、内容跳动
- 空状态：有帮助还是一片白
- 错误状态：对用户友好还是 stack trace
- A11y：ARIA 标签、对比度、键盘导航、焦点陷阱
- 暗模式：confirm-shaming、隐藏费用、难取消
每条发现：严重度、位置、修复。- 整理修复列表。 每条发现都让它”给我能直接粘的 diff”。散文回答拒收——要代码。
- 排优先级。 Blocker 先 → warning → nit。一次会话上限 10 条；超过会疲劳。
- 修完再审。 在打过补丁的代码上跑同样的 prompt。出现新发现 = AI 校准准；零新发现 = 它在模式匹配。
期待的样本发现
- Firebase 公开配置对象里有数据库 URL——这没问题（本来就是公开的），AI 会标记；去核对规则是否够紧。
- 没依赖数组的
useEffect——每次 render 都跑，有时合理，会被标记为性能隐患。 - 通用错误 toast（“Something went wrong”）——标 UX 暗模式；展开成可操作。
target="_blank"链接缺rel="noopener noreferrer"——常见，标安全。- 未消毒的
dangerouslySetInnerHTML——真 blocker。
第一次实操怎么跑
对你最高风险的功能（auth、支付、管理后台）跑安全审计。当作校准：AI 出的是真问题还是通用问题？三条真发现 = 在你这个 stack 上工作流跑通了。零真 + 五通用 = 上下文贴太薄，加更多文件。
完成后检查
- 发现有没有引用具体文件 / 行，还是”你应当考虑”？具体 = 信号；模糊 = 噪声。
- Blocker 是真的 blocker 吗？AI 有时把 nit 标成 blocker——推回去：“这为什么是发版 blocker 不是 nit？”
- 修复是可粘 diff 还是散文？要 diff。
- 修完之后重新审，是不是干净的？冒新问题 = 先验证再当真。
怎么复用这套流程
- 三个审计 prompt 存一份文档，把项目名和 stack 写死。
- 每个项目维护一份”以前抓到过”清单。版本间模式会重复。
- 任何外部 review 之前都跑（AdSense、App Store、SOC 2 准备）。AI 飞行前能砍掉意外。
- 团队场景：把审计发现 + 修复粘进 release notes。未来的你会感谢现在的你。
建议的操作流程
项目上下文贴入 → 3 轮结构化审计 → diff 形式的修复列表 → 按优先级应用 → 复审 → 上线。总耗时：小 App 30-45 分钟，大一点 1-2 小时。比上线后修同样问题便宜得多。
容易踩的坑
- 把 AI 审当全面审。它抓得到 60-80% 的明显问题，剩下 20-40% 要人眼或真渗透测试。
- 修复不验证。AI 偶尔通过”压住症状”（catch + ignore）来”修复”，根因没动。
- 上下文贴太少就拿到通用建议。修法是加上下文，不是改 prompt。
- 三轮审计塞一个超大 prompt 一起跑。质量降。分开做、分开 triage。
- 一直放着 nit 不修。会累积。每版一个 nit，一年就 30 个。
- 跳过复审。第一次审计的发现可能互相遮蔽，第二轮才会浮出更深一层。
FAQ
- 能替代真安全审计吗？: 不能。是让真审计更快更便宜的飞行前。SOC 2 和 PCI 需要人。
- 特定漏洞，比如某框架的 CSRF 呢？: 把 prompt 框到你的栈：“Next.js 14 + App Router，专门查 Server Actions 里的 CSRF。“靶向 prompt 出靶向发现。
- 怎么让 AI 推得更狠？: 加一句”狠一点——当你是个高级 reviewer 抓过这个团队的草率”。它会挖出外交辞令 prompt 藏起来的东西。
- 能放进 CI 自动化吗？: 能，注意：每个 PR 把项目文件 pipe 给模型；按”无新 blocker” gate 合并。准备好覆盖 AI 的严重度判定。
- 成本呢？: 小 App 三轮审计约 1-5 美元的 API 费用。值。