独立开发者和小团队基本没有专门的安全或性能 reviewer，问题就这样悄悄累积，直到上线那天一次性全爆出来。任何重要发版前跑一次聚焦的 30 分钟 AI 审计，能抓到大部分明显坑——CORS 配错、env 漏出去、N+1 查询、缺 rate limit、键盘陷阱——并交给你一份分级、可直接粘 diff 的修复清单。这是一份能产出可执行发现、而不是通用 checklist 的结构化 prompt 工作流。
TL;DR
- 跑三个独立审计，别塞成一个超大 prompt：安全、性能、UX / 可访问性。揉在一起质量会掉。
- 安全审计锚定到 OWASP Top 10:2025（第八版，2026 年的当前参考）。Broken Access Control 仍是 #1，Security Misconfiguration 从 #5 蹿到了 #2。
- AI 这一遍是飞行前检查，不是真审计。自动化可访问性扫描器只能完整覆盖大约 29.5% 的 WCAG 2.2 成功准则，其余要靠人眼。AI 安全发现也一样对待。
- 贴真实上下文（项目目录树、
package.json、部署配置、关键文件）。上下文薄就出通用建议，解法是加上下文，不是换个更聪明的 prompt。 - 要 diff，不要散文。修完再审一遍，确认你解决的是根因而不是症状。
这篇讲什么
一套上线前或每季度跑一次的可复用审计：贴项目结构加关键文件、跑三轮聚焦审计、离开时拿到一份分级修复清单。它跟技术栈无关——例子假设典型的 Astro/Next.js + Firebase 栈，但 prompt 适配任何现代 app。
这篇适合谁看
独立 App 开发者、小型产品团队，尤其是你没有专门的 SRE 或安全 review，而且上过一两个”早点抓到就好了”项目的人。如果你已经有正式的 SOC 2 / 渗透测试，这篇相关性就不高——它是从业者的飞行前检查，不替代真审计。
什么时候适合用
任何非琐碎的上线前（新公开 endpoint、新认证流程、新支付集成）。重要依赖升级后——这一点现在更要紧，因为 Software Supply Chain Failures 已经单列成 OWASP 的一个类别（A03:2025）。即使什么都没改，每季度做一次健康检查。还有提交 AdSense 或 Google 审批前，因为审核方会查一些 AI 能稳定抓到的具体 UX 和可访问性模式。
给审计挑对模型
审计本质是个上下文问题：模型得把整个项目装进脑子里，才能发现跨文件的问题。截至 2026 年 6 月，值得用的工具：
| 工具 | 上下文窗口 | 最适合 | 备注 |
|---|---|---|---|
| Claude Code（Opus 4.7 / Sonnet 4.6） | 100 万 token | 全仓安全 + 架构审计 | 只跑 Anthropic 模型；直接读你的仓库 |
| Cursor（Sonnet 4.6、GPT-5.5、Gemini 3.1 Pro） | 最高约 100 万 | IDE 内审计；BugBot 做单 PR review | 多模型可选；适合修完再复查的循环 |
| ChatGPT Plus（GPT-5.5） | App 内约 320 页 | 贴入一小撮聚焦文件 | 完整 100 万上下文只在 $200 Pro 档 |
| Gemini 3.1 Pro（Google AI Pro，$19.99/月） | 100 万 token | 大 monorepo、长配置 dump | 长上下文召回强 |
要做全仓审计，优先用能读整棵树的工具（Claude Code 或 Cursor）。只审单个功能时，把相关文件贴进 ChatGPT 或 Claude 就够了。
开始前准备
- 项目结构（
tree输出或ls -R src/）、package.json、部署配置（firebase.json、vercel.json）准备好待贴。 - 明说技术栈：框架、托管、数据库、auth、支付。AI 能猜一部分，但你不说的它就漏。
- 决定范围：整个 App，还是单个功能（新支付流程、新认证、新管理面板）。聚焦审计出的发现更尖锐。
- 准备一份 triage 文档（Google Doc、Notion 页面，或 Markdown 文件），每条发现都落进去，带优先级和负责人。
- 先跑一遍
npm audit并把输出贴上。它拿你的 lockfile 对照 GitHub Advisory 数据库查已知 CVE，给 AI 一个真实基线去推理，而不是瞎猜。
具体步骤
- 提供上下文。 贴项目结构、
package.json、部署配置。加两句话说”这个 App 做什么、谁在用”。 - 跑安全审计：
对照 OWASP Top 10:2025 审计这个项目。每一项给出 PASS / FAIL / N/A
并说明原因。检查：
- 访问控制失效（A01）：保护路由是否真受保护、角色检查是否一致、
IDOR、服务端请求伪造（SSRF）
- 安全配置错误（A02）：默认凭据、生产环境冗长报错、CORS 开太大、
缺安全 header
- 供应链（A03）：未锁版本的依赖、npm audit 标出的包
- 加密失效：密钥进客户端 bundle 或提交进 repo、弱哈希、明文 PII
- 注入：XSS、SQL 注入、命令注入、文件上传限制
- 认证失效：会话处理弱、登录缺 rate limit、无暴力破解防护
- 日志失效：日志里有密钥或 PII、敏感操作无审计轨迹
每条发现：严重度（block/warn/nit）、确切文件 + 行号、修复以 diff 给出。- 跑性能审计：
审计这个项目的性能问题。检查：
- 数据库：N+1 查询、缺索引、大无界读
- Bundle 体积：无用依赖、可代码分割处
- 图片：未优化格式、没 lazy loading、缺 width/height
- API 调用：请求 waterfall vs 并行、缺缓存
- 渲染：SSR vs CSR 误用、hydration 成本
- Serverless 冷启动风险
每条发现：严重度、位置、修复以 diff 给出、预期影响
（例如"LCP 降约 400ms""bundle 减约 80KB"）。- 跑 UX / 可访问性审计：
审计这个项目的可访问性（WCAG 2.2 AA）和 UX 暗模式。明确说明你只能
抓到可自动化的那部分，并标出哪些需要人工复核。检查：
- 表单：label 是否绑定到输入框、错误信息、校验时机
- Loading 状态：缺骨架屏、布局跳动（CLS）
- 空状态 + 错误状态：有帮助的文案 vs 一片白 vs stack trace
- A11y：alt 文本是否存在、对比度（正文 4.5:1）、ARIA 误用、
键盘导航、可见焦点、焦点陷阱
- 暗模式：confirm-shaming、隐藏费用、难取消的流程
每条发现：严重度、位置、修复以 diff 给出。另外单独列出哪些 WCAG 准则
你光看代码无法评估。- 整理成修复列表。 每条发现都让它”给我能直接粘的 diff”。散文回答拒收，要代码。
- 排优先级。 Blocker 先，然后 warning，再 nit。每次会话上限约 10 条——超过会疲劳。
- 修完再审。 在打过补丁的代码上跑同样的 prompt。冒出几条新发现 = AI 真在读你的代码；真实代码库上零新发现，通常意味着它在模式匹配，那就加更多上下文。
为什么要分三个审计
把三者塞进一个 prompt 是最常见的错，它会拖垮每一项结果。安全 review 要的是对抗思维；性能 review 要的是 profiling 思维；可访问性 review 要的是终端用户思维。一次要全部，等于逼模型在三者间取平均，输出读起来就像通用 checklist。分开跑，各自 triage，再往下走。
AI 能抓到什么、抓不到什么
诚实地设期望。安全审计能干净地对应到 OWASP Top 10:2025——光 Broken Access Control 一类就覆盖 40 个不同的 CWE，出现在 3.73% 被测应用里，是所有类别中最高的。AI 擅长抓机械模式（一个未保护路由、一个未锁版本依赖、一个缺失的 header），但对业务逻辑漏洞很弱：某个用户该不该能访问某条记录，只有你完全清楚。
可访问性是这道差距最清楚的例子。自动化工具（Lighthouse 背后的 axe-core 引擎）只能完整自动化大约 29.5% 的 WCAG 2.2 成功准则，另有约 10% 部分覆盖，剩下约 60% 要人工测试。焦点顺序、逻辑阅读顺序、以及 alt 文本是否有意义，基本 100% 靠人。所以把 AI 的可访问性这一遍当作第一轮粗扫，然后真机上用键盘走一遍。
期待的样本发现
- Firebase 公开配置对象里带着数据库 URL——这没问题（它本就该公开），但 AI 会标记。去核对你的 Security Rules 是否真的够紧。
- 没依赖数组的
useEffect——每次 render 都跑。有时是故意的，但常被标成性能隐患。 - 通用错误 toast（“Something went wrong”）——标成 UX 问题；展开成可操作的。
target="_blank"链接缺rel="noopener noreferrer"——常见，标成轻微安全 / 性能问题。- 未消毒的
dangerouslySetInnerHTML——真 blocker（存储型 XSS）。 npm audit标出的未锁版本或传递依赖——在 OWASP A03:2025 之下，这不再是 nit；锁版本或升级它。
第一次实操怎么跑
对你最高风险的功能（auth、支付、管理后台）跑安全审计。当作校准：AI 出的是真问题、具体到文件，还是泛泛的？三条具体发现 = 工作流在你这个栈上跑通了。零真发现加五条通用 = 上下文贴太薄，加更多文件。
完成后检查
- 发现有没有引用具体文件和行号，还是”你应当考虑”？具体 = 信号；模糊 = 噪声。
- Blocker 是真 blocker 吗？AI 有时把 nit 标成 blocker——推回去：“这为什么是发版 blocker 而不是 nit？”
- 修复是可粘的 diff 还是散文？要 diff。
- 修完后重新审一遍，回来干净吗？冒出新问题就先验证再当真。
- 可访问性审计有没有诚实标出它查不了的部分？如果它声称完整覆盖了 WCAG，那它在吹。
怎么复用这套流程
- 三个审计 prompt 存一份文档，把项目名和栈写死进去。
- 每个项目维护一份”以前抓到过”清单。版本之间模式会重复。
- 任何外部 review 前都跑一遍（AdSense、App Store、SOC 2 准备）。这个飞行前能砍掉意外。
- 团队场景：把发现加修复粘进 release notes，让下一个人继承上下文。
- 在 CI 里，你可以每个 PR 把改动文件 pipe 给模型，按”无新 blocker” gate 合并——Cursor 的 BugBot 就自动做类似的事。准备好覆盖模型的严重度判定。
容易踩的坑
- 把 AI 审当成全面审。它抓得到明显的机械问题；业务逻辑漏洞和那约 60% 靠人工的 WCAG 准则，需要人眼或真渗透测试。
- 修复不验证。AI 偶尔靠”压住症状”（catch 然后忽略）来”修复”，根因没动。
- 上下文贴太少就拿到通用建议。解法是加上下文，不是换 prompt。
- 三轮审计塞进一个超大 prompt 一起跑。质量会降；分开做、分开 triage。
- 一直放着 nit 不修。会累积——每版一个 nit，一年就 30 个。
- 跳过复审。第一遍的发现可能互相遮蔽，第二遍才浮出更深一层。
FAQ
- 能替代真安全审计吗？: 不能。它是让真审计更快更便宜的飞行前。SOC 2 和 PCI 需要人，业务逻辑的访问检查也需要人。
- 该用哪个模型？: 全仓审计用能读整棵树的工具——Claude Code（Opus 4.7，100 万 token 上下文）或 Cursor。单个功能就把文件贴进 ChatGPT Plus（GPT-5.5）或 Claude，够用。
- 怎么让 AI 推得更狠？: 加一句”狠一点——当你是个抓过这个团队草率的高级工程师来 review”。它会挖出外交辞令 prompt 藏起来的东西。
- 框架特定问题，比如 CSRF 呢？: 点名你的栈：“这是用 App Router 的 Next.js，专门查 Server Actions 里的 CSRF。“靶向 prompt 出靶向发现。
- 能放进 CI 吗？: 能，注意：每个 PR 把改动文件 pipe 给模型，按”无新 blocker”gate。Cursor 的 BugBot 自动做类似的单 PR review。永远保留人工覆盖严重度。
- 成本呢？: 小 App 三轮审计约 1–5 美元 API 费用（截至 2026 年 6 月，Opus 4.7 是每百万输入/输出 token 5/25 美元）。比上线后修同样问题便宜。
相关阅读
权威来源参见 OWASP Top 10:2025 与 WCAG 2.2 标准。