HackDigest实战：AI每日摘要邮件系统架构与实现

1. 从标题拆解这个项目的真实需求

1.1 一个标题背后的三个核心问题

"HackDigest – AI-summarized daily news digest via email"这个标题看起来简单，但它其实一次性回答了三个问题：信息源怎么来、内容怎么处理、结果怎么送达。这三个问题恰好对应了一个完整信息管道的三个环节——采集、加工、分发。很多人做类似项目时容易犯一个错误，就是一上来就写代码，结果写到一半发现数据源不稳定、摘要质量忽高忽低、邮件送达率堪忧，最后项目烂尾。我在动手之前习惯先把这三个环节的边界划清楚，再决定用什么技术栈。

先说信息源。HackDigest这个名字里的"Hack"大概率指向技术社区、开发者资讯、开源项目动态这类内容，而不是泛泛的新闻。这类信息源的特点是更新频繁、格式不统一、噪音多。如果直接抓RSS，你会发现很多站点只给摘要不给全文；如果直接爬网页，又要面对反爬和结构变动。所以采集层必须设计成可插拔的，每个源一个适配器，坏了不影响整体。

再说加工。AI摘要不是简单地把文章丢给大模型让它"总结一下"。真正做过的人都知道，长文本摘要会遇到截断问题，短文本摘要会遇到信息密度不足的问题，多语言内容还会遇到翻译和摘要混在一起的问题。更关键的是，摘要的"粒度"需要控制——太短没信息量，太长用户不如直接看原文。我的经验是，把摘要控制在150到250字之间，同时保留原文链接，用户感兴趣可以点进去看全文。

最后说分发。邮件看起来是最简单的分发方式，实际上坑最多。SMTP服务器的信誉、HTML邮件的兼容性、不同邮件客户端的渲染差异、退订机制、垃圾邮件过滤，每一项都能让一个业余项目翻车。我见过太多人用个人邮箱群发，结果第二天账号就被封了。所以分发层要么用成熟的邮件服务API，要么自建SMTP但严格控制发送频率和列表质量。

1.2 为什么选择"每日摘要"而不是实时推送

这个选择背后有很深的用户心理考量。实时推送听起来很酷，但实际使用中会造成严重的注意力碎片化。用户一天收到几十条推送，很快就会关掉通知。而每日摘要把信息集中在一个时间点送达，用户可以在固定时间（比如早上通勤时）一次性浏览完，心理负担小得多。这也是为什么很多成功的资讯产品都采用日报或周报形式，而不是实时流。

从技术角度看，每日摘要还带来一个额外好处：可以批量处理。你可以在凌晨低峰期集中抓取、集中调用AI接口、集中发送邮件，这样既降低了成本，又避免了实时系统的复杂性。我实测下来，批量处理的成本比实时处理低至少40%，因为可以合并请求、复用连接、错峰使用资源。

1.3 适合谁来参考这个项目

这个项目的受众其实比想象中广。第一类是独立开发者，想做一个自己的信息聚合工具，顺便练手AI应用开发。第二类是技术团队，想给内部成员做一个技术资讯简报，提升团队的信息同步效率。第三类是对AI应用感兴趣但不知道从哪入手的人，这个项目涵盖了API调用、数据处理、定时任务、邮件发送等常见环节，是一个很好的练手项目。

不过我要提前说清楚：这个项目不适合想一夜暴富的人。它不是一个能快速变现的产品，而是一个自用工具或者小范围分享的工具。如果你指望靠它赚钱，可能会失望。但如果你把它当作一个学习项目，或者当作一个提升自己信息获取效率的工具，它的价值就很大。

2. 整体架构设计与技术选型思路

2.1 四层架构：采集、清洗、摘要、分发

我把整个系统分成四层，每层职责单一，层与层之间通过标准数据格式（JSON）通信。这样做的好处是，任何一层出问题都可以单独替换或调试，不会牵一发而动全身。

采集层负责从各个信息源获取原始内容。我选择用Python的feedparser处理RSS源，用requests加BeautifulSoup处理需要爬取的网页。为什么不直接用现成的爬虫框架？因为对于这个项目来说，框架太重了，而且很多框架的反爬策略反而会增加被封的风险。轻量级的方案更可控。

清洗层负责把原始内容统一成标准格式。这一步经常被忽略，但非常重要。不同来源的文章，有的带HTML标签，有的带广告，有的带作者信息，有的带发布时间。清洗层要做的就是提取出标题、正文、链接、发布时间这四个核心字段，去掉所有噪音。我一般用正则表达式加BeautifulSoup的组合，先把HTML转成纯文本，再用规则过滤掉短行和广告关键词。

