前言

这篇文章最早写的是我第一次折腾 Discord 机器人时的一些记录。后来这一套东西在服务器上来回重构了很多次：做过 QQ 侧桥接，试过 AstrBot / NapCat，也试过把一堆功能混在同一个机器人里，最后还是慢慢收敛成了两条清晰的线：

• shen-test：偏工作、信息查询、任务提醒、生活管理
• shen-play：偏娱乐、轻互动、小游戏和抽卡

现在回头看，这个项目真正有价值的地方，不是“功能很多”，而是终于把边界划清楚了：该认真做事的时候有 shen-test，该放松玩的时候有 shen-play。这篇文章也按现在真实在跑的版本重写一遍，把开发过程、当前功能和一些踩坑后的取舍说清楚。

一、项目从“能跑”到“能长期用”

1. 最早的目标其实很朴素

我一开始的想法很简单：做一个能在 Discord 里陪我聊天、帮我查东西、顺手做一些日常任务的小机器人。那时候正好各种 AI 编程工具开始成熟，我自己虽然不是纯程序员路线，但已经能靠 AI 把很多想法快速落地。

早期版本其实很“贪心”——聊天、查询、娱乐、任务、提醒、抽卡、占卜、图像生成，全想塞进去。这样的好处是新鲜，坏处也很明显：

1. 功能越来越多，但边界越来越乱
2. 自然语言触发容易互相打架
3. 一个机器人同时承担“助理”和“玩伴”两种角色，体验会变得拧巴

后来我花了不少时间重构，才把这套东西变成现在比较舒服的样子。

2. 期间也尝试过 QQ 方案

中间我确实认真折腾过一段 QQ 机器人路线，甚至把 AstrBot、NapCat、WebUI、插件和端口映射都完整跑起来了。那套方案对“快速接平台”和“借现成插件”来说非常方便，但它也让我更清楚地意识到：

• 平台接入和插件生态很爽
• 但真正长期想要的“脑子”和“行为方式”，还是得自己掌控

所以最后我保留了这段经验，但主力维护的，还是回到了自己写的 Discord 机器人上。

二、当前的整体结构

现在这套 Discord 项目本体只保留两个机器人：

1. shen-test

定位是工作与生活管理型助理。

它负责：

• AI 对话
• 信息查询
• 任务与提醒
• 晨间简报
• 语音转写 / TTS / 截图 / 生图等工具能力
• 用户画像与长期记忆

一句话理解：它更像一个会逐渐理解你习惯的数字助理。

2. shen-play

定位是娱乐与轻互动型陪聊机器人。

它负责：

• 轻松聊天
• 人设切换
• 抽卡与历史卡片查看
• 小游戏
• 表情包、俳句、美女图、运势、星座等轻内容
• 洛克王国相关提醒

一句话理解：它更像一个负责“陪你玩”的机器人。

3. 为什么最后要拆成两个机器人

这个决定是整个项目里我最满意的一次重构。

因为现实里“工作助手”和“娱乐搭子”本来就不是同一种人格。如果把任务提醒、画像记忆、新闻查询、小游戏、抽卡、洛克王国提醒全部塞进一个入口里，最后只会变成：

• 功能是多了
• 但每一项都不够顺手

拆开以后，很多事情反而变简单了：

• shen-test 可以安心往效率工具和长期记忆方向做
• shen-play 可以放心往娱乐体验和玩法方向做
• 文档、配置、命令边界都会更清楚

三、shen-test：从聊天机器人变成助理

shen-test 是我第一个真正长期维护下来的机器人，也是这套项目里最“像产品”的部分。

1. AI 对话仍然是核心入口

最基础的用法还是直接在频道里 @shen-test 或私聊它。它支持多轮上下文，所以不是那种“一问一答就结束”的工具，而是能顺着聊下去。

但现在我更在意的已经不是“能不能聊天”，而是它能不能真的在日常里帮上忙。

2. 它现在的命令分组

AI 工具组

• /ai status
• /ai models
• /ai web
• /ai tts
• /ai draw
• /ai asr
• /ai screenshot

这一组是最接近“通用 AI 助手”的部分。

• status：看当前模型、连接状态、运行信息
• models：切换模型
• web：联网搜索或网页相关能力
• tts：文本转语音
• draw：文生图
• asr：音频转文字
• screenshot：网页截图

信息查询组

• /info weather
• /info news
• /info history
• /info drama

这里我保留的都是我确实会用到的查询：

