1. 当一份日报只剩下日期：这个标题到底在说什么
看到"AI 日报 — 2026-09-21"这个标题，第一反应可能是：这不就是个日期吗？正文空白、关键词空白、摘要空白，连热搜词和网络热词都是空的。但恰恰是这种"什么都没有"的状态，反而暴露了一个非常典型的真实场景——自动化日报系统的产物。
我在过去几年里帮不少团队搭过类似的日报/周报自动生成流水线，最常见的情况就是：定时任务跑完了，文件生成了，标题也按模板拼好了，但内容抓取环节挂了，或者数据源当天没有更新，最后落盘的就是一个只有标题、日期正确、正文空白的"空壳日报"。所以这个标题背后真正值得聊的，不是"AI日报"这四个字有多高大上，而是一套日报自动化系统从设计到落地，中间到底有多少个环节会悄悄失败，以及怎么让它在失败时至少不丢人。
这篇内容适合三类人看：一是正在做信息聚合、日报推送、内容自动化的开发者；二是被"每天手动整理行业动态"折磨到想写脚本的运营同学；三是想搞清楚"自动化流水线为什么总是隔三差五出问题"的技术负责人。我会围绕日报系统的数据采集、内容清洗、模板渲染、失败兜底、调度策略这几个核心环节展开，把每一步的坑和取舍讲透。关键词就三个：日报自动化、内容聚合、失败兜底——这三个词基本覆盖了这类项目的全部命脉。
先说结论：一个能长期稳定运行的日报系统，难点从来不在"生成"，而在"生成之前的数据质量"和"生成之后的异常处理"。90%的日报项目死在这两头，中间那部分反而是最简单的。
2. 日报系统的数据从哪来：采集层的三种典型架构
2.1 主动抓取、被动订阅与人工投喂的取舍
日报的内容来源，决定了整个系统的复杂度。我见过的主流方案无非三种，各有各的适用场景。
第一种是主动抓取。写爬虫定时去目标站点拉取列表页和详情页，解析出标题、摘要、发布时间。这种方案的好处是数据源可控、覆盖广，坏处是维护成本高——目标站点改一次页面结构，你的解析规则就得跟着改。我自己的经验是，纯抓取方案如果目标站点超过10个，维护成本会指数级上升，因为每个站点的反爬策略、页面结构、更新频率都不一样。
第二种是被动订阅。通过RSS、公开API、邮件列表、Webhook等方式接收内容。这种方案稳定性远高于抓取，因为数据格式是约定好的，不会因为对方改个CSS类名就崩掉。缺点是覆盖面受限于对方是否提供订阅渠道。实际项目中，我通常会把RSS作为主力，抓取作为补充。
第三种是人工投喂。运营同学把觉得重要的链接丢进一个收集箱（比如一个共享文档、一个表单、一个IM群），系统再去处理这些链接。这种方案看起来"不够自动化"，但在内容质量要求高的场景下反而是最优解——因为机器判断不了"什么值得进日报"，人可以。
| 采集方式 | 稳定性 | 覆盖广度 | 维护成本 | 适合场景 |
|---|---|---|---|---|
| 主动抓取 | 低 | 高 | 高 | 目标明确、数量少的站点 |
| 被动订阅 | 高 | 中 | 低 | 有RSS/API的成熟平台 |
| 人工投喂 | 极高 | 低 | 中 | 质量优先、量小的精选日报 |
我的建议是混合使用：RSS打底保证基本盘，抓取补充关键源，人工投喂做质量兜底。三者按优先级合并去重，这样即使某一路挂了，日报也不至于开天窗。
2.2 采集频率与去重：别让同一篇文章出现三次
采集频率是个容易被忽视的参数。设得太密，浪费资源还容易触发对方限流；设得太疏，日报就失去了"日报"的时效性。我的经验值是：对于日更型日报，采集频率设为每2-4小时一次比较合理，既能保证当天内容及时入库，又不会给对方服务器造成压力。
去重是另一个重灾区。同一篇文章可能通过多个渠道进来（RSS一次、抓取一次、人工又投喂一次），如果不去重，日报里就会出现三条一模一样的标题。去重的核心是生成一个稳定的内容指纹。最简单的做法是用URL去重，但URL可能带各种追踪参数（utm_source之类），需要先归一化。更稳妥的是用"标题+来源"做哈希，或者对正文做SimHash做近似去重。
import hashlib from urllib.parse import urlparse, urlunparse, parse_qs, urlencode def normalize_url(url): parsed = urlparse(url) # 去掉常见的追踪参数 query = parse_qs(parsed.query) for key in ['utm_source', 'utm_medium', 'utm_campaign', 'ref', 'from']: query.pop(key, None) clean_query = urlencode(query, doseq=True) return urlunparse(parsed._replace(query=clean_query)) def content_fingerprint(title, source): raw = f"{title.strip()}|{source.strip()}" return hashlib.md5(raw.encode('utf-8')).hexdigest()这段代码看着简单，但normalize_url这一步能省掉后面大量的重复内容。我踩过的坑是：早期没做URL归一化，结果同一篇公众号文章因为分享链接带了不同的追踪参数，在日报里出现了四次，被读者吐槽"你们是不是没去重"。
2.3 采集失败时的信号：为什么你的日报会变成空壳
回到开头那个"只有标题没有正文"的场景。采集失败通常有几种表现：请求超时、返回403/429、解析规则匹配不到内容、数据源当天确实没更新。这几种情况在系统里应该被区别对待。
请求超时和限流是临时性失败，应该重试；解析规则失效是结构性失败，需要告警并人工介入；数据源没更新是正常状态，不该报错。如果系统不区分这几种情况，就会出现"要么疯狂重试把对方惹毛，要么默默失败导致日报空白"的极端。
我的做法是给每个采集任务定义健康度指标：连续失败次数、最近成功时间、本次抓取条数。当"本次抓取条数为0"且"不是首次运行"时，触发一个低优先级告警，而不是直接让日报空白。这样至少能在日报生成前发现问题。
3. 从原始数据到可读日报：清洗与渲染的关键动作
3.1 内容清洗：把网页正文变成能读的段落
采集回来的原始内容，往往带着大量噪音：导航栏文字、广告、版权声明、相关阅读推荐。直接塞进日报会非常难看。清洗的目标是提取出真正的正文主体。
常见的做法是用正文提取算法（比如基于文本密度的Readability类算法），或者针对特定站点写XPath规则。前者通用但准确率一般，后者精准但维护成本高。我的折中方案是：通用算法打底，关键站点用规则覆盖。对于日报这种场景，其实不需要100%精准，能去掉80%的噪音就已经很可读了。
清洗之后还要做摘要生成。日报不可能把每篇文章全文贴出来，通常每篇给个100-200字的摘要。摘要可以是抽取式的（从原文里挑最重要的句子），也可以是生成式的（用模型重新组织语言）。抽取式的好处是不会编造事实，坏处是可能不够连贯；生成式更流畅，但有幻觉风险。对于日报这种要求准确性的场景，我倾向于抽取式为主，人工润色为辅。
3.2 模板渲染：日期、分组、排序的细节
日报的模板渲染看着简单，其实细节很多。首先是日期处理：标题里的"2026-09-21"应该是内容对应的日期，而不是生成日期。这两个日期在跨天运行时容易搞混——比如凌晨2点生成的日报，内容其实是前一天的，标题该写哪天？我的规则是：以内容的时间范围为准，而不是以生成时刻为准。
其次是分组和排序。日报通常按主题分组（比如"行业动态""产品更新""技术文章"），组内按重要性或时间排序。重要性怎么定？可以用来源权重、阅读量、关键词命中数等综合打分。排序规则一旦定下来就要稳定，否则读者会觉得"今天的日报怎么跟昨天结构不一样"。
def render_daily_report(date, articles): # 按分类分组 groups = {} for art in articles: groups.setdefault(art['category'], []).append(art) lines = [f"# AI 日报 — {date}", ""] for category, items in groups.items(): lines.append(f"## {category}") # 组内按权重降序 items.sort(key=lambda x: x['weight'], reverse=True) for i, art in enumerate(items, 1): lines.append(f"{i}. [{art['title']}]({art['url']})") lines.append(f" {art['summary']}") lines.append("") return "\n".join(lines)这段渲染逻辑里，weight的计算是灵魂。我一般用"来源权重 × 0.5 + 时效性 × 0.3 + 关键词命中 × 0.2"这样的加权公式，具体系数根据实际效果调。
3.3 空内容的兜底：宁可少写，不可乱写
现在回到最核心的问题：当采集到的内容为空时，日报该怎么办？
我见过两种错误做法。一种是"硬凑"——用模板生成一堆"今日暂无重要动态，请关注后续更新"之类的废话，读者一看就知道系统挂了。另一种是"直接不发"——但订阅者会以为你停更了。
正确的做法是分级兜底。第一级：如果当天内容少于阈值（比如3条），在日报顶部加一行说明"今日内容较少，以下为精选"。第二级：如果完全为空，不发日报，但给运营同学发一条内部告警，让他决定是手动补内容还是跳过当天。第三级：如果连续多天为空，触发系统级告警，说明采集链路可能整体挂了。
提示：兜底逻辑一定要在系统设计初期就考虑，而不是等出了事故再补。我见过太多项目，正常流程写得漂漂亮亮，一到异常情况就抓瞎。
4. 让日报按时出现：调度、监控与长期维护
4.1 调度策略：定时任务的时区与重试
日报系统的调度，核心就两个问题：什么时候跑和跑失败了怎么办。
什么时候跑，取决于你的读者什么时候看。如果是给国内读者看的早报，通常早上7-8点推送，那生成任务就得在6点前跑完。考虑到采集可能耗时，我一般把采集任务分散在全天（每2-4小时一次），生成任务固定在推送前1小时执行。
时区是个大坑。如果你的服务器是UTC时间，而读者在东八区，那"早上7点"对应的cron表达式就得换算。我踩过的坑是：服务器UTC，cron写的0 7 * * *，结果读者早上7点收到的是前一天下午的内容。后来统一改成所有时间戳存UTC，展示和调度时再转本地时区，才彻底解决。
重试策略上，我建议指数退避：第一次失败等1分钟重试，第二次等5分钟，第三次等15分钟，最多重试3次。超过3次就放弃并告警，不要无限重试——无限重试在对方限流时只会让情况更糟。
4.2 监控指标：怎么知道日报系统还活着
一个健康的日报系统，应该有几个核心监控指标：
- 采集成功率：每个数据源最近24小时的成功率，低于90%就该看看了
- 内容条数趋势：每天入库的条数，如果突然断崖式下跌，说明采集出问题了
- 生成耗时：从开始生成到完成的时间，如果越来越长，可能是数据量膨胀或代码有性能问题
- 推送成功率：日报生成后是否成功送达，这个最容易被忽视
这些指标不需要多复杂的监控系统，一个简单的定时脚本把数据写进数据库，配个可视化面板就够了。关键是要有告警，而不是等读者来投诉才发现问题。
4.3 长期维护：数据源会死，规则会失效
做日报系统最需要有的心理准备是：你依赖的数据源，随时可能消失或改变。我维护过的系统里，平均每三个月就会有一个数据源出问题——要么停止更新，要么改版导致解析失效，要么直接关站。
所以系统设计上要解耦：每个数据源是一个独立的采集器，有独立的配置和健康检查。某个源挂了，不影响其他源，也不会让整个日报空白。同时要定期review数据源列表，把长期不更新的源清理掉，补充新的源。
另一个维护重点是解析规则的版本管理。每次改解析规则，都要记录改了什么、为什么改、影响哪些源。否则半年后回头看，根本不知道某段正则为什么长那样。
5. 几个真实踩过的坑和对应的解法
5.1 编码问题：中文乱码的三种来源
中文日报最容易遇到的坑就是乱码。乱码通常来自三个地方：响应头声明的编码和实际编码不一致、HTML meta标签声明的编码不准、数据库连接编码没设对。
我的处理顺序是：先看响应头的Content-Type，如果没有或不准，再看HTML里的<meta charset>，如果还不准，就用chardet之类的库做猜测。最后统一转成UTF-8再入库。数据库连接一定要显式指定charset=utf8mb4，否则emoji和生僻字会出问题。
5.2 时间格式：别用字符串比较时间
早期我图省事，把发布时间存成字符串，结果排序时"2026-9-21"排在"2026-10-01"后面（因为字符串比较是逐字符的）。正确做法是存成标准的时间戳或ISO 8601格式，展示时再格式化。这个坑看似低级，但真的很多人踩。
5.3 摘要截断：别把句子截一半
生成摘要时如果直接按字数截断，很容易出现"……人工智能技术正在快速"这种半句话。我的做法是按句子边界截断：先分句，再累加句子直到接近字数上限，最后加省略号。这样读起来至少是完整的。
import re def smart_truncate(text, max_len=150): sentences = re.split(r'(?<=[。！？.!?])', text) result = "" for s in sentences: if len(result) + len(s) > max_len: break result += s return result.strip() or text[:max_len]5.4 推送渠道：别把鸡蛋放一个篮子
日报的推送渠道，我建议至少准备两个。主渠道用邮件或IM机器人，备用渠道用另一个。曾经有一次主渠道的API临时故障，导致当天日报没发出去，读者以为我们停更了。后来加了备用渠道，主渠道失败自动切备用，就再没出过这种事故。
6. 写在最后的一点个人体会
做日报自动化这件事，技术难度其实不高，难的是长期稳定。我见过太多项目，demo阶段跑得飞起，上线一个月后就开始三天两头出问题，最后不了了之。根本原因往往不是技术不行，而是没有把异常处理和维护成本算进去。
如果你正准备做类似的项目，我的建议是：先把"失败时怎么办"想清楚，再动手写正常流程。数据源宁少勿多，先把三五个源跑稳，再逐步扩展。监控和告警从第一天就要有，哪怕只是发个邮件给自己。最后，接受一个现实：没有任何自动化系统能做到100%无人值守，定期的人工review是必要的，这不是系统不完善，而是这类项目的固有属性。
至于那个"只有标题没有正文"的日报，它其实是个很好的提醒——系统在告诉你，某个环节需要你去看一眼了。
