Simon Willison 发布了 Datasette 1.0a33 alpha。不是 1.0 正式版，但这次比普通小版本更值得看。

关键变化只有一个：?_extra= 这个 JSON 响应扩展机制，不再只覆盖 tables，现在扩展到了 queries 和 rows。更要紧的是，它进了文档。一个 API 设计从实验走进文档，意思就不一样了：它开始朝 1.0 的稳定接口收口。

1.0a33 改的是 JSON API 的选择权

问题这次变化直接影响
版本状态Datasette 1.0a33 alpha仍不能当稳定 1.0 使用
?_extra= 范围从 tables 扩展到 queries、rows查询结果和行级响应也能按需加字段
文档状态已写入 JSON API 文档不再只是临时实验口子
演示工具extras API explorer可勾选 30 项 extras，看 JSON 响应变化
AI 参与Claude Fable 5 规划，GPT-5.5 xhigh 实现小型 API 工具的启动成本下降

?_extra= 解决的不是权限问题，也不是查询语言，更不是数据库性能优化。

它解决的是一个很具体的问题：调用 Datasette 的 JSON API 时，调用方到底想拿多少附加信息。

默认响应保持干净。需要列名、总数、计数 SQL、数据库名、数据库颜色、列类型等信息时，再通过 ?_extra= 点名要。比如请求某个表的 JSON 时，可以额外要求 columns 这类字段，而不是让服务端默认把所有元数据都塞进去。

这对两类人最直接。

插件作者要开始检查自己是不是依赖了旧的表级 extras，后面如果要支持 queries 和 rows，就要把扩展点想清楚。数据发布者和 API 使用者可以开始测试新文档里的写法，但最好先把它放在试验环境里，不要把 alpha 接口当成长期契约。

好 API 的分寸，是默认少给一点

我更看重的不是 30 项 extras，而是这个设计没有急着把响应做胖。

很多 API 走到 1.0 前，会忍不住把默认返回堆满。今天加一个 count，明天加一个 schema，后天再加一段调试信息。短期方便，长期麻烦。调用方开始依赖每一个字段，服务端也就越来越改不动。

Datasette 这次选了另一条路：默认响应尽量克制，复杂度由调用者声明。

这有点像早期 Web API 从“页面旁边顺手吐点 JSON”，走向“调用方明确选择自己要什么”。不完全一样，Datasette 也不是平台级革命。但权力结构相似：返回什么，不再完全由服务端替你决定。

“多则惑，少则得。”放在 API 上也成立。字段不是越多越体贴。默认路径越干净，长期维护越有余地。

?_extra= 的好处就在这里。它没有另起一套大协议，也没有把 Datasette 包装成 GraphQL。它只是沿着 URL 参数这个旧机制，把可选复杂度变成显式选择。

这类小设计很容易被低估。真正成熟的接口，往往不是功能最多，而是知道哪些东西不该默认给。

AI 做 explorer，是开发流程的信号，不是产品主菜

Simon 还做了一个 extras API explorer。Claude Fable 5 在 Claude Code 里负责规划，GPT-5.5 xhigh 在 Codex Desktop 里负责实现。这个工具可以勾选 30 项 extras，看请求 URL 和 JSON 响应怎么变。

别把它误读成 Datasette 的核心能力。它只是演示工具。

但它说明了一个现实变化：一次性开发者工具的启动成本正在下降。过去给 API 写一个 explorer，哪怕只是演示，也要花一段完整时间。现在有 AI 辅助，很多“以前懒得做”的解释层，会更容易被补出来。

问题也在这里。

AI 降低的是第一锤成本，不是维护成本。文档同步、边界条件、版本兼容、用户预期，这些账不会自动消失。工具一旦被人用起来，就会从“顺手做的 demo”变成“别人会依赖的入口”。

所以我不把这个 explorer 看成产品亮点。我更愿意把它看成 API 设计的压力测试：接口清楚，AI 很快能帮你做出解释层；接口混乱，AI 只会更快把混乱可视化。

接下来最该看两个变量。

一个是 ?_extra= 在 1.0 正式版前会不会继续稳定，包括 extras 名称、语义和 queries、rows 上的行为边界。另一个是插件作者会不会真正围绕它适配，而不是继续各写各的扩展返回。

如果这两件事走稳，1.0a33 就不只是一个 alpha 小版本。它更像 Datasette 在 1.0 前补上的一块接口地基：把选择权交给调用者，把实验写进文档，再用 AI 快速做出可交互说明。

小参数不小。它决定的是 API 以后会不会越长越乱。