摘要层是核心。我选择调用大模型API而不是本地部署，原因有三：第一，本地部署对硬件要求高，一个能跑得动的模型至少需要16GB显存，成本不低；第二，API的摘要质量通常比同参数量的本地模型好，因为服务商做了大量优化；第三，API按量付费，对于每天几十篇文章的规模，成本完全可以接受。我算过一笔账，每天处理50篇文章，每篇平均2000字，用主流大模型的API，一个月成本大概在20到30元之间。

分发层负责把摘要发送给用户。我选择用邮件服务商的API而不是自建SMTP，因为自建SMTP的送达率太难保证了。主流邮件服务商有专门的IP池和信誉管理，送达率能到95%以上，而自建SMTP经常被扔进垃圾箱。虽然API要花钱，但省下来的调试时间和用户信任度，绝对值这个价。

2.2 为什么用Python而不是Node.js或Go

这个问题我被问过很多次。Python的优势在于生态：feedparser、BeautifulSoup、requests、pandas这些库都是现成的，写起来快。而且大模型API的官方SDK通常Python版本最完善，文档最全。Node.js的异步性能更好，但对于这个项目来说，每天几十篇文章的处理量，Python的性能完全够用。Go的性能最好，但开发效率低，写个爬虫要处理很多底层细节。

我的建议是：如果你已经熟悉某个语言，就用那个语言，不要为了这个项目专门学新语言。如果你什么都不会，Python是最容易上手的。我见过有人用Go写这个项目，代码量是Python的三倍，维护成本高很多。

2.3 数据存储：为什么我用SQLite而不是MySQL

对于个人项目或小团队项目，SQLite完全够用。它不需要单独部署服务，一个文件就是一个数据库，备份和迁移都极其简单。我每天处理几十篇文章，SQLite的读写性能绰绰有余。MySQL适合高并发场景，但这个项目根本没有高并发——每天就一次批量写入，一次批量读取。

我用两张表：一张存原始文章，一张存摘要结果。原始文章表保留30天，摘要结果表永久保留。这样既能追溯问题，又不会让数据库无限膨胀。表结构很简单，字段包括id、title、content、url、source、publish_time、summary、created_at。索引建在publish_time和source上，方便按时间范围和来源查询。

2.4 定时任务：cron还是APScheduler

如果你用Linux服务器，cron是最简单的选择。一行配置就能搞定每天定时执行。但cron的缺点是错误处理麻烦，如果脚本报错，你只能去日志里翻。APScheduler是Python的定时任务库，可以在代码里控制任务调度，错误处理更灵活，还能动态添加或删除任务。

我最后选了APScheduler，因为我想在任务失败时自动重试，并且把失败信息记录到数据库里。cron做不到这些，除非你写额外的包装脚本。APScheduler的配置也很简单，几行代码就能定义一个每天凌晨2点执行的任务。

3. 核心环节的详细实现与参数计算

3.1 信息源采集：RSS优先，网页兜底

采集环节我遵循一个原则：能用RSS就用RSS，不能用RSS才爬网页。RSS的好处是结构稳定、有标准格式、不需要处理反爬。我整理了大概20个技术类RSS源，覆盖了主流的技术社区和博客平台。每个源用一个适配器类来处理，适配器负责把RSS条目转换成统一的文章对象。

对于没有RSS的源，我用网页爬取。这里有个技巧：不要直接爬首页，而是找列表页或归档页。首页通常包含大量动态内容和广告，列表页更干净。爬取时设置合理的请求头，包括User-Agent和Accept-Language，模拟正常浏览器行为。请求间隔至少1秒，避免给目标站点造成压力。

注意：爬取网页前一定要看目标站点的robots.txt和服务条款。有些站点明确禁止爬取，那就不要爬。尊重规则不仅是法律问题，也是技术社区的基本礼仪。

采集频率我设定为每天一次，在凌晨1点执行。这个时间点大部分站点已经更新完当天内容，而且服务器负载低。采集时记录每个源的成功或失败状态，如果某个源连续三天失败，就发邮件提醒我去检查。

3.2 内容清洗：把噪音去掉，把结构留下

清洗环节的核心目标是把原始内容变成"干净"的文本。我定义了一个清洗管道，包含以下步骤：

第一步，HTML转纯文本。用BeautifulSoup的get_text()方法，但要注意保留段落分隔。我通常先把<p>标签替换成换行符，再提取文本。

第二步，去除短行。很多网页会有导航栏、侧边栏、页脚，这些内容转成文本后通常是短行。我设置一个阈值，少于20个字符的行直接删掉。这个阈值需要根据实际内容调整，技术文章通常段落较长，20字符是个比较安全的界限。

