AI项目实战开发

Python 爬虫 + AI 总结：自动生成行业日报系统

引言

摘要：本节给出关键结论、核心步骤和可执行建议。

对很多工程团队来说，“行业日报”并不是内容运营问题，而是一个典型的信息工程问题：多源采集、增量更新、内容清洗、去重聚合、结构化抽取、AI 总结、引用追溯、定时分发。如果这套流程靠人工维护，成本高、覆盖不稳定，而且很难做到每天同一时间、同一标准输出。

现在这件事之所以值得工程化重做，是因为两类能力已经比较成熟了：

1. Python 抓取生态足够完善：Requests 适合轻量 API/RSS 拉取，feedparser 适合订阅源解析，Scrapy 适合批量化抓取，Firecrawl/Crawl4AI 则更适合动态页面、JS 渲染和 LLM 友好内容提取。
2. AI 总结链路已经标准化：OpenAI 官方 Responses API 已将web_search等工具纳入统一调用模型，支持域名过滤与 sources 返回，这意味着“联网检索 + 引用可追溯 + 结构化总结”可以进入生产流水线，而不只是 Demo。

这篇文章从工程落地角度讲清楚：如何设计一套Python 爬虫 + AI 总结的自动行业日报系统。

大家想学习更多AI知识，可以看这里：
GPTBUYS、ZeoAPI

摘要

摘要：本文给出一个可落地的行业日报系统架构，从信源接入、抓取、清洗、去重、结构化抽取到 AI 总结与分发，覆盖选型、代码示例、排错和上线建议。

本文核心观点如下：

• 信源层优先 RSS/Atom，其次 API，最后 HTML 抓取。feedparser 支持 ETag、Last-Modified 等特性，适合做稳定增量采集。
• 采集层按复杂度分级：简单请求用 Requests，批量抓取用 Scrapy，动态页面可考虑 Firecrawl 或 Crawl4AI。
• 清洗层要尽量输出 LLM 友好的标准文本或结构化数据。Firecrawl 官方提供 scrape/extract，能直接产出 markdown 或 schema 化结果。
• AI 总结层建议直接基于 OpenAI Responses API。官方已将 web search 纳入工具链，并支持 sources 输出与域名过滤，适合行业日报的可追溯要求。
• 工程重点不在“会不会调模型”，而在“有没有稳定的数据流水线”。如果增量、去重、引用、失败重试没做好，日报质量会持续波动。

系统整体架构设计

摘要：行业日报不是单点脚本，而是一条分层流水线，建议按“采集—标准化—抽取—总结—分发”拆开。

一个更稳妥的工程架构如下：

1. 信源接入层

来源一般包括：

• RSS / Atom 订阅源
• 官方博客 / 公司公告页
• 新闻站点专题页
• 行业数据库或开放 API
• 指定白名单站点的搜索结果

其中 RSS/Atom 是最值得优先接入的，因为结构稳定、增量友好。feedparser 官方文档明确支持 ETag、Last-Modified、日期解析和编码处理，这对日报系统非常实用。

2. 采集层

不同采集任务用不同工具：

• Requests：适合拉 RSS、调用新闻 API、补抓详情页
• Scrapy：适合规模化调度、批量抓取、统一导出
• Firecrawl Scrape：适合复杂网页转 markdown/html
• Crawl4AI：适合现代网站、虚拟滚动、智能链接发现

Scrapy 官方截至 2025-07-02 的稳定版为 2.13.3，说明它仍然是生产级抓取框架。Requests 当前文档面向 2.33.1，并支持 Python 3.9+，适合作为轻量接入基础库。

3. 标准化与抽取层

抓回来的网页不能直接喂给模型。建议统一转成：

• 标题
• 发布时间
• 来源站点
• URL
• 正文 markdown / clean text
• 标签 / 公司名 / 产品名 / 融资信息等字段

Firecrawl 的/extract支持结合 prompt 和 schema 输出结构化数据，这非常适合日报中的“重点字段抽取”。

4. AI 总结层

AI 层建议做两级处理：

• 单篇摘要：将每篇文章压缩成 100~200 字
• 全局日报摘要：对所有文章做聚合总结，输出“今日重点、趋势、公司动态、投融资、风险信号”

OpenAI 官方文档说明 Responses API 支持web_search工具，并可返回sources，还能做 domain filtering，这对引用追溯和信源白名单控制很关键。

5. 分发层

分发方式可以包括：

