从零搭建AI摘要邮件服务：大模型驱动的信息聚合实践

1. 从一封每天早上七点准时到达的邮件说起我做了一个叫 HackDigest 的小工具核心逻辑一句话就能说清楚每天早上定时抓取一批技术社区和新闻源的内容用大模型做摘要和去重把结果整理成一封结构清晰的邮件发到订阅者的邮箱里。没有 App没有网页端没有推送通知收件箱就是产品界面。这个想法不是凭空冒出来的。我自己有很长一段时间被信息焦虑折磨——RSS 订阅了几百个源Twitter 列表塞满了技术博主再加上各种周刊和邮件列表每天光是扫一眼标题就要花掉四十分钟以上而且大部分内容看完就忘真正有价值的那几条反而淹没在噪音里。后来我试过用自动化工具把内容聚合到一个文档里但聚合不等于消化几百条链接堆在一起打开的动力都没有。转折点是我开始认真用大模型做文本摘要。最初只是手动把几篇文章丢进去让它提炼要点后来发现这个流程完全可以自动化抓取、清洗、摘要、去重、排版、发送每一步都有成熟的工具可以用。HackDigest 就是这么一步步搭起来的从最初一个跑在本地终端里的脚本变成了现在每天稳定服务一批订阅者的邮件摘要服务。这篇文章我会把整个项目的设计思路、技术选型、踩过的坑、以及如果你也想做一个类似的东西需要注意的细节全部拆开讲。适合有基本编程能力、对大模型 API 调用有初步了解、想做一个自己的信息聚合工具的读者。如果你只是想找一个现成的摘要服务这篇文章可能不太适合你但如果你想理解AI 摘要邮件这件事背后的工程逻辑那接下来的内容应该能给你不少参考。2. 为什么是邮件而不是 App 或网页2.1 邮件作为交付渠道的天然优势很多人听到每天发摘要邮件的第一反应是为什么不做个 App或者至少做个网页我认真考虑过这两个方向最后都放弃了原因很实际。邮件的第一个优势是零安装成本。用户不需要下载任何东西不需要注册账号不需要学习新的界面。输入邮箱点订阅第二天早上就能收到第一封。这个转化路径短到几乎不存在摩擦。相比之下做一个 App 意味着要处理应用商店审核、版本兼容、推送权限申请、用户留存等一系列问题而这些工作对于一个个人项目来说投入产出比非常低。第二个优势是邮件天然适合摘要这种内容形态。摘要的本质是用更少的时间获取更多的信息它要求的是快速浏览、快速判断、快速跳转。邮件的线性阅读体验恰好匹配这个需求——从上到下扫一遍感兴趣的标题点进去看原文不感兴趣的直接划过。网页端当然也能做到这一点但网页需要用户主动打开而邮件是主动送到用户面前的。第三个优势是邮件的技术栈极其成熟。SMTP 协议几十年没变过发送邮件的库在各个语言里都有稳定的实现HTML 邮件的排版虽然有一些兼容性坑但整体来说是一个被解决了的问题。我不需要处理推送服务的证书管理不需要担心 App 被下架不需要维护服务器的高可用——至少在这个项目的规模下不需要。提示邮件作为交付渠道有一个容易被忽略的好处——它自带归档和搜索功能。用户可以在自己的邮箱里搜索几个月前的摘要这比在 App 里翻历史记录方便得多。2.2 邮件摘要的读者到底需要什么在设计 HackDigest 的内容结构之前我先问了自己一个问题一个技术从业者早上打开这封邮件他最想看到什么我的答案是三样东西今天发生了什么值得知道的事、每件事的一句话概括、如果我想深入了解去哪里看原文。这三样东西对应到邮件结构里就是分组标题、摘要正文和原文链接。我见过一些摘要类产品试图在邮件里塞进太多东西——完整的文章正文、评论区精选、相关推荐、广告位。结果就是邮件变得又长又重读者打开之后第一眼看到的是密密麻麻的文字直接关掉。摘要邮件的核心竞争力是轻一旦变重就失去了存在的意义。所以 HackDigest 的每封邮件控制在 15 到 20 条内容按主题分成三到四个板块每条内容包含标题、两到三句摘要、原文链接。整封邮件在手机上一屏能看完大半在电脑上不需要滚动太多。这个长度是我反复调整后确定的——太短显得单薄太长读者看不完。2.3 和自己搭 RSS的区别在哪里有人可能会说RSS 阅读器不就能做这件事吗我订阅一堆源每天扫一遍效果差不多。区别在于摘要和去重。RSS 阅读器给你的是原始标题和摘要你需要自己判断哪条值得看。而 HackDigest 做的是把同一件事在不同来源的报道合并成一条用大模型生成一段中性的概括然后按重要性排序。这个合并同类项的过程是 RSS 阅读器做不到的也是大模型在这个项目里最核心的价值。举个例子某天有三个技术博客都在讨论同一个新发布的工具RSS 阅读器会给你三条独立的条目你得自己发现它们说的是同一件事。HackDigest 会把这三条合并成一条摘要里综合三个来源的信息原文链接列出三个。这样你花一份时间得到的是三份信息的交集。3. 整条流水线的四个关键环节3.1 内容抓取源的选择比抓取技术更重要HackDigest 的内容来源分成三类技术社区的热门帖子、行业新闻站点的最新文章、以及一些高质量个人博客的更新。抓取本身没有太多技术含量无非是 RSS 解析和 HTML 抓取两种方式。RSS 优先因为结构清晰、解析稳定没有 RSS 的站点就用 HTML 抓取需要针对每个站点写解析规则。这部分代码不复杂但维护成本不低——网站改版是家常便饭解析规则说失效就失效。真正花时间的是源的选择和权重的调整。我最初贪多加了三十多个源结果每天抓回来几百条内容摘要之后还是有五六十条邮件变得又长又杂。后来我做了两件事一是砍掉低质量的源只保留那些每篇都值得看一眼的二是给每个源设置权重权重高的源的内容在排序时优先展示。注意源的权重不是一成不变的。我会定期看邮件的打开率和点击率如果某个源的内容长期没人点就降低它的权重或者直接移除。这个反馈循环是保持摘要质量的关键。抓取频率方面我设置的是每天早上六点跑一次抓取过去二十四小时内发布的内容。这个时间窗口是权衡的结果——太短可能漏掉一些内容太长则会有太多旧闻混进来。对于更新频率特别高的源我会单独设置更短的抓取间隔避免遗漏。3.2 大模型摘要提示词设计决定输出质量这是整个项目里最核心也最微妙的部分。同样一篇文章提示词写得好和写得差摘要质量天差地别。我最初用的提示词非常朴素请总结以下文章的主要内容。结果大模型给出的摘要要么太长把原文复述了一遍要么太短只说了个大概要么带着明显的AI 味——那种四平八稳、没有信息量的概括。经过反复调整我现在用的提示词结构是这样的先给大模型设定角色你是一个技术新闻编辑然后明确输出要求用两到三句话概括不超过一百字保留关键的技术名词和数字再给出格式约束不要用本文介绍了这样的开头直接说重点最后才是待摘要的正文。这个提示词里有两个细节值得展开说。第一个是字数限制。不给限制的话大模型倾向于写长摘要因为它觉得写得越多越完整。但摘要邮件的场景下短就是好。我试过 50 字、80 字、100 字、150 字几个档位最后发现 80 到 100 字是甜点区——足够说清楚一件事又不会让邮件变得臃肿。第二个是禁止特定的开头句式。本文介绍了这篇文章讨论了作者认为这类开头是摘要的毒药它们占用了宝贵的字数却没有传递任何信息。在提示词里明确禁止这些句式之后摘要的信息密度明显提升。还有一个容易被忽略的点是批量处理的成本控制。每天抓回来的内容可能有几百条如果每条都调用一次大模型 API成本会很高。我的做法是先用简单的规则做一轮筛选——比如标题里包含特定关键词的、来源权重高的、发布时间新的——把候选集缩小到五十条左右再调用大模型做摘要。这样既控制了成本也保证了摘要的质量集中在真正重要的内容上。3.3 去重与合并让同一件事只出现一次去重是摘要邮件里最容易被低估的环节。如果不做去重你会看到同一件事被不同来源报道了五次摘要内容大同小异读者会觉得这个产品很蠢。我的去重策略分两层。第一层是基于 URL 的精确去重这个简单维护一个已抓取 URL 的集合就行。第二层是基于内容相似度的模糊去重这个复杂一些需要判断两篇标题不同但内容相似的文章是不是在说同一件事。模糊去重的实现方式我试过两种。一种是传统的文本相似度算法比如计算标题的编辑距离或者词向量余弦相似度。这种方法速度快、成本低但对于换了说法的同一件事识别率不高。另一种是把候选文章的标题和摘要一起丢给大模型让它判断这几篇文章是否在讨论同一件事。这种方法准确率高但成本也高。最后的方案是混合的先用文本相似度做粗筛把可能重复的文章分到一组再用大模型对每组做精细判断和合并。这样既控制了成本又保证了去重的准确率。合并之后的摘要不是简单地把几篇的摘要拼在一起而是让大模型基于所有来源的信息重新生成一段综合摘要。这样出来的摘要比单一来源的更全面也更中立。3.4 邮件排版与发送HTML 邮件的兼容性坑邮件排版看起来简单实际上坑不少。不同的邮件客户端对 HTML 和 CSS 的支持程度差异很大尤其是国内的一些邮箱客户端对现代 CSS 特性的支持相当有限。我的原则是能用表格布局就用表格布局能用内联样式就用内联样式。Flexbox 和 Grid 在邮件客户端里的支持情况参差不齐表格布局虽然老派但兼容性最好。字体方面我用的是系统默认字体栈不引入外部字体避免加载失败导致排版错乱。邮件的结构我固定为顶部是日期和一句话导读中间是分板块的内容列表底部是退订链接和反馈入口。每个板块有一个小标题每条内容包含标题加粗、摘要正常字重、原文链接带下划线。整体配色克制白底黑字为主链接用蓝色不加背景色和装饰元素。发送环节用的是标准的 SMTP 服务配合一个邮件发送库处理重试和错误日志。这里有一个经验一定要处理发送失败的情况。邮件发送不是百分之百可靠的可能因为网络问题、对方服务器拒收、或者触发了反垃圾规则而失败。我的做法是记录每次发送的状态失败的邮件在下一个发送周期重试连续失败三次以上的地址标记为无效并暂停发送。4. 那些让我熬夜排查的坑4.1 摘要质量忽好忽坏大模型的幻觉问题项目上线第一周我收到一封订阅者的回复邮件说某天的摘要里有一个事实错误——把某个工具的发布时间写错了。我检查了原文原文里根本没有提到发布时间是大模型自己编出来的。这就是所谓的幻觉问题。大模型在摘要时如果原文信息不完整它倾向于用自己训练数据里的知识去补全而不是老老实实说原文没有提到。对于新闻摘要这种要求事实准确的场景这是致命的。我的应对措施有三个。第一是在提示词里明确要求只使用原文中出现的信息不要添加原文没有的内容。第二是在摘要生成之后加一步校验——把摘要和原文一起丢给大模型让它检查摘要里是否有原文不支持的说法。第三是对于关键信息比如日期、数字、人名在摘要里保留原文的表述方式不做改写。即使做了这些幻觉也不能完全消除。所以我在每封邮件的底部加了一行小字摘要由 AI 生成可能存在误差请以原文为准。这既是免责也是对读者的提醒。4.2 邮件进了垃圾箱发送信誉的维护项目跑了一个月之后有订阅者反馈说收不到邮件了。我查了发送日志邮件确实发出去了但对方没收到。大概率是进了垃圾箱。邮件进垃圾箱的原因很多常见的有发送频率突然变化、邮件内容包含垃圾邮件特征词、发送 IP 的信誉度低、收件人没有把发件人加入白名单。我逐一排查之后发现问题出在邮件内容上——摘要里有一些技术术语被垃圾邮件过滤器误判了。解决方法是调整邮件内容避免使用容易被误判的词汇和格式。同时我在订阅确认邮件里加了一段说明建议用户把发件人加入白名单。这个小小的改动让邮件的到达率明显提升。提示如果你也要做邮件发送类的项目建议在项目早期就关注发送信誉的问题。用一个专门的域名和邮箱发送不要用个人邮箱控制发送频率不要短时间内大量发送在邮件里提供清晰的退订入口。这些措施都能降低进垃圾箱的概率。4.3 抓取源失效一个安静的定时炸弹抓取源失效是那种不报错但也不工作的问题。RSS 地址返回 404 了或者网页结构变了导致解析不到内容程序不会崩溃只是默默地抓回来零条内容。如果不做监控可能好几天都不会发现。我的做法是给每个源加一个健康检查每次抓取之后记录每个源抓回来的条目数。如果某个源连续两次抓回来零条就发一封告警邮件给我自己。这个机制帮我及时发现了好几个失效的源。另一个相关的问题是抓取频率和对方服务器的承受能力。有些小站点的服务器比较弱抓取太频繁可能导致对方服务不稳定。我在抓取时加了延迟并且遵守 robots.txt 的规则。这既是技术上的礼貌也是避免被封 IP 的必要措施。4.4 成本失控大模型 API 的账单惊吓项目刚上线的时候我没有做成本控制每天把所有抓回来的内容都丢给大模型做摘要。第一个月的账单出来比我预期的高了不少。分析之后发现成本主要花在两个地方一是摘要生成二是去重时的相似度判断。前者是必需的后者其实可以优化。我把去重的第一层改成了本地的文本相似度计算只有疑似重复的才调用大模型做精细判断这一项的成本就降下来了。摘要生成这边我做了两件事一是前面提到的预筛选减少调用次数二是根据内容长度动态选择模型——短内容用便宜的小模型长内容才用大模型。这样调整之后成本控制在了可接受的范围内。5. 如果你也想做一个这些经验可以直接抄5.1 技术栈选择怎么方便怎么来HackDigest 的技术栈非常朴素Python 做抓取和数据处理一个大模型 API 做摘要一个邮件发送库做投递一个轻量级的数据库存抓取记录和订阅者信息一个定时任务调度器负责每天触发。我没有用任何复杂的框架没有微服务没有消息队列没有容器编排。原因很简单这个项目的规模不需要这些。每天处理几百条内容、发送几百封邮件一台最基础的云服务器就绰绰有余。过早引入复杂的架构只会增加维护成本不会带来任何实际收益。如果你要自己做一个类似的东西我的建议是从最简单的方案开始。先用一个脚本把整条流水线跑通确认效果之后再考虑优化。很多人在项目初期就纠结于用什么框架怎么设计架构结果还没跑通就放弃了。5.2 提示词模板可以直接拿去用的版本下面是我现在用的摘要提示词模板你可以根据自己的需求调整你是一个技术新闻编辑负责为每日摘要邮件撰写内容概括。 要求 1. 用两到三句话概括以下内容的核心信息总字数控制在 80 到 100 字。 2. 只使用原文中出现的信息不要添加原文没有的内容。 3. 保留关键的技术名词、产品名称和数字。 4. 不要用本文介绍了这篇文章讨论了作者认为等开头句式直接说重点。 5. 语气中立客观不要加入个人评价。 原文内容 {content} 请输出摘要这个模板的关键在于约束足够具体。模糊的指令得到模糊的输出具体的指令得到具体的输出。字数、句式、信息范围都给出明确要求之后大模型的输出质量会稳定很多。5.3 订阅者增长慢就是快HackDigest 没有做过任何推广订阅者全部来自口碑传播。有人收到邮件觉得不错转发给同事同事再订阅。这个增长很慢但质量很高——通过口碑来的订阅者打开率和留存率都明显高于其他渠道。我见过一些类似的项目上线第一天就到处发帖推广短时间内涌入大量订阅者但因为内容质量还没打磨好这些人很快就退订了。摘要类产品的核心是内容质量不是用户数量。在内容质量稳定之前推广得越猛流失得越快。如果你要做类似的项目我的建议是先把内容质量打磨到自己满意再考虑让更多人知道。前一百个订阅者应该来自你信任的人他们的反馈比任何数据都值钱。5.4 持续运营比写代码更难的部分写代码是一次性的工作运营是每天都要做的事。HackDigest 上线之后我每天早上都会花十分钟看一遍当天发出的邮件检查摘要质量、链接有效性、排版有没有问题。这个习惯坚持了几个月帮我发现了很多自动化流程发现不了的问题。运营还包括处理订阅者的反馈。有人会回复邮件说某条摘要写得好有人会说某个源的内容质量下降了有人会建议增加某个板块。这些反馈是产品改进的重要输入我基本上每条都会认真看。注意做摘要类产品最怕的是发出去就不管了。一旦内容质量下滑订阅者会用退订来投票。保持每天检查、每周复盘的习惯是让产品活下去的关键。6. 关于 AI 摘要这件事我的一些真实体会做了几个月的 HackDigest我对AI 摘要这件事有了更具体的认识。大模型在摘要任务上的表现取决于原文的质量和提示词的质量。原文结构清晰、信息密度高摘要就好原文本身就很水摘要也只能是水的浓缩。提示词写得具体摘要就精准提示词写得模糊摘要就泛泛。所以与其抱怨AI 摘要不行不如回头看看原文和提示词有没有问题。另一个体会是摘要不能替代阅读。HackDigest 的定位是帮你决定哪些内容值得花时间读原文而不是帮你省掉读原文的时间。有些订阅者可能只扫一眼摘要就过去了但对于真正重要的内容摘要的作用是引导你去读原文而不是替代原文。这个定位想清楚之后很多产品决策就顺了。最后说一个技术之外的体会做这种每天定时运行的项目稳定性比功能丰富更重要。用户不会因为你多了一个花哨的功能而留下但会因为某天没收到邮件而退订。所以我把大部分精力花在了监控、告警、错误处理上而不是加新功能。这个取舍在个人项目里尤其重要——你的时间有限应该花在让核心流程稳定运行上而不是让它变得更复杂。