Jazz Agent

一个单用户工具：读取纽约爵士俱乐部的演出排期，理清谁在演出，并为每个俱乐部按周生成一个 Spotify 播放列表，音乐无需人工请求便会送达。它会永久保存它曾经浮现出的每一条记录，并把这个记录日志通过 MCP 交到 Claude，以便你能够向 Claude 提问、以及边听边记录你喜欢的作品。

两个半分结构，刻意分开设计：

• 日常批量流水线：通过 cron 定时抓取、匹配并对齐播放列表。

• 始终运行的 MCP 服务器：回答有关日志的问题并记录反馈。

为什么这样的方式构建

三个发现主导了这一设计，而三者全都与直接做法相反：

1. Spotify 从根本上剔除了你原本要用的端点。 2024 年 11 月后的 API 改动对所有新注册的应用移除了 related-artists、recommendations、audio-features 与 audio-analysis。现在既没有声学数据，也没有艺人相似度数据。艺人之间的关联来自 MusicBrainz，乃至每个爵士俱乐部自身的演出信息；所谓"风格"，不外乎的是类型标签和你自己记录的爱好。

2. CSS 选择器无法面对 6 个不再维护的网站。 ... 提取不再依赖页面结构，而是直接对页面文本交给 LLM 进行；因此新增一个俱乐部，只需在数据表里添加一行，某个演出场地改版也不会破坏任何东西。

3. 以周为单位，而不是以夜为单位。 每个俱乐部在每一周的预订周期（周二到周一）里只有一个播放列表，因此住场演出横跨数晚、同一组艺人附上两份歌单、以及歌单在演唱一段时间后过期之类的整类问题都消失了。日常运行得以变成一个幂等的收敛循环，不再是一次性的事件。

Related MCP server: Spotify MCP Server

文档

PRD 刻意保持未编辑，作为最初的设计意图记录。当架构与其偏离时，对应 ADR 会明确说明，并写明它所取代的 PRD 的哪个部分。

状态

所有 v1 里程碑内的 issue 都已实现并测试。真正投入生产之前还剩两件事，都需要人来完成：申请一组真实的 Google OAuth 客户端和一个真实的 Spotify 开发者应用（见 docs/RUNBOOK.md 第 4–5 节），以及部署到真实的 VPS。构建过程以 v1 里程碑下的 issue 跟踪，每个 issue 都有明确的验收标准和显式的 Blocked by 链接 —— 需要了解完成的内容和背后的理由，可以查看已关闭的 issues。

技术栈

Python 3.12 + uv，Postgres 17（tsvector、pg_trgm、pgvector），httpx 并可选地针对每个俱乐部使用 Playwright，提取与仲裁使用 Anthropic Claude Haiku，FastMCP 搭配 Google 委派的 OAuth，部署基于小规格 Linux VPS 的 Docker Compose。

许可证

MIT.