• 天气
• 新闻
• 历史上的今天
• 短剧搜索

任务管理组

现在 shen-test 的任务系统已经收成一组新的 /task 命令：

• /task list
• /task add
• /task delete
• /task brief

这里面最实用的是两层：

1. 一次性提醒：比如明天下午三点提醒我交东西
2. 每日定时任务：比如每天早上固定发一份简报

晨间简报

这是后来加上的功能，也是我很喜欢的一项。现在它支持一个开关式的入口，默认早上 9 点发送，内容固定包括：

• 上海市嘉定区天气
• 今天的任务
• 科技新闻
• 历史上的今天

它不是什么复杂系统，但非常贴近日常使用场景。

3. 自然语言触发比斜杠命令更重要

我后来越来越在意一件事：机器人不该只会等你“正确地输入命令”，而应该尽量听懂你在说什么。

所以 shen-test 现在保留了不少自然语言触发能力，比如：

• “提醒我明天早上 9 点开会”
• “每天 8 点给我发科技新闻”
• “看看今天上海嘉定的天气”
• “帮我截一下这个网页”

当然，自然语言这一块我也踩了很多坑。最典型的问题是：任务创建太自由时，很容易误判。

所以后来我专门收紧了边界：

• 只认更明确的提醒句式
• 只识别到时间但没识别到内容时，不乱建任务
• 每日任务和普通聊天分得更开

这部分看起来不像“加新功能”，但实际上很重要，因为它决定了这玩意儿到底是好用还是烦人。

4. 画像和长期记忆

这是 shen-test 和普通聊天机器人的最大区别之一。

它现在的“记住你”，分成两层：

第一层：本地画像

本地画像负责记比较稳定的东西，比如：

• 你的偏好
• 你的默认习惯
• 你不喜欢什么风格
• 你的长期目标和一些固定事实

这层是结构化的，适合做“越来越懂你”的底子。

第二层：Mem0 记忆

如果配置了 MEM0_API_KEY，它还会把历史对话片段写进外部记忆里，并在后续聊天时检索相关内容。

这样形成的是三层记忆：

• 系统提示中的角色与规则
• 本地画像
• 外部长时记忆
• 再加上最近几轮上下文

这套东西还谈不上完美，但已经比单纯的上下文缓存强很多了。

5. 后来删掉的一些东西

shen-test 并不是一路只加不减。相反，我删掉的东西不少。

比如以前它也带过一堆娱乐功能：

• 海龟汤
• 星座
• 今日宜忌
• 小六壬
• 纯小游戏入口

后来我把这些都往 shen-play 迁了。原因很简单：shen-test 的价值不在“什么都能做”，而在“工作流足够顺”。

四、shen-play：就是为了好玩

如果说 shen-test 更像助理，那 shen-play 就是彻底往“陪你玩”这条线做的。

1. 人设切换和重新开聊

现在 shen-play 支持：

• /persona
• /new

这两个命令其实很关键。

/persona

它会从 persona/ 文件夹里读取当前可用人设，你可以直接切换。现在这边是多 persona 结构，不像 shen-test 那样固定只有一套主人设。

/new

这个命令会清空当前会话的短上下文，重新开始一段对话。

它背后对应的是一个明确的取舍：

shen-play 不做长期用户记忆。

也就是说，它保留短上下文，保证你们这一段聊天是连贯的；但它不会像 shen-test 那样不断积累对你的长期认知。这是我刻意做的设计，不是没做完。

因为娱乐机器人最怕的不是“记不住”，而是“记太多之后开始变重”。

2. 现在的娱乐能力

shen-play 当前保留的命令和玩法，基本都围绕“轻松、可玩、反馈快”来设计。

核心命令

• /menu
• /models
• /status
• /help

抽卡与卡片

• /gacha
• /gacha_card

这是现在 shen-play 里最有辨识度的一块。

后来我把抽卡从“纯文本结果”升级成了收藏卡片式输出：

• 顶部有标题
• 中间是主视觉图
• 底部保留编号和简短说明
• 不同稀有度有不同边框和配色
• 支持按编号调历史卡片

这一块前后改了很多轮，包括：

• 字体过小
• 中文乱码
• 边框太素
• 文案超出卡片范围
• SSR 不够有排场

最后才收成现在这版：更像“收藏卡”，而不是“截图里塞文字”。

小游戏与轻内容

