Spotify Engineering

RSS: https://engineering.atspotify.com/feed
Spotify 工程博客，分享 Spotify 在 AI、移动端、Web、数据科学、开源等领域的技术实践。

Spotify 用外部索引让 Parquet 数据湖支持毫秒级点查询

Spotify 推出 Random Access Parquet（RAP），通过外部索引将 key 直接映射到 Parquet 文件的行位置，让数据湖里的 Parquet 文件可以直接支撑毫秒级点查询，无需额外复制到 Bigtable 等 KV 存储。核心思路是用预计算索引替代 Parquet 内置的 footer+PageIndex+Bloom filter 链式读取，配合 ZSTD frame reset、列交错、covering index 等优化，单次点查询可降至一次几 KB 的范围读甚至零存储读取。同一份文件同时服务批分析和在线 AI agent 检索，改变了数据湖只能做离线分析的经济学。
评论点赞收藏1 天前

LLM 能在 A/B 测试中替代人类吗？

Spotify Engineering 发文讨论 LLM 能否替代人类参与 A/B 测试，结论是只能基于假设使用，而非设计上可行。文章指出 LLM 预测可以替代人类结果，但存在局限性，需要谨慎使用。
评论点赞收藏2 天前

为在线点查询建立数据湖索引

Spotify Engineering 提出为在线点查询构建数据湖索引方案，解决大规模数据低延迟访问问题。该方案针对流媒体服务高频实时读取场景设计，通过分层索引结构优化查询性能，同时兼顾存储成本与扩展性。
评论点赞收藏19 天前

编码不再是瓶颈：Spotify如何将开发者体验扩展至团队与AI Agent

核心看点：Spotify首席架构师在Code with Claude活动上提出，AI辅助编码普及后，编码本身已非瓶颈，团队效能和Agent协作体验才是新重心。文章为Spotify工程博客的活动报道摘要，介绍了其内部平台如何赋能团队与AI Agent更高效协作。但原文内容极简短，仅有一段概要式描述，缺乏具体技术方案、数据支撑或一手实践经验，信息密度极低，属于企业博客的通告性质内容，没有个人观点或讨论入口。
评论点赞收藏73 天前

Spotify 工程博客：2025 Wrapped Archive 背后的技术内幕

Spotify 工程团队详细拆解 2025 Wrapped 中 "Archive" 功能的完整技术实现：从数亿用户全年听歌数据中，用 7 种启发式规则（最大听歌日、最大发现日、最怀旧日、最反常日等）自动识别最多 5 个"值得纪念的日子"，再通过 LLM 为每个日子生成个性化叙事报告。核心工程细节包括：双层提示词设计平衡创意与安全；模型蒸馏+DPO 将 14 亿份报告生成成本压到可行水平；列式键值数据库用日期作为列限定符实现无锁并发写入；全球同步上线前做预扩缩容+合成压测避免冷启动毛刺；LLM-as-judge 自动评估流水线采样 16.5 万份报告，配合 SQL+正则缺陷回溯批量修复。文中还披露了一个真实踩坑案例：时区 bug 导致部分"最大发现日"报告数据错误，团队通过结构化评估定位根源并批量重跑。对于关心大规模 AI 工程化、高吞吐在线系统、推荐内容叙事化的读者，是一份有具体数据、有架构图、有工程权衡的一手经验分享。
评论点赞收藏112 天前

后台编码代理：通过强反馈循环实现可预测结果

Spotify 工程团队公开其后台编码代理（代号 Honk）的核心设计——强验证循环如何让代理在零人工监督下产出可靠代码。他们定义了三种失败模式：代理无法生成 PR、PR 不通过 CI、以及最危险的——CI 通过但功能错误。应对方案是双层验证：底层是确定性验证器，自动识别代码库中的 Maven 等构建系统，执行格式检查、编译和测试，并将复杂的构建输出精简为简短的成功/失败信号；上层是 LLM 法官，审查代理的 diff 是否超出原始指令范围。内部数据显示约 25% 的代理 session 被法官否决，其中一半能自行纠正方向。设计哲学上刻意限制代理能力——只能编辑代码和执行验证器，不能接触 Slack、git push 等外部系统——这种受限反而提升了可预测性和安全性。适合关注 AI 编码代理、LLM 落地工程化的技术读者。
评论点赞收藏165 天前

Spotify 如何发布 App，第一部分

