每天早上七点半我会把前一天从 HackerNews 上捞下来的几十条链接过一遍最后留下五到八条每条配三句话的解读发出去。这份《科技AI资讯日报》我已经连续更新了大半年中间断过两次一次是出差一次是真的没有值得写的东西——后者反而让我想明白了这份日报到底该怎么做。如果你也在做类似的事给团队写内部技术周报、维护一个 AI 资讯栏目、或者单纯想让自己每天早上花十分钟就摸清行业里发生了什么下面这些经验应该能直接拿去用。我会讲清楚三件事HackerNews 这种信源应该怎么筛、一份日报的流水线怎么搭、以及哪些坑我已经替你踩过了。内容偏工程实践不需要你会写代码但你得愿意动手把重复劳动交给脚本。1. 一份AI资讯日报到底该解决什么问题1.1 信息过载的本质不是信息太多是噪音太多做日报之前我订阅了四十多个信息源每天醒来手机上有三百多条未读。真正的问题不是读不完而是读完以后我依然说不清楚昨天这个领域究竟发生了什么值得记住的事。这就是典型的信噪比问题内容总量在涨但有效信息的密度在降。我做过一个粗糙的统计把某一天抓到的两百条 AI 相关链接人工打了标签结果是真正包含新的事实新模型发布、新论文、新工具上线、重要版本更新的不到三成厂商公关稿和融资通稿占两成剩下的一半是观点文、二手转述、以及对同一件事的重复报道。也就是说如果你不做筛选你花在阅读上的时间有七成是浪费的。日报的价值就建立在这个判断上它不是让你读得更多而是让你读得更少但更准。一份日报如果读起来和刷信息流没有区别那它就没有存在的必要——你把 RSS 列表按时间排序得到的就是同样的东西。1.2 HackerNews 的价值和它藏着的偏见HackerNews 是我最主要的信源原因有三条。第一投票机制天然做了初筛能上首页的内容至少经过了数百人的是否值得一看的判断。第二评论区经常比正文更有价值尤其是那些指出论文复现失败、指出基准测试不公平、或者贴出自己实测数据的回复这些是任何二手资讯都不会告诉你的。第三它的受众以工程师和创业者为主对能跑起来的东西有强烈的偏好这恰好过滤掉了大量纯概念炒作。但它有很明显的偏见你必须心里有数。它偏英文内容非英语世界的技术动态基本进不来它偏工程和基础设施纯理论或者偏产品侧的内容不容易冒头它对某些话题有明显的周期性狂热一个方向火了接下来两周首页会出现大量相关但质量参差的帖子。更要命的是它的滞后性——真正重要的事往往先在专业社区或者邮件列表里发酵等到 HackerNews 首页的时候已经过去一两天了。我把这些偏见当成已知的系统误差来处理日报里我会明确标注某条内容的热度来源也会刻意补充一两条非英文社区或者非工程视角的动态哪怕它们的投票数不高。1.3 我给这份日报定的三条规矩第一不做搬运。一条资讯如果没有我自己的判断就不进日报。判断可以很短比如这个基准测试的对比基线和上一版不一致结论要打折扣但必须有。第二每条不超过四句话。事实一句背景一句判断一到两句。写长很容易写短很难而读者的注意力是最稀缺的资源。第三不预测。我不写这标志着某某时代的到来也不写未来三年会怎样。我只写已经发生的事以及这件事和我已知的信息之间的关系。这条规矩是吃过亏之后才立下的——早期我写过几次这将是转折点后来基本都被打脸了而读者是记得的。这三条规矩看起来简单执行起来每天都要和自己的表达欲作斗争。但正是这三条让这份日报从又一个资讯聚合变成了有人愿意每天早上专门点开看的东西。2. 选题与信源把噪音挡在门外的四道过滤器2.1 第一道用热度衰减公式理解为什么这条在榜上HackerNews 的排序不是简单的按票数排票数相同的新帖会排在旧帖前面。社区里被广泛引用的一个近似公式是这样score (points - 1) / (age_hours 2) ^ 1.8这个公式能解释很多现象。假设一条帖子有 100 票、发布 3 小时代入后大约是 (99) / (5^1.8) ≈ 99 / 18.1 ≈ 5.47。另一条帖子有 300 票、发布 20 小时代入后是 (299) / (22^1.8) ≈ 299 / 262 ≈ 1.14。也就是说100 票的新帖可以轻松压过 300 票的旧帖。理解这个公式的实际意义在于榜单排名不等于重要性它混合了时间和热度两个维度。所以我在初筛的时候会用两个阈值同时卡票数下限设在一个相对稳定的位置比如 80 票以上同时关注那些票数不高但发布不到两小时的帖子因为这类内容往往处在上升期等你第二天再看已经冲上去了那时候再写就晚了。2.2 第二道评论数与票数的比值藏着真正的分歧点我后来发现一个更好用的信号评论数 / 票数。这个比值高的帖子通常意味着内容本身没有明确的共识大家在评论区吵起来了。这类帖子往往比那些一致叫好的帖子更有信息量因为分歧点就是技术选型的真实难点。我的经验阈值大概是这样比值在 0.3 以下通常是纯分享型内容比如某个开源项目上线、某篇教程读完正文就够比值在 0.5 到 1 之间一般是有讨论价值的观点文或者有争议的技术方案评论区必须扫一遍比值超过 1.2 的往往是行业争议或者伦理话题我会格外小心地判断它是否适合放进日报——这类内容传播快但信息量不稳定容易把日报变成情绪出口。2.3 第三道辅助信源的编排别让 HackerNews 成为唯一入口只靠一个信源你会得到一份视野狭窄的日报。我的辅助信源分四类各承担不同职责信源类型主要作用我的处理方式厂商官方发布页与官方博客拿一手事实、版本号、参数只取原文表述不引用二手转述工程团队技术博客拿真实落地经验和踩坑记录优先挑有具体数据、有架构图的论文预印本平台的当日更新拿前沿方向的变化只挑有开源实现或者有复现讨论的开源仓库的趋势榜拿工具层的真实热度看的是近期新增关注而非总星数这四类信源里我最看重第二类。厂商发布页给的是事实技术博客给的是这东西在实际系统里到底好不好用后者才是日报区别于新闻通稿的地方。2.4 第四道我自己的关键词表这道过滤器是最个性化的一道。我维护两张表一张是提权词一张是降权词每次初筛时按命中情况加减分。提权词包括本地部署、推理成本、上下文长度、Agent 工具调用、代码生成、评测基准、模型量化、多模态输入、上下文工程、工程实践、可观测性。降权词包括颠覆、碾压、史上最强、全面超越、杀疯了、王炸、一夜之间。降权词命中的条目不是直接删而是先扣分除非它同时命中提权词否则基本进不了日报。这张表每两周更新一次。判断标准很简单过去两周里哪些词频繁出现但事后发现毫无信息量就进降权表哪些词背后总能挖出有价值的技术细节就进提权表。3. 采集与整理一套每天只花二十分钟的半自动流水线3.1 数据从哪来优先用接口别硬爬页面能拿到结构化数据的地方就不要去解析 HTML。HackerNews 官方提供了一套公开的只读接口主要用到三个端点topstories.json返回当前首页的条目 ID 列表item/id.json返回单条内容的详情包含标题、链接、分数、评论数、发布时间beststories.json返回另一个维度的榜单。这三个端点配合起来足够支撑一份日报的全部数据需求。用接口的好处很直接不需要处理页面结构变化不会因为改版导致脚本全线崩掉也不用担心请求频率问题这类公开接口本身就有合理的访问约定。下面是我用的一段抓取脚本逻辑很简单就是把首页 ID 拉下来再逐个取详情import time import requests BASE https://hacker-news.firebaseio.com/v0 def fetch_json(path): resp requests.get(f{BASE}/{path}, timeout10) resp.raise_for_status() return resp.json() def get_top_items(limit60): ids fetch_json(topstories.json)[:limit] items [] for idx, item_id in enumerate(ids): try: data fetch_json(fitem/{item_id}.json) except Exception as exc: print(fskip {item_id}: {exc}) continue if not data or data.get(type) ! story: continue items.append({ id: data.get(id), title: data.get(title, ), url: data.get(url) or fhttps://news.ycombinator.com/item?id{data.get(id)}, score: data.get(score, 0), comments: data.get(descendants, 0), time: data.get(time, 0), }) time.sleep(0.15) # 控制请求节奏避免给对方造成压力 return items这里有两个细节值得说。一是time.sleep(0.15)公开接口虽然不要钱但也没理由对它做密集请求加一点间隔是对服务方的尊重也能降低自己被限流的概率。二是url字段要留一个兜底——有些帖子的讨论本身就是内容比如Ask HN类型的提问这类帖子没有外链兜底指向讨论页才不至于丢信息。3.2 用脚本把初筛这一步交给机器拿到原始列表之后第一件事是算前面说的那个衰减分数然后排序。第二件事是打标签也就是拿关键词表去匹配标题。这一步完全不需要任何模型用最简单的字符串匹配就够速度快、结果可解释、不会因为模型版本更新而行为漂移。我一般把条目分成四档输出A 档是必须看的高衰减分数 命中提权词B 档是应该看的高衰减分数或命中提权词C 档是备选分数中等无关键词命中D 档是直接跳过的命中降权词且无提权词。实际写日报的时候我百分之八十的选材来自 A 档和 B 档C 档偶尔补位D 档基本不看。这套分档最大的价值不是我选得更准而是我不再需要在两百条里逐条判断这条要不要看。决策成本被提前摊销到脚本里了。3.3 去重和聚类同一个事件只出现一次去重这件事做日报的人早晚要面对。同一个模型发布可能同时出现官方发布页媒体解读开发者实测社区讨论四条链接如果都收进日报读者会觉得你在凑数。我的做法分两层。第一层是 URL 归一化去掉查询参数、去掉结尾斜杠、统一大小写先把明显的同链去重。第二层是标题相似度把标题转成小写、去掉标点、按词切分然后算两组词的交集比例超过一个阈值就认为是同一事件。这个阈值我试过几个值最终定在 0.6 左右——太高会漏掉真正重复的表述差异大的报道太低会误杀同一家公司两件不同的事。判定为同一事件之后不是简单删掉多余的而是按信息密度排序保留一条。我的排序偏好是官方来源 有实测数据的开发者记录 有独立分析的技术博客 一般媒体报道。这个顺序未必适合所有人但官方优先于转述、一手数据优先于观点这条原则基本是通用的。3.4 AI 打草稿人做终审摘要这一步我会用模型打草稿但绝不直接发布。具体做法是把原文链接和标题丢给模型要求它输出三句话——第一句陈述事实第二句交代背景这个东西解决了什么问题、和已有的什么方案是什么关系第三句指出需要注意的点。同时要求它标注哪些信息来自原文哪些是推测。这个要求很关键。模型很容易把可能据称这类限定词丢掉把推测写成结论。我复核的时候重点看两处有没有把不确定表述改成了确定表述有没有出现原文里根本没有的数字。这两类错误一旦发出去对日报的可信度伤害是致命的。复核完事实之后我会用自己的话重写第三句判断。这一步我不交给模型因为判断的价值恰恰在于它来自一个真实从业者的经验和立场。4. 单条资讯怎么写三段式模板4.1 事实、上下文、判断我把每条资讯固定写成三段结构。事实段回答发生了什么只包含可核验的信息谁发布的、什么版本、什么时间、关键数字是什么。上下文段回答这件事处在什么位置它和同类方案相比是什么关系之前的版本是什么样的这次变动的幅度大不大。判断段回答我该怎么看它有什么值得注意的地方什么情况下值得关注什么情况下可以先放一放。这个结构的好处是读者可以按需阅读。只想扫一遍的人看事实段就够三十秒能过完八条对某条感兴趣的人往下读上下文和判断。它也让写作者不容易糊弄——因为事实段必须具体你很难用空话把一段什么也没说的内容填满。4.2 搬运和解读的差别在哪很多人觉得写资讯就是把外文翻译一下。我整理了一张对比表把两种写法的差异拆开看维度搬运式写法解读式写法内容来源只依赖原文原文 同类方案对比 自身经验数字处理直接照抄参数换算成可感知的量级标注测试条件不确定性原文怎么写就怎么抄明确指出哪些结论证据不足对读者的用知道有这个东西知道要不要花时间研究它时效性当天有效过期作废半年后回看依然成立表格里最后一行是我最在意的。搬运式内容的价值完全绑在你不知道这件事上一旦知道就归零解读式内容的价值在于那部分判断它不会因为时间流逝而失效甚至事后回看还能验证判断准不准。4.3 标题和导语的写法日报里的条目标题我遵循两条保留可检索的关键词但不说结论。比如某模型发布新版本比某模型大幅增强推理能力更好因为后者是判断而判断应该放在正文里。把判断塞进标题会让读者失去自己判断的机会也会让你在判断错了之后很难收场。导语我一般用一句不超过四十字的话概括事件然后直接进入事实段。不要写今天有个大新闻也不要写相信很多朋友已经看到了这类过渡句在日报里是纯粹的浪费——读者点开就是为了知道发生了什么不需要铺垫。4.4 什么样的条目应该直接删掉除了关键词过滤我还会主动删三类内容。第一类没有可验证细节的传闻比如据知情人士透露某公司正在做某个东西除非有第二个独立信源否则不写。第二类纯情绪化争议比如围绕某个观点的口水战除非争议背后涉及具体技术判断的分歧否则不进日报。第三类我在这个方向上完全没有判断能力的遇到这种我会如实写这条我没看懂但看起来重要先记下而不是硬凑一段分析。承认看不懂不丢人编一段看起来像分析的话才丢人。5. 排版、节奏与长期可持续5.1 栏目怎么设固定栏目能培养读者的阅读习惯但栏目太多会让日报变得臃肿。我的日报常年保持四个栏目头条解读一到两条展开写、快速浏览五到六条每条三句话、工具与开源一到两条偏实操、一句话观察当天的一条个人感想不超过五十字。这四个栏目承担不同功能头条建立当天的信息主轴快速浏览保证覆盖面工具栏目提供可操作的东西一句话观察保持人的存在感。真正让读者觉得这是个人在写的日报而不是某个自动聚合服务的往往是最后那个栏目。栏目一旦定下来就不要频繁改。我中途曾经试图加过论文速递和融资动态两个栏目坚持了两周就砍掉了——前者我读不进去后者信息量太低读者的反馈也是这两块可以去掉。栏目不是越多越显得专业而是每个都得有稳定的内容供给。5.2 把每天的成本压到四十分钟以内一份日报如果每天要花三个小时你一定坚持不下去。我把每天的时间拆成这样脚本跑完拿到分档列表大约在凌晨自动完成早上花十分钟过 A 档和 B 档的标题圈出八到十条候选花十分钟扫这些条目的关键内容和评论区高赞回复花十五分钟写主要花在判断段剩下五分钟排版和检查。压缩成本的关键在于把决策和表达分开。决策选哪些在早上精力最好的十分钟内完成不要边写边选表达怎么写尽量模板化因为格式固定能省下大量犹豫。真正需要动脑的只有判断段而这部分恰恰是你作为从业者最有优势的地方值得花时间。5.3 几个能让你坚持半年的习惯第一个习惯是提前备稿。我常备三到五条随时可以发的内容比如某个工具的深度使用记录、某个方向的阶段性总结。遇到当天真的没有值得写的资讯就用备稿顶上并且如实说明今天新闻比较淡聊聊别的。读者的接受度比你想的高得多。第二个习惯是建立素材池。看到有意思的东西但当天不用就丢进一个待办清单标注日期和关键词。这个池子的作用是让你在某个话题突然火起来的时候能立刻拿出两三周前的观察形成前后对照——这是日报最难得的深度。第三个习惯是定期回看自己的判断。我每个月会把上个月的判断段翻一遍看看哪些说错了。这件事不太愉快但它是让日报质量曲线向上走的唯一方法。我的经验是事实类的错误很少判断类的偏差很常见而且往往集中在高估短期影响上。6. 常见问题与踩坑记录6.1 问题速查表现象可能原因处理方式脚本报错、拿不到列表接口返回结构变动或请求异常打印原始响应体先确认返回内容再改解析逻辑同一事件反复出现在日报里去重只做了 URL没做标题相似度加上标题词交集比对阈值从 0.6 起调选出来的条目读者反响平平关键词表偏向自己的兴趣每月根据读者反馈调整降权词不只看自己爱看什么摘要出现原文没有的数字模型自由发挥每个数字都必须能在原文里定位到找不到就删写着写着变成观点文上下文段和判断段混在一起强制分段事实段里不许出现判断性词汇连续几天写不出来信源单一或者阈值定得太高临时降低票数阈值或者启用备稿这张表里的每一条都是我自己遇到过的。新手最容易踩的是最后一条一开始把标准定得很高结果第三周就断更了。可持续性比单期质量重要得多。6.2 我踩过的四个坑坑一为了显得专业而堆术语。早期我写的条目里塞满了各种缩写和专有名词自认为显得懂行结果收到的反馈是看不懂。后来我给自己定了个规矩每条资讯里如果必须出现一个专业术语就用一句话解释它解决什么问题。日报的读者水平参差不齐能为新手让路的内容不会因此显得浅。坑二把热度当成重要性。有一次我把某条讨论量极高的帖子放在头条展开写了很长第二天回看发现自己被节奏带偏了——那条内容本身没有新事实只是观点冲突激烈。从那以后我加了一条自检这条内容如果去掉所有争议性表述还剩多少可核验的信息剩下不足一半的就不进头条。坑三在摘要里用模型直接生成的判断。这个我前面提过但值得再说一遍。模型写的判断读起来非常流畅四平八稳什么问题都不得罪恰恰是这种完美的中立让日报失去了性格。读者的反馈很直接那段看起来像通稿。判断段必须手写哪怕写得糙一点。坑四忽视了非工程类动态。有段时间我的日报几乎全是模型和框架的技术细节一位读者留言说看完还是不知道这些东西对普通用户意味着什么。这句话提醒了我日报的受众不全是开发者。现在每条偏技术的条目后面我会补一句这对普通使用者意味着什么通常是一句话但它让整个日报的可读范围扩大了一倍。回看这大半年的更新记录我最大的感受是一份资讯日报的技术含量其实不在采集和排版而在你敢删掉多少东西。最初我总担心漏了重要的事恨不得把看到的都写上现在我反而觉得日报里每多一条没必要的条目都在稀释剩下那些真正重要的内容。每天少写两条读起来反而更扎实——这个道理我想了很久才想明白也是在反复被读者反馈教育之后才真正接受。