用 OpenClaw 搭建 Slack 每日摘要机器人
手把手教你用 OpenClaw 搭建 Slack 每日摘要工作流：自动收集频道消息、AI 智能总结、定时推送，让团队不再错过重要信息。
最近更新: 2026-03-31
所需 Skills
你将搭建什么
一套自动化的每日摘要系统：
- 收集消息 — 全天自动采集 Slack 频道中的对话
- AI 智能总结 — 提取关键要点、决策和待办事项
- 定时推送摘要 — 在你设定的时间准时送达
- 全自动运行 — 通过 Cron 调度，配好就不用管了
适合团队负责人、远程办公者，或者任何需要掌握全局又不想逐条刷消息的人。
为什么需要每日摘要
Slack 的实时通知是一把双刃剑。每一条消息推送都会打断你的专注状态，研究表明被打断后平均需要 23 分钟才能完全恢复专注力。算下来，一天的碎片化时间损失惊人。
每日摘要的本质是批量处理沟通信息。不是每条消息到了就反应，而是在你选择的时间，一次性收到结构化的总结。这消除了"消息焦虑"——那种看到侧边栏一堆未读频道时的压迫感——取而代之的是平静、可预期的信息流。
扫 10 个频道的 150 条独立消息，需要持续的脑力投入：过滤噪音、跟踪讨论、记住上下文。而一份结构良好的摘要把这些压缩成 2 分钟的阅读量，按重要性排序。你能完全掌握决策、阻塞点和待办事项，却不会被塞满的侧边栏所焦虑。
这种方式特别适合管理者、高管和跨职能协作者——需要对多个频道保持感知，但不需要实时参与每一场对话。
前置条件
- OpenClaw 已安装并配置好
- Slack 工作区，有管理员或应用安装权限
- Slack Bot Token，需包含
channels:history、channels:read和chat:write权限 - Node.js 18+
第 1 步：安装所需 Skills
# 1. Slack 集成 npx clawhub@latest install slack # 2. AI 摘要生成 npx clawhub@latest install summarize # 3. 定时调度 npx clawhub@latest install cron
第 2 步：配置 Slack 集成
创建 Slack 应用
- 前往 api.slack.com/apps，创建新应用
- 在 OAuth & Permissions 中添加以下 Bot Token Scopes：
channels:history— 读取频道消息channels:read— 列出频道chat:write— 发送摘要消息
- 将应用安装到你的工作区
- 复制 Bot User OAuth Token（以
xoxb-开头）
配置 Skill
在 OpenClaw 中设置 Slack Token：
# Skill 首次使用时会提示输入配置 clawhub inspect slack
第 3 步：配置摘要生成器
Summarize Skill 可以处理任何文本输入。对于每日摘要场景，建议配置：
- 输出格式：带分节的结构化要点
- 关注领域：决策、待办事项、公告、问题
- 篇幅：精炼（每个频道 200-400 字）
第 4 步：设置 Cron 定时任务
创建每日 Cron 任务运行摘要工作流：
# 每个工作日下午 6 点推送 # Cron Creator 支持自然语言输入
Cron 任务会依次：
- 从配置的频道获取消息（过去 24 小时）
- 交给 Summarize Skill 处理
- 格式化为结构化摘要
- 推送到指定的摘要频道
第 5 步：测试摘要
在依赖 Cron 调度之前，先手动运行一次验证：
- 检查 Slack 连接是否正常
- 确认消息拉取返回了预期内容
- 检验摘要生成的质量
- 验证摘要发送到了正确的频道
自定义选项
多频道摘要
监控多个频道并按频道分组汇总：
#engineering— 技术讨论和决策#product— 功能需求和路线图更新#incidents— 线上问题和解决方案#general— 全公司公告
优先级过滤
让摘要器重点标注：
- 带表情回复的消息（👀、✅、🚨）
- 提到特定关键词的消息
- 回复数较多的讨论串
- 特定人员的消息（领导层、值班人员）
多时段摘要
针对不同需求设置不同推送时间：
- 早报（上午 8:00）— 隔夜活动摘要
- 日终总结（下午 6:00）— 全天摘要
- 周报（周五下午 4:00）— 一周回顾
进阶：条件触发摘要
不是每天都需要摘要。你可以设置智能触发条件，只在有意义的时候发送。
跳过周末和节假日
将 Cron 设为仅工作日运行，并维护一个节假日列表。Cron Skill 支持类似 0 18 * * 1-5 的表达式，只在工作日执行。对于节假日，在工作流开头加一个日期检查，匹配到节假日就提前退出。
紧急检测
设置关键词告警，绕过每日调度直接推送。如果消息中包含"故障"、"P0"、"安全事件"、"回滚"等关键词，系统会立即发送一条精简摘要，不用等到定时时间。这样两全其美：常规更新批量处理，关键事件实时告警。
活跃度阈值
设置最低消息数阈值。如果某个频道在 24 小时内消息不到 3 条，摘要价值不大。工作流可以先检查消息量，在活跃度低于阈值时跳过该频道甚至整个摘要。
关键词分类
定义关键词组来分类呈现特定主题。比如把提到"部署"、"发布"、"上线"的消息归入「发布」板块，把提到"bug"、"崩溃"、"报错"的消息归入「问题」板块。在 AI 摘要基础上增加了一层智能分类。
不同角色的摘要模板
不同角色需要从相同频道获取不同信息。你可以创建多套摘要配置，分别面向不同受众。
技术负责人
🔧 技术摘要 — 2026年3月31日 阻塞问题 (2) • 认证服务在 staging 环境触发限流 — @chen 排查中，需要 DevOps 支持 • CI 流水线集成测试失败 — 支付模块的不稳定测试 Pull Request (5 已合并, 3 待审) • 已合并：移动端 API 的 GraphQL 迁移 (#1842)、缓存失效修复 (#1839) • 待审查：数据库索引优化 (#1845) — 已开放 2 天 部署 • 生产环境部署 v2.3.12 于下午 2:30 — 成功，无回滚 • Staging 部署 v2.4.0-beta.3 于下午 4:00 — 2 个冒烟测试失败 技术决策 • 已批准：PostgreSQL 切换到连接池方案 (RFC-0047) • 讨论中：采用 OpenTelemetry 做分布式链路追踪
产品经理
📦 产品摘要 — 2026年3月31日 功能讨论 • 移动端引导流程重新设计 — 3 个方案已分享，团队倾向方案 B • 企业级 SSO — Acme 客户反馈已整合到需求文档 • API 限流 — 开发者社区要求提高免费版配额 用户反馈 (来自 #support 和 #feedback) • 4 条请求：报表看板增加 CSV 导出功能 • 2 个企业客户对新搜索过滤器给出好评 • Bug 反馈：日期选择器在 Safari 上不工作（工单已创建） 已做决策 • v2.4 功能冻结确认为 4 月 3 日 • Q2 OKR 草稿截止 4 月 7 日 — 各 PM 请提交 近期安排 • 设计评审定在 4 月 2 日上午 10:00
高管
📊 高管简报 — 2026年3月31日 关键指标 • 活跃用户：12,847（周环比增长 3.2%） • API 可用性：99.97%（SLA 目标：99.9%） • 待处理工单：23（较昨日 31 个减少） 事故 • 一起已解决事故：数据库连接池耗尽（停机 45 分钟） • 根因已定位，修复已部署 — 未影响客户数据 战略决策 • 工程团队批准 PostgreSQL 连接池迁移 • v2.4 功能冻结定在 4 月 3 日 — 按计划 4 月 15 日发布 需要关注 • 企业定价方案需要财务部意见 — 阻塞 2 个销售对话 • Q2 招聘计划：3 个工程岗位已获批，职位描述待编写
摘要输出示例
一份典型的每日摘要长这样：
📋 每日摘要 — 2026年3月31日 🔧 #engineering (12 条消息) • 决策：移动端 API 从 REST 迁移到 GraphQL（@sarah 已批准） • 待办：@mike 在周四前更新 API 文档 • 讨论：新缓存层的性能基准测试 — 结果待出 📦 #product (8 条消息) • 公告：v2.4 功能冻结从 4 月 3 日开始 • 需求：3 个新功能需求已标记进 Q2 规划 • 问题：企业版定价方案 — 需要 @finance 给意见 🚨 #incidents (2 条消息) • 已解决：数据库连接池耗尽（10:30 - 11:15） • 当前无活跃事故
周报格式
适合周末回顾的宏观视角：
📋 周报 — 2026年3月25日-31日 本周亮点 • GraphQL 迁移获批并启动实施 • v2.3.12 发布，缓存层改进带来 40% API 响应提速 • 2 个新企业客户完成上线 数据概览 • 4 个频道共 87 条消息 • 6 项决策已做出，12 项待办已创建 • 3 起事故（全部解决，平均处理时间 38 分钟） 下周待跟进 • 企业定价方案 — 等待财务部审核 • OpenTelemetry RFC — 还需 2 人批准 • 移动端引导流程重设计 — 周二最终设计评审
项目维度摘要
当你需要围绕某个具体项目看进展：
📋 项目摘要：移动应用 v3.0 — 2026年3月31日 进展 • 认证流程开发完成（PR #1842 已合并） • 推送通知服务 — 完成 80%，集成测试通过 • 离线模式 — 设计方案已批准，4 月 2 日开始开发 阻塞 • 第三方 SDK 与 iOS 18 兼容性问题 — 已联系供应商 • 引导页设计素材延迟到 4 月 3 日 团队动态 • @alex 4 月 1-3 日休假 — @jordan 接手推送通知 • Sprint 评审移至 4 月 4 日下午 2:00
事故专项摘要
面向值班团队和关注稳定性的相关方：
🚨 事故摘要 — 2026年3月31日 活跃事故：0 今日已解决：1 • INC-2847：数据库连接池耗尽 - 持续时间：10:30 – 11:15（45 分钟） - 影响：12% 的 API 请求返回 503 错误 - 根因：新批处理任务中的连接泄漏 - 修复：连接池上限已调整，泄漏已在 PR #1840 中修复 - 后续：添加连接池监控告警（截止 4 月 2 日） 7 日趋势 • 事故总数：3（较上周 5 起减少） • 平均解决时间：38 分钟 • SLA 达标率：99.97%
常见问题排查
消息拉取失败
- 确认 Bot Token 包含
channels:history权限 - 确保 Bot 已加入你要监控的频道
- 检查频道 ID 是否正确（可用
channels:read列出）
摘要质量不理想
- 增加消息获取的上下文窗口
- 在摘要器配置中添加关注指令
- 在摘要前过滤掉 Bot 消息和自动化通知
Cron 任务未触发
- 确认 OpenClaw 实例正在运行
- 检查 Cron 任务状态：
clawhub list - 确认系统时区与你预期的一致
常见问题
可以。工作流的核心逻辑与平台无关。把 Slack Skill 替换为 Discord Skill（运行 `clawhub install discord`），Summarize 和 Cron Creator Skill 的使用方式完全不变。你只需提供 Discord Bot Token（需要 `Read Message History`、`Send Messages` 权限），并配置 Discord 服务器的频道 ID。
免费版 Slack 限制消息历史为 90 天，付费版无限制。每日摘要只回看 24 小时的消息，所以免费版完全够用。如果你要做周报或月度汇总，需要注意 90 天的限制。免费版团队如果需要更长期的总结，可以将摘要单独存档作为替代方案。
Cron 任务在 OpenClaw 所在机器上本地运行。如果那台机器在计划时间关机或休眠，任务不会执行，也没有内置的重试机制。要实现可靠的 7×24 运行，建议把 OpenClaw 部署在服务器、VPS 或云实例上。一台每月几美元的 VPS 或者一个闲置的树莓派就能胜任。
默认情况下摘要发送到 Slack 频道，但你有多个选择。可以利用 Slack 自带的邮件通知功能把摘要频道的消息转发到邮箱。或者在工作流中加入 Email Skill（`clawhub install email`），通过 SMTP 直接发送。后者还能把摘要发给不在 Slack 工作区的人，比如外部合作方或偏好邮件的高管。
在摘要器中配置正则表达式，自动脱敏 API 密钥、密码、Token 和个人身份信息。除了脱敏，还要控制哪些频道被纳入摘要——完全排除 `#hr-confidential` 或 `#legal` 等频道。为了增强安全性，把摘要发送到权限受控的私有频道，而不是公开频道。
为不同时区设置多个 Cron 调度，让各地区在方便的本地时间收到摘要。比如一个在东八区下午 6 点，一个在 CET 下午 6 点。每个调度可以覆盖相同的频道，但推送到各自地区的摘要频道。或者选一个所有人工作时间都有交集的统一时间（比如 UTC 上午 10 点），让团队成员上班后自行查看。
当然可以。最简单的方式是用工作日专用的 Cron 表达式，如 `0 18 * * 1-5`，只在周一到周五运行。对于公司节假日，在工作流配置中维护一个日期列表，工作流运行前先检查当前日期，命中就提前退出。如果团队分布在多个国家，还可以接入公共节假日 API。
可以。摘要发到 Slack 频道后，自动可以通过 Slack 搜索找到。如果需要更结构化的存档，可以在工作流中加一步，将每份摘要保存为 Markdown 或 JSON 文件，存到指定目录或云存储。随着时间积累，这就形成了一个可搜索的团队活动档案。有些团队会把摘要同步到 Notion、Confluence 或 Google Drive 作为长期参考。
可以。在工作流中接入日历 API（Google Calendar、Outlook），运行前检查特定日程。比如全员大会那天跳过摘要（反正大家都同步了），或者团队外出日跳过。在工作流开头加一个日历检查步骤，查找标记了特定关键词（如"no-digest"）的日程。这样你可以灵活控制哪些日子不发摘要，而不用改 Cron 表达式。
摘要发到 Slack 频道，所以频道成员就是受众。创建一个专门的频道如 `#daily-digest`，只邀请需要收到的人。要更精细的控制，可以设置多个摘要频道——一个给技术负责人、一个给产品经理、一个给高管——每个频道有自己的模板和数据来源。成员还可以利用 Slack 的频道通知偏好，在不需要的日子静音摘要频道，而不用退出。