从基于 Claude 到自研 Honk：全球领先的音频流媒体平台 Spotify 如何让 AI Coding 进入组织级协作

公众号名称：AI 启蒙小伙伴

作者名称：邵猛

发布时间：2026-05-21 07:45

写在前面

Spotify 是全球最大的音乐流媒体平台，最近它们的首席架构师 & 工程 VP Niklas Gustavsson 在 Anthropic Code w/ Claude 大会上发表了一篇非常有技术价值的演讲。从企业级 AI Coding 出发，Spotify 的实践绝对值得深入学习和参考。

Coding is no longer the constraint: Scaling devex to teams and agents at Spotify

https://www.youtube.com/watch?v=zFslvuvYifQ\[1\]

核心一句话：当 AI 让写代码速度明显提高后，软件组织的主要限制会转移到代码库治理、验证体系、迁移能力、评审分配、产品决策和组织协作上。

换句话说，AI 没有让工程管理变得不重要，反而让基础工程能力更重要。

视频讲了什么

Niklas Gustavsson 先给出 Spotify 的工程规模：接近 3000 名工程师，每天约 4500 次生产部署，后端有约 4000 万行代码的大型 monorepo，同时还有数千个小型 polyrepo。

AI 编程工具在 Spotify 的采用速度非常快。超过 96% 的工程师每周使用 AI 编程工具，94% 的工程师认为 AI 工具提升了自己的生产力，PR 频率增长约 60**%**。

但演讲重点不在于这些数字本身，更在于数字背后的变化：大量 PR 开始由“开发者 + AI agent”共同产生，代码产出速度上升后，旧的软件交付瓶颈开始松动，新的瓶颈浮现出来。

Spotify 的关键做法

第一，Spotify 早在 AI 大规模使用前，就已经在做大规模代码维护自动化。 原因是他们发现生产代码库增长速度曾经是工程师人数增长速度的 7 倍，这会让工程师越来越多地被迁移、升级、弃用 API、安全修复等维护任务占用。

他们为此做了 Fleetshift，用来跨大量组件批量执行迁移。到目前为止，已经合并了约 250 万个自动维护变更，其中大部分可以自动创建 PR、自动验证、自动合并。

第二，传统脚本适合简单变更，比如配置修改、依赖升级。 但一旦涉及 API 替换、代码调用方式变化，就会遇到很多边界情况。演讲中引用了 Hyrum’s Law：只要 API 有足够多用户，所有可观察行为都可能被依赖。也就是说，大规模代码迁移不是写一个规则脚本就能解决的。

这就是 Honk 出现的背景。Honk 是 Spotify 的后台编码 agent，基于 Claude 和 Agent SDK，运行在 Spotify 自己的执行环境里，可以访问受信任工具，并能调用 CI、构建、多系统验证等能力。它被接入 Fleetshift，用来在大量仓库中真正完成代码修改。

第三，Honk 不只是批量迁移工具，也逐渐变成开发者可交互使用的 agent。 工程师可以在 Slack 里提到 Honk，让它去做事并返回 PR。Spotify 还推出了 Honk V2，把它接入内部的 agent 编排工具 Chirp，支持多个 agent session、团队共享 session，以及类似多人协作的工作方式。

最重要的工程观点

视频里最有价值的一点是：Spotify 认为“标准化代码库”会同时提升人和 agent 的效率。

他们长期坚持减少不必要的技术差异。典型后端服务使用相似技术栈、相似设计模式、相似项目结构。对人来说，这减少了重复选择，降低协作成本；对 agent 来说，这意味着 Claude 可以从大量一致代码中学习本地模式，生成更符合项目习惯的代码。

演讲者明确说，他们看到 Claude 在结构一致的代码库里表现更好，在碎片化更严重的代码库里表现更差。

这点很关键。很多团队讨论 AI 编程时只关心模型能力，但 Spotify 的经验说明，模型能力只是其中一部分。代码库是否一致、是否有明确规范、是否有测试、是否有 lint、是否有可调用的工具，都会直接影响 agent 的表现。

Backstage 的角色

Backstage 在这里不是普通门户，是 Spotify 工程系统的基础入口。过去开发者要去很多不同系统查看部署、CI、A/B 测试、组件归属等信息；Backstage 把这些集中起来，并从“软件目录”开始，解决“这个组件归谁管”这样的问题。

现在，这些能力也开放给 agent。Claude 可以通过 MCP 或命令行工具查询组件负责人、查看组件状态，必要时还可以去 Slack 询问相关团队。

这说明一个趋势：面向人的开发者平台，如果结构化得足够好，也可以变成面向 agent 的工作平台。

对企业和开发者们的启发

这段视频的重点不是“每家公司都应该复制 Honk”，因为每个公司的具体情况并不相同，它传达了几个更通用的判断：

AI 编程规模化以后，工程体系会被放大检验。测试、CI、lint、代码目录、所有权、技术规范，这些不是低效流程，而是 agent 能否可靠工作的条件。
大规模代码维护是 agent 很适合的场景。版本升级、API 迁移、安全修复这类任务有明确目标、可验证结果、范围可批量扩展，比开放式产品开发更容易先产生稳定价值。
人类判断不会消失，但位置会变化。PR 数量增长后，不可能所有变更都用同样方式人工审查。Spotify 已经在让部分低风险 PR 自动合并，同时把人工注意力放到更重要的地方。
写代码不再总是最慢的环节。Spotify 提到，现在任何人可以在真实生产代码库里用 Claude 快速做原型，几分钟生成可安装、可测试的 app。这会让产品验证、优先级判断、是否值得发布，变成更突出的限制。

我的判断

这个视频重要，是因为它把“AI 编程”从个人效率工具，推进到了组织级软件生产系统。

个人层面，AI 可以让工程师更快写代码；组织层面，真正的难题是：如何让成百上千个工程师、数千个服务、海量 PR、自动迁移工具、代码目录、验证系统和 agent 协同工作。

Spotify 的答案很清楚：不放松工程约束，要把约束做得更清楚、更机器可读、更可验证。这样 agent 才能更独立地完成任务，人也才能把精力转向更高价值的判断。