1. 当"AI晨报"只剩一个日期：一个被掏空的信息产品样本

2026年2月28日，我照例打开订阅列表，看到一条推送标题写着"AI晨报 | 2026年2月28日"。点进去，正文是空的，关键词是空的，摘要描述也是空的。这不是个例——过去大半年里，我陆续收集到十几条类似的"空壳晨报"，它们有统一的命名格式、统一的日期后缀，唯独没有内容。这件事本身比任何一条AI新闻都更值得聊：一个信息产品，为什么会在最关键的"信息"环节彻底缺位？

先把结论摆在前面："AI晨报"这类日更型信息产品，真正的难点从来不是"生成"，而是"筛选、压缩、校验"这三件事。标题里那个日期是唯一确定的信息，恰恰暴露了整条流水线在最末端断裂——采集可能跑了，摘要可能生成了，但没有任何一个环节对"最终交付物是否为空"负责。我做过两年多的信息聚合类项目，也帮几个团队搭过类似的日报系统，见过太多"看起来在运转、实际上在空转"的案例。这篇就借这个空标题，把日更型AI信息产品的完整链路拆一遍：从信源怎么选、去重怎么做、摘要怎么压、质量怎么兜底，到最终怎么保证"每天都有东西可发"。适合正在做资讯聚合、行业日报、内部情报简报的同行参考，也适合单纯好奇"一条晨报背后要跑多少东西"的读者。

需要说明的是，输入里除了标题什么都没有，所以下文涉及的具体信源、参数、工具选型，都是基于我实际做过的同类项目的常见实践做的合理补全，不是对某个特定系统的还原。但方法论是通用的，你拿去改改就能用。

2. 一条晨报的完整链路：从信源到成品的六个环节

很多人以为"AI晨报"就是调个接口、让模型写一段话。真做过就知道，模型生成只是中间一小段，前后各有一大堆脏活。我把整条链路拆成六段，每一段都有它自己的失败模式，而"空标题"这种事故，往往不是某一段挂了，而是段与段之间的交接没人管。

2.1 信源采集：广度优先还是精度优先

采集环节第一个要做的决策是信源结构。我的经验是分三层：核心源、扩展源、兜底源。核心源是那些更新稳定、质量可控的渠道，比如几个头部厂商的官方博客、几个固定的技术社区板块、几份定期发布的行业报告。扩展源是覆盖面更广但噪声更大的聚合类渠道。兜底源则是当核心源当天没更新时用来填空的备用渠道。

这里有个反直觉的点：信源不是越多越好。我早期做过一个版本，接了四十多个源，结果每天抓回来三百多条原始条目，去重和筛选的成本直接爆炸，最后摘要质量反而下降——因为模型要在大量低质内容里挑重点，注意力被稀释了。后来砍到十二个核心源加八个扩展源，日更条目稳定在六十到八十条，摘要质量肉眼可见地提升。

采集频率也要想清楚。日更产品不需要实时抓取，但也不能一天只跑一次——万一那次跑的时候某个源正好在维护，当天就缺了一块。我的做法是核心源每两小时轮询一次，扩展源每天两次，兜底源每天一次。所有抓取结果先落原始库，不做任何加工，保留原始标题、链接、发布时间、来源标识四个字段。这一步的关键是原始数据必须可追溯，后面出问题要能回查是哪条、哪个源、什么时候抓的。

2.2 去重与聚类：同一件事被写了八遍怎么办

去重是日更产品里最容易被低估的环节。一条重要新闻出来，八个源会从八个角度写八遍，如果不去重，你的晨报就会变成"某公司发布某产品"重复八次的复读机。去重要分两层做：精确去重和语义聚类。

精确去重好办，对标题做归一化（去标点、转小写、去空格）后算哈希，哈希相同直接合并。但真正麻烦的是语义重复——"某团队开源了一个推理框架"和"某团队把推理框架放上了代码托管平台"，字面完全不同，说的是同一件事。这时候要用向量相似度做聚类，把相似度超过阈值的条目归到一组。

