AI项目实战开发

Python 爬虫 AI 总结自动生成行业日报系统引言摘要本节给出关键结论、核心步骤和可执行建议。对很多工程团队来说“行业日报”并不是内容运营问题而是一个典型的信息工程问题多源采集、增量更新、内容清洗、去重聚合、结构化抽取、AI 总结、引用追溯、定时分发。如果这套流程靠人工维护成本高、覆盖不稳定而且很难做到每天同一时间、同一标准输出。现在这件事之所以值得工程化重做是因为两类能力已经比较成熟了Python 抓取生态足够完善Requests 适合轻量 API/RSS 拉取feedparser 适合订阅源解析Scrapy 适合批量化抓取Firecrawl/Crawl4AI 则更适合动态页面、JS 渲染和 LLM 友好内容提取。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/htmlCrawl4AI适合现代网站、虚拟滚动、智能链接发现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 / Crawl4AIFirecrawl 官方文档强调其 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为什么标准化很关键便于去重同一篇新闻可能被多个源转载标题轻微不同但正文高度重合便于模型输入裁剪不是所有字段都要传给模型可以只传 title abstract clean body便于后续统计例如统计某公司一周出现次数或统计某赛道热度变化Firecrawl Extract 的价值Firecrawl 的 extract 官方定位就是把 URL 转成适合 LLM 使用的 markdown 或 structured data。对于日报系统它特别适合做这几件事从文章中提取公司名、产品名、金额、时间识别“发布 / 融资 / 合作 / 安全事件 / 产品更新”等事件类型统一输出 JSON直接进入数据库去重建议去重不要只看 URL建议组合URL 归一化标题 hash正文 SimHash / MinHash发布时间窗口来源权重这样能避免多站转载导致日报“同一条消息出现 4 次”。AI 总结与引用追溯设计摘要AI 总结要解决的不是“能不能写”而是“是否稳定、可控、可追溯”。行业日报最怕两件事模型总结过度发挥输出无法追溯到原始来源为什么优先考虑 Responses APIOpenAI 官方迁移文档指出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摘要不同工具适合不同层级任务没有银弹关键是按复杂度分层组合。DimensionRequestsfeedparserScrapyFirecrawlOpenAI Responses API web_search主要定位轻量 HTTP 请求与接口调用RSS/Atom 订阅解析批量化网页抓取框架动态页面抓取与 LLM-ready 内容转换联网检索、总结与引用追溯适合场景API、详情页补抓、服务调用官方博客、媒体订阅、公告增量拉取多源站点规模化抓取JS 渲染页、PDF、复杂网页清洗行业搜索、补充检索、总结生成工程复杂度低低中高中中动态页面能力弱不涉及需额外方案强官方强调支持动态网站搜索能力不负责页面渲染抓取增量抓取能力需自行实现强支持 ETag/Last-Modified强可自行调度依赖业务层控制适合检索补充不替代采集主存储结构化输出支持需自行解析基础字段需自定义 Item/Pipeline强支持 markdown/structured data可生成结构化总结并返回 sources最佳角色接入层基础库首选订阅源接入大规模抓取主框架复杂页面内容标准化AI 总结与官方搜索工具链实战代码示例摘要下面给出一个最小可用实现包含 RSS 增量采集与 AI 总结两个关键环节。示例 1用 feedparser Requests 拉取今日文章importhashlibimportrequestsimportfeedparserfromdatetimeimportdatetime,timezone# 目的拉取 RSS 并生成标准化文章对象# 关键点优先使用 RSS 做低成本增量接入FEEDS[https://example.com/rss.xml,]defbuild_id(url:str,title:str)-str:# 用 URL 标题生成稳定 ID便于入库和去重rawf{url}|{title}.encode(utf-8)returnhashlib.md5(raw).hexdigest()deffetch_feed(feed_url:str):# 可选先用 requests 获取后续可自行处理超时、代理、重试resprequests.get(feed_url,timeout15)resp.raise_for_status()parsedfeedparser.parse(resp.content)items[]forentryinparsed.entries:titleentry.get(title,).strip()urlentry.get(link,).strip()publishedentry.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(ffetch failed:{feed}, err{e})print(ffetched{len(all_items)}items)forxinall_items[:3]:print(x)示例 2用 OpenAI Responses API 做日报总结fromopenaiimportOpenAI# 目的把已清洗的文章列表汇总成日报# 关键点要求模型输出结构化结果并保留引用来源思路clientOpenAI()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)promptf 你是一名行业分析编辑请基于以下文章列表生成中文行业日报。 要求 1. 输出“今日重点”“趋势观察”“公司动态”三个部分 2. 语言简洁、工程化不写空话 3. 每条结论尽量带上对应链接 4. 不要编造未出现的信息 文章列表{content}responseclient.responses.create(modelgpt-4.1,inputprompt)# 说明不同 SDK 版本字段访问方式可能略有差异# 实际工程中建议统一封装模型响应解析层print(response.output_text)示例 3用 Firecrawl 做复杂页面抽取# 目的把复杂网页转换为更适合 LLM 使用的 markdown# 关键点适用于 JS 渲染、正文提取困难的页面fromfirecrawlimportFirecrawlApp appFirecrawlApp(api_keyYOUR_FIRECRAWL_API_KEY)resultapp.scrape_url(https://example.com/news/123,formats[markdown])# 返回结果中通常包含 markdown/html 等字段# 后续可把 markdown 送入摘要模型或结构化抽取流程print(result)代码块注释规范摘要代码注释不是解释语法而是解释“为什么这样设计”和“关键边界条件”。建议在技术文章和生产代码里统一遵循以下规则先写目的再写步骤例如注明“用于增量抓取 RSS”“用于将文章统一为标准结构”不要写成“for 循环遍历列表”这种无意义注释只注释关键决策点比如为什么用 MD5 生成稳定 ID为什么超时设置为 15 秒为什么先做标准化再喂给模型边界条件必须写明空标题怎么办请求失败如何重试模型输出格式不稳定如何兜底注释与实现保持同步代码改了注释也要改过时注释比没有注释更危险示例代码注释要短而准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-ModifiedURL 抓取结果做缓存正文 hash 不变就不重复总结3. 失败重试与回补采集失败重试 2~3 次总结失败允许延迟补跑对重要信源设置“兜底回补任务”4. 引用必须落库不只是把 AI 输出保存下来更要保存原始 URL抓取时间清洗后的正文模型输入片段模型输出及 sources这会直接决定系统的可审计性。5. 新项目建议优先 Responses API根据 OpenAI 官方迁移文档与 changelogResponses API 已成为官方推荐方向并集成 web search 等工具。对新建日报系统而言优先采用这条路线会更可持续。结论摘要自动行业日报的本质是一个“可靠信息流水线 可追溯 AI 总结”的工程系统。如果你准备从 0 到 1 落地建议按下面顺序推进先接 RSS/Atom 和少量 API 信源再补充 HTML 抓取统一标准化文章结构做好去重与增量更新最后接入 AI 单篇摘要和全局日报生成在输出中强制附引用来源一开始不要追求“全网最全”而要先做到每天稳定运行来源可控摘要可信输出可追溯把这四件事做好这套“Python 爬虫 AI 总结”的日报系统就已经具备生产价值了。下一步可以继续扩展为专题监控、舆情预警、竞品追踪、周报/月报自动化。Web search | OpenAI APIhttps://platform.openai.com/docs/guides/tools-web-search?api-moderesponsesScrape | Firecrawlhttps://docs.firecrawl.dev/features/scrapeExtract | Firecrawlhttps://docs.firecrawl.dev/features/extractChangelog - OpenAI APIhttps://platform.openai.com/docs/changelog/added-run-additional-instructionsMigrate to the Responses API | OpenAI APIhttps://platform.openai.com/docs/guides/migrate-to-responsesDownload Scrapy | Scrapyhttps://www.scrapy.org/download/ Crawl4AI v0.7.0: The Adaptive Intelligence Updatehttps://docs.crawl4ai.com/blog/releases/0.7.0/Community Updates — Requests 2.33.1 documentationhttps://requests.readthedocs.io/en/latest/community/updates.htmlRequests: HTTP for Humans™ — Requests 2.33.1 documentationhttps://requests.readthedocs.io/Documentation — feedparser 6.0.11 documentationhttps://feedparser.readthedocs.io/