1. 当日报变成一种产品我为什么要做这件事每天早上打开手机信息流像开闸的水一样涌过来。模型发布了新版本、某个开源项目突然冲上热榜、某篇论文在圈子里被反复转发、某个工具悄悄改了定价策略。这些事单看都不大但攒上三天不看就会发现自己跟同事聊天时插不上嘴做技术选型时脑子里还是上个月的旧地图。我做过一个统计如果靠手动刷各种信息源来维持不掉队每天至少要花四十分钟以上而且这四十分钟里真正有效的信息可能不到十分之一。剩下的时间都消耗在重复内容、标题党、以及跟自己方向完全无关的噪音上。这个投入产出比太差了。所以从去年开始我给自己搭了一套自动化的信息聚合流程每天固定时间产出一份结构化的AI 日报。它不是简单的链接堆砌而是经过筛选、分类、去重、摘要之后的一份可读性较强的简报。今天这篇就完整拆解这套系统是怎么搭起来的包括数据源怎么选、去重怎么做、摘要怎么生成、以及我在这个过程中踩过的那些坑。适合所有想建立个人信息管道的人参考不管你是做算法的、做产品的还是纯粹想保持对行业敏感度的从业者。需要先说明一点这套东西的核心不是用多先进的模型而是流程设计得合不合理。我见过太多人一上来就想着接个大模型做全自动摘要结果数据源一团糟去重没做最后产出的日报自己都不想看。工具是次要的管道才是关键。2. 信息源的分层策略不是所有源都值得同等对待2.1 为什么我把信息源分成三层而不是一锅端最开始我犯过一个典型错误把所有能想到的源都塞进一个列表里统一抓取、统一处理。结果就是高质量源和低质量源混在一起噪音把信号淹没了。后来我改成三层结构每一层的处理策略完全不同。第一层是必读源数量控制在十个以内。这一层的标准是信息密度高、更新频率稳定、内容经过一定程度的编辑把关。比如几个头部实验室的官方博客、几个我长期跟踪的独立研究者的个人站点、以及两三个高质量的邮件通讯。这一层的特点是宁可少不可滥每一个源都是我手动验证过至少一个月的。第二层是扫描源数量可以放宽到三四十个。这一层主要是各类聚合平台、社区热榜、以及一些更新频繁但质量参差的渠道。这一层不需要逐条精读只需要抓取标题和摘要做快速筛选。真正有价值的内容会被提升到日报的正文里其余的只作为背景参考。第三层是触发源这一层不产生常规内容只在特定条件下触发。比如某个关键词突然在多个渠道同时出现、某个项目的 star 数在短时间内暴涨、某篇论文被多个独立来源引用。这一层的作用是捕捉异常信号避免我因为只盯着固定源而错过突发的重要变化。三层结构的好处是处理成本可以差异化分配。第一层可以花时间做深度摘要第二层只做轻量筛选第三层用规则引擎自动监控。如果一锅端要么全部浅处理导致质量不够要么全部深处理导致根本跑不完。2.2 每一层的具体抓取方式与频率设定第一层我用的是 RSS 加网页监控的组合。RSS 优先因为结构稳定、解析成本低。但现实是很多优质源不提供 RSS或者提供的 RSS 只输出摘要不输出全文。这种情况我会用网页监控的方式定时抓取列表页检测新增条目。频率设定为每六小时一次因为这一层的源更新不会太频繁抓太勤是浪费。第二层我用的是各平台的公开接口加页面解析。这一层的挑战在于格式不统一每个源都要单独写解析规则。我的做法是抽象出一个通用的条目模型包含标题、链接、时间戳、来源标识、原始摘要五个字段每个源的解析器只负责把原始数据映射到这个模型上。这样后续的去重和筛选逻辑就不用关心数据从哪来。第三层是规则引擎我用一个简单的关键词匹配加频率统计来实现。具体来说维护一个关键词列表每次抓取后统计每个关键词在最近二十四小时内的出现次数如果某个关键词的出现频率超过历史均值的若干倍就触发提醒。这个机制帮我捕捉到过好几次突发的热点比人工刷到要早几个小时。提示第三层的阈值不要设得太敏感否则每天都会触发一堆误报。我的经验是先用两周的数据跑一遍看看正常波动范围再把阈值设在均值加两到三倍标准差的位置。2.3 源质量评估我用什么指标决定一个源的去留一个源要不要留在列表里我主要看三个指标。第一个是有效信息率就是抓取一百条内容里有多少条最终进入了日报或者被我手动收藏。如果连续两周这个比例低于百分之五我就会考虑把它降级或者移除。第二个是时效性同一个事件这个源比我最快的源晚多久。如果总是慢半天以上那它的价值就大打折扣因为我在别处已经看过了。第三个是独特性这个源的内容有多少是别处没有的。有些源更新很勤、质量也不差但内容全是转载和聚合那它对我来说就是冗余的。我宁愿少看几个源也不想在重复内容上浪费时间。这三个指标我每个月复盘一次用一张简单的表格记录。说实话大部分源在三个月内就会被调整一次能长期留在第一层的源非常少。这不是源的问题而是我的需求在变方向在变所以源列表也必须跟着变。3. 去重这件事比想象中麻烦得多3.1 为什么简单的标题匹配根本不够用去重听起来是个简单问题实际上是我整个管道里最花心思的部分。最开始我用的是标题精确匹配结果发现同一个事件在不同平台的标题措辞完全不同精确匹配几乎不起作用。后来改成标题的模糊匹配用编辑距离算相似度好了一些但误判率还是很高。问题在于同一个事件可能有多种表述方式。比如一个模型发布有的源写某团队发布新模型有的写新一代模型正式亮相有的直接写模型名字。标题层面看完全不同但说的是同一件事。反过来有些标题很像但其实是不同事件比如两个不同团队在同一天发布了同名但不同方向的工作。我现在的做法是组合多个信号来判断。标题相似度只是其中一个还要看发布时间是否接近、来源是否属于同一类别、以及内容里提取出的关键实体是否重合。关键实体包括模型名、机构名、人名、技术术语等。如果两个条目的关键实体重合度超过一定比例且发布时间在同一个时间窗口内就判定为重复。3.2 我实际用的去重流程从粗筛到精判具体流程分三步。第一步是时间窗口粗筛只把发布时间在前后十二小时内的条目放在一起比较。这一步能砍掉大部分计算量因为跨天的事件基本不可能是同一件事。第二步是关键实体提取与比对。我用一个轻量的实体识别流程把标题和摘要里的专有名词抽出来形成一个实体集合。两个条目的实体集合做交集如果交集大小超过较小集合的一半就进入下一步。第三步是语义相似度精判。这一步我会用一个句子嵌入模型把标题和摘要编码成向量算余弦相似度。阈值我设在零点八五左右这个值是试出来的。设太高会漏掉一些表述差异大的重复项设太低会把相关但不相同的内容误判为重复。这三步走下来去重的准确率我估计在百分之九十以上。剩下的误判主要出现在两种情况一种是同一事件的不同阶段报道比如先报道发布、后报道评测这种我其实不想去重因为它们是递进关系另一种是综述类内容里提到了多个事件跟单个事件的报道容易混淆。这两种情况我目前还是靠人工在最终审核时处理。3.3 去重做过头会有什么后果这里要特别提醒一句去重不是越狠越好。我有一段时间把阈值调得很低结果发现日报变得非常单薄很多有价值的跟进报道被当成重复项删掉了。去重的目标是去掉冗余不是去掉所有相似内容。判断标准应该是如果两条内容我都看了会不会觉得浪费时间如果第二条提供了新的角度、新的数据、或者新的进展那它就不应该被去掉。我现在的做法是去重只处理同一时间、同一事件、同一角度的重复对于跟进报道和不同角度的分析保留并在日报里标注关系。4. 摘要生成怎么让机器写的东西自己能看下去4.1 直接让模型总结全文为什么效果不好我试过最直接的做法把原文丢给模型让它生成一段摘要。结果很不理想。主要问题是模型容易抓错重点尤其是技术类内容它往往会把背景介绍写得很详细却漏掉真正的核心贡献。还有就是长度不可控有时候一句话就完了有时候写了半页还没进入正题。后来我分析了一下原因。技术内容的重点往往在特定的位置比如论文的贡献部分、项目的更新日志、发布公告的关键段落。如果让模型自由发挥它没有这个位置感。所以我改成先做结构化提取再基于提取结果生成摘要。4.2 结构化提取加模板填充我的实际方案具体来说我针对不同类型的内容定义了不同的提取模板。对于论文类内容我提取的是解决的问题、提出的方法、主要结果、局限性。对于项目更新类内容我提取的是新增功能、修复的问题、破坏性变更、升级建议。对于行业新闻类内容我提取的是事件主体、事件内容、影响范围、后续关注点。提取的方式是先用规则定位关键段落比如论文的摘要部分、项目的 changelog 部分然后把定位到的文本交给模型做信息抽取。抽取出来的字段再按照固定模板组装成摘要。这样做的好处是结构稳定每一条摘要的格式都一致读起来很顺。而且因为字段是分开抽取的模型不容易漏掉关键信息。模板大概是这样的【类型】论文 【核心问题】xxx 【方法概述】xxx 【主要结果】xxx 【值得关注的点】xxx这个模板不是给读者看的最终格式而是我内部使用的中间结构。最终呈现时我会把字段重新组织成一段通顺的文字但底层的信息完整性是由模板保证的。4.3 摘要长度与信息密度的平衡摘要多长合适我试过很多版本。太短了信息不够太长了又失去了摘要的意义。最后的经验是每条摘要控制在三到五句话大约一百到一百五十字。这个长度足够说清楚一件事的核心又不至于让人失去耐心。但长度不是唯一标准信息密度更重要。我见过很多摘要字数不少但一半是废话比如该研究具有重要意义、为后续工作提供了参考这种。我在后处理阶段会专门过滤这类空话用规则匹配加模型判断的方式把没有实际信息的句子删掉。还有一个细节摘要里尽量保留具体数字和专有名词。比如性能提升了百分之三十比性能显著提升有用得多在某数据集上达到某分数比取得了良好效果有用得多。这些具体信息是读者判断价值的关键依据不能为了语言流畅而牺牲掉。5. 日报的最终组装与呈现5.1 分类逻辑怎么让读者三秒钟找到自己关心的部分日报的内容多了之后如果不分类读起来会很累。我的分类逻辑是按内容类型分而不是按来源分。主要分四块模型与产品动态、研究与论文、开源与工具、行业与生态。每块下面再按重要性排序。为什么按类型分而不是按来源分因为读者的关注点是发生了什么而不是谁报道的。同一条新闻来自哪个源对读者来说不重要重要的是它属于哪个类别。按类型分能让读者快速跳过自己不关心的部分。每块内部的排序我用的是一个简单的加权分数考虑的因素包括来源权重、内容完整度、时效性、以及我个人的兴趣标签。这个分数不是固定的我会根据近期的关注方向调整权重。比如这段时间我在看多模态方向那相关内容的权重就会调高。5.2 从原始条目到最终日报的完整流水线整条流水线跑下来大概是这样的定时任务触发各层源开始抓取原始数据进入暂存区解析器把原始数据映射成统一条目模型去重模块运行标记重复项分类模块根据内容特征打标签摘要模块对通过筛选的条目生成结构化摘要排序模块计算权重分数并排序组装模块按模板生成最终日报人工审核处理误判和特殊情况整个流程从触发到产出大概需要十五到二十分钟其中大部分时间花在模型调用上。如果追求速度可以把摘要生成改成异步的先出列表再补摘要。但我个人习惯是等摘要都生成完再看因为列表本身信息量有限。5.3 人工审核这一环为什么不能省我试过完全自动化不看直接发。结果出了几次问题有一次去重误判把两条重要内容合并了有一次摘要把关键数字写错了还有一次分类把一篇论文放到了错误的类别里。这些错误如果被读者看到会严重影响日报的可信度。所以我现在保留了一个轻量的人工审核环节大概花五到十分钟。主要看三件事有没有明显的误判、摘要有没有事实错误、排序有没有明显不合理的地方。这个时间投入是值得的因为自动化能处理百分之九十的工作但剩下百分之十的错误如果不管会毁掉整个产品的体验。注意人工审核不是重新做一遍筛选而是抽查和纠错。如果发现自己每天都在大量修改那说明前面的自动化环节有问题应该去修管道而不是靠人工补。6. 踩过的坑与现在还在解决的问题6.1 抓取频率与源站压力的平衡早期我为了追求时效性把抓取频率设得很高结果有几个源直接把我限流了。后来我学乖了每个源都单独设置频率并且遵守源站的 robots 规则。对于没有明确规则的源我默认用较低的频率宁可慢一点也不要给人家添麻烦。还有一个细节是抓取时间的分散。如果所有源都在同一时刻抓会造成瞬时压力也容易触发风控。我现在把不同源的抓取时间错开均匀分布在一个时间窗口内。6.2 模型调用成本的控制摘要生成是模型调用的大头。如果每条内容都调用一次成本会很高。我的优化策略是分级处理第一层的重要内容用较好的模型做深度摘要第二层的扫描内容用轻量模型做快速摘要第三层只做规则判断不调用模型。这样整体成本能降下来不少。另外就是缓存。同一个事件如果多个源都报道了去重之后只需要生成一次摘要其他重复项直接复用。这个缓存机制帮我省了很多调用。6.3 内容质量波动与兜底策略自动化管道最怕的是上游变化。某个源改了页面结构解析器就失效了某个接口改了返回格式整个流程就断了。我现在的做法是每个环节都有监控和告警一旦某个源连续多次抓取失败或者解析结果异常就会收到提醒。兜底策略也很重要。如果摘要生成失败日报里就显示原始摘要而不是空白如果某个源挂了就用缓存的上次内容顶上同时标注该源暂时不可用。这些细节看起来小但能保证日报的连续性不会因为一个环节出问题就整个停摆。7. 这套系统跑了一年之后我的几点真实体会第一个体会是管道的价值远大于模型。我见过很多人把精力花在换更好的模型上但数据源没选好、去重没做好、分类逻辑混乱再好的模型也救不回来。反过来即使用一个中等水平的模型只要管道设计合理产出的日报质量也完全够用。第二个体会是自动化不是目的省时间才是。我搭这套系统的初衷是减少手动刷信息的时间所以每一个环节的设计都要问一句这能不能帮我省时间。如果某个环节的自动化成本比手动做还高那就不值得做。比如我曾经想做一个自动生成趋势图的功能后来发现手动看数据更快就放弃了。第三个体会是日报的读者首先是自己。这套系统最开始是给我自己用的所以所有的取舍都围绕我的需求。后来有朋友说想用我才做了一些通用化的调整。但核心逻辑没变如果我自己都不想看那这个东西就没有价值。所以每次改版我第一个测试的用户永远是自己。第四个体会是保持简单比追求完美更重要。我见过太多人一开始就想做一个大而全的系统结果复杂度失控维护成本高到自己都不想碰。我的建议是从最小可用版本开始先跑通一个源、一个分类、一个摘要模板然后再逐步扩展。我现在这套系统看起来功能不少但都是一年时间里一点点加上去的每一步都验证过才保留。最后说一个具体的技巧如果你也想搭类似的系统建议先从手动加半自动开始。就是先手动收集几天看看自己真正关心什么、哪些源真正有用然后再把这些需求转化成自动化的规则。直接上来就全自动很容易做出一堆自己不需要的功能。