阈值怎么定？我试过0.75、0.82、0.88几个值。太低会把不相关的条目误合并，太高则漏掉真正的重复。最后稳定在0.84左右，配合一个规则：如果两条的发布时间相差超过48小时，即使相似度很高也不合并，因为可能是后续进展而非重复报道。聚类之后，每组选一条作为代表条目，选的标准是来源权重最高、信息量最全的那条，其余作为"相关报道"挂在下面，不单独占位。

2.3 摘要压缩：把三百字压成三十字还不丢信息

摘要环节是整条链路的技术核心。我的做法是两段式压缩：先抽取，再生成。抽取阶段用规则加轻量模型，把每条内容里的关键实体（产品名、机构名、数字、时间）和关键动作（发布、开源、收购、下架）标出来，形成一个结构化的"信息骨架"。生成阶段再让模型基于这个骨架写摘要，而不是直接把原文丢给模型自由发挥。

为什么多这一步？因为直接让模型总结长文，它容易"脑补"——原文没说的它给你补上，原文说"可能"它给你写成"确定"。有了信息骨架做约束，模型的发挥空间被限制在骨架范围内，幻觉率能降一大截。我实测过，加骨架约束后，摘要里出现原文没有的实体的情况从大约每十条一次降到每五十条一次。

摘要长度也要控制。晨报的定位是"扫一眼就知道今天发生了什么"，所以每条摘要控制在40到60字，超过80字读者就不看了。如果一条内容实在压不到60字，说明它信息密度太高，应该拆成两条，而不是硬压。

2.4 排序与配比：什么该放头条

排序不是简单按时间倒序。我的排序公式大致是：来源权重 × 0.4 + 内容热度 × 0.3 + 时效衰减 × 0.2 + 人工干预 × 0.1。来源权重是给每个源预设的分值，热度用互动数据或引用次数估算，时效衰减是越新的分越高，人工干预留给编辑手动置顶。

配比也很关键。一份好的晨报不能全是某一家厂商的消息，也不能全是技术、没有产业动态。我一般按**技术40%、产业30%、工具20%、杂项10%**的比例来配，如果某类当天内容不足，就从扩展源里补，实在补不上就如实标注"今日该类无更新"，而不是硬凑。

2.5 校验与兜底：为什么"空标题"能发出来

回到开头那个问题。一条只有标题、没有正文的晨报能发出来，说明校验环节缺失或者形同虚设。我在自己的系统里加了三道校验：

第一道是非空校验，正文长度低于阈值直接拦截，不允许进入发布队列。第二道是完整性校验，检查每条摘要是否包含实体和动作，缺任何一个就标记为待人工复核。第三道是总量校验，如果当天有效条目少于某个下限（比如十条），系统不自动发布，而是通知人工介入，要么补采要么手动编写。

这三道校验加起来不到五十行代码，但能拦住绝大多数"空壳"事故。很多团队的问题不是技术不够，而是没人对最终交付物负责——采集的人觉得摘要该管，摘要的人觉得发布该管，发布的人觉得采集没给东西。所以我的建议是：明确一个"发布责任人"角色，哪怕就是你自己，每天发布前必须肉眼过一遍成品。

2.6 发布与归档：发出去只是开始

发布之后要做两件事：归档和反馈。归档是把每天的成品存下来，按日期建索引，方便以后检索"某件事是哪天第一次出现的"。反馈是记录每条内容的后续表现——阅读量、转发量、有没有被后续事件推翻。这些数据反过来用来调信源权重和排序参数。

我特别想强调归档的价值。日更产品做久了，最大的资产不是某一天的晨报，而是时间序列。你能回答"某个技术方向在过去半年是怎么演进的""某家厂商的发布节奏是什么样"，这种纵向视角是单条新闻给不了的。所以从第一天起就要把数据结构设计好，别等到攒了半年数据才发现没法按主题聚合。

3. 摘要质量的三个隐形杀手：幻觉、同质化、时效错位

链路跑通只是及格线，真正决定晨报好不好看的是摘要质量。我踩过的坑里，有三个问题反复出现，而且都不容易靠单点修复解决。

3.1 幻觉：模型比你更"懂"那条新闻

