1. 一份日报的诞生从信息洪流到可读清单每天早上七点我的手机屏幕上会准时弹出一份自己搭建的AI日报。它不是某个平台推送的订阅消息也不是付费情报服务而是一套跑在我本地环境里的自动化流程——抓取、筛选、去重、摘要、排版最后输出成一份可以直接阅读的Markdown文档。2026年9月20日这一期恰好是这套系统稳定运行的第400天我想借这个节点把整套东西拆开来讲讲。先说清楚这份日报到底解决什么问题。做AI相关工作的朋友应该都有体会信息源太散了。模型发布、论文更新、开源项目、行业动态、工具迭代这些东西散落在几十个渠道里你不可能每天手动刷一遍。但如果不刷又会错过一些真正重要的变化。我试过纯靠人工筛选坚持了不到两周就放弃了——不是懒是信息量实在太大人工处理的速度跟不上产生的速度。所以这份日报的核心目标很明确用自动化手段把分散的AI信息聚合成一份结构化、可快速浏览的清单。它适合几类人参考一是想搭建类似系统的开发者二是对AI行业保持关注但没时间深挖的从业者三是想了解信息聚合类项目怎么落地的人。整套方案不依赖任何特定平台核心逻辑是通用的。需要提前说明的是下面讲的所有工具选型、参数配置、处理逻辑都是我在实际运行中反复调整后的结果。有些地方看起来绕但每一个绕都有它绕的理由我会尽量把为什么这么做讲透。2. 信息源的选择与抓取策略2.1 为什么信息源要分层而不是平铺最开始我犯过一个错误把所有信息源放在同一个优先级里统一抓取、统一处理。结果就是日报里充斥着大量低价值内容——某个小模型的版本号从1.2.1升到1.2.2这种和某个重要开源项目发布重大更新混在一起读者根本没法快速定位重点。后来我改成了三层信息源结构核心层头部实验室的官方发布渠道、几个主要预印本平台的新论文、GitHub上star增长最快的项目。这一层每天产出量不大但每一条都值得看。扩展层技术社区的热门讨论、行业媒体的深度报道、几个高质量的个人博客更新。这一层用来补充核心层可能遗漏的视角。兜底层聚合类站点的趋势榜单、社交平台上的高互动内容。这一层噪音最大但偶尔能捞到一些还没被主流关注的东西。分层的意义在于后续的筛选和排序可以按层给不同的权重。核心层的内容默认进入日报扩展层需要达到一定热度阈值兜底层只有触发特定关键词才会被收录。2.2 抓取频率与去重机制的实际配置抓取频率这块我踩过一个坑。一开始设的是每小时抓一次想着实时性越好越好。结果发现两个问题一是很多源本身更新频率就没那么高频繁抓取纯属浪费请求二是同一篇文章在不同时间抓到的内容可能有细微差异比如阅读数变了导致去重逻辑误判。现在的配置是这样的信息源层级抓取频率去重主键备注核心层每2小时标题发布者标题做归一化处理扩展层每4小时标题URLURL去掉追踪参数兜底层每6小时内容指纹用simhash做近似去重去重这块重点说一下。精确去重标题完全一致只能解决一部分问题真正麻烦的是近似重复——同一件事被不同来源报道标题措辞不一样但说的是同一回事。我的做法是对标题做归一化去掉标点、统一大小写、把常见同义词替换成统一形式然后再比对。对于兜底层因为内容质量参差不齐直接用simhash算内容指纹相似度超过阈值的只保留最早出现的那条。提示去重阈值不要设得太激进。我一开始把相似度阈值设到0.85结果把一些同一主题但不同角度的内容也误杀了。后来调到0.92误杀明显减少同时重复内容依然能有效过滤。2.3 抓取失败时的降级处理任何自动化系统都会遇到抓取失败。网络波动、源站改版、反爬策略调整这些都会导致某次抓取拿不到数据。我的处理原则是单次失败不报警连续失败才介入。具体逻辑是每个源维护一个失败计数器。单次失败计数器加一下次成功则清零。连续失败达到3次系统会发一条提醒给我同时该源暂时降级——从核心层降到扩展层或者从扩展层降到兜底层。如果连续失败达到10次该源会被暂时禁用直到我手动检查修复。这个机制的好处是不会因为一次偶发的网络问题就打断整个流程同时又能及时发现真正需要处理的源站变化。3. 从原始信息到可读摘要的处理链路3.1 摘要生成为什么不能直接截取前几句很多人做信息聚合时摘要就是简单截取正文的前100个字。这种做法在AI领域特别容易出问题——很多技术文章的开头是背景铺垫或者客套话真正的核心信息在中间甚至结尾。直接截取开头读者看到的往往是近年来人工智能技术快速发展这种毫无信息量的句子。我的做法是基于内容结构做摘要而不是基于位置。具体分三步第一步识别内容类型。是论文、是项目发布、是行业新闻、还是工具更新不同类型的内容核心信息的分布位置不一样。论文的核心通常在摘要和结论项目发布的核心在功能列表和更新日志行业新闻的核心在事件本身和影响分析。第二步提取候选句。根据内容类型从对应的位置抽取候选句子。比如论文就从摘要里抽项目发布就从更新说明里抽。第三步压缩和重组。把候选句里的冗余信息去掉保留关键的主谓宾结构必要时把多个短句合并成一个通顺的长句。这套逻辑跑下来摘要的可读性比简单截取高出一大截。当然也有翻车的时候——有些源站的HTML结构不规范导致内容类型识别错误摘要就会跑偏。这种情况我会在日报生成后人工扫一眼发现明显不对的就手动修正同时把那个源站的结构特征记下来下次调整解析规则。3.2 分类打标让日报有结构感一份没有分类的日报读起来就像一锅乱炖。我给每条内容打上分类标签日报按标签分组呈现。目前的分类体系是这样的模型与算法新模型发布、算法改进、训练技巧相关工具与框架开发工具、库、框架的更新和发布行业与应用AI在各行业的落地案例、产品动态研究与论文学术方向的新进展观点与讨论有深度的分析、评论、趋势判断打标的方式是关键词规则加轻量分类模型。关键词规则负责处理那些特征明显的条目比如标题里出现releaselaunch开源就归到工具或模型类。分类模型负责处理边界模糊的条目模型不大跑在本地CPU上完全够用。这里有个经验分类标签不要设太多。我一开始设了十几个分类结果每条内容都要纠结放哪个类别读者看着也累。后来砍到五个覆盖了90%以上的内容剩下的归入其他反而清爽了很多。3.3 排序逻辑热度、时效与个人偏好的平衡日报的排序直接决定了读者的阅读体验。纯按时间排重要的旧内容会被淹没纯按热度排刚发布的高质量内容又来不及积累热度。我的排序公式是三个因子的加权综合得分 时效分 × 0.4 热度分 × 0.35 偏好分 × 0.25时效分随时间衰减发布后2小时内最高24小时后降到很低。热度分综合了互动量、引用数、star增长等指标。偏好分是我自己维护的一个关键词权重表——比如我对推理优化小模型端侧部署这些方向特别关注相关内容的偏好分就会高一些。这个权重不是拍脑袋定的。我观察了两周自己的阅读行为发现自己实际点开的内容里时效性强的占四成左右热度高的占三成半个人偏好的占两成半。于是就把权重调成了上面这个比例。当然这个比例因人而异你可以根据自己的阅读习惯调整。4. 日报的呈现格式与阅读体验优化4.1 Markdown模板的设计取舍日报最终输出成Markdown格式方便在任意编辑器里阅读也方便归档和检索。模板结构经过了好几轮迭代现在的版本长这样# AI日报 2026-09-20 今日共收录 23 条 | 核心层 8 条 | 扩展层 11 条 | 兜底层 4 条 ## 模型与算法 ### 1. [标题] - 来源xxx - 摘要xxx - 链接xxx ## 工具与框架 ... ## 今日观察 对当天整体动态的一段简短分析几个设计细节值得说一下。顶部的统计信息让读者一眼知道今天的量级。每条内容下面的来源和链接是必须的方便溯源。今日观察是我后来加的一个模块用几句话概括当天最值得注意的趋势这部分目前还是人工写的因为自动生成的质量还达不到我的要求。4.2 阅读节奏的控制一份日报如果太长读者会疲劳。我的控制目标是全文阅读时间在8到12分钟之间。超过这个长度要么是当天信息确实多要么是筛选不够严格。控制长度的手段有几个一是设置每日收录上限核心层不设限扩展层最多15条兜底层最多5条。二是对长内容做折叠摘要控制在80字以内想看详细的点链接。三是分类之间的顺序按重要性排模型和工具类放前面观点讨论类放后面读者如果时间不够看完前面几类就可以停了。注意不要为了控制长度而牺牲信息完整性。我试过把摘要压到50字以内结果很多内容变得没头没尾读者反而要频繁点链接体验更差。80字左右是一个比较舒服的平衡点。4.3 归档与检索的配套方案日报每天生成一份时间长了就是一笔可观的信息资产。我按月份建文件夹每天的日报存成一个独立的Markdown文件文件名格式是YYYY-MM-DD.md。同时维护一个索引文件记录每天收录条目的标题和分类方便快速检索。检索这块我用了一个轻量的全文索引工具把每天的日报内容建了索引。想找某个话题的历史记录时直接搜关键词就能定位到具体是哪天的哪一条。这个功能在写季度总结或者做趋势分析时特别有用。5. 运行中遇到的典型问题与修复记录5.1 编码问题导致的乱码这个问题出现在项目早期。有些源站的页面编码不是UTF-8抓下来的内容里中文全是乱码。一开始我以为是抓取工具的问题换了几个库都没解决。后来才定位到是响应头的编码声明和实际编码不一致——页面声明是UTF-8实际内容是GBK。修复方案是在解析前先检测实际编码。我用了一个编码检测库对抓到的原始字节流做检测然后用检测到的编码来解码。同时加了一个兜底逻辑如果检测置信度低于某个阈值就尝试用几个常见编码分别解码选乱码最少的那次结果。这个坑的教训是不要相信源站声明的编码。以实际字节流的检测结果为准声明只作为参考。5.2 时间戳时区混乱不同源站的时间格式和时区五花八门。有的用UTC有的用当地时间有的干脆只给个3小时前这种相对时间。这导致排序时经常出现未来时间或者很久以前的误判。我的处理方式是统一转换成本地时间。对于绝对时间解析后根据源站所在时区做转换。对于相对时间以抓取时刻为基准反推。转换完成后所有时间戳都统一格式存储。排序时用的就是这个统一后的时间。这里有个细节相对时间的反推会有误差因为抓取时刻和实际发布时刻之间可能有延迟。我的做法是给相对时间反推的结果加一个标记排序时这类条目的时效分稍微降一点避免它们因为反推误差而排到不该排的位置。5.3 摘要生成中的事实性错误这是最让我头疼的一类问题。摘要生成逻辑偶尔会把原文的意思搞反比如把不支持某功能摘要成支持某功能或者把两个不同条目的信息混在一起。排查下来原因主要有两个一是原文本身有歧义摘要逻辑做了错误的消解二是多个条目的内容在去重阶段被错误合并导致摘要时拿到了混合后的文本。针对第一个原因我在摘要生成后加了一个一致性检查把摘要和原文的关键实体做比对如果摘要里出现了原文没有的实体或者原文的关键否定词在摘要里丢失了就标记为可疑转人工复核。针对第二个原因我收紧了去重的合并条件只有相似度极高且来源相同的条目才合并来源不同的即使内容相似也保持独立。5.4 源站改版导致的解析失效源站改版是自动化抓取的天敌。页面结构一变原来的解析规则就失效了轻则抓不到内容重则抓到一堆无关的导航文字。我的应对策略是解析规则与源站配置分离。每个源站的解析规则写在一个独立的配置文件里改版时只需要改对应的配置文件不用动主流程代码。同时每次抓取后会做一个内容质量检查如果抓到的内容长度异常短或者包含大量导航类关键词就判定为解析可能失效触发提醒。这套机制不能完全避免改版带来的中断但能把修复时间从发现日报内容不对再回头排查缩短到收到提醒直接改配置。6. 这套系统跑了一年之后的一些体会6.1 自动化不是终点人机配合才是我一开始的设想是全自动人完全不介入。跑了一段时间后发现完全自动化的日报质量是有天花板的。摘要可能跑偏分类可能出错排序可能不符合当天的实际情况。后来我调整了思路自动化负责处理80%的常规内容人工负责20%的关键判断。具体来说系统自动生成日报初稿我每天早上花10分钟左右过一遍修正明显的错误补充今日观察那段人工分析然后发布。这10分钟的投入换来的是日报质量的显著提升。而且随着系统不断学习我的修正习惯需要人工介入的比例在慢慢下降。6.2 信息源的质量比数量重要刚开始搭建时我恨不得把所有能找到的AI相关源都加进去。结果日报变得又长又杂阅读体验很差。后来我做了减法砍掉了大量低质量源只保留真正有信息增量的那些。判断一个源是否值得保留我的标准是过去一个月里这个源贡献了多少条被我标记为必读的内容。如果一个月下来一条都没有那这个源就可以考虑移除了。这个标准很粗暴但很有效。6.3 日报的价值在于持续不在于单期单看某一天的日报可能觉得就是一些信息的罗列。但连续看一个月、一个季度就能看出趋势的演变。哪些方向在升温哪些在降温哪些是反复出现但一直没有实质进展的这些判断都需要时间序列上的对比才能做出来。所以我在系统里加了一个趋势追踪模块对每个分类下的关键词做频率统计生成周度和月度的趋势报告。这个模块的输出不放在日报里而是单独归档供做阶段性回顾时参考。6.4 给想搭建类似系统的朋友几条实在建议如果你也想搭一套自己的AI日报系统我的建议是先从最小的闭环开始。不要一上来就追求大而全先跑通抓取一个源、生成一条摘要、输出一份最简单的日报这个最小闭环然后再逐步扩展。把配置和代码分开。源站配置、分类规则、排序权重这些都放到配置文件里改的时候不用动代码维护成本会低很多。留好人工介入的接口。系统再智能也有出错的时候设计时就要考虑人工修正的流程不要做成一个黑盒。定期回顾和清理。信息源、分类体系、排序权重这些都不是设好就一劳永逸的需要根据实际运行情况定期调整。这套系统到现在还在持续迭代最近在尝试的方向是把摘要生成换成更轻量的本地模型进一步降低运行成本。等跑稳定了再找机会把新的经验整理出来。
从信息洪流到可读清单：AI日报自动化系统的架构与优化实践
1. 一份日报的诞生从信息洪流到可读清单每天早上七点我的手机屏幕上会准时弹出一份自己搭建的AI日报。它不是某个平台推送的订阅消息也不是付费情报服务而是一套跑在我本地环境里的自动化流程——抓取、筛选、去重、摘要、排版最后输出成一份可以直接阅读的Markdown文档。2026年9月20日这一期恰好是这套系统稳定运行的第400天我想借这个节点把整套东西拆开来讲讲。先说清楚这份日报到底解决什么问题。做AI相关工作的朋友应该都有体会信息源太散了。模型发布、论文更新、开源项目、行业动态、工具迭代这些东西散落在几十个渠道里你不可能每天手动刷一遍。但如果不刷又会错过一些真正重要的变化。我试过纯靠人工筛选坚持了不到两周就放弃了——不是懒是信息量实在太大人工处理的速度跟不上产生的速度。所以这份日报的核心目标很明确用自动化手段把分散的AI信息聚合成一份结构化、可快速浏览的清单。它适合几类人参考一是想搭建类似系统的开发者二是对AI行业保持关注但没时间深挖的从业者三是想了解信息聚合类项目怎么落地的人。整套方案不依赖任何特定平台核心逻辑是通用的。需要提前说明的是下面讲的所有工具选型、参数配置、处理逻辑都是我在实际运行中反复调整后的结果。有些地方看起来绕但每一个绕都有它绕的理由我会尽量把为什么这么做讲透。2. 信息源的选择与抓取策略2.1 为什么信息源要分层而不是平铺最开始我犯过一个错误把所有信息源放在同一个优先级里统一抓取、统一处理。结果就是日报里充斥着大量低价值内容——某个小模型的版本号从1.2.1升到1.2.2这种和某个重要开源项目发布重大更新混在一起读者根本没法快速定位重点。后来我改成了三层信息源结构核心层头部实验室的官方发布渠道、几个主要预印本平台的新论文、GitHub上star增长最快的项目。这一层每天产出量不大但每一条都值得看。扩展层技术社区的热门讨论、行业媒体的深度报道、几个高质量的个人博客更新。这一层用来补充核心层可能遗漏的视角。兜底层聚合类站点的趋势榜单、社交平台上的高互动内容。这一层噪音最大但偶尔能捞到一些还没被主流关注的东西。分层的意义在于后续的筛选和排序可以按层给不同的权重。核心层的内容默认进入日报扩展层需要达到一定热度阈值兜底层只有触发特定关键词才会被收录。2.2 抓取频率与去重机制的实际配置抓取频率这块我踩过一个坑。一开始设的是每小时抓一次想着实时性越好越好。结果发现两个问题一是很多源本身更新频率就没那么高频繁抓取纯属浪费请求二是同一篇文章在不同时间抓到的内容可能有细微差异比如阅读数变了导致去重逻辑误判。现在的配置是这样的信息源层级抓取频率去重主键备注核心层每2小时标题发布者标题做归一化处理扩展层每4小时标题URLURL去掉追踪参数兜底层每6小时内容指纹用simhash做近似去重去重这块重点说一下。精确去重标题完全一致只能解决一部分问题真正麻烦的是近似重复——同一件事被不同来源报道标题措辞不一样但说的是同一回事。我的做法是对标题做归一化去掉标点、统一大小写、把常见同义词替换成统一形式然后再比对。对于兜底层因为内容质量参差不齐直接用simhash算内容指纹相似度超过阈值的只保留最早出现的那条。提示去重阈值不要设得太激进。我一开始把相似度阈值设到0.85结果把一些同一主题但不同角度的内容也误杀了。后来调到0.92误杀明显减少同时重复内容依然能有效过滤。2.3 抓取失败时的降级处理任何自动化系统都会遇到抓取失败。网络波动、源站改版、反爬策略调整这些都会导致某次抓取拿不到数据。我的处理原则是单次失败不报警连续失败才介入。具体逻辑是每个源维护一个失败计数器。单次失败计数器加一下次成功则清零。连续失败达到3次系统会发一条提醒给我同时该源暂时降级——从核心层降到扩展层或者从扩展层降到兜底层。如果连续失败达到10次该源会被暂时禁用直到我手动检查修复。这个机制的好处是不会因为一次偶发的网络问题就打断整个流程同时又能及时发现真正需要处理的源站变化。3. 从原始信息到可读摘要的处理链路3.1 摘要生成为什么不能直接截取前几句很多人做信息聚合时摘要就是简单截取正文的前100个字。这种做法在AI领域特别容易出问题——很多技术文章的开头是背景铺垫或者客套话真正的核心信息在中间甚至结尾。直接截取开头读者看到的往往是近年来人工智能技术快速发展这种毫无信息量的句子。我的做法是基于内容结构做摘要而不是基于位置。具体分三步第一步识别内容类型。是论文、是项目发布、是行业新闻、还是工具更新不同类型的内容核心信息的分布位置不一样。论文的核心通常在摘要和结论项目发布的核心在功能列表和更新日志行业新闻的核心在事件本身和影响分析。第二步提取候选句。根据内容类型从对应的位置抽取候选句子。比如论文就从摘要里抽项目发布就从更新说明里抽。第三步压缩和重组。把候选句里的冗余信息去掉保留关键的主谓宾结构必要时把多个短句合并成一个通顺的长句。这套逻辑跑下来摘要的可读性比简单截取高出一大截。当然也有翻车的时候——有些源站的HTML结构不规范导致内容类型识别错误摘要就会跑偏。这种情况我会在日报生成后人工扫一眼发现明显不对的就手动修正同时把那个源站的结构特征记下来下次调整解析规则。3.2 分类打标让日报有结构感一份没有分类的日报读起来就像一锅乱炖。我给每条内容打上分类标签日报按标签分组呈现。目前的分类体系是这样的模型与算法新模型发布、算法改进、训练技巧相关工具与框架开发工具、库、框架的更新和发布行业与应用AI在各行业的落地案例、产品动态研究与论文学术方向的新进展观点与讨论有深度的分析、评论、趋势判断打标的方式是关键词规则加轻量分类模型。关键词规则负责处理那些特征明显的条目比如标题里出现releaselaunch开源就归到工具或模型类。分类模型负责处理边界模糊的条目模型不大跑在本地CPU上完全够用。这里有个经验分类标签不要设太多。我一开始设了十几个分类结果每条内容都要纠结放哪个类别读者看着也累。后来砍到五个覆盖了90%以上的内容剩下的归入其他反而清爽了很多。3.3 排序逻辑热度、时效与个人偏好的平衡日报的排序直接决定了读者的阅读体验。纯按时间排重要的旧内容会被淹没纯按热度排刚发布的高质量内容又来不及积累热度。我的排序公式是三个因子的加权综合得分 时效分 × 0.4 热度分 × 0.35 偏好分 × 0.25时效分随时间衰减发布后2小时内最高24小时后降到很低。热度分综合了互动量、引用数、star增长等指标。偏好分是我自己维护的一个关键词权重表——比如我对推理优化小模型端侧部署这些方向特别关注相关内容的偏好分就会高一些。这个权重不是拍脑袋定的。我观察了两周自己的阅读行为发现自己实际点开的内容里时效性强的占四成左右热度高的占三成半个人偏好的占两成半。于是就把权重调成了上面这个比例。当然这个比例因人而异你可以根据自己的阅读习惯调整。4. 日报的呈现格式与阅读体验优化4.1 Markdown模板的设计取舍日报最终输出成Markdown格式方便在任意编辑器里阅读也方便归档和检索。模板结构经过了好几轮迭代现在的版本长这样# AI日报 2026-09-20 今日共收录 23 条 | 核心层 8 条 | 扩展层 11 条 | 兜底层 4 条 ## 模型与算法 ### 1. [标题] - 来源xxx - 摘要xxx - 链接xxx ## 工具与框架 ... ## 今日观察 对当天整体动态的一段简短分析几个设计细节值得说一下。顶部的统计信息让读者一眼知道今天的量级。每条内容下面的来源和链接是必须的方便溯源。今日观察是我后来加的一个模块用几句话概括当天最值得注意的趋势这部分目前还是人工写的因为自动生成的质量还达不到我的要求。4.2 阅读节奏的控制一份日报如果太长读者会疲劳。我的控制目标是全文阅读时间在8到12分钟之间。超过这个长度要么是当天信息确实多要么是筛选不够严格。控制长度的手段有几个一是设置每日收录上限核心层不设限扩展层最多15条兜底层最多5条。二是对长内容做折叠摘要控制在80字以内想看详细的点链接。三是分类之间的顺序按重要性排模型和工具类放前面观点讨论类放后面读者如果时间不够看完前面几类就可以停了。注意不要为了控制长度而牺牲信息完整性。我试过把摘要压到50字以内结果很多内容变得没头没尾读者反而要频繁点链接体验更差。80字左右是一个比较舒服的平衡点。4.3 归档与检索的配套方案日报每天生成一份时间长了就是一笔可观的信息资产。我按月份建文件夹每天的日报存成一个独立的Markdown文件文件名格式是YYYY-MM-DD.md。同时维护一个索引文件记录每天收录条目的标题和分类方便快速检索。检索这块我用了一个轻量的全文索引工具把每天的日报内容建了索引。想找某个话题的历史记录时直接搜关键词就能定位到具体是哪天的哪一条。这个功能在写季度总结或者做趋势分析时特别有用。5. 运行中遇到的典型问题与修复记录5.1 编码问题导致的乱码这个问题出现在项目早期。有些源站的页面编码不是UTF-8抓下来的内容里中文全是乱码。一开始我以为是抓取工具的问题换了几个库都没解决。后来才定位到是响应头的编码声明和实际编码不一致——页面声明是UTF-8实际内容是GBK。修复方案是在解析前先检测实际编码。我用了一个编码检测库对抓到的原始字节流做检测然后用检测到的编码来解码。同时加了一个兜底逻辑如果检测置信度低于某个阈值就尝试用几个常见编码分别解码选乱码最少的那次结果。这个坑的教训是不要相信源站声明的编码。以实际字节流的检测结果为准声明只作为参考。5.2 时间戳时区混乱不同源站的时间格式和时区五花八门。有的用UTC有的用当地时间有的干脆只给个3小时前这种相对时间。这导致排序时经常出现未来时间或者很久以前的误判。我的处理方式是统一转换成本地时间。对于绝对时间解析后根据源站所在时区做转换。对于相对时间以抓取时刻为基准反推。转换完成后所有时间戳都统一格式存储。排序时用的就是这个统一后的时间。这里有个细节相对时间的反推会有误差因为抓取时刻和实际发布时刻之间可能有延迟。我的做法是给相对时间反推的结果加一个标记排序时这类条目的时效分稍微降一点避免它们因为反推误差而排到不该排的位置。5.3 摘要生成中的事实性错误这是最让我头疼的一类问题。摘要生成逻辑偶尔会把原文的意思搞反比如把不支持某功能摘要成支持某功能或者把两个不同条目的信息混在一起。排查下来原因主要有两个一是原文本身有歧义摘要逻辑做了错误的消解二是多个条目的内容在去重阶段被错误合并导致摘要时拿到了混合后的文本。针对第一个原因我在摘要生成后加了一个一致性检查把摘要和原文的关键实体做比对如果摘要里出现了原文没有的实体或者原文的关键否定词在摘要里丢失了就标记为可疑转人工复核。针对第二个原因我收紧了去重的合并条件只有相似度极高且来源相同的条目才合并来源不同的即使内容相似也保持独立。5.4 源站改版导致的解析失效源站改版是自动化抓取的天敌。页面结构一变原来的解析规则就失效了轻则抓不到内容重则抓到一堆无关的导航文字。我的应对策略是解析规则与源站配置分离。每个源站的解析规则写在一个独立的配置文件里改版时只需要改对应的配置文件不用动主流程代码。同时每次抓取后会做一个内容质量检查如果抓到的内容长度异常短或者包含大量导航类关键词就判定为解析可能失效触发提醒。这套机制不能完全避免改版带来的中断但能把修复时间从发现日报内容不对再回头排查缩短到收到提醒直接改配置。6. 这套系统跑了一年之后的一些体会6.1 自动化不是终点人机配合才是我一开始的设想是全自动人完全不介入。跑了一段时间后发现完全自动化的日报质量是有天花板的。摘要可能跑偏分类可能出错排序可能不符合当天的实际情况。后来我调整了思路自动化负责处理80%的常规内容人工负责20%的关键判断。具体来说系统自动生成日报初稿我每天早上花10分钟左右过一遍修正明显的错误补充今日观察那段人工分析然后发布。这10分钟的投入换来的是日报质量的显著提升。而且随着系统不断学习我的修正习惯需要人工介入的比例在慢慢下降。6.2 信息源的质量比数量重要刚开始搭建时我恨不得把所有能找到的AI相关源都加进去。结果日报变得又长又杂阅读体验很差。后来我做了减法砍掉了大量低质量源只保留真正有信息增量的那些。判断一个源是否值得保留我的标准是过去一个月里这个源贡献了多少条被我标记为必读的内容。如果一个月下来一条都没有那这个源就可以考虑移除了。这个标准很粗暴但很有效。6.3 日报的价值在于持续不在于单期单看某一天的日报可能觉得就是一些信息的罗列。但连续看一个月、一个季度就能看出趋势的演变。哪些方向在升温哪些在降温哪些是反复出现但一直没有实质进展的这些判断都需要时间序列上的对比才能做出来。所以我在系统里加了一个趋势追踪模块对每个分类下的关键词做频率统计生成周度和月度的趋势报告。这个模块的输出不放在日报里而是单独归档供做阶段性回顾时参考。6.4 给想搭建类似系统的朋友几条实在建议如果你也想搭一套自己的AI日报系统我的建议是先从最小的闭环开始。不要一上来就追求大而全先跑通抓取一个源、生成一条摘要、输出一份最简单的日报这个最小闭环然后再逐步扩展。把配置和代码分开。源站配置、分类规则、排序权重这些都放到配置文件里改的时候不用动代码维护成本会低很多。留好人工介入的接口。系统再智能也有出错的时候设计时就要考虑人工修正的流程不要做成一个黑盒。定期回顾和清理。信息源、分类体系、排序权重这些都不是设好就一劳永逸的需要根据实际运行情况定期调整。这套系统到现在还在持续迭代最近在尝试的方向是把摘要生成换成更轻量的本地模型进一步降低运行成本。等跑稳定了再找机会把新的经验整理出来。
