AI开发：如何避免弄巧成拙

Patrick Collins

如何在使用AI开发时避免不慎自毁

AI是一个令人难以置信的生产力工具，但它正让我们变得鲁莽。这里有6个使用AI而不自毁的技巧——从安全提示到代理二分法（Agent Rule of Two）。

AI为软件工程师带来了惊人的生产力提升。我个人一直在使用Claude Opus 4.6——它通过了我的“氛围检查”，我用它来编写我几乎接触到的所有代码。在Cyfrin，我们也一直在与AI合作，以帮助保护我们的代码库。

但包括我们自己在内的整个行业，因为能用AI做越来越多的事情，所以变得越来越敢于做更蠢的事情。而且攻击面正在迅速扩大。

AI已经搞砸了

以下是AI已经出错的真实案例：

Moonwell事件。 安全审计师 Pashov 指出，Claude协助编写了Moonwell项目中 一个git提交，该提交错误配置了一个预言机，导致cbETH的定价约为1.12美元，而非2,200美元——造成了 178万美元的坏账。希望1美元继续是ETH的错误价格...

EchoLeak漏洞 (CVE-2025-32711)。 仅仅是发送一封开启了Microsoft 365 Copilot的电子邮件给某人，Copilot就会读取该邮件并被提示注入——自动将敏感数据发送给黑客。你甚至不需要打开邮件。

Slopsquatting。 AI幻觉出一个不存在的软件包。攻击者注册该软件包。现在，这个幻觉出的软件包真实存在——并加载了恶意代码。你的供应链被破坏了。

明文私钥。 已经是2026年了，AI仍然告诉人们硬编码私钥没关系。但事实并非如此。

根据 OWASP，三大AI攻击向量是：

1. 提示注入
2. 敏感信息泄露
3. Slopsquatting / 供应链攻击

而且AI编写的代码也并非无懈可击。BaxBench 排行榜显示，即使是最好的模型——Claude Code——也只有大约56%的时间能编写出正确且安全的代码。

那么... AI是坏的吗

没那么快。

Claude Opus 4.6 已经发现了500多个漏洞。AI项目一直在HackerOne的排行榜上大放异彩。在Cyfrin，当我们进行智能合约审计时，我们使用AI来帮助我们理解和浏览代码库。这是一项繁重的工作，既然AI对生产力如此有帮助，我不可能不使用它。

问题不是“我们应该使用AI吗？”——而是“我们如何在不自毁的情况下使用它？”

如果你更喜欢观看而不是阅读，本文有一个 配套视频。欢迎将你的AI指向这篇文章，以帮助你保持安全。

第一法则：这是你的错

在我们深入探讨这些技巧之前，这里有一个首要原则：你就是开发者，你就是安全研究员。 这意味着你对你发布的任何错误负责。

把错误归咎于AI是不对的。这是你的错。

你必须审查你的AI正在做什么。你必须知道你的AI可以访问什么。这就是所有这一切的总结。

技巧1：添加安全提示

听起来很蠢。我们都见过那些梗，有人要求Claude“给我创建一个价值十亿美元的公司，并且不要犯任何错误。”

但有趣的是，它确实有效。在 BaxBench 上，他们发现仅仅在提示中添加一个通用的安全提醒，就能将Claude Code的安全代码率从56%提高到66%。 仅仅通过告诉你的AI关注安全，就能实现如此显著的提升。

这就是Claude Code的技能系统等工具发挥作用的地方：

• Cyfrin SolSkill 帮助编写更安全的Solidity代码并捕捉常见的代码异味。
• Trail of Bits Claude Code Config 为你的Claude Code环境添加了一整套注重安全的设置。你绝对应该设置这个。

技巧2：使用常规安全工具

这是“显而易见”的建议，但人们忘记了：你仍然可以使用所有常规安全工具，同时结合AI。

像 Slither 和 Aderyn 这样的静态分析工具仍然非常有价值。不要因为你有了AI助手就停止使用它们。分层你的防御。

(并关注 Cyfrin 的 Twitter——我们正在这方面酝酿一些好东西。)

技巧3：容器化你的环境

使用容器化来隔离你的开发环境。对于智能合约开发，你可以启动一个隔离的容器，并将Claude或ChatGPT放入其中，以便环境被沙盒化。