幻觉是摘要生成的头号敌人。模型在压缩信息时，会不自觉地"补全"它认为合理的细节。比如原文说"某团队发布了新版本"，模型可能写成"某团队发布了性能提升30%的新版本"——那个30%是它从训练数据里带出来的，原文根本没有。

对抗幻觉最有效的办法不是换更强的模型，而是约束生成空间。我前面说的信息骨架是一层约束，还有一层是禁止性提示词：明确告诉模型"只能使用骨架中出现的信息，不得添加任何数字、时间、机构名"。另外，生成后要做一次实体回查，把摘要里出现的所有实体拿去和原文比对，原文没有的直接标红。

还有一个土办法但很管用：让模型自己标注置信度。生成摘要后追加一问"这条摘要中哪些部分是你推断的"，模型标为推断的部分人工重点复核。虽然模型的自评不完全可靠，但能筛出大部分高风险条目。

3.2 同质化：十条摘要读起来像一条

日更产品做久了会出现一种尴尬：连续几天的摘要读起来都差不多，因为底层新闻本身就相似——今天这家发个模型，明天那家发个模型，摘要写出来都是"某机构发布某模型，参数若干，性能提升若干"。读者看三天就腻了。

破解同质化要从摘要的切入角度下手。同样是"发布新模型"，有的可以从技术路线切入，有的可以从应用场景切入，有的可以从竞争格局切入。我的做法是给摘要生成加一个角度轮换机制：系统记录最近七天用过的切入角度，生成新摘要时优先选择近期没用过的角度。这样即使新闻本身相似，读起来也有新鲜感。

另一个办法是增加对比信息。摘要里带一句"相比上一版本"或"与同类产品相比"，信息量立刻不一样。但这要求系统有历史数据积累，所以又回到归档的重要性——没有历史，就做不了对比。

3.3 时效错位：把旧闻当新闻发

时效错位有两种表现：一是把几天前的旧闻当成今天的新闻发，二是把刚发生的事标成"昨日回顾"。前者通常是去重没做好，旧条目没被过滤掉；后者是时间字段处理有误，把抓取时间当成了发布时间。

解决办法是严格区分三个时间：事件发生时间、内容发布时间、系统抓取时间。排序和标注都以事件发生时间为准，抓取时间只用于排查问题。如果一条内容的事件发生时间无法确定，宁可标注"时间不详"也不要瞎猜。我见过一个系统把抓取时间当发布时间，结果周末抓的周一发，读者以为是周一的新鲜事，其实是周六的旧闻，信任度直接崩。

4. 工具选型：为什么我没用"全自动一条龙"方案

市面上有不少"全自动资讯聚合"的工具和框架，号称接上信源就能自动出日报。我试过几个，最后都放弃了，转而自己搭。原因不复杂：全自动方案在"最后一公里"上不可靠。

4.1 全自动方案的三个硬伤

第一个硬伤是信源适配。每个源的页面结构、更新规律、反爬策略都不一样，通用工具往往只能处理标准RSS，遇到非标准源就抓瞎。而真正有价值的信源，恰恰经常是非标准的。

第二个硬伤是质量不可控。全自动方案为了追求"零人工"，会把所有环节都交给模型，包括那些本该人工判断的环节——比如某条内容该不该上头条、某条摘要的措辞是否准确。结果就是产出稳定但平庸，偶尔还会出大错。

第三个硬伤是无法积累。全自动方案通常不保留中间数据，你只能看到最终成品，看不到采集了什么、去重去掉了什么、摘要基于什么生成的。出了问题没法排查，也没法用历史数据优化。

4.2 我的技术栈组合

我最后用的是一套"半自动"组合：采集用轻量爬虫框架加定时任务，去重和聚类用向量库加相似度计算，摘要用通用大模型加提示词约束，校验用规则引擎，发布用静态站点生成。整套东西跑在一台普通云主机上，每天的处理量完全够用。

关键不是用了什么工具，而是每个环节都留了人工介入的口子。采集可以手动补源，去重可以手动合并，摘要可以手动改写，发布前必须人工确认。这些口子平时不用，但出事的时候能救命。

