1. 一份日报背后的信息筛选逻辑做科技资讯日报这件事我从2023年就开始折腾了。最开始是给自己看每天早上花四十分钟刷HackerNews、几个大模型厂商的更新页、还有几个技术社区的热榜把值得关注的东西记到Notion里。后来有朋友说你这整理得挺清楚不如发出来。于是就有了现在这个「科技AI资讯日报」的固定栏目每天一期覆盖HackerNews精选和全球热点速递两个板块。这份日报解决的核心问题其实很朴素信息过载。做AI方向的人应该都有体会每天醒来打开手机光是模型发布、框架更新、Agent工具链迭代的消息就有几十条再加上HackerNews上那些讨论帖、论文解读、开源项目根本看不过来。更麻烦的是很多消息是重复的、低质的、甚至是标题党。一份好的日报价值不在于全而在于筛——把噪音过滤掉把真正值得花时间的东西挑出来再用最短的篇幅讲清楚它是什么、为什么重要。适合看这份日报的人我大致分了三类。第一类是AI应用开发者关心LLM框架、Agent编排、工具链集成这些落地层面的东西第二类是技术决策者需要快速判断某个新模型、新范式值不值得投入资源跟进第三类是对AI保持好奇的泛技术读者不一定动手写代码但想跟上这个领域在发生什么。这三类人的需求不一样所以日报在结构上做了分层HackerNews精选偏技术深度和社区讨论全球热点速递偏行业动态和产品发布中间用关键词标签做交叉索引。提示日报类内容最忌讳什么都放。我早期犯过的错就是贪多一天塞二十条结果读者反馈看不过来跟没看一样。后来砍到每天8到12条每条控制在150字以内反而打开率上去了。关键词这块我单独说一下。每期日报会挂几个标签比如这期的HackerNews、AI、LLM、Agent、GLM。标签不是随便打的它承担两个功能一是让读者快速判断这期有没有自己关心的方向二是方便后续做归档检索。我自己的知识库里就是按标签建的索引比如想回顾Agent安全相关的所有内容直接搜标签就能拉出一串。标签的选择标准是具体且可复用像AI这种太泛的标签只作为兜底真正有用的是Agent安全LLM网关GLM接入这种能定位到具体技术点的词。2. HackerNews精选的选题与拆解方法2.1 什么样的帖子值得进日报HackerNews每天首页的帖子大概有几十个但真正值得放进日报的我按三个维度筛技术新颖度、讨论质量、落地相关性。技术新颖度好理解就是这东西是不是最近才出现的或者是不是一个老问题的新解法。讨论质量看评论区HN的评论区有时候比正文还有价值尤其是那些有实战经验的人在里面补充细节、指出坑点。落地相关性则是判断这个帖子对实际做项目有没有参考意义纯理论探讨除非特别有启发性否则一般不放。举个具体的例子。这期日报里有一条是关于LLM Wiki项目的就是Karpathy之前提过的那个用LLM自动整理个人知识库的想法。这个帖子在HN上讨论很热因为它触及了一个真实痛点我们每天读的东西太多但真正内化成自己知识体系的太少。LLM Wiki的思路是用大模型做知识蒸馏把零散的笔记、文章、代码片段自动归类、摘要、建立关联。这个选题就同时满足三个维度——新颖LLM的新应用场景、讨论质量高评论区有人分享了实际搭建经验、落地相关任何做知识管理的人都能用。再比如Agent安全那条A-MemGuard那个框架。Agent现在很火但安全问题一直是悬在头上的剑。这个框架提出了一种主动防御的思路针对的是Agent记忆模块被污染或攻击的场景。这种选题的价值在于它指出了一个很多人还没意识到的问题——大家忙着搭Agent但很少有人认真想Agent的记忆如果被恶意注入会怎样。这种提前预警型的内容在日报里权重会给高一些。2.2 从标题到摘要的压缩技巧HN的帖子标题往往很简洁有时候甚至有点晦涩。日报里不能只放标题得补一段摘要说清楚这东西是什么、解决了什么问题。这段摘要的写法有讲究我总结了一个三句话模板第一句说是什么项目/论文/工具的名称和基本定位第二句说为什么重要它针对的痛点或它带来的新可能第三句说怎么用/怎么参与开源地址、使用方式、讨论入口。以GLM相关的条目为例。如果只写GLM大模型官网更新读者不知道更新了什么。补上摘要就变成GLM发布新版本重点提升了代码生成和Agent任务规划能力。对国内开发者来说GLM是目前接入成本较低的选择之一配合Claude Code for VSCode插件可以直接在编辑器里调用。官网已开放API申请。这样三句话下来读者就知道要不要点进去看了。注意摘要里不要堆术语。我见过一些日报写基于Transformer架构的端到端多模态对齐方案这种写法除了显得专业没有任何用。换成一个能同时处理文字和图片的模型训练方式让它在两种输入之间建立关联读者立刻能懂。2.3 评论区淘金的具体操作HN的评论区是我花时间最多的地方。一个帖子正文可能就几百字但评论区能有两三百条里面藏着大量实战经验。我的做法是先用浏览器的查找功能搜几个关键词比如productionscalepitfallactually这些词往往出现在有实质内容的评论里。然后重点看那些被顶到前面的评论以及那些有回复讨论的评论。这期日报里关于Agent execution terminated due to error的排查技巧就是从一条评论里挖出来的。原帖是一个开发者抱怨自己的Agent跑着跑着就挂了报错信息很模糊。评论区有人指出这类错误八成是工具调用的payload格式不对尤其是当Agent调用的工具返回了非结构化数据时模型解析不了就会直接终止。这个经验后来被我写进了日报的常见问题板块很多读者反馈说帮他们省了几个小时的排查时间。3. 全球热点速递的覆盖范围与取舍3.1 热点速递和HN精选的分工HackerNews精选偏技术社区视角关注的是技术人在讨论什么。全球热点速递则更宽一些覆盖产品发布、行业动态、政策变化、有意思的应用案例。两者的分工是HN精选解决深度热点速递解决广度。比如这期热点速递里有一条是关于教别人用AI赚翻了的现象讨论这不是技术帖但它反映了一个真实趋势——AI技能的变现路径正在从做产品扩展到做教育。这种内容放在HN精选里不合适但放在热点速递里就刚好。热点速递的选题标准比HN精选松一些但有一条底线必须和AI或技术沾边。纯粹的商业新闻、娱乐八卦不放。另外热点速递的条目一般比HN精选短每条控制在100字左右因为它的作用是告知而不是解读。3.2 热词背后的趋势判断每期日报的关键词列表其实是一个趋势观察窗口。把这期的热词拉出来看ai、llm、agent、glm、claudecodeforvscode接入glm、llm wiki、agent安全、a-memguard……能看出几条线索。第一Agent已经从概念讨论进入工程实践阶段热词里出现了agent execution terminated due to error这种具体的报错信息说明真的有人在跑Agent并且遇到了问题。第二GLM的生态在扩张claudecodeforvscode接入glm和trea claude插件配置智谱glm这两个词说明开发者正在把GLM接入各种工具链。第三LLM Wiki和A-MemGuard这两个词指向同一个方向——LLM的知识管理和记忆机制正在成为新的关注点。这种趋势判断不一定每期都写进日报但它会影响我选条的偏好。比如这期我特意多放了两条和Agent记忆、Agent安全相关的内容就是因为从热词里看到了这个方向的升温。3.3 热点速递的排版与阅读节奏热点速递的排版我试过几种方案最后定下来的是短段落加粗关键词的形式。每条热点用两三句话说完关键信息加粗读者扫一眼就能抓住重点。比如GLM大模型官网更新了API文档新增了Agent任务规划相关的接口说明接入Claude Code for VSCode的配置步骤也做了简化。LLM Wiki项目在GitHub上开源了核心代码支持用本地模型做知识库的自动整理和关联适合有隐私需求的个人用户。这种排版的好处是阅读节奏快适合早上通勤时快速浏览。缺点是深度不够所以重要的条目会在HN精选里再展开一次。4. 日报生产的完整流程与工具链4.1 信息源的配置与自动化采集我的信息源分三层。第一层是必看源包括HackerNews首页、几个大模型厂商的官方博客、GitHub Trending的AI分类。这些源每天固定时间抓一次用RSS加过滤规则。第二层是补充源包括技术社区的热榜、几个高质量的技术周刊、以及一些活跃开发者的社交账号。这些源不固定抓取但会在日报生产时手动扫一遍。第三层是线索源主要是读者投稿和评论区反馈这部分量不大但往往有独家信息。自动化采集这块我用的是自己写的一个小脚本核心逻辑是抓取RSS、去重、按关键词打标签、存入本地数据库。去重很重要因为同一个新闻往往在多个源出现不去重的话日报会显得很重复。打标签的规则是预设一个关键词表比如agentllmglm安全这些命中就自动打上。这个脚本不复杂一百多行Python但省了我每天至少半小时的手动整理时间。# 简化的RSS采集与去重逻辑 import feedparser import hashlib from datetime import datetime def fetch_and_dedupe(feed_urls, seen_hashes): entries [] for url in feed_urls: feed feedparser.parse(url) for entry in feed.entries: # 用标题链接生成唯一标识 uid hashlib.md5( (entry.title entry.link).encode() ).hexdigest() if uid not in seen_hashes: seen_hashes.add(uid) entries.append({ title: entry.title, link: entry.link, summary: entry.get(summary, ), published: entry.get(published, ), source: url }) return entries提示去重不能只用标题因为同一个事件不同媒体的标题可能不一样。我的做法是标题和链接一起做哈希链接相同的一定是重复的标题相同但链接不同的保留人工判断。4.2 人工筛选与摘要撰写的时间分配自动化采集之后是人工筛选。我给自己定了一个时间盒筛选15分钟摘要撰写40分钟排版10分钟总共65分钟。筛选阶段就是快速过一遍采集到的条目按前面说的三个维度打分选出8到12条。摘要撰写是最花时间的因为要压缩信息又不能丢关键点。我的做法是先给每条写一个一句话版本然后再扩成三句话。一句话版本是给自己看的确保我理解了这条内容的核心三句话版本是给读者看的确保读者能快速判断要不要深入了解。排版阶段主要是调整顺序和加标签。顺序上HN精选放在前面热点速递放在后面因为HN精选更需要专注阅读。标签加在每条末尾用方括号括起来比如[Agent]、[LLM]、[GLM]。这样读者搜索的时候可以直接搜标签。4.3 发布渠道与反馈收集日报的发布渠道我试过几个最后保留的是两个一个技术社区的长文帖和一个邮件列表。技术社区的长文帖适合公开讨论读者会在评论区补充信息或者指出错误。邮件列表适合深度读者打开率比社区帖高不少。两个渠道的内容基本一致但邮件列表会多一段编辑手记写我当天选条时的思考比如为什么某条看起来不起眼的内容我给了高权重。反馈收集主要看三个指标打开率、评论数、转发数。打开率低说明标题或摘要没吸引力评论数少说明内容没有讨论点转发数低说明内容不够有用。这三个指标里我最看重转发数因为转发意味着读者觉得这东西值得分享给别人是有用的最直接信号。5. 常见问题与排查技巧实录5.1 信息源失效与替代方案做日报最常遇到的问题就是信息源失效。RSS停更、网站改版、API限额这些都会打乱采集流程。我的应对策略是每个必看源都准备一个备选源。比如HackerNews的RSS如果挂了就用它的API某个厂商博客如果不再更新RSS就用网页监控工具盯着更新页面。备选源平时不用但主源出问题的时候能立刻顶上。另一个问题是信息源的质量波动。有些源平时质量不错但偶尔会连续几天发一些低质内容。这种情况我的做法是临时降权而不是直接移除。降权就是同样的内容从这些源来的条目在筛选时打分低一些除非特别突出否则不选。观察一两周如果质量恢复就恢复正常权重如果持续低质就考虑移除。5.2 摘要写得太长或太短的调整摘要长度失控是新手常犯的错。写得太长日报变得臃肿读者没耐心看完写得太短信息量不够读者不知道这条到底讲了什么。我的经验值是HN精选每条摘要120到180字热点速递每条80到120字。这个长度能容纳是什么为什么重要怎么参与三句话又不至于让读者觉得在读长文。如果摘要超了优先砍的是背景介绍和形容词。比如这是一个非常有意思的、由社区驱动的、专注于Agent安全的开源框架砍成一个社区驱动的Agent安全开源框架。如果摘要太短补的是具体细节。比如GLM更新了补成GLM更新了API文档新增Agent任务规划接口接入VSCode插件的配置步骤做了简化。5.3 读者反馈的典型问题与处理读者反馈里最常见的是这条为什么放进来。有时候我觉得某条很重要但读者觉得无关。这种情况我会在下一期的编辑手记里解释选条理由如果多人反馈同一条无关下次就不选这类内容。另一种反馈是这条漏了读者觉得某个重要新闻我没放。这种反馈很有价值我会检查是不是信息源没覆盖到如果是就补充信息源。还有一种反馈是摘要写错了。技术类内容很容易出现细节错误比如把模型版本号写错、把功能描述得不准确。这种反馈我会第一时间核实并更正同时在下一期日报里加一个更正板块说明上期哪里错了、正确的信息是什么。这个做法一开始有人觉得没必要但后来发现它反而增加了读者信任——大家知道这个日报是认真核实的不是随便抄的。常见问题排查思路解决方法信息源RSS失效检查源地址是否变更、是否停止更新切换到备选源或使用网页监控摘要长度失控统计字数对比目标区间超长砍背景和形容词过短补具体细节读者反馈选条不当看反馈人数和具体理由单人反馈在编辑手记解释多人反馈调整选条标准摘要细节错误核实原始来源下期加更正板块说明错误和正确信息采集脚本报错看日志定位是网络问题还是解析问题网络问题加重试解析问题更新解析规则5.4 独家避坑技巧做了这么久日报有几个坑是我踩过之后才明白的。第一个坑是不要追求每日必更。早期我给自己定死规矩每天必须发结果有几天实在没什么值得放的内容硬凑了几条低质的读者立刻反馈质量下降。后来改成有则发无则停反而口碑更好了。日报的价值在筛选不在数量。第二个坑是不要只盯着大厂。大厂的发布当然重要但很多有意思的东西来自个人开发者和中小团队。这期日报里LLM Wiki和A-MemGuard都是个人或小团队的项目但讨论热度不比大厂发布低。我的信息源里专门有一类是小团队和个人的博客、GitHub仓库这部分往往能挖到独家内容。第三个坑是不要忽略负面信息。报错、失败案例、被弃用的项目这些看起来不正能量但对读者很有价值。比如Agent execution terminated due to error这条它不是一个成功案例但它帮读者避开了同样的坑。日报里适当放一些踩坑记录读者的反馈往往比成功案例更热烈。6. 从日报到个人知识库的延伸日报做完之后内容不应该就散了。我的做法是把每期日报的内容归档到个人知识库里按标签建索引。具体来说每条内容提取三个要素核心概念、相关工具/项目、关键结论。这三个要素存入知识库打上标签。时间长了知识库就变成一个可检索的领域地图。比如想查Agent安全相关的所有内容搜标签就能拉出一串从最早的A-MemGuard到后来的各种讨论脉络很清楚。这个知识库还有一个用法是做趋势对比。比如GLM这个标签从最早出现到现在内容的变化能看出它的生态是怎么一步步扩大的。最开始只是模型发布后来是API开放再后来是各种工具链接入最近是Agent任务规划能力的增强。这种纵向对比单看某一期日报是看不出来的但知识库能把它串起来。提示知识库的标签体系不要建得太细。我一开始建了上百个标签结果维护成本太高很多标签只用了一两次。后来精简到三十个左右的核心标签加上一些临时标签反而更好用。核心标签是长期稳定的方向临时标签是短期热点用完就归档。最后分享一个我最近在试的做法用LLM辅助做日报的初筛。具体来说把采集到的条目批量喂给一个本地模型让它按技术新颖度、讨论质量、落地相关性三个维度打分我只需要复核高分和低分的条目中间段的快速扫过。这个做法还在试验阶段目前看能省大概20%的筛选时间但模型的判断有时候会偏比如它容易高估那些标题里有热门关键词但内容空洞的条目。所以我的用法是模型初筛人工复核而不是完全交给模型。这个日报栏目做到现在最大的体会是筛选比采集难判断比信息重要。信息到处都是但知道什么值得看、什么可以跳过这个能力需要时间积累。每期日报的选条过程其实也是我自己在训练这个判断力的过程。读者的反馈、评论区的讨论、知识库的纵向对比都在帮我修正判断。这大概就是做日报这件事除了帮别人省时间之外对我自己的另一层价值。