datasette-llm 连发小修：默认参数和调用账本，才是 LLM 进生产的硬门槛

Simon Willison 最近这两个小版本，单看都不像大新闻。

一个是 datasette-llm 0.1a7，给模型增加默认选项配置机制。另一个是 datasette-llm-accountant 0.1a4，修复 response chains 跟踪 bug，关联 datasette-llm#7。

但这两件小事放在一起，味道就变了。

LLM 应用刚做 demo 时，大家盯着“能不能跑”。真进生产后，问题会变成另一套：默认参数谁来定？调用链怎么追？钱花在哪？出错是谁的锅？

模型能力是前台戏。参数和账本，才是后台秩序。

发生了什么：一个管默认值，一个修账本链路

这次能确认的信息很少，也正因为少，不能乱拔高度。

相比只管默认参数，datasette-llm-accountant 0.1a4 把问题往后推了一步：默认值之外，还要能追踪响应链、把账记清。

这不是功能堆叠，而是工程闭环。

一个 LLM 请求现在很少只是“一问一答”。它可能触发检索、工具调用、二次改写、模型重试，再拼出最后那段回复。用户看到一句话，后台可能跑了一串链。

这串链如果记不准，后面全是雾。

成本雾。错误雾。责任雾。

为什么重要：LLM 应用最怕的不是贵，是不知道为什么贵

默认参数配置，看起来像小功能。其实它解决的是“谁来决定模型怎么跑”。

temperature、max tokens、系统提示、模型选项，这些东西如果散落在调用代码里，团队迟早会吃亏。今天这个页面改一点，明天那个插件改一点，线上行为就开始漂。

LLM 产品最麻烦的地方，不是它不稳定。是它的不稳定经常披着“灵活”的外衣。

默认选项机制的价值就在这里：把隐性决策显性化。把散在各处的调用习惯收回来。让一个项目至少知道自己默认在用什么方式和模型说话。

accountant 修 response chains，则是另一层约束：把一次输出背后的调用路径记录下来。

这两者合在一起，才像一个能进生产的系统：

• 默认参数可控，避免调用行为到处漂；
• 响应链可追，出了问题能复盘；
• 调用成本可归因，不靠感觉控预算；
• 插件生态能共享规则，而不是各写各的暗门。

原发布说明没有给具体 schema，没有说 token 怎么统计，也没有展开计费模型。这里不能替它脑补。

但“response chains”这个词已经够关键。

链路一旦断了，账本就只是摆设。

谁最受影响：不是普通用户，是把 LLM 接进工作流的人

普通用户大概率感知不到这些变化。

真正受影响的是两类人。

一类是用 Datasette 做数据应用、又开始接 LLM 的开发者。他们需要的不是漂亮演示，而是可控调用。默认参数统一之后，插件和应用之间少一点互相猜。

另一类是准备把 LLM 功能放进内部流程的小团队。尤其是那种一边查数据、一边生成摘要、一边触发工具的场景。

这类应用最容易在试用阶段看起来很顺，到了生产环境开始出账单、出事故、出甩锅。

一次调用几分钱不吓人。可链式调用一多，用户量一上来，重试再叠上去，成本曲线就不再听产品经理讲故事。

工程里最怕的不是贵。

最怕的是没人说得清为什么贵。

小版本暴露的大问题：AI 工程正在从“能跑”转向“管得住”

过去两年，LLM 应用的叙事太偏“跑起来”。

接 API，套 RAG，加 agent，做个 demo。屏幕上能吐字，故事就算讲完一半。

但生产环境不吃这一套。

生产环境问的是：

• 同一个请求为什么今天花 3 毛，明天花 3 块？
• 哪一步调用了更贵的模型？
• 工具调用失败后有没有重试？
• 用户投诉那次输出，链路还能不能还原？
• 默认参数是谁改的，什么时候改的？

这些问题不性感。可它们决定一个 LLM 功能是不是业务资产，还是一台会烧钱的魔术盒。

早期互联网也走过类似路径。访问日志、统计系统、广告归因，最开始都像边角工具。后来大家发现，没有它们，网站只有流量热闹，商业上是瞎的。

AI 不完全一样。但逻辑相似：当技术从玩具变成业务，计量系统就会从配角变成地基。

“天下熙熙，皆为利来。”放到这里很直白：调用算不清，规模化就是空话。

我不太买账那种只谈模型能力、不谈运营约束的 AI 乐观主义。

模型越强，团队越容易往里塞更多流程。流程越复杂，观测、审计、成本归因越不能缺席。否则模型看着更强，产品反而更虚。

这也是 datasette-llm 这条线有意思的地方。它没有把重点放在“又接了哪个更强模型”上，而是在补那些不起眼的控制面：默认参数、调用记录、链式响应追踪。

小修小补，不代表小问题。

很多系统垮掉，不是因为没有大功能，而是因为小账没人管，小链没人查，小默认值到处乱飞。

接下来该看什么：别看口号，看三件小事

这类项目后面不必盯着宏大路线图。

看三个具体变量就够了。

第一，默认选项能不能覆盖更多真实调用场景。只支持简单配置，和能在插件生态里稳定传递规则，是两回事。

第二，accounting 能不能从“记录调用”走到“解释调用”。记录花了多少是一层，说明为什么花、哪一步花、谁触发的是另一层。

第三，response chains 能不能成为调试和审计的基础。不是只给开发者看日志，而是在出错、超支、复盘时真的能用。

如果这三件事站住，datasette-llm 的价值就不只是“给 Datasette 接 LLM”。它会更像一套小而硬的 LLM 工程治理工具。

如果站不住，那它也会和很多 AI 插件一样：能跑，能演示，但一到生产就开始靠人肉补账。

热闹归热闹，账本终归要翻开。

LLM 进生产，先问能不能查清，再谈能不能飞高。