Simon Willison 这次发布的 datasette-apps，表面看只是一个 Datasette 插件：把一段自包含 HTML、CSS、JavaScript 放进 Datasette 页面里跑。

真正有意思的地方在后面。

如果 AI 已经很擅长生成前端小工具，那这些工具要不要永远停在临时 Demo？能不能安全接上一份真实、持久、可查询、可写入的数据？datasette-apps 给出的答案是：可以试，但必须把边界画死。

它做的是受控小应用，不是通用低代码

datasette-apps 允许用户在 Datasette 里托管单文件小应用。应用运行在 <iframe sandbox> 中，可以渲染 HTML/CSS/JS，但不能碰 Datasette 主页面的敏感东西。

几个关键点很清楚：

问题datasette-apps 的做法现实影响
前端怎么来单文件 HTML+JavaScript适合手写，也适合 LLM 生成和修改
跑在哪里受限 iframe sandbox不能访问 cookies、localStorage、父页面 DOM
能不能联网默认用 CSP 禁止外部请求降低恶意或有 bug 应用外传私有数据的风险
怎么读数据通过受控 SQL 查询不是让脚本随便碰 Datasette
怎么写数据只能调用 allow-list 的 stored queries写入被收进明确授权的管道
父子窗口怎么通信用 MessageChannel，而不是只靠 postMessage页面跳转后通道会关闭，多一层防御

它的主场不是替代 Retool、Appsmith 或完整内部系统。至少从这次发布看，它更适合 Datasette 数据之上的小型界面：搜索页、时间线、数据看板、内部查询工具、有限写入表单。

AI 在这里是加速器，不是发动机。插件本身不依赖 LLM。

你可以复制创建页面里的 prompt 到 ChatGPT、Claude、Gemini，让模型生成单文件应用。也可以配合 Datasette Agent，像 Claude Artifacts 那样生成、编辑应用。但没有 AI，这套机制照样成立。

这点很关键。因为“AI 会写网页”已经不新鲜了。新鲜的是，AI 写出来的网页开始接上受控数据库后端。

它像 Claude Artifacts 接上了持久数据

Claude Artifacts 的体验很顺：说一句，模型给你一个能跑的小界面。

但它的短板也明显。很多 Artifacts 更像纸飞机，飞得起来，落不下来。没有稳定数据层，没有权限模型，没有长期可维护的后端关系。

datasette-apps 补的是这块。

SQLite/Datasette 负责数据。LLM 可以负责界面。浏览器沙箱负责划边界。三件事合在一起，小工具开发的动作就变了：不一定要“写一个应用”，也可以是“给已有数据套一个可控界面”。

这对两类人最直接。

一类是用 Datasette、SQLite 做内部数据工具的开发者。以前运营、编辑、研究同事要一个过滤器、一个时间线、一个状态修改页，很容易卡在排期里。写正式系统太重，扔 Excel 又太散。现在可以把数据留在可查询、可审计的后端，把界面做轻。

另一类是已经在用 LLM 写小工具的人。接下来要调整的不是“让模型多写点代码”，而是给模型一个更窄的目标：只生成单文件界面，只调用允许的 API，只在指定数据边界内工作。

这有点像早期 Web 里的 CGI，也像后来的 Rails 脚手架，但不完全一样。那时的问题是快速把数据库变成网页。现在的问题是，模型可以快速生成网页，数据和权限不能跟着失控。

“工欲善其事，必先利其器。”但工具一旦能碰私有数据，利器也会伤人。

真正要盯的是权限，不是 AI 写了多少代码

我更在意 datasette-apps 的安全设计。

它没有把自己包装成“安全运行任意代码”。它做的是受控风险：iframe sandbox 先把应用关起来；CSP 默认掐掉外部网络；读数据走受控 SQL；写数据必须通过 allow-list 的 stored queries；MessageChannel 再补一层父子窗口通信防线。

这条路线是对的。小应用最危险的地方，往往不是代码难看，而是权限拿得太顺。

原文里有个关键插曲。Claude Fable 5 做安全评估时发现过一个真实问题：低权限用户可以创建应用，查询可见表，再把数据发到自己允许的 CSP 主机；如果他诱导管理员访问这个应用，应用就可能借管理员权限查询私有数据并外传。

这个洞后来通过权限收紧修补：设置任意 CSP 白名单需要新的 apps-set-csp 权限，只给可信人员；站点管理员也可以配置 allowed_csp_origins，让普通用户只能从预设来源里选择。

这段比“用了多少 AI 辅助开发”重要得多。

它说明两件事。

沙箱不是魔法结界。权限设计也不只是在代码里写几个 if。管理员会点击链接，用户会复制代码，CSP 白名单会变成新的出口。浏览器能挡住很多技术路径，但挡不住一次被诱导的高权限访问。

所以 datasette-apps 值得肯定，但不能神化。它不是低门槛通用应用平台，更不是“放心运行别人给你的网页”。它目前更适合有 Datasette 基础、能理解 SQL 权限和 CSP 边界的团队。

如果你只是想让非技术同事随便拖拽搭应用，它不一定合适。如果你的数据权限很复杂、写操作影响生产流程，也不能只靠这个插件解决治理问题。

更现实的采用方式，是从低风险场景试起：只读看板、搜索界面、时间线、内部数据浏览器。等 stored queries、CSP 白名单、日志和管理员权限都跑顺，再考虑有限写入。

接下来最该看三件事：

观察点为什么重要
stored queries 的写入权限是否足够细写入一旦放宽，小工具就会变成生产入口
CSP 白名单和 apps-set-csp 权限怎么配置网络出口决定数据能不能被带走
查询与错误日志是否足够可见出问题时，团队要能知道应用查了什么、哪里被拦了

模型会越来越会写界面。这已经是便宜能力。

更贵的是边界：数据权限、网络访问、写入动作、审计日志、管理员配置。谁把这些做清楚，谁才有资格让 AI 小工具进入真实工作流。

小工具开发正在从“搭一座房子”，变成“在已有城市里临时开一扇门”。门开得快是本事。门通向哪里，谁能拿钥匙，才是分水岭。