AI 生成代码之后，下一步很自然就是“跑一下”。这也是最危险的地方。代码生成工具越强，越容易让人忘记一个基本事实：你并不知道它刚刚写出来的代码会做什么。尤其是当系统开始支持 shell、文件读写、网络请求和动态预览时，沙箱就不是锦上添花，而是底线。

Cloudflare Dynamic Workers 提到的一个典型场景，是让 AI 生成的应用在安全、轻量的 isolate 中按需运行，并且可以拦截网络请求。这个方向值得关注，因为它解决的不是“如何生成更多代码”，而是“如何安全地试运行生成代码”。

实战里要隔离什么

很多人以为沙箱就是 Docker 起一个容器。容器当然有用，但 Agent 场景里的隔离粒度更细。你至少要隔离文件系统、环境变量、网络访问、执行时间、资源上限和外部凭据。AI 生成的代码不应该默认拿到你的生产 token，也不应该默认能访问内网服务。

一个个人开发者可落地的版本是：预览环境只挂载临时目录，只暴露 mock 数据，只允许访问白名单域名，只运行有限命令，并在任务结束后销毁。不要为了演示顺滑，把本地 .env 整个丢进去。那不是效率，是把事故写进产品说明书。

如果你做的是“AI 帮用户生成小工具”的产品，沙箱还应该支持回放。用户报错时，你需要知道当时生成了哪些文件、执行了哪些命令、拦截了哪些请求、资源是否超限。没有这些信息，线上问题只能靠猜。

踩坑：沙箱不是只防恶意代码

第一个坑是只考虑攻击，不考虑误操作。AI 写出死循环、疯狂请求 API、生成超大文件、递归安装依赖，未必是恶意，但照样能把你的服务拖垮。资源上限和超时比“相信模型不会乱来”可靠得多。

第二个坑是让沙箱访问真实第三方服务。比如让生成代码直接调用 Stripe、GitHub、数据库或邮件服务。实战中应该先用 mock 或专用测试凭据，生产凭据只在人工确认后的部署流程里出现。

第三个坑是沙箱结果不可解释。用户看到预览失败，只得到一句“运行错误”，体验会很差。沙箱应该输出结构化错误：依赖安装失败、启动失败、端口未监听、网络被拦截、资源超限。这样 AI 才有机会自动修复，人也能看懂问题。

结论

AI 生成代码的下半场，不只是更快生成，而是更安全地运行、预览和修复。个人开发者如果在做生成式开发工具、内部自动化平台、Agent 执行器，应该尽早把沙箱当成核心模块，而不是等用户数据出事后再补。能运行，只是第一步；能受控地运行，才是工程化。

参考：Cloudflare Dynamic Workers：https://blog.cloudflare.com/dynamic-workers/