1. 一份“AI雷达日报”到底在扫什么先把话说在前头看到“AI雷达日报-2026年10月12日”这个标题很多人第一反应是“这不就是个资讯聚合吗”。但我做了几年信息聚合类项目之后发现真正有价值的日报产品核心从来不是“把新闻堆在一起”而是雷达这两个字——它得有扫描、过滤、排序、去重、归档这一整套动作最后才落到“日报”这个呈现形态上。我理解的“AI雷达日报”本质是一个面向AI领域的信息监测与摘要系统。它每天定时抓取多个信息源把当天与人工智能相关的动态捞出来经过清洗、分类、打分、摘要最终生成一份结构化的日报。它能解决的问题很具体信息太散、更新太快、噪音太多、看不过来。适合谁来参考三类人——想自己搭一套信息管道的开发者、需要每天跟踪行业动态的产品和运营、以及想练手“抓取处理生成”全链路的技术学习者。这篇东西我不打算写成产品说明书而是按我自己搭类似系统的经验把“雷达”这套东西从设计到落地拆开讲。标题里那个具体日期其实是个很好的切入点日报是按天切片的这意味着整个系统必须围绕“时间窗口”来设计而不是简单的关键词搜索。这一点后面会反复提到因为它决定了你抓什么、怎么存、怎么去重。2. 整体设计与思路拆解2.1 为什么是“雷达”而不是“搜索”搜索是用户带着明确意图去查雷达是系统主动扫、主动推。这两个模式的工程差异非常大。搜索可以容忍延迟用户等两秒没关系雷达不行它得在固定时间点把过去24小时的东西全部过一遍还要保证不漏、不重、不乱序。我当初设计时的第一个决策就是以“时间窗口”为主键而不是以“关键词”为主键。具体做法是给每条抓取到的内容打上一个publish_time和crawl_time日报生成时只取publish_time落在[T-24h, T]区间内的条目。这样做的好处是即使某个源当天没更新日报也不会因为“搜不到关键词”而空掉逻辑上更稳。提示很多新手会直接用“当天日期”去过滤结果遇到跨时区或延迟发布的内容就漏了。用时间戳区间比用日期字符串靠谱得多。2.2 分层架构采集层、处理层、生成层我把整个系统拆成三层这个拆法不是拍脑袋而是为了让每一层都能独立替换和调试。采集层负责从各个源把原始内容拉下来只做最基础的存储不做任何判断。处理层清洗、去重、分类、打分、摘要这是最重的一层。生成层把处理好的结构化数据渲染成日报可以是Markdown、HTML或者纯文本。为什么这么分因为采集层最容易坏——源站改版、限流、编码变化都会让采集挂掉。如果采集和处理耦合在一起一个源出问题可能拖垮整条流水线。分层之后采集层挂了只影响那一个源处理层照常跑历史数据日报顶多缺一块不会整体崩。2.3 选型背后的取舍为什么不用现成的大而全方案市面上有不少现成的聚合工具但我最后选择自己写原因有三个。第一通用工具的过滤规则往往很粗AI领域里“大模型”“推理”“多模态”这些词的权重和普通资讯完全不同通用工具给不了这种细粒度。第二日报的排版和字段是我自己定的通用工具导出格式改起来很别扭。第三自己写才能把“打分逻辑”握在手里这对日报质量影响极大。当然自己写也有代价维护成本高。所以我的建议是如果你只是想要一份能看的日报用现成工具加人工筛选就够了如果你想把“雷达”当成一个长期迭代的项目那自己搭更值。3. 核心细节解析与实操要点3.1 信息源的选择与权重设计雷达扫得准不准七成看源选得好不好。我的经验是源要分三档档位类型权重说明一档官方发布渠道1.0权威性最高但更新频率低二档行业媒体与社区0.7更新快但需要去重和甄别三档个人观点与讨论0.4噪音大但常有独家视角权重不是拍脑袋定的而是根据“历史命中率”动态调整的。我做过一个简单的统计某个源在过去30天里有多少条内容最终被选进了日报。命中率高的源权重往上调长期不命中的降权甚至剔除。这个机制让雷达越跑越准。注意不要一次性接入太多源。我一开始贪多接了二十几个结果去重和分类的压力陡增日报反而变乱。后来砍到八个核心源质量立刻上来了。3.2 去重日报质量的第一道生死线同一条消息官方发一遍媒体转一遍社区再讨论一遍。如果不去重日报里会出现三条几乎一样的内容读者直接关掉。我的去重策略是两级去重第一级是精确去重用URL的规范化形式做哈希。注意URL里的追踪参数比如各种utm_开头的东西必须提前剥掉否则同一个页面会因为参数不同被当成两条。第二级是语义去重这个稍微复杂。我的做法是把标题和正文前200字拼起来做一次向量化然后计算余弦相似度超过阈值我设的是0.85就判定为重复只保留权重最高的那条。阈值这个数不是固定的源越多、越杂阈值可以适当调高。# 语义去重的核心逻辑示意 from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity def dedup_by_similarity(items, threshold0.85): texts [it[title] it[content][:200] for it in items] vec TfidfVectorizer().fit_transform(texts) sim_matrix cosine_similarity(vec) keep [] dropped set() for i in range(len(items)): if i in dropped: continue keep.append(items[i]) for j in range(i 1, len(items)): if sim_matrix[i][j] threshold: dropped.add(j) return keep这段代码只是示意实际用的时候我会把向量缓存起来避免每天重复计算。另外TF-IDF对短文本效果一般如果条件允许换成句向量模型效果会更好但计算成本也上去了得权衡。3.3 分类与打分的实操细节分类的目的是让日报有结构读者能快速跳到关心的板块。我用的分类体系比较粗模型动态、产品发布、研究进展、行业应用、工具与开源。粗有粗的好处——分类太细会导致边界模糊反而增加误判。打分是决定“谁上头条”的关键。我的打分公式大致是score source_weight * 0.4 freshness * 0.3 keyword_hit * 0.2 engagement * 0.1其中freshness是时间衰减因子越新的越高keyword_hit是命中核心关键词的数量engagement是互动量如果有的话。这个公式我调过很多次权重不是绝对的你可以根据自己的偏好改。比如你更看重时效性就把freshness的权重提到0.4。实操心得关键词表要定期维护。AI领域新词出得快上个月还热门的词这个月可能就过时了。我一般每两周review一次关键词表把长期不命中的词删掉把新冒出来的词加进去。4. 实操过程与核心环节实现4.1 采集层的落地定时任务与容错采集层我用的是定时任务每天早上六点跑一次抓过去24小时的内容。为什么选六点因为大部分源在凌晨更新六点抓能覆盖到同时给处理层留出足够时间保证日报在上班前生成好。容错这块踩过不少坑。最典型的是某个源突然返回502如果没做重试那天的日报就缺一块。我的做法是每个源独立重试三次间隔分别是30秒、2分钟、5分钟。三次都失败就记一条告警日志但不阻断其他源。# 采集任务的调度示意crontab 0 6 * * * /usr/bin/python3 /opt/radar/collect.py /var/log/radar/collect.log 21日志一定要留而且要按天切分。出问题的时候日志是唯一能告诉你“到底哪一步挂了”的东西。4.2 处理层的落地清洗与摘要清洗包括去HTML标签、去广告、去无关段落。这一步看着简单但特别容易出问题。比如有些源的内容里嵌了脚本直接正则去标签会误伤正文。我的做法是先用解析库把正文抽出来再做正则清洗顺序不能反。摘要这块早期我用的是抽取式挑最重要的句子后来换成了生成式。抽取式的优点是快、稳、不会胡说生成式的优点是读起来顺但偶尔会编。我的折中方案是标题用抽取式正文摘要用生成式但生成后做一次事实校验把摘要里出现的数字和原文比对对不上就退回抽取式结果。注意摘要长度控制在80到120字之间比较合适。太短信息不够太长读者不如直接看原文。4.3 生成层的落地日报模板设计日报的模板我改过十几版最后定下来的结构是头部日期和概览、按分类分块的条目列表、每条包含标题、来源、一句话摘要和原文链接。为什么加“来源”因为读者需要判断可信度。为什么加“一句话摘要”因为日报的核心价值就是帮读者省时间。## AI雷达日报 - 2026年10月12日 今日共收录 18 条动态覆盖 5 个分类。 ### 模型动态 - **某开源模型发布新版本**来源一档 摘要新版本在推理效率上有明显提升官方给出了基准测试数据。模板渲染我用的就是普通的模板引擎没什么特别的。关键是字段要稳定处理层输出什么生成层就渲染什么中间不要做二次加工否则出了问题很难定位。4.4 参数计算时间窗口与去重阈值的确定时间窗口我前面说了是24小时但这里有个细节窗口的起点和终点怎么定。如果固定为“昨天六点到今天六点”那跨窗口发布的内容可能被漏掉。我的做法是窗口稍微重叠取“昨天五点到今天六点”多出来的一小时用来兜底去重逻辑会把重复的干掉。去重阈值0.85是怎么来的我做过一组实验把阈值从0.7调到0.95观察日报的重复率和误杀率。0.7的时候误杀太多不同内容被当成重复0.95的时候重复又漏网。0.85是个平衡点但这个数跟你的向量模型有关换模型就得重新调。5. 常见问题与排查技巧实录5.1 日报内容突然变少或变空这是最常见的问题排查顺序我总结成一张表现象可能原因排查方法全部为空采集层全挂看采集日志确认是否有网络或权限问题部分为空某个源挂了单独跑那个源的采集脚本内容变少去重阈值过低临时调高阈值观察条目数变化内容变少时间窗口错位检查服务器时间与时区设置我遇到过一次“全部为空”查了半天发现是服务器时间被同步错了导致时间窗口取到了未来。这种问题最坑因为代码逻辑没错错在环境。5.2 摘要出现事实错误生成式摘要偶尔会编数字这个没法完全避免但可以降低概率。我的做法是在prompt里明确要求“只使用原文中出现的信息”并且在生成后做一次数字比对。如果摘要里的数字在原文里找不到就标记为可疑人工复核或者退回抽取式。实操心得不要迷信生成式摘要。日报是给人看的一条错误信息的代价远大于十条平淡信息的代价。宁可保守不要冒进。5.3 分类边界模糊导致误判“某公司发布新工具”到底算产品发布还是工具与开源这种边界问题几乎每天都会遇到。我的处理方式是允许多标签一条内容可以同时属于两个分类渲染时在主要分类下展示次要分类里做个引用。这样既避免了硬分类的尴尬又不至于让读者迷路。5.4 源站改版导致采集失效源站改版是采集层的头号杀手。我的应对策略是结构断言每次采集后检查关键字段比如标题、正文是否为空如果连续三次为空就触发告警。这样能在源站改版的第一时间发现而不是等日报变空了才反应过来。6. 让雷达越跑越准的几个进阶思路6.1 引入反馈闭环日报发出去之后读者的点击行为其实是很好的反馈信号。哪些条目被点得多说明这类内容有价值哪些被忽略说明可能选错了。我把点击数据回写到打分模型里作为engagement的一部分跑了一段时间之后日报的命中率确实有提升。这个闭环的关键是别把反馈当唯一标准。点击高不代表内容重要可能只是标题党。所以反馈的权重不能太高我一般控制在0.1到0.15之间。6.2 关键词表的动态维护前面提过关键词表要定期维护这里补充一个具体做法我会统计每个关键词在过去一周的命中次数和最终入选率。命中多但入选率低的词说明它带来的都是噪音该降权命中少但入选率高的词说明它精准该提权。这个统计我一般用脚本自动跑输出一张表人工过一遍就行。6.3 多日趋势的观察单看一天的日报很难判断雷达准不准。我习惯把最近七天的日报放在一起看观察分类分布、来源分布、条目数量的变化。如果某天某个分类突然暴增可能是那个源出了问题也可能是真有大事发生。这种趋势观察能帮你发现很多单日看不出来的问题。7. 我在实际搭建中踩过的坑最后分享几个具体的坑都是真金白银换来的。第一个坑是编码问题。有些源返回的内容编码不统一有的是UTF-8有的是GBK直接解码会乱码。我的做法是先用chardet之类的库探测编码再解码解码失败就跳过那条不要让一条坏数据污染整个日报。第二个坑是时间格式混乱。不同源的时间格式五花八门有的带时区有的不带有的是相对时间“3小时前”。我统一转成时间戳存储转换失败的条目单独放一个队列人工处理。这个队列不能太大否则说明你的解析逻辑有问题。第三个坑是过度依赖单一源。我曾经有个源特别优质命中率很高结果有一天它挂了日报质量断崖式下跌。从那以后我坚持每个分类至少有两个源互为备份。第四个坑是忽略存储成本。原始内容如果全存几个月下来数据量很可观。我的做法是原始内容只保留30天处理后的结构化数据长期保留。这样既省空间又不影响历史日报的查询。这套东西跑下来最大的体会是雷达的价值不在于抓得多而在于筛得准。抓取是体力活筛选才是技术活。你把去重、打分、分类这三件事做扎实了日报自然就好看了。至于那个具体的日期它只是雷达每天扫描的一个切片真正重要的是切片背后那套稳定运转的机制。