Spotify 工程团队详细披露每周服务6.75亿用户的移动App发版流程。Release Manager（发布经理）负责协调从代码合并到全量上线的整条流水线：第一周主干开发+内部Alpha测试，第二周分支冻结+仅修复关键Bug，随后分两阶段（1%→100%）向商店提审和灰度。以有声书功能（Audiobooks）为例展示了如何控制大功能单独发版、利用Feature Flag降低风险、用Dashboard监控Crash率和阻塞Bug。整体节奏是每周一个版本，95%以上的发布都顺利全量推送。本文适合对规模化CI/CD、移动端发布管理感兴趣的工程师阅读。
评论点赞收藏187 天前

Spotify随机播放：用算法让"随机"听起来更人性化

Spotify用户常抱怨随机播放"不够随机"，总重复听到相同歌曲。工程团队揭秘：问题出在统计随机性不等于人感知的随机——就像连续抛五次硬币都是正面，概率上合理，但感觉不对。他们提出的解决方案"Fewer Repeats"不是改变随机算法，而是生成多个随机序列，根据歌曲近期播放时间评分，选出最"新鲜"的版本。现已成为Premium默认设置，同时保留纯随机模式（Mersenne Twister算法）供传统用户选择。
评论点赞收藏208 天前

Spotify 后台编码代理（Honk）的演进之路（第一部分）

Spotify 工程团队详细分享了内部代号 Honk 的后台编码代理系统如何将 AI 引入大规模代码库维护。自 2024 年中以来，Spotify 约半数 PR 已由自动化系统生成，而新的 AI 编码代理更在半年内生成了超过 1500 个已合并到生产环境的 PR。这套系统基于已有的 Fleet Management 框架，用 AI 代理替代了传统手工编写的源码转换脚本——工程师只需用自然语言描述变更意图，代理即可自动完成代码修改、生成 PR、提交审查。相比手写代码，某些迁移任务节省了 60-90% 的时间。文章给出了具体架构细节（自建 CLI 支持无缝切换多种 LLM 和代理、MCP 协议集成、LLM 作为评审者评估 diff），列举了真实落地场景（Java Records 迁移、Scio 跨版本升级、Backstage UI 组件迁移），并坦诚讨论了性能不可预测、输出质量控制、安全沙箱和规模化运行成本等尚未完全解决的新挑战。这是一篇有真实数据、一手架构经验的技术分享，对于关注 AI 辅助编程和大型工程提效的读者有直接参考价值。
评论点赞收藏273 天前

Spotify自动化内容营销：规模化获取用户的工程实践

Spotify工程团队详细拆解了规模化自动化内容营销系统的完整技术架构。核心看点：他们如何用After Effects + nexrender实现广告创意批量自动生成，以及用XGBoost机器学习模型对内容进行排序。A/B测试结果显示，ML模型相比启发式方法在测试区域获客成本分别降低4%和14%，点击率提升11%–12%，并额外带来9%月活用户增长。文章坦率分享了应对Facebook API中断、Apple IDFA政策变更、第三方归因平台迁移（Adjust→Branch）等真实工程挑战的解决思路和架构设计取舍，对广告技术、增长工程和ML系统从业者有直接参考价值。
评论点赞收藏314 天前

创意用户名引发的 Spotify 账户劫持漏洞

一篇罕见的、有血有肉的工程事故复盘：黑客利用 Unicode 用户名伪装（如用 ᴮᴵᴳᴮᴵᴿᴰ 冒充 bigbird）劫持 Spotify 账户，漏洞根源竟是 Python 从 2.4 升级到 2.5 时 unicodedata 模块行为改变，导致 Twisted 框架的 nodeprep.prepare 函数失去幂等性，最终让密码重置请求指向错误账户。作者以第一人称讲述复活节期间紧急封堵漏洞的全过程：从论坛用户发帖爆料、工程师紧急排查、临时限制注册规则，到最终定位 Unicode 3.2 字符集边界问题并修复。文章技术细节清晰（附 Python 代码、规范引用、复现步骤），叙事有悬疑和反转（"最终 twist"），结尾给出四点工程教训——验证用户输入、小心 Unicode 陷阱、善待白帽用户、升级并非总是安全。对后端工程师、安全从业者、Unicode 处理相关开发者有直接参考价值，且行文有人味、有现场感，不是通稿式技术文。
评论点赞收藏475 天前

我们如何生成了数百万条内容标注

