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日。如果我是这个系统的负责人看到这条空标题我会按下面的清单逐项排查。这份清单你也可以拿去自查。检查项正常表现异常时的可能原因采集条目数与历史均值偏差在20%以内信源失效、网络问题、反爬升级去重后条目数占采集数的30%到60%阈值失当、信源同质化摘要非空率100%模型调用失败、校验缺失摘要实体回查通过率95%以上模型幻觉、骨架提取有误发布前人工确认有记录流程缺失、责任人缺位归档完整性每日成品可检索存储故障、索引未建这份清单里摘要非空率100%和发布前人工确认是两条红线。只要这两条守住就不会出现只有标题没有正文的事故。反过来说一条空标题能发出来说明这两条红线至少破了一条甚至两条都破了。7. 日更产品的长期主义内容之外的三件事做日更产品内容质量是明线还有三条暗线决定它能走多远。第一是节奏感。日更不等于每天一样。周一适合放产业动态周五适合放本周回顾月初适合放月度趋势。节奏感让读者形成预期预期带来粘性。第二是可检索性。前面说过归档的价值这里再强调一次没有检索的归档等于没归档。至少要支持按日期、按主题、按实体三种检索方式否则攒了一年的数据也调不出来。第三是反馈闭环。读者的阅读、转发、纠错都是信号要收集起来反哺系统。我见过做得最好的一个日更产品每期末尾有个本期纠错入口读者指出错误后下一期公开更正。这个动作成本极低但信任度提升非常明显。最后分享一个我自己的小习惯每天早上发布前我会把成品从头到尾读一遍不是检查格式而是问自己一个问题——如果我只读这一份今天AI圈发生了什么我能不能说清楚如果答案是能就发如果答案是含糊就回去补。这个习惯比任何自动化校验都管用因为它逼你对最终交付物负责。那个2026年2月28日的空标题缺的就是这一遍。