2026年2月，同一周内，Claude Opus 4.6 同时出现在两条新闻里。

第一条：Anthropic 宣布，Claude Opus 4.6 自主扫描开源代码，发现了超过 500 个此前未知的高危漏洞，让全球开发者紧急打补丁。

第二条：DeFi 借贷协议 Moonwell 被黑，损失 178 万美元（约 1280 万人民币）。GitHub 提交记录显示，出问题的代码由 Claude Opus 4.6 联合编写。

同一个模型，同一周，英雄和肇事者。

先说英雄那一面

Anthropic 的安全团队让 Claude Opus 4.6 去做一件事：像人类安全研究员一样，自己去找开源代码里的漏洞。

没有给它特殊工具，没有写复杂的提示词，没有定制脚手架。

结果是 500+ 个零日漏洞（zero-day），全部经人工验证，无一误报。

受影响的三个项目你可能没听过，但你每天都在间接使用它们：

• Ghostscript：几乎所有 PDF 渲染和打印背后都用它
• OpenSC：银行卡、身份证、企业 U 盾里的智能卡认证库
• CGIF：处理 GIF 图片格式的底层库

Claude 的做法是：翻阅 Git 提交历史，理解代码的演变脉络，找到那些"应该检查边界但没检查"的地方，生成可以复现漏洞的 PoC 代码。

这些漏洞里有缓冲区溢出，有堆溢出，有算法逻辑边界问题。共同点是：传统 fuzzing 工具扫不到，因为它们需要先理解代码意图，才能知道"这里少了一个乘法"算不算漏洞。

Anthropic 安全负责人 Logan Graham 说：「这是防御者与攻击者之间的竞赛，我们希望尽快把工具交到防御者手中。」

再说肇事者那一面

Moonwell 是一个运行在 Base 和 Optimism 区块链上的借贷协议。你可以把它理解成一个链上版本的抵押贷款平台——用户抵押加密资产，借出资金，平台根据资产价格动态计算抵押率和清算线。

这里有一个关键角色叫 Oracle（预言机），负责给平台提供"外部价格"——就像告诉系统"现在 1 个 ETH 值 2200 美元"。

2月15日，Moonwell 通过社区提案 MIP-X43，激活了一个新的 Chainlink OEV 包装合约，用来给 cbETH（Coinbase 的质押以太币）定价。

问题出在这里。

正确的定价公式是：

1
2
3

cbETH 美元价格 = cbETH/ETH 汇率 × ETH/USD 价格
              ≈ 1.07 × 2200
              ≈ 2354 美元

但出问题的代码只返回了第一步的结果——cbETH/ETH 汇率约为 1.07~1.12，然后直接把这个数字当成美元价格用了。

于是系统认为：1 个 cbETH = 1.12 美元。

实际价格是约 2350 美元。

差了 2000 倍。

套利机器人立刻嗅到了机会。逻辑很简单：偿还约 1 美元的债务，就能触发清算，获得价值数千美元的 cbETH 作为抵押品奖励。链上机器人跑得比人快，几分钟内就把漏洞榨干了。

最终损失：178 万美元。

Pashov 的那条推文

事件发酵后，知名链上审计员 Pashov 翻出了 Moonwell 的 GitHub 提交记录。

PR 里有一行信息：Co-authored-by: Claude Opus 4.6

他在 X 上发问：「这是否是第一个被黑客攻击的 vibe-coded Solidity 智能合约？」

这条推文点燃了整个 Web3 安全社区。

但 Pashov 也做了一个重要补充——这不是他想简单甩锅的意思：

「AI 背后有人类审查。仅仅归咎于神经网络是不正确的。但此事件对 vibe coding 趋势确实是一个警示。」

这句话是关键。出问题的不是 Claude，是流程。

为什么 AI 既能找漏洞，又能制造漏洞？

这两件事看起来矛盾，其实逻辑上完全一致。

AI 是一个能力放大器。

当 Anthropic 的安全团队用它找漏洞时：有明确目标，有人工验证，有完整流程，找到漏洞→验证→上报→修复。

当 Moonwell 开发者用它写智能合约时：任务是"实现 oracle 接口"，代码通过了，测试跑绿了，提案投票过了，合约上链了。没有人在发布前问一句：「这段定价逻辑，如果缺了一个乘法，会发生什么？」

AI 把你的速度放大了，也把你跳过的步骤放大了。

cbETH 定价公式那个 bug，其实并不难发现——如果有人专门去做安全审计的话。问题是 Vibe Coding 的节奏天然不鼓励停下来做这件事：模型给你一段代码，看起来完整，测试通过，你就继续往下走了。

研究数据也在佐证这一点：一项针对 15 个 AI 生成应用的研究发现，共存在 69 个安全漏洞——平均每个应用 4-5 个。

给用 AI 写代码的你：五条不能省的检查

用 Vibe Coding 写普通 CRUD 应用和写金融合约，风险级别完全不同。但以下几条，任何场景都适用：

1. 让 AI 给自己做安全审查 写完代码，让同一个模型（或另一个模型）扮演攻击者角色，问它：「如果我要攻击这段代码，我会怎么做？」

2. 数字计算必须人工验证 涉及金额、价格、汇率、百分比的计算，不要相信 AI 默认给你的公式。手算一遍，代入边界值：极大值、极小值、零、负数。Moonwell 的 bug 如果有人手动验证「cbETH 价格应该是美元量级，不是接近 1 的小数」，就不会发生。

3. 搞清楚代码的部署环境 在本地跑的代码出错，最多重启。在链上、生产数据库、支付系统里出错，没有撤销键。Vibe Coding 的速度感适合 demo，不适合 production。

4. 单元测试必须覆盖异常路径 让 AI 帮你写测试时，明确要求写"当价格数据异常时，系统如何响应"的测试用例。幸福路径（happy path）测试通过不代表系统健壮。

5. 外部数据接口做合理性校验 任何从外部获取的数据（价格、用户输入、API 响应），都应该在使用前验证范围。cbETH 的价格应该在 ETH 价格的 1-1.2 倍区间，超出这个范围就应该报警暂停，而不是直接使用。

结论

Moonwell 的故事不是 Claude 的问题，也不是 Vibe Coding 的问题。

是没有安全审查流程的问题。

AI 让写代码变得更快，这是真的。

AI 让代码变得更安全，这不是自动发生的。

防御者用好了 AI，能发现 500 个别人看不到的漏洞。

攻击者（或马虎的开发者）用好了 AI，能用几行代码造出 1280 万的窟窿。

差距在于：你在用 AI 加速的同时，有没有在关键节点停下来，做那些 AI 替代不了的判断。

素材来源：The Hacker News、ForkLog、Cryptopolitan、Anthropic 官方公告