1. 当日报变成产品一个信息聚合项目的起点做内容的人都有一个共同的痛点每天花大量时间刷各种信息源最后发现真正有价值的内容不到十分之一。我在过去两年里一直在折腾一件事——用自动化手段把每天散落在各处的AI领域动态汇总成一份结构化的日报。这个项目从最初的一个简单脚本逐步演化成了一套完整的流水线中间踩过的坑足够写好几篇复盘。今天这篇就把整套思路和实现细节摊开来讲。所谓AI日报本质上是一个信息聚合与再加工系统。它的核心任务可以拆成三步从多个渠道抓取原始信息、对信息进行筛选和分类、按照固定模板生成可读性强的日报内容。听起来不复杂但真正做起来每一步都有大量细节需要打磨。适合谁来参考如果你正在做内容运营、行业研究、或者单纯想搭建一套个人信息过滤系统这套方法都能直接迁移。我最初的做法非常原始手动打开十几个页面复制粘贴到文档里再逐条写摘要。一天下来光整理就要花两三个小时而且质量完全取决于当天的精神状态。后来我开始思考哪些环节是可以自动化的哪些环节必须保留人工判断。这个问题的答案决定了整个系统的架构方向。2. 信息源分层不是所有渠道都值得同等对待2.1 为什么不能全都要刚开始做聚合的时候我的心态是宁可多抓不能漏掉。结果就是每天抓回来几百条内容筛选的时间比手动整理还长。后来我意识到一个问题信息源的价值密度差异极大。有些渠道每天产出几十条但真正值得关注的可能只有一两条有些渠道更新频率低但每一条都是精品。所以我开始对信息源做分层管理。具体来说分成三个层级核心层更新频率适中、内容质量稳定、与我的关注领域高度匹配。这一层的信息默认全部进入候选池。观察层内容质量不错但噪音较大需要设置关键词过滤规则只有命中特定主题的才进入候选池。扫描层更新极其频繁、内容参差不齐只在特定条件下触发抓取比如某个话题突然升温时才去回溯。这个分层策略带来的直接好处是候选池的内容量从每天几百条降到了三四十条筛选效率提升了一个数量级。2.2 抓取频率与时间窗口的取舍确定了信息源之后下一个问题是多久抓一次我试过三种方案方案抓取频率优点缺点实时抓取每5分钟时效性最强请求量大容易被限流定时批量每天2次请求可控实现简单时效性一般混合模式核心层实时其他定时兼顾时效与成本架构复杂度上升最终我选择了混合模式。核心层的信息源用较高的频率轮询其他层级每天固定时间批量抓取两次。这里有个经验抓取频率不要设成整数分钟比如不要设成每5分钟一次而是设成每5分17秒左右这样可以避免和其他定时任务撞在一起导致资源争抢。另外时间窗口的设置也很关键。我最初用的是抓取最近24小时的内容但实际运行下来发现有些信息源的内容发布时间戳不准确导致要么漏抓要么重复。后来改成了记录上次抓取的最后一条ID每次从该ID之后开始抓这样就避免了时间戳带来的问题。2.3 去重策略别让同一条新闻出现三次去重是聚合系统里最容易被低估的环节。同一条新闻可能被多个渠道转载标题略有不同正文几乎一样。如果不去重日报里就会出现大量重复内容阅读体验极差。我的去重方案分两层第一层是精确去重基于内容的哈希值。把正文去掉空白字符后计算哈希完全相同的直接丢弃。这一层能解决大部分转载问题。第二层是模糊去重基于标题的相似度。我用的是编辑距离加关键词重合度的组合判断。具体来说如果两条内容的标题编辑距离小于某个阈值且核心关键词重合度超过60%就判定为同一条新闻的不同版本保留信息量最全的那一条。注意模糊去重的阈值需要根据实际数据调优。阈值太松会误杀不同新闻太紧则起不到去重效果。我的经验是从较松的阈值开始逐步收紧观察一周的去重结果再定稿。3. 从原始信息到日报条目筛选与摘要的工程化处理3.1 关键词规则引擎的搭建思路信息抓回来之后第一步是筛选。我的做法是建一套关键词规则引擎每条规则由必须包含的词和可以包含的词两部分组成。必须包含的词用来确定主题方向可以包含的词用来做优先级排序。举个例子如果我的关注领域是AI应用落地那么一条规则可能是必须包含模型或算法或推理可以包含部署、优化、成本、延迟命中可以包含中的词越多优先级越高这套规则引擎的好处是透明可控每一条筛选结果都能追溯到具体规则。相比用模型做分类规则引擎在初期数据量不大的时候更实用调整起来也更快。但规则引擎也有明显的短板它无法理解语义。比如这个模型不支持中文和这个模型支持中文都会命中模型和中文但含义完全相反。所以我在规则引擎之后加了一层人工复核每天花十分钟快速过一遍筛选结果把明显不相关的剔除掉。3.2 自动摘要的三种实现路径对比摘要生成是整个系统里技术含量最高的部分。我先后尝试了三种方案方案一抽取式摘要。从原文中直接抽取关键句子拼接成摘要。实现简单不需要模型但读起来比较生硬句子之间的衔接不自然。方案二模板式摘要。针对特定类型的内容预设模板比如某团队发布了某工具主要功能是某某适用于某某场景。这种方式生成的摘要可读性最好但模板覆盖不了所有情况遇到新类型的内容就抓瞎。方案三生成式摘要。用语言模型对原文进行改写和压缩。效果最好但需要控制好输入长度和输出格式否则容易产生幻觉或者遗漏关键信息。我最终采用的是方案二和方案三的混合策略对于常见类型的内容走模板对于模板覆盖不到的内容走生成式摘要。这样既保证了大部分内容的稳定性又保留了处理长尾情况的能力。3.3 分类标签体系的设计原则日报里的内容需要分类否则读者找起来很费劲。我最初设计了一套非常细的分类体系有二十多个标签结果发现维护成本极高而且很多标签一个月都用不到一次。后来我做了简化只保留六个一级分类每个分类下面最多三个二级标签。分类的原则是一个普通读者能在三秒内判断一条内容属于哪个分类。如果判断不了说明分类设计有问题。一级分类二级标签示例判断标准模型动态新模型发布、版本更新涉及具体模型产品的变化技术方法训练技巧、推理优化涉及可复用的技术方案产品应用工具上线、功能更新涉及具体产品的功能变化行业观察市场数据、趋势分析涉及行业层面的信息开源项目新项目、重要更新涉及开源仓库的动态观点讨论技术博客、经验分享涉及个人或团队的观点输出这套分类体系运行了半年多基本没有遇到归类困难的情况。4. 日报排版与分发让内容真正被读进去4.1 日报模板的迭代过程日报的排版看起来是小事实际上直接影响阅读完成率。我最早的模板是一大段文字堆在一起自己回头看都觉得累。后来逐步迭代了四个版本第一版是纯文本列表每条内容一行信息密度高但可读性差。第二版加了分类标题和分隔线结构清晰了一些但每条内容的格式不统一。第三版统一了每条内容的格式标题加粗、摘要一段、来源标注在末尾。第四版在第三版的基础上增加了今日重点板块把当天最重要的三条内容单独拎出来放在最前面。实测下来第四版的阅读完成率比第一版高了将近一倍。读者需要的是引导而不是一堆平等权重的信息。4.2 分发渠道的选择与适配日报生成之后需要分发出去。不同渠道的格式要求不一样需要做适配邮件适合长内容排版用HTML兼容性好。但要注意邮件客户端的CSS支持有限不要用太复杂的样式。即时通讯工具适合短内容每条控制在两三句话以内。超过一定长度会被折叠读者需要手动展开。文档平台适合归档和检索可以保留完整的格式和链接。我的做法是生成一份主文档然后根据不同渠道的规则自动裁剪和转换。这里有个细节即时通讯渠道的分发要控制频率不要一次性把整份日报拆成几十条消息发出去那样会被当成骚扰。我一般是发一条汇总消息附上完整日报的链接。4.3 反馈闭环怎么知道日报做得好不好没有反馈的系统是盲目的。我在日报末尾加了一个简单的反馈入口读者可以标记有用或没用。运行一段时间后我根据反馈数据做了几件事第一把连续两周没用率最高的信息源降级或移除。第二把有用率高的内容类型加大权重在筛选阶段就给更高的优先级。第三调整了摘要的长度因为数据显示摘要在80到120字之间的内容反馈最好。这个反馈闭环不需要很复杂哪怕只是统计一下点击率也比完全没有反馈强。5. 运行半年后我总结出的几条实战经验5.1 关于自动化程度的把握很多人做这类项目容易走极端要么全手动要么追求全自动。我的经验是筛选和排版可以全自动但摘要和重点推荐必须保留人工干预。原因很简单自动摘要偶尔会出错而日报一旦出现事实性错误对信任度的打击是致命的。我每天花在人工复核上的时间大约是十五分钟这十五分钟换来的是整份日报的可靠性。5.2 关于信息源的动态管理信息源不是一成不变的。有些渠道会逐渐降低更新频率有些会改变内容方向有些会直接停止维护。我每个月会做一次信息源的健康检查主要看三个指标更新频率是否正常、内容质量是否稳定、抓取成功率是否达标。任何一个指标连续两周不达标就会触发人工审查决定是调整规则还是直接移除。5.3 关于系统稳定性的几个细节这套系统运行过程中我遇到过几次比较典型的问题。一次是某个信息源的页面结构改版导致抓取规则全部失效日报内容突然少了一大半。后来我加了一个监控机制如果某个信息源连续两次抓取结果为空就发提醒。另一次是摘要生成服务偶尔超时导致日报生成延迟。解决办法是加了重试机制和降级方案超时的时候自动切换到模板式摘要。还有一个容易被忽略的点是时区处理。如果信息源分布在不同时区时间戳的转换一定要统一到同一个时区再做比较否则会出现未来时间或者昨天的时间被当成今天这类问题。5.4 这套系统还能怎么扩展目前这套系统主要处理文本信息后续可以考虑的方向包括对重要内容自动生成语音版本方便通勤时收听对开源项目自动追踪star增长趋势识别突然升温的项目对同一事件的不同来源报道做交叉验证提高信息的可信度。这些扩展不需要推翻现有架构在现有流水线上增加处理节点就能实现。做这类系统最大的体会是不要追求一步到位先跑通最小闭环再逐步优化。我第一版系统只用了不到一百行代码功能也很粗糙但它让我看到了自动化的价值也让我知道了哪些环节是真正的瓶颈。后面的所有迭代都是在这个最小闭环的基础上长出来的。