每首歌一个 PR?

MMaximilian Schwarzmüller
컴퓨터/소프트웨어경제 뉴스경영/리더십

스크립트

00:00:00“Spotify 每天进行 4,500 次生产部署
00:00:05且 73% 的合并请求(pull requests)现在由 AI 辅助完成。”
00:00:10哇。
00:00:11尤其是每天 4,500 次生产部署,
00:00:15这确实令人印象深刻。
00:00:16但我不太确定这种深刻是好事还是坏事。
00:00:19X 上那条推文下面有一个很有趣的评论,
00:00:23我看了觉得挺有意思的。
00:00:25他们是在为每一首歌都做一个合并请求吗?
00:00:28确实看起来像是这样。
00:00:30我是说,这出自 Claude Devs 的 X 账号。
00:00:35这是对 Claude Code 的一次推广,
00:00:37因为正如我们在帖子里了解到的,
00:00:39他们显然正在使用 Claude Code
00:00:42以及 Anthropic 的模型来实现如此大量的交付。
00:00:45当然,如果你看过我之前的视频,
00:00:48你就会知道,我也在使用 AI 智能体。
00:00:50这就是未来。
00:00:52这就是如今软件开发的工作方式。
00:00:54我开设了一门 Claude Code 课程,分享我所有的见解、
00:00:57技巧以及如何有效使用这个工具。
00:01:00但每天 4,500 次生产部署,认真的吗?
00:01:05我是说,是的,Spotify 显然是一家大公司。
00:01:08这不是什么秘密,但你不得不怀疑他们到底在做什么?
00:01:12我是 Spotify 的活跃用户。
00:01:15我感觉这款应用,嗯,并没有太大的变化,
00:01:21至少在过去一年左右的时间里没有往好的方向变化。
00:01:26对我来说,实在无法理解那每天 4,500 次生产部署里到底包含些什么。
00:01:37拜托,这不是开玩笑,我是认真的。
00:01:40请在评论区分享你们认为他们整天在交付些什么。
00:01:44至于 73% 的合并请求,嗯,确实。
00:01:48我的意思是,AI 辅助在理论上可以是任何东西。
00:01:51显然,简单的补全,标签页补全,老派风格,
00:01:58在你审查合并请求并可能进行一些修改时,也可以算作 AI 辅助。
00:02:04当然,让 AI 智能体来分析也属于 AI 辅助。
00:02:08坦率地说,我很惊讶它不是 100%,因为我想,
00:02:13AI 应该会参与到几乎所有的 PR 审查或几乎所有 PR 的创建中。
00:02:20但是的,我相信这个数字会改变。
00:02:22看到这一点并不奇怪。
00:02:26但第一个数字确实反映了我们所见的一种普遍趋势,对吧?
00:02:34几个月前我们讨论过整个“Token 最大化”的争论。
00:02:38后来很多公司意识到这太贵了,而且仅仅告诉软件工程师
00:02:44尽可能多地消耗 Token 可能不是一个好策略,
00:02:48因为显然很容易消耗 Token,但这并不能保证好的结果。
00:02:53现在我们似乎正在转向一个流行“大量交付”的时代。
00:02:58因为有了 AI,你当然可以做到,对吧?
00:03:01你可以交付很多东西。
00:03:02你可以同时运行五个智能体,使用 Git 工作树,
00:03:06同时处理四个不同的项目。
00:03:08是的,你可以在一定程度上进行并行处理。
00:03:12肯定能用 AI 构建很多东西。
00:03:15毫无疑问。
00:03:17它确实能加速你作为软件开发者的工作。
00:03:20但它也可能让你慢下来。
00:03:21我们都有过那样的经历,在 AI 的帮助下走错了路,
00:03:25因为你变得越来越像个“氛围编码员”(vibe coder),
00:03:28因为你懒得去评估 AI 生成的内容,
00:03:32因为继续下去感觉实在太快了。
00:03:36然后某一点上,你对自己的代码库完全没有理解,
00:03:39但有些东西无法运行,或者你对代码发展的方向不满意,
00:03:42于是你放弃了那个项目或者撤销了很多工作。
00:03:48好吧,我们可以争论一下这时候你是否真的更有效率了。
00:03:52但撇开这些不谈,我们大家都在设法弄清楚如何最好地利用 AI,
00:03:58你确实可以用它提高效率。
00:04:01我是说,即使你只是给它一个明确的计划,告诉它该做什么,
00:04:05而且那只是一个微小的功能,
00:04:06仅仅让它吐出大块的代码就能帮你提速。
00:04:10我不确定它是否像有些人声称的那样有 10 倍的提升甚至更多。
00:04:14我不确定每天 4,500 次部署是否是我们应该追求的衡量标准。
00:04:22我认为我们确实应该致力于弄清楚如何有效地使用 AI,
00:04:28如何,当然,加速我们的软件交付,
00:04:32但也许,也该稍微关注一下质量,而不仅仅是数量。
00:04:37现在,我们都处于那种数量时代,对吧?
00:04:39Token 最大化,部署次数。
00:04:41质量同样重要,AI 可以提供帮助。
00:04:45但好的旧式测试,包括人工测试,
00:04:48不仅仅是 AI 生成的自动化测试,
00:04:51因为它有一种倾向,或者说可能有种倾向写出能通过,
00:04:56但实际上什么都没测试到的测试。
00:04:57但抛开这些,好的旧式人工测试,
00:05:00以及真正地将你作为人类的品味和决策注入工作流程中。
00:05:07我觉得这些可能都是好主意。
00:05:09很有意思,到时候看看这个趋势何时会结束。
00:05:13我只是偶然发现了那个数字,想分享我对那个数字的惊叹。
00:05:18就像我之前提到的,我真的很想听听,
00:05:20你们认为 Spotify 整天都在交付些什么?
00:05:25因为我真的无法理解。
00:05:29抱歉。

