1. 一份 AI 日报的诞生从信息洪流到每日必读每天早上七点我的手机闹钟还没响浏览器里已经躺着十几个标签页——arXiv 的新论文、几个头部实验室的博客更新、GitHub Trending、还有一堆行业群里的截图和链接。三年前我开始做一件事把这些碎片整理成一份能让人十分钟读完的 AI 日报。到今天这份日报已经迭代了上千期2026 年 9 月 25 日这一期正好是我重新设计整个流水线之后的第一个完整版本。很多人以为做日报就是复制粘贴加个标题真上手才知道信息筛选、去重、可信度判断、摘要压缩、排版分发每一步都是坑。这份日报解决的核心问题很具体在信息过载的环境里用最低的阅读成本让读者抓住当天真正值得关注的 AI 动态。它适合三类人参考——想自己搭一套信息聚合流程的开发者、需要每天跟踪行业但没时间刷全网的从业者、以及想把日报这种内容形态做成产品的独立创作者。我做的不是新闻搬运而是一条从采集到分发的完整内容流水线。下面我把这套东西拆开讲包括为什么这么设计、每个环节怎么落地、踩过哪些坑以及 9 月 25 日这一期具体是怎么跑出来的。你照着做大概率能搭出一份属于自己的日报哪怕不做日报这套信息处理方法也能直接用在你的日常工作中。2. 整体设计与思路拆解为什么是流水线而不是手工活2.1 日报的本质是一条内容加工流水线刚开始做日报那会儿我全靠手工早上刷一遍信息源看到有意思的就复制到文档里手动改改措辞排个版发出去。前两周还行到第三周就崩了——漏掉重要消息、重复内容、格式不统一最要命的是每天要花两个多小时根本坚持不下去。后来我想明白了日报这东西的本质不是写作而是加工。原料是全网的信息成品是一份结构化的简报中间需要的是采集、清洗、筛选、摘要、排版、分发六个环节。既然是加工那就该用流水线的思路来做每个环节职责单一环节之间用标准化的数据格式衔接任何一个环节出问题都能单独替换。这个思路带来的最大好处是可维护。比如某天某个信息源挂了我只需要换掉采集环节里的一个适配器后面的流程完全不受影响。再比如我想调整摘要风格只改摘要环节的提示词就行不用动其他部分。2.2 为什么选择半自动而不是全自动这里有个关键取舍全自动流水线听起来很酷但实际做下来纯自动的日报质量很难看。原因很简单——AI 摘要会漏掉上下文自动去重会误杀相关但不同的内容自动排序会把真正重要的东西埋掉。我最后选的是半自动方案采集、清洗、初步摘要全自动但最终的筛选和定稿保留人工介入。具体来说机器负责把 200 条原始信息压缩成 30 条候选我再花 15 分钟从中挑出 8 到 10 条调整措辞和排序。这样既保证了效率整个流程 30 分钟内跑完又保证了质量人工把关最后一道。提示不要一上来就追求全自动。先把人工环节跑通记录下你每天做判断的标准等标准稳定了再逐步自动化。我见过太多人一上来就写复杂的工作流结果调了两周发现还不如手工快。2.3 信息源的选型逻辑少而精分层级信息源的选择直接决定日报的质量上限。我的原则是分层级、控数量而不是越多越好。目前我维护的信息源分三层层级类型数量作用更新频率核心层头部实验室博客、顶会论文列表5-8 个保证不漏重大进展每日检查扩展层行业媒体、技术社区热榜10-15 个捕捉应用层动态每日检查补充层社交平台讨论、开源项目更新按需发现边缘信号每周扫描核心层是必须每天看的扩展层用来补充视角补充层则是有精力就看。这个分层的好处是即使某天时间紧张只看核心层也能保证日报不空。选信息源有个反直觉的经验宁可少选几个高质量源也不要贪多。我早期订阅了 50 多个源结果每天光筛选就累得够呛而且大量内容重复。砍到 20 个以内之后效率反而上去了。2.4 数据格式的统一一切以 JSON 为中心流水线能跑起来的前提是环节之间能对话。我定的规矩很简单所有环节的输入输出都是 JSON。采集环节输出原始条目数组清洗环节输出标准化条目摘要环节输出带摘要的条目排版环节消费最终条目。一条标准化条目的结构大概是这样{ id: unique-hash, title: 条目标题, source: 来源名称, url: 原始链接, published_at: 2026-09-25T08:30:00Z, raw_content: 原始正文或摘要, summary: 加工后的摘要, category: 模型/应用/开源/政策, importance: 3, tags: [标签1, 标签2] }这个结构看起来简单但它是整个流水线的骨架。id用于去重importance用于排序category用于分组tags用于检索。字段一旦定下来后面所有环节都围绕它工作改起来也方便。3. 核心细节解析与实操要点每个环节的坑与技巧3.1 采集环节稳定比快更重要采集环节最容易犯的错是追求实时。我早期用轮询的方式每 5 分钟抓一次结果经常被目标站点限流还浪费资源。后来改成定时批量采集每天早上六点跑一次把所有源一次性抓完稳定得多。采集的技术选型上我推荐两条路线RSS/Atom 优先如果目标站点提供 RSS直接用。这是最稳定的方式解析简单不容易被反爬。HTML 解析兜底没有 RSS 的站点用解析库提取。这里要注意选择器要写得宽容一点别依赖太具体的 DOM 路径否则站点一改版就全挂。采集环节的三个实操要点设置合理的超时和重试。单个源超时 10 秒失败重试 2 次重试间隔递增。别让一个挂掉的源拖垮整个流程。记录采集日志。每个源抓了多少条、耗时多少、有没有报错都记下来。出问题时能快速定位。保存原始数据。抓到的原始内容先存一份别急着清洗。万一后面发现清洗逻辑有问题还能回溯。注意采集频率要克制。很多站点对高频访问不友好一天抓一两次足够了。日报本来就是日报没必要做到分钟级。3.2 清洗与去重日报质量的分水岭清洗环节决定了日报的干净程度。这一步做不好读者会看到大量重复、残缺、格式混乱的内容。我的清洗流程分四步第一步字段标准化。把不同来源的字段映射到统一结构。比如有的源用pubDate有的用published统一成published_at有的源时间是本地时间统一转成 UTC。第二步正文提取。很多源的 RSS 只给摘要需要抓取原文提取正文。这里推荐用成熟的正文提取库别自己写正则准确率差太多。第三步去重。去重是清洗环节的核心。我用的策略是标题相似度 URL 归一化双重判断URL 归一化去掉追踪参数、统一协议和域名大小写相同 URL 直接判重。标题相似度用编辑距离或词向量算相似度超过阈值我设的 0.85判为重复。去重有个坑同一事件的不同报道不该被当成重复。比如两家媒体都报道了同一个模型发布标题不同、角度不同这时候应该保留信息量更大的那条而不是简单删掉。我的做法是去重时保留来源权重高 正文长的那条。第四步质量过滤。过滤掉太短的内容少于 100 字、纯广告、以及明显是标题党的条目。3.3 摘要生成提示词设计比模型选择更重要摘要环节是很多人最关心的部分。我的经验是模型选择的影响远小于提示词设计。同一个模型提示词写得好和写得差输出质量能差一个档次。我用的摘要提示词核心要素有四个角色设定明确告诉模型你是一个 AI 行业分析师为专业读者写简报。输出结构规定摘要必须包含发生了什么 为什么重要 关键数据三部分。长度约束每条摘要控制在 80 到 120 字太短信息不足太长读者没耐心。风格约束要求客观、具体、不用形容词堆砌禁止震撼颠覆这类词。一个实际用的提示词模板大概长这样你是一名 AI 行业分析师为专业读者撰写每日简报。 请将以下内容压缩成 80-120 字的摘要包含三部分 1. 核心事实谁做了什么 2. 关键数据或技术细节 3. 对行业的影响或意义 要求客观具体不使用夸张词汇不添加原文没有的信息。 原文{content}摘要环节的实操心得批量处理要控制并发。一次发太多请求容易被限流我一般控制在 5 到 10 个并发。保留原文对照。摘要生成后我会把原文和摘要并排存着方便人工复核时快速判断。对长文分段摘要再合并。超过模型上下文长度的内容先分段摘要再合并成一条效果比直接截断好。3.4 分类与排序让读者一眼看到重点分类和排序决定了日报的可读性。我的分类体系是固定的四类模型进展、应用落地、开源动态、行业政策。每类下面按重要性排序。重要性打分我用的是规则 模型结合的方式规则部分来源权重核心层 2、是否含关键实体如知名机构 1、是否有具体数据1。模型部分让模型判断这条内容对行业的影响程度输出 1 到 5 分。两者加权得到最终分数。这个打分不追求绝对准确只要能保证重要的排在前面就够了。提示排序规则要定期回顾。我每个月会看一遍历史日报检查有没有当时排前面但事后看并不重要的条目据此调整权重。4. 实操过程与核心环节实现9 月 25 日这一期是怎么跑出来的4.1 环境准备与依赖清单先说环境。整套流水线跑在一台普通的云服务器上配置不高2 核 4G 足够。依赖清单如下# 核心依赖 python3.10 requests # HTTP 请求 feedparser # RSS 解析 beautifulsoup4 # HTML 解析 readability-lxml # 正文提取 scikit-learn # 相似度计算 openai # 模型调用或任意兼容接口 jinja2 # 模板渲染安装就一行命令pip install requests feedparser beautifulsoup4 readability-lxml scikit-learn openai jinja2目录结构我习惯这样组织ai-daily/ ├── config/ │ └── sources.yaml # 信息源配置 ├── data/ │ ├── raw/ # 原始采集数据 │ └── processed/ # 清洗后数据 ├── scripts/ │ ├── collect.py # 采集 │ ├── clean.py # 清洗去重 │ ├── summarize.py # 摘要 │ └── render.py # 排版 ├── templates/ │ └── daily.md.j2 # 日报模板 └── output/ └── 2026-09-25.md # 最终日报这个结构的好处是每个环节独立成脚本可以单独运行、单独调试。4.2 采集脚本的关键实现采集脚本的核心逻辑是读配置、遍历源、抓取、存原始数据。关键代码片段import feedparser import requests from datetime import datetime, timezone def collect_rss(source): feed feedparser.parse(source[url]) items [] for entry in feed.entries: items.append({ title: entry.get(title, ), url: entry.get(link, ), published_at: entry.get(published, ), raw_content: entry.get(summary, ), source: source[name], }) return items def collect_html(source): resp requests.get(source[url], timeout10) resp.raise_for_status() # 用配置里的选择器提取 soup BeautifulSoup(resp.text, html.parser) items [] for node in soup.select(source[selector]): items.append({ title: node.select_one(source[title_sel]).get_text(stripTrue), url: node.select_one(a)[href], raw_content: node.get_text(stripTrue), source: source[name], }) return items采集时我加了两个保护超时设置和异常捕获。单个源失败不影响其他源失败的源记入日志第二天再试。9 月 25 日这一期采集环节一共跑了 22 个源成功 20 个失败 2 个一个超时一个改版导致选择器失效。总共抓到 187 条原始条目。4.3 清洗去重的参数计算清洗环节最关键的是去重阈值。这个阈值怎么定我的方法是用历史数据做实验。具体做法取过去一周的条目人工标注哪些是重复的然后跑不同阈值下的去重结果算准确率和召回率。我试过 0.7、0.8、0.85、0.9 四个值结果如下阈值准确率召回率说明0.700.820.95误杀较多相关但不同的内容被删0.800.890.91平衡较好0.850.930.86我最终选的偏保守0.900.960.72漏掉不少重复我选 0.85是因为宁可漏掉重复也不要误杀。重复内容读者能自己跳过但误杀会让读者错过信息。9 月 25 日这一期187 条原始条目经过清洗去重后剩下 94 条。去掉了 93 条其中大部分是同一事件的重复报道。4.4 摘要生成的批量处理摘要环节我用的是批量处理一次发 10 条控制并发。核心代码import asyncio from openai import AsyncOpenAI client AsyncOpenAI() async def summarize_one(item): prompt f你是一名 AI 行业分析师为专业读者撰写每日简报。 请将以下内容压缩成 80-120 字的摘要包含三部分 1. 核心事实谁做了什么 2. 关键数据或技术细节 3. 对行业的影响或意义 要求客观具体不使用夸张词汇不添加原文没有的信息。 原文{item[raw_content][:2000]} resp await client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.3, ) item[summary] resp.choices[0].message.content.strip() return item async def summarize_batch(items, batch_size10): results [] for i in range(0, len(items), batch_size): batch items[i:ibatch_size] results.extend(await asyncio.gather(*[summarize_one(it) for it in batch])) await asyncio.sleep(1) # 控制节奏 return results这里有几个参数值得说temperature 设 0.3摘要要稳定不需要创造性低温度更合适。原文截断到 2000 字太长的原文直接截断比分段摘要再合并简单效果也够用。批次间 sleep 1 秒避免触发限流。9 月 25 日这一期94 条内容全部生成摘要耗时约 4 分钟。4.5 人工定稿与排版机器跑完之后进入人工环节。我打开处理好的数据按重要性排序从 94 条里挑出 10 条作为当日重点其余作为其他动态简列。挑选的标准是三条是否有实质进展纯观点、纯预测的降权。是否影响面广只影响小众的降权。是否有可验证的信息只有传闻没有实锤的降权。9 月 25 日这一期最终定稿 10 条重点 12 条简讯。排版用 Jinja2 模板渲染模板大概长这样# AI 日报{{ date }} ## 今日重点 {% for item in highlights %} ### {{ loop.index }}. {{ item.title }} {{ item.summary }} 来源{{ item.source }} {% endfor %} ## 其他动态 {% for item in briefs %} - {{ item.title }}{{ item.source }} {% endfor %}排版环节的实操心得模板要留手动调整的口子。我经常在渲染后手动改几条的措辞所以模板不要写得太死留出可编辑的空间。5. 常见问题与排查技巧实录5.1 采集失败从日志里找线索采集失败是最常见的问题。我的排查顺序是看日志每个源的采集结果都记了日志先看是超时、403、还是解析失败。手动访问用浏览器打开目标 URL确认站点是否正常。检查选择器如果是解析失败多半是站点改版了用开发者工具重新找选择器。常见问题速查表现象可能原因解决方法超时站点慢或网络问题增加超时时间加重试403被识别为爬虫加 User-Agent降低频率解析为空选择器失效重新检查 DOM 结构内容乱码编码问题显式指定编码重复抓取没有去重在采集层加 URL 去重注意遇到 403 不要硬刚。降低频率、加合理的 User-Agent 通常能解决。如果站点明确不欢迎抓取就换源别较劲。5.2 摘要质量差先查提示词再查模型摘要质量差的表现有几种太短、太长、跑题、加戏。排查顺序太短或太长检查提示词里的长度约束是否明确。我一般会给出具体字数范围而不是简短一点。跑题检查原文是否被正确传入。有时候正文提取失败传进去的是导航栏文字摘要自然跑题。加戏模型添加了原文没有的信息。这时候要降低 temperature并在提示词里强调不添加原文没有的信息。我踩过的一个坑早期提示词写请总结以下内容模型经常输出这篇文章介绍了……这种元描述。后来改成请将以下内容压缩成摘要直接输出摘要内容不要有这篇文章之类的引导语问题就解决了。5.3 去重误杀宁可漏杀不可错杀去重误杀是让人最难受的问题——明明是不同的内容被当成重复删掉了。我的应对策略提高阈值从 0.8 提到 0.85减少误杀。加白名单对特定来源或特定关键词的条目跳过去重。人工复核去重结果保留一份被删列表人工抽查。有一次我把两家媒体对同一模型的不同角度报道误判为重复删掉了其中一条结果那条恰好包含了关键的技术参数。从那以后我就加了被删列表复核机制。5.4 流水线跑得慢定位瓶颈整套流水线正常 30 分钟内跑完。如果某天特别慢通常是这几个原因某个源响应慢拖累了整体。解决方法是给每个源设独立超时。摘要并发太高被限流降低并发增加间隔。数据量突然增大比如某天有重大事件条目数翻倍。这时候可以临时提高筛选阈值减少进入摘要环节的数量。我一般会在每个环节记录耗时跑完之后看一眼哪个环节最慢针对性优化。5.5 内容同质化如何保持日报的独特性做久了会发现日报内容越来越同质化——大家都在报同样的东西。我的应对方法有三个加自己的判断每条重点后面加一句我的看法哪怕只有一句话也能让日报有辨识度。挖掘边缘信号核心层的信息大家都报但补充层的小众讨论往往只有我在跟。做纵向对比把当天的事件和历史联系起来比如这是某机构今年第三次发布类似成果这种上下文是别人没有的。提示日报的价值不在于全而在于选和评。同样的信息你的筛选标准和点评角度才是核心竞争力。6. 我个人的一些实操体会做这份日报到现在最大的体会是工具和流程都是次要的判断力才是核心。流水线能帮你省时间但哪条重要、哪条该删、哪条该怎么写这些判断机器替代不了。另一个体会是别追求完美。我早期总想把每条摘要都打磨到极致结果每天花三四个小时坚持不下去。后来想通了日报是日报稳定输出比单期质量更重要。现在我的标准是80 分就发反而坚持了上千期。最后分享一个小技巧建立自己的事件库。每次遇到重大事件记一笔——时间、主体、关键数据。时间长了这个库就成了你做纵向对比的素材来源也是日报独特性的来源。9 月 25 日这一期里有一条某开源项目 star 数破十万我就是翻了事件库才发现这个项目从发布到破十万只用了四个月这个对比一加进去条目的信息量立刻上去了。这套流水线后续还能扩展的方向不少比如加一个周报汇总环节把一周的重点自动聚合或者加一个主题追踪对特定技术方向做持续跟踪。但那是下一步的事了眼下先把每天的日报稳定跑好。
从信息洪流到每日必读：AI日报自动化流水线实战
1. 一份 AI 日报的诞生从信息洪流到每日必读每天早上七点我的手机闹钟还没响浏览器里已经躺着十几个标签页——arXiv 的新论文、几个头部实验室的博客更新、GitHub Trending、还有一堆行业群里的截图和链接。三年前我开始做一件事把这些碎片整理成一份能让人十分钟读完的 AI 日报。到今天这份日报已经迭代了上千期2026 年 9 月 25 日这一期正好是我重新设计整个流水线之后的第一个完整版本。很多人以为做日报就是复制粘贴加个标题真上手才知道信息筛选、去重、可信度判断、摘要压缩、排版分发每一步都是坑。这份日报解决的核心问题很具体在信息过载的环境里用最低的阅读成本让读者抓住当天真正值得关注的 AI 动态。它适合三类人参考——想自己搭一套信息聚合流程的开发者、需要每天跟踪行业但没时间刷全网的从业者、以及想把日报这种内容形态做成产品的独立创作者。我做的不是新闻搬运而是一条从采集到分发的完整内容流水线。下面我把这套东西拆开讲包括为什么这么设计、每个环节怎么落地、踩过哪些坑以及 9 月 25 日这一期具体是怎么跑出来的。你照着做大概率能搭出一份属于自己的日报哪怕不做日报这套信息处理方法也能直接用在你的日常工作中。2. 整体设计与思路拆解为什么是流水线而不是手工活2.1 日报的本质是一条内容加工流水线刚开始做日报那会儿我全靠手工早上刷一遍信息源看到有意思的就复制到文档里手动改改措辞排个版发出去。前两周还行到第三周就崩了——漏掉重要消息、重复内容、格式不统一最要命的是每天要花两个多小时根本坚持不下去。后来我想明白了日报这东西的本质不是写作而是加工。原料是全网的信息成品是一份结构化的简报中间需要的是采集、清洗、筛选、摘要、排版、分发六个环节。既然是加工那就该用流水线的思路来做每个环节职责单一环节之间用标准化的数据格式衔接任何一个环节出问题都能单独替换。这个思路带来的最大好处是可维护。比如某天某个信息源挂了我只需要换掉采集环节里的一个适配器后面的流程完全不受影响。再比如我想调整摘要风格只改摘要环节的提示词就行不用动其他部分。2.2 为什么选择半自动而不是全自动这里有个关键取舍全自动流水线听起来很酷但实际做下来纯自动的日报质量很难看。原因很简单——AI 摘要会漏掉上下文自动去重会误杀相关但不同的内容自动排序会把真正重要的东西埋掉。我最后选的是半自动方案采集、清洗、初步摘要全自动但最终的筛选和定稿保留人工介入。具体来说机器负责把 200 条原始信息压缩成 30 条候选我再花 15 分钟从中挑出 8 到 10 条调整措辞和排序。这样既保证了效率整个流程 30 分钟内跑完又保证了质量人工把关最后一道。提示不要一上来就追求全自动。先把人工环节跑通记录下你每天做判断的标准等标准稳定了再逐步自动化。我见过太多人一上来就写复杂的工作流结果调了两周发现还不如手工快。2.3 信息源的选型逻辑少而精分层级信息源的选择直接决定日报的质量上限。我的原则是分层级、控数量而不是越多越好。目前我维护的信息源分三层层级类型数量作用更新频率核心层头部实验室博客、顶会论文列表5-8 个保证不漏重大进展每日检查扩展层行业媒体、技术社区热榜10-15 个捕捉应用层动态每日检查补充层社交平台讨论、开源项目更新按需发现边缘信号每周扫描核心层是必须每天看的扩展层用来补充视角补充层则是有精力就看。这个分层的好处是即使某天时间紧张只看核心层也能保证日报不空。选信息源有个反直觉的经验宁可少选几个高质量源也不要贪多。我早期订阅了 50 多个源结果每天光筛选就累得够呛而且大量内容重复。砍到 20 个以内之后效率反而上去了。2.4 数据格式的统一一切以 JSON 为中心流水线能跑起来的前提是环节之间能对话。我定的规矩很简单所有环节的输入输出都是 JSON。采集环节输出原始条目数组清洗环节输出标准化条目摘要环节输出带摘要的条目排版环节消费最终条目。一条标准化条目的结构大概是这样{ id: unique-hash, title: 条目标题, source: 来源名称, url: 原始链接, published_at: 2026-09-25T08:30:00Z, raw_content: 原始正文或摘要, summary: 加工后的摘要, category: 模型/应用/开源/政策, importance: 3, tags: [标签1, 标签2] }这个结构看起来简单但它是整个流水线的骨架。id用于去重importance用于排序category用于分组tags用于检索。字段一旦定下来后面所有环节都围绕它工作改起来也方便。3. 核心细节解析与实操要点每个环节的坑与技巧3.1 采集环节稳定比快更重要采集环节最容易犯的错是追求实时。我早期用轮询的方式每 5 分钟抓一次结果经常被目标站点限流还浪费资源。后来改成定时批量采集每天早上六点跑一次把所有源一次性抓完稳定得多。采集的技术选型上我推荐两条路线RSS/Atom 优先如果目标站点提供 RSS直接用。这是最稳定的方式解析简单不容易被反爬。HTML 解析兜底没有 RSS 的站点用解析库提取。这里要注意选择器要写得宽容一点别依赖太具体的 DOM 路径否则站点一改版就全挂。采集环节的三个实操要点设置合理的超时和重试。单个源超时 10 秒失败重试 2 次重试间隔递增。别让一个挂掉的源拖垮整个流程。记录采集日志。每个源抓了多少条、耗时多少、有没有报错都记下来。出问题时能快速定位。保存原始数据。抓到的原始内容先存一份别急着清洗。万一后面发现清洗逻辑有问题还能回溯。注意采集频率要克制。很多站点对高频访问不友好一天抓一两次足够了。日报本来就是日报没必要做到分钟级。3.2 清洗与去重日报质量的分水岭清洗环节决定了日报的干净程度。这一步做不好读者会看到大量重复、残缺、格式混乱的内容。我的清洗流程分四步第一步字段标准化。把不同来源的字段映射到统一结构。比如有的源用pubDate有的用published统一成published_at有的源时间是本地时间统一转成 UTC。第二步正文提取。很多源的 RSS 只给摘要需要抓取原文提取正文。这里推荐用成熟的正文提取库别自己写正则准确率差太多。第三步去重。去重是清洗环节的核心。我用的策略是标题相似度 URL 归一化双重判断URL 归一化去掉追踪参数、统一协议和域名大小写相同 URL 直接判重。标题相似度用编辑距离或词向量算相似度超过阈值我设的 0.85判为重复。去重有个坑同一事件的不同报道不该被当成重复。比如两家媒体都报道了同一个模型发布标题不同、角度不同这时候应该保留信息量更大的那条而不是简单删掉。我的做法是去重时保留来源权重高 正文长的那条。第四步质量过滤。过滤掉太短的内容少于 100 字、纯广告、以及明显是标题党的条目。3.3 摘要生成提示词设计比模型选择更重要摘要环节是很多人最关心的部分。我的经验是模型选择的影响远小于提示词设计。同一个模型提示词写得好和写得差输出质量能差一个档次。我用的摘要提示词核心要素有四个角色设定明确告诉模型你是一个 AI 行业分析师为专业读者写简报。输出结构规定摘要必须包含发生了什么 为什么重要 关键数据三部分。长度约束每条摘要控制在 80 到 120 字太短信息不足太长读者没耐心。风格约束要求客观、具体、不用形容词堆砌禁止震撼颠覆这类词。一个实际用的提示词模板大概长这样你是一名 AI 行业分析师为专业读者撰写每日简报。 请将以下内容压缩成 80-120 字的摘要包含三部分 1. 核心事实谁做了什么 2. 关键数据或技术细节 3. 对行业的影响或意义 要求客观具体不使用夸张词汇不添加原文没有的信息。 原文{content}摘要环节的实操心得批量处理要控制并发。一次发太多请求容易被限流我一般控制在 5 到 10 个并发。保留原文对照。摘要生成后我会把原文和摘要并排存着方便人工复核时快速判断。对长文分段摘要再合并。超过模型上下文长度的内容先分段摘要再合并成一条效果比直接截断好。3.4 分类与排序让读者一眼看到重点分类和排序决定了日报的可读性。我的分类体系是固定的四类模型进展、应用落地、开源动态、行业政策。每类下面按重要性排序。重要性打分我用的是规则 模型结合的方式规则部分来源权重核心层 2、是否含关键实体如知名机构 1、是否有具体数据1。模型部分让模型判断这条内容对行业的影响程度输出 1 到 5 分。两者加权得到最终分数。这个打分不追求绝对准确只要能保证重要的排在前面就够了。提示排序规则要定期回顾。我每个月会看一遍历史日报检查有没有当时排前面但事后看并不重要的条目据此调整权重。4. 实操过程与核心环节实现9 月 25 日这一期是怎么跑出来的4.1 环境准备与依赖清单先说环境。整套流水线跑在一台普通的云服务器上配置不高2 核 4G 足够。依赖清单如下# 核心依赖 python3.10 requests # HTTP 请求 feedparser # RSS 解析 beautifulsoup4 # HTML 解析 readability-lxml # 正文提取 scikit-learn # 相似度计算 openai # 模型调用或任意兼容接口 jinja2 # 模板渲染安装就一行命令pip install requests feedparser beautifulsoup4 readability-lxml scikit-learn openai jinja2目录结构我习惯这样组织ai-daily/ ├── config/ │ └── sources.yaml # 信息源配置 ├── data/ │ ├── raw/ # 原始采集数据 │ └── processed/ # 清洗后数据 ├── scripts/ │ ├── collect.py # 采集 │ ├── clean.py # 清洗去重 │ ├── summarize.py # 摘要 │ └── render.py # 排版 ├── templates/ │ └── daily.md.j2 # 日报模板 └── output/ └── 2026-09-25.md # 最终日报这个结构的好处是每个环节独立成脚本可以单独运行、单独调试。4.2 采集脚本的关键实现采集脚本的核心逻辑是读配置、遍历源、抓取、存原始数据。关键代码片段import feedparser import requests from datetime import datetime, timezone def collect_rss(source): feed feedparser.parse(source[url]) items [] for entry in feed.entries: items.append({ title: entry.get(title, ), url: entry.get(link, ), published_at: entry.get(published, ), raw_content: entry.get(summary, ), source: source[name], }) return items def collect_html(source): resp requests.get(source[url], timeout10) resp.raise_for_status() # 用配置里的选择器提取 soup BeautifulSoup(resp.text, html.parser) items [] for node in soup.select(source[selector]): items.append({ title: node.select_one(source[title_sel]).get_text(stripTrue), url: node.select_one(a)[href], raw_content: node.get_text(stripTrue), source: source[name], }) return items采集时我加了两个保护超时设置和异常捕获。单个源失败不影响其他源失败的源记入日志第二天再试。9 月 25 日这一期采集环节一共跑了 22 个源成功 20 个失败 2 个一个超时一个改版导致选择器失效。总共抓到 187 条原始条目。4.3 清洗去重的参数计算清洗环节最关键的是去重阈值。这个阈值怎么定我的方法是用历史数据做实验。具体做法取过去一周的条目人工标注哪些是重复的然后跑不同阈值下的去重结果算准确率和召回率。我试过 0.7、0.8、0.85、0.9 四个值结果如下阈值准确率召回率说明0.700.820.95误杀较多相关但不同的内容被删0.800.890.91平衡较好0.850.930.86我最终选的偏保守0.900.960.72漏掉不少重复我选 0.85是因为宁可漏掉重复也不要误杀。重复内容读者能自己跳过但误杀会让读者错过信息。9 月 25 日这一期187 条原始条目经过清洗去重后剩下 94 条。去掉了 93 条其中大部分是同一事件的重复报道。4.4 摘要生成的批量处理摘要环节我用的是批量处理一次发 10 条控制并发。核心代码import asyncio from openai import AsyncOpenAI client AsyncOpenAI() async def summarize_one(item): prompt f你是一名 AI 行业分析师为专业读者撰写每日简报。 请将以下内容压缩成 80-120 字的摘要包含三部分 1. 核心事实谁做了什么 2. 关键数据或技术细节 3. 对行业的影响或意义 要求客观具体不使用夸张词汇不添加原文没有的信息。 原文{item[raw_content][:2000]} resp await client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.3, ) item[summary] resp.choices[0].message.content.strip() return item async def summarize_batch(items, batch_size10): results [] for i in range(0, len(items), batch_size): batch items[i:ibatch_size] results.extend(await asyncio.gather(*[summarize_one(it) for it in batch])) await asyncio.sleep(1) # 控制节奏 return results这里有几个参数值得说temperature 设 0.3摘要要稳定不需要创造性低温度更合适。原文截断到 2000 字太长的原文直接截断比分段摘要再合并简单效果也够用。批次间 sleep 1 秒避免触发限流。9 月 25 日这一期94 条内容全部生成摘要耗时约 4 分钟。4.5 人工定稿与排版机器跑完之后进入人工环节。我打开处理好的数据按重要性排序从 94 条里挑出 10 条作为当日重点其余作为其他动态简列。挑选的标准是三条是否有实质进展纯观点、纯预测的降权。是否影响面广只影响小众的降权。是否有可验证的信息只有传闻没有实锤的降权。9 月 25 日这一期最终定稿 10 条重点 12 条简讯。排版用 Jinja2 模板渲染模板大概长这样# AI 日报{{ date }} ## 今日重点 {% for item in highlights %} ### {{ loop.index }}. {{ item.title }} {{ item.summary }} 来源{{ item.source }} {% endfor %} ## 其他动态 {% for item in briefs %} - {{ item.title }}{{ item.source }} {% endfor %}排版环节的实操心得模板要留手动调整的口子。我经常在渲染后手动改几条的措辞所以模板不要写得太死留出可编辑的空间。5. 常见问题与排查技巧实录5.1 采集失败从日志里找线索采集失败是最常见的问题。我的排查顺序是看日志每个源的采集结果都记了日志先看是超时、403、还是解析失败。手动访问用浏览器打开目标 URL确认站点是否正常。检查选择器如果是解析失败多半是站点改版了用开发者工具重新找选择器。常见问题速查表现象可能原因解决方法超时站点慢或网络问题增加超时时间加重试403被识别为爬虫加 User-Agent降低频率解析为空选择器失效重新检查 DOM 结构内容乱码编码问题显式指定编码重复抓取没有去重在采集层加 URL 去重注意遇到 403 不要硬刚。降低频率、加合理的 User-Agent 通常能解决。如果站点明确不欢迎抓取就换源别较劲。5.2 摘要质量差先查提示词再查模型摘要质量差的表现有几种太短、太长、跑题、加戏。排查顺序太短或太长检查提示词里的长度约束是否明确。我一般会给出具体字数范围而不是简短一点。跑题检查原文是否被正确传入。有时候正文提取失败传进去的是导航栏文字摘要自然跑题。加戏模型添加了原文没有的信息。这时候要降低 temperature并在提示词里强调不添加原文没有的信息。我踩过的一个坑早期提示词写请总结以下内容模型经常输出这篇文章介绍了……这种元描述。后来改成请将以下内容压缩成摘要直接输出摘要内容不要有这篇文章之类的引导语问题就解决了。5.3 去重误杀宁可漏杀不可错杀去重误杀是让人最难受的问题——明明是不同的内容被当成重复删掉了。我的应对策略提高阈值从 0.8 提到 0.85减少误杀。加白名单对特定来源或特定关键词的条目跳过去重。人工复核去重结果保留一份被删列表人工抽查。有一次我把两家媒体对同一模型的不同角度报道误判为重复删掉了其中一条结果那条恰好包含了关键的技术参数。从那以后我就加了被删列表复核机制。5.4 流水线跑得慢定位瓶颈整套流水线正常 30 分钟内跑完。如果某天特别慢通常是这几个原因某个源响应慢拖累了整体。解决方法是给每个源设独立超时。摘要并发太高被限流降低并发增加间隔。数据量突然增大比如某天有重大事件条目数翻倍。这时候可以临时提高筛选阈值减少进入摘要环节的数量。我一般会在每个环节记录耗时跑完之后看一眼哪个环节最慢针对性优化。5.5 内容同质化如何保持日报的独特性做久了会发现日报内容越来越同质化——大家都在报同样的东西。我的应对方法有三个加自己的判断每条重点后面加一句我的看法哪怕只有一句话也能让日报有辨识度。挖掘边缘信号核心层的信息大家都报但补充层的小众讨论往往只有我在跟。做纵向对比把当天的事件和历史联系起来比如这是某机构今年第三次发布类似成果这种上下文是别人没有的。提示日报的价值不在于全而在于选和评。同样的信息你的筛选标准和点评角度才是核心竞争力。6. 我个人的一些实操体会做这份日报到现在最大的体会是工具和流程都是次要的判断力才是核心。流水线能帮你省时间但哪条重要、哪条该删、哪条该怎么写这些判断机器替代不了。另一个体会是别追求完美。我早期总想把每条摘要都打磨到极致结果每天花三四个小时坚持不下去。后来想通了日报是日报稳定输出比单期质量更重要。现在我的标准是80 分就发反而坚持了上千期。最后分享一个小技巧建立自己的事件库。每次遇到重大事件记一笔——时间、主体、关键数据。时间长了这个库就成了你做纵向对比的素材来源也是日报独特性的来源。9 月 25 日这一期里有一条某开源项目 star 数破十万我就是翻了事件库才发现这个项目从发布到破十万只用了四个月这个对比一加进去条目的信息量立刻上去了。这套流水线后续还能扩展的方向不少比如加一个周报汇总环节把一周的重点自动聚合或者加一个主题追踪对特定技术方向做持续跟踪。但那是下一步的事了眼下先把每天的日报稳定跑好。
