关于 bot-developer
bot-developer 是面向开发者的技能,涵盖 Discord、Telegram 和 Slack 生产级机器人构建。重点包括事件驱动架构、对话状态管理、限流与审核系统。
主要功能
- 01事件驱动的机器人架构
- 02多轮对话状态管理
- 03分布式与自适应限流
- 04带衰减机制的积分审核
- 05自动审核规则与模糊匹配
- 06审计日志与安全建议
适用场景
- 01构建 Discord、Telegram 或 Slack 机器人
- 02创建审核和自动审核系统
- 03实现多轮对话流程
- 04添加经济、XP 或等级功能
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ curiositech/ some_claude_skills --skill bot-developer安装后在 Claude Code 中输入/bot-developer确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
CHANGELOG.md.claude-plugin/plugin.jsonreferences/architecture-patterns.mdmoderation-system.mdplatform-templates.mdrate-limiting.md详细介绍
Bot 开发者
擅长构建具备完善架构、状态管理和可扩展性的生产级 Bot。
快速开始
User: "Build a Discord moderation bot with auto-mod"
Bot Developer:
1. Set up event-driven architecture (message broker + service layer)
2. Implement state machine for multi-turn mod flows
3. Add distributed rate limiting (Redis)
4. Create point-based moderation with decay
5. Configure auto-mod rules (spam, caps, links, words)
6. Deploy with proper logging and error handling
核心原则:生产级 Bot 需要限流、状态管理和优雅降级,而不只是命令处理器。
核心能力
1. 平台专业知识
| 平台 | 连接方式 | 最适合 |
|---|---|---|
| Discord | Gateway(WebSocket) | 游戏社区、大型服务器 |
| Telegram | Webhook(生产环境) | 国际用户、群组/频道 |
| Slack | Socket Mode/Webhook | 工作场所、集成 |
2. 生产架构
- 使用消息代理(Redis Streams / RabbitMQ)的事件驱动设计
- 服务层分离(用户、审核、经济系统、集成)
- PostgreSQL + Redis + S3 数据层
- 基于 Cog 的模块化结构
3. 状态管理
- 用于多轮对话的有限状态机
- 超时处理(不活跃后自动重置)
- 防止竞争条件
- 跨轮次保留上下文
4. 限流
- 使用 Redis 后端的分布式限流器
- 根据 API 响应头调整的自适应限流器
- 按用户、服务器和全局设置限流桶
- 优雅降级并提供 retry-after 信息
5. 审核系统
- 基于积分的逐级处理(阈值可配置)
- 随时间自动衰减
- 自动审核规则(刷屏、大写、链接、违禁词)
- 使用模糊匹配拦截绕过尝试(l33t 文字)
- 用于合规的审计日志
逐级处理阈值
| 积分 | 操作 |
|---|---|
| 0-2 | 不采取操作 |
| 3-5 | 禁言 |
| 6-9 | 踢出 |
| 10-14 | 临时封禁 |
| 15+ | 永久封禁 |
自动审核规则
| 规则 | 检测方法 |
|---|---|
| 刷屏 | 滑动时间窗口内的消息频率 |
| 大写 | 字符比例(>70% 为大写) |
| 链接 | URL 正则表达式 + 域名白名单 |
| 词语 | 词典 + Levenshtein(85% 阈值) |
| 提及 | 统计 @mention 及其变体 |
| 邀请 | Discord 邀请正则表达式 + URL 展开 |
适用场景
适用于:
- Discord/Telegram/Slack Bot 开发
- 审核和自动审核系统
- 多轮对话流程
- 经济/XP/等级系统
- 与外部 API 集成
不适用于:
- 没有聊天界面的 Web API(使用 backend-architect)
- 通用自动化脚本(使用 python-pro)
- 前端聊天小组件(使用 frontend-developer)
- 单独进行 AI/ML 模型集成(使用 ai-engineer)
反模式
反模式:在生产环境中轮询
表现:使用 bot.polling() 或 Telegram 长轮询
问题:浪费资源、响应较慢,且无法扩展
替代方案:使用带有适当验证的 Webhook
反模式:没有限流
表现:发送 API 请求时不进行节流 问题:导致 Bot 被封禁、触发 429 错误、用户体验差 替代方案:实现能遵循 API 响应头的自适应限流器
反模式:仅在内存中保存状态
表现:将对话状态存储在 Python 字典中 问题:重启后状态丢失,也无法扩展到多个实例 替代方案:使用 Redis 保存状态,使用 PostgreSQL 持久化数据
反模式:阻塞事件处理器
表现:在 on_message 中执行长时间运行的操作
问题:阻塞所有其他事件,导致超时
替代方案:使用异步任务,通过消息队列处理繁重工作
安全检查清单
TOKEN SECURITY
├── Never commit tokens to git
├── Use environment variables or secret manager
├── Rotate tokens if exposed
└── Separate tokens for dev/staging/prod
PERMISSION CHECKS
├── Verify user permissions before action
├── Use platform's permission system
├── Check bot's permissions before attempting
└── Fail safely if permissions missing
INPUT VALIDATION
├── Sanitize all user input
├── Validate command arguments
├── Parameterized queries (no SQL injection)
└── Rate limit user-triggered actions
参考文件
references/architecture-patterns.md- 事件驱动架构、状态机references/rate-limiting.md- 分布式与自适应限流references/moderation-system.md- 基于积分的审核、自动审核references/platform-templates.md- Discord.py、Telegram webhook 模板、安全性
核心见解:生产级 Bot 故障通常源于限流和状态错误,而非命令逻辑不佳。先构建基础设施。
搭配使用:ai-engineer(LLM 集成)| backend-architect(API 设计)| deployment-engineer(托管)
评论
支持 Markdown