1. 一份日报背后的信息筛选逻辑做科技资讯日报这件事我从2023年就开始折腾了。最开始是给自己看的每天早上花半小时刷一圈HackerNews、几个大模型厂商的更新页、还有几个技术社区的热帖把值得记的东西丢进一个Markdown文件里。后来有朋友说你这东西整理得还行干脆发出来吧于是就有了现在这个「科技AI资讯日报」的固定栏目。到2026年9月这个时间节点整个AI圈的信息密度已经到了一个人根本刷不完的程度——光HackerNews首页一天就有上百条新帖再加上各家大模型厂商的更新、Agent框架的迭代、开源项目的冒头如果没有一套筛选和编排的方法论做出来的日报要么是流水账要么就是漏掉了真正重要的东西。这份日报的定位很明确给一线开发者和技术决策者看的每日信息快照。它不是给投资人看的行业分析也不是给小白看的科普合集而是假设读者已经对LLM、Agent、大模型生态有基本认知需要的是“今天发生了什么值得我花五分钟知道的事”。所以选材标准就三条第一有实质性的技术更新或产品发布不是PR稿第二在HackerNews或技术社区引发了真实讨论不是自嗨第三对国内开发者有参考价值哪怕是国外的项目也要能对应到国内的使用场景。关键词里出现的HackerNews、AI、LLM、Agent、GLM这几个词基本覆盖了这份日报的核心内容板块。HackerNews是信息源AI和LLM是领域标签Agent是当前最热的技术方向GLM则是国内大模型生态里绕不开的一个名字。把这几个词串起来就是一份日报的骨架从HackerNews精选全球技术热点聚焦LLM和Agent方向的前沿动态同时关注GLM等国内大模型的落地进展。做日报最忌讳的是“什么都放”。我试过一段时间每天塞十几条结果读者反馈说看不过来自己也累得半死。后来砍到每天5到8条核心资讯每条配一段自己的解读反而口碑上来了。信息筛选的本质是做减法不是做加法。2. 日报内容架构与选题标准拆解2.1 为什么是HackerNews打底HackerNews在技术资讯圈的地位不用多解释但用它做日报信息源有几个坑得提前说清楚。第一HN的投票机制会导致某些话题被过度放大比如某个编程语言的小更新可能因为踩中了社区情绪而冲上首页但实际技术价值有限。第二HN的评论区往往比原文更有价值很多一线工程师会在评论里分享自己的实操经验这些内容如果不看就浪费了。第三HN的时效性很强但有些帖子是“旧闻新发”需要判断是不是真的值得收录。我的做法是每天早上先扫一遍HN首页前30条用关键词过滤LLM、Agent、model、inference、training、open source等把明显不相关的比如纯前端框架更新、硬件评测先排除。剩下的逐条看评论区如果评论区有超过20条实质性讨论就标记为候选。然后再看原文链接判断是产品发布、技术博客、论文还是开源项目。最后按“对国内开发者的参考价值”排序取前3到5条。这个流程听起来简单但实际操作中最大的挑战是判断一条资讯的“半衰期”。有些新闻当天很热但一周后就没人记得了有些看起来不起眼但可能是某个技术方向的转折点。我的经验是如果一个项目在HN上连续两天都有讨论或者评论区出现了多个不同公司的工程师在交流实现细节那这条资讯就值得重点收录。2.2 Agent方向为什么单独成块2026年的AI圈Agent已经从“概念验证”阶段进入了“工程化落地”阶段。关键词里出现的agent开发、agent框架、agent安全、agent项目、吴恩达 agent 教程、pi agent、hermes agent、agent智能体、agent框架与编排这些词反映了一个现实Agent不再是单一技术点而是一个完整的工程体系。所以在日报里Agent方向的内容我会单独成块通常包含三类信息第一类是框架和工具的更新比如某个Agent框架发布了新版本支持了新的编排能力第二类是安全相关的进展比如a-memguard这类针对LLM Agent记忆系统的防御框架第三类是实操教程和案例比如吴恩达的Agent教程更新、某个团队分享的Agent项目落地经验。为什么要把Agent单独拎出来因为Agent的开发范式和传统的LLM应用有本质区别。传统LLM应用是“输入-输出”的线性模式而Agent是“感知-规划-行动-反思”的循环模式涉及记忆管理、工具调用、多步推理、错误恢复等一系列工程问题。这些问题在传统LLM开发中不存在或者不是核心矛盾。所以Agent方向的资讯需要单独归类方便读者快速定位。2.3 GLM和国内大模型的报道角度关键词里GLM出现的频率很高包括glm、glm大模型官网、claudecodeforvscode接入glm、trea claude插件配置智谱glm。这说明国内开发者对GLM的关注度在持续上升尤其是GLM与主流开发工具的集成场景。在日报里报道GLM相关的资讯我会特别注意两个角度第一是能力更新比如GLM发布了新版本、在某个基准测试上取得了什么成绩、支持了哪些新功能第二是生态集成比如GLM接入了哪些开发工具、有哪些开源项目开始默认支持GLM、社区里有哪些基于GLM的实践案例。第二个角度往往比第一个更有价值因为能力更新是厂商自己说的而生态集成是开发者用脚投票的结果。报道国内大模型有一个原则不吹不黑用事实说话。参数、基准测试、实际体验这三者要分开说。参数是厂商公布的基准测试是实验室环境下的实际体验才是开发者真正关心的。日报里我会尽量把这三者区分清楚避免读者被单一维度的信息误导。3. 从热词看当前AI技术栈的演进方向3.1 LLM基础设施层的分化关键词里有一组词很值得玩味llm、llm wiki知识库、llm框架、llm ontology、llm模型、llm驱动的公立医院债务风险智能预警与化解策略研究、llm网关、llm request failed: provider rejected the request schema or tool payload、llm是否属于深度学习、llm大语言模型、llm powered autonomous agents、karpathy llm wiki、llm wiki项目、llm wiki 原文。这组词反映了一个趋势LLM的基础设施层正在快速分化。两年前大家聊LLM聊的是模型本身——参数多大、效果多好、训练成本多高。现在聊LLM聊的是围绕模型的一整套工程体系怎么管理知识库llm wiki、怎么做模型路由llm网关、怎么定义领域本体llm ontology、怎么处理请求失败provider rejected the request schema or tool payload。这种分化是技术成熟的标志。当一个技术从“能不能用”进入“怎么用好”的阶段基础设施层就会开始细化。llm wiki这类项目的出现说明开发者不再满足于把文档丢给模型做RAG而是希望有一套更结构化的知识管理方案。llm网关的流行说明多模型切换已经成为常态开发者需要一个统一的入口来管理不同厂商的API。Karpathy的llm wiki项目在社区里引发了大量讨论这个项目的核心思路是用wiki的方式组织LLM相关的知识让开发者可以像查百科一样查找LLM的概念、工具、实践。这种“知识结构化”的需求恰恰是LLM应用进入深水区后的必然产物。3.2 Agent工程化的三个关键问题从关键词里的agent execution terminated due to error、agent安全、a-memguard: a proactive defense framework for llm-based agent memory、agent框架与编排、agent项目、agent智能体这些词来看Agent的工程化落地正在围绕三个关键问题展开。第一个问题是执行可靠性。agent execution terminated due to error这个错误信息在开发者社区里出现的频率越来越高说明Agent在执行多步任务时错误处理和恢复机制还不够成熟。一个Agent任务可能涉及十几次工具调用任何一步出错都可能导致整个任务失败。怎么设计容错机制、怎么在失败后回滚、怎么给Agent提供清晰的错误反馈这些都是工程化必须解决的问题。第二个问题是记忆安全。a-memguard这个项目的出现很有代表性它针对的是LLM Agent记忆系统的安全问题。Agent在执行任务过程中会积累大量记忆这些记忆可能包含敏感信息、错误推理、甚至被恶意注入的内容。如果没有防御机制Agent可能会基于被污染的记忆做出错误决策。a-memguard的思路是主动防御在记忆写入和读取两个环节都做安全检查这个方向值得关注。第三个问题是编排复杂度。agent框架与编排这个词组说明多Agent协作已经成为实际需求。单个Agent的能力有边界复杂任务需要多个Agent分工协作。但多Agent系统的编排复杂度远高于单Agent涉及任务分配、通信协议、冲突解决、全局状态管理等一系列问题。目前这个领域还没有形成标准方案各种框架都在探索自己的路径。3.3 开发工具链的AI化改造关键词里ai编程、claudecodeforvscode接入glm、trea claude插件配置智谱glm、ai测试开发、ai辅助这些词指向的是另一个重要趋势开发工具链正在被AI全面改造。Claude Code for VS Code接入GLM这个场景很有意思。它说明两个事情第一AI编程助手已经从“可选插件”变成了“标配工具”第二国内大模型正在积极接入主流开发工具不再满足于只在自己的平台上提供服务。Trea Claude插件配置智谱GLM也是类似的逻辑开发者希望在自己习惯的工具里使用自己偏好的模型而不是被绑定在某个特定平台上。AI测试开发是另一个值得关注的方向。传统的软件测试依赖人工编写测试用例覆盖率有限且维护成本高。AI测试开发试图用LLM来生成测试用例、分析测试结果、甚至自动修复测试失败。这个方向目前还在早期但已经有一些团队在尝试了。工具链的AI化改造有一个隐性门槛上下文管理。AI编程助手需要理解项目的代码结构、依赖关系、编码规范才能给出有价值的建议。如果只是把代码片段丢给模型效果会大打折扣。所以接入GLM这类模型时怎么做好上下文注入和提示词工程比选哪个模型更重要。4. 日报制作中的实操细节与避坑经验4.1 信息源的优先级排序做日报最怕的是信息源太多导致每天花大量时间在“刷”上而不是在“整理”上。我现在的信息源优先级是这样的优先级信息源用途每日耗时P0HackerNews首页全球技术热点15分钟P0主要大模型厂商更新页模型能力更新10分钟P1技术社区热帖开发者实践讨论10分钟P1开源项目趋势榜新项目发现5分钟P2行业媒体补充背景信息5分钟P0级别的信息源是每天必看的P1级别是选择性看P2级别是偶尔看。这个优先级不是固定的比如某个大模型厂商要开发布会那它的更新页就会临时升到P0。但整体框架不变避免每天被信息流牵着走。4.2 每条资讯的解读怎么写日报里的每条资讯我不会只放一个链接和标题而是会配一段自己的解读。这段解读通常包含三个部分是什么、为什么重要、对读者有什么用。“是什么”部分用一两句话概括核心信息不堆砌细节。“为什么重要”部分解释这条资讯在技术演进中的位置比如它是解决了某个长期存在的问题还是开辟了一个新方向。“对读者有什么用”部分给出具体的行动建议比如“如果你在用某个框架可以关注这个更新”“这个项目的思路可以借鉴到你的Agent项目里”。这三部分的比例大概是2:3:5重点放在“对读者有什么用”上。因为读者看日报的时间有限他们最关心的是“这条资讯跟我有什么关系”。4.3 常见问题与排查技巧做日报这几年踩过的坑不少这里整理几个典型问题问题一资讯时效性判断失误。有时候早上看到一条新闻觉得很重要就收录了结果下午就被辟谣或者出现了反转。解决办法是对于重大新闻先标记为“待确认”等半天后再决定是否收录。如果日报是早上发那就只收录前一天已经确认的信息。问题二解读过于主观。早期我写解读时喜欢加很多个人判断比如“这个项目肯定能火”“这个方向没前途”。后来发现这种判断经常被打脸而且会误导读者。现在的做法是只陈述事实和逻辑把判断留给读者。如果一定要给观点就明确标注“个人看法”。问题三格式不统一。日报的格式如果不统一读者阅读成本会很高。我的做法是固定模板每条资讯包含标题、来源链接、一句话摘要、解读段落。解读段落的长度控制在150到300字之间太短说不清楚太长读者没耐心看。问题四遗漏重要信息。有时候因为早上时间紧漏掉了某个重要更新读者会在评论区指出来。解决办法是建立一个“补录”机制如果当天有重要信息遗漏第二天日报开头会补上。同时把读者的反馈整理成关键词库下次筛选时重点关注。做日报有一个心得不要追求每天都有大新闻。AI圈不是每天都有颠覆性进展的大部分日子都是小步迭代。如果为了凑内容而把不重要的事情放大反而会降低日报的可信度。宁可某天只有三条资讯也不要塞五条水货。5. 从资讯到行动读者如何用好这份日报5.1 建立自己的信息处理流程日报只是一个信息入口真正有价值的是读者自己的信息处理流程。我建议读者可以这样操作每天早上花10分钟扫一遍日报把感兴趣的条目标记出来中午花15分钟深入阅读标记的条目看看原文和评论区晚上花5分钟记录一下今天学到的东西哪怕只是一句话。这个流程的关键是不要试图看完所有内容。日报里可能有一半的内容跟你的工作不直接相关跳过它们不是损失而是节省时间。真正重要的是找到那几条跟你当前项目或学习方向相关的资讯深入下去。5.2 从资讯中提取可复用的模式看资讯不能只看表面要学会提取背后的模式。比如看到某个Agent框架发布了新版本不要只看它增加了什么功能还要想它为什么增加这个功能这个功能解决了什么痛点这个痛点在我的项目里存在吗如果存在我能不能借鉴它的思路再比如看到a-memguard这样的安全框架不要只把它当成一个工具还要理解它的设计思路为什么要在记忆写入和读取两个环节都做检查这种“双层防御”的思路能不能用到其他场景这种模式提取的能力比记住具体的技术细节更重要。5.3 参与社区讨论的正确姿势HackerNews的评论区是一个很好的学习场所但参与讨论需要技巧。我的经验是先看再问先搜再答。看到一个问题先翻翻评论区有没有人已经问过再搜搜有没有相关的讨论。如果确实没有再提问。提问时要具体不要问“这个项目怎么样”这种宽泛的问题而是问“这个项目在处理XX场景时是怎么做的”。回答问题时要谨慎只回答自己真正实践过的内容。如果只是看过文档没有实操就明确说“根据文档应该是这样但我没有实际验证过”。这种诚实的态度在技术社区里反而更受尊重。6. 工具选型与自动化辅助6.1 日报制作工具链目前我的日报制作工具链比较简单用Feedly做RSS订阅管理用Notion做素材收集和草稿撰写用Markdown做最终排版。Feedly的好处是可以把多个信息源聚合在一起按关键词过滤。Notion的好处是支持多人协作和版本管理方便回溯。自动化方面我用了一个简单的Python脚本做初步筛选。脚本会抓取HN首页的帖子用关键词列表过滤把候选帖子输出到一个CSV文件里。然后我手动从这个CSV里挑选最终收录的条目。这个脚本大概50行代码用requests和BeautifulSoup就能实现不需要复杂的框架。import requests from bs4 import BeautifulSoup def fetch_hn_top(): url https://news.ycombinator.com/ resp requests.get(url, timeout10) soup BeautifulSoup(resp.text, html.parser) items [] for item in soup.select(.athing): title_el item.select_one(.titleline a) if title_el: items.append({ title: title_el.text, link: title_el.get(href, ) }) return items keywords [LLM, Agent, model, inference, open source, GLM] candidates [i for i in fetch_hn_top() if any(k.lower() in i[title].lower() for k in keywords)] for c in candidates: print(c[title], c[link])这个脚本的过滤逻辑很简单就是标题里包含关键词就保留。实际使用中我会根据当天的信息密度调整关键词列表。比如某天Agent相关的帖子特别多我就会把Agent相关的关键词细化避免遗漏重要内容。6.2 大模型辅助筛选的尝试我也试过用LLM来辅助筛选资讯。具体做法是把HN首页的帖子标题和摘要喂给模型让它判断哪些跟LLM、Agent相关并给出相关性评分。实测下来模型在“相关性判断”上表现不错但在“重要性判断”上还差得远。它会把一些标题党或者旧闻新发的帖子评为高分而漏掉一些标题不起眼但内容扎实的帖子。所以目前的方案是模型做初筛人工做终审。模型负责把明显不相关的帖子过滤掉人工负责从剩下的帖子里挑选真正有价值的。这个分工比较合理既利用了模型的效率又保留了人的判断力。用LLM辅助筛选有一个坑模型的偏好和你的偏好可能不一致。比如模型可能更关注“新模型发布”这类新闻而你可能更关注“工程实践”类的帖子。解决办法是在提示词里明确你的偏好比如“优先选择有实际代码示例的帖子”“优先选择讨论工程问题的帖子”。提示词越具体筛选结果越符合预期。6.3 排版与发布的自动化日报的排版目前还是手动做的因为Markdown格式比较简单手动排版反而比写脚本更快。发布渠道主要是技术社区和个人博客两边的内容一样只是格式略有调整。技术社区支持Markdown直接粘贴个人博客用的是静态站点生成器需要把Markdown文件放到指定目录。未来如果日报的篇幅继续增加可能会考虑用脚本自动生成部分内容比如“今日热词”板块可以用脚本从资讯标题里提取高频词。但核心的解读部分还是得手动写因为这是日报的价值所在自动化不了。7. 一些个人体会做日报这件事最大的收获不是“知道了多少新闻”而是建立了一套自己的信息处理框架。这套框架包括怎么筛选信息源、怎么判断信息价值、怎么组织信息结构、怎么呈现给读者。这套框架不仅适用于做日报也适用于日常的技术学习和项目决策。另一个体会是坚持比质量更重要。日报这种东西偶尔出一期高质量的很容易难的是每天都能保持稳定的质量。我的做法是把日报制作流程标准化降低每期的决策成本。比如固定模板、固定信息源、固定筛选标准这样即使某天状态不好也能保证基本质量。最后说一个具体的技巧建立自己的关键词库。我会把读者反馈、社区讨论、自己的观察整理成一个关键词库每次筛选资讯时都会参考这个库。这个库是动态更新的比如最近Agent安全相关的讨论多了我就会把“agent安全”“memory defense”这些词加进去。关键词库越丰富筛选的准确率越高。这个日报项目后续还可以扩展的方向包括增加视频版、增加深度分析专栏、增加读者投稿板块。但这些都是后话先把每天的日报做好比什么都重要。