AI 生成的代码 45% 有漏洞?我用 Claude 做 Code Review,揪出了 3 个人眼看不到的 Bug

上周五下午,线上告警群突然炸了。

一个用户反馈:连续点击「提交订单」按钮,钱扣了两次,但只生成了一笔订单。排查了半小时,最后发现是一个 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 个问题:

修复后的代码:

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碎碎念」的文章,欢迎关注