第三步，去除广告和推广内容。我维护了一个关键词列表，包含"广告"、"推广"、"赞助"、"点击购买"等词。包含这些词的行直接删除。这个列表需要持续维护，因为广告形式在不断变化。

第四步，截断超长文章。大模型的上下文窗口有限，而且超长文章的摘要质量会下降。我把文章截断到3000字以内，优先保留开头和结尾，因为技术文章的核心观点通常在开头，结论在结尾。

清洗后的文本存入数据库，同时记录原始长度和清洗后长度。如果清洗后长度少于原始长度的30%，说明清洗可能过度了，需要人工检查。

3.3 AI摘要：提示词设计与成本控制

摘要质量的好坏，八成取决于提示词。我试过很多版本的提示词，最后稳定下来的版本是这样的：

你是一个技术资讯编辑。请对以下文章进行摘要，要求： 1. 摘要长度控制在150到250字之间 2. 保留文章的核心观点和关键数据 3. 如果文章涉及技术方案，说明方案名称和主要特点 4. 如果文章涉及产品发布，说明产品名称和主要功能 5. 用客观中立的语气，不要添加个人评价 6. 输出格式为纯文本，不要用Markdown 文章标题：{title} 文章正文：{content}

这个提示词的关键在于"约束"。很多人写提示词只说"总结一下"，结果模型输出的摘要长度随机、格式随机、重点随机。加上明确的长度、内容、格式约束后，摘要质量稳定很多。

成本控制方面，我做了三件事：第一，批量请求。把多篇文章合并成一个请求发给模型，减少请求次数。第二，缓存。如果同一篇文章之前已经摘要过（通过URL判断），直接复用结果。第三，降级。如果API调用失败，先用一个简单的规则摘要（比如取前200字）顶上，保证邮件能正常发送。

我实测下来，用主流大模型的API，每篇文章的摘要成本大约在0.3到0.5元之间。每天50篇文章，一个月成本在450到750元之间。如果预算有限，可以选择更便宜的模型，或者减少文章数量。

3.4 邮件分发：模板设计与送达率优化

邮件模板我用的是简单的HTML加内联CSS。为什么不用外部CSS？因为很多邮件客户端会屏蔽外部样式，内联CSS兼容性最好。模板结构很简单：顶部是标题和日期，中间是文章列表，每篇文章显示标题、摘要、来源和链接，底部是退订链接。

送达率优化我做了以下几件事：

第一，用邮件服务商的API而不是自建SMTP。我试过自建SMTP，送达率只有60%左右，换成API后提升到95%以上。

第二，设置合理的发送频率。每天只发一封，不要频繁发送。如果用户没有打开邮件，不要重复发送。

第三，提供退订链接。这是法律要求，也是用户体验的基本尊重。退订链接要放在邮件底部，点击后立即生效。

第四，监控退信率。如果退信率超过5%，说明邮件列表质量有问题，需要清理无效地址。

第五，避免垃圾邮件关键词。标题和正文里不要出现"免费"、"赚钱"、"紧急"这类词，容易被过滤。

3.5 参数计算：每天处理多少篇文章合适

这个参数需要根据你的用户数量和阅读时间来定。我的经验是，一封邮件里的文章数量控制在5到10篇之间。少于5篇，用户觉得不值一看；多于10篇，用户看不完，反而会忽略。

如果用户是技术从业者，每天阅读技术资讯的时间大概在15到20分钟。按每篇文章摘要阅读时间1到2分钟计算，5到10篇正好。如果用户是学生或初学者，阅读速度慢一些，可以减到3到5篇。

文章的选择策略也很重要。我按来源权重和发布时间排序，优先选择权重高、时间新的文章。权重可以手动设置，比如官方博客权重高，个人博客权重低。同时保证来源多样性，不要全是同一个站点的文章。

4. 实操过程与关键步骤记录

4.1 环境准备与依赖安装

我用的环境是Ubuntu 22.04，Python 3.10。依赖库包括：feedparser、requests、beautifulsoup4、apscheduler、sqlalchemy、openai（或其他大模型SDK）、sendgrid（或其他邮件服务SDK）。安装命令很简单：

pip install feedparser requests beautifulsoup4 apscheduler sqlalchemy openai sendgrid

数据库用SQLite，不需要额外安装。邮件服务需要注册账号并获取API Key，大模型服务也需要注册并获取API Key。这两个Key存在环境变量里，不要硬编码在代码中。

4.2 数据库初始化

我用SQLAlchemy定义模型，然后调用create_all()创建表。代码如下：

