1. 一份 AI 日报的诞生从信息洪流到每日必读每天早上八点我的手机里会准时弹出一份自己做的 AI 日报。它不是那种从新闻网站复制粘贴的流水账而是一份经过筛选、验证、拆解和重新组织的行业情报。2026 年 9 月 25 日这一期是我连续更新的第 400 多期也是我踩了无数坑之后把流程打磨到相对顺手的一期。如果你也在做类似的信息聚合项目或者想给自己团队做一份内部技术简报那这套东西可以直接拿去用。先说清楚这份日报到底解决什么问题。AI 领域的信息密度极高每天醒来就有几十条所谓的“重磅发布”“颠覆性突破”“行业地震”。但真正值得关注的可能只有三到五条。剩下的要么是融资 PR要么是论文预印本的过度包装要么是同一件事被不同媒体反复翻炒。一份好的日报核心价值不在于“全”而在于“筛”——把噪音去掉把信号留下并且告诉你这个信号为什么重要、跟昨天的那条有什么关系、对你可能意味着什么。这份日报的读者画像很明确AI 方向的产品经理、算法工程师、技术负责人以及需要快速了解行业动态但没时间刷几十个信息源的投资人和创业者。它不追求学术深度也不做长篇大论的分析而是用最短的篇幅把一件事讲清楚发生了什么、关键细节是什么、我的判断是什么。每一条控制在 150 到 300 字之间整份日报阅读时间不超过 8 分钟。我试过很多种形式从最早的纯链接列表到后来的长文综述再到现在的“标题 核心事实 一句话点评”结构。最终稳定下来的这套模板是在阅读完成率、信息留存率和制作耗时三个维度上平衡得最好的。下面我把整个项目的设计思路、技术选型、实操流程和踩坑经验全部拆开讲。2. 整体设计与思路拆解为什么是现在这个形态2.1 从“信息搬运”到“信息加工”的定位转变最早做日报的时候我的做法很简单早上花半小时刷一圈信息源把看起来重要的链接复制到一个文档里加个日期就发出去。结果就是读者反馈“信息量太大不知道重点在哪”我自己也觉得没什么价值——因为读者自己也能刷到这些链接我做的事情只是帮他们省了几次点击这个价值太薄了。后来我意识到日报的核心竞争力不在于“我比你先看到”而在于“我比你想得深一步”。同样一条“某公司发布新模型”的消息普通搬运工只会写“某公司今天发布了 X 模型参数规模 Y在 Z 基准上得分 W”。但我会多问几个问题这个模型跟三个月前那版比真正的改进在哪是数据质量提升了还是训练方法变了它在实际场景中的表现有没有第三方验证发布时机有没有什么讲究把这些想清楚写出来的东西才有“加工”的痕迹读者才会觉得“看你的日报比自己刷省时间”。这个定位转变直接影响了后面的所有设计。信息源的选择上我不再追求“覆盖所有媒体”而是精选那些有一手信息或者有独立判断的源头。筛选标准上我不再按“热度”排序而是按“信息增量”排序——一条消息如果只是重复已知事实哪怕全网都在转我也不收。写作方式上我不再追求客观中立而是明确给出自己的判断和理由哪怕这个判断后来被证明是错的读者也能从中看到思考过程。2.2 日报的模块化结构设计现在这份日报的固定结构是四个板块头条深挖、快讯速览、论文精选、工具推荐。每个板块的定位和写作要求都不一样。头条深挖每天只选一条通常是当天信息增量最大、影响面最广的事件。这一条我会花最多时间不仅写清楚事实还要补充背景、分析影响、给出判断。篇幅在 400 到 600 字之间相当于一篇微型分析文章。快讯速览是 5 到 8 条短消息每条 100 到 150 字只讲核心事实和一句话点评不做展开。论文精选通常选 1 到 2 篇值得关注的预印本重点讲清楚它解决了什么问题、方法有什么新意、跟已有工作比进步在哪。工具推荐则是介绍一个最近发现的好用工具或开源项目偏实操向。这个结构不是拍脑袋定的而是根据读者反馈迭代出来的。最早我试过“全部长文”模式结果制作耗时太长经常断更。后来试过“全部短讯”模式读者又觉得太浅没有深度内容。现在的混合结构既保证了每天有“硬菜”又有足够的“配菜”让整份日报显得丰满。制作时间控制在 90 分钟左右可持续性比较好。2.3 技术选型为什么不用全自动方案很多人问我为什么不搞全自动抓取加 AI 摘要。我试过而且试了不止一次。结论是全自动方案在“筛选”和“判断”这两个环节上目前还达不到可用的水平。抓取环节确实可以自动化RSS、API、网页监控都能做。但筛选环节就麻烦了。AI 摘要工具分不清“某公司发布新模型”和“某公司发布新模型但第三方复现发现性能远低于宣传”之间的本质区别前者是 PR后者才是新闻。它也不知道一条消息在行业脉络中的位置——比如某个技术路线三年前被证明走不通现在有人换个名字重新包装AI 摘要只会照搬原文的乐观表述。判断环节就更难自动化了。写点评需要结合行业背景、技术趋势、竞争格局来做综合判断这恰恰是当前 AI 最不擅长的部分。我试过让 AI 写点评出来的东西全是“这一进展标志着该领域的重要突破”“有望推动行业进一步发展”之类的废话没有任何信息增量。所以现在的方案是“半自动”抓取和初步分类用脚本完成筛选和写作全部人工。脚本每天早上六点跑一次把过去 24 小时的信息源更新抓下来按关键词做初步分类生成一个候选列表。我七点开始人工过一遍选出真正值得写的条目然后逐条写作。这个流程既保证了效率又保留了人工判断的核心价值。3. 核心细节解析与实操要点每条日报是怎么写出来的3.1 信息源的筛选与维护信息源的质量直接决定日报的质量。我目前维护着大约 40 个信息源分为四类官方发布渠道、行业媒体、个人博主、学术预印本平台。官方发布渠道包括主要 AI 公司的博客和公告页。这类源的价值在于一手信息但缺点是更新频率不稳定而且内容偏 PR 向需要交叉验证。行业媒体我主要看三四家选择标准是“有独立采编能力不纯粹翻译外媒”。个人博主是我最看重的信息源因为他们的判断往往比媒体更敏锐而且愿意说一些媒体不方便说的话。学术预印本平台主要看最新上传的论文但只关注那些有开源代码或者有知名机构背书的。维护信息源是个持续工作。我每个月会做一次复盘看哪些源在过去一个月里提供了真正有价值的信息哪些源只是制造噪音。表现不好的源直接删掉同时补充新的候选源。这个“新陈代谢”机制很重要因为信息源的质量会随时间变化——有些博主一开始质量很高后来开始接广告或者转向其他领域就需要及时调整。注意不要贪多。我见过有人维护上百个信息源结果每天光浏览就花两小时真正写日报的时间反而没了。信息源在精不在多10 个高质量源远胜 50 个平庸源。3.2 筛选标准的量化与执行筛选是日报制作中最关键的环节。我给自己定了一套可执行的量化标准避免凭感觉做判断。第一条标准是“信息增量”。一条消息如果包含以下任意一项就算有增量新的事实之前没公开过的数据或细节、新的视角对已知事实的不同解读、新的关联把两件看似无关的事联系起来。如果一条消息只是重复已知事实哪怕它上了热搜我也不收。第二条标准是“影响半径”。我会问自己这条消息会影响多少人影响程度有多深比如某个开源工具更新了一个小版本只影响少数开发者那就不值得进日报。但如果这个更新改变了某个常用功能的行为可能影响大量项目那就值得写。第三条标准是“可验证性”。对于声称有突破性进展的消息我会优先选择那些有第三方验证或者有可复现代码的。纯 PR 稿如果没有其他信息源交叉验证我通常不写或者写的时候明确标注“未经独立验证”。这三条标准执行下来每天从候选列表里能选出的条目通常在 8 到 12 条之间刚好填满四个板块。如果某天候选特别少我会降低标准补充一些“值得关注但不算重磅”的内容。如果某天候选特别多我会提高标准只保留最核心的几条。3.3 写作风格的刻意练习日报的写作风格是“专业但不学术直接但不粗糙”。具体来说有几个刻意练习的点。第一每句话都要有信息量。我写完一条后会逐句检查如果某句话删掉之后读者不会损失任何信息那就删掉。比如“据悉”“据了解”“有消息称”这类词除非确实需要保护信源否则一律不用。第二用具体数字代替模糊表述。“性能大幅提升”不如“推理速度提升 40%”“很多用户反馈”不如“GitHub 上 200 多条 issue 提到这个问题”。数字让信息更可信也更容易被记住。第三点评要有立场。我要求自己每条快讯的点评必须包含一个明确的判断不能是“值得关注”“拭目以待”这种万能废话。判断可以是“这个方向大概率走不通”也可以是“这个做法很聪明可能会被广泛借鉴”但必须有观点。第四控制句子长度。移动端阅读场景下长句子是阅读体验的杀手。我尽量把每句话控制在 40 字以内超过就拆成两句。段落也尽量短每段不超过 4 行。4. 实操过程与核心环节实现2026 年 9 月 25 日这一期的完整记录4.1 早晨六点的自动抓取与初步分类早上六点脚本准时运行。这个脚本是我用 Python 写的核心逻辑很简单遍历配置好的信息源列表用 feedparser 解析 RSS用 requests 加 BeautifulSoup 抓取没有 RSS 的页面把过去 24 小时的新内容存到一个 JSON 文件里。import feedparser import requests from bs4 import BeautifulSoup from datetime import datetime, timedelta def fetch_rss(url): feed feedparser.parse(url) cutoff datetime.now() - timedelta(hours24) items [] for entry in feed.entries: published datetime(*entry.published_parsed[:6]) if published cutoff: items.append({ title: entry.title, link: entry.link, summary: entry.get(summary, ), source: feed.feed.title, published: published.isoformat() }) return items抓取完成后脚本会做一个初步分类。分类逻辑是基于关键词匹配如果标题或摘要里出现“模型”“发布”“开源”等词归入“产品技术”类出现“融资”“收购”“合作”等词归入“商业动态”类出现“论文”“研究”“实验”等词归入“学术研究”类。这个分类很粗糙但足够把候选列表从几百条压缩到几十条减轻人工筛选的负担。六点二十左右脚本跑完生成一个包含大约 60 到 80 条候选的列表。我会在手机上先扫一眼标题把明显不相关的比如纯营销内容、重复条目快速划掉剩下大约 30 条进入详细筛选。4.2 七点开始的人工筛选与深度阅读七点整我坐到电脑前打开候选列表开始逐条筛选。这个过程通常需要 30 到 40 分钟。筛选的第一步是“快速淘汰”。我会先看标题和来源如果标题里出现“震撼”“颠覆”“史上最强”这类词直接跳过——真正重要的消息不需要用形容词来证明自己。如果来源是我不熟悉的媒体而且没有其他信息源交叉验证也先跳过。第二步是“深度阅读”。对于保留下来的条目我会点开原文仔细读。读的时候带着几个问题核心事实是什么有没有数据支撑跟已知信息有什么冲突或补充有没有利益相关方没有披露这些问题帮助我快速判断一条消息的真实价值和潜在偏差。以 9 月 25 日这一期为例候选列表里有一条关于某开源模型发布新版本的消息。标题很普通没有夸张词汇来源是一个我长期关注的技术博客。点进去读完发现这个新版本的核心改进是训练数据配比的调整而不是模型架构的变化。这个细节很重要因为很多媒体报道时会笼统地说“模型升级”但实际改进点在哪里决定了这个升级对用户有没有意义。我决定把这条放进快讯并在点评里明确指出“改进来自数据侧而非架构侧对推理成本的影响有限”。4.3 八点开始的写作与编排八点开始正式写作。我通常先写头条深挖因为这条最耗时需要查背景资料和做分析。9 月 25 日的头条我选了一条关于某研究机构发布多模态推理基准的消息。选它的理由是多模态推理是当前的热点方向但一直缺乏统一的评估标准这个基准的发布可能会影响后续很多工作的评价方式。写头条的时候我会先列一个提纲事实是什么、背景是什么、关键细节有哪些、我的判断是什么。然后按这个提纲展开控制在 500 字左右。写完后我会放一放先去写快讯最后再回来改头条——隔一段时间再看更容易发现表述不清或者逻辑跳跃的地方。快讯的写作相对快一些每条 10 分钟左右。我会把最重要的信息放在第一句然后补充一两个关键细节最后加一句点评。点评尽量短一两句话说完不展开。论文精选和工具推荐通常放在最后写因为这两块相对独立不需要跟当天其他内容做太多关联。论文精选我会重点讲“这篇论文解决了什么问题”和“方法的新意在哪”避免陷入技术细节的堆砌。工具推荐则偏实操讲清楚“这个工具能做什么”“怎么用”“有什么坑”。4.4 九点半的终审与发布九点半左右初稿完成。我会花 15 分钟做终审检查几个东西事实有没有错误、表述有没有歧义、链接能不能打开、排版有没有问题。事实核查是最重要的我会对每条消息的关键数据做二次确认确保没有把“提升 40%”写成“提升 4 倍”这种低级错误。终审完成后我会把日报导出为 Markdown 格式通过邮件和即时通讯工具发给订阅者。同时会在个人博客上同步一份存档方便后续检索。5. 常见问题与排查技巧实录那些踩过的坑和总结的经验5.1 信息源突然失效怎么办信息源失效是家常便饭。RSS 地址变更、网站改版、博主停更都会导致抓取失败。我的做法是给每个信息源加一个“健康检查”机制如果连续三天没有抓到新内容脚本会发提醒给我让我手动检查是源本身停止更新了还是抓取规则需要调整。对于网站改版导致的抓取失败我通常不会花太多时间去修爬虫规则而是优先找有没有替代的 RSS 或者 API。如果实在没有就暂时把这个源标记为“手动检查”每天花两分钟人工看一眼。毕竟我的目标是获取信息不是维护爬虫。5.2 同一条消息被多个源报道怎么处理这种情况很常见尤其是重大发布。我的处理原则是优先采用一手源如果一手源信息不够详细再参考二手源的补充。但最终写进日报的内容必须是我自己核实过的不能直接复制任何一方的表述。如果不同源之间有矛盾比如一家说“性能提升 50%”另一家说“提升 30%”我会在日报里明确指出这个差异并说明可能的原因比如测试条件不同、基准选择不同。这种“矛盾本身也是信息”的处理方式读者反馈很好因为他们能看到不同角度的说法而不是被单一来源牵着走。5.3 写作时间不够怎么压缩有时候早上有急事只有一个小时写日报。这种情况下我会启动“精简模式”头条只写 300 字快讯减到 4 条论文和工具板块合并成一条。核心原则是“宁可少写不可乱写”——如果时间不够导致质量下降我宁愿少发几条也不发未经核实的内容。长期来看提高写作速度的关键是建立“素材库”。我平时会随手记录一些行业背景知识、常用数据、典型判断逻辑写日报的时候可以直接调用不用每次从头查起。这个素材库我维护了两年多现在写一条快讯的平均时间从最早的 20 分钟降到了 10 分钟左右。5.4 读者反馈怎么处理读者反馈是改进日报的重要输入。我会认真看每一条反馈但不会全部采纳。有些读者希望增加某个板块有些希望减少某类内容这些需求往往是矛盾的。我的做法是如果多个读者反映同一个问题就认真考虑调整如果只是个别读者的偏好就记录在案但不一定执行。最常见的反馈是“某条消息我觉得不重要为什么你选了”。这种反馈很有价值因为它让我看到自己的判断跟读者预期的差异。我会反思是我高估了这条消息的影响还是读者不了解背景所以觉得不重要如果是后者我会在后续的日报里补充更多背景信息帮助读者理解为什么某件事值得关注。5.5 常见问题速查表问题现象可能原因排查方法解决建议抓取脚本报错信息源改版或网络问题检查目标页面是否可访问更新抓取规则或暂时跳过该源候选列表为空RSS 地址失效或时间窗口设置错误手动访问源站确认是否有更新修正 RSS 地址或调整时间窗口日报发出后发现有事实错误核实不充分或来源本身有误回顾写作时的核实流程在下一期更正并说明建立更严格的双源核实机制写作时间超过预期头条选题过于复杂或资料查找耗时记录每个环节的实际耗时简化头条结构提前建立素材库读者反馈“信息量太大”快讯条数过多或单条过长统计阅读完成率减少快讯条数控制单条在 150 字以内6. 工具链与效率提升让日报制作可持续6.1 核心工具选型与配置整个日报制作涉及的工具不多但每个都经过仔细挑选。抓取环节用 Python 加 feedparser 和 BeautifulSoup这是最灵活的方案可以处理各种格式的信息源。数据存储用 SQLite轻量且不需要额外服务。写作和排版用 ObsidianMarkdown 原生支持而且有很好的标签和搜索功能方便后续检索历史内容。发布用 Buttondown 的 API支持 Markdown 邮件订阅管理也简单。我特意没有用 Notion 或类似的重型工具因为日报制作需要快速打开、快速编辑、快速发布任何多余的加载时间都会累积成可观的浪费。Obsidian 的本地文件模式打开就是秒开编辑体验也很流畅。6.2 自动化边界哪些环节必须人工前面提到过筛选和写作必须人工。但还有一些环节我试过自动化最终放弃了。比如“自动生成标题”我试过用 AI 根据内容生成标题但出来的标题要么太泛“AI 领域今日要闻”要么太夸张“重大突破某模型性能飙升”。后来我改成手动写标题虽然多花几分钟但标题质量明显更好打开率也更高。再比如“自动排版”我试过用脚本把内容按模板填充但遇到特殊情况比如某条快讯需要配图、某条论文需要加公式就处理不了。现在排版还是手动但模板已经固定操作很熟练实际耗时并不多。我的经验是凡是涉及“判断”和“创意”的环节人工都比自动化好凡是重复性的、规则明确的环节自动化都能省时间。这个边界要根据自己的实际情况来定没有标准答案。6.3 持续更新的动力管理做日报最大的挑战不是技术而是坚持。我见过很多人做了一两周就放弃了原因通常是“太累”或者“觉得没价值”。我的应对方法是把日报制作变成一种“学习仪式”。每天早上的这两个小时是我集中了解行业动态、思考技术趋势的时间。写日报的过程本身就是学习而不是额外的负担。这个心态转变很重要——如果觉得写日报是“输出”是“消耗”那很难坚持如果觉得是“输入”是“整理自己的思考”那就容易多了。另外我会定期回顾历史日报看看自己过去的判断哪些对了、哪些错了。这个复盘过程既有成就感看到自己判断准确的时候也有教育意义看到自己判断失误的时候。这些反馈让我觉得日报不只是给读者看的也是给自己积累的。6.4 扩展方向从日报到知识库日报做了 400 多期之后积累的内容已经形成了一个小型知识库。我现在会定期把日报里的内容按主题重新整理比如“多模态模型进展”“推理优化技术”“开源生态变化”等形成专题综述。这些综述比单期日报更有深度也更适合作为参考资料。这个扩展方向不需要额外的工作量只是把已有的内容重新组织。但它的价值很大——单期日报是“快消品”看完就过去了专题综述是“耐用品”可以反复查阅。如果你也在做类似的信息聚合项目建议从一开始就注意内容的可检索性和可重组性后面会省很多事。最后分享一个我用了很久的小技巧每天写完日报后花两分钟写一句“今日最大收获”。这句话不用发给读者只是给自己看的。坚持下来你会发现这两分钟的积累比日报本身更有价值。
从信息洪流到每日必读：AI日报的筛选、写作与自动化实践
1. 一份 AI 日报的诞生从信息洪流到每日必读每天早上八点我的手机里会准时弹出一份自己做的 AI 日报。它不是那种从新闻网站复制粘贴的流水账而是一份经过筛选、验证、拆解和重新组织的行业情报。2026 年 9 月 25 日这一期是我连续更新的第 400 多期也是我踩了无数坑之后把流程打磨到相对顺手的一期。如果你也在做类似的信息聚合项目或者想给自己团队做一份内部技术简报那这套东西可以直接拿去用。先说清楚这份日报到底解决什么问题。AI 领域的信息密度极高每天醒来就有几十条所谓的“重磅发布”“颠覆性突破”“行业地震”。但真正值得关注的可能只有三到五条。剩下的要么是融资 PR要么是论文预印本的过度包装要么是同一件事被不同媒体反复翻炒。一份好的日报核心价值不在于“全”而在于“筛”——把噪音去掉把信号留下并且告诉你这个信号为什么重要、跟昨天的那条有什么关系、对你可能意味着什么。这份日报的读者画像很明确AI 方向的产品经理、算法工程师、技术负责人以及需要快速了解行业动态但没时间刷几十个信息源的投资人和创业者。它不追求学术深度也不做长篇大论的分析而是用最短的篇幅把一件事讲清楚发生了什么、关键细节是什么、我的判断是什么。每一条控制在 150 到 300 字之间整份日报阅读时间不超过 8 分钟。我试过很多种形式从最早的纯链接列表到后来的长文综述再到现在的“标题 核心事实 一句话点评”结构。最终稳定下来的这套模板是在阅读完成率、信息留存率和制作耗时三个维度上平衡得最好的。下面我把整个项目的设计思路、技术选型、实操流程和踩坑经验全部拆开讲。2. 整体设计与思路拆解为什么是现在这个形态2.1 从“信息搬运”到“信息加工”的定位转变最早做日报的时候我的做法很简单早上花半小时刷一圈信息源把看起来重要的链接复制到一个文档里加个日期就发出去。结果就是读者反馈“信息量太大不知道重点在哪”我自己也觉得没什么价值——因为读者自己也能刷到这些链接我做的事情只是帮他们省了几次点击这个价值太薄了。后来我意识到日报的核心竞争力不在于“我比你先看到”而在于“我比你想得深一步”。同样一条“某公司发布新模型”的消息普通搬运工只会写“某公司今天发布了 X 模型参数规模 Y在 Z 基准上得分 W”。但我会多问几个问题这个模型跟三个月前那版比真正的改进在哪是数据质量提升了还是训练方法变了它在实际场景中的表现有没有第三方验证发布时机有没有什么讲究把这些想清楚写出来的东西才有“加工”的痕迹读者才会觉得“看你的日报比自己刷省时间”。这个定位转变直接影响了后面的所有设计。信息源的选择上我不再追求“覆盖所有媒体”而是精选那些有一手信息或者有独立判断的源头。筛选标准上我不再按“热度”排序而是按“信息增量”排序——一条消息如果只是重复已知事实哪怕全网都在转我也不收。写作方式上我不再追求客观中立而是明确给出自己的判断和理由哪怕这个判断后来被证明是错的读者也能从中看到思考过程。2.2 日报的模块化结构设计现在这份日报的固定结构是四个板块头条深挖、快讯速览、论文精选、工具推荐。每个板块的定位和写作要求都不一样。头条深挖每天只选一条通常是当天信息增量最大、影响面最广的事件。这一条我会花最多时间不仅写清楚事实还要补充背景、分析影响、给出判断。篇幅在 400 到 600 字之间相当于一篇微型分析文章。快讯速览是 5 到 8 条短消息每条 100 到 150 字只讲核心事实和一句话点评不做展开。论文精选通常选 1 到 2 篇值得关注的预印本重点讲清楚它解决了什么问题、方法有什么新意、跟已有工作比进步在哪。工具推荐则是介绍一个最近发现的好用工具或开源项目偏实操向。这个结构不是拍脑袋定的而是根据读者反馈迭代出来的。最早我试过“全部长文”模式结果制作耗时太长经常断更。后来试过“全部短讯”模式读者又觉得太浅没有深度内容。现在的混合结构既保证了每天有“硬菜”又有足够的“配菜”让整份日报显得丰满。制作时间控制在 90 分钟左右可持续性比较好。2.3 技术选型为什么不用全自动方案很多人问我为什么不搞全自动抓取加 AI 摘要。我试过而且试了不止一次。结论是全自动方案在“筛选”和“判断”这两个环节上目前还达不到可用的水平。抓取环节确实可以自动化RSS、API、网页监控都能做。但筛选环节就麻烦了。AI 摘要工具分不清“某公司发布新模型”和“某公司发布新模型但第三方复现发现性能远低于宣传”之间的本质区别前者是 PR后者才是新闻。它也不知道一条消息在行业脉络中的位置——比如某个技术路线三年前被证明走不通现在有人换个名字重新包装AI 摘要只会照搬原文的乐观表述。判断环节就更难自动化了。写点评需要结合行业背景、技术趋势、竞争格局来做综合判断这恰恰是当前 AI 最不擅长的部分。我试过让 AI 写点评出来的东西全是“这一进展标志着该领域的重要突破”“有望推动行业进一步发展”之类的废话没有任何信息增量。所以现在的方案是“半自动”抓取和初步分类用脚本完成筛选和写作全部人工。脚本每天早上六点跑一次把过去 24 小时的信息源更新抓下来按关键词做初步分类生成一个候选列表。我七点开始人工过一遍选出真正值得写的条目然后逐条写作。这个流程既保证了效率又保留了人工判断的核心价值。3. 核心细节解析与实操要点每条日报是怎么写出来的3.1 信息源的筛选与维护信息源的质量直接决定日报的质量。我目前维护着大约 40 个信息源分为四类官方发布渠道、行业媒体、个人博主、学术预印本平台。官方发布渠道包括主要 AI 公司的博客和公告页。这类源的价值在于一手信息但缺点是更新频率不稳定而且内容偏 PR 向需要交叉验证。行业媒体我主要看三四家选择标准是“有独立采编能力不纯粹翻译外媒”。个人博主是我最看重的信息源因为他们的判断往往比媒体更敏锐而且愿意说一些媒体不方便说的话。学术预印本平台主要看最新上传的论文但只关注那些有开源代码或者有知名机构背书的。维护信息源是个持续工作。我每个月会做一次复盘看哪些源在过去一个月里提供了真正有价值的信息哪些源只是制造噪音。表现不好的源直接删掉同时补充新的候选源。这个“新陈代谢”机制很重要因为信息源的质量会随时间变化——有些博主一开始质量很高后来开始接广告或者转向其他领域就需要及时调整。注意不要贪多。我见过有人维护上百个信息源结果每天光浏览就花两小时真正写日报的时间反而没了。信息源在精不在多10 个高质量源远胜 50 个平庸源。3.2 筛选标准的量化与执行筛选是日报制作中最关键的环节。我给自己定了一套可执行的量化标准避免凭感觉做判断。第一条标准是“信息增量”。一条消息如果包含以下任意一项就算有增量新的事实之前没公开过的数据或细节、新的视角对已知事实的不同解读、新的关联把两件看似无关的事联系起来。如果一条消息只是重复已知事实哪怕它上了热搜我也不收。第二条标准是“影响半径”。我会问自己这条消息会影响多少人影响程度有多深比如某个开源工具更新了一个小版本只影响少数开发者那就不值得进日报。但如果这个更新改变了某个常用功能的行为可能影响大量项目那就值得写。第三条标准是“可验证性”。对于声称有突破性进展的消息我会优先选择那些有第三方验证或者有可复现代码的。纯 PR 稿如果没有其他信息源交叉验证我通常不写或者写的时候明确标注“未经独立验证”。这三条标准执行下来每天从候选列表里能选出的条目通常在 8 到 12 条之间刚好填满四个板块。如果某天候选特别少我会降低标准补充一些“值得关注但不算重磅”的内容。如果某天候选特别多我会提高标准只保留最核心的几条。3.3 写作风格的刻意练习日报的写作风格是“专业但不学术直接但不粗糙”。具体来说有几个刻意练习的点。第一每句话都要有信息量。我写完一条后会逐句检查如果某句话删掉之后读者不会损失任何信息那就删掉。比如“据悉”“据了解”“有消息称”这类词除非确实需要保护信源否则一律不用。第二用具体数字代替模糊表述。“性能大幅提升”不如“推理速度提升 40%”“很多用户反馈”不如“GitHub 上 200 多条 issue 提到这个问题”。数字让信息更可信也更容易被记住。第三点评要有立场。我要求自己每条快讯的点评必须包含一个明确的判断不能是“值得关注”“拭目以待”这种万能废话。判断可以是“这个方向大概率走不通”也可以是“这个做法很聪明可能会被广泛借鉴”但必须有观点。第四控制句子长度。移动端阅读场景下长句子是阅读体验的杀手。我尽量把每句话控制在 40 字以内超过就拆成两句。段落也尽量短每段不超过 4 行。4. 实操过程与核心环节实现2026 年 9 月 25 日这一期的完整记录4.1 早晨六点的自动抓取与初步分类早上六点脚本准时运行。这个脚本是我用 Python 写的核心逻辑很简单遍历配置好的信息源列表用 feedparser 解析 RSS用 requests 加 BeautifulSoup 抓取没有 RSS 的页面把过去 24 小时的新内容存到一个 JSON 文件里。import feedparser import requests from bs4 import BeautifulSoup from datetime import datetime, timedelta def fetch_rss(url): feed feedparser.parse(url) cutoff datetime.now() - timedelta(hours24) items [] for entry in feed.entries: published datetime(*entry.published_parsed[:6]) if published cutoff: items.append({ title: entry.title, link: entry.link, summary: entry.get(summary, ), source: feed.feed.title, published: published.isoformat() }) return items抓取完成后脚本会做一个初步分类。分类逻辑是基于关键词匹配如果标题或摘要里出现“模型”“发布”“开源”等词归入“产品技术”类出现“融资”“收购”“合作”等词归入“商业动态”类出现“论文”“研究”“实验”等词归入“学术研究”类。这个分类很粗糙但足够把候选列表从几百条压缩到几十条减轻人工筛选的负担。六点二十左右脚本跑完生成一个包含大约 60 到 80 条候选的列表。我会在手机上先扫一眼标题把明显不相关的比如纯营销内容、重复条目快速划掉剩下大约 30 条进入详细筛选。4.2 七点开始的人工筛选与深度阅读七点整我坐到电脑前打开候选列表开始逐条筛选。这个过程通常需要 30 到 40 分钟。筛选的第一步是“快速淘汰”。我会先看标题和来源如果标题里出现“震撼”“颠覆”“史上最强”这类词直接跳过——真正重要的消息不需要用形容词来证明自己。如果来源是我不熟悉的媒体而且没有其他信息源交叉验证也先跳过。第二步是“深度阅读”。对于保留下来的条目我会点开原文仔细读。读的时候带着几个问题核心事实是什么有没有数据支撑跟已知信息有什么冲突或补充有没有利益相关方没有披露这些问题帮助我快速判断一条消息的真实价值和潜在偏差。以 9 月 25 日这一期为例候选列表里有一条关于某开源模型发布新版本的消息。标题很普通没有夸张词汇来源是一个我长期关注的技术博客。点进去读完发现这个新版本的核心改进是训练数据配比的调整而不是模型架构的变化。这个细节很重要因为很多媒体报道时会笼统地说“模型升级”但实际改进点在哪里决定了这个升级对用户有没有意义。我决定把这条放进快讯并在点评里明确指出“改进来自数据侧而非架构侧对推理成本的影响有限”。4.3 八点开始的写作与编排八点开始正式写作。我通常先写头条深挖因为这条最耗时需要查背景资料和做分析。9 月 25 日的头条我选了一条关于某研究机构发布多模态推理基准的消息。选它的理由是多模态推理是当前的热点方向但一直缺乏统一的评估标准这个基准的发布可能会影响后续很多工作的评价方式。写头条的时候我会先列一个提纲事实是什么、背景是什么、关键细节有哪些、我的判断是什么。然后按这个提纲展开控制在 500 字左右。写完后我会放一放先去写快讯最后再回来改头条——隔一段时间再看更容易发现表述不清或者逻辑跳跃的地方。快讯的写作相对快一些每条 10 分钟左右。我会把最重要的信息放在第一句然后补充一两个关键细节最后加一句点评。点评尽量短一两句话说完不展开。论文精选和工具推荐通常放在最后写因为这两块相对独立不需要跟当天其他内容做太多关联。论文精选我会重点讲“这篇论文解决了什么问题”和“方法的新意在哪”避免陷入技术细节的堆砌。工具推荐则偏实操讲清楚“这个工具能做什么”“怎么用”“有什么坑”。4.4 九点半的终审与发布九点半左右初稿完成。我会花 15 分钟做终审检查几个东西事实有没有错误、表述有没有歧义、链接能不能打开、排版有没有问题。事实核查是最重要的我会对每条消息的关键数据做二次确认确保没有把“提升 40%”写成“提升 4 倍”这种低级错误。终审完成后我会把日报导出为 Markdown 格式通过邮件和即时通讯工具发给订阅者。同时会在个人博客上同步一份存档方便后续检索。5. 常见问题与排查技巧实录那些踩过的坑和总结的经验5.1 信息源突然失效怎么办信息源失效是家常便饭。RSS 地址变更、网站改版、博主停更都会导致抓取失败。我的做法是给每个信息源加一个“健康检查”机制如果连续三天没有抓到新内容脚本会发提醒给我让我手动检查是源本身停止更新了还是抓取规则需要调整。对于网站改版导致的抓取失败我通常不会花太多时间去修爬虫规则而是优先找有没有替代的 RSS 或者 API。如果实在没有就暂时把这个源标记为“手动检查”每天花两分钟人工看一眼。毕竟我的目标是获取信息不是维护爬虫。5.2 同一条消息被多个源报道怎么处理这种情况很常见尤其是重大发布。我的处理原则是优先采用一手源如果一手源信息不够详细再参考二手源的补充。但最终写进日报的内容必须是我自己核实过的不能直接复制任何一方的表述。如果不同源之间有矛盾比如一家说“性能提升 50%”另一家说“提升 30%”我会在日报里明确指出这个差异并说明可能的原因比如测试条件不同、基准选择不同。这种“矛盾本身也是信息”的处理方式读者反馈很好因为他们能看到不同角度的说法而不是被单一来源牵着走。5.3 写作时间不够怎么压缩有时候早上有急事只有一个小时写日报。这种情况下我会启动“精简模式”头条只写 300 字快讯减到 4 条论文和工具板块合并成一条。核心原则是“宁可少写不可乱写”——如果时间不够导致质量下降我宁愿少发几条也不发未经核实的内容。长期来看提高写作速度的关键是建立“素材库”。我平时会随手记录一些行业背景知识、常用数据、典型判断逻辑写日报的时候可以直接调用不用每次从头查起。这个素材库我维护了两年多现在写一条快讯的平均时间从最早的 20 分钟降到了 10 分钟左右。5.4 读者反馈怎么处理读者反馈是改进日报的重要输入。我会认真看每一条反馈但不会全部采纳。有些读者希望增加某个板块有些希望减少某类内容这些需求往往是矛盾的。我的做法是如果多个读者反映同一个问题就认真考虑调整如果只是个别读者的偏好就记录在案但不一定执行。最常见的反馈是“某条消息我觉得不重要为什么你选了”。这种反馈很有价值因为它让我看到自己的判断跟读者预期的差异。我会反思是我高估了这条消息的影响还是读者不了解背景所以觉得不重要如果是后者我会在后续的日报里补充更多背景信息帮助读者理解为什么某件事值得关注。5.5 常见问题速查表问题现象可能原因排查方法解决建议抓取脚本报错信息源改版或网络问题检查目标页面是否可访问更新抓取规则或暂时跳过该源候选列表为空RSS 地址失效或时间窗口设置错误手动访问源站确认是否有更新修正 RSS 地址或调整时间窗口日报发出后发现有事实错误核实不充分或来源本身有误回顾写作时的核实流程在下一期更正并说明建立更严格的双源核实机制写作时间超过预期头条选题过于复杂或资料查找耗时记录每个环节的实际耗时简化头条结构提前建立素材库读者反馈“信息量太大”快讯条数过多或单条过长统计阅读完成率减少快讯条数控制单条在 150 字以内6. 工具链与效率提升让日报制作可持续6.1 核心工具选型与配置整个日报制作涉及的工具不多但每个都经过仔细挑选。抓取环节用 Python 加 feedparser 和 BeautifulSoup这是最灵活的方案可以处理各种格式的信息源。数据存储用 SQLite轻量且不需要额外服务。写作和排版用 ObsidianMarkdown 原生支持而且有很好的标签和搜索功能方便后续检索历史内容。发布用 Buttondown 的 API支持 Markdown 邮件订阅管理也简单。我特意没有用 Notion 或类似的重型工具因为日报制作需要快速打开、快速编辑、快速发布任何多余的加载时间都会累积成可观的浪费。Obsidian 的本地文件模式打开就是秒开编辑体验也很流畅。6.2 自动化边界哪些环节必须人工前面提到过筛选和写作必须人工。但还有一些环节我试过自动化最终放弃了。比如“自动生成标题”我试过用 AI 根据内容生成标题但出来的标题要么太泛“AI 领域今日要闻”要么太夸张“重大突破某模型性能飙升”。后来我改成手动写标题虽然多花几分钟但标题质量明显更好打开率也更高。再比如“自动排版”我试过用脚本把内容按模板填充但遇到特殊情况比如某条快讯需要配图、某条论文需要加公式就处理不了。现在排版还是手动但模板已经固定操作很熟练实际耗时并不多。我的经验是凡是涉及“判断”和“创意”的环节人工都比自动化好凡是重复性的、规则明确的环节自动化都能省时间。这个边界要根据自己的实际情况来定没有标准答案。6.3 持续更新的动力管理做日报最大的挑战不是技术而是坚持。我见过很多人做了一两周就放弃了原因通常是“太累”或者“觉得没价值”。我的应对方法是把日报制作变成一种“学习仪式”。每天早上的这两个小时是我集中了解行业动态、思考技术趋势的时间。写日报的过程本身就是学习而不是额外的负担。这个心态转变很重要——如果觉得写日报是“输出”是“消耗”那很难坚持如果觉得是“输入”是“整理自己的思考”那就容易多了。另外我会定期回顾历史日报看看自己过去的判断哪些对了、哪些错了。这个复盘过程既有成就感看到自己判断准确的时候也有教育意义看到自己判断失误的时候。这些反馈让我觉得日报不只是给读者看的也是给自己积累的。6.4 扩展方向从日报到知识库日报做了 400 多期之后积累的内容已经形成了一个小型知识库。我现在会定期把日报里的内容按主题重新整理比如“多模态模型进展”“推理优化技术”“开源生态变化”等形成专题综述。这些综述比单期日报更有深度也更适合作为参考资料。这个扩展方向不需要额外的工作量只是把已有的内容重新组织。但它的价值很大——单期日报是“快消品”看完就过去了专题综述是“耐用品”可以反复查阅。如果你也在做类似的信息聚合项目建议从一开始就注意内容的可检索性和可重组性后面会省很多事。最后分享一个我用了很久的小技巧每天写完日报后花两分钟写一句“今日最大收获”。这句话不用发给读者只是给自己看的。坚持下来你会发现这两分钟的积累比日报本身更有价值。