• 企业微信 / 钉钉机器人
• 飞书消息卡片
• 邮件日报
• Markdown 落库到 CMS / CSDN / 知识库
• 数据库存档用于回溯

信源接入与抓取策略

摘要：要想日报稳定，关键不是“爬得多”，而是“信源质量高、增量抓取准、抓取方式分层”。

实际项目里我建议采用这样的优先级：

第一优先级：RSS/Atom

适用场景：

• 媒体资讯
• 官方博客
• 公司公告
• 开源项目更新

优势：

• 结构化
• 增量自然
• 实现简单
• 站点封禁风险低

feedparser 文档明确支持 RSS/Atom 解析、ETag 和 Last-Modified，这意味着你可以只抓“今天新增”的内容。

第二优先级：开放 API

比如某些媒体、数据库或内部服务提供 JSON 接口。
这类场景 Requests 足够好用，代码简单、可维护性高。

第三优先级：HTML 抓取

当没有 RSS/API 时，再进入 HTML 层：

• 列表页抓 URL
• 详情页提正文
• 清洗广告、导航、推荐模块

这里工具选择取决于页面复杂度：

• 静态站：Requests + BeautifulSoup/lxml
• 大规模站群：Scrapy
• 动态 JS 站：Firecrawl / Crawl4AI

Firecrawl 官方文档强调其 scrape 能处理动态网站、JS 渲染页面、PDF、图片等复杂内容，并提供 Python SDK。对于“采集结果直接给 LLM 用”的流水线，它会比传统纯 HTML 提取更省事。

白名单与可信信源控制

行业日报很容易出现“来源杂、结论不稳”的问题。
OpenAI web search 文档提到支持domain filtering，这意味着你可以把搜索结果限制在指定域名下，例如：

• 企业官网
• 主流媒体
• 行业研究机构
• 官方文档站点

这一步对于生产系统非常重要，因为它直接影响模型总结质量。

结构化提取与数据标准化

摘要：AI 总结前一定要先做标准化，否则模型会把导航栏、广告和正文混在一起。

建议统一定义一份文章标准模型，例如：

id source_name source_domain url title author published_at lang content_markdown summary_short entities keywords category hash fetched_at

为什么标准化很关键

1. 便于去重

   • 同一篇新闻可能被多个源转载
   • 标题轻微不同，但正文高度重合

2. 便于模型输入裁剪

   • 不是所有字段都要传给模型
   • 可以只传 title + abstract + clean body

3. 便于后续统计

   • 例如统计某公司一周出现次数
   • 或统计某赛道热度变化

Firecrawl Extract 的价值

Firecrawl 的 extract 官方定位，就是把 URL 转成适合 LLM 使用的 markdown 或 structured data。
对于日报系统，它特别适合做这几件事：

• 从文章中提取公司名、产品名、金额、时间
• 识别“发布 / 融资 / 合作 / 安全事件 / 产品更新”等事件类型
• 统一输出 JSON，直接进入数据库

去重建议

去重不要只看 URL，建议组合：

• URL 归一化
• 标题 hash
• 正文 SimHash / MinHash
• 发布时间窗口
• 来源权重

这样能避免多站转载导致日报“同一条消息出现 4 次”。

AI 总结与引用追溯设计

摘要：AI 总结要解决的不是“能不能写”，而是“是否稳定、可控、可追溯”。

行业日报最怕两件事：

• 模型总结过度发挥
• 输出无法追溯到原始来源

为什么优先考虑 Responses API

OpenAI 官方迁移文档指出，Responses API 是构建 agents 的未来方向，适合新系统；同时 Assistants API 已进入弃用迁移路径。
对于日报系统，这意味着：

• 新项目优先按 Responses API 设计
• 工具调用链更统一
• 更方便串联抓取、搜索、总结、状态管理

web_search 在日报里的角色

你可以把 web_search 放在两种位置：

方案 A：作为补充检索

先用自有爬虫抓取，再让模型联网检索补充背景信息。

适合：

• 需要扩展上下文
• 补充权威解释
• 查找遗漏来源

方案 B：作为信源发现器

先用 web_search 找候选文章，再进入自建抓取/清洗环节。

适合：

• 新专题冷启动
• 监控新站点
• 每日热点发现

sources 返回的重要性

官方文档说明sources字段可返回模型实际参考的 URL。
这对于日报系统很重要，因为你可以：

• 在日报正文中自动附“参考链接”
• 将 AI 结论与来源绑定
• 审计模型是否引用了白名单外站点

总结 Prompt 设计建议

不要只让模型“写日报”，而要明确结构，例如：