from sqlalchemy import create_engine, Column, Integer, String, Text, DateTime from sqlalchemy.orm import declarative_base from datetime import datetime Base = declarative_base() class Article(Base): __tablename__ = 'articles' id = Column(Integer, primary_key=True) title = Column(String(500)) content = Column(Text) url = Column(String(1000), unique=True) source = Column(String(100)) publish_time = Column(DateTime) summary = Column(Text) created_at = Column(DateTime, default=datetime.utcnow) engine = create_engine('sqlite:///hackdigest.db') Base.metadata.create_all(engine)

url字段设了unique约束，这样重复文章会自动被忽略，不需要额外写去重逻辑。

4.3 采集适配器示例

以RSS源为例，适配器代码如下：

import feedparser from datetime import datetime def fetch_rss(source_name, rss_url): feed = feedparser.parse(rss_url) articles = [] for entry in feed.entries: article = { 'title': entry.get('title', ''), 'content': entry.get('summary', ''), 'url': entry.get('link', ''), 'source': source_name, 'publish_time': datetime(*entry.published_parsed[:6]) if hasattr(entry, 'published_parsed') else datetime.utcnow() } articles.append(article) return articles

这个函数返回一个文章列表，后续统一入库。对于网页源，适配器会复杂一些，需要解析HTML并提取正文。我通常用BeautifulSoup的find_all('p')获取所有段落，然后拼接。

4.4 摘要生成与入库

摘要生成的代码如下：

def generate_summary(title, content): prompt = f"""你是一个技术资讯编辑。请对以下文章进行摘要，要求： 1. 摘要长度控制在150到250字之间 2. 保留文章的核心观点和关键数据 3. 用客观中立的语气，不要添加个人评价 4. 输出格式为纯文本 文章标题：{title} 文章正文：{content[:3000]} """ response = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], temperature=0.3 ) return response.choices[0].message.content.strip()

temperature设为0.3，是为了让输出更稳定，减少随机性。如果设为0.7或更高，每次生成的摘要风格会差异很大，不利于保持一致性。

4.5 邮件发送与定时任务

邮件发送用SendGrid的API，代码如下：

from sendgrid import SendGridAPIClient from sendgrid.helpers.mail import Mail def send_digest(articles, recipient): html_content = build_html(articles) message = Mail( from_email='digest@yourdomain.com', to_emails=recipient, subject=f'HackDigest 每日摘要 - {datetime.now().strftime("%Y-%m-%d")}', html_content=html_content ) sg = SendGridAPIClient(os.environ.get('SENDGRID_API_KEY')) sg.send(message)

定时任务用APScheduler配置：

from apscheduler.schedulers.blocking import BlockingScheduler scheduler = BlockingScheduler() scheduler.add_job(run_digest, 'cron', hour=2, minute=0) scheduler.start()

run_digest函数里依次调用采集、清洗、摘要、发送四个步骤。每个步骤都有日志记录，方便排查问题。

5. 常见问题与排查技巧实录

5.1 摘要质量不稳定的排查思路

摘要质量不稳定是最常见的问题。表现是：有时候摘要很准，有时候完全跑偏。排查思路如下：

第一，检查原文质量。如果原文本身是碎片化的推文或短消息，摘要质量肯定差。解决办法是过滤掉过短的文章，只处理正文超过500字的。

第二，检查提示词。如果提示词太模糊，模型会自由发挥。解决办法是加更多约束，比如指定摘要结构、指定关键词保留。

第三，检查模型版本。不同版本的模型摘要风格不同。解决办法是固定模型版本，不要频繁切换。

第四，检查temperature参数。如果temperature太高，输出随机性大。解决办法是降到0.2到0.3之间。

我整理了一个速查表：

5.2 邮件进入垃圾箱的排查与解决

邮件进入垃圾箱是另一个高频问题。排查步骤如下：

第一，检查发件人域名。如果用的是免费邮箱域名，很容易被过滤。解决办法是用自己的域名，并配置SPF和DKIM记录。

第二，检查邮件内容。如果包含大量链接或敏感词，会被过滤。解决办法是减少链接数量，避免敏感词。

第三，检查发送频率。如果短时间内发送大量邮件，会被判定为垃圾邮件。解决办法是控制发送频率，每天不超过一封。

第四，检查退信率。如果退信率过高，发件人信誉会下降。解决办法是定期清理无效地址。

第五，用工具测试。把邮件发送到不同邮箱（Gmail、Outlook、QQ邮箱），检查是否进入垃圾箱。如果某个邮箱有问题，针对性优化。

5.3 采集失败的常见原因与处理

采集失败的原因很多，我列几个常见的：