核心看点：Spotify 工程团队公开了构建百万级内容标注平台的技术架构与流程经验，标注量提升 10 倍、标注效率提升 3 倍。背景是 ML 和 GenAI 模型训练对高质量标注数据的巨大需求，Spotify 需要对数亿量级的曲目和播客节目进行标注。文章详细拆解了三大支柱：扩展人类专家队伍（核心标注员+质量分析师+项目经理）、搭建灵活标注工具能力（支持分类/音视频片段标注/自然语言处理等多种任务类型）、建立可集成 ML 工作流的基础设施。还介绍了并行运行数十个标注项目、专家一致性指标、自动升级机制等实操细节。对从事数据标注平台建设或 ML 数据管线优化的团队有参考价值，但属于机构技术总结，缺乏个人视角和讨论入口。
评论点赞收藏663 天前

在 Spotify for Artists 中应用外观模式

Spotify 工程团队在统一多子系统用户体验时，利用外观模式（Facade Pattern）构建了 S4X-Masthead 组件库，解决了 Spotify for Artists 不同业务线之间顶部导航栏（Masthead）的实现碎片化问题。文章详细说明了如何通过 CMS 动态加载内容、统一主数据源，将 MastheadHeader、MastheadFooter 和 MastheadProvider 封装为单一集成入口，避免各客户端重复实现与版本漂移。工程博客，有具体架构图和代码设计思路，对从事前端架构、微前端或多团队协作系统的开发者有参考价值。
评论点赞收藏839 天前

Spotify实验之道：最大化创新影响力的三个经验

Spotify工程团队分享了在成熟产品环境下通过实验驱动创新的三个实战经验。一、从需要做出的决策出发设计实验，而非盲目追求完美信息；二、针对日本等特定市场细分用户群体做本地化实验，缩小受众范围反而更容易验证假设并取得顶部指标影响；三、将新功能拆解为最关键的组件分别测试，而非一次性测试完整体验，避免因漏洞或可用性问题导致误判。文章结合日本市场和东南亚营销活动的真实案例，解释了为什么在成熟产品中"做减法"比"做加法"更有效，以及如何通过聚焦同质化用户群体来提高实验的统计显著性和实际影响力。
评论点赞收藏877 天前

我们用黄金路径解决软件生态碎片化问题

Spotify 平台团队产品经理一手复盘内部「黄金路径」实践：面对多家初创式自治团队导致的工具碎片化、靠同事口耳相传的「谣言驱动开发」，团队用 Hack Week 产物——一份后端工程教程——逐步演变为覆盖客户端、数据工程、ML 等领域的核心文档体系。文章详细拆解了 8 个成功要素：清晰受众定位、单一核心目的、极致步骤化、忠于实际路径、按学科分册、教育导向、特殊地位保障、以及新员工强制走读带来的海量反馈闭环。作者不回避教训，坦承从专职技术写手转向集中化模式后产生了新的协调问题，并正在探索 Golden State 自动合规检测和面向跨职能团队的全产品黄金路径蓝图。这是一篇有具体方法、有真实踩坑、有可复用工程管理智慧的深度分享，不是空洞趋势文，对技术管理者和平台团队尤其有参考价值。
评论点赞收藏929 天前

Spotify 如何用自动化内容广告系统实现规模化用户增长

Spotify 工程团队详解内部搭建的自动化内容广告生成与排序系统，核心组合是 After Effects 模板化素材+nexrender 开源批渲染框架，配合 XGBoost ML 模型对全球艺人进行智能排序，决定每支广告投放哪些艺人。A/B 测试中 ML 模型相比启发式方法降低 4%–14% 注册成本、提升 11%–12% 点击率，带来 9% 月活用户增量。文章坦诚分享五大工程挑战：素材渲染异步编排、依赖 Facebook API 的容灾方案、iOS 14.5 IDFA 隐私政策影响评估、归因平台从 Adjust 迁移到 Branch、ML 中艺人多样性建模困境。技术细节扎实，有具体指标和架构图，适合增长工程师、广告技术从业者参考，但机构号发文缺乏个人叙事和讨论入口，整体偏工程复盘而非观点输出。
评论点赞收藏952 天前

登录芦苇

登录后关注作者、收藏内容和参与讨论。

热门话题

人工智能12,865 人关注AI 会怎样改变日常工作？产品思考8,243 人关注怎样判断一个产品值得长期做？独立开发5,917 人关注一个人如何持续完成作品？
关于芦苇 · 联系我们 · 下载 App · © 2026 芦苇