推荐的维度错了
现有音乐推荐的逻辑几乎都是同一套：分析历史播放行为 → 找相似偏好 → 推歌。这套逻辑很成熟，但它有一个根本性盲点——
它只知道你过去喜欢什么，不知道你现在是什么状态。同一首歌，在下雨的周五下午你需要它，在晴天的周一早上你可能并不需要。情绪是实时的，而历史偏好是滞后的。
市面上也有「心情推荐」功能，但大多只是让你选一个标签（开心/悲伤/工作），然后给你一个对应歌单。
这太粗糙了。你的「当下」不是一个标签，而是一个由多个维度拼成的状态：外面在下雨、你今天有个重要会议、你刚发了一句「好累」——这三层加在一起，才是真正的此刻。
推荐音乐的正确维度是「上下文感知」，而不是「偏好匹配」。上下文 = 天气 + 日程 + 情绪表达。
把三层「当下」注入 AI 上下文
我的方案是：在用户发送一条消息之前，系统已经知道这三件事——
这三层信息被整合进 System Prompt，AI 在推荐时不只是知道「用户喜欢什么类型的歌」，而是知道「用户今天处于什么状态、需要什么感觉的音乐」。
全栈独立开发，完整交互闭环
AI 的推荐通过 WebSocket 流式推送到前端，实现打字机效果。同时并发接入讯飞/智谱 TTS，将文字回复转为 DJ 播报音频——用户听到的不只是歌单，还有一段「为什么推这首歌」的语音解释。
网易云 API 提供歌曲搜索和在线播放，整个链路从「说一句话」到「歌曲播放」完全自动。
两个真正难的问题
① AI 主服务不稳定时怎么办
Claude API 有时响应慢或不可用。我设计了一个双模型降级链路：系统启动时读取环境变量判断主服务是否可用，不可用时自动切换到智谱 GLM，整个切换过程对用户无感。
这不是「做了个备选方案」——而是从一开始就把可用性当成一等需求来设计架构。
② 如何让 AI 真的理解「当下」
只把天气/日程塞进 Prompt 是不够的，AI 容易给出模板化回答。我的解法是在 System Prompt 中明确描述「当下上下文」的优先级，要求 AI 在推荐理由中显式引用这些信息——让用户感受到这个推荐是专门为此刻做的，而不是随机给的。
独立全栈部署，完整运行
这个项目验证了「上下文感知推荐」的可行性。它不是一个成熟的商业产品，但它完整地实现了从「当下状态感知」到「个性化音乐推荐」到「在线播放」的全链路，并且稳定运行中。