「我只是想要一个比telegram-bot-ruby更快、不阻塞、在Ruby里感觉对的东西。」——Telegem作者的开场白，像极了每个程序员深夜写代码的起点。

2025年12月20日：一个不想做框架的人

打开网易新闻 查看精彩图片

那天他提交了第一行代码。目标很小：解决现有Ruby Telegram库的阻塞问题。telegram-bot-ruby是主流选择，但在异步场景下表现不佳。

他没有规划路线图，没有写商业计划书。只是单纯觉得「应该有个更好的方式」。

这个起点决定了Telegem的基因——async-first（异步优先），非阻塞，Ruby原生体验。

2026年4月：追上Telegram的速度

Telegram Bot API更新频繁，多数Ruby封装库落后数月。v3.4.0发布时，Telegem已与Telegram 2026年4月版本完全同步。

新增支持包括：托管机器人（managed bots）、多正确答案的投票（polls with multiple correct answers）等特性。

作者的原话是：「The works」——全部搞定。

Redis存储：从玩具到生产级

此前版本会话数据存内存，单进程运行无碍。但webhook模式多worker部署时，共享存储成为刚需。

v3.4.0引入Redis存储，解决了这个架构瓶颈。这是一个典型的「从个人项目到被真实使用」的转折点——用户倒逼基础设施升级。

135天后的数据

打开网易新闻 查看精彩图片

Telegem吸引了数千名开发者试用。作者坦言：「不是所有人都找到了它，不是所有人都留了下来。」

但这个数字远超他最初的预期。

开源项目的冷启动曲线通常陡峭：前100个用户最难。Telegem用四个月跨过了这道坎，说明Ruby社区对现代异步Bot框架存在真实需求。

下一步：不做功能堆砌

作者明确表态：不会为加功能而加功能。Telegem已进入稳定期，重点转向可维护性和开发者体验。

安装方式保持简洁：

命令行直接gem install telegem，或在Gemfile指定gem 'telegem', '~> 3.4.0'。

为什么这个案例值得看

Telegem的路径揭示了工具类开源项目的典型成长逻辑：先解决个人痛点，再被同类开发者发现，最后由真实使用场景驱动架构演进。

Redis存储不是作者第一天想做的，是多worker部署的用户需求推出来的。这种「被使用 shaping 产品」的模式，比闭门造车更可持续。

对于正在考虑技术选型的Ruby开发者，Telegem提供了一个信号：如果你需要异步、非阻塞、紧跟API更新的Telegram Bot方案，现在有了一个经过生产验证的选项。

gem install telegem，试试看它在你项目里「感觉对不对」。