1. 项目背景与需求分析
作为一名长期关注AI领域的技术从业者,我每天都要面对海量的行业资讯。从2025年开始,AI领域的技术突破和商业应用呈现爆发式增长,但随之而来的信息过载问题也日益严重。经过三个月的实际使用验证,这个基于OpenClaw框架开发的AI新闻早报系统已经成为了我工作中不可或缺的信息助手。
1.1 信息筛选的痛点
在开发这个系统之前,我的日常信息获取流程是这样的:
- 早上打开十几个浏览器标签页(机器之心、36氪、量子位等)
- 快速浏览标题,点击感兴趣的文章
- 收藏有价值的文章到笔记软件
- 晚上抽时间阅读收藏的内容
这个过程存在几个明显问题:
- 时间成本高:每天平均花费1.5小时在信息筛选上
- 信息质量不稳定:容易被标题党吸引,错过真正有价值的内容
- 缺乏系统性:碎片化阅读难以形成行业趋势的整体认知
- 信息滞后:重要新闻可能因为推送机制错过
1.2 解决方案设计原则
基于这些痛点,我设想了理想的解决方案应该具备的特性:
- 自动化程度高:完全不需要人工干预的自动化流程
- 内容质量可控:建立可靠的内容筛选机制
- 深度分析能力:不只是简单聚合,还要有专业解读
- 定时稳定推送:形成固定的信息接收习惯
- 可扩展性强:能随着需求变化灵活调整
经过对多个技术方案的评估,最终选择了OpenClaw作为基础框架,主要考虑其以下几个特点:
- 内置定时任务调度系统
- 支持多种消息推送渠道
- 提供LLM集成能力
- 模块化的Skill设计理念
- 活跃的开发者社区
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 系统架构详解
2.1 整体架构设计
系统采用典型的三层架构设计,将数据采集、处理分析和推送展示三个环节解耦:
code复制数据层 → 处理层 → 展示层
具体实现上分为三个核心模块:
-
数据采集模块(Python脚本)
- 负责从多个来源抓取原始新闻数据
- 执行初步的清洗和过滤
- 生成中间数据缓存
-
内容处理模块(OpenClaw Skill)
- 读取中间数据
- 调用LLM进行内容提炼
- 生成最终展示格式
-
推送展示模块(OpenClaw消息服务)
- 定时触发整个流程
- 处理消息格式转换
- 对接飞书API完成推送
这种架构设计的优势在于:
- 各模块职责单一,便于维护
- 中间数据可追溯,方便调试
- 处理流程可灵活调整
- 推送渠道可随时更换
2.2 关键技术选型
2.2.1 数据采集方案对比
在数据采集环节,我评估了三种常见方案:
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| RSS订阅 | 实现简单 | 源有限,更新慢 | 个人轻度使用 |
| 爬虫 | 灵活可控 | 维护成本高 | 特定网站采集 |
| 搜索API | 覆盖面广 | 可能有调用限制 | 广泛主题采集 |
最终选择百度搜索API方案,因为:
- 覆盖了所有主流媒体网站
- 支持精确的时间范围筛选
- 提供网站过滤功能
- 有稳定的Python SDK
2.2.2 内容处理技术栈
内容处理环节的核心技术选择:
- OpenClaw框架:提供任务调度和LLM集成能力
- GPT-4模型:用于内容摘要和趋势分析
- Jinja2模板:格式化最终输出内容
- JSON Schema:定义数据结构规范
特别值得一提的是GPT-4模型的使用技巧:
- 采用few-shot prompting提供示例
- 设置temperature=0.3保证稳定性
- 使用max_tokens=1500控制输出长度
- 添加role指令:"你是一位资深的AI行业分析师"
2.3 数据流设计
系统的完整数据流如下:
-
触发阶段:
- OpenClaw Cron服务每天9:00触发任务
- 调用generate_report.py脚本
-
采集阶段:
- 脚本执行13个并行搜索任务(9主题+4媒体)
- 每个搜索获取10条结果
- 合并得到约130条原始数据
-
处理阶段:
- 应用媒体权重过滤
- 执行标题哈希去重
- 按权重排序取前50条
- 保存为JSON中间文件
-
分析阶段:
- OpenClaw读取JSON文件
- 调用LLM生成摘要和洞察
- 格式化Markdown输出
-
推送阶段:
- 通过飞书Webhook发送消息
- 记录推送日志
- 异常情况发送警报
3. 核心实现细节
3.1 数据采集模块
3.1.1 搜索策略设计
搜索策略采用"主题+媒体"双维度覆盖:
python复制TOPIC_QUERIES = [
"AI 大模型",
"人工智能 自动驾驶",
"AI 智能体 Agent",
"人形机器人",
"OpenAI 谷歌 英伟达"
]
MEDIA_QUERIES = [
"机器之心 site:jiqizhixin.com",
"新智元 site:aiera.com",
"量子位 site:qbitai.com",
"36 氪 AI site:36kr.com"
]
这种设计确保了:
- 主题覆盖AI领域热点方向
- 重点媒体内容不会遗漏
- 每个搜索限定最近一周结果
3.1.2 媒体权重算法
媒体权重配置采用分级制度:
python复制MEDIA_WEIGHTS = {
100: ['机器之心', '新智元', '量子位'], # 专业AI媒体
80: ['新华社', '人民日报', '央视新闻'], # 官方媒体
60: ['36氪', '钛媒体', '虎嗅'], # 科技媒体
40: ['新浪科技', '网易科技', '腾讯科技'], # 门户科技
5: ['百家号', '搜狐号', '头条号'] # 自媒体
}
权重计算逻辑:
- 提取新闻来源域名
- 匹配权重字典
- 默认权重为5
- 过滤权重<10的内容
3.1.3 去重算法实现
去重是保证内容质量的关键环节。经过测试比较了几种方案:
- 精确匹配:效果差,同一新闻标题可能有变体
- 编辑距离:计算量大,准确率一般
- 标题哈希:性价比最高的方案
最终实现的哈希去重逻辑:
python复制def deduplicate(news_list):
seen = set()
result = []
for news in news_list:
# 标准化处理
title = news["title"].lower().replace(" ", "")
# 生成哈希
title_hash = hash(title)
if title_hash not in seen:
seen.add(title_hash)
result.append(news)
return result
实际测试显示,这种方法可以过滤掉90%以上的重复内容,而处理时间仅增加约200ms。
3.2 内容处理模块
3.2.1 LLM提示工程
LLM处理的提示词设计非常关键。经过多次迭代,最终确定的提示结构:
code复制你是一位资深的AI行业分析师,请根据提供的新闻列表:
1. 筛选出10条最具行业价值的新闻
2. 为每条新闻生成:
- 简洁摘要(50字以内)
- 专业洞察(100字以内)
3. 最后总结3-5个当日行业趋势
新闻列表:{news_items}
输出格式:
📰 标题 | 来源
📝 摘要
💡 洞察
这个提示设计的特点:
- 明确角色设定
- 具体输出要求
- 结构化格式
- 包含示例
3.2.2 内容缓存策略
为了提高系统可靠性,实现了多级缓存:
- 原始数据缓存:保存搜索得到的原始JSON
- 处理中间结果:存储LLM处理前的数据
- 推送内容缓存:保留最终发送的Markdown
缓存文件命名包含日期信息:
code复制ai_news_raw_20240315.json
ai_news_processed_20240315.json
ai_news_output_20240315.md
这种设计带来了以下好处:
- 出现问题可以回溯检查
- 避免重复处理节省资源
- 便于生成周报/月报汇总
3.3 推送展示模块
3.3.1 消息模板设计
推送消息采用Markdown格式,经过精心设计:
markdown复制📰 今日AI新闻早报({date})
⭐ {rating} | {title}
📝 {summary}
💡 {insight}
📰 来源:{source} | {date}
...
💡 今日趋势观察:
1. {trend1}
2. {trend2}
3. {trend3}
评分系统规则:
- ⭐⭐⭐⭐⭐:重大突破或政策
- ⭐⭐⭐⭐:重要行业动态
- ⭐⭐⭐:一般技术新闻
3.3.2 飞书集成实现
飞书机器人配置要点:
- 创建自定义机器人
- 获取Webhook地址
- 设置安全签名
- 处理消息卡片样式
推送代码示例:
python复制def send_to_feishu(content):
headers = {"Content-Type": "application/json"}
payload = {
"msg_type": "interactive",
"card": {
"config": {"wide_screen_mode": True},
"elements": [{
"tag": "markdown",
"content": content
}]
}
}
requests.post(WEBHOOK_URL, json=payload, headers=headers)
4. 运维与优化经验
4.1 性能监控指标
系统运行两个月后收集的关键指标:
| 指标 | 平均值 | 优化措施 |
|---|---|---|
| 采集时间 | 45s | 增加并行搜索 |
| 处理时间 | 15s | 优化去重算法 |
| 推送延迟 | <1s | 改用异步调用 |
| 成功率 | 99.8% | 增加重试机制 |
| LLM消耗 | 180K tokens/天 | 优化提示词 |
4.2 常见问题排查
4.2.1 消息推送失败
症状:系统显示成功但收不到消息
排查步骤:
- 检查飞书机器人是否在线
- 验证Webhook地址是否正确
- 查看网络连接状态
- 检查消息内容是否超限
解决方案:
- 实现消息分段发送
- 增加失败重试逻辑
- 添加监控告警
4.2.2 内容质量下降
症状:近期推送内容相关性降低
可能原因:
- 搜索关键词需要更新
- 媒体权重需要调整
- 去重阈值不合适
优化方法:
- 每月评审关键词列表
- 动态调整媒体权重
- 优化标题预处理逻辑
4.3 系统扩展方向
基于用户反馈,计划中的改进:
-
个性化推荐:
- 记录用户点击偏好
- 动态调整内容权重
- 实现简单协同过滤
-
多语言支持:
- 增加英文源采集
- 集成翻译API
- 支持双语推送
-
交互功能:
- 允许对新闻评分
- 支持收藏分享
- 添加评论功能
-
数据分析:
- 生成周报/月报
- 趋势可视化
- 热点话题追踪
5. 项目总结与展望
这个AI新闻早报系统从构思到稳定运行历时两个月,期间经历了三次大的架构调整。目前系统每天稳定地为我和团队成员提供高质量的行业资讯,显著提升了信息获取效率。
5.1 关键收获
- 分离关注点:数据采集与内容处理的分离是系统稳定的关键
- 缓存很重要:合理使用缓存可以大幅提高系统可靠性
- 提示词工程:LLM的效果高度依赖提示词设计
- 监控不可少:完善的日志和监控能快速定位问题
5.2 经验教训
- 避免过度设计:初期花费太多时间在边缘功能上
- 重视异常处理:早期版本对网络波动处理不足
- 预留扩展空间:数据结构应该更灵活一些
- 文档要同步:几次因为文档滞后导致配置错误
5.3 未来计划
基于现有架构,下一步计划:
- 增加多数据源支持(学术论文、专利等)
- 实现基于用户反馈的动态调权
- 开发浏览器插件版本
- 构建行业知识图谱
这个项目的成功验证了"AI+自动化"在信息处理领域的巨大潜力。随着技术的不断进步,我相信这类系统会变得越来越智能和个性化,最终成为每个专业人士的标配工具。
