Simon Willison 给 Datasette 加了一个新插件：datasette-apps。它允许单文件 HTML+JavaScript 小应用跑在 Datasette 里面，不是另起一个前端项目，也不是把数据库接口裸露出去。

最值得看的一点很具体：这些小应用可以接真实数据库。于是问题立刻变了。不是“AI 能不能写出一个页面”，而是“这段页面代码凭什么读你的数据，凭什么写你的库”。

它能做什么，也被限制在什么地方

datasette-apps 的基本形态很克制：一个自包含 HTML+JS 文件，运行在 Datasette 托管的受限 iframe 中。

创建页会提供可复制的 prompt，方便拿去给 ChatGPT、Claude、Gemini 生成或修改应用。但插件本身不依赖 LLM。AI 只是特别适合这种单文件应用形态。

问题datasette-apps 的做法对开发者的影响
应用怎么写单文件 HTML+JavaScript适合快速生成搜索页、时间线、看板、小型录入界面
怎么读数据可执行只读 SQL能接真实数据，但读权限仍由 Datasette 管
怎么写数据只能走预先配置的 stored queries不能随便 UPDATE/INSERT，写入动作要先被白名单化
怎么隔离风险iframe sandbox + 不可变 CSP不能访问 cookies、localStorage，不能任意外连
怎么排错查询和错误有可见日志内部工具出问题时，不至于全靠猜

这不是通用低代码平台。它更像 Datasette 生态里的一个实验：给小应用一个入口，同时把入口做窄。

这个区别很重要。低代码产品常常卖“谁都能搭”。datasette-apps 这一路线更朴素：可以搭，但先别信它。尤其当应用是 LLM 生成的，默认不信任才是正常姿势。

对使用 Datasette、SQLite 或内部数据工具的开发者来说，比较现实的动作不是立刻迁移系统，而是先拿它做低风险内部工具：只读查询页、临时分析界面、固定流程录入。涉及敏感表、跨团队权限、外部网络请求的场景，应该先观望或只在受控环境试。

真正的产品设计藏在权限缝里

这套插件最有价值的地方，不是“能跑 JavaScript”。能跑 JS 的地方太多了。

关键是它把危险能力拆开：读是读，写是写，外连是外连，配置 CSP 又是另一项权限。

应用运行在 iframe sandbox 里，碰不到父页面 DOM，也读不到 cookies 和 localStorage。CSP 被设计成不可变，用来限制外部请求，防止应用把私有数据带出去。

应用和 Datasette 通信，也不是随手 fetch。它通过 MessageChannel 这类受控通道发请求，由父页面验证。听起来细碎，但内部工具的事故，往往就死在这些细碎处。

原文里有个安全插曲很说明问题。Claude Fable 5 做评估时发现过一个 CSP allow-list 权限漏洞：低权限用户如果能给自己的应用配置外部域名，就可能写一个恶意应用，诱导管理员访问，再借管理员权限查询并外泄数据。

这类攻击并不玄。代码权限低，但看代码的人权限高。内部系统里，最常见的风险不是黑客电影式破门，而是权限借道。

后续修复也对症：新增 apps-set-csp 权限，把配置外部域名这件事收紧给可信人员。普通用户只能从管理员预设的 allowed_csp_origins 中选择。

这里的教训很直接：不要把“用户能创建应用”和“用户能决定应用把数据发到哪里”放在同一个权限里。前者是生产力，后者是泄露通道。

“天下熙熙，皆为利来。”放到开发者工具里，就是人人都想少写代码、快交付。但门槛降下来后，成本不会凭空消失。它会转移到权限、审计、默认策略和运维责任上。

AI 写应用的分水岭，是默认安全

过去一年，LLM 写小工具已经不稀奇。一个表单、一个图表、一个 JSON 查看器、一个内部看板雏形，几句话就能出来。

真正难的是下一步：它要接真实数据，要给同事用，要保存状态，要能追日志，还不能把数据库开成公共水龙头。

datasette-apps 目前能给出的答案，是一条窄路：让 AI 擅长生成的单文件应用进入 Datasette，但用沙箱和白名单把它拴住。它没有证明“AI 应用已经安全”，只说明一件事：如果要让 AI 写的小应用碰数据，产品结构必须先假设它会作恶。

这和早期 Web 插件、浏览器扩展、企业内网脚本有点像。不完全一样，但权力结构相似：小工具看起来轻，实际拿到的上下文很重。一旦它能读用户身份、页面状态和数据库结果，就不再是玩具。

最受影响的不是普通用户，而是两类人。

一类是内部工具开发者。以前临时页面可以随手写，现在如果要让 LLM 参与生成，就要把 stored queries、CSP、日志和权限分组一起设计。否则省下的是前端时间，欠下的是安全债。

另一类是小团队的数据负责人。datasette-apps 可以降低做内部查询界面的成本，但不适合拿来绕过权限治理。采购或引入这类工具时，应该先看三件事：谁能创建应用，谁能配置外连域名，谁能批准写入动作。

接下来最该观察的，也不是它能不能生成更漂亮的 UI。

要看这几个变量：stored queries 的管理体验够不够顺；CSP 权限能不能被团队正确配置；日志是否足够支撑审计；低权限用户和管理员之间的边界能不能在真实协作里守住。

如果这些做不好，AI 写应用越快，风险扩散越快。模型越会写代码，产品越需要笨办法：锁门、记账、留痕、分权。

这次 datasette-apps 少见地把方向摆正了。它没有把 AI 生成代码当魔法，而是把它当不可信输入来处理。这个判断很老派，也更接近真实世界。