技能介绍

要解决的问题

很多团队把“Squad 自治”误读成“少管”，结果对齐不足就授权，方向漂移、技术债积累；迁移 Google Cloud Platform（GCP）时，既想降风险又想快速优化，反而把重写和迁移混在一起；优化推荐系统时，“惊喜感”“完成率”“版权风险”很难放到同一张表里评估。声田音乐工程师助手不提供空泛原则，而是把声田音乐工程师岗位助手（@org-02qudk26/spotify-engineer）中的工程上下文和检查项拆成可执行流程，帮助产品负责人、后端/平台工程师、数据与推荐工程师在架构评审、迁移计划、实验决策中统一语言。

技能如何工作

核心能力围绕五个工程要点展开：

对齐与授权：Daniel Ek 的领导力演进（直接控制 → 分享上下文 → 主编式管理）被整理成 Context Over Control 的决策链。团队先确认“为什么做”，再定义“哪些不可妥协”，最后把执行细节交给 Squad；这一步对应 SKILL.md 中的 §2.2。
BaRT 推荐系统：BaRT: Bandits for Recommendations as Treatments 把每条推荐当作多臂老虎机的一次“处理”，同时约束探索（新内容）与利用（已知偏好）。工程落地会拆成协同过滤、自然语言处理、音频分析三条信号管道，并对显式/隐式反馈设置权重（见 §4）。
Audio-first 架构：播放链路优先保证低延迟和连续体验，Ogg Vorbis 与 FLAC 的码率切换、特征抽取（danceability、energy、tempo）服务于个性化，而不是孤立的音质参数（§5）。
GCP-native 迁移：采用 lift-and-shift first、rewrite strategically 的顺序，避免在迁移窗口内做高风险重构；配合可视化仪表盘、迁移指南而非临时团队，降低执行摩擦（§3.1）。
发布与风险控制：Feature Launch Checklist 覆盖灰度发布、回滚方案、护栏指标和 on-call runbook；风险表把 license、engagement、scale、privacy、competitive 五类风险映射到缓解动作（§9）。

适用边界与注意点

这套模型适合需要明确责任边界、快速实验且能接受结构化检查的中大型团队。它不意味着可以照搬 Spotify 的组织图：资料本身提醒，Squad/Tribe/Chapter/Guild 是理想化描述，实际应关注原则而非结构。推荐实验不能跳过基线指标；迁移 GCP 时不要跳过数据映射和依赖梳理。内容用于工程讨论和培训，不替代 Spotify 官方文档、内部数据或合规审查。