每天早上一睁眼就刷新闻刷完一圈发现要么是标题党要么是三天前的旧闻真正有用的行业动态早就被铺天盖地的内容淹没了。我项目里有个AI方向的调研需求老板丢给我一句话帮我盯着AI创业这块的动态每天给我整理一份简报。人肉盯新闻根本不现实我只能顺手写了个脚本调用新闻类API扔进去AI创业这个关键词让它每天自动抓取、自动去重、自动生成一份Markdown格式的当日简报。这项目做完之后已经稳定跑了好几个月过程踩了不少坑我把它完整拆开讲讲。这套东西本质上做的事其实不复杂关键词输入、API请求、数据清洗、按固定模板输出。难的点在于稳定和好用——API不返回数据了怎么办、关键词命中了一堆无关内容怎么办、免费额度用完了怎么办这些才是真正磨人的地方。我把整个过程、代码思路、参数选择逻辑和踩坑实录全部记录下来新手照着搭能少走很多弯路。1. 项目拆解与整体思路1.1 这个项目到底解决了什么问题先别急着写代码想清楚一件事你需要的不是调一个API而是一条完整的信息流水线。拿AI创业这个关键词举例如果你只是简单调一次新闻API拿到的一定是大量噪声——平台随手发的一条融资快讯会进来标题里带AI的无关科技八卦也会进来甚至半个月前的旧闻都会被翻出来。我最早第一版脚本就是这样跑出来的简报惨不忍睹七条里有三条跟创业没关系。所以整个项目的核心难点并不在API调用本身而在数据过滤的规则设计、时效性控制、以及输出格式的可读性。另一个容易被忽视的需求是每天自动。抓一次、两次没有意义定时任务才是这个项目的灵魂。搭配上调度机制之后它才算真正替代了人肉盯新闻的动作。这个项目的整体链路分四段关键词配置 → API请求 → 数据清洗 → 简报生成。每一段都有独立的坑后面我一个一个讲。1.2 为什么选API而不是直接去网页抓取拿到需求之后我其实犹豫过两个技术路线直接写爬虫去各大科技媒体抓页面的方式还是用新闻API的方式。直接抓网页的诱惑是新闻源可控、内容全、不依赖第三方接口。但实践过一次就知道有多恶心。目标网站的HTML结构经常变一个class类名改了你的解析器就废了反爬机制越来越强请求频率稍高就被封IP为了应付不同的站点你得写不同的解析代码维护成本直线上升。某个站今天改版了整个链路断掉这种不确定性对日报系统来说是致命的。API方式的优势是稳定和标准化。新闻聚合服务把采集、去重、分类这些脏活累活都做完了你只需要处理好关键词和参数就行。输出结构统一出错概率低维护起来也很轻松。代价是——免费的API在请求配额、历史数据时长、返回字段上都有限制。但在抓取最新的行业新闻这个场景里免费额度基本够用是性价比很高的选择因此我会选API方案。2. 新闻API选型与参数解析2.1 主流新闻API怎么选市面上的新闻聚合接口分成几类一类是大而全的通用新闻API覆盖面广但中文内容质量和行业垂直度一般一类是垂直领域的数据服务比如专门做创投、科技资讯的数据好但接入门槛和价格都高还有一类是各门户自带的开放接口稳定性看平台心情不推荐作为主力源。我实际的筛选标准就三条第一是否支持中文关键词检索返回结果里中文新闻的比例要说得过去第二免费档位的每日请求次数够不够你跑多个关键词——如果一天要跑好几个关键词很快就超了第三返回字段是否包含发布时间、来源、摘要、链接这几项基本配置少了任何一个都会让简报制作变得非常别扭。我的选择落地之后是这样的用一个通用新闻API作为主数据源把请求频率控制在每分钟几次、每天累计请求数控制在免费额度内。同时留了一个备用源配置主源出问题时自动切换。多源策略会在后面常见问题里详细介绍这里先记住一个结论别把鸡蛋放在一个数据源里新闻API挂掉是常态不是意外。2.2 核心参数设置与返回结构解析新闻API的调用方式大同小异本质都是构造一个HTTP GET请求带上认证信息和查询参数。我需要重点解析几个核心参数。q关键词这是最需要花心思的参数。直接填AI创业会匹配到大量带AI、带创业但跟主题关系不大的内容。实际使用中要配合布尔操作符比如写成AI AND 创业的形式或者用精确短语限定。不同API支持的查询语法不完全一样但思路是一致的通过词组和逻辑符把范围收紧。from / to时间范围这个参数决定了你拿回来的是不是昨天的新闻。日报的场景下我一般把 from 设置为今天零点to 设置为当前时间这样天然过滤掉旧闻。有些免费API支持的历史时间窗口很短比如只能查最近7天所以一个准确的 from 参数能帮你省不少事。sortBy排序规则大多数API支持按相关性、发布时间、热度排序。我的经验是抓新闻简报用publishedAt倒序保证看到的是最新内容如果你做的是主题研究报告想看到的是权威大稿那就用relevancy。别默认使用API自己的默认值你永远猜不到它的默认逻辑是什么。language语言明确指定中文避免混入大量英文内容。有些API只在特定参数里支持语言过滤不设置的话它会返回全语种的结果这对简报是灾难。pageSize / page分页控制每次返回条数。简报场景每页取50条足够了不要贪多。条数越多后续清洗的负担越大而且免费API单次请求上限通常就100条。API的返回结构一般是JSON核心字段各家大同小异都会有一个articles数组每条包含title、description、url、publishedAt、source等信息。你拿到的publishedAt通常是UTC时间不转换就直接写进简报会出现下午三点显示早上八点的错乱。这个细节放在后面问题排查部分单独讲。3. 自动化抓取与简报生成实现3.1 从零搭建抓取脚本环境方面我会用Python因为它处理JSON、做文本清洗、写定时任务都方便。依赖只有两个核心库requests负责发HTTP请求schedule负责定时任务。日志这块用自带的logging就行不用额外引入复杂框架。在写具体实现之前先把目录结构规划好避免所有代码堆在一个单个文件里后期难以维护。news_daily/ ├── config.py # 关键词、API地址、请求参数配置 ├── fetcher.py # 新闻API调用与数据获取 ├── cleaner.py # 数据清洗与去重过滤 ├── reporter.py # 简报生成与格式化输出 ├── scheduler.py # 调度入口 ├── logs/ # 运行日志存放目录 └── output/ # 生成的日报文件目录配置模块先跑起来# config.py API_ENDPOINT https://api.news-demo.example.com/v1/everything API_KEY your-api-key-placeholder KEYWORDS [AI创业, AI 融资, 大模型 创业] REQUEST_PARAMS { language: zh, sortBy: publishedAt, pageSize: 50, page: 1, } TIME_RANGE_HOURS 24 # 只取最近24小时的新闻然后是数据获取模块核心就是一个带参数校验的GET请求。这里有几个必须处理的细节请求要设置超时时间避免某个API卡死导致整个脚本挂起返回状态码非200时要做异常处理把错误信息写进日志而不是直接抛错中断。# fetcher.py import requests import datetime import logging from config import API_ENDPOINT, API_KEY, KEYWORDS, REQUEST_PARAMS logger logging.getLogger(__name__) def fetch_news(keyword: str, time_from: str) - list: params { q: keyword, from: time_from, to: datetime.datetime.now().isoformat(), language: REQUEST_PARAMS[language], sortBy: REQUEST_PARAMS[sortBy], pageSize: REQUEST_PARAMS[pageSize], page: REQUEST_PARAMS[page], apiKey: API_KEY, } try: resp requests.get(API_ENDPOINT, paramsparams, timeout10) resp.raise_for_status() data resp.json() if data.get(status) ! ok or not data.get(articles): logger.warning(f关键词 [{keyword}] 无有效返回) return [] return data[articles] except requests.exceptions.Timeout: logger.error(f请求超时: {keyword}) return [] except requests.exceptions.HTTPError as e: logger.error(fHTTP错误: {e}) return [] except Exception as e: logger.error(f未知异常: {e}) return []函数返回的是清洗前的原始数据列表。注意time_from参数不是写死的我让它在调度入口统一生成保证每天的请求窗口都准确对齐最近24小时。3.2 数据清洗与简报生成的逻辑数据清洗这一步是整个项目里性价比最高的环节它决定了简报的阅读体验。直接拿API的原始返回出简报的做法我也试过结果就是阅读者要从一堆重复内容里挑重点体验很差。我遇到的第一个问题是平台转载重复。同一家媒体的稿件会被各个门户互相转载标题或正文高度相似。对 title 做规范化处理之后用MD5值去重一个简单方案是只保留第一篇。这样每天能挤掉两到三成水分。第二个问题是关键词命中但内容跑偏。这需要做一层基于正文片段的过滤我维护了一个简单的排除词列表比如标题里只出现AI但正文完全没有创业、融资、产品、落地这些业务语义的条目统一标记为低相关度。这个规则的边界需要根据自己的场景去调不用过度设计能过滤明显噪声就够了。第三个问题是内容完整度检测。description字段为空、url字段为空的条目直接丢弃它们不值得占简报的位置。清洗完之后是格式化输出。我选择了Markdown格式的日报原因是它既能方便阅读也能随时转换成HTML。日常实际使用中被Copy到各种文档工具里不会乱版。# reporter.py def build_report(articles: list, keyword: str) - str: lines [f# 每日行业简报{keyword}, ] lines.append(f生成时间{datetime.datetime.now():%Y-%m-%d %H:%M}) lines.append(f今日收录{len(articles)} 条) lines.append() for idx, item in enumerate(articles, start1): title item.get(title, ).strip() source item.get(source, {}).get(name, 未知来源) pub_time item.get(publishedAt, )[:16].replace(T, ) url item.get(url, ) summary item.get(description, ).strip() lines.append(f### {idx}. {title}) lines.append(f 来源{source} 时间{pub_time}) lines.append() if summary: lines.append(f摘要{summary}) lines.append(f链接{url}) lines.append() return \n.join(lines)3.3 定时运行与部署细节脚本能跑通是一回事每天准点跑是另一回事。我先后试过几种定时方案最终用的是schedule库配合后台常驻进程的方式因为它跨平台、配置直观而且出错时日志排查方便。# scheduler.py import logging import schedule import time from fetcher import fetch_news from cleaner import clean_articles from reporter import build_report logging.basicConfig(levellogging.INFO, format%(asctime)s | %(levelname)s | %(message)s) def job(): keywords [AI创业, AI 融资, 大模型 创业] all_articles [] for kw in keywords: time_from (datetime.datetime.now() - datetime.timedelta(hours24)).isoformat() raw fetch_news(kw, time_from) cleaned clean_articles(raw) report build_report(cleaned, kw) output_path foutput/{datetime.datetime.now():%Y-%m-%d}_{kw}.md with open(output_path, w, encodingutf-8) as f: f.write(report) logging.info(f关键词 {kw} 简报已生成: {len(cleaned)} 条) schedule.every().day.at(08:00).do(job) while True: schedule.run_pending() time.sleep(60)注意两个细节第一文件写入的编码必须是utf-8否则Windows环境下打开中文内容会乱码第二每日生成一个独立文件比把内容追加进同一个文件更好用这样做久了之后你能回顾某天的信息后续要做趋势分析时也有素材。部署层面我选择放在一台低配服务器上让它常驻运行。因为没有图形界面资源需求整体的占用相对有限。服务器上挂nohup或写简单启动脚本即可。如果只是个人使用Windows任务计划程序配合python scheduler.py也能达到同样效果。我的建议是能挂着跑就别手动触发定时任务是这个项目价值的一半。4. 常见问题与排查技巧实录4.1 免费接口的请求限制与超额处理免费新闻API最头疼的问题就是请求次数限制。我遇到过不止一次脚本跑到中午就开始返回429状态码一看控制台原来免费档位每天只能请求500次。我代码里为了抓四个关键词每个关键词做了翻页遍历早早就把限额耗光了。排查后发现原因有三个一是翻页逻辑写得太贪每次把最大分页数都轮一遍二是没有做时间窗口内的请求润滑短时间密集请求特别容易被限流三是多个关键词共用一个API Key没有错峰调度。解决方案很简单。第一严格控制每个关键词只取前1到2页数据日报不需要几十年前的旧闻第一页已经是该时间窗口下最新的一批了。第二在关键词之间加time.sleep()比如3到5秒把瞬时请求频率降下来。第三在代码里对429响应做特殊处理捕获到之后自动暂停60秒重试一次而不是直接拉崩。4.2 发布时间字段的时区错乱问题这属于不看不知道、一看吓一跳的坑。API返回的publishedAt字段绝大多数情况下是UTC时间我最初直接在简报里原样使用。有一天我早上八点打开简报发现头条新闻的发布时间写着凌晨两点我还以为是API数据有问题仔细一推才知道是UTC没做本地化。正确的处理方式是在清洗阶段就把时间统一转换成东八区时间转换逻辑不超过三行代码但必须放在数据写入简报之前。我建议在cleaner.py里对所有时间字段做标准化转换后续不管换哪家API都不用再改这块。4.3 关键词命中不准的内容过滤策略大部分通用新闻API的文本匹配是比较宽松的你搜AI创业它可能把AI在医疗行业的创业故事创业公司用AI做电商这类近似主题都带进来。这看起来是好事但实际简报里会夹杂大量不相关内容反而会影响阅读效率。我的做法分三层。第一层在API请求层面通过加引号和AND逻辑符收缩匹配只保留同时包含核心词的文本。第二层在清洗层面对标题做包含性检测标题完全不出现业务核心词的直接丢弃。第三层在排序阶段把纯资讯类的泛AI新闻排到最后把标题同时命中融资、发布、合作、增长等事件词的排前面。这套策略做下来简报的有效信息占比从最开始的六成左右提升到了八成五以上。4.4 链接跳转失败与摘要截断的处理新闻API返回的链接大多是经过跳转的短链或追踪链直接放进简报里阅读体验尚可但偶尔会出现链接时效性问题——上午生成的简报下午点击就提示内容不存在。我测试后发现这类问题多出在源站做了内容下线或反爬拦截。建议做一层链接健康度抽查随机抽三条URL做HEAD请求检查返回状态码状态码异常的直接从简报里替换掉。当然不用每条都查那样太耗配额。摘要截断的问题则简单得多凡是超过80个字符的description字段统一截断到圆满的句子结束位置保证简报排版不会因为长短不一变得凌乱。前面提到的内容整理成速查表方便你排查时对照症状可能原因处理方式大量429返回请求频率过高增加请求间隔限制翻页次数文章时间全都早于预期UTC时间未转本地统一做时区转换简报混入大量无关内容关键词匹配过宽加AND逻辑符、过滤层某几条链接打不开源站下线或反爬抽查链接状态异常即删除中文标题乱码文件写入编码错误指定utf-8编码写入同一篇文章反复出现各平台互相转载对title归一化后MD5去重5. 从日报延伸到更多关键词与场景5.1 多关键词并行与自定义输出模板这个项目跑通AI创业之后我很快加了AI 融资和大模型 创业两个关键词因为它们之间存在交叉但没有完全被AI创业覆盖。配置层面把关键词列表外置到配置文件里新增一个关键词不需要改代码。输出模板目前是Markdown如果你的使用场景是发到IM群里可以考虑把输出格式切换成HTML或纯文本只需要改reporter.py里的字符串拼接逻辑。5.2 结合摘要和趋势数据的进一步拉宽日报做顺手之后可以做的事就多起来了。比如把每篇文章的标题和摘要拼接后调用文本摘要接口做一个一两句话的核心提炼放在简报标题下面这样打开简报第一屏就能掌握今天大概发生了什么。再比如每天的数据都落地到SQLite积累两三个月后能统计出AI创业相关资讯在周几最密集、哪些媒体发布量最大甚至做一个简单的热度趋势图。这些都不是难点真正的底座是稳定运行的抓取链路。5.3 推送渠道的替换与扩展如果你想把简报从文件变成通知可以去接邮件或者群机器人。邮件的好处是可以沉淀、可以归档聊天机器人的好处是打开率极高适合日常快扫。我个人推荐邮件作为主力推送渠道因为它的格式兼容性最好排版不会乱。机器人作为补充发送摘要即可。6. 最后的几个实操建议这个项目做完之后我有几个体会。第一日报类工具的核心不是功能炫技而是稳定。稳定跑三个月的简单脚本比功能花哨但每周挂两次的工程更有价值。第二控制单次请求的量够用就好不要试图一次性把API的可用数据全拉回来少即是多。第三配置和代码要分离关键词、API地址、请求频率都放进配置文件改动时不用碰代码逻辑。还有一个小技巧我一直留着在被要求再次做个类似项目的时候使用给每个API请求打上自定义业务标识方便后续在日志和监控里审计是哪类请求出了问题这在多个关键词并行跑的场景下排查效率尤其高。这个项目我目前一直在用每天早上的第一件事就是打开邮箱看简报三五分钟就能知道AI创业领域昨天有哪些值得关注的消息。其实做一个好的自动化工具最大的成就感不在于技术多复杂而在于你把它设好后的一整年它都在替你干活。