1. 一份日报的诞生：从信息洪流到可读清单
每天早上七点，我的浏览器标签页会同时打开十几个信息源：arXiv 的 cs.AI 和 cs.CL 板块、几个头部实验室的官方博客、GitHub Trending 的 Python 分区、还有三四个行业垂类媒体。这个习惯从 2023 年一直保持到现在，中间换过工具、换过抓取脚本、换过筛选逻辑，唯一没变的是"日报"这个输出形态。很多人觉得做日报就是复制粘贴加排版，但真正做过一段时间的人都知道，最难的从来不是"找到信息"，而是"决定什么不进日报"。
这篇内容围绕"AI 日报（2026年9月23日）"这个具体产物展开，把一份日报从选题、筛选、验证到成稿的完整链路拆开讲。适合两类人看：一是正在做类似信息聚合产品的开发者，二是想建立自己信息筛选体系的技术从业者。我不会只给一个"看起来很美"的流程，而是把中间那些反复调整的判断标准、踩过的坑、以及为什么最终选择某种结构的原因都摊开来说。日报这种形态看起来简单，但它对"信息密度"和"可读性"的平衡要求极高，做砸了就是一堆链接的堆砌，做好了才是真正能节省读者时间的东西。
先说一个反直觉的结论：一份好的 AI 日报，它的价值有 60% 体现在"被排除的内容"上。你每天能看到的新模型发布、新论文上传、新工具开源，数量远超一般人想象。如果全放进去，读者五分钟就关掉了。所以日报的核心竞争力其实是编辑判断力，而编辑判断力是可以被结构化和流程化的。下面我会从信息源的选取逻辑开始，一步步拆到最终的排版决策。
2. 信息源的分层与权重设计
2.1 为什么不能只靠一个聚合器
我最早做日报的时候，图省事，直接用一个 RSS 聚合器把所有源拉到一个时间线里，按时间倒序排。结果就是：OpenAI 发一条产品更新，和某个不知名实验室上传一篇质量一般的预印本，在时间线上占同样的位置。读者看到的是"信息平权"，但实际体验是"噪音淹没信号"。
后来我改成三层结构。第一层是核心源，数量控制在 8 到 10 个，这些源的内容默认进入候选池，除非当天有重大事件把它们挤掉。第二层是观察源，大概 20 到 30 个，它们的内容需要满足特定条件（比如被核心源引用、或者在社交平台上有明显讨论量）才能进入候选。第三层是长尾源，数量不限，但只用于交叉验证和补充背景，基本不会单独成条。
这个分层的关键在于：权重不是固定的，而是按天动态调整的。比如某天某个观察源发了一篇被多个核心源转发的技术报告，那它当天的权重就会临时提升。我试过用纯静态权重跑了一个月，结果就是日报越来越像"核心源摘要"，失去了发现新东西的能力。
2.2 抓取频率与去重策略
抓取频率这件事，我踩过最大的坑是"抓太勤"。早期我设了每 15 分钟抓一次，结果同一个源在一天内被反复抓取，去重逻辑又写得不够细，导致同一篇内容以不同 URL 参数的形式重复出现。后来我把频率降到核心源每小时一次、观察源每三小时一次，去重逻辑改成基于内容指纹而不是 URL。
内容指纹的做法很简单：把标题和正文前 500 字拼接，去掉标点和空格，取 SHA-256 的前 16 位作为指纹。这样即使 URL 带了不同的追踪参数，或者标题有细微改动，也能识别为同一篇。实测下来，这个改动让重复率从 12% 降到了 1% 以下。
注意：去重不能只看标题。我遇到过两次不同来源用了完全相同的标题，但内容完全不同，一次是两家媒体同时报道同一个事件但角度不同，另一次是标题撞车但主题无关。所以指纹必须包含正文片段。
2.3 时间窗口的取舍
日报的时间窗口看起来应该是"过去 24 小时"，但实际操作中我会把它设成"过去 20 小时到过去 28 小时"这个浮动区间。原因有两个：一是不同源的发布时间戳时区不统一，硬卡 24 小时会漏掉一些边缘内容；二是有些重要内容会在发布后几小时才被社区发现，如果只抓发布时刻，会错过这些"延迟发酵"的条目。
这个浮动窗口的代价是可能重复收录前一天已经出现过的内容。我的处理方式是：在候选池里给每条内容打一个"首次出现时间"标签，如果某条内容在昨天的日报里已经出现过，即使今天又被讨论，也不会再次进入正文，最多放在"持续关注"的附注里。
3. 从候选池到日报正文的筛选逻辑
3.1 三条硬性排除规则
候选池每天大概会有 80 到 150 条内容，最终进入日报正文的通常只有 8 到 12 条。这个压缩比意味着排除规则必须非常明确，不能靠"感觉"。我目前用的是三条硬性规则：
第一条，纯商业融资新闻不进正文。除非融资额超过某个量级且伴随明确的技术路线披露，否则这类内容对技术读者的价值有限。它们会被归入日报末尾的"行业动态"简讯区，用一两句话带过。
第二条，没有可验证细节的"即将发布"类内容不进正文。很多源会发"某公司即将推出某功能"这种消息，但没有任何技术细节或时间表。这类内容我统一放到"传闻与预告"区，并且明确标注"未经证实"。
第三条，纯观点输出且无新事实的内容不进正文。有些博主或分析师会发长文评论某个趋势，但如果全文没有引入新的事实、数据或案例，就不值得占用日报的正文位置。
这三条规则看起来简单，但执行起来需要克制。我刚开始做的时候，总觉得"这条也挺有意思的"，结果日报越做越长，读者反馈是"看不过来"。后来我给自己定了一个硬指标：正文条目数不超过 12 条，超过就必须砍。
3.2 价值评估的四个维度
通过硬性排除的内容，会进入一个四维评分：技术新颖度、实用价值、讨论热度、信息完整度。每个维度 1 到 5 分，总分 20 分。通常总分 14 分以上的才会进入正文候选，12 到 14 分的放在"值得一看"区，12 分以下的直接丢弃。
这四个维度的权重不是平均的。技术新颖度和实用价值各占 30%，讨论热度占 25%，信息完整度占 15%。为什么讨论热度权重这么高？因为日报的读者不只是想知道"发生了什么"，还想知道"社区怎么看"。一条内容如果在技术社区引发了大量讨论，即使它本身的技术含量一般，也值得被收录，因为讨论本身可能包含有价值的信息。
信息完整度权重最低，是因为很多重要内容在刚发布时信息并不完整，后续会有补充。如果因为"信息不完整"就排除，会漏掉很多真正重要的东西。我的做法是：信息完整度低的条目，在日报里会标注"待补充"，并在第二天跟进。
3.3 人工复核的不可替代性
我试过完全自动化的筛选流程，用关键词匹配加评分模型，跑了两周就放弃了。原因是自动化流程无法处理"语境"。举个例子：某天有一条内容是"某模型在某个基准测试上提升了 3 个百分点"，自动化流程会因为它包含"提升"和具体数字而给高分。但实际上，那个基准测试已经被社区广泛认为存在数据泄露问题，这个提升没有意义。这种判断只有人工能做。
所以我的流程是：自动化评分负责排序和初筛，人工复核负责最终决定。人工复核的时间大概每天 30 到 40 分钟，主要做三件事：检查评分最高的 20 条是否有"语境陷阱"，检查评分中等的条目是否有被低估的，以及决定当天的头条。
4. 日报正文的写作与排版决策
4.1 每条内容的固定结构
日报正文里的每一条，我都用固定的四段式结构：一句话概括、关键细节、为什么值得关注、原始链接。这个结构是经过多次调整后定下来的。
一句话概括要求控制在 40 字以内，必须包含"谁做了什么"和"结果是什么"。比如"某实验室发布新模型，在长文本理解任务上超过现有最好水平"，而不是"某实验室有新动作"。
关键细节部分用两到三句话展开，只放最核心的事实：模型规模、训练数据量、评测结果、可用性等。这里的原则是只放可验证的事实，不放形容词。"效果显著提升"这种表述一律不用，改成具体的数字或对比。
为什么值得关注这部分是最能体现编辑判断力的。它要回答的是"这条内容对读者意味着什么"。可能是技术路线的变化、可能是某个长期问题的解决、也可能是对现有工具链的影响。这部分我通常写两到三句，但每句都要有信息量。
原始链接放在最后，用简洁的 Markdown 链接格式。如果内容有多个相关链接（比如论文加代码仓库），会并列放出来。
4.2 头条的选择标准
每天的头条不是评分最高的那条，而是当天最具"信号价值"的那条。信号价值的意思是：这条内容是否预示了某个趋势、是否改变了某个领域的竞争格局、是否解决了某个被广泛关注的问题。
举个例子，如果某天同时有一条"某模型在某个基准上提升 2 个百分点"和一条"某开源项目发布了新的训练框架，支持多种硬件后端"，后者更可能成为头条，因为它影响的是整个生态，而不只是单个模型的性能数字。
头条的选择还有一个隐性标准：它必须是当天最容易被误解的内容。也就是说，如果读者只看标题不看正文，可能会得出错误结论，那这条就适合做头条，因为日报正文可以起到澄清和解释的作用。
4.3 排版上的几个细节
排版这件事，我调整过很多次。最早用纯文本加分隔线，后来用表格，再后来用现在的"标题加短段落"结构。最终选择这个结构的原因是：它在手机和桌面端都有不错的可读性，而且方便读者快速扫读。
每条内容的标题用三级标题，加粗关键词。正文段落控制在三到四行，超过就拆成两段。链接统一放在段落末尾，不单独占一行。条目之间用空行分隔，不用分隔线，因为分隔线在移动端会显得很碎。
还有一个细节：数字和专有名词的格式要统一。比如"3 个百分点"和"3%"不要混用，"大语言模型"和"LLM"不要在同一篇里交替出现。这些细节看起来小，但会影响读者的阅读流畅度。
5. 那些让我重新调整流程的意外情况
5.1 突发重大事件的处理
日报是固定时间发布的，但重大事件不会挑时间。我遇到过两次在日报发布前半小时出现重大新闻的情况。第一次我选择"先发再补"，结果读者在评论区说"这么重要的事都没提"。第二次我改成"延迟发布"，但延迟了 40 分钟，又有读者说"今天怎么晚了"。
后来我定了一个规则：如果重大事件发生在计划发布时间前 60 分钟内，就延迟发布，并在日报开头加一句"因突发新闻，本期延迟发布"。如果发生在 60 分钟之前，就正常发布，但在下一期开头补一条"上期遗漏"。
这个规则的关键是透明。读者能接受延迟，但不能接受"假装没发生"。
5.2 信息源失效与迁移
做日报时间长了，一定会遇到信息源失效的情况。有的是网站改版导致抓取规则失效，有的是源本身停止更新，还有的是内容质量下降。我现在的做法是：每个源都有一个"健康度"指标，连续三天没有产出有效内容，就会触发检查。如果是抓取问题就修规则，如果是源本身的问题就降权或移除。
源迁移这件事比较麻烦。有些团队会换域名或换发布平台，如果只按域名抓取就会漏掉。我的做法是给每个核心源维护一个"作者列表"，即使换了平台，只要作者还在发内容，就能通过作者维度找到。
5.3 读者反馈的筛选
读者反馈是改进日报的重要输入，但不能全听。我收到过两类反馈：一类是"希望增加某个领域的内容"，另一类是"某条内容写得太简略"。第一类反馈我会评估，如果某个领域确实有足够多的优质源，就考虑增加。第二类反馈我会区分：如果是"事实错误"，立刻改；如果是"希望更多细节"，就看这条内容是否值得展开，如果值得，就在下一期做补充。
有一个反馈我印象很深：有读者说"你们的日报越来越像新闻联播了"。这句话让我反思了很久。后来我意识到，问题出在"只报喜不报忧"。日报不应该只收录"成功"和"突破"，也应该收录"失败"和"争议"。比如某个模型被发现有严重缺陷、某个工具被曝出安全问题，这些同样有信息价值。从那以后，我在筛选时会特意保留一定比例的"负面"内容。
6. 工具链的选型与踩坑记录
6.1 抓取层：从 BeautifulSoup 到 Playwright
最早我用 requests 加 BeautifulSoup 做抓取，对于静态页面够用。但后来很多源改成了客户端渲染，requests 拿到的 HTML 里没有正文。我试过用 Selenium，但资源占用太高，跑十几个源就把内存吃满了。后来换成 Playwright，资源占用低很多，而且对异步加载的支持更好。
Playwright 的坑在于：它的默认超时是 30 秒，对于加载慢的源经常超时。我改成 60 秒，并且加了重试机制。另外，有些源会检测无头浏览器，需要设置特定的 User-Agent 和视口大小。这些细节在官方文档里不会写，只能一个个试。
6.2 存储层：SQLite 够用，但要注意并发
候选池和去重指纹都存在 SQLite 里。SQLite 的好处是零配置、单文件、方便备份。但它的写并发能力有限，如果抓取脚本同时写入多个源的数据，会遇到"database is locked"错误。我的解决方式是：抓取脚本只负责把数据写到临时文件，另一个单独的进程负责读取临时文件并写入 SQLite。这样写入是串行的，不会锁冲突。
6.3 排版层：为什么放弃自动生成
我试过用模板自动生成日报的 Markdown，但效果不好。自动生成的内容在格式上没问题，但在"语气"和"重点"上很生硬。比如它会把所有条目的"为什么值得关注"写成同样的句式，读起来像机器写的。后来我改成"自动生成草稿加人工润色"，自动生成负责把事实和链接填进去，人工负责调整语气和重点。这样效率比纯手工高，质量比纯自动好。
7. 关于日报这件事的一些个人体会
做日报这件事，最大的收获不是"知道了更多信息"，而是"学会了判断什么信息不重要"。每天面对上百条候选内容，逼着你去思考：这条内容三个月后还有人记得吗？这条内容对读者的实际工作有影响吗？这条内容是不是只是"看起来热闹"？
我现在的日报流程已经比较稳定了，但每隔几个月还是会做一次复盘，看看哪些环节可以优化。最近在考虑的一件事是：要不要给每条内容加一个"置信度"标签，区分"已证实"和"待证实"。这个想法还在试验阶段，因为加标签会增加读者的认知负担，需要找到合适的呈现方式。
另外，我越来越觉得日报的"附注"部分比正文更有价值。正文是当天的事实，附注是编辑的判断和观察。比如"这条内容和上周某条内容可能有关联"、"这个趋势值得持续关注"这类话，放在附注里比放在正文里更合适。读者如果只看正文，能知道发生了什么；如果看了附注，能知道这意味着什么。
最后分享一个我一直在用的小技巧：每天日报发布后，我会把当天所有被排除的内容标题扫一遍，看看有没有"漏网之鱼"。这个习惯帮我抓到了好几条被评分系统低估的重要内容。排除列表和入选列表同样重要，甚至更重要。
