他让机器人每天读70篇论文，8个用户逼他重写整个产品

30个Zotero标签页从未打开，邮箱里塞满未读的新闻通讯，那种"有人已经发表了我正准备花三周发现的东西"的焦虑——这是作者每天醒来面对的现实。arXiv（预印本平台）的RSS订阅每天推送100多篇论文，噪音太大；邮件通讯被大脑自动归类为营销邮件；Twitter算法推荐又不够贴合他的细分领域。

他真正想回答的问题是：过去24小时，我的精确子领域里发生了什么变化，值不值得花时间？

答案是一个叫Broletter的Telegram（即时通讯应用）机器人。每天早上推送一条短消息，分4个板块。点击展开，跳过其余。用表情反馈，明天推送就会调整。整个交互设计只为消除一件事：那面让他"稍后阅读"却永不返回的文字墙。

第一版：被意大利朋友当众处刑

最初的版本是5个板块，每篇约300字，作为独立消息发送，带反应按钮。看起来就是一份正经的新闻通讯。作者把它丢进一个Telegram好友群测试。

第二天，一位朋友回复：

「"no bro troppo lungo non me lo leggerò mai. Cioè tipo meglio che mi fai un sunto ultra veloce e io dico subito cosa mi interessa e cosa no e tu mi mandi il messaggio completo"」

翻译过来："太长了，我永远不会读的。不如你给我超快摘要，我立刻告诉你哪些感兴趣，你再发完整版。"

作者查了Firestore（数据库），8个用户的数据：7票赞成，1票反对。但那个意大利人的反馈足够尖锐，让他意识到问题核心不是内容质量，而是决策成本。用户还没读到内容，就已经被"要不要读"的选择耗尽了。

第二版：把"稍后阅读"改成"现在决定"

新版本的核心交互变成：一行预览 + 点击展开按钮。用户先看到标题和一句话钩子，感兴趣才点，全文才送达。不点的部分永远折叠。

这个设计偷师的是现代新闻应用的"卡片式"体验，但作者加了一层：用Telegram的回调按钮（Callback Button）实现真正的延迟加载。不是把全文藏在折叠里，而是物理上还没发送到聊天窗口。用户点击的瞬间，机器人才去取完整内容。

反馈系统也变了。每篇摘要下面有❤️三个反应。表示"多推这类"，是"少推"，❤️则是"这个方向再深入"。算法不复杂，主要是标签权重调整，但足够让第二天的推送更个人化。

作者提到一个细节：他原本想做个复杂的推荐系统，用嵌入向量（Embedding Vector）做语义匹配。但8个用户的规模让这种工程显得可笑。手动调权重反而更快，也更透明——他能直接告诉用户"为什么给你推了这个"。

技术栈：能偷就偷，能省就省

Broletter的后端是Python，部署在Railway（云平台）。arXiv的抓取用官方API，每天凌晨批量拉取前一天的计算机科学和物理学论文。摘要生成最初用OpenAI的GPT-4，后来换成Claude 3.5 Sonnet，因为作者在长文本理解上更喜欢它的稳定性。

一个关键取舍：他没有自己做PDF解析。arXiv的摘要通常足够判断相关性，全文只在用户点击后才去获取。这省了大量存储和计算，也让整个系统能在免费额度内运行。

数据库选Firestore是因为作者熟悉，但承认"对于这个项目有点重"。用户数据只有反应记录和偏好标签，几百KB就能存下。他考虑过SQLite（轻量级数据库），但Firestore的实时同步让调试更方便——他能在控制台直接看到用户的点击流。

Telegram Bot API（应用程序接口）的选择是刻意的。作者试过Discord，但STEM研究者用Telegram的比例明显更高。WhatsApp的API太贵且审核严格。Slack则太重，不适合个人使用场景。

从论文到一切：配置化设计

Broletter的代码结构被设计成"输送机制，而非内容孤岛"。核心循环是：源 → 抓取 → 摘要 → 个性化 → 推送。源可以替换。

作者自己主要用arXiv，但文档里列了其他配置案例：实习信息聚合（抓取Indeed和LinkedIn）、初创公司融资动态（监控Crunchbase和TechCrunch）、实验室内部更新（连接Slack webhook）。有个用户甚至用它追踪特定GitHub仓库的Release（发布版本）。

这种设计哲学来自作者的产品经理背景。他描述为"不要为用户定义内容，要为他们定义选择内容的语法"。每个源只需要实现两个接口：fetch()返回原始条目，summarize()返回结构化摘要。其余路由、个性化、推送都是通用的。

一个被放弃的功能：社交分享。作者曾想让用户把有趣的论文一键转发到群组，但测试发现这会破坏个人化的精准感。推送内容变成"可能适合所有人"的平均值，反而降低了打开率。

