30 秒看懂
Spotify 的 Honk 最初用于自动维护数千个代码组件，如今现有的测试基础设施也帮助验证编码智能体的工作，工程负责人 Niklas Gustavsson 说。他表示，约 73% 的拉取请求由 AI 编写，拉取请求频率提高了 75% 以上；公司仍在建立方法，将这些产出与用户价值联系起来。他认为，团队加快速度的同时，需要更好的自动化和一致的代码来保持质量稳定。Spotify 还建立了内部商店，供员工分享应用原型。
- 1代码增长快于团队规模，Spotify 因此自动化维护工作Gustavsson 说，代码库的增长速度曾是工程师人数增长速度的七倍。代码库统一管理基础设施取代了对数千个组件反复进行的手动迁移。
- 2模型评判器提高了早期修改的成功率，后来又被移除Gustavsson 回忆，加入评判器后，拉取请求的成功率从约 20%–30% 升至 80%。他说，模型和智能体基础设施进步后，Honk 最终不再需要它。
- 3自动合并修改需要更强的测试团队无法再参与每一次自动修改，因此 Spotify 加强了自动化测试。这些检查现在也帮助验证智能体生成的工作。
- 4提高速度并稳定质量需要持续投入可靠性Gustavsson 说，Spotify 在大幅加快速度的同时保持质量指标稳定，但公司必须投入测试，并预计还需继续加强可靠性。
- 5Spotify 表示 73% 的拉取请求由 AI 编写Gustavsson 还将拉取请求频率超过 75% 的增长归因于 AI 工具。Spotify 仍在建立方法，将这些产出与实验、用户价值和收入联系起来。
- 6一致的代码为智能体提供更好的参考示例标准化最初是为了提高工程师效率；Gustavsson 说，它也有助于智能体，因为仓库各处的示例遵循共同约定时，不容易让模型混淆。
- 7员工可以在内部商店分享可运行的应用原型Gustavsson 说，工程师和非工程人员都可以描述想法，利用真实应用和后端基础设施构建原型，有时一两个小时就能完成。
要点建议
- 在依靠智能体修改可能不会由组件负责人逐一审查的代码之前，先投入自动化测试。
- 提高代码和框架的一致性，让智能体能从仓库其他位置的有用示例中学习。
- Gustavsson 表示，Spotify 约 73% 的拉取请求由 AI 编写；公司仍在努力将工程产出与用户价值联系起来。
- 为员工提供快速构建和分享原型的方式，也包括非工程岗位的员工。
- 不要假定产出加快会自动保持质量；应监测质量并持续投入可靠性工作。
按章节阅读整理后的全文
从自动补全到后台智能体
Gustavsson 介绍个人工作流的变化及其使用的大型代码仓库。他说，Claude 可以参考现有代码。
Spotify 工程负责人 Niklas Gustavsson 回忆说，当 Boris Cherny 预测开发者会在几个月内停止使用集成开发环境（IDE）时，他曾对此持怀疑态度。Gustavsson 说，两个月后他自己就不再使用 IDE；他的工作方式变化之快，在他约 30 年的职业生涯中前所未见。
Gustavsson 受过分子生物学训练，在攻读博士期间处理基因组测序数据时学习了更多编程知识。原本计划离开生物学一年的他，后来长期从事软件工作。Spotify 后来开始尝试用语言模型自动修改代码，起初进展困难。
早期实验没有解决所有维护问题，但使用模型和评判器逐渐指明了方向。对 Gustavsson 个人来说，后来的一个 Claude Opus 版本是转折点：他不再只是把模型当作自动补全工具、再手动编辑最后一部分代码，而是可以交给它真实问题，无需自己在 IDE 里完成最后的修改。
Gustavsson 说，他如今使用相对简单的配置：多个终端会话和在后台工作的智能体。他通常打开 5 至 10 个标签页，配有对应终端和工作树。Spotify 有几个大型单体仓库，也有数千个较小的仓库；需要处理后者时，他会临时打开会话。
他起初担心在超大型单体仓库中使用智能体，因为早期工具在索引方面遇到过困难。Spotify 的后端单体仓库包含超过 2,000 万行代码，但他说 Claude 在其中运行良好，包括能够在仓库中寻找其他代码作为参考。
Cherny 问 Spotify 如何建立后台智能体工具 Honk。Gustavsson 说，大约五六年前，公司发现代码库的增长速度约为工程团队增长速度的七倍，意味着每位工程师最终需要维护的代码越来越多。
Spotify 为什么建立全代码库自动化
公司代码增长快于工程团队。代码库统一管理实现了重复迁移的自动化，但确定性脚本难以继续扩展。
Spotify 希望继续把想法变成产品，而不是把所有时间花在维护上。过去，Java 升级或 API 变更等迁移需要向数百个团队发送说明，每个团队再手动修改数千个组件中的相关部分。一次迁移可能耗时数月，公司每年只能完成约十次。
代码库统一管理基础设施让许多此类修改自动化，并合并了数百万个拉取请求。但确定性脚本遇到了复杂度上限：即使只是更换 API，也因为代码可能有多种调用方式而变得困难。每个脚本都积累了数千行处理边缘情况的代码。
从一次性修改到 Honk
Spotify 通过拆分任务和评判器改进了早期模型生成的修改。现在的 Honk 智能体可以使用工具并运行验证构建。
Spotify 尝试用早期语言模型解决这个问题，但仅仅把代码交给模型并要求一次完成修改，效果并不好。随着模型进步，团队学会了拆分任务，并用模型评判结果。这些迭代最终形成了 Honk，尽管最初的版本并非基于 Claude 构建。
Honk 最初用于安排和编排跨仓库代码修改。工程师很快希望把它用于其他任务，包括从 Slack 中调用它，因此它逐渐成为更通用的工具。Gustavsson 说，发布的 V2 版本实际上经历了远不止两次内部迭代。
Gustavsson 说，Honk 早期版本从独立评判器中获益很大：他记得拉取请求的成功率从约 20%–30% 升至 80%。后来公司移除了评判器，因为团队发现较新的模型和智能体基础设施不再需要它，也足够好。
他说，目前的架构相对简单：Claude Agent SDK 在 Kubernetes pod 中运行，并可以使用工具。早期版本使用预先定义的允许列表；V2 允许用户添加自己的工具。一项重要能力是在 Linux 和 macOS 上运行验证构建，后者是 iOS 开发所需的。
Cherny 问，验证能否超越构建，进一步操作 iOS 模拟器。Gustavsson 说可以：Spotify 将模拟器与 Claude 集成，帮助把 Figma 设计转为界面实现，并把 iOS 应用的功能移植到电视应用。
验证让自动修改能够进入各团队负责的组件
Spotify 开始自动合并全代码库修改时加强了测试。Gustavsson 说，质量和可靠性仍需要主动投入。
Cherny 认为，当智能体拆分任务、在每一步都没有人参与的情况下工作时，验证尤其重要。Gustavsson 表示赞同，并说 Spotify 在代码库统一管理工作中加强了自动化测试。
Spotify 将代码库划分为数千个组件，每个组件由特定团队负责和运营。过去，这些团队可以审查自己代码的每次修改，有时可以弥补测试不足。自动化拉取请求改变了这一预期：团队可能在修改自动合并前根本看不到它，因此测试必须加强。
Gustavsson 说，早期投入现在也帮助 Spotify 验证智能体生成的工作。Cherny 认为，让质量实践自动化可以使工作加快。Gustavsson 补充说，必须同时关注速度和质量：Spotify 在速度提高的同时保持了质量指标稳定，但测试投入是必要的，可靠性工作也必须继续。
部署以及衡量 AI 的回报
公司通过频繁部署更快获得反馈，并报告拉取请求频率提高。它正在建立工程工作与用户价值之间的联系。
Gustavsson 说，Spotify 每天大约进行 4,500 次生产环境部署，因此有很多可能出错的机会。频繁部署是公司长期以来为更快获得想法反馈而做的努力。有些想法大约一小时就能进入生产环境，但另一些需要大量探索，无法这么快发布。
公司大约有 2,900 名工程师。被问到如何衡量 AI 工具的回报时，Gustavsson 表示，Spotify 将拉取请求频率超过 75% 的提高归因于 AI，并说约 73% 的拉取请求由 AI 编写。但衡量问题并不止于这些产出指标。
Spotify 希望将拉取请求和部署连接到计划中的工作项，再连接到实验、发布、用户价值和收入。Gustavsson 说，公司仍在建立这些联系。随着应用成熟，他预计更精确的投资回报估算会变得重要，包括取得改进所花费的成本。
标准化、工作方式变化和更快的原型
Gustavsson 建议保持代码一致，继续重视工程基础。Spotify 也在让工程师和非工程人员构建并分享原型。
对于其他工程领导者，Gustavsson 建议不要忽视自动化测试和标准化等基础投入。Spotify 为帮助员工而提高代码、工具和框架的一致性；他说，这种一致性也有助于智能体寻找示例，不必面对同一件事的十种不同做法。
Gustavsson 说，他曾担心把编码工作交出去会让自己失去喜欢的智力挑战，包括他在编程竞赛中享受的挑战。多个智能体在后台工作后，他发现即使解决问题的方式变了，解决问题本身对他仍然重要。他强调，不同人对这一转变的感受会有所不同。
他说，这些工具让他能够在不熟悉的代码库中做出贡献，而过去理解这些代码可能需要数天或数周。Cherny 也描述了类似变化：花在实现上的时间减少，更多时间用于思考下一步、与客户交谈和构建原型。
Spotify 为工程师和非工程人员投入了原型开发。Gustavsson 说，员工可以用自然语言表达想法，让 Claude 使用公司的移动应用和后端实现端到端原型。内部应用商店让同事可以分享和试用这些原型。
Gustavsson 说，使用真实应用基础设施和数据，有时一两个小时就能准备好可分享的原型。他说，公司各层级员工都构建了原型，包括一位联席首席执行官和其他高管；一个想法可以在一天内得到尝试，无需等待数周或数月才有团队腾出时间。
同频道的其他文章
16:17EN → 简体中文
Claude· 2026年11月6日Salesforce 如何用 Claude Code 将有效编码产出翻倍Boris Cherny, Muralidhar Krishnaprasad, Richard Pack · AnthropicSalesforce 介绍如何衡量 AI 辅助工作的价值、培训工程师使用智能体，并检查生成代码的缺陷。
10:38EN → 简体中文Claude· 2026年10月23日Factory 的 Matan Grinberg：如何建立值得信赖的软件智能体Kai Gill, Matan Grinberg · AnthropicFactory 首席执行官说，智能体从一家银行的 COBOL 迁移中吸取经验，让下一次迁移所需的人力参与减少了 90%。
12:19EN → 简体中文Claude· 2026年10月8日Shopify 的 Mikhail Parakhin：用 AI 做过去做不到的事Boris Cherny, Mikhail Parakhin · AnthropicShopify 首席技术官介绍商家预测系统，并建议开发时使用最大模型，生产环境使用成本较低的模型。
33:46EN → 简体中文Claude· 2026年10月6日Every 如何打造学习团队风格的共享 AI 同事Katelyn Lesse, Dan Shipper, Willie Williams · AnthropicEvery 的 Slack 智能体共享工作流，从编辑的历史修改中学习，并通过隔离会话尊重访问权限。
17:50EN → 简体中文Claude· 2026年9月24日Patrick Collison：用 AI 加速开发，同时保持可靠性Boris Cherny, Patrick Collison · AnthropicStripe 首席执行官介绍隔离开发、严格的安全边界，以及一个由两三名工程师借助 AI 用两个月完成的项目。
34:42EN → 简体中文Claude· 2026年9月8日三位创始人谈 AI 智能体的验证、扩展与成本Lance Martin, Sahaj Garg, Mihir Garimella, Todd Olson · AnthropicWispr、Actively 和 Pendo 介绍如何构建智能体产品、测试其工作，以及决定哪些基础设施由自己管理。