1. 当日报变成一场信息焦虑的自我救赎每天早上七点半我的手机闹钟还没响微信里已经躺着三条AI日报推送。点开一看十条新闻里有八条是昨天在另一个号上刷到过的剩下两条是标题党——某大模型一夜颠覆行业点进去发现只是发了个版本号。这种体验持续了大概两个月我终于受不了了决定自己动手做一份真正有用的AI日报。这个项目的起点特别朴素我受够了被算法投喂的碎片化信息想要一份每天花五分钟就能看完、但看完之后真的知道昨天AI圈发生了什么的东西。关键词就三个——信息筛选、自动化聚合、人工判断。听起来简单做起来才发现每一步都是坑。从信息源的选取到去重逻辑的设计从摘要生成到排版输出我前后迭代了四个版本踩过的坑足够写一篇避坑指南。这篇文章适合两类人看一类是和我一样每天被信息洪流淹没、想建立自己信息筛选机制的人另一类是对自动化内容聚合感兴趣、想了解背后技术实现逻辑的开发者。我会把整个项目的设计思路、技术选型、实操步骤和踩坑经验全部摊开来讲不藏私。你不需要有很深的编程基础但需要对信息处理这件事有基本的耐心——因为最难的从来不是技术而是判断什么值得留下。2. 信息源的选择为什么我砍掉了80%的订阅源2.1 从多多益善到少即是多的认知转变项目第一版的时候我像个囤积癖一样往信息源列表里塞东西。技术博客、行业媒体、社交平台上的AI话题、几个知名研究者的个人主页、甚至还有两个论坛的精华区。结果第一天跑下来抓了三百多条内容光去重就花了我两个小时最后真正值得看的不到十条。这个投入产出比让我意识到一个问题信息源的质量远比数量重要。我后来做了一个简单的统计把每个信息源在过去一周内产生的被我标记为有价值的内容数量除以它产生的总内容数量得到一个信噪比。结果很残酷排名前五的信息源贡献了超过70%的有价值内容而排名后二十的信息源加起来贡献不到5%。这意味着我花了大量时间在处理垃圾信息上。于是第二版我做了个狠心的决定只保留信噪比排名前20%的信息源其余全部砍掉。具体来说我保留了以下几类官方发布渠道模型更新、产品发布这类信息官方渠道永远是最快最准的。我订阅了几个主要AI公司的官方博客和更新日志。经过验证的行业媒体不是所有挂着AI名头的媒体都值得看。我筛选的标准是是否有固定的编辑团队、是否会对新闻做事实核查、是否区分报道和评论。高质量的个人技术博客这类源需要花时间淘但一旦找到几个靠谱的价值极高。我通常通过看某篇文章的引用链来发现新的优质博客。学术预印本平台的特定分类不是全看而是设置关键词过滤只抓取和我关注方向相关的论文。砍掉80%的源之后每天抓取的内容量降到了五十条左右去重后大概三十条我花十五分钟就能筛完。效率提升了焦虑感反而下降了。2.2 信息源分级与权重分配的具体操作光砍源还不够不同信息源的可信度和时效性是不一样的。我设计了一个简单的三级权重体系级别类型权重系数处理策略A级官方公告、经过核实的行业报道1.0直接进入候选池优先展示B级个人技术博客、社区高赞讨论0.7需要交叉验证标注来源C级社交平台碎片信息、未经验证的爆料0.3仅作为线索不直接采用这个权重体系在实际操作中帮我避免了好几次误判。比如有一次某个C级源爆料说某模型要开源我没有直接采信而是等了两天果然官方出来辟谣了。如果没有这个分级机制我可能就把那条假消息写进日报了。权重分配的逻辑其实很简单信息在传播链条上每经过一次转发可信度就衰减一次。所以越接近源头的信息权重越高。这个原则不仅适用于AI日报任何信息聚合项目都可以参考。2.3 动态调整信息源不是一成不变的我每个月会做一次信息源审查看看哪些源的质量在下降哪些新源值得加入。审查的指标包括过去一个月的采用率、被其他源交叉验证的次数、以及我个人的主观评分。有一个容易被忽略的点是信息源的质量会随时间变化。有些博客刚开始写的时候很用心后来可能因为作者工作忙就变成月更甚至停更了有些媒体刚开始做的时候很扎实后来可能为了流量开始标题党。所以定期审查是必须的不能设好就不管了。我自己的做法是维护一个简单的表格记录每个源的基本信息和月度评分。这个表格不需要多复杂用在线表格工具就能搞定。关键是养成定期回顾的习惯。3. 去重与摘要自动化处理中最容易翻车的两个环节3.1 去重不是简单的字符串比对第一版去重我用的最笨的办法标题完全匹配就判定为重复。结果发现同一个事件不同媒体的标题写法千差万别。比如某公司发布新一代模型和某公司推出最新AI系统说的是同一件事但字符串比对完全识别不出来。后来我改进了策略分三步走第一步是URL去重。这个最简单同一个链接肯定指向同一内容。但问题是很多媒体会互相转载URL不同但内容一样。第二步是标题相似度计算。我用了编辑距离和词向量相似度结合的方式。编辑距离能捕捉字面上的相似词向量能捕捉语义上的相似。两个指标都超过阈值才判定为重复。这里的关键是阈值设定——设太高会漏掉重复设太低会把不同事件误判为同一件。我试了好几组参数最后定在编辑距离0.6、词向量相似度0.75这个组合上实测下来准确率最高。第三步是正文指纹比对。对于标题相似度处于临界值的内容我会进一步比对正文的前200个字符的哈希值。如果哈希值相同或高度相似就判定为重复。这三步走下来去重的准确率从最初的60%左右提升到了90%以上。剩下的10%主要是那些同一事件不同角度报道的情况这种我反而认为是值得保留的因为不同角度的信息可以互相补充。3.2 摘要生成为什么我最终选择了模板人工的混合方案摘要生成是我踩坑最多的环节。一开始我想得很美用现成的文本摘要API输入正文输出摘要全自动。实际跑起来发现几个问题摘要质量不稳定同样的模型对有些文章摘要得很准对另一些就抓不住重点。无法区分信息重要性模型不知道哪句话是核心结论哪句话是背景铺垫。风格不统一有的摘要像新闻稿有的像论文摘要读起来很割裂。我试过调参、换模型、加提示词效果都不理想。后来我想明白了一件事日报的摘要不是简单的文本压缩而是信息重组。它需要判断什么信息对读者最重要然后用统一的风格表达出来。于是我换了个思路设计了一套模板化的摘要生成方案# 摘要生成模板示例伪代码 def generate_summary(article): # 提取关键要素 entity extract_entity(article) # 涉及的主体 action extract_action(article) # 发生了什么 impact extract_impact(article) # 有什么影响 # 根据文章类型选择模板 if article.type release: template {entity}发布了{action}主要影响是{impact}。 elif article.type research: template 一项关于{action}的研究显示{impact}。 elif article.type opinion: template 有观点认为{action}值得关注的是{impact}。 return template.format(entityentity, actionaction, impactimpact)这套方案的核心是先让程序提取结构化信息再用模板组装成自然语言。提取环节用规则和模型结合的方式组装环节用固定模板保证风格统一。最后我再人工过一遍修正明显的错误。实测下来这套混合方案比纯模型摘要的效率高很多。程序处理三十条内容大概需要两分钟我人工审核和修正大概需要十分钟。总共十二分钟就能完成原来需要一小时的工作。3.3 那些让我半夜爬起来改代码的bug做自动化处理最怕的就是静默失败——程序没报错但输出结果是错的。我遇到过几次这样的情况有一次去重逻辑出了bug把两条完全不相关的内容判定为重复结果日报里少了一条重要新闻。我是第二天早上看读者反馈才发现的。后来我加了一个去重日志每次判定为重复的内容都会记录下判定依据和相似度分数方便事后审查。还有一次摘要生成的时候实体提取环节把公司名和产品名搞混了导致摘要读起来完全不通。这个问题的根源是实体识别模型对某些新出现的专有名词识别不准。我的解决办法是维护一个自定义词典把常见的AI公司名、产品名、模型名都加进去提取的时候优先匹配词典。这些坑让我养成了一个习惯每次修改核心逻辑之后都要用历史数据跑一遍回归测试。我会准备一组标注好的测试数据包含各种边界情况每次改完代码就跑一遍看看有没有引入新的问题。这个习惯帮我避免了好几次线上事故。4. 排版与输出让日报读起来不像机器生成的4.1 信息分块为什么我坚持三条一屏的原则日报的排版我改了很多版。最开始是简单列表一条接一条读起来很累。后来尝试了卡片式布局每条内容一个卡片但卡片太多滚动起来也很烦。最后我定了一个原则每屏不超过三条内容每条内容不超过三行。这个原则的依据是人的短时记忆容量。心理学上有个著名的7±2理论说的是人一次能记住的信息块大概是5到9个。但在移动端阅读场景下这个数字要打折扣因为屏幕小、干扰多。我实测下来三条是一个比较舒服的量——既能提供足够的信息密度又不会让人感到压迫。具体排版上我用了这样的结构第一条最重要的新闻加粗标题摘要控制在两行以内。第二条次重要新闻正常字重摘要一行半左右。第三条值得关注的动态用稍小的字号摘要一行。三条之后留白然后开始下一组。这样读者可以快速扫读也可以在某一条上停留细看。4.2 视觉层次用格式引导阅读顺序排版的核心是引导读者的视线。我用了几个简单的技巧加粗只用于最重要的关键词比如公司名、产品名、核心结论。一条摘要里加粗不超过两处。分隔线不同板块之间用细线分隔但不用太粗的线避免视觉噪音。留白段落之间留足够的空白让眼睛有休息的地方。字号梯度标题、正文、注释用不同的字号形成清晰的层次。这些技巧听起来很基础但组合起来效果很明显。我做过一个小范围的对比测试用新排版和旧排版各发了一周新排版的平均阅读完成率高了将近一倍。4.3 输出格式的选择Markdown还是HTML技术选型上我纠结过一阵。Markdown的好处是通用性强可以方便地转换成其他格式HTML的好处是控制力强可以实现更复杂的排版效果。最后我选择了Markdown作为主要输出格式HTML作为可选输出。原因是我的主要发布渠道对Markdown的支持都很好而且Markdown的纯文本特性让版本管理和差异对比变得很简单。每次日报生成后我可以直接用git diff看到和昨天的区别方便追溯。如果你也想做类似的项目我的建议是先确定发布渠道再决定输出格式。如果发布渠道支持Markdown那就用Markdown如果不支持再考虑HTML或者其他格式。不要为了技术而技术。5. 自动化流程的搭建从手动到半自动的渐进式改造5.1 定时任务为什么我放弃了完全自动最开始我想做全自动定时抓取、自动处理、自动发布我什么都不用管。但跑了一周就发现不行——自动发布的内容里偶尔会出现事实错误或者表述不当的地方而我没有机会在发布前拦截。后来我改成了半自动流程程序在每天早上六点自动抓取和处理生成一个草稿然后我花十到十五分钟审核和修改确认无误后再发布。这个流程兼顾了效率和可控性。定时任务的实现我用的是最朴素的方式服务器上的cron job。每天早上六点触发抓取脚本六点十分触发处理脚本六点半生成草稿并发送到我的邮箱。我起床后打开邮箱审核修改完直接发布。# crontab 配置示例 0 6 * * * /path/to/fetch_script.sh /var/log/fetch.log 21 10 6 * * * /path/to/process_script.sh /var/log/process.log 21 30 6 * * * /path/to/generate_draft.sh /var/log/draft.log 21这个配置很简单但足够可靠。关键是要把日志输出重定向到文件方便出问题的时候排查。5.2 异常处理当抓取失败时会发生什么自动化流程最怕的就是某个环节挂了但没人知道。我遇到过几次这样的情况某个信息源的页面结构变了抓取脚本报错退出但因为没有告警机制我直到第二天才发现日报里少了那个源的内容。后来我加了一套简单的告警机制抓取失败告警如果某个源连续两次抓取失败发送邮件提醒。内容量异常告警如果当天抓取的内容量低于历史平均值的50%发送提醒。处理超时告警如果处理脚本运行超过预设时间还没结束发送提醒。这些告警不需要多复杂用最简单的邮件通知就行。关键是要有不能等出了问题再补救。5.3 数据存储为什么我用文件而不是数据库技术选型上我选择了用文件系统而不是数据库来存储数据。原因有几个数据量不大每天几十条内容一年也就一万多条文件系统完全够用。便于调试出问题的时候直接打开文件看就行不需要连数据库查。版本管理用git管理文件每次变更都有记录方便回溯。迁移方便换服务器的时候直接把文件夹拷过去就行。我用的目录结构是这样的ai-daily/ ├── raw/ # 原始抓取内容 │ ├── 2026-10-01/ │ ├── 2026-10-02/ │ └── 2026-10-03/ ├── processed/ # 处理后的内容 │ ├── 2026-10-01.json │ ├── 2026-10-02.json │ └── 2026-10-03.json ├── drafts/ # 生成的草稿 │ ├── 2026-10-01.md │ ├── 2026-10-02.md │ └── 2026-10-03.md └── config/ # 配置文件 ├── sources.json └── templates/这个结构清晰明了找什么东西都很方便。如果你要做的项目数据量更大或者需要更复杂的查询那可以考虑上数据库。但对于个人项目来说文件系统往往是更务实的选择。6. 人工审核环节那些只有人才能做的判断6.1 事实核查机器做不到的最后一公里自动化流程可以帮我抓取、去重、生成摘要但有一件事它做不了判断一条信息是否可信。这个判断需要背景知识、需要常识、需要对信息源的了解这些都不是程序能替代的。我审核的时候会问自己几个问题这条信息的来源可靠吗是官方渠道还是二手转述信息里有具体的数字、时间、人名吗还是模糊的据悉有消息称这条信息和我知道的其他信息矛盾吗如果矛盾哪个更可信如果这条信息是错的会有什么后果这几个问题过一遍大部分假消息和低质量信息就被筛掉了。剩下的才进入日报。6.2 价值判断什么值得读者花时间看事实核查之后是价值判断。一条信息是真的不代表它值得被放进日报。我判断价值的标准有三个时效性是昨天发生的事吗如果是三天前的除非特别重要否则不放。影响力这件事会影响多少人是行业级的还是小圈子的独特性是独家信息还是大家都在报如果大家都在报我有没有提供额外的视角这三个标准帮我过滤掉了大量真实但无用的信息。比如某个小公司发了个不痛不痒的更新虽然是真的但既没有时效性优势也没有影响力更谈不上独特性那就没必要放。6.3 语言润色让机器生成的内容读起来像人写的最后一步是语言润色。机器生成的摘要往往有几个毛病用词重复、句式单一、缺乏过渡。我的润色原则是换词同一个意思换不同的表达避免重复。调整句式长短句结合不要全是主谓宾。加过渡条目之间加简短的过渡语让阅读更流畅。删冗余把据悉据了解这类废话删掉。润色这一步花的时间不多大概每条内容十几秒但效果很明显。读者反馈说日报读起来不像机器写的这让我觉得这些功夫没白费。7. 运营三个月后的一些真实体会7.1 读者反馈教会我的事日报发出去之后我收到过各种反馈。有人说太长了有人说太短了有人说应该多放技术内容有人说应该多放行业动态。这些反馈让我意识到一件事你不可能让所有人都满意。我的应对策略是明确日报的定位然后坚持这个定位。我的日报定位是给AI从业者的每日信息简报不是给大众的科普也不是给投资人的行业分析。明确了定位之后很多反馈就知道该怎么处理了——符合定位的采纳不符合的礼貌感谢但不改。7.2 持续运营的关键降低自己的负担做日报最大的挑战不是技术是坚持。每天都要花时间审核、润色、发布时间长了很容易懈怠。我见过好几个类似的日报项目做了几周就停更了。我的经验是把流程设计得尽可能省力。自动化能做的绝不手动做能提前准备的绝不拖到最后一刻。比如我会在周末把下周的模板准备好把常用的过渡语和格式固定下来这样工作日的时候只需要专注于内容本身。另外接受不完美。有时候某天内容确实比较少那就少发几条有时候某条摘要润色得不够好但意思到了就行。不要因为追求完美而给自己太大压力那样反而坚持不下去。7.3 如果重新来过我会怎么做如果让我重新做这个项目我会做几个调整更早地砍掉低质量信息源我在信息源筛选上浪费了太多时间应该一开始就狠心一点。更早地引入人工审核环节纯自动化的尝试浪费了不少精力半自动才是可持续的方案。更注重排版排版对阅读体验的影响比我预想的大应该更早重视。建立读者反馈渠道早期没有反馈渠道走了不少弯路。后来加了个简单的反馈入口帮助很大。这些经验不一定适用于所有人但如果你也在做类似的信息聚合项目希望能帮你少踩几个坑。最核心的一点是工具是为人服务的不要为了自动化而自动化。该人工判断的地方就人工判断该花时间的地方就花时间最终产出质量才是最重要的。