• RSS源失效：返回404或解析错误。处理方法是记录失败状态，连续失败三次后自动禁用该源，并发送提醒。
• 网页结构变化：解析不到正文。处理方法是增加备用解析规则，比如先试class="content"，失败再试class="article"。
• 请求被拒绝：返回403或429。处理方法是降低请求频率，增加请求头，或者换用RSS源。
• 编码问题：中文乱码。处理方法是检测编码并转换，requests的response.encoding可以手动设置。

提示：采集失败不要慌，先看日志。日志里记录了每个源的请求URL、返回状态码、错误信息。根据日志定位问题，比盲目调试快得多。

5.4 成本超支的控制技巧

AI摘要的成本主要取决于文章数量和模型选择。控制成本的技巧：

第一，去重。同一篇文章可能被多个源收录，通过URL去重可以节省30%左右的调用量。

第二，缓存。已经摘要过的文章不再重复调用API，直接复用结果。

第三，批量。把多篇文章合并成一个请求，减少请求次数。但要注意不要超过模型的上下文窗口。

第四，降级。对于非核心文章，用更便宜的模型或规则摘要。

第五，监控。每天统计调用次数和费用，设置预算告警。如果超过预算，自动暂停非核心任务。

我实测下来，通过去重和缓存，成本能降低40%左右。再加上批量请求，总成本能控制在每天1元以内。

5.5 用户反馈与迭代方向

项目上线后，我收集了一些用户反馈。最常见的反馈是：摘要质量参差不齐，有些文章摘要很好，有些很水。针对这个问题，我增加了人工审核环节——每天随机抽三篇摘要，人工检查质量，如果发现问题就调整提示词。

另一个反馈是：文章选择不够精准，有些文章不感兴趣。针对这个问题，我增加了来源权重和关键词过滤。用户可以配置自己感兴趣的关键词，系统只推送包含这些关键词的文章。

还有一个反馈是：邮件排版在手机上不好看。针对这个问题，我优化了HTML模板，用了响应式设计，确保在手机和电脑上都能正常显示。

6. 后续扩展与个人经验分享

6.1 从邮件扩展到多通道分发

邮件只是分发渠道之一。后续可以扩展到其他通道，比如即时通讯工具、RSS输出、网页版。每个通道写一个适配器，复用同一套摘要数据。这样用户可以选择自己习惯的渠道，提升使用体验。

我个人的经验是，不要一开始就做多通道，先把邮件做好。邮件是最通用的渠道，几乎人人都有邮箱。等邮件稳定运行一个月后，再考虑扩展。

6.2 从每日摘要扩展到个性化推荐

目前的摘要对所有用户是一样的。后续可以根据用户的阅读历史，做个性化推荐。比如用户经常点击AI相关的文章，就多推送AI相关的。这需要记录用户的点击行为，并做一个简单的推荐算法。

推荐算法不需要很复杂，基于关键词的加权排序就够用。用户点击某篇文章后，给该文章的关键词加分，下次排序时优先推送高分关键词的文章。

6.3 我踩过的三个坑

第一个坑：一开始用个人邮箱群发，结果第二天账号被限制。后来换成邮件服务API，问题解决。教训是：不要用个人邮箱做群发，专业的事交给专业的服务。

第二个坑：提示词写得太简单，摘要质量忽好忽坏。后来加了详细约束，质量稳定很多。教训是：提示词是AI应用的核心，值得花时间打磨。

第三个坑：没有做去重，同一篇文章被多个源收录，重复摘要浪费钱。后来加了URL去重，成本降了三分之一。教训是：数据清洗环节不能省，省下的时间最后都要还回去。

6.4 给新手的三个建议

第一，先跑通最小闭环。不要一上来就追求完美，先把采集、摘要、发送三个环节跑通，哪怕摘要质量一般，哪怕只支持一个源。跑通后再逐步优化。

第二，重视日志。每个环节都要打日志，记录成功和失败。出问题时，日志是唯一的线索。我习惯把日志写到文件，同时输出到控制台，方便实时查看。

第三，控制成本。AI API是按量付费的，如果不加控制，月底账单可能吓你一跳。设置预算告警，定期检查调用量，该缓存就缓存，该降级就降级。

这个项目我断断续续做了两个月，中间重构了两次。第一次重构是因为采集层太乱，每个源写一个脚本，维护成本高。第二次重构是因为摘要层没有缓存，重复调用太多。重构后代码清晰很多，维护也轻松了。如果你也在做类似的项目，我的建议是：先想清楚架构，再动手写代码。磨刀不误砍柴工，前期多花一小时设计，后期能省十小时调试。