OpenClaw定时任务实战：千问3.5-27B每日早报自动生成与推送

1. 为什么需要自动化早报服务

每天早上打开手机，总会被各种新闻推送轰炸——财经、科技、社会热点混杂在一起，真正关心的内容反而被淹没。作为一个技术从业者，我发现自己最需要的是经过筛选的行业动态和深度技术解读，而不是泛泛的社会新闻。

去年尝试过用Python写爬虫抓取RSS源，再用模板拼接成日报。但维护成本太高：每次网站改版就要调整解析规则，内容质量也参差不齐。直到发现OpenClaw+千问3.5-27B的组合，才找到理想的解决方案——让AI理解我的需求，从海量信息中提炼真正有价值的内容。

2. 技术方案设计

2.1 核心组件选型

整个系统由三个关键部分组成：

• OpenClaw：作为任务调度与执行引擎，负责定时触发、流程控制
• 千问3.5-27B：处理自然语言理解与内容生成
• 飞书机器人：作为最终推送渠道

选择这个组合主要考虑：

1. 隐私性：所有数据处理都在本地完成，不会将阅读偏好暴露给第三方
2. 灵活性：可以随时调整新闻源和生成模板
3. 成本可控：相比调用商业API，自建方案长期成本更低

2.2 工作流设计

整个自动化流程分为四个阶段：

1. 信息采集：从预设的15个技术类RSS源抓取最新内容
2. 内容过滤：根据我的订阅关键词（如"LLM"、"RAG"）进行初筛
3. 摘要生成：千问模型理解原文后，生成包含核心观点的三段式摘要
4. 格式编排：将摘要转换为飞书富文本格式，添加原文链接

# 简化版工作流示意
cron触发 → OpenClaw启动 → 抓取RSS → 模型过滤 → 生成摘要 → 格式转换 → 飞书推送

3. 具体实现步骤

3.1 环境准备

首先确保已部署好OpenClaw和千问3.5-27B模型。我的配置是：

• 硬件：NVIDIA RTX 4090显卡（24GB显存）
• OpenClaw版本：v1.2.3
• 模型镜像：qwen3.5-27b-mirror

验证模型服务可用性：

curl -X POST http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
  "model": "qwen3.5-27b",
  "messages": [{"role": "user", "content": "测试连接"}]
}'

3.2 配置飞书通道

在OpenClaw配置文件中添加飞书机器人配置：

{
  "channels": {
    "feishu": {
      "enabled": true,
      "appId": "cli_xxxxxx",
      "appSecret": "xxxxxx-xxxxxx",
      "connectionMode": "websocket"
    }
  }
}

测试消息推送：

openclaw tools feishu --text "测试消息"

3.3 编写早报生成Skill

创建自定义Skill文件morning_news.js，核心逻辑包括：

// 示例代码片段
async function generateDigest(articles) {
  const prompt = `请用三段式总结以下内容：
  1. 核心观点
  2. 技术细节
  3. 行业影响
  
  原文：${articles[0].content}`;
  
  const resp = await openclaw.models.complete({
    model: "qwen3.5-27b",
    messages: [{role: "user", content: prompt}]
  });
  
  return formatForFeishu(resp.choices[0].message.content);
}

3.4 设置定时任务

通过crontab配置每日7:30自动执行：

30 7 * * * /usr/local/bin/openclaw task run morning_news

为避免资源冲突，特别添加了模型调用限流：

{
  "tasks": {
    "morning_news": {
      "rateLimit": "1/30s"
    }
  }
}

4. 实际效果与优化

4.1 生成样例

经过两周调优后，典型的早报内容如下：

技术早报 2024-03-15

1. 核心观点：Meta发布Llama3技术白皮书，上下文窗口扩展至128K
2. 技术细节：采用新型位置编码方案，在长文本任务中PPL降低17%
3. 行业影响：可能推动RAG架构向更长的上下文依赖转变

查看原文

4.2 遇到的坑与解决

问题1：内容重复推送

• 现象：同一篇文章有时会出现在连续两天的早报中
• 解决：在Skill中添加了基于MD5的内容去重缓存

问题2：生成速度慢

• 现象：处理10篇文章需要超过5分钟
• 优化：
  • 改用流式API逐步返回结果
  • 对非重点文章只生成单段摘要

问题3：格式错乱

• 现象：飞书消息中的Markdown标记未被正确解析
• 调整：改用飞书富文本JSON格式直接构造消息体

5. 个人使用建议

经过一个月的实际使用，总结出几点经验：

1. 关键词配置：不要设置太宽泛的关键词（如"AI"），否则会包含大量低质内容。我现在的策略是组合使用"LLM+微调+32K"这类具体术语。

2. 模型温度值：发现temperature=0.7时生成内容最平衡。低于0.5会过于死板，高于0.9则容易跑题。

3. 错误处理：一定要在Skill中添加重试机制。网络波动导致模型调用失败时，自动重试3次后再报错。

这个方案最大的价值不在于省时间（其实调试花了大量精力），而是获得了完全符合个人需求的信息筛选。现在每天早上的技术早报就像有个了解我喜好的专业编辑精心准备的，这种体验是通用新闻APP无法提供的。

---

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。