• /blackjack
• /meme
• /haiku
• /beauty
• /roll
• /rps
• /guess
• /slots
• /joke
• /fortune
• /liuren
• /star
• /quiz
• /drama
• /praise

这部分的策略不是追求复杂，而是追求：

• 打开就能玩
• 反馈快
• 味道统一

3. 洛克王国这条线

这也是比较有个人色彩的一部分。

现在 shen-play 里保留了：

• /roco_watch
• /roco_unwatch

主要用于订阅洛克王国世界更新提醒。后面这条线其实还有很多可做的，比如：

• 活动更新摘要
• 远行商人变化提醒
• 材料和攻略查询

但我现在更倾向于慢慢加，而不是一次塞爆。

五、这套东西后来到底改了哪些关键结构

如果只看命令，会觉得像是功能列表。但真正花时间的，其实是下面这些结构性调整。

1. 配置统一到了仓库根目录

后来我把两个机器人的配置统一成根目录一个 config.yaml，而不是各自维护一份。

这样做的好处很明显：

• 共享模型配置
• 共享天气、新闻等 API Key
• 管理时更不容易漏改

只有两个 Discord Token 仍然分开：

• SHEN_TEST_TOKEN
• SHEN_PLAY_TOKEN

2. 部署脚本固化了

我后来专门把：

• 推 GitHub
• 上传服务器
• 远端编译
• 重启 systemd 服务

这套流程固化成了脚本。原因很现实：如果每次改完都靠手敲命令，迟早要出错。

现在整个项目在服务器上是两个常驻服务：

• shen-test-bot.service
• shen-play-bot.service

这让它们真正从“脚本”变成了“服务”。

3. 文档开始变得重要

项目做到后面，我越来越觉得 README 不是装饰，而是产品的一部分。

所以后面我做了一件很重要的事：

• 每次命令、功能、自然语言边界发生变化，都同步写回 README

这件事很朴素，但特别值。因为只要功能足够多，不及时整理文档，最后连自己都会忘掉“现在到底能干嘛”。

六、技术上到底用了什么

这套项目的基础很直接：

• Python
• discord.py
• JSON 持久化本地数据
• 外部模型 API
• 少量定时循环和 systemd 常驻

1. 模型与服务

这套机器人前后接过不少模型源，当前比较稳定的是：

• DeepSeek
• SiliconFlow
• OpenRouter（作为补充）

2. 外部能力

涉及到的外部能力包括：

• 天气 API
• 新闻 API
• 历史上的今天 API
• Mem0 长期记忆
• Tavily 搜索
• Edge TTS / 语音能力

3. 代码层面的几个重点

真正让我花时间的，不是把某个接口接上，而是这些细节：

• 自然语言和 slash 命令怎么共存
• 任务系统怎么避免误触发
• 画像和长期记忆怎么配合
• shen-test 和 shen-play 怎么划清边界
• 抽卡卡片怎么做得既稳定又好看

这些事情每一项都不算“炫技”，但它们决定了项目到底能不能长期用下去。

七、这套项目现在的真实状态

如果只用一句话概括当前版本，我会这么说：

这已经不是一个“功能堆砌的 Discord 机器人”，而是一套有明确分工的小型双机器人系统。

它现在的真实状态是：

• shen-test：工作和生活管理主线，偏长期使用
• shen-play：娱乐和轻互动主线，偏即时体验
• 两边共享一部分底层配置，但人格和目标不同
• 服务器上作为常驻服务运行
• GitHub 仓库和本地工作目录会持续同步更新

当然，它仍然远没有到“完美”的程度。还有很多细节可以继续做，比如：

• 更完整的任务闭环
• 更自然的记忆纠错
• 更精细的抽卡系统与卡池设计
• 更好看的博客配图和管理后台

但至少现在，它已经不再是那种“做着玩玩，过几天就废弃”的东西了。

八、总结

这套 Discord 机器人对我来说，最有意思的地方不只是写出了一个能聊天的 bot，而是它完整经历了一次很真实的产品演化：

• 从想到什么做什么
• 到功能越来越杂
• 再到重新拆分边界
• 最后收成两条真正有各自定位的线

如果说前期的关键词是“能做出来”，那现在的关键词其实是：

• 收敛
• 分工
• 真实可用
• 能长期维护

这也是我现在越来越看重的一件事：不是 AI 帮你一次性把东西写出来，而是它能不能陪你把一个东西慢慢磨到真的顺手。

项目仓库：

https://github.com/yys806/discord-bot