Slack 是个黑洞。消息越积越多，每个人都在 @你，关键的决策、重要的反馈、需要置顶的事项全埋在几百条未读里。你当然可以手动整理，但说实话，谁有那个时间？
更烦的是，很多操作明明可以自动化，但你一直没有动手去做。给消息加一个”已读”标记、把老板的决策置顶、定期扫一眼关键频道的动态，这些事每天都在重复，每次都要打开客户端、找到频道、点几下。你知道有办法解决，但一直排不上优先级。
Peter Steinberger 的 Slack Skill 瞄准的就是这个缺口。它是一个运行在 Clawdbot 上的 MCP 工具，安装一个命令就能让 AI 代理直接操作你的 Slack 工作区。不是通知你、不是提醒你，是替你读消息、加反应、发消息、置顶内容。47.7k 次下载、157 个星标、安全审计通过。
说白了，这篇文章就想讲清楚一件事：当 AI 能直接操控你的消息工具时，日常工作流会变成什么样。不是概念讨论，是看它到底能做什么、怎么做的、以及 steipete 的设计选择哪些地方值得琢磨。如果你也在想让 AI 打理 Slack 的日常操作，看完应该能少走点弯路。
环境准备
先别被”MCP 工具””Bot Token”这些词吓到。这个 Skill 的前置条件就两个：一个 WorkBuddy 环境，一个 Slack 工作区的 Bot Token。不需要额外配置数据库、不需要改权限体系、不需要单独部署服务。
Slack Bot Token 的获取路径也不复杂。在 Slack API 控制台创建一个 App，授予必要的 OAuth 权限范围，主要是 chat:write、reactions:write、pins:write、channels:history、channels:read，安装到工作区后拿到 Bot Token。然后在 Clawdbot 配置里填入这个 Token。整个过程如果熟悉 Slack 的 App 管理，五分钟内搞定。
安装 Skill 本身更简单：
openclaw skills install slack
对，就这一行。没有依赖安装、没有编译步骤、不需要手动下载任何东西。steipete 把入口压缩到了它能达到的最小体积。
装完之后跑个简单验证：让 AI 代理读一条频道里的最近消息。如果能正确返回消息内容，说明 Slack 连接已经打通。如果没通，十有八九是 Bot Token 的权限范围没给够。reactions:read 和 channels:history 是最容易被漏掉的两项。
操作流程
这个 Skill 的工作原理出奇的直白。它没有复杂的多步编排、没有条件分支、没有嵌套路由。整个工具就是一个统一的 slack 命令，通过 action 参数区分 11 种操作。AI 代理拿到你的指令后，直接调用对应 action，返回结果。
实际用起来，最常见的操作是读消息和加反应。你可以让 AI 代理扫一遍某个频道的最近 20 条消息，找出需要你关注的内容，然后自动给关键消息加上 ✅、👀 或者任何你指定的表情。在多人协作的频道里，这种操作能让你的注意力只聚焦在真正需要决策的事情上。
发送和编辑消息是另一个高频场景。AI 代理可以以 Bot 的身份在频道或私信中发消息，目标可以是 channel:C123 或 user:U456。发送后发现措辞需要调整，也能直接编辑甚至删除。编辑需要提供 channelId 和 messageId，这两个参数通常可以从上下文行中拿到，不需要手动输入。
置顶功能是我觉得被低估的一个。活跃的频道里，关键决策、每周状态更新、重要公告往往被新消息迅速淹没。让 AI 代理自动置顶这些内容，或者根据特定规则取消过期置顶，省下的手动操作远超预期。试想一下：每次站会结束后，TL 的总结消息自动被置顶，不需要任何人多做一个动作。
另外两个功能组是成员信息和自定义表情列表。memberInfo 根据用户 ID 查询成员资料，emojiList 拉取工作区所有自定义表情。这俩使用频率不如前三个高，但在需要快速定位某个团队成员或确认某个表情可用时，比打开 Slack 客户端翻找快太多了。
关键设计
steipete 在这个 Skill 的设计上做了一个很关键的选择：把 11 个操作全部塞进一个 slack 工具里，而不是拆成 11 个独立工具。这不是偷懒。统一入口意味着 AI 代理不需要在多个工具之间做选择，每次跟 Slack 交互都走同一条通道，路由成本为零。
从设计意图来推，steipete 显然不打算做一个”Slack 全能客户端”。这个 Skill 的定位是轻量级代理层，让 AI 能做 Slack 里最常用、最重复的那几件事，而不是取代 Slack 客户端。11 个 action 覆盖的是消息、反应、置顶、成员、表情，没有频道管理、没有工作区设置、没有权限控制。边界划得很清楚。
这个设计的 trade-off 也很明显。好处是极简、零学习成本、AI 代理不会选错工具。代价是灵活性受限，批量归档消息、创建新频道、修改频道主题这些操作都不在支持范围内。不过这些低频操作本来也不该由 AI 代理来负责。
如果我来设计，可能会加一个”搜索消息”的 action。目前读消息只能按最近 N 条拉取，没法按关键词或时间范围搜索。这在信息量大的频道里是一个明显的缺口。但加了搜索之后复杂度会跳一个量级，需要支持 Slack 的搜索语法、分页、排序，可能正是 steipete 想避免的。
使用场景
最能体现这个 Skill 价值的场景是日常站会自动化。团队在 Slack 频道里每人发一条今日计划和昨日进度，AI 代理逐条读完，给每个人的消息加上 ✅ 反应，然后置顶 TL 的总结消息。整个过程不需要你打开 Slack 客户端，对 AI 说一句”帮我处理今天的 standup”就全搞定了。
决策追踪是另一个实用场景。设计评审、技术方案讨论、产品方向拍板，这些讨论通常散落在频道的不同位置。用 Slack Skill 配合 AI 的记忆能力，可以做到：识别含决策关键词的消息、自动置顶、标记”已确认”表情、并在后续讨论中引用这些决策。从社区反馈来看，这恰恰是很多团队装上之后第一个想到的用法。
多频道监控场景更激进一些。AI 代理可以定期扫多个频道的最近消息，按重要程度过滤后向你汇报摘要。你不需要在十几个频道之间切换，问一句”有什么需要我关注的”就行。这个用法对 Bot Token 的 channels:history 和 channels:read 权限要求更全面，但配置一次就够了。
局限性也值得说清楚。这个 Skill 不支持 Slack 的 Block Kit 消息格式，只能发送纯文本，不适合需要精细内容排版的场景。也不适合大规模消息分发，如果你要给几百人发 DM，Slack 自身的速率限制会让操作变得很慢。它最擅长的还是高频、轻量、重复性的日常 Slack 操作。
洞察与反思
说实话，MCP 工具替代传统的 Slack Bot 集成，这个趋势比单个 Skill 本身更有意思。以前要做一个 Slack 自动化，你得写一个 Bot 服务、处理 OAuth、管理 Webhook、部署维护。现在一个 11-action 的 MCP 工具加上一个 Bot Token 就能覆盖 80% 的常见需求。开发成本从”几周”降到”几分钟”，这才是真正的范式变化。
Peter Steinberger 给这个 Skill 选的是 MIT-0 许可证，比 MIT 还松，连署名都不要求。他是 PSPDFKit 的创始人、iOS 开发圈里有名的技术极客，这种选择不是偶然。开源、零依赖、极简接口，这套组合拳的本质是降低采纳门槛。一个 Skill 能不能活下去，很多时候不取决于功能多强，而取决于用户愿不愿意花五分钟试试。
但我越看越觉得这个极简设计是一把双刃剑。11 个 action 覆盖了 Happy Path，边缘场景完全没处理。消息发送失败后的重试策略是什么？速率限制触发了怎么降级？Bot Token 过期了有没有提醒机制？这些都不是”功能”，而是生产环境里真正决定可靠性的东西。目前全部依赖 Clawdbot 的底层处理，Skill 自身没有任何容错逻辑。
MCP 生态正在快速膨胀，像 Slack Skill 这种”单一工具、单一功能”的轻量级 MCP 会越来越多。但当你有 20 个这样的 Skill 同时运行时，谁来协调它们之间的优先级和冲突？Slack Skill 要发消息、GitHub Skill 要评论 PR、Notion Skill 要更新文档，如果同时触发，谁先谁后、谁等谁、谁覆盖谁？这是 MCP 生态下一个阶段必须回答的问题。
资源地址
| 资源 | 地址 |
|---|---|
| ClawHub | https://clawhub.ai/steipete/slack |
总结
Slack 最让人疲惫的不是消息多，是你明知道有些操作可以自动化、但一直没有动手去做。React、置顶、读消息、发消息，这些事每天都在重复，每次都要打开客户端点几下。steipete 的这个 Skill 把这几件事压成了一个命令，本质上是在替你省掉那些不必要的手动操作。
装这个 Skill 不会超过两分钟。先从最简单的开始：让它帮你标记已完成的对话、置顶本周的重要决策。别一上来就让它替你在频道里发言，先观察、再加反应、最后再开口，这个顺序比较安全。
说到底，AI 代理接管消息工具这件事，争议本身比技术实现更值得关注。让 AI 替你读消息、替你回复、替你表态，边界在哪？哪些操作可以放心交给它、哪些必须自己来？每个团队对这个问题都会有不同的答案。你自己的答案是什么，可能比这个 Skill 能做到什么更重要。