$1.78M “Vibe” 检查：Moonwell 事件教会我们的 AI 安全

Source: Dev.to

想象一下，你写了一行看起来完美、通过了单元测试并且得到了资深审查员的“点赞”的代码——结果它在几分钟内抹去了 1.78 百万美元。

这正是 2026 年 2 月在 Moonwell 这家去中心化借贷协议上发生的事。转折点是？这个 bug 并非人类编写，而是由 Anthropic 的 Claude Opus 4.6 共同创作的。

欢迎来到 “vibe coding” 的时代——代码看起来很对，但逻辑却是一个定时炸弹。

178万美元的 “Vibe” —— 出了什么问题？

事件围绕一个名为 MIP‑X43 的治理提案展开。其目标很简单：集成 Chainlink 的 Oracle 可提取价值（OEV）包装合约，以处理 cbETH（Coinbase 包装的质押 ETH）的价格馈送。

AI 生成的代码在语法上完美无缺，能够编译，看起来也很专业。但它遗漏了一个基本的数学步骤：乘法。

代码没有将 cbETH/ETH 汇率乘以 ETH/USD 价格馈送，而是直接把原始的兑换比例当作已经是美元计价的数值使用。

结果？

• 实际 cbETH 价格： ~$2,200
• Oracle 报告的价格： $1.12
• 后果： 99.9 % 的低估导致瞬间清算连锁反应。套利机器人蜂拥而至，以几分钱的价格抢夺大量抵押品。

“Vibe Coding” 陷阱

我们都有过这样的经历：让大型语言模型（LLM）“为这个预言机写一个 Solidity 包装器”，它就会输出看起来和文档一模一样的代码。这就是 vibe coding——依赖 AI 输出的“可信度”，而不是严格的逻辑验证。

Moonwell 事件是一个关于此类风险的典型案例：

• 语法完美： 代码整洁，遵循了所有最佳实践。
• 逻辑幻觉： AI “幻觉”地把原始比例当作了最终价格。
• “瑞士奶酪”失误： 人工审查员、GitHub Copilot，甚至像 OpenZeppelin 的 Code Inspector 这样的自动扫描工具都未能发现问题。

为什么会这样？因为 自动化偏差。我们倾向于比自己的直觉更信任高级模型和扫描器。如果 AI 说它是好的，我们就默认数学计算是正确的。

从聊天机器人到代理 AI

我们正快速从“聊天机器人 AI”（模型回答问题）转向 代理 AI（如 Claude Opus 4.6 这类模型实际上能够编写、测试并部署代码）。

在传统工作流中，bug 是人为错误。在代理系统中，漏洞是一种 具有执行能力的幻觉。安全性不能再是冲刺结束时的“最终检查”；它必须成为部署的前提条件。

如何保障 AI 辅助的工作流

如果你正在使用 AI 来帮助编写生产代码（说实话，我们大多数人都是这么做的），你需要一本全新的操作手册。以下是避免出现 “Moonwell‑style” 灾难的三条实用步骤：

1. 重新定义 “Human‑in‑the‑Loop”（HITL）

不要只对 AI 的 PR 进行形式审查。进行 对抗性测试：与其检查 AI 做了什么，不如寻找它 没做什么。在 Moonwell 案例中，如果审阅者专门问 “美元转换在哪里？” 本可以避免 178 万美元的损失。

2. 使用专用的 AI 安全扫描工具

标准的静态分析工具虽能检查语法，但往往漏掉细微的逻辑幻觉。部署专为模拟边缘情况并验证 AI 生成逻辑的数学一致性而设计的工具。

3. 对 AI 输出采用 “零信任” 策略

将每一行 AI 代码视为可能有缺陷，直至证明其安全。对 AI 代理能够触及的系统设定严格边界，并对涉及金融资产或核心基础设施的任何代码要求多签批准。

AI 确定性的未来

Moonwell 事件不仅是 Web3 的警示故事；它也是对每位开发者的警醒。随着我们在工作流中集成更多自主代理，对 AI security 和严格治理的需求已不可协商。

在 NeuralTrust，我们正在构建确定性的基础设施，帮助团队弥合信任鸿沟。目标不是停止使用 AI，而是以确信单一的“氛围”不会演变成系统性故障的方式使用它。