Spotify AI编程实践：从代码自动化到工程文化转型
去年 9 月，当 Spotify 工程副总裁 Niklas Gustavsson 对 Claude Code 创始人 Boris Cherny 说出“到了年底，可能已经没人再用 IDE 了”时，Boris 的第一反应是“这绝对不可能”。然而仅仅两个月后，Boris 发现自己真的不再打开传统 IDE，整个工作方式彻底改变。这种变化，是他从事编程工作近 30 年来从未见过的。
如今在 Spotify，约 73% 的 PR 已经可以直接由 AI 生成，AI 工具推动 PR 提交频率提高了 75% 以上。这家拥有 2900 名工程师的流媒体巨头，每天进行约 4500 次生产环境部署，工程师甚至可以在通勤路上通过手机提交代码。但 Spotify 的实践并不是简单地给工程师购买一套 Claude Code 订阅，其背后是持续多年的代码自动化基础设施、代码库标准化、自动化测试、持续集成和验证闭环建设。
1. 从“代码维护危机”到 AI 自动化：Spotify 的七年演进路径
1.1 代码增长速度是工程师人数的 7 倍，被迫寻找自动化解法
大约五六年前，Spotify 发现了一个严峻问题：公司代码库的增长速度远远超过工程师人数的增长速度，大约快了 7 倍。这意味着随着时间推移，需要维护的代码越来越多，而 Spotify 作为一家不缺产品创意的公司，一直有大量想要交付给用户的功能。如果团队长期被维护工作拖住，显然不是一个理想状态。
于是他们开始尝试自动化这些维护工作。很多工作非常枯燥，比如迁移到最新的 Java 版本、升级依赖库，或者在数千个代码仓库中把某个 API 迁移到另一个 API。他们构建了一套称为“代码舰队管理（fleet management）”的基础设施。在此之前，每次迁移都需要把迁移说明发给所有团队，让每个团队手动完成自己负责组件的迁移，整个过程可能持续好几个月。
1.2 从确定性脚本到 AI 驱动的智能体演进
最初，Spotify 完全依赖确定性脚本完成代码变更。脚本会被应用到代码库中，完成相应的代码修改或配置修改。但他们很快发现，代码中的接口、调用方式和依赖关系极其复杂，一旦试图修改代码，难度会迅速上升。
即使只是替换一个方法或者 API，当它存在 5 种不同调用方式时，问题也会变得非常复杂。为了迁移代码，他们编写的每一个脚本最终都会膨胀到数千行，用来处理代码里的各种边界情况。这也是为什么大模型几乎一出现，他们就思考能不能用它们解决这个问题。
早期尝试效果并不理想，一方面是因为当时模型能力还不够，另一方面是他们解决问题的方式也比较天真——基本上只是把代码直接放到模型面前，要求模型一次性完成修改。但随着模型能力提升和对问题理解的深入，他们开始使用大模型评估器检查输出结果，也用不同方式拆解和分解任务，经过多轮迭代形成了今天的 Honk 系统。
2. Honk 架构解析：从代码生成到全流程验证的工程实践
2.1 简化的智能体架构与工具集成
Honk 的架构实际上相当简单。Claude Agent SDK 运行在一个 Kubernetes 容器组中，并拥有一组工具的访问权限。在 V2 之前，这些工具是提前定义好的许可列表，只有信任的工具才会开放给智能体。到了 V2，用户可以自行添加工具，智能体可以调用 Spotify 内部的任何工具。
其中最重要的工具之一是执行验证流程，比如运行持续集成构建。这些构建既可以运行在 Linux 上，也可以运行在 macOS 上。macOS 对 Spotify 尤其重要，因为所有 iOS 开发都需要在 macOS 环境中完成构建。
2.2 验证闭环：从构建测试到模拟器集成
验证环节是 Honk 系统的核心。他们有一些场景会把模拟器和 Claude 集成起来，自动完成从 Figma 设计稿到用户界面实现的整个过程。例如，他们一直在用这种方式，把电视端应用从现有的 iOS 应用移植过去。
这种闭环开发中，智能体拿到任务后需要展开任务、拆解任务，并在没有人类参与的情况下完成大量工作。这时验证就是最重要的一环。很多公司常犯的错误就是对验证闭环投入不足，而 Spotify 在这方面做了重大调整——强化自动化测试。
2.3 从人工审查到自动化合并的工程文化转变
在推进这项工作的过程中，Spotify 对工程实践做出了一项重大调整：把代码库拆分成了数千个组件，每个组件都有清晰定义的所有权，由特定团队负责。在投资代码舰队管理之前，每一次合并进代码库的变更都需要对应团队参与，这意味着在某些情况下可以在自动化测试方面稍微松懈一些，因为团队始终可以检查每一个 PR。
但当他们开始自动生成并提交针对源代码的 PR 时，就必须改变对各团队的要求。团队可能不再参与每一次变更，他们会自动合并其中大多数变更，相关团队甚至可能根本不会看到这些 PR。这意味着必须构建更完善的自动化测试体系，确保所有软件都能够承受这种自动化变更。
3. 标准化与一致性：为什么代码规范决定了 AI 编程的上限
3.1 代码一致性对智能体性能的关键影响
Spotify 发现了一个重要规律：代码库越一致，智能体的表现就越好。Claude 很擅长从单体代码仓库里的其他代码中寻找参考，但如果同一件事在代码库中存在 10 种不同实现方式，Claude 就会变得困惑。
他们一直在推动代码库变得更加一致，也在推动团队统一使用的工具和框架。这些投资最初是为了降低人类工程师的工作复杂度，提高人的生产力，但这些做法同样可以非常顺利地迁移到智能体上。过去那些合理、健康的工程实践，在这个新时代依然适用，只是具体形式可能发生变化。
3.2 从人类可读到机器可理解的代码转型
标准化工作让 Spotify 的代码库逐渐从“人类可读”转向“机器可理解”。当代码风格统一、接口规范、依赖清晰时，智能体更容易理解代码意图并作出正确修改。这种转型不是一蹴而就的，而是通过多年的代码审查、工具链建设和工程文化塑造逐步实现的。
例如，他们的后端单体代码仓库有超过 2000 万行代码，但 Claude 在这些代码仓库中的表现非常出色，很大程度上得益于代码的一致性和规范性。智能体能够查看代码仓库中的其他代码，并从中寻找解决当前问题的参考和启发。
4. ROI 衡量与工程生产力：从 PR 数量到用户价值的连接
4.1 初期的明显信号与后续的精细衡量
从 ROI 角度来看，Spotify 最初比较容易看到清晰的信号。例如 PR 提交频率提高了 75% 以上，而且可以直接把这种提升归因于 AI 工具。目前大约 73% 的 PR 可以直接由 AI 生成，这些指标表现相当不错。
但随着技术逐渐成熟、成本结构不断改善，大家对 ROI 测算精度的要求也越来越高。他们现在正在努力改进衡量方法，一部分是衡量生产力提升了多少，另一部分是为了获得这些提升究竟付出了多少成本，包括消耗了多少 Token、投入了多少小时，以及最终产生了多少有效产出。
4.2 从工程指标到业务价值的连接链路
Spotify 希望能够把工程师完成的交付物连接起来，例如 PR 和部署。这些交付物会进一步关联到“工作项（work item）”，也就是团队提前规划的工作。之后，工作项会连接到 A/B 测试和功能发布，从而能够反向归因，例如某一个 PR 为某项交付作出了贡献，而这项交付又进一步创造了用户价值。
这种连接在过去很难实现，因为人工编写的 PR 与最终业务价值之间的链路太长且不透明。而 AI 生成的 PR 由于有更完整的元数据和执行记录，使得这种归因变得可能。
5. 工作流重构：从 IDE 依赖到多智能体协作的新模式
5.1 个人工作流的彻底转变
Niklas Gustavsson 描述了他现在的工作流：在终端里开很多个 Tmux 会话，每当要做工作时，后台通常都会同时运行多个智能体。他一般会开 5 到 10 个终端标签页，配置成一个矩阵式工作区：一边是多个 Claude 会话，另一边是与它们对应的终端，并配合多个 Git 工作树使用。
这种工作流的核心变化是从“亲自编辑代码”转向“指导智能体完成代码”。在 Claude Opus 4.5 之前，他的工作流通常是让模型先写出大约 80% 的代码，然后还是要进入 IDE 完成最后的修改。后来，他突然不再需要做这一步了，模型可以直接完成实现。
5.2 从单任务串行到多任务并行的效率提升
传统开发模式下，工程师通常一次只能深入解决一个问题。而有了智能体协作，可以同时推进多个任务。Niklas 提到，他现在经常会同时让 5 个智能体在后台工作，与它们互动的方式已经和一两年前完全不同。
这种并行处理能力不仅提高了效率，还改变了问题解决的方式。工程师可以更宏观地思考系统设计，而把具体的实现细节交给智能体处理。原本用于实现的时间，现在更多被用来思考下一步该做什么、与客户交流，以及进行原型开发。
6. 原型开发民主化：从工程师专属到全员参与的技术普惠
6.1 非工程人员的创造力释放
Claude 和其他类似工具带来的一个重要突破，是任何人都可以把自己的想法用自然语言表达出来，然后让 Claude 负责实现。当越来越多人开始掌握这种方式，包括非工程人员，他们就开始尝试直接在 Spotify 的真实应用中实现自己的想法。
几个月前，Spotify 开始构建一套基础设施，让整个过程变得更简单。如今在 Spotify 内部，已经有了一种非常简单的方式，可以直接为移动端应用和后端系统构建端到端原型。他们还为这些原型建立了内部应用商店，员工可以把自己的原型分享出去，也可以在自己的应用中查看并体验其他人的原型。
6.2 高管直接参与原型验证的变革意义
目前，Spotify 的一位联合 CEO 也在内部应用商店里提交了原型。很多高级管理人员构建了质量很好的原型，这些通常是他们过去一直放在脑子里的想法。他们当然拥有完整的工程团队可以把这些想法真正开发出来，但工程团队往往正在专注于其他事情。
现在，他们可以比过去更快地尝试自己的想法，亲自感受最终产品大概会是什么样子。这种事情在一年前几乎无法想象，而现在他们每天都在做。这种变化不仅提高了创新速度，还改变了组织内部的沟通和决策方式。
7. 工程文化的适应性转变：从编码技能到问题解决能力的重心迁移
7.1 重新定义工程师的核心价值
对于从事工程工作很多年的工程师，Niklas 分享了他的个人体验：他一直非常享受编程中解决问题的过程，之前其实有点担心这项技术会改变工作方式，让自己怀念解决困难问题时的那种高强度思维挑战。
但事实证明，他真正喜欢的是解决问题，至于通过什么方式解决问题并不是最关键。他现在不仅变得更高效，能够通过工作创造更多价值，也开始可以解决过去根本无法解决的问题。他可以直接进入一些陌生代码库，过去可能需要几天甚至几周才能熟悉这些代码，而现在能够很快作出贡献。
7.2 从实现者到架构师和指导者的角色演变
工程师的角色正在从代码实现者向系统架构师和智能体指导者转变。过去大量花在实现上的时间被释放出来后，工程师可以更专注于问题定义、方案设计和质量验证。这种转变要求工程师具备更广泛的技能，包括对业务的理解、对系统的宏观视角，以及指导智能体完成任务的能力。
Spotify 的实践表明，这种转变不是对工程师的威胁，而是对他们能力的扩展。工程师现在可以解决更复杂、更有价值的问题，而不是被琐碎的编码任务束缚。
8. 可复用的企业级 AI 编程落地框架
8.1 基础设施先行的投资策略
Spotify 的经验强调，模型能力只是起点，真正决定 AI Coding 能否在大型企业落地的，是企业是否已经把代码、测试、工具和研发流程改造成一个可以被智能体理解、调用和验证的系统。这项投资需要长期坚持，不能期望一蹴而就。
首先应该投资的是代码仓库的标准化和一致性，这是智能体能够有效工作的基础。其次是自动化测试体系的完善，这是确保 AI 生成代码质量的关键。最后是持续集成和部署管道的优化，为智能体提供快速的反馈循环。
8.2 渐进式推进的实践路径
从 Spotify 的经验看，成功的 AI 编程落地应该采用渐进式策略。从最简单的自动化任务开始，比如依赖升级和代码格式化，逐步扩展到更复杂的代码修改任务。在每一步都建立完善的验证机制，确保代码质量不会因为自动化而下降。
同时要注重工程文化的适应性转变，让团队逐渐习惯与智能体协作的工作方式。这种转变需要时间，不能强行推进，要允许工程师以自己的节奏适应新的工作模式。
8.3 度量与反馈的持续优化
建立完善的度量体系至关重要，不仅要跟踪 AI 生成的 PR 数量，还要关注这些 PR 的最终业务价值。通过连接工程指标与业务成果，可以更准确地评估 AI 编程的投资回报，并为后续优化提供方向。
反馈循环的缩短也是关键优势。Spotify 现在可以将想法到验证的时间从几周缩短到几小时，这种速度优势在竞争激烈的市场中具有重要战略价值。其他企业在推进类似转型时，也应该把缩短反馈周期作为核心目标之一。
Spotify 的实践展示了一个未来图景：当编码不再是瓶颈时，工程师可以专注于更有创造性的工作，非工程人员可以直接参与产品创新，整个组织的创新速度将得到质的提升。这不仅是工具的改变，更是工作方式、组织文化和创新模式的全面演进。