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.04Python 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_keyTrue) title Column(String(500)) content Column(Text) url Column(String(1000), uniqueTrue) source Column(String(100)) publish_time Column(DateTime) summary Column(Text) created_at Column(DateTime, defaultdatetime.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( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.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_emaildigestyourdomain.com, to_emailsrecipient, subjectfHackDigest 每日摘要 - {datetime.now().strftime(%Y-%m-%d)}, html_contenthtml_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, hour2, minute0) scheduler.start()run_digest函数里依次调用采集、清洗、摘要、发送四个步骤。每个步骤都有日志记录方便排查问题。5. 常见问题与排查技巧实录5.1 摘要质量不稳定的排查思路摘要质量不稳定是最常见的问题。表现是有时候摘要很准有时候完全跑偏。排查思路如下第一检查原文质量。如果原文本身是碎片化的推文或短消息摘要质量肯定差。解决办法是过滤掉过短的文章只处理正文超过500字的。第二检查提示词。如果提示词太模糊模型会自由发挥。解决办法是加更多约束比如指定摘要结构、指定关键词保留。第三检查模型版本。不同版本的模型摘要风格不同。解决办法是固定模型版本不要频繁切换。第四检查temperature参数。如果temperature太高输出随机性大。解决办法是降到0.2到0.3之间。我整理了一个速查表问题表现可能原因解决办法摘要太短提示词未指定长度明确要求150-250字摘要太长原文太长截断原文到3000字摘要跑偏提示词太模糊增加内容约束摘要风格不一致temperature太高降到0.3以下摘要包含评价提示词未要求中立明确要求客观中立5.2 邮件进入垃圾箱的排查与解决邮件进入垃圾箱是另一个高频问题。排查步骤如下第一检查发件人域名。如果用的是免费邮箱域名很容易被过滤。解决办法是用自己的域名并配置SPF和DKIM记录。第二检查邮件内容。如果包含大量链接或敏感词会被过滤。解决办法是减少链接数量避免敏感词。第三检查发送频率。如果短时间内发送大量邮件会被判定为垃圾邮件。解决办法是控制发送频率每天不超过一封。第四检查退信率。如果退信率过高发件人信誉会下降。解决办法是定期清理无效地址。第五用工具测试。把邮件发送到不同邮箱Gmail、Outlook、QQ邮箱检查是否进入垃圾箱。如果某个邮箱有问题针对性优化。5.3 采集失败的常见原因与处理采集失败的原因很多我列几个常见的RSS源失效返回404或解析错误。处理方法是记录失败状态连续失败三次后自动禁用该源并发送提醒。网页结构变化解析不到正文。处理方法是增加备用解析规则比如先试classcontent失败再试classarticle。请求被拒绝返回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是按量付费的如果不加控制月底账单可能吓你一跳。设置预算告警定期检查调用量该缓存就缓存该降级就降级。这个项目我断断续续做了两个月中间重构了两次。第一次重构是因为采集层太乱每个源写一个脚本维护成本高。第二次重构是因为摘要层没有缓存重复调用太多。重构后代码清晰很多维护也轻松了。如果你也在做类似的项目我的建议是先想清楚架构再动手写代码。磨刀不误砍柴工前期多花一小时设计后期能省十小时调试。
