Tukuan.ai 0.11 正式发布：
回到一条主路径

Tukuan.ai 0.11 已发布。

这一版把模型选择、计费、文件上传和站内通知收拢到了同一条产品路径里，让 Tukuan.ai 更像一个真正可用 的分析产品，而不是几块能力的拼接。

0.10 打下了账号、身份和隔离层的基础。0.11 做的，是把这些基础真正推到用户可感知的层面：你可 以在同一个工作台里选择合适模型、看到可信的套餐和计费状态、直接上传文件开始分析，也能在产品内部 持续收到与自己相关的通知和公告。

0.11 改变了什么

0.11 的重点不是某一个孤立功能，而是此前还比较分散的几块能力，现在开始按一条统一逻辑工作：

• 模型选择会按照当前套餐自动约束
• 套餐和计费状态以最终生效结果为准，而不是以支付跳转页面为准
• 上传文件会进入和其他分析输入相同的 Workbench 路径
• 运营通知和账户公告会进入可持久保存的 inbox 历史

对用户来说，这意味着产品行为会更一致。你不需要在几套不同的入口、不同的状态判断、不同的保存方式 之间切换，来猜系统到底以哪一套逻辑在工作。

按套餐感知的模型选择

在 0.11 之前，模型选择更像一层偏内部的系统逻辑。到了 0.11，它开始变成一条更明确的产品规则。

用户仍然可以使用 auto，但 auto 不再是一个含糊的默认选项。系统会根据当前账户套餐，在允许范围 内自动选择合适模型；只有在当前任务确实需要更强能力时，才会提升到更高规格。

对用户的直接意义是两点：

• 你看到的模型能力和你的套餐是对齐的
• 你不需要自己处理底层模型和 provider 的复杂差异

我们希望模型选择更像产品能力，而不是把底层技术细节直接丢给用户。

像产品真相一样工作的计费系统

0.11 也把商业化路径切换到了当前的 Paddle 生产流。

这个版本加入了 Paddle checkout、billing portal、账单摘要页面和账单记录可见性。更关键的是，它强 化了一个规则：套餐和计费状态，应该以最终确认后的结果为准，而不是以一次支付成功跳转为准。

这看起来像后台细节，但本质上是产品可信度问题。因为如果套餐状态、credits 和订阅状态不稳定，模型 能力和使用限制就会显得不可信。

对用户来说，这一版的变化是：你在产品里看到的套餐状态，应该更接近真正已经生效的状态，而不是一个 短暂的页面结果。

上传文件成为一级输入

0.11 里另一个很关键的变化，是上传文件不再被当成旁路。

CSV 和 XLSX 现在可以直接进入系统，并以正常对话的一部分回到 Workbench 里。对于 Cloudflare Worker 部署，这个版本也新增了直连 R2 的上传模式，支持签名 session 和可恢复的 multipart 上传。

对用户来说，这件事很直接：你现在可以更自然地从一个文件开始分析，而不是先走一条“上传路径”，再切 到另一条“分析路径”。

我们一直希望 Workbench 是同一条主路径的起点。文件输入现在终于更接近这个目标。

Inbox、维护通知与账户公告

0.11 还给产品加上了一层更持久的沟通界面。

新的 /inbox 成为应用内消息中心，支持未读数、已读与 dismiss 动作，以及 header 预览整合。在此基 础上，平台维护通知现在可以同时出现在全局 notice bar 和 inbox 历史中。符合条件的非个人账户管理 员，也可以向当前成员发布账户公告。

这不只是 UI 润色。它让产品第一次有了一个稳定的站内沟通位置，而不是把重要信息塞进短暂的 toast 或 一次性提醒里。

对用户来说，这意味着和你有关的通知不再那么容易“看过就丢”，而是有一个可以回头查看的地方。

持续加固受治理主路径

除了用户能直接看到的功能，0.11 也继续推进了很多加固工作：

• semantic discovery draft 继续向更稳定的配置入口收敛
• dashboard refresh 失败时会返回更可检查的问题信息，而不是不透明地失败
• 计费幂等、webhook 重试和最终状态处理更严格
• 上传校验、session 启动和管道完整性检查更稳
• inbox 状态同步和深链恢复路径更可靠

这些都不是“演示型功能”，但它们决定了产品在真实使用里是不是稳定、是不是可信。

为什么这个版本重要

对我们来说，0.11 的意义在于，几块此前还更像基础能力的系统，终于开始像一个完整产品那样协同工 作。

用户现在可以在同一个产品路径里，获得更一致的模型体验、看到更可信的计费状态、把文件自然带入分析 流程，并收到可持久保存的站内通知。

这就是为什么我们把 0.11 称为产品化发布版本。