• 今日重点 3 条
• 行业趋势 2 条
• 公司动态列表
• 风险/争议信息
• 每条结论附来源 URL

这样输出更稳定，也更适合自动发布。

Key Comparison Table

摘要：不同工具适合不同层级任务，没有银弹，关键是按复杂度分层组合。

实战代码示例

摘要：下面给出一个最小可用实现，包含 RSS 增量采集与 AI 总结两个关键环节。

示例 1：用 feedparser + Requests 拉取今日文章

importhashlibimportrequestsimportfeedparserfromdatetimeimportdatetime,timezone# 目的：拉取 RSS 并生成标准化文章对象# 关键点：优先使用 RSS 做低成本增量接入FEEDS=["https://example.com/rss.xml",]defbuild_id(url:str,title:str)->str:# 用 URL + 标题生成稳定 ID，便于入库和去重raw=f"{url}|{title}".encode("utf-8")returnhashlib.md5(raw).hexdigest()deffetch_feed(feed_url:str):# 可选：先用 requests 获取，后续可自行处理超时、代理、重试resp=requests.get(feed_url,timeout=15)resp.raise_for_status()parsed=feedparser.parse(resp.content)items=[]forentryinparsed.entries:title=entry.get("title","").strip()url=entry.get("link","").strip()published=entry.get("published","")# 统一成内部结构，后续可直接送入数据库或队列item={"id":build_id(url,title),"source_name":parsed.feed.get("title","unknown"),"url":url,"title":title,"published_at":published,"fetched_at":datetime.now(timezone.utc).isoformat(),}items.append(item)returnitemsif__name__=="__main__":all_items=[]forfeedinFEEDS:try:all_items.extend(fetch_feed(feed))exceptExceptionase:# 生产环境建议接日志系统，不要只 printprint(f"fetch failed:{feed}, err={e}")print(f"fetched{len(all_items)}items")forxinall_items[:3]:print(x)

示例 2：用 OpenAI Responses API 做日报总结

fromopenaiimportOpenAI# 目的：把已清洗的文章列表汇总成日报# 关键点：要求模型输出结构化结果，并保留引用来源思路client=OpenAI()articles=[{"title":"某公司发布新模型平台","source":"官方博客","url":"https://example.com/post/1","summary":"发布了新的企业级模型部署能力，强调安全与成本优化。"},{"title":"某赛道融资动态更新","source":"行业媒体","url":"https://example.com/post/2","summary":"本周出现多笔早期融资，资金集中在自动化与数据基础设施方向。"}]content="\n".join(f"- 标题：{a['title']}\n 来源：{a['source']}\n 链接：{a['url']}\n 摘要：{a['summary']}"forainarticles)prompt=f""" 你是一名行业分析编辑，请基于以下文章列表生成中文行业日报。 要求： 1. 输出“今日重点”“趋势观察”“公司动态”三个部分 2. 语言简洁、工程化，不写空话 3. 每条结论尽量带上对应链接 4. 不要编造未出现的信息 文章列表：{content}"""response=client.responses.create(model="gpt-4.1",input=prompt)# 说明：不同 SDK 版本字段访问方式可能略有差异# 实际工程中建议统一封装模型响应解析层print(response.output_text)

示例 3：用 Firecrawl 做复杂页面抽取

# 目的：把复杂网页转换为更适合 LLM 使用的 markdown# 关键点：适用于 JS 渲染、正文提取困难的页面fromfirecrawlimportFirecrawlApp app=FirecrawlApp(api_key="YOUR_FIRECRAWL_API_KEY")result=app.scrape_url("https://example.com/news/123",formats=["markdown"])# 返回结果中通常包含 markdown/html 等字段# 后续可把 markdown 送入摘要模型或结构化抽取流程print(result)

代码块注释规范

摘要：代码注释不是解释语法，而是解释“为什么这样设计”和“关键边界条件”。

建议在技术文章和生产代码里统一遵循以下规则：

1. 先写目的，再写步骤

   • 例如注明“用于增量抓取 RSS”“用于将文章统一为标准结构”
   • 不要写成“for 循环遍历列表”这种无意义注释

2. 只注释关键决策点

   • 比如为什么用 MD5 生成稳定 ID
   • 为什么超时设置为 15 秒
   • 为什么先做标准化再喂给模型

3. 边界条件必须写明

   • 空标题怎么办
   • 请求失败如何重试
   • 模型输出格式不稳定如何兜底