70篇的筛选漏斗

每天实际处理的流程是：arXiv CS和Physics类别约200篇新论文 → 作者自定义的关键词过滤器（基于标题和摘要的布尔匹配）砍掉60% → 剩余80篇进入Claude生成摘要 → 按用户偏好标签排序 → 每人每天最多4篇。

关键词过滤是粗糙但有效的。作者维护了一个个人词典，包含他的研究兴趣（"formal verification""distributed systems"）和明确排除项（"quantum computing"在他领域外）。这个列表每月调整一次，比训练分类器省事。

Claude的摘要提示词（Prompt）迭代了十几个版本。现在的结构是：用一句话向非专业朋友解释这篇论文在解决什么问题；为什么重要；如果只能记住一个结论，是什么。禁止出现"本文""作者"等学术套话，禁止列举"贡献1、2、3"。

作者测试过让Claude直接判断"这篇对用户是否相关"，但幻觉率太高。机器在不确定时倾向于说"可能相关"，导致噪音回升。最终方案是生成摘要让人判断，把决策权留在用户端。

使用数据：小样本的诚实

作者公开了8人测试组的数据（运行6周）：平均打开率61%，完整阅读率（展开后滚动到底部）34%，反馈率（至少点一个表情）28%。作为对比，行业邮件通讯的平均打开率约21%，点击率2-5%。

但他强调这个数字不可比。8个用户里有5个是他直接认识的，社交压力扭曲了行为。真正有趣的是细分：当推送包含用户明确标记过的关键词时，打开率跳到89%；包含新领域（算法探索）时，骤降到23%。

一个意外发现：周末推送的表现比工作日好15%。作者的假设是工作日用户自己也在刷arXiv，机器人变成"确认我已经知道的东西"；周末则是"帮我保持连接"，需求更真实。

目前最大的流失原因是Telegram本身。两个用户因为"不想多装一个应用"而停用。作者考虑过WhatsApp Business API，但每月20美元的基础费对这个零收入项目不友好。

开源与边界

项目代码在GitHub公开，但作者留了明显的缺口：配置文件里API密钥的位置是空的，Claude的提示词只给了一个简化版。他的解释是"我不想维护一个被滥用的公共摘要服务"，但也承认"完整的提示词确实调了很久，有点舍不得"。

文档里有一个"自己部署"的章节，但警告"需要一定的技术耐心"。依赖项包括Python 3.11、Firebase项目、Telegram Bot Father（机器人创建工具）的令牌、以及至少一个AI提供商的API密钥。作者估计熟练开发者需要45分钟，新手可能需要半天。

没有计划做SaaS（软件即服务）版本。作者的原话是："这个工具的价值恰恰在于它是为我定制的。做成通用产品，要么变成另一个Mendeley（文献管理工具，被用户抱怨臃肿），要么死在获客成本上。"

但他接受Pull Request（代码合并请求）。目前有两个外部贡献：一个是Docker（容器化）配置，让部署更简单；另一个是arXiv的bioRxiv（生物学预印本）适配器，来自一个做计算生物学的用户。

一个被删掉的功能

作者提到曾经做过"论文对话"模式：用户可以对某篇论文追问，机器人用RAG（检索增强生成，一种结合外部知识库的AI技术）回答。实现了一周后移除。

问题是用户行为分裂。少数人会深入问技术细节，但大多数人只想知道"要不要读原文"。对话模式让后者感到负担——他们不得不主动结束对话才能继续下一条推送。最终他保留了简单的"请求全文"按钮，把深度交互留给用户自己去PDF里解决。

这个决策的代价是：当用户真的想讨论论文时，机器人无能为力。作者的妥协是，在每条推送底部加了一个"在Zotero中打开"的链接，把深度场景导出到专业工具。

下一步：更懒，还是更准？

作者列出了三个可能方向，都还没动手：

一是多模态。arXiv上的论文越来越多包含图表，纯文本摘要会漏掉关键信息。他测试过Claude的图像理解，但速度太慢，破坏了"早上扫一眼"的流畅性。

二是协作过滤。如果两个用户标记了相似的论文，他们的推荐是否可以交叉？8人样本太小，但作者好奇这个机制在规模扩大后的效果。

三是反向搜索：用户输入一个研究想法，机器人在历史论文中找最相关的。这技术上可行，但会改变产品定位——从"被动推送"变成"主动工具"，用户心智完全不同。

目前他选择维持现状。Broletter每天仍只服务8个人，读70篇论文，推送4条摘要。那个意大利朋友还在群里，偶尔用母语发反馈，作者用翻译软件猜意思。