如果你想知道生成式 AI 领域的真实情况——不是厂商在新闻稿中粉饰的幻象，而是开发者实际在构建什么——Datasette 创始人 Simon Willison 的观察几乎能带你直达真相。正如 Willison 多年来在其博客中持续记录的那样，我们在使用 AI 构建系统时，正重蹈 Web 2.0 时代的覆辙：把数据和指令当成一回事。过去，这个错误导致了 SQL 注入；如今，它带来了提示注入（prompt injection）、数据泄露，以及那些自信满满却大规模做错事的智能体。

基于 Willison 的实战笔记，以下是你的 AI 智能体策略很可能是一场安全噩梦的原因，以及如何通过一些看似枯燥但必不可少的工程手段来修复它。

提示注入就是新时代的 SQL 注入

Willison 曾撰文回顾他在十月份发表的一场演讲，主题是“危险地运行 Claude Code”。这恰好是一个绝佳案例，说明了为什么智能体既令人兴奋又令人恐惧。他先是描述了“YOLO 模式”带来的生产力飞跃，随即话锋一转，指出你应当警惕的原因：提示注入仍是“一种极其常见的漏洞”。事实上，提示注入就是我们这个时代的 SQL 注入。

Willison 一直强调所谓“致命三要素”（lethal trifecta）——如果你的系统同时具备以下三点，你就暴露在风险之中：

· 访问私有数据（如邮件、文档、客户记录）

· 接触不可信内容（如网页、外部邮件、日志）

· 具备对数据执行操作的能力（如发送邮件、执行代码）

这并非理论推测，甚至算不上稀奇。只要你的智能体能读取文件、抓取网页、创建工单、发送邮件、调用 webhook 或推送代码提交，你就已经构建了一个自动化系统，而任何不可信输入通道都可能成为指令注入的入口。你可以称其为“提示注入”、“间接提示注入”或“混淆代理”（confused deputy），名字并不重要，关键在于它的模式。

此时，指望用 AI 来检测 AI 攻击，就显得像是一种魔法思维。安全社区已警告一年之久：许多提议的防御方案在面对自适应攻击时会失效。一篇 2025 年 6 月的论文直言不讳：当研究人员针对防御机制定制攻击时，多数最新方法在多数情况下被绕过的成功率超过 90%。

换句话说，我们正在构建本质上就是“待触发的混淆代理”的自主系统。企业的解决方案并非更好的提示词，而是网络隔离、沙箱机制，并假设模型本身已经被攻破。

简而言之，这正是 AI 分散我们注意力之前，我们本应专注的基础安全实践。

上下文是缺陷，而非特性

开发者圈子里普遍存在一种懒惰的假设：上下文越多越好。当 Google（Gemini）或 Anthropic（Claude）宣布支持两百万 token 的上下文窗口时，我们会欢呼雀跃，因为这意味着可以把整个代码库塞进提示中。

听起来很棒，对吧？其实不然。

正如我此前所写，上下文不是魔法记忆，而是一种依赖。你向上下文窗口添加的每一个 token，都会扩大混淆、幻觉和注入攻击的攻击面。Willison 指出：上下文不是免费的，它本身就是一种投毒载体。

当前的最佳实践是改进架构，而非堆砌更大的提示。应考虑作用域明确的工具、小而清晰的上下文、隔离的工作区，以及将持久状态存放在专为此设计的存储系统中。换言之，“上下文纪律”意味着我们构建的系统要主动裁剪模型所见内容。如此一来，我们将 token 视为必要但批量存储时具有危险性的元素。

记忆本质上仍是数据库问题

Willison 将此称为“上下文卸载”（context offloading），这与我反复强调的观点一致：AI 的记忆问题归根结底是数据工程问题。对 Willison 而言，上下文卸载是指将状态从不可预测的提示中移出，存入持久化存储。

然而，太多团队正凭“感觉”（vibes）行事——把 JSON 数据块扔进向量数据库，就称之为“记忆”。请注意，当我们将这些线索串联起来会发生什么：

· Willison 说上下文不是免费的，因此必须卸载状态。

· 卸载状态意味着你在构建一个记忆存储（通常是向量数据库，有时是混合存储，有时是带嵌入和元数据的关系型数据库）。

· 这个存储既成为智能体的“大脑”，也成为攻击者的目标。

目前，大多数团队给智能体添加记忆的方式，就像早期 Web 应用把 SQL 直接拼接到表单上一样：仓促、乐观，且输入清洗程度大致相当（几乎没有）。这就是我为何坚持认为：记忆只是另一种数据库问题。数据库历经数十年积累的安全经验——最小权限原则、行级访问控制、审计、加密、保留策略、备份恢复、数据溯源和治理——同样适用于智能体。

此外，请记住：记忆不仅仅是“上次我们聊了什么？”，它还包含身份、权限、工作流状态、工具调用轨迹，以及系统行为及其原因的持久记录。正如我最近指出的：如果你无法回放记忆状态以调试智能体为何产生幻觉，那你拥有的不是一个系统，而是一座赌场。

让“感觉”付出代价

Willison 常被描绘成一位 AI 乐观主义者，因为他真心喜欢用这些工具编写代码。但他严格区分了“氛围编程”（vibe coding，即让 AI 写脚本并祈祷它能运行）和“氛围工程”（vibe engineering）。二者的区别就在于：工程。

在他的 “JustHTML” 项目中，Willison 并没有简单地让大语言模型输出代码了事。他为 AI 构建了一套包含测试、基准和约束的“安全框架”。他用 AI 生成实现，但用代码验证行为。

这与近期 METR 研究的发现一致：使用 AI 工具的开发者完成任务往往耗时更长，因为他们花了大量时间调试 AI 产生的错误。部分原因在于我曾指出的现象：AI 生成的代码“几乎正确”，而正是这个“几乎”需要不成比例的时间去修正。

对企业而言，结论显而易见：AI 并未取代“编写—测试—调试”的循环，它只是加速了“编写”环节，因此你必须加倍投入“测试”环节。

通往未来的枯燥之路

“封装一个 API 就上线”的轻松日子已经结束（如果它们真的存在过的话）。我们正从 AI 的演示阶段迈入工业化阶段，这意味着开发者必须把评估（单元测试等）视为真正的工作。据 Hamel Husain 所言，你应将 60% 的时间用于评估。开发者还需花更多时间打磨架构，而非仅仅磨练提示技巧。

颇具讽刺意味的是，生成式 AI 当前“最紧迫的问题”其实并不新，它们都是老问题。我们正在一个编译器偶尔会胡编乱造、代码可能被 Markdown 文件社交工程攻击、应用“状态”只是一堆 token 的世界里，重新学习软件工程与安全的基本功。

所以，没错，AI 模型确实神奇。但如果你想在企业环境中使用它们，又不想无意间暴露客户数据库，就必须停止把它们当作魔法，而应视其为不可信、甚至可能具有破坏性的组件。

因为正如 Willison 所言：没有扎实、枯燥、真正的工程，就不存在所谓的“感觉工程”。