Simon Willison 在 2026 年 5 月 5 日发布了 datasette-llm 0.1a7。这个版本只补了一个看起来很小的能力：可以为特定模型配置默认选项。

例子很具体。使用 datasette-enrichments-llm 做 enrichment 操作时，可以统一指定某个模型，并把 temperature 设为 0.5。

我更在意的不是 temperature=0.5 这个数字本身，而是它被放到了哪里。datasette-llm 是供其他 Datasette 插件依赖的 LLM 集成插件，不是 Datasette 原生内置的完整 LLM 平台。0.1a7 做的事，是把默认模型和默认参数往公共依赖层收。

0.1a7 更新了什么：给特定模型设默认选项

这次更新的功能点很窄：为具体模型配置默认 options。

原发布说明只点出这一项，没有说新增模型提供商，也没有说模型能力变强。它仍是 0.1a7，版本号里的 alpha 状态也提醒我们：这不是稳定正式版的承诺。

可以把变化压成一张表：

问题之前更容易出现的状态0.1a7 补上的能力影响
模型默认值各插件或各操作分别处理可为特定模型配置默认选项少写重复配置
参数一致性temperature 等参数容易分散enrichment 操作可统一套用默认值，如 temperature=0.5结果更容易复现和比较
插件边界上层插件各自维护一部分 LLM 配置逻辑datasette-llm 承担公共配置入口插件生态更容易协同
版本预期早期迭代datasette-llm 0.1a7不应按稳定版来用

这里的关键词不是“大模型”，而是“默认值”。

做过数据处理的人会知道，默认值常常不是小事。同一批数据，一部分 enrichment 用一个模型，一部分用另一个模型；一部分 temperature 是 0.5，另一部分忘了设。跑完以后，结果能不能解释，能不能复现，就会变成麻烦。

这就是 0.1a7 的真实价值：它不替你判断哪个模型更好，但让你更容易把选择固定下来。

默认参数配置解决的是插件生态里的碎片化

当只有一个插件调用 LLM，参数写在插件里也能凑合用。

但 Datasette 的 LLM 使用场景不会只停在一个按钮上。数据导入后做 enrichment，表格字段做标注，记录做摘要，后面都可能接上模型调用。插件越多，配置越容易散。

成熟软件生态里，这类问题并不新鲜。Django 项目会把数据库、缓存、中间件放到统一配置里；编辑器插件也会尊重工作区级设置。原因很简单：公共行为如果散在每个扩展里，维护成本会慢慢变高。

datasette-llm 0.1a7 更像是在 Datasette 的 LLM 插件层做同一件事。它把“用哪个模型、默认参数是什么”这类公共问题，往一个可复用的位置放。

对插件开发者，动作会更明确：如果插件依赖 datasette-llm，就可以少设计一套自己的默认参数逻辑，更多依赖公共配置机制。

对用 Datasette 做数据增强的技术用户，动作也很具体：同一批 enrichment 任务，应优先把模型和 temperature 这类参数放到统一配置里，而不是每次操作临时填一遍。

这不是为了好看。它减少的是参数漂移。

现在该观察什么：谁采用，规则是否清楚

这次更新不能被夸成“Datasette 做成了完整 LLM 平台”。原文也没有给出性能、成本、兼容性数据。更不能推导出它会自动降低调用费用。

目前能确定的只有一件事：datasette-llm 增加了按模型配置默认选项的机制，并且这个机制服务于依赖它的 Datasette LLM 插件。

接下来最该看三件事。

观察点为什么重要现实判断
上层插件是否采用这套机制只有被插件使用，公共配置才有意义datasette-enrichments-llm 是关键场景之一
配置格式是否继续变化0.1a7 仍是 alpha团队不宜把它当稳定接口押重注
插件级参数与模型默认值如何覆盖默认值冲突会影响结果解释覆盖规则越清楚，越适合团队流程

如果是个人项目，可以更快试。尤其是已经在用 Datasette 做 enrichment 的用户，统一模型和 temperature 默认值，立刻能减少手工配置。

如果是团队生产流程，做法应保守一点。可以先在非关键任务里验证配置方式，观察上层插件是否跟进，再决定是否迁移更多任务。这里的收益是维护成本下降，限制是 alpha 版本仍可能调整。

这类更新不热闹。没有新模型，没有跑分，也没有发布会式的口号。

但插件生态能不能长起来，常常取决于这些地基活：默认值放哪里，依赖边界怎么划，公共配置谁来管。datasette-llm 0.1a7 至少说明，Datasette 的 LLM 支持正在从单点调用，往可被多个插件共同依赖的工程结构靠近。