夜雨聆风上周五下午,线上告警群突然炸了。
一个用户反馈:连续点击「提交订单」按钮,钱扣了两次,但只生成了一笔订单。排查了半小时,最后发现是一个 useEffect 里的竞态条件--而这段代码,是三天前用 AI 辅助生成的。
说实话,当时我盯着那段代码看了好几遍,逻辑上完全说得通。happy path 跑得很顺,单元测试也全绿。但就是在并发场景下,它会默默地吞掉一个请求。
这就是 2026 年最危险的 Bug 类型:看起来完全正确的错误。
Veracode 今年的报告给出了一个触目惊心的数字:AI 生成代码引入安全漏洞的概率是 45%,Java 项目里 72% 的 AI 代码至少踩中一个 CWE。CodeRabbit 的数据也显示,AI 生成代码引发的问题数量是人类手写代码的 1.7 倍。
但我想说的不是"别用 AI 写代码"--那是因噎废食。我想分享的是:怎么用 AI 来审 AI 写的代码,让它自己抓自己的 Bug。
过去两个月,我在项目里用 Claude 做 Code Review,揪出了十几个人眼很难发现的隐蔽问题。今天挑 3 个最典型的,连带我的 Prompt 模板一起分享。
为什么人眼越来越难审 AI 代码?
先说一个反直觉的事实:AI 生成的代码,比人写的代码更难 Review。
不是因为它写得烂,恰恰相反--它写得太"对"了。变量命名规范、结构清晰、注释完整,看起来就像一个高级工程师的手笔。你的大脑会自动进入"快速扫描"模式,觉得"嗯,没问题"。
但问题往往藏在你觉得"没问题"的地方。
传统的人写代码,Bug 通常很"明显"--拼写错误、逻辑反了、少了个判断。你扫一眼就能抓到。但 AI 生成的 Bug 更像是"正确的错误":每一行单独看都没问题,组合在一起才会出事。
人眼审代码靠的是模式匹配,而 AI 的 Bug 恰好不在你的模式库里。
这就是为什么我开始用"AI 审 AI"的策略--用一个模型生成代码,用另一个模型来审查。就像让两个人互相检查作业,盲点不同,才能查漏补缺。
案例一：useEffect 里的竞态条件，藏得比你想象的深
回到开头那个线上事故。简化后的代码大概长这样:
const [orderId, setOrderId] = useState<string | null>(null)
const handleSubmit = async () => {
setLoading(true)
const res = await createOrder(cartItems)
setOrderId(res.id)
setLoading(false)
}
useEffect(() => {
if (orderId) {
processPayment(orderId)
}
}, [orderId])
看出问题了吗?大多数人看不出来。
逻辑很清晰:创建订单 -> 拿到 orderId -> 触发支付。单测也能过。但在真实场景下,用户快速点击两次按钮,createOrder 会被调用两次,两个异步请求几乎同时返回,setOrderId 被连续调用两次,但 useEffect 可能只触发一次--因为 React 的批量更新机制。
我把这段代码丢给 Claude,用的 Prompt 是:
审查这段 React 代码的并发安全性。
假设用户可能快速重复触发 handleSubmit。
重点关注:状态更新的时序、useEffect 的触发条件、
异步操作的竞态风险。列出所有可能的边界情况。
Claude 在 10 秒内指出了 3 个问题:
1. 没有防重复提交的锁机制
2. useEffect 依赖 orderId,但连续的 setOrderId 在批量更新下可能合并
3. 如果第一次请求慢、第二次快,orderId 会被覆盖成第二次的值,第一笔订单的支付永远不会触发
修复后的代码:
const submitRef = useRef(false)
const handleSubmit = async () => {
if (submitRef.current) return
submitRef.current = true
setLoading(true)
try {
const res = await createOrder(cartItems)
await processPayment(res.id)
setOrderId(res.id)
} finally {
setLoading(false)
submitRef.current = false
}
}
关键改动:用 useRef 做防重入锁,把支付逻辑从 useEffect 移到 handleSubmit 里串行执行。
这个 Bug 人眼很难抓到,因为它只在特定时序下才会触发。但 AI 天然擅长穷举边界情况--这正是它做 Review 的优势。
案例二：看似无害的内存泄漏，吃掉了 200MB
第二个案例来自一个实时数据看板组件。AI 生成的代码用 WebSocket 订阅数据更新:
const useRealtimeData = (channel: string) => {
const [data, setData] = useState<DataPoint[]>([])
useEffect(() => {
const ws = new WebSocket(`wss://api.example.com/${channel}`)
ws.onmessage = (event) => {
const point = JSON.parse(event.data)
setData(prev => [...prev, point])
}
r => ws.close()
}, [channel])
return data
}
代码看起来很标准,cleanup 也写了。但我用 Claude 审查时,它立刻指出:
setData(prev => [...prev, point])会让 data 数组无限增长。如果 WebSocket 每秒推送 10 条数据,一小时后数组会有 36000 个元素。每次 setState 都会创建一个新数组,旧数组等待 GC 回收,但由于 React 的闭包引用链,部分旧数组可能无法及时释放。
我当时的反应是"不至于吧"。然后打开 Chrome DevTools 的 Memory 面板,挂了 10 分钟--内存从 50MB 涨到了 250MB。
数据不骗人。一个"标准写法"的 Hook,10 分钟吃掉 200MB 内存。
修复方案很简单,加个滑动窗口:
ws.onmessage = (event) => {
const point = JSON.parse(event.data)
setData(prev => {
const next = [...prev, point]
return next.length > 500 ? next.slice(-500) : next
})
}
但这不是重点。重点是:这种"慢性内存泄漏"在开发环境几乎不可能被发现--你不会在本地挂着页面一小时不关。只有在生产环境,用户长时间停留在看板页面时才会暴露。
而 Claude 在审查时,不需要真的跑代码,它通过静态分析就能推断出数组增长的趋势。
案例三：被忽略的 XSS，藏在 dangerouslySetInnerHTML 的“安全”用法里
第三个案例更隐蔽。一个富文本展示组件,AI 生成的代码用了 DOMPurify 做消毒:
import DOMPurify from 'dompurify'
const RichContent: React.FC<{ html: string }> = ({ html }) => {
const clean = DOMPurify.sanitize(html)
return <div dangerouslySetInnerHTML={{ __html: clean }} />
}
用了 DOMPurify,看起来很安全对吧?大多数 Review 到这里就会放行。
但 Claude 指出了一个问题:
DOMPurify 默认配置允许
<a>标签的target和href属性。攻击者可以构造<a href="javascript:void(0)" onclick="...">的变体,或者利用<a href="https://evil.com">做钓鱼。更关键的是,DOMPurify 默认不过滤 CSS,攻击者可以通过style属性做 CSS 注入,比如position:fixed覆盖整个页面。
我去翻了 DOMPurify 的文档,确实如此。默认配置对于大多数场景够用,但在用户可控的富文本场景下,需要更严格的白名单:
const clean = DOMPurify.sanitize(html, {
ALLOWED_TAGS: ['p', 'br', 'strong', 'em', 'ul', 'ol', 'li', 'code'],
ALLOWED_ATTR: ['class'],
ALLOW_DATA_ATTR: false,
})
安全问题最怕的不是"没做防护",而是"以为做了防护"。
DOMPurify 给了你一种安全感,但默认配置的宽松程度远超大多数人的预期。这种"虚假的安全感"比完全不做防护更危险--因为没人会再去质疑它。
我的 AI Code Review Prompt 模板
分享我日常用的 Review Prompt,经过两个月迭代,效果比较稳定:
请审查以下 React + TypeScript 代码,重点关注:
1. 并发安全:异步操作的竞态条件、状态更新时序
2. 内存管理:闭包引用、事件监听器清理、数组/对象无限增长
3. 安全漏洞:XSS、注入、敏感信息泄露
4. 边界情况:空值、极端输入、网络异常、组件卸载时的异步回调
对每个问题:
- 说明触发条件(什么场景下会出问题)
- 评估严重程度(P0-P3)
- 给出最小修复方案(不要重写整个组件)
[粘贴代码]
几个关键点:
用不同模型交叉审查。 生成代码用 Cursor,审查用 Claude Opus。两个模型的"盲点"不同,交叉审查能覆盖更多边界。2026 年的最佳实践是:生成端和审查端用不同模型,避免"盲点相同"。
别只审逻辑,审"假设"。 AI 生成代码时会做很多隐含假设--比如"用户不会快速点击"、"数据量不会太大"、"输入一定是合法的"。你的 Prompt 要明确打破这些假设。
把 Review 结果喂回去。 让 AI 根据 Review 意见修复代码后,再做一轮 Review。我通常跑 2-3 轮,直到没有新问题。
但这还不是最坑的部分
工具再好,最终还是要人来把关。
我见过太多团队把 AI Review 当成"自动化质检"--跑一遍没报错就合代码。这跟 Snyk 扫一遍全绿就觉得安全了一样,是一种危险的心理安慰。
Harness 的报告用上 AI 工具却没更新审查流程的团队,生产事故涨了 34%。不是 AI 不好用,是大家把"辅助工具"当成了"替代方案"。
AI Code Review 的正确姿势是:让 AI 帮你发现问题,但由你来决定怎么修。
它是你的第二双眼睛,不是你的替身。
你平时用 AI 做 Code Review 吗?有没有被它揪出过意想不到的 Bug?评论区聊聊。
这是「Hans碎碎念」的文章,欢迎关注
