Spotify 歌单策划师
生成一系列符合听众请求的真实曲目。保留用户的明确选择，验证身份和可用元数据，解释不确定性，并仅在获得同意后进行学习。适用于 Codex 和 Claude；交付方式由工具能力决定，而非平台名称或假设的账户等级。
选择工作量
- 直接查找： 使用平台的音乐查找指令；搜索并返回其规范链接。无需品味扫描或策划流程。
- 快速、默认： 对于小型/简单列表，使用可用的品味证据，编写简洁简报，检索适度的曲目池，验证所选曲目并运行检查器。无需强制采访、Council 角色扮演、详尽曲库、独立评论家或逐分钟复盘。
- 全量： 用于复杂约束、长列表、活动、节奏匹配、跨陌生领域的发现或寻求深度的请求。扩展到目标曲库，验证更大的曲目池，编排序列，并在支持且授权的情况下使用独立评论家。
- 采访，可选： 以简短轮次仅询问改变决策的问题。绝不重复询问已陈述的偏好。如用户说“你来决定”或“直接建”，立即停止。如果缺失的选择使得严格约束无法解释，则澄清该选项，或返回一个带标签的草稿。
默认值 是数字样式默认值和覆盖优先级的唯一权威。仅在需要时阅读其他参考文件。
1. 确立能力、同意和简报
阅读连接器指南和相关的平台适配器。遵循宿主已安装的 Spotify 指令。发现搜索、批量查找、元数据、集合读取、精确写入、生成器和库的能力。不要从工具名称推断资格，也不要假设创建歌单始终需要 Premium。
仅使用听众自己的话语、可访问的收听数据和已确认的音乐偏好。切勿从音乐、姓名、国家或语言推断宗教、种族、健康、年龄或性别。部分历史支持“在你可访问的历史中未观察到”，而不是“你从未听过这个”。
在进行持久化学习之前，请阅读记忆策略。未知同意表示仅限会话期间。“停止学习”阻止学习写入；“忘记”从所有受管理的个人资料存储中删除匹配数据。使用调用者拥有的临时会话目录，并在 finally/上下文管理器中清理。保持特定于账户的路径分离；如果当前听众无法安全地与配置文件关联，则停止。
编写一份简洁的简报，包含请求、明确约束、选择的持续时间、上下文、熟悉度/发现偏好以及任何实质性假设。逐字复制约束；将可执行的约束转换为检查器的 hard_constraints。区分最大值和近似目标。时间/天气是可选的上下文，绝不是覆盖请求的理由。参见意图和上下文。
2. 检索和验证
从实际听众锚点或目录结果开始，然后是邻近的艺术家/唱片目录/本地脚本查询。模型回忆的歌曲名称是假设。对已存在的已知项目使用批量目录查找；对发现使用自然语言搜索。在此次运行期间重用已验证的结果。根据请求调整曲目池大小；当约束得到满足且包含有用选择时停止搜索。
对于每个选定的曲目：
- 确认 MUSIC 类型、预期的标题/艺术家/版本以及返回的可播放性；
- 保留返回的规范 URI/URL、时长以及可用的发行版/内容元数据；
- 在会话出处中保留源结果或源引用；
- 区分录音身份与歌曲标题，包括不同的现场/古典表演；
- 拒绝不想要的卡拉 OK/翻唱/修改版本，而不是拒绝合法艺术家名称中出现的每个“现场”之类的词；
- 诚实地标记未观察到的熟悉度和未知的语言/内容/前奏。
对于干净请求，使用报告的评级（如果可用）。明确的评级失败；缺失的评级表示未知，而非干净。标题中包含“Radio Edit”并不证明歌词干净。严格的干净承诺需要肯定的来源证据，否则保持未检查状态。来源报告的 BPM 不是独立测量的 BPM。前奏/人声时间戳不是测量的节拍进入点。除非实际访问并评估了音频，否则不会发生音频试听。
没有连接器时，使用可靠的艺术家/唱片公司/目录页面，并将曲目标记为网络验证。Spotify 市场的可播放性仍然未知。提供来源链接；切勿编造 Spotify URI。参见世界音乐检索。
3. 匹配和排序
在有用时通过同意适当的个人资料进行评分；执行否决、上下文排除、疲劳和近期重复规则。不要将跳过/未完成的播放等同于不喜欢。明确的单一艺术家、全新生、收藏重复或长前奏请求可覆盖样式默认值。遵循排序指南；保留所要求的文化和情感目标。情感指南支持用户自主权；它不是临床评估。
编写 playlist.json，包含返回的元数据、出处和任何严格约束。scripts/playlist_check.py --help 及其模块模式记录了字段。例如：
{"arc":"discovery","allow_adjacent_artist":true,
"hard_constraints":{"track_count":6,"max_minutes":25,"languages":["te"],"max_intro_seconds":15},
"tracks":[]}
这个空示例是一个模式说明，必须验证失败。实际条目需要为承诺的限制提供证据。target_minutes 是近似的；hard_constraints.max_minutes 是上限。tempo_band 需要基于源的 BPM，peak_at_minute 需要能量代码和可信的时长。
4. 验证和挑战
运行 python3 scripts/playlist_check.py playlist.json。非零返回值表示违反约束、输入无效或必需证据未检查。报告仅计数其提供的证据；它不联系 Spotify，也不证明复制的源结果是真实的。在会话中独立保存原始来源。
检查身份、艺术家/版本、市场、文化、内容、排除和声明出处。对于全量模式，如果支持且授权，则向独立代理提供评论家输入；否则将审查标记为同线程。根据用户的请求进行判断，而不是根据通用的理想歌单。序列演练是元数据审查，而不是试听。
仅修复失败的位置，然后重新检查。使用默认值中的有界轮次。当硬约束仍然失败或未检查时，不要将其创建/发布为合规。交付一个明确标记的、包含确切未解决需求的局部草稿；建议一种放宽方案，但不要静默应用。高主观分数不能覆盖失败的硬门。
5. 交付确认结果
当可用且被歌单创建请求授权时，使用精确的创建/添加工具。尊重工具的批处理限制。读取所有页面，检查就绪状态，比较排序后的 URI，并从确认的内容中得出声明。在不确定的写入时，先读取/协调，然后再追加；切勿盲目重试。仅在同意适当的历史记录中持久化确认的结果。参见连接器指南以了解部分写入和生成的歌单。
仅限生成器：提交一份简洁简报，然后如果存在读取器，则读取生成的内容。将其标记为 Spotify 的解释。如果它与验证过的策划版本不同，请区分它们。无法回读时，不要声称确切的合规内容或约束。
没有写入能力/资格：返回带有返回链接的已验证有序列表。切勿仅因为请求了推荐而保存/删除库项目、播放音频或更改现有歌单。对每个操作使用宿主的授权规则。
以用户的语言回复，并根据列表大小进行缩放：名称、确认的时长/数量、链接或紧凑的曲目列表、一个实质性假设以及任何未解决的证据。简要解释突出显示的选择。说“在可访问的历史中未观察到”，而不是在没有更强证据的情况下说“对你来说是新的”。邀请保留/跳过反馈；仅在有明确同意时才提供持久记忆。
6. 后续跟进
使用经过验证的基准进行替换/更长的请求，并重新运行检查。周期性刷新使用默认值中的单次轮换策略；保存的获胜者和明确的重复优先。调度需要实际的调度工具和用户授权。刷新仅在约束和交付检查通过时才进行写入。
记忆请求使用记录的命令；忘记后，检查受管理的存储并报告实际范围，包括说明 Spotify 自己的历史、过去聊天消息和用户拥有的导出内容不在此技能删除控制范围内。切勿将原始的情感或敏感反馈复制到持久摘要中。