夜雨聆风想象一个很普通的场景。
你让 Claude 把一份 Google 文档做成幻灯片。做到一半，它发现当前的幻灯片工具不支持删除线，也不能把文字居中，更没有直接插入 SVG 的入口。
传统软件会怎么处理？
要么绕过去，要么告诉你“暂不支持”，再把需求送进某个永远排不完的产品待办列表。
但视频里的 Claude 做了另一件事：它先修改了这款幻灯片工具，给它补上缺失的能力，然后继续完成演示文稿。
这段演示来自 AI Engineer 在 2026 年 8 月 5 日上传的一场演讲。主讲人 Kenton Varda 是 Cloudflare 联合创始人，也是 Workers 架构的重要设计者。他展示的原型叫 Gadgets。
它表面上像一个 AI 版办公套件，真正大胆的地方却是：
每一份文档，都可以是一款独立应用；每个用户，都可以让 Agent 只修改自己的那一份。
如果这个方向成立，我们熟悉了几十年的“软件版本”，可能真的要被改写。
01 软件最大的浪费，是让所有人等待同一个版本
今天的云软件有一个默认前提：开发者在服务器上维护一套“正确版本”，所有用户访问同一套功能。
这个模式稳定、便于运维，却也制造了一个越来越明显的矛盾。
一款软件服务十万人，就会收到十万种细微需求。有人只想给看板加一个字段，有人想让表格多一种统计方式，有人只需要一个极其小众的导出按钮。
对开发团队来说，这些需求未必没有价值，只是很难进入主线版本。它们会在工单、论坛和 Jira 里等待，被优先级、兼容性和维护成本一层层过滤。
插件看似解决了问题，却经常把开发者带进另一个坑：为了开放一个小功能，需要设计 API、权限、生命周期、版本兼容和审核机制。最后，插件系统本身可能变成一次耗时数年的重写。
Gadgets 的判断很直接：既然 AI 已经能写出这段个性化代码，就不要逼平台把每一种小众需求都做进公共版本。
公共产品继续保持干净、可靠；个人真正需要的那一点变化，由自己的 Agent 加到自己的应用实例里。
02 Gadgets 不是部署平台，而是一套会“生长”的办公软件
第一次打开 Gadgets，用户看到的不是服务器、容器和部署按钮，而是一个很像办公套件的首页。
左边可以描述自己想要什么，右边则是已经拥有的应用实例：幻灯片、看板、文档、图表，甚至是临时生成的小工具。
左侧描述需求，右侧管理自己的应用实例
这里有两个很关键的概念。
Blueprint，蓝图。
它更像一份没有用户数据的应用模板。演示里已经有 Kanban、文本编辑器、幻灯片生成器等蓝图。用户可以从蓝图创建自己的副本，也可以直接描述需求，让 Agent 生成新的应用。
Gadget，应用实例。
它不是“所有人访问的一款 SaaS”，而是某一块看板、某一份演示文稿、某一个小工具本身。代码、状态与权限都围绕这一份实例组织。
这带来一个很微妙的变化：过去我们先购买一款软件，再把文档放进软件；在 Gadgets 里，文档和软件开始变成同一个东西。
一份演示文稿不只是数据，它还带着渲染、交互和编辑能力。缺什么功能，Agent 就可以只给这份演示文稿补什么功能。
03 真正困难的不是生成代码，而是约束代码
听到“让 AI 随时改应用”，很多开发者的第一反应不是兴奋，而是警觉。
AI 生成的代码不能默认可信。它可能写出 XSS，可能错误处理权限，也可能把本不该暴露的数据交给前端。如果只是把代码上传到一台普通服务器执行，个人应用越多，攻击面就越大。
Gadgets 的重点因此不是代码生成界面，而是一套新的信任边界。
根据演讲中的设计，应用界面运行在一个 null origin 的隔离 iframe 里。它不能直接读取宿主页面的 DOM、Cookie 或登录状态，只能通过 postMessage 与外层平台通信。
需要调用服务端时，前端通过 Cap'n Web RPC 请求自己的服务端代码；服务端代码则运行在动态创建的 Worker 沙箱里。平台只把明确授权的能力以 binding 的形式交给它，例如某一份状态存储，而不是把平台级 API Token 塞进生成代码。
分享和访问控制也不交给每个 Gadget 自己实现，而由宿主平台统一处理。
这解释了演讲中那句很容易被误读的话：在这个架构下，即使生成代码里出现 XSS，也“没有什么可偷”。
更准确的理解是：XSS 并没有从世界上消失，而是隔离环境尽量让恶意脚本拿不到宿主身份、其他应用数据和平台密钥。 漏洞仍然需要修，但它造成的权限半径被显著压小。
Cloudflare 官方的 Platforms 文档也采用相似思路：为不同租户运行隔离 Worker，通过 bindings 暴露存储和服务，并避免把底层凭证直接泄露给租户代码。
04 “没有容器、没有数据库”，到底是什么意思
演讲后半段还有一个很容易传播成口号的说法：Gadgets 不需要容器，也不需要数据库。
它不是说应用没有状态，而是说平台不需要为每个个人小应用单独准备一套传统容器和外置数据库。
每个应用拥有自己的服务端逻辑与状态接口
前端与服务端代码运行在 Workers / workerd 的隔离模型中；每个 Gadget 的状态可以落到与实例绑定的 Durable Object 中。用户创建一块新看板，相当于创建一个新的应用实例和一份独立状态，而不是复制一整套虚拟机、容器编排和数据库账号。
这套做法对“海量、很小、生命周期不确定”的个人应用尤其合适：
启动成本足够低，临时工具不必背着一套常驻服务器； 每个实例天然隔离，删除和分享的边界更清楚； 平台可以统一管理身份、资源上限、日志与权限； Agent 生成的代码只拿到完成当前任务所需的能力。
Cloudflare 现有的 Workers for Platforms，本来就在解决“让客户代码在平台内安全运行”的问题。Gadgets 更像是把这套底层能力向上翻译成普通用户可以理解的办公体验。
05 它真正可能改变的，不是开发工具
如果只把 Gadgets 看成“又一个 AI 生成网页工具”，就低估了它。
它瞄准的是软件里长期没有被满足的那部分需求：价值真实存在，但用户太少，不值得进入标准产品。
一个销售团队可以让自己的客户列表多一个特殊评分；研究人员可以给一份数据表临时增加领域计算；家长可以把家庭清单改成适合孩子使用的界面；小团队可以为一次活动生成只使用两周的内部系统。
这些软件不需要成为创业项目，也不需要服务一百万用户。它们只需要在一个具体时刻，为一个具体的人解决问题。
这可能让应用从“标准化商品”变成一种更接近文档的东西：可复制、可分享、可修改，也可以在任务结束后被丢弃。
而专业开发者的价值并不会消失。相反，真正重要的工作会从“给每个人加同一个按钮”，转向设计可靠的蓝图、权限模型、数据边界、审计机制和复杂业务系统。
06 现在别急着把它当成成品
这场演讲最值得看的地方是架构方向，而不是下载按钮。
按照视频中的说明，Gadgets 在演讲录制时仍是原型，尚未开源，也没有面向普通用户提供完整安装流程。因此，当前没有可信的“一键部署教程”可写，网上出现的同名项目也不能直接视为这套原型。
它还需要回答不少现实问题：
Agent 改坏应用后，如何稳定回滚和比较版本； 应用分享给别人后，代码与数据分别如何迁移； 外部网络、邮件、支付等高风险能力如何逐次授权； 大量个人实例如何做成本控制、日志审计和长期维护； 用户如何理解“这份文档其实也在运行代码”。
最重要的是，隔离只能限制权限，不能保证业务逻辑正确。 一个不会泄露数据的报表，也可能算错数字；一个拿不到平台密钥的 Agent，也可能在授权范围内误删内容。
所以 Gadgets 展示的不是“AI 写代码已经绝对安全”，而是一条更可信的路线：先承认生成代码不可靠，再用平台架构把它关进足够小的权限盒子里。
最后
过去二十多年，云软件把安装、升级和运维从用户电脑搬到了开发者服务器上。我们换来了稳定，也逐渐接受了一个事实：软件长什么样、什么时候更新，决定权在服务商手里。
AI 现在开始把一部分决定权送回来。
不是让每个人都成为全职程序员，也不是让每个人维护自己的服务器，而是让软件在可靠边界内，长成使用者当下需要的样子。
视频里最让我印象深刻的，不是 Claude 生成了一个多复杂的界面。
而是它遇到“这个软件没有该功能”时，没有停下来等下一个版本。
它把软件本身，也当成了可以继续编辑的内容。
这或许才是个人 AI 应用真正的起点。
参考资料：
AI Engineer 演讲视频：https://www.youtube.com/watch?v=RmS5s6Wbin4 Cloudflare for Platforms 文档：https://developers.cloudflare.com/cloudflare-for-platforms/ Cloudflare Workers for Platforms：https://www.cloudflare.com/developer-platform/products/cloudflare-for-platforms/ Cloudflare 关于 AI 生成代码隔离的文章：https://blog.cloudflare.com/deploy-your-own-ai-vibe-coding-platform/