핵심 요약

软件开发领域正从“Token 最大化”转向“海量交付”模式,但每天 4,500 次生产部署的追求可能导致质量被忽视,人类的品味与决策依然是软件开发的必要前提。

하이라이트

  • Spotify 每天执行 4,500 次生产部署。

  • 目前 73% 的合并请求(pull requests)通过 AI 辅助完成。

  • 过度追求 AI 生成代码的“海量交付”模式可能导致开发者对代码库失去把控。

  • AI 辅助编码涵盖范围极广,从简单的标签页补全到复杂的 AI 智能体分析皆在其内。

  • 自动化测试存在缺陷,可能生成无法检测实际问题的无效测试用例。

타임라인

海量交付的现状与数据

  • Spotify 每日生产部署达到 4,500 次。
  • AI 辅助在合并请求处理中的占比高达 73%。
  • 高频交付往往依赖 Claude Code 等 AI 工具实现。

这一阶段展示了软件开发流程的量化指标。每天 4,500 次部署表明大型软件公司正在通过 AI 实现交付提速。虽然 AI 辅助覆盖了大部分合并请求,但其实际形态跨度很大,包括基础补全与 AI 智能体分析等多种形式。

数量与质量的矛盾

  • 业界正在经历从消耗 Token 到盲目追求交付频率的范式转换。
  • 使用 AI 同时并行处理多个项目会增加开发者的认知负担。
  • 过度依赖 AI 生成代码可能使开发者丧失对代码库的底层理解。

虽然 AI 可以加速微小功能的实现,但追求高频部署并非衡量效率的唯一标准。当开发者因追求速度而忽略评估 AI 输出时,会进入“氛围编码”状态,导致项目由于缺乏理解或代码质量问题而被迫撤销。

人工参与的必要性

  • AI 自动生成的测试可能通过测试但无法验证实际逻辑。
  • 软件开发需要回归人类测试与品味决策。
  • AI 应作为提升效率的工具,而非取代人类的判断。

盲目崇拜部署次数可能掩盖质量危机。开发流程需要人工参与的测试与决策作为质量把控的核心,而非仅依赖 AI 的自动化能力。软件质量的保障最终仍取决于开发者对交付内容的深度掌控。

커뮤니티 글

모든 글 보기