那天我让它 Review 一个 Stripe Webhook 处理器，它给我列了 7 个问题。

其中有一条是："你在处理 payment_intent.succeeded 事件之前没有校验幂等性，同一个事件如果 Stripe 重试发送，你的数据库会重复写入订单记录。"

我盯着那行代码看了三分钟。

这段代码我自己过了两遍，上线前让下面的小伙伴也看过。没人发现。

一个人干活，谁来帮你把关？

对很多做出海独立开发的创业者来说，最孤独的不是深夜改 bug，是没有人帮你 Review 代码。

不是因为你不想要 Review，是因为：你就一个人。

找朋友？他不了解你的项目背景，光解释上下文就要半小时。发到技术群？十条消息九条没人理。花钱请外包？一次 Review 的沟通成本比直接改 bug 还高。

我之前的解决方案是：自己 Review 自己。

说人话就是：写完代码，等一天，脑子冷静下来再看一遍。

这个方法有用，但有两个根本性缺陷。第一，你的盲点是固定的，等一天还是那些盲点。第二，你等不起一天，你有 deadline。

Claude Code 做代码审查，解决的就是这个问题。而且它强过人工 Review 的地方，比你想象的多。

实际怎么用——我固定下来的四种用法

用法一：提交前的全量扫描

在 Claude Code 交互模式里，直接跑：

帮我 Review 这次修改涉及的所有文件。重点关注：1）安全性问题，包括输入校验、SQL注入、XSS；2）出海场景的特殊问题，包括时区处理、Stripe 支付的幂等性、数据合规；3）性能问题，包括不必要的数据库查询、没有加索引的查询条件。发现问题按严重程度分级：Critical / Warning / Suggestion。

为什么要分级？因为不是每个问题都值得你现在停下来改。Critical 是必须改，Warning 是这次 sprint 内改，Suggestion 是记录下来下次优化。

没有分级，它给你列一堆东西，你不知道先改哪个，容易直接摆烂。

用法二：针对高风险模块的专项审查

有些模块出了问题代价特别高：支付、认证、数据删除。这些值得单独跑一次更深入的审查。

针对支付模块的 Prompt：

专项审查 app/api/webhooks/stripe/route.ts 这个文件。

检查以下 Stripe Webhook 的关键问题：

1. 是否正确验证了 webhook signature（stripe.webhooks.constructEvent）

2. 是否处理了幂等性——同一个 event_id 重复收到时会不会重复处理

3. checkout.session.completed 和 payment_intent.succeeded 有没有重复处理同一笔订单的风险

4. subscription 状态变更（canceled、past_due）有没有及时同步到数据库

5. 失败的 webhook 处理有没有错误日志，方便排查

这个 Prompt 是我踩了坑之后总结出来的。幂等性那条，就是文章开头的那个故事。

用法三：安全性专项——出海必做

做出海产品有一些安全要求，国内开发经验覆盖不到。

对整个项目做一次安全审查，重点针对出海 SaaS 的常见风险：

1. API 路由是否都做了认证校验，有没有未授权可访问的接口

2. 用户数据隔离：A 用户能不能访问到 B 用户的数据（IDOR 漏洞）

3. 环境变量里的密钥有没有可能被 console.log 或错误信息暴露

4. Stripe 相关接口有没有做请求来源验证

5. 数据库查询有没有使用 Prisma 的参数化查询，还是有字符串拼接 SQL 的情况

IDOR（Insecure Direct Object Reference）是出海产品最常见的安全漏洞之一。

说人话就是：你查询 SELECT * FROM tasks WHERE id = 123，但没有加 AND userId = currentUser.id——任何登录用户都能通过猜 id 看到别人的数据。

这个漏洞非常隐蔽，人工 Review 很容易忽略，因为你在想业务逻辑，不在想安全边界。

用法四：性能问题扫描

在开发阶段发现性能问题，成本是 0。上线后再发现，代价可能是用户流失。

扫描项目里所有 Prisma 查询，找出以下性能问题：

1. N+1 查询：在循环里执行查询，应该用 include 或 findMany 一次性拿数据

2. 没有使用 select 限制返回字段，返回了整个对象但只用了几个字段

3. 查询条件里的字段没有对应的数据库索引

4. 在 Server Component 里有没有重复查询同一份数据

N+1 查询是新手最常见的性能问题。

举个例子：你查出 100 个用户，然后循环里对每个用户再查一次他的订阅状态——结果是 101 次数据库请求。用 Prisma 的 include 一次搞定，就是 1 次。

这个问题人工 Review 很难发现，因为代码看起来逻辑没问题，但你要在脑子里模拟执行流程才能察觉。Claude Code 帮你模拟。

踩坑环节

坑一：让它"整体看一下"，结果什么都没看到位

刚开始用的时候，我会说"帮我 Review 一下这个项目"。

它给我的反馈看起来很全，但全是泛泛的建议："建议加错误处理"、"可以优化性能"、"注意安全性"。

我当时傻乎乎地以为它已经仔细看过了，就没继续追问。

后来我改成指定文件、指定问题维度、指定关注点，反馈质量差了十倍不止。

解决方案： Review 的 Prompt 必须具体。指定文件路径，指定检查维度，指定你担心的具体问题。模糊的问题得到模糊的答案，这条规律对人和 AI 都适用。

坑二：它说"没问题"，我就真的以为没问题了

有一次我问它"这个 API 路由有没有安全问题"，它说"代码逻辑清晰，没有明显安全漏洞"。

我就上线了。

一周后用户反馈说他能看到别的用户的数据。就是 IDOR，就是那个"根据 id 查询没有过滤当前用户"的问题。

回头看，我的 Prompt 太笼统，它回答了我问的问题，但我问的问题本身就有盲区。

解决方案： 安全性 Review 要用检查清单式的 Prompt，不要问"有没有安全问题"，要问"是否存在以下 X 种具体的安全问题"。让它对照清单逐条核查，而不是凭感觉判断。

总结

人工 Review 的上限是 reviewer 的认知边界；AI Review 的上限是你 Prompt 的具体程度。

你问得越具体，它看得越深。你问得越模糊，它越是在陪你走过场。

---

最后问你一个有点扎心的问题： 你的项目里，现在有没有某个模块你心里隐约觉得"可能有问题但一直没细看"——如果用上面那套 Prompt 去 Review，你最怕它发现什么？