Cyfrin devcontainer 是一个很好的起点。如果你的AI失控或被注入，影响范围将仅限于该容器，而不是你的整个机器。

技巧4：像处理放射性物质一样处理敏感信息

关于敏感信息有两个担忧：

1. 你不希望你的AI拥有敏感信息
2. 你不希望你的AI泄露敏感信息

规则是：如果你没有使用本地LLM，那么假设如果你的AI可以访问某个东西，那么全世界现在都可以访问它。

私钥绝不应该以明文形式存在，你的AI也绝不应该访问它们。Cyfrin SolSkill 内置了专门防止这种情况的提示。

技巧5：代理二分法

你们中的一些人可能在想：“Patrick，闭嘴。我想让我的AI访问我的敏感信息和密码，这样我就可以使用像OpenClaw这样的工具了。”

我个人不推荐这样做。但如果你执意要这样做，请使用代理二分法（Agent Rule of Two）。

这个框架源自 Meta的AI安全研究，灵感来源于 Simon Willison的“致命三位一体”概念 和Google Chrome团队的Rule of 2。

你的代理在任何时候都应该只具备以下三个属性中的两个：

• A. 代理可以处理不可信的输入
• B. 代理可以访问敏感系统或私人数据
• C. 代理可以改变状态或进行外部通信

选择两个。绝不能全部拥有。

如果你的AI代理同时具备这三个属性，你就完了。攻击者通过不可信数据（比如恶意电子邮件——见 EchoLeak）对你的代理进行提示注入，代理可以访问你的私人信息，并且可以将其发送出去。游戏结束。

但去掉其中任何一个：

仅B + C (无不可信输入)：恶意电子邮件永远不会到达AI。代理只处理可信来源。

仅A + C (无私人数据)：即使代理被提示注入，也没有任何敏感信息可供泄露。

仅A + B (无外部通信)：即使代理被注入并读取了你的敏感数据，它也无法将其发送到任何地方。

在使用像OpenClaw这样的工具时应用此原则。限制对特定账户的访问。拆分你的代理，这样就不会有任何一个代理成为单点故障。

在加密领域，要更加偏执

在智能合约世界中，我的建议更简单：根本不要给代理任何你的私人或敏感信息。

即使有了二分法（Rule of Two），如果你的代理本身被黑客攻击怎么办？如果你使用的是本地LLM，情况会稍微好一些，但你仍然应该担心云中的数据被盗。

技巧6：注意你的供应链

对于像slopsquatting这样的供应链攻击：知道你的AI正在建议哪些软件包。 不要仅仅因为AI告诉你，就盲目安装。验证它是否存在，验证它是真实的软件包，并验证它不是某人已经武器化的幻觉。

像 Snyk 和 npm audit 这样的工具可以提供帮助。

提示注入仍未解决

我把这个放在最后，因为它可能是当今最难防御的攻击。

是的，你可以进行输入净化。是的，你可以（也应该）进行人机协作（human-in-the-loop）交互，尤其是在审查智能合约代码时。但提示注入从根本上来说是一个我们尚未解决的问题。

值得注意的是：sockdrawermoney—— Code4rena（它开启了竞争性审计的热潮）的联合创始人，以及 npm audit 的共同创建者之一——一直在研究一种旨在通过污点追踪（taint tracking）来缓解提示注入的语言。每当你的代理接触到某个东西时，数据就会被标记为可信或不可信。这非常酷，我自己也还在深入研究。

总结（TL;DR）

1. AI是一个令人难以置信的生产力工具，但它正让我们变得鲁莽
2. 根据 OWASP，三大AI攻击向量：提示注入、敏感数据泄露、slopsquatting
3. 添加安全提示 —— 在 BaxBench 上将安全代码率提高了约10%
4. 使用安全工具 —— Slither、Aderyn 和静态分析仍然重要
5. 容器化 —— 沙盒化你的AI环境 ( Cyfrin 的 devcontainer)
6. 私钥绝不能以明文形式存在 —— 你的AI绝不应该访问它们
7. 代理二分法 —— 绝不能同时授予全部三项：不可信输入、私人数据和外部通信
8. 你对你的AI产生的一切负责。 审查它。审查所有的一切。

保持安全。

• 原文链接： cyfrin.io/blog/how-to-no...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～