2026年3月25日，早上六点四十分，我照例坐到书桌前，屏幕左边是整理好的订阅列表，右边是几个信息聚合页面。这一天的人工智能早间新闻要从三百多条原始信息里筛出来，最后能写进正文的，大概只有十几条。窗外天还没完全亮，电脑的风扇声是房间里唯一的声音。
这份工作我做了快两年，流程早就稳定，但每天的判断仍然是新的。技术圈的消息越来越快，真正麻烦的不是信息不够，而是噪音太多。同样一个模型发布，官方博客、第三方评测、社区讨论、营销号翻译稿可能给出完全不同的画风；同样一个开源项目，release 说明里的“性能提升”和实际跑出来的数据经常是两回事。早间新闻要做的，就是把这些杂音压下去，把真正值得关注的变化挑出来，用读者能快速消化的方式递到他们面前。
今天我想借这一期，把这份早间新闻背后完整的选源、验证、筛选、编排逻辑拆开讲一遍。适合正在做技术内容、社区运营，或者单纯每天想高效跟上 AI 动态的读者，读完之后你大概率能搭出属于自己的信息管线。
1. 今天早上六点四十分，我打开了阅读器
先还原一下今天早上的现场。六点四十分左右，我把订阅源按优先级刷了一遍，大类上有实验室官方博客、代码托管平台的 trending 列表、开发者社区的高赞帖、以及一些行业媒体。再配合关键词监控，把涉及模型发布、开源许可变更、框架升级、投融资、训练方法论文的消息单独捞出来。这个过程大概持续三十分钟，期间我会顺手把候选条目丢进一个临时清单，后面统一处理。
1.1 今天会进入早报的几条消息
今天凌晨到现在，消息量不算爆炸，但有几个值得认真对待的节点。某实验室更新了他们的多模态视觉理解模型的版本，官方说明里提到在长视频理解任务上错误率降低了约三成，数据集和评测脚本都会一并公开。某个开源社区上线了一个新的推理加速框架，主打动态量化，宣传口径是“显存占用最高可降低四成”。还有一支端侧 AI 团队开源了一个模型压缩工具包，集成了一批常见的剪枝和蒸馏方法，看起来是想做成标准化的端侧部署流水线。
再往下翻，还有一条某头部云厂商更新模型服务协议的消息，以及某高校团队投出去的一篇关于稀疏注意力新方法的论文。这些条目分属不同层级，有的可以直接写进早报，有的只适合放在“值得留意”的小清单里。它们之间差别很大，但不是靠感觉区分的，背后有一套明确的筛选逻辑。
1.2 我的信息管线：四层过滤
我自己的信息管线可以拆成四层。第一层是订阅源抓取，负责把官方博客、论文预印本、项目 release 记录这些结构化信息收进来。第二层是关键词监控，把“多模态”“量化”“蒸馏”“推理加速”这类高频词相关的消息单独打标。第三层是社区热帖计分，也就是去看开发者社区里哪些讨论在短时间内获得了大量回复，热度本身就是一个信号。第四层才是人工筛选，由我逐条判断是不是值得做进早间新闻。
前两层解决“有没有”的问题，第三层解决“讨论度”的问题，第四层解决“值不值得”的问题。大多数读者其实只做到了第一层，关注了一堆账号，每天滚动刷屏，看起来接收了大量信息，实际上真正进入判断环节的没有几条。分层之后，每个环节只管一个目标，效率会高很多。打个比方：不是每条街上的人都要请进家里喝茶，你得先看门牌号，再看手里有没有请柬，最后还得等你自己点头。
2. 信息源决定新闻的上限：我的源头分级
很多刚开始做早报的朋友会问，从哪看新闻最全？我通常反过来问，你的信息来源是什么性质的？官方原话、社区二手转述、还是营销号改写？同样一条消息，经过的转手越多，失真越严重。所以我在源头层面就做了分级。
2.1 一级源头：研发单位的官方发布
一级源头，是实验室、团队、云厂商自己的博客、文档站点和官方账号。这类信息的好处是准确、成体系，能拿到第一手的技术细节和设计意图。比如今天那条多模态视觉理解模型的消息，官方博客里写了架构调整的思路、数据配比的改动、评测集的设计方式，这些细节在二手转述里往往会被压缩成一句“更强了”。
但一级源头有一个问题：它是带着立场的。官方博客本质上是一种对外叙事，目标是让读者和技术社区对这项工作产生正面认知。所以官方文字里常常会放大亮点、淡化限制。比如很多发布说明会写“在多个基准上达到最优”，但仔细看能发现评测基准是自建的，或者对比的基线是半年前的版本。一级源头的可信度高，但不能不设防地全盘接收。
2.2 二级源头：开发者社区和开源仓库的动静
二级源头是我个人最依赖的，包括开源仓库的 release 记录、issue 讨论、代码提交记录，以及开发者社区里的实际反馈。今天那条端侧压缩工具包，最早就是从代码托管平台的趋势列表里看到的，点进去发现 release 说明写得很实在，还附了在不同芯片上的实测数据。这种信息在官方宣传出来之前就已经在社群里流动了，而且往往是开发者实际跑过之后的口碑。
二级源头的价值在于它更接近“事实”本身。开源项目的代码就摆在那里，有没有水分，跑一遍就知道。issue 区里用户的抱怨、兼容性报告、性能对比，都是非常真实的一手信号。缺点是碎片化严重，信息密度低，需要花时间扒拉。我一般会在每天晚上做一轮仓库动向的粗略扫视，早上只精读前一天晚上标记过的重点项目。
2.3 三级源头：媒体、自媒体和论坛
三级源头是行业媒体、自媒体和各类论坛推文。这一层的问题最大，因为传播链条长，且多数写手没有技术背景，基本是拿官方公告改写。它们最大的作用是提供“线索”，帮我发现一些还没进入主流视野的小团队和小项目，但绝对不能作为新闻事实的来源。
我见过太多翻车案例了。一条消息在三级源头里被转了三手之后，原本“该团队探索了某种新训练方法”的表述，会被改写成“重大突破”，再转一手变成“颠覆性进展”。做早间新闻如果从这一层捞消息，很容易把传闻当新闻发出去。我对三级源头的态度是：标题可以扫，内容不要直接信；发现有价值的线索，回到一级和二级源头去核实。
2.4 分级之后的日常操作
分级不是静态标签，而是一套动态权重。我每周会做一次小调整，看看过去七天里哪些信源贡献了有效新闻，哪些反复出现误导、标题党或者二手加工，然后把权重往下调。下面是我目前常用的一张分级表：
| 级别 | 来源类型 | 更新频率 | 可信度 | 新闻转化率 | 用途 |
|---|---|---|---|---|---|
| A | 实验室/团队/云厂商官方博客 | 日/周更 | 高 | 中 | 核心技术动态 |
| A | 开源仓库 release 记录与 issue 区 | 小时级 | 高 | 高 | 真实可验证进展 |
| B | 论文预印本服务器新文章 | 日更 | 高 | 中 | 前沿方法追踪 |
| B | 开发者社区高赞帖与讨论 | 全天 | 中高 | 中 | 生态反应与踩坑反馈 |
| C | 行业媒体与自媒体 | 全天 | 中低 | 低 | 线索发现 |
| C | 投资与融资事件报道 | 不定 | 中 | 低 | 产业风向判断 |
这张表不是死的，转化率这个指标尤其重要。有些信源虽然可信度很高，但一个月也贡献不了一条能写进早报的内容；有些看似边缘的信源反而频繁带来新项目线索。所以它会动态变化，比如某个账号连续三周都在制造话题但没提供任何可验证的信息，我直接取消订阅。
3. 离谱新闻是怎么被拦下来的：验证流程
从“有动静”到“能发出来”，中间隔着一整套验证流程。我每天在临时清单里放进大概四五十条候选，最后留下十几条，剩下的要么信息不足，要么验证不过关。这个过程常常被误解为“谨慎”，其实不是，它更多是一种技术判断：这条消息背后的证据链靠不靠谱。
3.1 官方公告同样要留个心眼
先拿官方公告开刀。今天那条多模态模型更新，声明里提到了“数据集和评测脚本一并公开”，这个细节很关键。有完整评测脚本，意味着第三方可以复现，可信度直接上一个台阶。反过来，如果只写“新模型已发布”，不提供评测细节，不公开权重使用条件，那这条消息的分量就得打个折扣。
我记忆中翻车最多的地方其实是“开源”这个词。很多项目宣传说开源，点进去发现只开了推理代码，训练代码和数据集一概没有；有的说是开放权重，但协议里写明了不能商用，或者只允许非商业研究。这些细节对普通用户可能无所谓，但早间新闻面向的是工程师和产品经理，被一句“开源”带偏，后面会浪费他们大量时间。所以我在写稿时会把协议类型、开放范围写清楚，不能只抄官方措辞。
3.2 性能数字不能直接照着写
性能数字是另一个重灾区。官方宣称“推理速度提升三倍”，看起来很有冲击力，但如果你不追问对比的基线是什么、测试用的硬件是什么、显存限制怎么设的、有没有使用特殊优化算子，这个数字就是无根的。同样的模型，在不同 GPU 上、不同精度下、不同序列长度下测出来可能是完全不同的结论。
我遇到过一个典型例子：某团队宣布推理吞吐量提升 250%，看起来很夸张，点开源码才发现对比的是自家早期版本，而且新版使用了 FP8 量化加自定义算子，老版本跑的是标准 FP16。这种对比当然有参考意义，但它和用户直接升级换来的提升不是一回事。我在早报里遇到这类数字，一般会做降噪处理：客观写清楚测试条件，把“三倍”改成“在特定硬件和精度设置下约三倍”。
3.3 小道消息、内测截图的处理方式
AI 圈现在特别流行流媒体式的新闻，比如“某公司正在秘密训练一个更大的模型”“某团队内部流出的评测截图”。这类内容传播极快，因为情绪价值拉满，但它的本质只是没有证据链的传闻。
早间新闻里我基本不用纯匿名爆料，如果消息源能提供可验证的侧证，比如公开的活动页面、招聘信息、或者演讲预告，我会把它降级为“传闻”处理，并明确标注信息来源的边界。大家都想抢首发，但抢首发和发假新闻之间往往只隔着一层窗户纸。我的原则是：宁可这条消息晚一天，也不能让读者看到错的东西。
3.4 我常用的验证清单
面对一条候选新闻，我会按顺序跑一遍下面的检查项，全部通过再进稿：
- 原始出处是哪里？是官方发布、代码仓库还是匿名爆料？
- 有没有至少一个独立信源？比如官方发布后是否有第三方开发者实测反馈？
- 发布主体和内容之间有没有商业利益关联？比如某公司发布的评测是不是在给自己产品铺路？
- 关键数字能不能复现？有没有附带评测脚本、数据集或详细实验设置？
- 时间线是不是自洽？发布预告、正式发布、社区讨论之间的先后顺序有没有问题？
这套清单看起来简单，但几乎每天都能拦下几条看着不错、细究有问题的消息。养成习惯之后，做早报的返工率会大幅下降。
4. 选择新闻也是一门减法：早间内容怎么排
追新闻不是把所有消息都塞进一篇文章，恰恰相反，做得越久越觉得“不写什么”才是核心问题。我每期早间新闻会控制条数，不做贪多，把真正有信息量的内容突出出来。
4.1 排序规则：模型层优先，工具链次之
面对一批候选，我一般按这个优先级排序：模型与算法的实质更新排最前，其次是能够直接上手的开发框架和工具链，再次是生态类消息，比如某个平台上线了新模型服务，最后才是投融资和行业合作新闻。
为什么这么排？因为早间新闻的读者大多数是工程师、算法研究员和技术决策者，他们早晨打开一份简报，最想知道的是“今天有什么值得我动手试的东西”。模型层更新意味着技术能力边界在移动，框架与工具链更新意味着手头项目的效率可能被直接影响，而投融资类消息更多是行业风向参考，对当下工作帮助有限。比如今天那条端侧压缩工具包，虽然它只是一个工具，但它直接对应着部署阶段的高频痛点，我就会把它排在相对靠前的位置。
4.2 十条左右正文加一个小清单
一期早间新闻，正文部分我控制在十条到十四条，再多读者消化不了，少了又覆盖不到重要动态。正文之外，我还会加一个“快速浏览”小清单，把那些重要但没有必要展开的消息压缩成一句话条目，让读者三十秒内能扫完。
正文的每条大概一百五到两百字，只保留四部分：发生了什么、关键细节是什么、为什么值得关注、可能影响谁。很多新手写新闻恨不得把官方博客的每个技术点都复述一遍，结果读者看完发现什么也没记住。早报的价值不是全文翻译，而是信息压缩和判断注入。
4.3 直接放弃的消息类型
有几种消息我基本一眼就放弃。第一种是纯营销事件，比如某公司宣布和某机构达成战略合作，没有任何技术细节，只有双方的溢美之词。第二种是“又一家公司发布了新模型”但没有任何差异化信息，既没公布评测细节，也没有实际可体验的入口。第三种是纯粹的焦虑叙事，比如“某某能力即将取代什么岗位”，这类内容情绪价值高，但是信息量为零，放进早报只会拉低整体质量。
还有一类要特别留意：同一消息在不同信源里反复出现，看起来像很多条新闻，实际上只是一个事件的多方转述。如果不做去重，早报会变成信息复读机。我处理的方式是，以最早、最权威的源头为准，把它写成一条完整新闻，其余转述一律不单独列出。
5. 早间新闻不是播报，是带判断的解读
纯信息罗列谁都能做，真正拉开差距的是判断。读者看早间新闻，不只是想知道昨天发生了什么，更想知道这件事放在更大的背景里意味着什么。所以我的每条正文后面，几乎都跟着一段主观判断，明确告诉读者这是我的看法，不是事实本身。
5.1 把单条消息放进技术路线里看
举个例子，今天那条端侧模型压缩工具包，如果单独看，它就是又一个新的开源工具。但把它放进技术路线里看，信号就完全不同了：过去两年端侧部署一直依赖专家手工调参，脚本化、流程化的工具链出现，说明这个方向正在从“手艺活”变成“标准流程”。这种判断未必绝对正确，但它能帮读者建立一个理解新消息的坐标。
再比如那条推理加速框架，动态量化本身不算新技术，但它出现在一个强调开箱即用的新框架里，意义就不一样了。它可能意味着量化技术正在从“研究者专用”走向“普通开发者也能用”。这个判断比单纯描述框架功能更值得读者花时间去想。
5.2 动笔前先做一轮对比
有对比才有信息增量。我写新闻前通常会做一个小对比：这个新框架和目前主流的方案有什么异同？这个新模型在它所在的尺寸段里处于什么位置？对比结果不一定要写进正文，它更像是我自己要消化的背景，但有了这层对比，我写出来的东西就有了上下文，不会变成孤立的公告复述。
如果对比维度清晰，我会直接在正文里放一个小表格，比如显存占用、吞吐量、部署复杂度、周边生态完善程度。读者三十秒内就能完成新旧对比，比看一段抽象描述高效得多。但我也提醒自己，对比不是为了分高下，很多新工具解决的是旧工具解决不好的特定场景，强行排名反而失真。
5.3 每条消息后面都跟一个“你可以做什么”
去年开始，我给自己定了一个硬性要求：每条正文末尾，尽量写一句“今天可以做什么”。不一定非要很深，甚至可能只是一句“想跑推理流程的读者可以留意某个项目”，但它必须存在。因为早间新闻如果只提供信息不提供出口，读者看完会觉得很充实，实际什么也留不下。
比如今天那条多模态模型的消息，我会写“需要做长视频理解的团队可以去看看评测脚本，对照自己手头任务跑一遍。”这句话的份量很轻，但它把一条新闻和实践连接起来了，读者知道自己下一步可以干什么。时间久了，这种连接感会成为读者依赖一份早报的重要原因。
6. 两年早报生涯里我踩过的坑
做得越久越发现，做早间新闻最大的难点不是信息源不够，而是诱惑太多。抢首发的诱惑、堆数量的诱惑、追热点的诱惑，每一个都真实存在。我也在这些地方踩过坑，说几个印象最深的。
6.1 为了“抢先”抢出的错
刚做早报的时候，有一次我看到某实验室放出了新模型的预告页面，页面里挂出了几个演示用例，看起来很真。我判断消息可信，当天就写进了早间新闻。结果那只是一个预告页面，页面里挂出了几个演示用例，看起来很真。我判断消息可信，当天就写进了早间新闻。结果到了晚上，官方说正式发布延迟，页面上的演示用例也撤掉了。那条新闻虽然事后做了更正，但已经随着早报发出去了，传播出去的错误是收不回来的。
从那以后我给自己立了条规矩：发布预告和正式发布严格区分，预告阶段最多在“快速浏览”里提一句“值得留意”，不会作为正式新闻写。宁可慢半拍，也不能把流程不完整的事情当成事实报道。
6.2 早晨90分钟怎么分配
时间管理也是慢慢试出来的。刚开始做早报，我经常一坐在屏幕前就是三四个小时，大量时间花在犹豫和反复检查上，效率很低。后来我把早晨时间固定成三段：前三十五分钟扫源，把所有订阅和监控过一遍，把候选丢进清单；接下来四十分钟做验证和深度阅读，重点处理清单里最前面的五六条；最后十五分钟集中成稿，不回头，不改口。
很多内容写作者的问题在于把写作和验证混在一起，一边查资料一边写，结果效率极低。我把验证和写作明确分开之后，成稿速度快了很多，而且质量反而更稳。因为验证阶段脑子里全是“事实和证据”，写作阶段脑子里才是“组织和表达”，两件事占用的认知资源完全不同，混在一起只会互相干扰。
6.3 每月复盘：信息源权重是要调整的
每个月月底，我会花两三个小时做一次复盘，翻看当月发出去的早间新闻，对照后续事实发展，逐条检讨：哪些判断验证了，哪些判断偏了，哪些信息源贡献的新闻后来被出技术文档和官方博客。经过两个月的权重调整，这类模板类的早期信号基本消失，新闻的存留度明显提升。
这个复盘习惯同样适合普通读者。如果你也每天在看 AI 新闻，不妨月底花点时间回顾一下自己关注的账号里，有哪些已经超过一个月没有提供任何有价值的信息，该清一清就清一清。信息管线是需要修剪的，不修剪就会长满杂草。
做了两年早间新闻，最大的变化是我对“快”这件事不再焦虑了。信息永远追不完，但认知可以每天都往前挪一点。今天早上那十几条消息发出去之后，我关掉屏幕站起身，窗外天已经大亮。我记得刚开始做早报的时候总担心漏掉什么，现在反而更坦然——漏掉不重要，真正重要的东西，一定会在第二天的信源里再次浮出来。