4.3 成本账：一天到底花多少钱

很多人关心成本。我算过一笔账：采集和去重基本不花钱，主要成本在摘要生成的模型调用上。按每天八十条、每条摘要调用一次模型算，用中等规模的模型，一天的成本在几块钱到十几块钱之间，一个月不到五百块。如果用更小的模型加更严格的约束，成本还能再降一半。

这个成本对个人项目完全可接受，对企业内部简报更是九牛一毛。所以不要为了省这点钱去用质量差的模型，摘要质量下降带来的信任损失远超那点调用费。

5. 实操避坑：我踩过的五个坑和对应的解法

前面讲的是方法论，这一节讲具体的坑。这些都是我在实际跑日更产品时踩出来的，每条都对应一个具体的失败场景。

5.1 坑一：时区没统一，日期对不上

最早我的系统用服务器本地时间，结果跨时区的源抓回来时间全乱，有的条目显示"明天发布"。解法很简单：所有时间统一存UTC，展示时再转目标时区。这个坑看起来低级，但真有不少系统栽在上面。

5.2 坑二：去重阈值写死，换一批源就失效

去重阈值我一开始写死在代码里，后来换了一批信源，发现重复率飙升——因为新源的表述风格和旧源差异大，原来的阈值不适用了。解法是把阈值做成可配置项，并且加一个监控：每天统计去重前后的条目数比例，比例异常时告警。现在我每周会看一次这个比例，根据实际情况微调阈值。

5.3 坑三：摘要长度一刀切，长文被压变形

我一开始规定所有摘要不超过50字，结果遇到信息密度高的内容，压到50字就丢关键信息。解法是分级长度：普通条目40到60字，重要条目可以到80字，特重要条目允许到120字并单独成段。长度分级由排序分数决定，分数越高允许越长。

5.4 坑四：没有失败重试，一个源挂了就缺一块

有次某个核心源临时维护，抓取失败，系统直接跳过，当天晨报就少了这个源的内容。解法是加失败重试和降级：抓取失败先重试三次，间隔递增；三次都失败则标记该源为异常，同时从扩展源里找替代内容补位，并在成品里注明"某源今日不可用"。

5.5 坑五：发布前不预览，格式错乱直接推

最惨的一次是Markdown格式没转好，推出去的晨报全是乱码。解法是发布前强制预览，系统生成预览页面，人工确认无误才推。这个步骤花不了一分钟，但能避免社死。

6. 从"空标题"反推：一个健康日更系统的自检清单

回到最初那个"AI晨报 | 2026年2月28日"。如果我是这个系统的负责人，看到这条空标题，我会按下面的清单逐项排查。这份清单你也可以拿去自查。

这份清单里，"摘要非空率100%"和"发布前人工确认"是两条红线。只要这两条守住，就不会出现"只有标题没有正文"的事故。反过来说，一条空标题能发出来，说明这两条红线至少破了一条，甚至两条都破了。

7. 日更产品的长期主义：内容之外的三件事

做日更产品，内容质量是明线，还有三条暗线决定它能走多远。

第一是节奏感。日更不等于每天一样。周一适合放产业动态，周五适合放本周回顾，月初适合放月度趋势。节奏感让读者形成预期，预期带来粘性。

第二是可检索性。前面说过归档的价值，这里再强调一次：没有检索的归档等于没归档。至少要支持按日期、按主题、按实体三种检索方式，否则攒了一年的数据也调不出来。

第三是反馈闭环。读者的阅读、转发、纠错都是信号，要收集起来反哺系统。我见过做得最好的一个日更产品，每期末尾有个"本期纠错"入口，读者指出错误后下一期公开更正。这个动作成本极低，但信任度提升非常明显。

最后分享一个我自己的小习惯：每天早上发布前，我会把成品从头到尾读一遍，不是检查格式，而是问自己一个问题——"如果我只读这一份，今天AI圈发生了什么我能不能说清楚？"如果答案是能，就发；如果答案是含糊，就回去补。这个习惯比任何自动化校验都管用，因为它逼你对最终交付物负责。那个"2026年2月28日"的空标题，缺的就是这一遍。