Telegram 无服务器

疑似 AI 生成的文档

• 许多评论者确信 Telegram Serverless 文档是 LLM 写的，理由包括：
  • 反复出现诸如“没有 X，没有 Y，没有 Z”的模式。
  • 过度使用某些副词（例如“silently”“quietly”）以及加粗文本。
  • 某些句法习惯、强否定结构，以及“短促有力”的文风。
• 有人认为这些信号只有高度活跃于网络 / 技术圈的用户才会觉得明显；另一些人则指出，非母语者或较少接触 AI 的读者可能不会注意到。
• 有人分享了其他地方关于“Signs of AI writing”的文档链接。
• 少数人认为未披露的 AI 使用“很廉价”或是在浪费他们的时间；也有人说，这很适合冗长、枯燥的文档，而且这些内容将来大概率也是被其他 LLM 阅读。

架构与能力

• 无服务器 bot 运行在靠近 Telegram 系统的轻量级 V8 isolates 中。
• 每个 bot 附带一个 SQLite 数据库被视为一个很强的便利功能；大小限制没有文档说明。
• Bot 可以通过 HTTP 发起请求，具备：
  • 仅文本响应。
  • 32 MB 的响应上限（不清楚是按请求还是按调用）。
  • 没有直接的非 HTTP socket 访问，因此 Telegram 能在 URL 级别看到流量。

数据中心与 SQLite 复制

• Telegram 的基础设施被描述为少量逻辑数据中心（DC）；每个用户和 bot 都绑定到一个“home DC”。
• 写入只在 home DC 发生；bot 通常也在那里运行。
• 这表明 SQLite 很可能不是全局复制的；大多数交互都留在同一个 DC 内，从而简化了一致性。
• 全局排行榜之类的功能可能会很棘手；SQLite 具体如何处理仍不清楚。

限制、成熟度与开发体验

• 目前还没有明确的信息说明：
  • 执行时间、CPU、内存或带宽配额。
  • SQLite 数据库的存储限制。
• 密钥管理看起来很简陋：
  • 没有一等公民的 env var / secrets store；有人建议检查入一个放在版本控制之外的“secrets.js”文件。
• 缺少诸如 npm 依赖、TypeScript 支持、cron jobs，以及更丰富的运行时 API 等便利；有些人认为借鉴 Cloudflare Workers 的模式会有帮助。
• 只支持 JavaScript；一些人对 JS 持续占主导地位表示遗憾。

定价、商业模式与封闭测试

• 没有公开定价信息；许多人对在缺乏清晰模式的情况下构建其上感到不安。
• 一些人推断它现在是免费的，因为它处于封闭测试；有人引用了 Telegram 开发者聊天链接作为确认。
• 有人认为运行 JS 函数的增量成本相较于 Telegram 的整体存储和带宽成本很小。
• 关于 Telegram 可持续性的更广泛争论：
  • 一方认为大规模聊天 + 媒体 + bots 的成本非常高，不太可能仅靠 Premium 分层覆盖。
  • 另一方说聊天本身相对便宜；主要成本是大体积媒体的存储。
  • 广告和 Premium 账号被提及为收入来源；与加密货币的关联以及过去“可疑”的行为让一些人心存疑虑。
• 怀疑者担心，一旦开发者投入后，未来会被锁定并面临价格变动。

与其他消息平台的比较

• 多位用户称赞 Telegram 的 bot API 比 WhatsApp 的成熟且易用得多：
  • WhatsApp 的 business API 被认为手续繁琐、依赖合作伙伴，并且更面向企业收费。
• Signal：
  • 一些人把缺少 bot API 看作是隐私和简洁性的 feature。
  • 另一些人说这会阻碍迁移，因为他们依赖 Telegram 上大约 10 个以上的个人自动化 bot。
  • 第三方方案如 signald 为 Signal 提供了类似 bot 的 API，但需要自行托管。
  • 有人提到，使用 Telegram bots 会把内容暴露给 Telegram（bot 后端没有 E2EE），而基于 Signal 的 bots 可以保留更多隐私；关于 Signal 的电话号码要求也被提到，但尚未完全厘清。

垃圾信息、Bots 与用户体验

• Telegram 的公开侧被一些人描述为“充满 bots 和 spam”：
  • 其他人反驳说，bots 是 Telegram 的核心优势，对于自动化和集成极其有用。
  • 许多人表示 spam 主要与加入低质量公开频道/群组有关；在有熟人的私群里几乎没有 spam。
• 有人建议对用户收取小额费用以阻止 spam bots；也有人强调官方 bots 不能先向用户发消息，而且会被清楚标记。

使用场景与替代方案

• 人们讨论将无服务器 bots 用作：
  • 个人脚本、通知、电价、服务器宕机告警的 UI。
  • LLM 的前端（通过 OpenRouter 或类似服务），提供自定义规则、存储和记忆。
• 有人建议干脆使用像 Cloudflare Workers 这样的成熟平台来托管 bot 后端，理由是其成熟度和更稳健的定价。
• 关于在 BotFather 中启用“serverless”开关也出现了一些困惑；另一些人澄清它目前仅处于封闭测试。
• 术语说明：一些人不喜欢“serverless”意味着“运行在别人的服务器上”，但也承认这是业内标准术语。