4. 注释与实现保持同步

   • 代码改了，注释也要改
   • 过时注释比没有注释更危险

5. 示例代码注释要短而准

   • CSDN 文章里的注释建议一行解决一个问题
   • 便于读者快速复制和改造

常见问题与排错

摘要：自动日报上线后，问题通常出在信源稳定性、正文提取、去重和模型输出一致性上。

1. 抓取成功但正文为空

常见原因：

• 页面内容由 JS 渲染
• 选择器失效
• 反爬返回了空壳页面

处理建议：
优先换 RSS/API；否则使用 Firecrawl 或 Crawl4AI 处理动态页面。

2. 日报里同一新闻重复出现

常见原因：

• 多个媒体转载同一篇稿件
• URL 不同但正文近似
• 只按链接去重

处理建议：
增加标题 hash、正文相似度和发布时间窗口联合去重。

3. 模型总结“说多了”

常见原因：

• Prompt 太宽泛
• 输入材料中混入广告、推荐阅读、导航文本
• 未限制“不要编造”

处理建议：
先清洗正文，再使用固定输出模板，并要求只基于输入内容作答。

4. 搜索结果来源不够可信

常见原因：

• 未做域名白名单
• 模型搜索到了聚合站或低质量转载站

处理建议：
使用 OpenAI web search 的 domain filtering，只允许指定域名。

5. 每天运行耗时波动很大

常见原因：

• 所有源串行执行
• 动态页面占比过高
• 没有缓存和失败重试策略

处理建议：
静态源与 RSS 并发拉取，复杂站点单独队列处理，抓取和总结分阶段执行。

成本、稳定性与上线建议

摘要：真正能长期跑的日报系统，核心是把成本和波动控制在可接受范围内。

1. 先做“分层降本”

• RSS/API 优先，减少 HTML 抓取
• 单篇先压缩，再做全局总结
• 长文先抽取关键字段，再送模型

2. 建立缓存与增量机制

• RSS 用 ETag / Last-Modified
• URL 抓取结果做缓存
• 正文 hash 不变就不重复总结

3. 失败重试与回补

• 采集失败重试 2~3 次
• 总结失败允许延迟补跑
• 对重要信源设置“兜底回补任务”

4. 引用必须落库

不只是把 AI 输出保存下来，更要保存：

• 原始 URL
• 抓取时间
• 清洗后的正文
• 模型输入片段
• 模型输出及 sources

这会直接决定系统的可审计性。

5. 新项目建议优先 Responses API

根据 OpenAI 官方迁移文档与 changelog，Responses API 已成为官方推荐方向，并集成 web search 等工具。对新建日报系统而言，优先采用这条路线会更可持续。

结论

摘要：自动行业日报的本质，是一个“可靠信息流水线 + 可追溯 AI 总结”的工程系统。

如果你准备从 0 到 1 落地，建议按下面顺序推进：

1. 先接 RSS/Atom 和少量 API 信源
2. 再补充 HTML 抓取
3. 统一标准化文章结构
4. 做好去重与增量更新
5. 最后接入 AI 单篇摘要和全局日报生成
6. 在输出中强制附引用来源

一开始不要追求“全网最全”，而要先做到：

• 每天稳定运行
• 来源可控
• 摘要可信
• 输出可追溯

把这四件事做好，这套“Python 爬虫 + AI 总结”的日报系统就已经具备生产价值了。下一步可以继续扩展为：专题监控、舆情预警、竞品追踪、周报/月报自动化。

1. Web search | OpenAI API
   https://platform.openai.com/docs/guides/tools-web-search?api-mode=responses

2. Scrape | Firecrawl
   https://docs.firecrawl.dev/features/scrape

3. Extract | Firecrawl
   https://docs.firecrawl.dev/features/extract

4. Changelog - OpenAI API
   https://platform.openai.com/docs/changelog/added-run-additional-instructions

5. Migrate to the Responses API | OpenAI API
   https://platform.openai.com/docs/guides/migrate-to-responses

6. Download Scrapy | Scrapy
   https://www.scrapy.org/download/

7. 🚀 Crawl4AI v0.7.0: The Adaptive Intelligence Update
   https://docs.crawl4ai.com/blog/releases/0.7.0/

8. Community Updates — Requests 2.33.1 documentation
   https://requests.readthedocs.io/en/latest/community/updates.html

9. Requests: HTTP for Humans™ — Requests 2.33.1 documentation
   https://requests.readthedocs.io/

10. Documentation — feedparser 6.0.11 documentation
    https://feedparser.readthedocs.io/