AI 写的代码越聪明，系统就越危险：Cloudflare 工程师的睡不着觉时刻

当 AI 从“自动补全”进化到“自己写、自己跑、自己改代码”，我们交付速度飙升，但风险也被彻底低估。Cloudflare 的开发者布道师直言：你正在运行的，可能是来自互联网的、不可信代码。这场演讲讲清了一个所有 AI 工程师都绕不开的问题：为什么必须 sandbox AI 生成的代码，以及怎么做才不翻车。

最反直觉的真相：AI 帮你写得越多，你越像在裸奔

演讲一上来就戳破了一个行业幻觉：问题不在于“AI 会不会写代码”，而在于“我们已经让 AI 直接运行代码”。从自动补全，到完整代码生成，再到能自己执行、检查、复盘、迭代的 AI Agent——这不是效率工具的线性升级，而是信任边界的彻底崩塌。Harshil 说得很直白：我们正在运行来自互联网的不可信代码。LLM 是黑盒，它有时完全正确，有时微妙地错，有时——直接危险。真正让人睡不着觉的，不是模型不够强，而是它强到足以被当成生产系统的一部分。

三种真实存在的风险：不是“如果”，而是“已经在发生”

这些威胁不是安全团队的假想敌，而是 LLM 天生属性带来的结构性风险。第一种是幻觉：代码能跑、测试也过，但逻辑是错的，错得还很隐蔽。第二种更讽刺，叫“过度热心的 LLM”：模型忠实执行你的意图，却顺手做了你没意识到的高危操作。第三种才是安全视角最警惕的——被污染的 prompt。这里 LLM 并没有被黑，它只是被“正确地使用”在了对抗性输入上，结果自己成了攻击向量。这一点非常关键：问题不在模型是否被攻破，而在系统是否默认信任了它的输出。

解法不新，但原则很硬：别想着拦坏事，只允许好事

好消息是，这不是第一次人类要运行不可信代码。浏览器、操作系统、云平台，早就踩过坑。贯穿所有成功 sandbox 的核心原则只有一个：基于能力的安全模型（Capability-based Security）。不是枚举“哪些不能做”，而是明确“只允许做哪些”。默认拒绝，一切能力都要显式授予。这听起来保守，但它是唯一在规模化系统里被反复验证过的方式。把这个原则套回 AI 生成代码，你会发现：真正的问题不是模型，而是你给了它太多它不该有的能力。

没有银弹：eval、容器、隔离级别，全看你的需求

Harshil 给了一个非常工程师视角的答案：sandbox 不是非黑即白，而是一条光谱。最左边是几乎零隔离的 eval，风险最大；中间是容器；再往右是更强隔离。关键洞察在于：不是哪种技术最好，而是你的用例需要多强的隔离。他分享了自己构建应用时的两种实践：当需求简单、只需要 JS 执行环境时，用 V8 isolates，通过 binding 严格控制能力；但当需求升级，比如生成视频，就必须承认 isolates 不够用，直接上完整 Linux 容器——而且是“一用户一沙箱，没有例外”。这是成熟工程判断，而不是技术洁癖。

那张 takeaway 幻灯片，其实是给所有 AI 团队的警告

演讲最后的总结几乎可以贴在每个 AI 项目的 README 里：默认拒绝网络访问；只授予明确需要的能力；AI 生成的代码就是不可信代码；必须 sandbox、约束、并且每一次都要验证。这不是悲观主义，而是对现实的清醒认知。AI 会继续变强，但安全从来不是“等模型更聪明了就好了”的问题，而是系统设计的问题。

总结

如果你在做 AI 应用，这场演讲真正想告诉你的只有一件事：别再把“模型输出”当成“内部代码”。一旦 AI 能写代码、跑代码，它的权限模型就必须和外部攻击者同级对待。短期你可以做的，是审视系统里哪些地方默认信任了 LLM；中期，是引入真正的 sandbox 和 capability 设计；长期来看，谁能把“AI 不可信”内化成架构共识，谁才能放心地把 AI 推向生产。问题留给你：如果今天你的 LLM 生成了一段恶意但“看起来很合理”的代码，你的系统，能挡住吗？

关键词： AI安全， 代码生成， Sandbox， 大语言模型， AI Agent

事实核查备注： 需要核查演讲者姓名拼写（Harshil Agrawal / Hershel）、其在 Cloudflare 的具体头衔、视频时长以匹配文章长度假设、V8 isolates 与容器示例是否为演讲中的原话或演示内容