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, doseqTrue) return urlunparse(parsed._replace(queryclean_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(keylambda x: x[weight], reverseTrue) 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表达式就得换算。我踩过的坑是服务器UTCcron写的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再入库。数据库连接一定要显式指定charsetutf8mb4否则emoji和生僻字会出问题。5.2 时间格式别用字符串比较时间早期我图省事把发布时间存成字符串结果排序时2026-9-21排在2026-10-01后面因为字符串比较是逐字符的。正确做法是存成标准的时间戳或ISO 8601格式展示时再格式化。这个坑看似低级但真的很多人踩。5.3 摘要截断别把句子截一半生成摘要时如果直接按字数截断很容易出现……人工智能技术正在快速这种半句话。我的做法是按句子边界截断先分句再累加句子直到接近字数上限最后加省略号。这样读起来至少是完整的。import re def smart_truncate(text, max_len150): 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是必要的这不是系统不完善而是这类项目的固有属性。至于那个只有标题没有正文的日报它其实是个很好的提醒——系统在告诉你某个环节需要你去看一眼了。
