1. 项目概述一个帮你“消化”arXiv的智能摘要机器人作为一名长期泡在arXiv和各类学术数据库里的研究者我太懂那种被信息洪流淹没的无力感了。每天几十上百篇新论文加上各种领域通讯、会议摘要感觉不是在阅读而是在进行一场永无止境的“信息扫雷”。我的Zotero里塞满了“稍后阅读”的标签邮箱里堆叠着未读的学术简报而最让人焦虑的是你永远不知道是不是在你埋头苦干的三周里隔壁实验室已经发表了和你想法几乎一模一样的成果。这种状态持续了几个月后我意识到问题不在于我不够努力而在于信息获取的“接口”设计得太糟糕了。传统的RSS源噪音太大邮件简报总被潜意识归类为垃圾邮件社交媒体上的算法推荐又不够精准。我需要的是一个能回答一个核心问题的工具在我的细分领域里过去24小时到底发生了什么真正值得我关注的变化于是我动手搭建了Broletter——一个运行在Telegram上的AI摘要机器人。它的核心目标不是推送海量信息而是扮演一个极度挑剔、高度个性化的“学术助理”。每天早上它会给我发送一条结构清晰的消息将当天的精华内容浓缩在几个可交互的卡片里。我只需要点击我感兴趣的部分完整的摘要才会展开。这个简单的交互改变了一切因为它移除了阻碍阅读习惯的最大障碍面对一堵“文字墙”时那种“等会儿再看”然后永远不再打开的拖延心理。目前它每天帮我处理大约70篇arXiv论文让我能从信息焦虑中解脱出来把精力真正集中在思考和创作上。2. 核心设计思路从“推信息”到“拉兴趣”这个项目的核心哲学源于对传统信息推送模式的彻底反思。大多数工具都在做加法给你更多分类、更多标签、更复杂的过滤规则。但用户尤其是研究者的认知带宽是有限的。Broletter的设计思路是做减法其核心可以概括为预览驱动、按需深入、反馈调优。2.1 交互设计卡片式预览与渐进式展开最初的版本V1犯了一个经典错误我把生成长篇摘要直接分段发送以为提供了完整内容就是好的。结果来自朋友的反馈一针见血——“太长了我永远不会读它”。数据也证实了这一点在8个早期用户中7个投票希望“更短”只有3个人曾经使用过反馈按钮。这清楚地表明在用户决定投入时间之前就向他们展示全部内容是一种UX上的根本性失败。因此我彻底重构了交互流程形成了现在的“预览卡片”模式每日单条消息所有内容聚合在一条Telegram消息中避免信息碎片化。四段式预览每条消息包含4个板块例如“深度好奇”、“研究聚焦”、“快讯速览”、“你的研究角”每个板块仅显示一个精心撰写的一行式“钩子”Teaser。点击展开用户对哪个钩子感兴趣就点击对应的按钮该板块的完整摘要约300字才会被加载并显示。反馈闭环每个完整摘要下方有简单的反馈按钮如“相关”、“不相关”。用户的每一次点击和反馈都在无声地训练系统让明天的推荐更精准。这种设计将用户的决策成本降到最低。从“判断一整篇文章是否值得读”变为“判断这一句话是否吸引我”心理负担大大减轻阅读行为自然就发生了。2.2 内容架构通用池与个性化结合为了在控制成本的同时满足个性化需求我采用了混合内容架构。不是为每个用户从头生成所有内容而是将其分为“通用内容池”和“个性化章节”。通用内容池每日生成一次针对所有用户可能感兴趣的公共话题生成。例如每天我会围绕几个固定的主题如“虚拟内存原理”、“宇宙计算假说”生成“深度好奇”文章从当天最热门的5篇论文中生成“研究聚焦”准备3组有趣的科学“快讯速览”。这些内容一旦生成就会被存入缓存池供所有感兴趣的用户取用。个性化章节按用户生成这是核心价值所在。系统会根据用户预先设置的关键词如“few-shot learning”、“perovskite solar cells”以及历史反馈数据从当日的arXiv论文中筛选出最相关的几篇生成专属的“你的研究角”摘要。这部分是完全动态和个性化的。这种架构的好处显而易见100个用户共享同一份“深度好奇”内容我只为此支付一次AI生成费用而不是一百次。成本被均摊到几乎可以忽略不计。2.3 技术选型轻量、无状态与事件驱动作为一个独立开发项目技术栈的选择遵循“完全托管、按需付费、最小运维”的原则。后端运行时Cloud Run。它完美契合了Telegram Bot的Webhook模式和无状态特性。平时流量极低时可以缩容到零只在用户交互时触发容器启动成本极低。同时它也能用于运行定时批处理任务Cloud Run Jobs。数据库Firestore。选择它是因为其天然的“文档-用户”映射非常适合这个场景。每个用户就是一个文档里面存储了配置、关键词、反馈历史、订阅状态等。它的实时监听功能也为未来可能的实时特性留出了空间。更重要的是作为Serverless数据库它没有维护成本按读写次数计费在早期用户量少时成本接近为零。AI模型Google Gemini API。在对比了多个主流模型后Gemini 2.5 Flash系列在性价比、上下文长度和指令遵循能力上取得了最佳平衡。特别是其“思考令牌”的可配置性成为了成本控制的关键下文详述。支付Telegram Stars。这是被严重低估的利器。对于独立开发者而言集成传统支付Stripe、支付宝等需要处理合规、退款、欺诈等一系列头疼问题。Telegram Stars是其平台内货币用户直接用Stars购买服务。我无需处理任何支付细节Telegram负责结算并且提现到TON区块链时平台不抽成再通过交易所换成法币即可。这大大降低了商业化门槛。3. 系统架构详解从定时触发到消息送达整个系统像一个精心编排的流水线在云端自动运行。下图描绘了数据流与核心组件[Cloud Scheduler] | (每日定时触发如UTC 8PM) v [Cloud Run Job: prefetch-papers] | (一次性抓取并解析当日arXiv RSS源) v [Firestore: /papers_cache/{date}] | (存储原始论文元数据及摘要) v [Cloud Run Job: generate-all] | (1. 生成通用内容池 2. 为每个用户生成个性化摘要) v [Telegram Bot API] | (向每个订阅用户发送预览卡片消息) v 用户3.1 阶段一论文抓取与缓存 (prefetch-papers)这个Job每天在固定时间例如学术论文通常更新的凌晨运行一次。数据源订阅特定分类的arXiv RSS源例如cs.CL表示计算语言学。通过feedparser库解析。去重与过滤基于论文ID进行去重。可以加入基础过滤如排除某些不感兴趣的作者或过于简短的摘要。结构化存储将每篇论文的关键信息id,title,authors,abstract,categories,pdf_link,published存储到Firestore的一个集合中例如papers_cache/2023-10-27。这样后续所有处理都基于这份干净的缓存避免重复请求arXiv网站。实操要点设置合理的超时和重试机制因为arXiv偶尔响应较慢。存储时将摘要abstract进行简单的清洗去除LaTeX公式标记$...$为纯文本虽然会损失一些格式但利于后续AI处理。这个Job的运行时间很短成本几乎为零。3.2 阶段二内容生成 (generate-all)这是系统的“大脑”也分两步走步骤A生成通用内容池这是一个独立的函数每天只运行一次与用户数量无关。def generate_daily_pool(date: str, themes: List[str], top_papers: List[Paper]): pool {} # 1. 为每个主题生成“深度好奇”文章 for theme in themes: prompt f以通俗有趣的方式向聪明的外行解释{theme}这个概念。不超过300字。 content call_llm(prompt, modelgemini-2.5-flash-lite) pool[fcuriosity_{theme}] content # 2. 为Top 5论文生成“研究聚焦”摘要 for i, paper in enumerate(top_papers[:5]): prompt f总结这篇论文的核心贡献{paper.title}。摘要{paper.abstract}。用三句话说明它解决了什么问题用了什么方法有什么意义。 content call_llm(prompt, modelgemini-2.5-flash-lite) pool[fresearch_{paper.id}] content # 3. 生成几组“快讯速览” # ... 类似逻辑 save_to_firestore(fcontent_pool/{date}, pool)步骤B为每个用户组装个性化简报遍历所有活跃用户为每个人执行读取用户配置从Firestore获取用户的关键词列表、兴趣主题、过往的反馈点赞/点踩的文章ID。匹配论文从当日的论文缓存中根据关键词和反馈历史进行匹配和排序。一个简单的策略是关键词匹配标题/摘要 正向反馈过的论文的相似论文 热门论文。生成个性化摘要为匹配到的Top 3论文调用更强的AI模型Gemini 2.5 Flash生成详细摘要。提示词Prompt会包含用户的历史偏好例如“用户之前对‘对比学习’相关的论文反馈积极请侧重从对比学习的角度来解读这篇论文。”组装消息从通用池中选取与该用户兴趣主题匹配的“深度好奇”和“快讯速览”加上刚生成的个性化“研究角”组装成该用户专属的四个板块的完整内容。生成预览钩子将四个板块的完整内容再次发送给一个轻量级AI模型Gemini 2.5 Flash-Lite要求它为每个板块生成一个吸引人的一行式标题和一句话钩子。这是提升点击率的关键一步绝不能简单地截取第一句话。结构化存储将最终生成的完整摘要和预览钩子存入该用户文档下的当日记录中等待发送。3.3 阶段三消息推送与交互Telegram Bot通过Webhook接收事件。当generate-allJob完成后它会调用Bot API的sendMessage但这里用了关键的特性Inline Keyboard Markup。 消息正文是四个板块的预览钩子每个钩子下面跟着一个按钮callback data形如expand:curiosity:virtual_memory。 用户点击按钮后Telegram会向我的Webhook发送一个Callback Query我根据查询键从Firestore中取出对应的完整摘要然后用answerCallbackQuery或editMessageText方法将原消息更新展开对应板块的内容。 反馈按钮也是类似的Callback Query点击后记录到用户的历史数据中用于优化未来的推荐。4. AI成本控制的实战经验从每月$120降到$5这是本项目的精髓所在。最初使用默认配置时我预估100个用户的月成本高达120美元这完全不可持续。通过以下三重优化我将成本压缩到了每月5美元左右实现了超过95%的毛利率。4.1 第一刀禁用“思考令牌”——立省90%这是最具性价比的一步但很多人不知道。Gemini 2.5 Flash模型默认启用了“思考”Thinking机制。模型在输出最终答案前会在内部进行“思考”产生“思考令牌”。这些令牌会计入输出token费用但你却看不到它们的内容对于摘要、改写、创意写作这类任务思考过程并不能显著提升输出质量却会让你的账单暴增3到10倍。解决方案在调用API时显式地将思考预算设置为0。from google import genai response client.models.generate_content( modelgemini-2.5-flash, contentsprompt, configgenai.types.GenerateContentConfig( system_instructionsystem_prompt, # 关键禁用思考令牌 thinking_configgenai.types.ThinkingConfig(thinking_budget0), ), )效果验证我通过记录API返回的usage_metadata.candidates_token_count总令牌数和usage_metadata.total_token_count可见令牌数进行了对比。在禁用思考后生成相同质量的摘要总令牌数下降了70%以上而输出文本的长度和品质几乎没有变化。核心教训除非你的任务是复杂的逻辑推理、数学计算或代码生成否则对于大多数文本生成任务第一件事就是关闭思考令牌。这行代码的价值远超你这周做的任何提示词工程。4.2 第二刀混合模型策略——按需分配算力不是所有任务都需要最强的模型。我采用了双模型策略Gemini 2.5 Flash-Lite用于生成“通用内容池”深度好奇、研究聚焦、快讯速览。这些内容对所有用户一样质量要求是“清晰、准确、有趣”Flash-Lite完全胜任而其成本仅为标准Flash的1/6。Gemini 2.5 Flash仅用于生成“个性化研究角”。这部分需要深度理解用户特定领域、结合历史反馈进行个性化解读对模型能力要求更高值得投入更多成本。通过这种分层我将单用户每日成本最高的部分个性化摘要控制在了一次调用内而占大头的、可共享的内容生成成本被均摊到了极致。4.3 第三刀内容池架构——从O(n)到O(1)的飞跃这是系统架构设计直接带来的成本优势。如果不采用内容池100个用户就需要生成100次“深度好奇”、100次“研究聚焦”。假设每个生成需消耗1000个输出token这就是100 * 1000 * 2 200,000 token。 采用内容池后我每天只为8个主题生成8次“深度好奇”为5篇顶级论文生成5次“研究聚焦”。总共13次调用消耗13,000 token。100个用户共享这份成果。成本对比无池化Flash-Lite: 200,000 token * $0.4 / 1M $0.08/天约 $2.4/月。池化Flash-Lite: 13,000 token * $0.4 / 1M $0.0052/天约 $0.16/月。 仅此一项每月节省超过$2。当用户量增长到1000时节省的将是$20。4.4 成本核算表以100用户为例项目模型每日调用次数每次预估Token每日成本月度成本说明通用内容池Flash-Lite161000输出~$0.0064~$0.198主题5论文3快讯所有用户共享个性化摘要Flash1001500输出~$0.15~$4.50每个用户一次含思考令牌禁用预览钩子生成Flash-Lite100200输出~$0.008~$0.24为每个用户的四个板块生成吸引人的标题和摘要周日回顾摘要Flash1002000输出~$0.20~$6.00每周一次总结一周重点可选功能总计~$0.364/天~$10.93/月每用户均摊成本~$0.0036/天~$0.11/月实际上通过更精细的提示词优化和缓存策略实际成本比这个估算还要低。即使按每个用户每月0.5美元收费也有近80%的毛利空间。这证明了在AI应用中架构设计本身就是最有效的成本控制工具。5. 避坑指南与实战心得在开发和迭代Broletter的过程中我踩了不少坑也积累了一些超越代码的实战经验。5.1 产品与交互设计第一个可用的版本通常是错的我的V1版本功能完整但用户不愿用。最残酷的早期用户反馈朋友那句意大利语的“太长了”是产品最好的礼物。不要爱上你的第一版代码要爱上解决用户问题的过程。必须尽快将原型交到真实用户手中观察他们如何使用或不用。降低启动摩擦Telegram Bot的优势是无需下载新App用户已有账号。我进一步将免费试用期设为7天且无需绑定信用卡通过Telegram Stars的试用机制。注册流程控制在3次点击内完成。每增加一个步骤就会流失一批潜在用户。反馈必须极度轻量最初的反馈是5分制评分结果没人用。后来改为“相关”和“不相关”两个按钮点击率立刻上升。用户愿意进行二进制、一秒完成的反馈但不愿做任何评分或评论。5.2 技术实现细节错误处理与重试arXiv API和Gemini API都可能偶尔超时或失败。所有外部调用必须包裹在健壮的重试逻辑中如使用tenacity库。对于非关键任务如生成某条“快讯”失败要有降级方案例如从池中取一条昨天的备用内容。敏感内容过滤AI生成内容不可控。我设置了一个简单的后过滤层调用一个快速的内容安全API或使用一个轻量级本地分类器来过滤掉可能涉及不当或敏感话题的生成内容。这一点至关重要是项目能安全运行的前提。数据隐私用户的研究关键词和阅读历史是敏感数据。我在Firestore中做好数据隔离并在隐私政策中明确说明数据仅用于改善推荐不会分享给第三方。虽然早期项目可能没人看但好习惯要从一开始养成。监控与日志使用Cloud Logging记录所有Job的运行状态、API调用耗时和错误。设置一个简单的警报当每日内容生成Job失败时给我发送一条Telegram消息。没有监控的系统就像在黑夜中航行。5.3 商业化与运营Telegram Stars的妙用除了支付便捷Stars还是一个营销工具。我可以创建“邀请好友各得Stars”的活动利用Telegram的社交关系链进行裂变。提现到TON区块链后汇率波动是个风险对于小规模收入定期兑换成稳定币或法币是明智的。定价策略我设置了阶梯价格50/100/150 Stars每月对应不同频率每日/每周三次/每日周报的服务。通过早期用户访谈我发现重度研究者愿意为每日推送支付2-3美元而学生则更青睐基础版。提供选择总比单一价格好。内容边界有用户问能否加入VC融资新闻或实习信息。我坚持了“STEM学术摘要”的核心定位。试图满足所有人最终会失去所有人。清晰的边界让产品更有辨识度也让我知道该去哪里如arXiv, PubMed, ACL Anthology和不该去哪里获取内容。6. 扩展思路与未来可能Broletter目前是一个最小可行产品MVP但它的架构为许多扩展提供了可能。多源支持当前核心是arXiv。可以很容易地接入其他学术源如PubMed生物医学、SSRN社会科学、甚至特定会议的论文集网站。只需为每个源编写一个类似的“抓取-解析”适配器并统一存储到papers_cache中。个性化升级目前的推荐基于关键词和简单反馈。可以引入更复杂的协同过滤或嵌入向量相似度计算。当用户点击“展开阅读”后可以记录阅读时长更精细地衡量兴趣。社区特性可以允许用户将某篇论文的摘要“分享”到一个公共频道并附加自己的短评。这能形成一个围绕高质量论文的微型学术社区增加用户粘性。摘要风格定制让用户选择摘要风格如“极简要点式”、“详细批判式”、“面向初学者的科普式”。这可以通过在给AI的提示词中加入风格指令来实现。离线与导出提供每周摘要的PDF版本或Notion数据库同步满足用户归档和深度阅读的需求。这个项目的核心验证了一个想法在信息过载的时代工具的价值不在于提供更多信息而在于提供更精准的“注意力接口”。通过AI降低信息筛选的熵通过精巧的交互设计降低认知负荷让用户重新获得对信息流的主控权。从每天被70篇论文标题淹没到从容地点击阅读其中真正相关的3-4篇的深度摘要这中间的效率提升和焦虑缓解才是它真正的价值所在。
