大家好，我是 Gergely，这是《实用工程师通讯》的一期额外免费内容。每期中，我都会从资深工程师和工程领导者的视角，探讨大型科技公司与初创企业的动态。今天，我们将聚焦上周《焦点》五个话题中的一个。完整版订阅者已于七天前收到本文。如果您收到了这封转发邮件，可以 在此订阅。

去年八月，我们报道了前延部署工程师 (FDE) 需求突然兴起的趋势，而现在有迹象表明需求正在进一步增长。

谷歌：FDE 招聘激增

谷歌正在加倍投入 FDE，并大幅简化招聘流程。谷歌云 CEO 托马斯·库里安宣布在 Go-To-Market 团队内成立一个新的 AI 重点组织，并为其招聘大量 FDE。

我听说招聘流程已大大缩短，从持续数周的 4-6 轮面试，缩减至仅两天内的两轮面试。看来谷歌对此职位的渴求（甚至是急切？）非同寻常。

OpenAI 外包 FDE 大规模招聘

周一（5月11日），OpenAI宣布成立 OpenAI 部署公司，这是一家由 TPG、Advent 等公司出资 40 亿美元、估值 140 亿美元的独立实体。OpenAI 本身似乎并非投资者，而是扮演合作伙伴角色。

公告中提到了 FDE，并称他们的工作将是“与业务负责人、运营者和一线团队紧密合作，识别 AI 能产生最大影响的地方，围绕它重新设计组织基础设施和关键工作流程，并将这些收益转化为持久的系统。”

据此，FDE 将在 OpenAI 的企业销售活动中扮演重要角色，确保其 AI 系统为客户正常工作并交付价值。将此项业务外包给新的部署公司，也可以让 OpenAI 专注于开发更好的 AI 模型，而由其合作伙伴公司及其 FDE 负责面向客户的部分。

相关进展方面，OpenAI 收购了 Tomoro，这是一家总部位于英国、成立于 2023 年的 AI 公司，在英国、亚洲和澳大利亚雇用了 150 名 FDE。Tomoro 是 OpenAI 部署公司的首次收购。

Anthropic 计划外包 FDE 招聘

Anthropic 也在采取同样的做法，创建其自己的独立 FDE 咨询公司。上周一（5月4日），Anthropic发布了一份异常模糊的公告，宣布这项新业务，没有名称，也几乎没有提及投资细节。

投资者包括 Anthropic、贝莱德、Hellman & Friedman 和高盛。新业务将与“跨行业的中型公司合作，将 Claude 融入他们最重要的运营中。”

Anthropic 的做法似乎与 OpenAI 相同：创建一家有外部资金的独立公司，FDE 在其中将 Claude 集成到企业中，这些企业随后可能会购买比以往更多的 Claude 令牌。

FDE 还是顾问？

这些 FDE 角色看起来与外部顾问或系统集成商非常相似。一年前，我与 OpenAI 和 Ramp 的 FDE 交谈过，他们的工作似乎真正融合了平台工程——FDE 会回馈平台——软件工程（因为他们构建新解决方案），以及解决方案工程（集成到客户的服务中）。

但如今，该角色似乎即将变得与解决方案架构师或顾问难以区分，尤其是考虑到这些新的 FDE 工作机会位于准外部公司，与 AI 产品的开发团队分离。

招聘广告越来越清楚地说明了该角色，但仔细解读仍然有帮助。这里有一个谷歌云 FDE 的例子。乍看之下很吸引人（我做了强调）：

“你是一名嵌入式构建者，弥合前沿 AI 产品与客户生产级现实之间的鸿沟。”与传统顾问角色不同，你扮演的是“创新者-构建者”，超越高层架构，深入代码、调试，并与客户环境内的团队直接协作，交付定制的代理解决方案。你的角色专为具有创始人思维、高度自主的工程师设计。你将解决生产阻碍，包括解决阻止 AI 达到企业级成熟度的集成复杂性、数据准备问题和状态管理挑战。通过嵌入战略客户，你发挥双重作用：提供复杂 AI 系统的“白手套”部署，并充当关键反馈循环，将真实的现场洞察转化为谷歌云未来的产品路线图。”

翻译成大白话：

你是一名在客户办公室写代码的承包商。实际工作大约 25% 与编码相关，50% 是集成/管道工作，25% 是会议和客户支持。其他都是各种管理和内部流程相关的事情。

以下是我认为谷歌招聘广告中的一些术语在实际工作中意味着什么：

• “创始人思维”。没有人会提供需求规格，范围蔓延需要你自己处理。如果你的项目没有交付，那也是你的问题。
• “高度自主”。除了你自己，没有其他资源。
• “白手套”。不要对客户提出的任何建议说“不”，即使他们本该听从你关于某事的反馈。
• “将真实世界现场洞察转化为谷歌云未来产品路线图的关键反馈循环”。你会提交工单，谷歌的一些产品经理可能会看其中一些。

但公平地说，这份 FDE 工作确实适合一些人：

• 职业生涯早期、希望谷歌出现在简历上、但可能难以获得这家科技巨头软件工程师职位的人。
• 那些喜欢端到端交付、能在模糊性下工作良好（“创始人思维”很贴切！）并愿意对结果负责的人。

另一方面，我怀疑这份 FDE 工作可能不适合以下人群：

• 喜欢构建精心设计的系统并重视花时间将其做好的人。
• 喜欢构建全新系统的人。
• 偏好长期项目并与其他软件工程师协作的人。

在 OpenAI 和 Anthropic 的案例中，FDE 的外包性质更为明显。谷歌至少是将 FDE 招入公司，他们的一部分薪酬会包括股票。但在 OpenAI 和 Anthropic，新的 FDE 将被招聘到一家独立的公司，即使他们获得股票，也极可能不是 OpenAI 或 Anthropic 的股票。因此，如果 OpenAI 或 Anthropic 从 FDE 的工作中获益匪浅，FDE 们却无法分享这份红利！

简单来说：在这些外部公司被招聘的 FDE 不会被视为“核心”成员。如果他们是，那么这些公司本应像过去一样，直接招聘更多 FDE。

应届毕业生的机会？

如上所述，新的 FDE 角色可能成为刚进入行业的初级软件工程师的绝佳机会，Box CEO Aaron Levie表示：

阅读上周《焦点》的完整内容，或查看本周的《焦点》。本周内容涵盖：

1. Antigravity 2.0 从其新 IDE 中移除了 “IDE”。 关于重新设计的 IDE 的反馈压倒性负面，原因包括错误、糟糕的用户体验和模型支持，以及大量消耗 Gemini 令牌配额。另外：有迹象表明 Antigravity 自己的开发者在工作中使用其他工具？
2. 为什么谷歌的产品生态系统如此混乱？ 谷歌 I/O 会议上展示的产品范围给人留下了混乱、不连贯的印象。但谷歌“让千朵花齐放”的方法可能赋予这家搜索巨头在 AI 竞赛中其他大型科技公司都没有的、被低估的优势。
3. Meta 裁员 8000 人。 这家社交媒体巨头内部士气非常低落，成千上万的人失去工作，而此时其收入和利润正创下新高。与此同时，那些被分配去做枯燥数据标注工作的员工则幸免于难。
4. 行业脉搏。 Anthropic 每年支付 150 亿美元给 SpaceX 购买算力；SpaceX 的财务状况和 IPO 申请文件；GitHub 再遇困境；法院驳回埃隆·马斯克对 OpenAI 的“虚伪”诉讼；西班牙可能停止在西甲足球比赛期间屏蔽互联网。
5. 2026 年如何在前沿实验室获得工作。 谷歌一位杰出工程师建议专注于培养特定技能。

阅读完整的《焦点》。

由 mimo-v2.5 模型翻译，花费 8687 tokens

澳大利亚一个管理1240亿美元资产的养老基金，若非依赖第三方备份，将丢失存储在谷歌云上的所有数据。这是GCP罕见的重大失误——区域复制未能阻止数据删除——谷歌云首席执行官也罕见地发表声明承担责任。

以下内容节选自 《技术脉搏》第93期：OpenAI让谷歌起舞，最初发布于2024年5月16日。重新发布此文是因为谷歌云在2026年5月20日再次出事：通过 封锁Railway的谷歌云账户，导致云基础设施提供商Railway离线。本文是一则警示：如果您使用GCP，请准备好B计划，以防GCP删除您的账户和数据，或封锁您的账户。

继谷歌云在云服务提供商中排名遥遥落后之后，最近的一起事件可能进一步巩固其作为三大云服务商中最不可靠的声誉。

UniSuper是澳大利亚最大的退休储蓄账户之一，为61.5万名公民服务，也被称为“养老基金”。UniSuper管理着1240亿美元的资产，是该国最大的基金之一。

4月29日，该服务出现故障。会员无法登录在线账户或管理资金，直到两周后的5月15日才恢复。

原因是谷歌云意外删除了UniSuper的订阅，这也删除了与该订阅相关的所有数据。UniSuper曾在谷歌云的两个区域设置复制以防止单区域故障，但谷歌云也将副本一并删除了！

UniSuper之所以能避免数据丢失，全赖于在谷歌云之外的另一家服务商处有备份。 令人惊讶的是，UniSuper承认若非谷歌云的失误，他们将丢失谷歌云上的所有数据。UniSuper得以恢复服务的唯一原因是他们在另一家服务商处备份了数据。基本上，UniSuper不信任谷歌的跨区域复制策略，事实证明这是一个100%正确的假设。在养老基金中，那个决定投入额外资源进行“以防谷歌失败的备份”的人拯救了局面。

这对谷歌来说极其尴尬。UniSuper似乎迫使谷歌云采取了行动，与谷歌云首席执行官Thomas Kurian共同发布了一份声明，其中谷歌云将全部责任揽下。根据我的经验，这种情况很少如此黑白分明，因为通常需要双方共同导致如此重大的故障。如果最终发现UniSuper的员工在这次故障中扮演了角色，我也不会感到惊讶，但谷歌云犯了足够多的错误，使得新闻稿可以将所有责任归咎于它。我询问谷歌云该新闻稿是否真是联合发布，以及他们是否有更多补充。公司确认新闻稿无误，并未添加任何其他内容。

无论责任在谁，长达两周的停机时间对一家大型基金来说仍然很长。据我所知，对UniSuper的损害主要是声誉上的，因为资金是安全的。

用户有几周无法查看自己的余额，并被告知是谷歌云搞砸了。这意味着多达61.5万名澳大利亚人心中，UniSuper和谷歌云将与不可靠性牢不可破地联系在一起。

我不断看到谷歌云对其云服务的提供似乎没有明确的战略。几个月前，我们深入探讨了AWS、Azure和GCP如何应对区域性故障，我得出的结论是，在三大云服务商中，很难看出GCP有何战略，除了遵循流程，而且做得最不令人印象深刻。如果一家服务商在应对区域性故障时反应最慢，或者一个可用区故障就能拖垮整个区域，又或者尽管有区域复制，却通过删除操作丢失所有客户数据，那么它很难获得市场份额。

这次事件提醒我们，不应完全信任你的云服务商。 UniSuper明智地在其他地方为其在谷歌云中的数据保留了备份。虽然很想指责谷歌云：但没有任何厂商能绝对保证将来不会犯下同样前所未有的错误！

经验教训是，如果你拥有非常有价值的数据，请在其他地方保留备份。如果你使用任何云服务商，请使用另一个云、本地备份或其他方式。

阅读完整的《技术脉搏》期刊

由 mimo-v2.5 模型翻译，花费 2874 tokens

你好，我是Gergely，这是一期Pragmatic Engineer Newsletter的免费特刊。在每一期中，我都从资深工程师和工程领导者的视角，来报道大型科技公司和初创公司。今天，我们将深入探讨上周《脉搏》五个主题中的一个。完整订阅用户在七天前已经收到了下面这篇文章。如果你收到了这封转发的邮件，可以 在此订阅。

上周，我们报道了Anthropic 似乎在快速消耗开发者的善意，其做法包括悄然“削弱”Claude Code、无预警封禁企业账户，以及一项涉及先撤销后恢复Claude Code的奇怪增长实验。本周，一位订阅了20美元/月Pro计划的开发者，在订阅才几天后就失去了Claude Code的使用权：

本周，Anthropic宣布了大规模的数据中心扩张，并放宽了之前的使用限制。与此同时，埃隆·马斯克的SpaceX/xAI（合并后为一家公司）将其整个“巨像1号”数据中心租赁给了Anthropic。根据公告：

“巨像1号拥有超过22万个NVIDIA GPU，包括密集部署的H100、H200和下一代GB200加速器。该集群为大语言模型、多模态系统、科学模拟和前沿规模的生成式AI提供了极致的并行性能。

Anthropic计划利用这额外的计算能力，直接提升Claude Pro和Claude Max订阅用户的服务容量。”

与此次发布同步，Anthropic 宣布：

• 将Claude Code针对Pro、Max、Team和按席位企业计划的当前5小时使用限制翻倍。
• 取消Pro和Max计划下Claude Code的高峰时段限制。
• 大幅提高Opus模型的API速率限制。

产能问题是否是导致Anthropic让Claude变差的原因？可以确认的是，该公司已挣扎于产能问题数月之久。巧合的是，Claude Code被“削弱”导致了计算负载降低，而从便宜的计划中移除Claude Code访问权限，则可能被视为一种速率限制。甚至封禁企业账户，也可以看作是在业务难以支撑现有增长时的一种缩减行为。昨天（5月6日），在Anthropic主办的“Code with Claude”活动上，首席执行官Dario Amodei表示：

“我们最初预计的是10倍增长，而在过去一段时间里，我们看到的是收入和使用量上更接近于80倍的增长。”

SpaceX/xAI将大部分产能租赁给Anthropic颇具讽刺意味，因为xAI（马斯克的AI初创公司）开发的Grok是前沿模型，也是Claude的直接竞争对手。此外，Anthropic在今年1月还封禁了xAI开发者使用Claude。正如当时的报道：

“AI实验室不允许另一家AI实验室使用其模型是常见的做法，OpenAI、Anthropic和Google都是如此。另一方面，一个领先的AI实验室为何会想用竞争对手的模型来进行自己的日常工作？

事实证明，xAI（埃隆·马斯克的AI实验室）一直依赖Cursor来编写代码，我们知道这一点是因为他们的访问被切断了。”

Anthropic封禁xAI很可能是为了防止Claude在xAI试图改进Grok编码能力时被潜在地蒸馏。与此同时，马斯克今年早些时候曾称Anthropic“仇视人类且邪恶”，并表示新租户“憎恨西方文明”。但双方似乎都乐意将此事抛诸脑后并达成交易，因此可能另有隐情。

SpaceX/xAI是否可能正在退出前沿AI模型竞赛？将其数据中心产能的很大一部分出租，或许暗示了这一点。SpaceX/xAI拥有两个数据中心：巨像1号和巨像2号。巨像1号占据了当前SpaceX/xAI总容量的大约45%，以及规划总容量的20-25%。

放弃如此多的产能可能表明需求不足或产能闲置。这也意味着Grok正在将市场份额输给Claude、ChatGPT和其他领先模型。在二月份的AI工具调查中，我们发现很少有人提及Grok，其使用量落后于DeepSeek和Qwen等开源模型。

公平地说，与Anthropic和OpenAI不同，Grok从未拥有过发展起来的B2C或B2B业务。Grok最大的消费者用例似乎是其集成到社交媒体平台X中；至少，我不知道有任何科技公司在重要工作中使用该模型。

“敌人的敌人就是朋友，”这句格言说得好。如果马斯克最恨哪家公司，那就是OpenAI。他目前正在起诉OpenAI，声称该公司背弃了为人类利益开发安全AGI的非营利创始使命，转向了由微软支持的以利润为导向的模式。马斯克还声称，尽管投资了约4000万美元，他却没有任何公司所有权。

他要求1500亿美元的赔偿，解雇Sam Altman和Greg Brockman，并让OpenAI回归到他投资时的完全非营利状态。我们在2023年Sam Altman被解雇后不久，就在深度报道《OpenAI究竟是什么？》中探讨了OpenAI在非营利和营利之间的伦理挑战。

同样，如果今年早些时候Anthropic首席执行官Dario Amodei与印度总理同台时拒绝与Sam Altman握手有任何启示的话，那么Anthropic很可能也与OpenAI存在问题。

产能问题损害Anthropic，会使OpenAI受益。因此，通过向Anthropic提供大量产能，马斯克使得OpenAI更难赢得市场。考虑到他曾是投资者，这颇具讽刺意味。

阅读上周《脉搏》的完整内容，或查看本周的《脉搏》。本周内容涵盖：

1. 前场部署工程再度升温。 Google、OpenAI和Anthropic对这一职位的需求巨大。最新的FDE角色看起来像是由许多初级工程师担任的顾问/解决方案架构师角色。
2. 为何裁员激增？ 科技行业裁员规模高于2023年初以来的水平，原因各异：更小的团队催生了重组，并减少了对中层管理的需求。同时，业绩不佳的公司在没有AI影响的情况下也在裁员。
3. 新趋势：在微软自报100%的代码由AI生成。 随着年中绩效评估临近，一些管理者建议下属声称他们用AI完成了一切。
4. 行业脉搏。 亚马逊也在搞“token最大化”，SaaS公司增长快于以往——部分可能得益于AI，用AI重写为Rust语言的Bun表现良好，Anthropic在企业支出上超过OpenAI，等等。
5. 氛围编程与代理工程令人不安地接近。 软件工程师Simon Willison的一个相关观察：对AI代理代码的审查程度低于理想状态。

由 mimo-v2.5 模型翻译，花费 7345 tokens

简而言之： TechPays加入 Levels.fyi：欧洲领先的科技薪资网站将得到应得的关爱与维护。感谢 Zsombor多年来与我共同建设这个项目。

薪资透明度在科技行业一直是个问题，尤其是在欧洲。有一段时间，我以为伦敦或阿姆斯特丹的高级及以上软件工程师最高薪资大约在10万英镑/10万欧元左右。一旦达到这个水平，就意味着你已经成功，处于市场顶端！真的如此吗？

因此，当2016年我在Skyscanner担任首席工程师，拿着9.3万英镑的薪水时，我没想到自己还能获得显著更高的报酬。薪资调查一直证实我的收入远高于中位数，处于薪资等级的第90百分位。

想象一下我的惊讶：我收到了Uber在阿姆斯特丹的offer，它实际上让我的薪酬翻了一番，达到约22-25万欧元（26-29.5万美元）的水平。到第四年，我的薪酬达到28.3万欧元（33.2万美元）：

这感觉就像我发现了一个市场“隐秘的、更高层级”的部分，而其他人对此一无所知。当我在Uber担任经理并开始为团队招聘时，几位优秀的软件工程师对推进流程犹豫不决，因为他们假设自己已经处于市场的顶端——但他们的薪酬大约只有我们可能提供的一半！我无法告诉他们“你们的数据是错的，这里的薪水高得多！”，因此他们中的许多人干脆放弃面试，以为最多只能加薪5-10%。而他们本可能让薪酬翻倍……

我亲眼看到，缺乏准确的薪酬信息对我们开发者不利，并决定尝试改变这一点。我收集了近200名在荷兰工作的工程师的数据点，并解释说荷兰和欧洲的软件工程师薪酬中存在第三个、“隐藏”的层级，详见《荷兰及欧洲软件工程师薪酬的三峰分布》。

文章获得成功后，我决定将收集到的薪酬数据点“开源”，于是TechPays诞生了：

我和Zsombor Erdődy-Nagy共同建立了这个网站。我们注重支持薪酬匿名化、捕捉自由职业者薪酬，并详细拆解薪酬方案的构成。我们收到了许多暖心故事，讲述你们如何借助这些信息成功谈判获得了更好的薪酬方案。

知道我们在发挥作用，让我们作为副业项目坚持了几年。但随着时间的推移，Zsombor和我都忙于其他项目。对我来说，是《务实工程师》占用了更多时间。我们希望找到一种方式，让TechPays继续运营并得到应有的关爱。

Levels.fyi将接管运营TechPays——并吸收关于欧洲薪酬方案的知识，整合到他们的全球薪资透明平台中。我认识Levels.fyi的创始人Zuhayeer和Zaheer多年，我们共享在科技行业实现薪资尽可能透明的驱动力。

对于TechPays，没有任何变化：你仍然可以像以前一样浏览数据。并且可以期待在Levels.fyi上，无论是在欧洲还是全球，获得更高质量的数据点。

要了解更多薪酬细节，请查看Levels.fyi。并阅读基于Levels.fyi数据点的《美国、英国和印度科技薪酬的三峰分布特性》：

由 mimo-v2.5 模型翻译，花费 6324 tokens

嗨，我是Gergely，这是《实用工程师通讯》的额外免费刊期。在每一期中，我都从资深工程师和工程领导者的视角来探讨大型科技公司和初创企业。今天，我们从上周的《脉搏》议题中选取四个主题之一进行探讨。完整订阅者已于七天前收到了以下文章。如果您被转发了这封邮件，可以点击此处订阅。

GitHub最近的可靠性表现已远低于可接受水平：上月，第三方测量数据显示其可靠性仅为一个“9”（即90%）。而本月，根据第三方跟踪器的数据，可靠性已降至零个“9” – 86%。上周，情况变得更糟：发生了一起堪称丢人的数据完整性事件、更多服务中断，以及GitHub最终给出的部分解释。

数据完整性事件

上周四（4月23日），发生了这件事：当合并组包含多个PR时，通过合并队列使用挤压合并方法合并的PR会产生错误的合并提交。后续合并的提交被回滚：基本上，提交在合并的代码中“丢失”了！

由于GitHub引入了一个缺陷，该服务违背了其完整性承诺，即在使用挤压合并（一种通常用于将多个小提交合并为一个有意义提交的技术）时，PR会按预期合并。这很重要：因为数据完整性承诺对于像GitHub这样的服务来说是最重要的承诺之一。

总共影响了2,092个拉取请求，受影响的公司包括Modal和Zipline。实际上，GitHub将大量工作推给了受影响的客户，他们不得不手动梳理和恢复丢失的提交，而GitHub无法提供任何协助。

客户不得不手动查看其git历史记录并恢复缺失的代码。在按照手动恢复步骤（回滚挤压提交并逐一重新应用提交）操作后，所有提交应该都已恢复。

GitHub后来通过电子邮件将受影响的提交列表发送给了客户，但奇怪的是，GitHub高管似乎淡化了此次中断的性质。毕竟，一次搞乱数据完整性的中断，比单纯的可用性下降（数据未损坏）要严重得多。

Modal的软件工程师Can Duruk对GitHub对此事的低调回应表示不满：

“COO故意找一个巨大的分母让影响显得很小，感觉非常不诚实；而不是真诚地道歉，说明这完全违背了他们对客户的承诺。我们不得不深入挖掘他们的状态页面，才意识到他们竟然随意搞砸了我们的仓库。”

中断从未停止

周一（4月27日），GitHub网页界面上的拉取请求和议题消失了：

这与GitHub后端的Elasticsearch中断有关：集群过载并宕机。因此，虽然拉取请求、议题和项目并未完全消失，但在长达6小时的中断期间，它们也无法显示。

本周还发生了其他中断：

• 部分拉取请求未显示（周二，4月28日）
• 部分GitHub Actions出现问题（同一天）
• 仓库中的拉取请求不完整（周三，4月29日）

同样在周二（4月28日），安全公司Wiz披露了一个严重安全漏洞，攻击者仅需使用一个git push命令即可访问GitHub和GitHub Enterprise Server上的所有仓库。GitHub在六小时内修复了GitHub.com上的问题，但未更新的GitHub Enterprise服务器仍然存在漏洞。

著名开源贡献者因沮丧而离开GitHub

周二，HashiCorp创始人、Ghostty创建者Mitchell Hashimoto宣布GitHub不适合专业工作，他将转向其主要关注的开源终端Ghostty。Mitchell的理由非常简单：使用GitHub让他无法高效工作（强调为我所加）：

“过去一个月，我一直在写日记，每当GitHub中断对我的工作能力产生负面影响时，我就会在日期旁边打个‘X’。几乎每天都有一个X。在我写这篇文章的那天，因为GitHub Actions中断，我大约有两个小时无法进行任何PR审查。如果它每天都要让你中断几个小时，那么这里就不再是进行严肃工作的地方了。

这对我来说不再是有趣的去处了。我想去，但它不想让我去。我想完成工作，但它不想让我完成工作。我想发布软件，但它不想让我发布软件。

我希望它变得更好，但我也想写代码。而我无法再与GitHub一起写代码了。对不起。18年后，我必须离开。我希望能有一天回来，但这必须基于实际的成果和改进，而不是空话和承诺。”

Mitchell的经历表明，从像他这样的重度用户角度来看，GitHub的官方状态页面是不准确的。第三方的“缺失GitHub状态页面”可能是更准确的评估：GitHub的可靠性为零个“9”，仅为85.51%的正常运行时间。这意味着在过去90天里（!!），GitHub的一部分平均每天宕机2-3小时。

Mitchell的抱怨听起来很直接：

1. 作为专业软件工程师，拥有能帮助完成工作的工具很重要
2. 几个月来，GitHub通过一系列中断阻碍了他参与开源项目的工作
3. 使用一个不适合专业工作的产品毫无意义。
4. 由于GitHub没有显示出改进的迹象，转向另一个确实有效的解决方案是值得的

CTO将负载激增归咎于AI代理

GitHub首席技术官Vlad Fedorov分享了一篇更新，解释了为什么GitHub的可靠性几个月来一直很差。他确定代理产生的负载远大于预期是罪魁祸首。GitHub分享了说明此情况的图表：

这个图表看起来很引人注目——但有一个小问题：没有Y轴！所以，虽然它讲述了负载缓慢上升然后急剧增加的故事，但我们不知道增加了多少。不过，我设法从GitHub获取了数据，以下是显示两年实际负载增长的图表：

负载在两年内增加了约3.5倍，乍一看似乎并不那么严峻。这完全不像一个月内负载增加10倍，而且其中很大一部分发生在最近几个月。那么，为什么GitHub无法应对呢？在一篇博客文章中，Fedorov写道：

“一个拉取请求可能涉及Git存储、可合并性检查、分支保护、GitHub Actions、搜索、通知、权限、webhook、API、后台任务、缓存和数据库。在大规模下，小的低效会复合：队列加深、缓存未命中变成数据库负载、索引落后、重试放大流量，一个缓慢的依赖项可能会影响多个产品体验。”

以下是2023年1月和现在的每秒负载数字对比：

GitHub花了15年才达到2023年的数字，也许它预计未来会以类似的方式继续增长。如果是这样，一些关于长期基础设施改进的工程决策可能因为AI代理的到来而过时了。

加剧GitHub挑战的是，该公司正处于从自身数据中心向Azure迁移的过程中。去年10月，GitHub开始迁移到Azure——一个预计需要12个月的项目——因为它自身的数据中心容量已受到限制。

即使在服务负载相对稳定的情况下，这种大规模基础设施迁移也足够困难；仅仅确保不出问题就需要付出大量努力。但在负载激增时进行迁移意味着漏洞可能导致更明显的中断。当然，既然GitHub现在知道了预期情况，他们可以在Azure上确保获得更多的计算资源。

但其他大公司为基础设施负载增加10倍做好了准备，为什么微软/GitHub没有？一年前，我研究了大型科技公司如何准备应对AI对其业务的影响。谷歌正在改进其内部系统以适应10倍的负载增长。正如我们去年7月在《实用工程师》中报道的那样：

“谷歌正准备应对代码发布量增加10倍。一位前谷歌站点可靠性工程师告诉我：

“我从SRE朋友那里听说，他们正在准备应对进入生产环境的代码行数增加10倍。”

如果任何公司拥有AI工具可能影响的数据，那就是谷歌。生成的代码增加10倍，可能也意味着代码审查、部署、功能标记、源代码控制足迹，甚至漏洞和中断也增加10倍，如果不谨慎处理的话。”

关于预测的巨大负载增长并非行业内的秘密知识，但GitHub似乎天真地忽视了其潜在规模。根据Vlad的说法，GitHub确实最终计划需要将容量增加10倍，但那是在2025年10月，晚了几个月。在2026年2月，该公司现在将该预期调整为30倍。他写道：

“我们于2025年10月开始执行将GitHub容量增加10倍的计划，目标是大幅提高可靠性和故障转移能力。到2026年2月，很明显我们需要为一个需要当前规模30倍的未来进行设计。”

还有一个问题是，GitHub是否错误估计了它为应对爆发式负载增长所做的准备时间，以及它是否在今年年初增长比预期提前几个月实现时措手不及。

鉴于GitHub直到10月才开始为重大负载增长做准备，其当前问题不足为奇。在GitHub的规模下，拥有服务的每个团队提前一年规划其服务将有多少负载是常见的做法，硬件资源（如存储、虚拟机和网络）据此进行分配。负载规划可能占准备工作的一半，当现实不符合计划时，某些系统可能难以扩展。

所以，一方面，对于大多数服务来说，应对两年内3.5倍的负载增长不应该是太大的问题；尤其是那些可以水平扩展的服务（当状态不多时，只需添加新节点即可实现扩展）。但GitHub可能存储了大量带有拉取请求、工作流、项目等的状态。这可能使得数据库和运行工作流的系统在扩展方面更为棘手。

GitHub还面临18年的技术债务，以及数千名员工作为“组织开销”需要协调。随着其服务负载以前所未有的速度增长，由于所有这些累积的“债务”，响应变得更加困难：

• 技术债务：公司的许多系统已有10多年历史，可能是修补过的，使其更难以更改且风险更高
• 组织债务：GitHub约有4,000名员工，其中1,000名是工程师。团队之间相互依赖，即使是看似简单的工作也可能需要数十名工程师协同完成
• 客户期望：GitHub不能破坏客户的工作流，即使这样做意味着系统可以更快地进行更改

GitHub发现自己处于“创新者的窘境”中：该公司之所以成功，是因为它构建了在AI之前就合理的开发者工作流，并且过去能够准确预测服务负载变化。但现在工程团队的工作流包括AI代理，GitHub自身的工作流不一定最合适，而且该公司未能预测服务级别的变化。

其他厂商也因AI负载而崩溃？并非如此

这种情况中有一点不合逻辑：其他可能经历类似负载激增的厂商似乎并未像GitHub这样受可靠性问题困扰。Vercel、Linear、Resend、Railway、Sentry和其他基础设施提供商因AI而看到创纪录的增长，但能够跟上负载。

是的，像Anthropic、OpenAI和Cursor这样的AI厂商确实存在一些可靠性问题，但并非GitHub这样的规模。GitHub的直接竞争对手GitLab和Bitbucket，估计负载增长类似，但它们宕机的次数并没有那么多。

一个明显的问题是，GitHub有多少痛苦是自找的？拥有微软作为所有者，它拥有的资源比任何竞争对手或初创公司都多，但未能预测负载增长，并且规模太大而无法像初创公司那样灵活应对。

不可否认，解决重大负载增长是一个艰巨的挑战；这正是平均水平和杰出工程团队之间的区别所在。GitHub的应对方式不像一个世界级的工程组织。

GitHub的替代方案？

每一位GitHub的常用户都感受到了持续中断的痛苦。作为开发者，你可以希望微软最终会提高可靠性，或者寻找替代方案。如上所述，Mitchell选择离开，目前正在决定将Ghostty带到何处。

明显的替代方案是GitHub最大的竞争对手，GitLab和Bitbucket。每个都提供Git托管，且都没有GitHub正在经历的正常运行时间困扰。

自托管解决方案也是一个选择，例如自托管你的git仓库，或使用自托管平台，如Forgejo，一个开源的、本地优先的GitHub替代品。

我也怀疑，很快我们会看到初创公司提供类似GitHub的代码托管功能，同时提供更可靠的正常运行时间，并设计成能够处理GitHub希望有一天能支持的30倍或更高规模。

阅读上周《脉搏》的完整版，或查看本周的《脉搏》。本周议题涵盖：

1. Anthropic是否因容量不足而对开发者态度转变？
2. 亚马逊最终允许使用Claude Code和Codex
3. Meta在裁员前强制分配工程师进行数据标注
4. 新趋势：小型“AI优先”团队
5. 行业脉搏：为何Meta跟踪员工电脑活动，OpenAI开始从Datadog迁移，苹果不小心透露使用Claude Code，微软GitHub到Xbox的人员调动，VS Code即使Copilot未贡献也插入“由Copilot合著”，Coinbase裁员分析

由 mimo-v2.5 模型翻译，花费 14213 tokens

大家好，我是Gergely，本期是《务实工程师通讯》的免费特刊。每期我都从资深工程师和工程领导者的视角，探讨大型科技公司和初创企业的话题。今天，我们聚焦于上周《脉搏》专栏三个主题中的一个。完整订阅用户七天前已读到下文内容。如果您是通过转发收到此邮件，可以在此订阅。

上周，我们报道了行业内一种略显扭曲的“token最大化”趋势：开发者运行AI代理的唯一目的是提升个人“token数据”，以期在内部排行榜上排名更高，并避免被视为相比同行更少使用AI工具的卢德分子。

本周，我与一家大公司和一家种子轮初创公司的软件工程师进行了交流。两人几乎分享了相同的经历：在他们最近的全体会议上，公司领导层对飞速增长的token成本表示担忧。两地的token支出在过去六个月内都增长了约10倍——且没有放缓迹象。

为深入了解这一趋势，我采访了15家企业的开发者。以下是我在各种规模的工作场所中了解到的情况（名称已匿名）。

大型公司

将默认模型设为更便宜版本：员工超1万人、办公室遍布各大洲的SaaS公司

在这家大型SaaS公司，大多数开发者使用内部背景编码工具进行编程。该工具默认使用Claude Sonnet，这是Claude更便宜的版本。模型选择不会被持久化保存，因此偏好使用Opus的开发者必须在每次启动后重新选择。

该工具支持所有主要前沿模型，如Sonnet、Opus、GPT和Gemini。我所交谈的该公司开发者都是该工具的重度用户，且未遇到使用限制。

金融科技公司，美国，D轮融资，约8000人。首席工程师：

“token支出的成本高得惊人——领导层已向我们展示了这一趋势。他们除了展示支出增长并提及这不会可持续之外，没有多说。所以，目前还没有具体措施，但我感觉有些事情必须改变。设置限制、优先选用更便宜的模型、还是减少招聘？谁知道呢。”

基础设施公司，美国，上市公司，约5000人。工程总监：

“我们正在监控，但未限制。我们对使用量最大的用户进行抽查，但我们看到业务案例是可行的。

我们提供了一些模型选择指导——例如，关闭Claude中新的高耗能设置。一些用户正在尝试开源模型——但开源模型的使用是自下而上的倡议，而非自上而下推行。”

信息技术行业，美国，1万多人。工程总监：

“我们不得不在4月多次提高API预算限额。我们最近将Claude切换到了更高的耗能级别，这显著增加了每个PR的成本。

成本飙升的原因之一是使用最先进模型处理高要求任务。我们将这种高耗能设置甚至用于相当简单的任务，而这些任务本可由更便宜的模型或更低耗能的Claude循环处理。尽管我们几个人指出了这点，但领导层基本上表示目前预算不是问题。

我感觉预算增加并未纳入预测，我们即将面临清算。我怀疑当财务部门和组织内其他注重成本的部分意识到我们每天、每位高投入开发者花费数百美元时，态度就会改变。目前，对错失良机（FOMO）和不愿落后的担忧似乎压倒了成本纪律。”

游戏工作室，美国+欧洲，约5000人。高级开发者：

“什么预算增加？在这里为AI争取预算非常困难！Claude Code仍未推出，因为每月每开发者200美元被认为成本太高。我与初创公司的人交流，他们每月花费1000美元是完全正常的，这里的情况与他们天差地别。”

金融科技公司，美国+欧洲，后期阶段，约5000人。首席工程师：

“一些开发者现在每天在Claude Code上花费500美元（！！！）。实际上，这意味着员工成本翻倍了。在我看来，生产力提高了，但现在瓶颈在于代码审查。AI能很快生成代码，但我们仍然保留人工审查。领导层鼓励使用AI进行代码审查，但我的团队不会盲目信任AI。

AI的推行来自高层。今年的绩效评估中有一个关于AI的部分，根据开发者使用AI的好坏进行评级，这是每个人尽可能多地使用AI的另一个原因。”

中型公司

SaaS行业，美国，约2000人。开发者生产力负责人：

“模型路由帮助我们的成本增长不那么剧烈。例如，更改默认模型使成本降低了30%。这是我们AI支出策略的总结：短期：投入、投入、再投入！尝试并使用任何有意义的模型。衡量影响。衡量关键成果并按月报告支出。当支出与结果出现分歧时：调整。当我们的支出急剧增加，但成果未随之而来：看看我们能做些什么来调整差距。更多的支出应意味着更好的成果。如果不是，那我们做错了什么。”

金融行业，美国，约2000人。AI副总裁：

“我们使用Cursor和Claude Desktop，两者各有约800-1200名用户。Token使用量的增长有些出乎意料。估计值正在动态调整；最初严格限制（例如每用户100美元）的计划在面对现实时正在被打破，人们在3-5个工作日内就用完了额度。

使用昂贵的模型是一个问题。关于Cursor，许多开发者默认使用最昂贵的模型，而没有意识到使用Opus相比Sonnet等在智能上只有百分点的提升，却几乎立即耗尽预算。

我们正在努力屏蔽/管理最昂贵的模型[在Cursor中]，因为每月每用户数千美元在我们的规模下是不可持续的。Cursor是很好的合作伙伴，我们正与他们合作切换到“共享支出”模式，让重度用户可以动用额外支出池。

Claude情况类似。我们为所有人设置了100美元的Claude Desktop限额，但随着推进，我看到对于关键业务用例，我们需要高得多的限额。”

基础设施公司，美国，后期阶段，约700人。创始人：

“我们没有遇到太大问题。大多数人对失控成本进行自我监督；例如，我们有人因为缓存搞砸了一周花费约1万美元，但被发现并纠正了他们的设置。

在大多数情况下，我们没看到我们的高级人员每周花费超过约1000美元。需要明确的是，这不是一个小数目！但这已经是一小部分人群了。

我们现在只是将其计入工程成本：如果每月每员工花费2000美元，那就是每年24000美元。

那么，在工程师的现金薪酬已达20万至40万美元/年的情况下，谁在乎呢？好吧，如果是每月5000美元呢？那就是每年6万美元。

我们的赌注是token成本将稳定下来，我们最终将拥有本地化模型。

现在，可能需要五年才能稳定下来，但总体而言，目前的支出对我来说并不那么疯狂。

有很多人在这件事上很愚蠢，但大多数认真的高管会抵制。比如那些“Ralph循环”或其他疯狂行为，有人每天花1000美元，每周5000美元之类。这都只是人们在犯傻，以为自己在做“研发”，或者自以为比所有人都聪明，但他们只是在产出从未发布或毫无用处的垃圾。

我们在头几个月看到了一点“愚蠢的过度支出”，但现在都消失了。如果我们想看到更多产出而“严格要求”，成本可能会进一步上升，但我们不会那样做。”

医疗保健行业，美国，约500人。高级工程经理：

“我们不限制支出，并且有每月支出排行榜。我们鼓励开发者在token上花费更多！例如，我的一名工程师在一次长时间的Claude Code会话中一天就花费了1400美元。

我们看到了巨大的杠杆效应，用相同数量的人做了更多事情。这就是为什么我们对支出飙升感到无所谓。我们的流量同比增长超过10倍，我们设法保持业务运行，团队规模不变，依靠这些AI工具。

工程现在被产品和设计阻塞了——这从未发生过！这就是执行速度有多快。我们现在有资深工程师撰写产品PRD，以便我们能更快推进。

我在科技行业工作了近15年，从未见过如此剧烈的变化。我刚休完3个月的假回来，我日常工作中的每一件事都不同了！我感觉这些AI代理是自高级语言普及以来行业最大的变革。”

电子商务公司，美国和欧洲，约2000名开发者。工程负责人：

“支出的增长是疯狂的。这是使用量上升，且没有停止迹象。使用量高得惊人。

我们目前没有设置限制，现在也不会暂停。我们的CEO是AI信徒，不会让我们慢下来。

我们购买token有折扣。折扣从5%开始，随着与我们使用的供应商（那些常见的大牌）的用量增加而提高。

我们不允许开发者使用低于Opus 4.7的模型进行编码。更便宜的模型可能效果更好，但一点点错误推送到生产环境都会导致数小时的苦工。”

小型公司

A轮融资，美国，约50人。首席工程师：

“大约15名开发者是AI的重度用户，成本上升非常快。几乎所有人都使用Claude和Claude Code。我们正在考虑四个潜在选项：增加AI预算，并开始更多衡量。继续我们目前的做法，但允许开发者使用更多token，而非设置招聘限制。确切的ROI难以量化，但我们将开始衡量和追踪AI的采用率和影响。优化token消耗。在简单任务上使用更便宜的模型，审查token使用情况，看看哪里可以削减使用。缺点：这种方法可能很快就会收益递减。在公司内整合更多AI提供商。寻找封装LLM的工具。问题是：你如何替换Claude Code？转向本地模型：例如Kimi、Qwen等。问题是在高端硬件或云端GPU上投资巨大。优点：一旦完成，能提供更好的长期成本控制。

我们可能会选择选项1：增加支出但保持势头，并建立正确的衡量标准。我们可以稍后做选项2、3和4。但如果我们扼杀了公司内部使用AI的势头，结果可能更糟。”

AI基础设施，美国，种子轮，约15人。创始人：

“我们在6个月内看到了15倍的增长：六个月前，我们每位开发者的支出约为每月200美元，今天，对于我们的七名开发者，大约是每月每开发者3000美元，我们不会放慢使用，尤其是我们正在构建AI基础设施产品。不过，增长速度远超预期。”

小型自力更生公司，欧洲。创始工程师：

“我们应对成本增长的当前策略是切换到更便宜的模型；不幸的是，在我们这里是Opus换成Sonnet。话虽如此，Sonnet相当不错。”

企业如何管理token支出

无论公司规模大小，似乎都有两种策略来应对支出增长。总结如下：

策略一：“放任使用，开始衡量。”大约一半的受访者表示AI支出急剧上升，他们决定暂不采取任何措施。他们希望开发者在有意义的情况下尽可能多地使用AI，并尽可能帮助工作。

然而，由于成本急剧上升，这些公司现在开始衡量使用量，并试图评估其AI工具的影响。

有几家公司的影响似乎已经非常积极。客户数量、负载和收入都在爆炸性增长的小型初创公司发现，他们不需要招聘更多员工，因为现有工程师可以依靠AI工具来支持增长。

策略二：抑制支出。常见的节约成本方法包括：

• 在简单任务上使用更便宜的模型
• 将默认模型设为能力较弱的版本
• 设置支出上限，使工程师难以超出，或要求超支需获得批准

大多数采用策略一的公司曾短暂考虑过策略二，但放弃了，因为他们认为这是优化错了方向：在知道使用最先进工具的生产力影响之前就削减成本！

当支出达到数百万美元时，可获得折扣。我询问了几个人，在大量购买token时是否从供应商那里获得了折扣。没有具体数字，但我综合了关于可能定制协议的以下信息：

• Cursor：对超过数百万美元的支出开放折扣。公司在支出超过100万美元后与Cursor协商了折扣。一些公司从该级别开始协商分级折扣，从5%开始，随着支出增加而提高。
• Anthropic：无折扣。我与一些每年在Claude上花费超过500万美元的公司交谈过，他们没有获得任何折扣。如果Anthropic提供折扣，很可能在更高的层级。
• 所有折扣都是定制的，所以可以尝试协商——这是免费的！定价折扣是按客户定制的。查看是否有折扣最简单的方法就是询问供应商！

——

阅读上周《脉搏》的完整内容，或查看本周的《脉搏》。本周涵盖：

1. AI负载导致GitHub宕机——但其他供应商为何没事？GitHub的可靠性低于一个9（90%），并且还在恶化。高产的开源贡献者Mitchell Hashimoto正在退出GitHub，因为他认为它不适合专业工作。GitHub领导层将服务负载增加3.5倍作为性能下降的原因——或者这可能是自作自受。
2. Anthropic的信任速朽之路。直到最近，Anthropic还无可挑剔，但在过去一个月里，一切都变了。悄悄削弱Claude Code、封禁公司使用Claude、以及令人困惑的涨价，都加剧了Anthropic处于其“榨取”时代的印象——以相同或更差的服务赚取更多收入。
3. 行业脉搏。GitHub Copilot大幅涨价、Codex爆发式增长、谷歌急于构建优秀的编码模型、Cursor可能被SpaceX收购、AI代理删除汽车业务等。
4. Mitchell Hashimoto与“积木经济”。Ghostty的创建者发现，开源“积木”是通过软件组件赢得大规模采用的最佳方式——但基于开源积木构建业务变得更难了。

由 mimo-v2.5 模型翻译，花费 9325 tokens

大家好，我是Gergely，这是《务实工程师》通讯的一期特别免费版。在每一期中，我都通过资深工程师和工程领导者的视角来探讨大型科技公司和初创公司。今天，我们涵盖上周《脉搏》中的四个话题之一。完整订阅者已于七天前收到下文。如果您收到了转发的这封邮件，可以在此订阅。

在Meta内部，一位工程师创建了一个“代币排行榜”，根据代币使用量对员工进行排名。上周，《信息报》报道称：

“Meta平台的员工若想炫耀其AI超级用户能力，正在内部排行榜上争夺“会话不朽”——或更高级的“代币传奇”地位。

该排名由一名Meta员工使用公司数据在其内部网上设立，衡量员工消耗了多少代币——AI模型处理的数据单位。该排行榜被称为“Claudeonomics”（以AI初创公司Anthropic的旗舰产品命名），汇总了超过85,000名Meta员工的AI使用情况，列出了前250名高级用户。

这种做法是硅谷最新炫耀性消费形式的象征，被称为“tokenmaxxing”，它已将代币使用量转变为生产力的基准，以及衡量谁最具AI原生性的竞争指标。工人们正在最大化他们的提示、编程会话和并行工作的代理数量，以在Meta和其他公司内部排行榜上攀升，以此证明他们在AI自动化编码等功能中的价值。”

我和Meta的几位工程师聊了聊正在发生的事情，他们这样说：

• 巨大的浪费。 大量开发者运行着类似OpenClaw的内部代理，消耗大量代币却几乎没有任何产出。
• AI过度使用导致宕机。 一位开发者提到，一些严重事件是由看似粗心的AI代码生成引起的；就好像事件背后的开发者更关心用AI大量生成代码，而不是产品质量。
• 游戏化的排行榜。 排行榜上靠前的人产出的是一次性、浪费性的工作。这对任何查看轨迹（AI提示）的人来说都是显而易见的，而轨迹是可以查看的。

根据《信息报》，Meta员工在30天内总共使用了60.2万亿AI代币（！）。如果按Anthropic的API价格收费，这将花费9亿美元。当然，Meta很可能以折扣价购买代币，但这仍可能达到1亿多美元——很大程度上是由于无意义的“tokenmaxxing”。在社交媒体的反弹后，Meta上周废除了内部排行榜。在《信息报》披露了令人难以置信的tokenmaxxing数字细节的第二天，我确认Meta已移除其排行榜；或许他们意识到这种激励造成了巨大且不必要的浪费。如果是这样，这家社交媒体巨头得出这个结论竟然需要媒体报道，这有点令人惊讶。

Meta的一位工程师告诉我，他们认为Meta对代币排行榜有不同的目标。 一位资深工程师怀疑，增加AI使用量实际上才是真正的目标。他们说：

“设立排行榜总是会激励更多的AI使用。而更多的AI使用意味着产生大量真实世界的追踪数据。然后这些追踪数据可用于更好地训练Meta的下一代编码模型。

我相信这就是目标，即使没有人公开说出来。

这是一种昂贵的生成训练数据的方式，但如果任何公司有财力这样做，那就是Meta。”

微软：全力tokenmaxxing

类似地，微软自1月份以来也设有一个类似于Meta的内部代币排行榜，并且效果相当不错，正如我当时报道的：有一个内部代币仪表板，显示使用最多代币的个人，以推广代币的使用和对大型语言模型的实验。在这家Windows制造商，这个排行榜很有趣：

• 非常资深的工程师——杰出级别的员工——位列全公司前5名，尽管这个群体过去通常很少编写代码。
• 副总裁级别的员工进入了前10和前20名，尽管他们经常整天开会，很少写代码。

然而，开始时作为绩效评估或晋升的指标，很快就会成为开发者的目标。我和这家Windows制造商的一位软件工程师交谈过，他承认自己完全在“tokenmaxxing”——不是为了上排行榜，而是因为他不想被看作使用太少代币：

“我们有内部仪表板和指标跟踪AI使用情况、代币使用量、AI编写的代码百分比与手写代码的百分比。

我意识到不想被看作‘使用AI太少’，我不羞于承认我需要通过tokenmaxxing来做到这一点。我用来虚增代币使用量指标的方法：向AI询问关于文档中已有代码的问题。AI调出文档，处理它，并给我结果，速度慢10倍，但同时消耗大量代币。我可以使用‘readthedocs’[内部产品]，但那样我的代币数字就会变低让AI原型化一个我并不打算工作的功能。给它提示几次，然后把整个东西扔掉即使我知道手动完成工作更快，也默认始终使用代理。然后看着它失败。”

这位工程师相对较新，因此担心工作保障，正在玩这个游戏，通过消耗远超必要的代币来避免被贴上不够“AI原生”的标签。

销售力：消耗代币以达到“最低”和“理想”目标

在其他地方，销售力也创建了“tokenmaxxing”激励措施。 通过与一位工程师交谈，我了解到该公司构建了两个工具，实际上激励了代币的过度支出：

1. 带有跟踪工具的“最低”激励措施。 有一个Mac小组件显示你自己的支出，每15分钟更新一次。它还显示最低预期支出。上周，目标是在Claude Code上花费100美元，在Cursor上花费70美元。
2. 显示每个人的支出。 一个基于网页的工具可以查看任何同事的代币支出。它用于检查队友的使用情况。
3. 可以超过的“最大”支出限制。 直到上周，Claude Code每月还有250美元、Cursor有170美元的最大限制。*然而，如果达到限制，只需按一个按钮就可以超过。我了解到上周，销售力的一些工程组织移除了“最大”限制，以“消除开发过程中的任何阻力”。*

销售力向员工发出的信息很明确：“每月至少使用170美元的代币，否则会被标记。”谁愿意因为使用代币太少而被标记？结果是某种程度上浪费的代币支出：

• 白白消耗代币。 开发者向Claude或Cursor提问：“为我构建X”，其中X是一个与他们的工作无关的项目或产品，也不是他们会发布的东西。这只是消耗代币的一种方式
• 将代币支出调整到略高于平均水平。 许多开发者浏览同行的代币支出，以确定略高于平均水平的点，然后使用所需代币达到该标准

Shopify：避免tokenmaxxing的范例

据我所知，第一个代币排行榜是由Shopify在2025年创建的。而且效果很好！去年6月，Shopify的工程主管Farhan Thawar在务实工程师播客中告诉我：

“我们有一个排行榜，我们积极庆祝使用最多代币的人，因为我们希望确保如果他们用AI做出了出色的工作，就会被[庆祝]。

[对于排行榜上的顶尖者，]我想看看为什么他们每月花费1000美元在Cursor的额度上。也许是因为他们正在构建一些伟大的东西，而且他们手下有一个代理团队！”

我向Farhan询问了自那以后情况的详细信息。他告诉我：

“我们随后将代币排行榜更名为使用情况仪表板：出于显而易见的原因，因为我们不想鼓励‘竞争’以登上该榜单。我们的代币支出显示在内部维基个人资料和使用情况仪表板上。

我们还设置了断路器来捕获‘失控的代理’。 因此，如果个人支出在一天内激增，我们可以立即切断访问权限，你可以重新激活，如果使用量激增是故意的，或者它是失控的代理。断路器对我们很有用：我们不仅捕获了失控的代理，还以此发现了基础设施中的错误！”

Shopify的方法似乎在几个方面取得了成功：

• 使用情况仪表板早期起到了推动开发者使用AI工具的作用。 去年，开发者主要是在试验AI工具，因为它们的性能不如现在。使用情况仪表板鼓励开发者尝试新工具，并突出了高级用户。
• 断路器帮助了。 当使用量激增时切断支出有助于捕获“失控的代理”。
• 高使用量会被查看。 Farhan会与支出最高的个人沟通，了解使用情况。任何tokenmaxxing行为很可能在这个阶段就会被发现，这对用户来说会有点尴尬！

Farhan与我分享的另一个有趣的见解：与其关注“谁在*总*代币成本上花费最多？”，不如关注“谁的*代币*成本最高？”。生成昂贵代币的开发者被证明是做了深入的工作，了解这些工作很有趣！

Tokenmaxxing：对AI供应商有利，对其他所有人都不利

我认为很少有理性理由认为激励tokenmaxxing对任何公司有意义。它导致AI支出——大幅增加！——而回报却很少或没有价值。见鬼，在某些情况下，它实际上激励了更慢的工作——正如开发者使用AI回答文档中已有问题所显示的那样——并鼓励‘忙碌工作’，开发者提示他们甚至不想发布的项目。Tokenmaxxing似乎推动开发者专注于对业务毫无意义的事情。

在我看来，行业很大一部分使用代币计数数字的方式类似于多年前使用代码行数（lines-of-code）指标的方式。曾经有一段时间，每天或每月编写的代码行数是衡量程序员生产力的重要指标，直到人们意识到这是一个糟糕的关注点。代码行数指标很容易通过编写样板代码或一次性代码来操纵。此外，最好的开发者不一定是写代码最多的人；他们是那些能够快速可靠地解决业务难题的人——无论是否使用代码！

同样，开发者生成的代币数量很容易被操纵，如果这个指标被衡量，开发者确实会操纵它。但这样做会产生巨大的伴随AI账单！

—

阅读上周《脉搏》的完整内容，或查看本周《脉搏》。本周内容涵盖：

1. 新趋势：代币支出突破预算——接下来怎么办？ 在过去2-3个月里，许多科技公司对AI代理的支出激增，工程领导者开始意识到其影响。我们从15家公司收集了细节，包括他们应对这一认识的不同方式。
2. 新趋势：更多AI供应商无法满足需求。 与支出大幅增加相关，GitHub Copilot和Anthropic开始限制利润较低的个人用户，以便服务企业用户，这些用户的支出在过去几个月里轻易增长了10倍。例外是OpenAI和Codex。
3. Meta士气跌至历史低点？ 业务蓬勃发展，但Meta的开发者因即将发生的裁员以及针对所有美国员工推出的侵入性跟踪计划而愤怒和担忧。

由 mimo-v2.5 模型翻译，花费 7310 tokens

大家好，我是 Gergely，这是 Pragmatic Engineer 新闻通讯的一期额外免费刊。在每一期中，我都从高级工程师和工程领导者的视角来探讨大型科技公司和初创企业。今天，我们讨论的是上周《脉搏》期刊四个主题中的一个。完整订阅用户在八天前就收到了下面这篇文章。如果您收到了这封转发的电子邮件，可以在此处订阅。

我们已经习惯了追求四个九（99.99%，意味着每年约 52 分钟停机时间）的高可用性系统，并且认为勉强达到三个九（每年约 9 小时停机时间）是令人尴尬的。然而，在过去的一个月里，GitHub 的可靠性已经跌到了只有一个九！

以下数据来自第三方 "缺失的 GitHub 状态页"，该页面是在 GitHub 因其糟糕的可用性而停止更新自身状态页后建立的。最近的情况看起来很糟糕：

这意味着，在每 30 天里，GitHub 有 3 天出现问题，或者说每天有 2.5 小时的问题/性能下降（大约占 10% 的时间）。

GitHub 似乎无法跟上代理（agents）带来的基础设施负载的巨大增长。一位软件工程师构建了一个巧妙的网站 "Claude's Code"，用于追踪 Claude Code 机器人在 GitHub 上的贡献。过去三个月的增长非常巨大：

因基础设施过载导致的 GitHub 中断流

GitHub 的首席技术官 Vladimir Fedorov 在一篇博客文章中回应了可用性问题，并涵盖了三个主要事件：

• 2 月 2 日：安全策略无意中阻止了访问虚拟机元数据
• 2 月 9 日：一个数据库集群过载
• 3 月 5 日：一个 Redis 集群的写入失败

软件工程师 Lori Hochstein 对这些中断事件和首席技术官的回应进行了有益的分析，并有一些有趣的观察：

• 饱和度：2 月 9 日的数据库集群事件是由于使用量高于预期而导致数据库饱和。数据库比无状态服务更难扩展。GitHub 还低估了额外流量的程度。
• 故障转移 + 遥测缺口：2 月 2 日的事件是基础设施在一个区域出现故障后切换到健康区域，并因遥测缺口而使情况恶化（在新区域中应用了不正确的安全策略，阻止了对虚拟机元数据的访问）。
• 故障转移 + 配置问题：3 月 5 日的事件非常相似：在故障转移后，配置问题阻止了 Redis 集群的写入。

GitHub 能提供这些中断事件的详细信息当然很好。我的感觉是，基础设施压力导致了更多的基础设施问题 → 它们更快地触发了限制条件 → 故障转移不如应有的顺利。这是不是因为 GitHub 不断地更改其现有系统？

初创公司向 GitHub 展示如何做到

当 GitHub 难以跟上 AI 代理生成更多代码和拉取请求所带来的负载增长时，一家名为 Pierre Computer 的新初创公司声称已为 AI 代理推送代码构建了一个可扩展性远超 GitHub 的 "AI 原生" 解决方案。Pierre 由 Jacob Thornton 创立：他曾是 Coinbase、Medium 和 Twitter 的工程师，也是曾经非常流行的 Bootstrap CSS 库的创建者。

以下是 Pierre 支持而 GitHub 不支持的功能：

"在 [2025 年] 10 月，GitHub 分享称他们平均每分钟新增约 230 个仓库。

上周，我们（在 Pierre Computer）达到了持续 3 小时的峰值，每分钟超过 15,000 个仓库。

并且在过去的 30 天里，客户创建了超过 900 万个仓库。"

这些数字令人难以置信——虽然也是自我报告的——而 GitHub 显然无法接近这个水平，至少目前是这样！关于客户的信息很少，而这款名为 Code.storage 的产品似乎处于封闭测试阶段。

不过，这正是 GitHub 未能构建的那种 "AI 代理的 git"，也是它迫切需要的那种基础设施。

GitHub 是否失去了焦点和目标？

GitHub 的可靠性问题已经非常严重，如果持续下去，团队将开始尝试 Pierre 这样的小公司的替代方案，甚至可能考虑自托管 Git。但是，这个世界上最大的 Git 托管商是如何忽视其客户，并未能为其基础设施做好准备，以应对代码提交和拉取请求的增加呢？

Ghostty 的创始人 Mitchell Hashimoto 本人也是 GitHub 的重度用户，在对 GitHub 核心服务的现状感到沮丧后，他对如果由他掌管 GitHub 会怎么做提出了建议。他写道（强调部分为我所加）：

"如果由我掌管 GitHub，我会按以下顺序做：

1. 围绕成为智能体（agentic）代码生命周期关键基础设施，制定一个北极星计划，并确定一组衡量该计划的方法。

2. 解雇所有从事或支持 Copilot 工作的人员，并关闭它。这不是针对人的问题，我相信其中有很多人才；你只是在错误的公司工作。

3. 收购 Pierre 并推出智能体仓库托管服务，作为首个智能体产品。仓库将与遗留的 Web 产品分离，因为它们可能承载着遗留的跨产品交互负担。

4. 根据新的北极星重新评估所有产品线和计划。我猜 50% 会被砍掉（为不同的产品腾出空间）。

核心思想是所有智能体交互都应该关键性地依赖 GitHub API。代码审查应该是智能体化的，但实验室应该将其构建到 GitHub 中（而不是像今天这样通过 GHA 拼接，要真正的平台一级原语）。GitHub 应该绝对推出一个智能体聊天原语，智能体邮箱显然是好的。GitHub 应该是一个平台，而不是一个智能体本身。

这一点将非常明显地缺乏，因为我只有外部信息可以参考，不知道 GitHub 内部是如何运作的，他们的 KPI 是什么，或者他们定义了什么北极星，等等。

但是，在信息不完善的情况下，这就是我会做的。"

我的感觉是，GitHub 存在三个并行的问题：

• GitHub 和 Copilot 与微软的内部政治纠缠在一起。GitHub 的 Copilot 在 2021 年是第一个取得巨大成功的 "AI 产品"。微软将 "Copilot" 品牌用于其所有产品线，创建了低质量的 AI 集成。与此同时，微软内部的 Azure 和 Microsoft AI 等组织试图插手 GitHub，而 GitHub 是微软最积极的开发者品牌之一。
• GitHub 没有领导者，似乎是设计使然。GitHub 的最后一任首席执行官是 Thomas Dohmke，他自愿辞职，微软从未填补首席执行官的职位；相反，他们进行了重组，使 GitHub 成为微软 AI 集团的一部分，并剥夺了其独立性。看起来 "微软 AI" 一方在那场战斗中获胜了。
• GitHub 没有焦点，并且陷入将 Copilot 作为收入来源的追逐中。GitHub 没有首席执行官，并且陷入了内部政治，所以，GitHub 的团队能做什么？最安全的选择是增加收入，而最好的方法就是将更多资源投入 GitHub Copilot，并忽视可靠性等长期问题。

我同意 Mitchell 的观点：GitHub 没有 "北极星"，我们看到一个大型组织功能失调。缺乏愿景——以及首席执行官——正产生严重影响：

• GitHub Copilot 从 2021 年最常用的 AI 智能体，被 Claude Code 超越，不久后还将被 Cursor 超越。
• 作为一个平台，GitHub 没有如何演进以支持 AI 智能体的愿景。当然，GitHub 有一个 MCP 服务器，但它没有能够处理 AI 智能体产生的巨大负载的 "AI 原生 git 平台"。
• GitHub 不断发布没有方向的小功能和改进。例如，在 2025 年 10 月，他们开始开发堆叠差异（stacked diffs）。然而，当它发布时，堆叠差异工作流可能基本上已经过时了——至少对于 AI 智能体来说是这样！

当你比世界上任何人都更擅长做一件事时，赢得市场很容易。现在，GitHub 做的事情太多，并且在 Copilot、其平台和 AI 基础设施方面都做得不够好。

阅读上周《脉搏》的完整内容，或查看本周的《脉搏》。

了解近期 Pragmatic Engineer 的内容：

• 与 Thuan Pham 一起扩展 Uber（Uber 首任首席技术官——播客）。我们探讨了将 Uber 从不断发生故障扩展到全球基础设施、向微服务和平台团队的转变，以及 AI 如何重塑工程等话题。
• 与 Jean Lee 一起构建 WhatsApp（播客）：Jean Lee，WhatsApp 的第 19 号工程师，讲述了如何用一个小团队扩展应用、Facebook 的收购，以及这如何揭示工程的未来。
• 首席工程师角色在 2027 年及以后会是什么样子？？当智能体编写更多代码时，首席工程师角色会发生什么变化？实际上，他们可能比以往任何时候都更受欢迎！

由 mimo-v2.5 模型翻译，花费 8510 tokens

嗨，我是Gergely，这是《务实工程师通讯》的一期免费增刊。每期我都通过资深工程师和工程领导人的视角来探讨大型科技公司和初创企业。今天，我们探讨上周《脉搏》版块四个主题中的一个。《脉搏》上周版块的完整内容已提前七天发送给付费订阅者。如果您收到了这封转发邮件，可以在此订阅。

《华尔街日报》报道了一个有趣的趋势：企业希望招聘FDE（前线部署工程师）岗位，但开发者们对此并不太感兴趣：

“根据AlphaSense的数据，2025年Indeed上的相关职位发布量比2024年增长了十倍以上。同期，提及该职位的上市公司财报电话会议记录数量也从八份跃升至五十份。

唯一的问题是？很少有工程师想要这份工作。这份工作历来被认为要求苛刻、不受欢迎，且声望低于以产品为核心的工程岗位。

“每个公司都想要他们，但可能只有10%的市场对这个职位感兴趣，” Betts Recruiting的总裁兼首席运营官帕特里克·凯伦伯格（Patrick Kellenberger）说。“

去年夏天，我们曾探讨过FDE角色的兴起，并审视了其工作内容。当时，我这样描绘这个当时非常热门的角色：

在我采访过的OpenAI和Ramp等公司的FDE人员中，这个角色似乎符合这种描绘。然而，我后来与两位接受了FDE职位但感到失望的工程师交流过。这是他们实际情况中的看法：

这个角色类似于“销售工程师”，FDE帮助完成交易；或者是解决方案工程师（甚至顾问），FDE被派驻到客户处为其构建解决方案。他们不回馈平台，除了集成产品团队构建的软件外，所做的很少被认为是“软件工程”。

一些工程师在面试过程中就明白了这个角色的性质，从而拒绝了它。而另一些人接受了这份工作，后来却辞职了。以下是一位接受了公司FDE职位但未找到期望内容的开发者告诉我的：

“这份FDE工作是典型的IT服务思维。公司更希望我承担客户沟通负责人的角色，而不是软件开发。这不是我签约时期望的，我也不喜欢那种氛围和文化。我四周后就辞职了。”

在当今的就业市场中，如果一个薪水不错但工程师兴趣不高的职位需求很高，那总是有原因的！

阅读上周《脉搏》的完整版，或查看本周的《脉搏》。

回顾最近的《务实工程师》内容：

• 与Jean Lee共话WhatsApp的构建（播客）：WhatsApp第19号工程师Jean Lee，谈用小团队扩展应用、Facebook收购，以及这对工程未来的启示。
• 《脉搏》：2027年及以后，Staff Engineer角色会是什么样子？ 当AI代理编写更多代码时，Staff Engineer角色会发生什么变化？实际上，他们的需求可能会比以往任何时候都大！
• 从IDE到AI代理，与Steve Yegge对话（播客）：Steve Yegge谈AI如何重塑软件工程、“氛围编码”的兴起，以及开发者为何必须适应快速变化的技艺。

由 mimo-v2.5 模型翻译，花费 4533 tokens

你好，我是 Gergely，本期是《实用工程师》的免费特刊。本期内容是过去一周完整的《脉搏》期刊，付费订阅者在七天前已收到。这篇文章在订阅者中引起了大量讨论，因此我决定更广泛地分享，尤其是因为它引发了关于开源中哪些是可防御的、哪些不是的思考。

如果你是通过转发收到此邮件，可以在此订阅以在邮箱中接收此类期刊。

本期《脉搏》聚焦于单一事件，因为它意义重大并可能产生广泛影响。周二，Cloudflare 惊艳了开发者世界，宣布他们用一位开发者在一周内仅花费 1100 美元代币成本就重写了 Next.js：

这里有多个层面值得探讨：

1. Next.js 生态系统回顾。近一半的 React 开发者使用 Next.js，而部署 Next.js 的最佳平台是 Vercel——部分得益于其专有的构建输出。
2. Cloudflare 对 Next.js 做了什么。用更标准的 Vite 替换了 Next.js 的构建引擎，使得 Next.js 应用能轻松部署在 Cloudflare 上。
3. AI 让不可能变为可能。在工程上需要数年时间的工作，仅用一周和一些代币就完成了。
4. “AI 生成的粗糙内容”仍是问题。与 Cloudflare 的声明相反，vinext 并非生产就绪，需要大量清理和审计才能与 Next.js 相媲美。

1. Next.js 生态系统回顾

首先，提供一些背景。Next.js 是最流行的全栈 React 框架，根据 2025 年 Stack Overflow 开发者调查等最新研究，约半数的 React 开发者在使用它。Next.js 是一个开源项目，由 Vercel 构建并主要维护，也是许多开发者部署 Next.js 应用的首选平台。原因之一在于 Next.js 与 Vercel 的 Turbopack 构建工具高度契合，构建输出是一种专有格式。正如 Netlify 工程师 Eduardo Bouças 所写：

“Next.js 的构建输出采用了一种专有且未记录的格式，用于在 Vercel 部署中配置运行应用所需的基础设施。

这意味着除 Vercel 之外的任何托管提供商都必须基于未记录的 API 进行构建，而这些 API 可能在次版本或补丁版本中引入未预告的破坏性更改。（而且已经发生了）”

Next.js 的构建方式很有趣：所有内容都是开源的，但部署 Next.js 应用的最佳平台是 Vercel，因为它能最高效地运行这些未记录的构建产物。这对 Vercel 而言是明智的策略，竞争对手自然不乐见，因为任何托管提供商都希望 Next.js 产生标准的构建格式。要做到这一点，构建引擎 Turbopack 就需要被更标准的东西替换。

我们来谈谈 Web 开发的构建工具。根据《2025 年 JavaScript 现状调查》，Web 生态系统中最流行的工具是：

1. Vite：由于其速度和开发者体验，成为新项目的首选。底层使用了esbuild和Rollup等项目。
2. Webpack：一个性能不佳但仍广泛用于旧项目的遗留工具。
3. Turbopack：由 Vercel 创建，为大型Next.js应用优化。使用 Rust 构建，旨在提升性能。
4. Bun：一个相对较新的一体化运行时和打包器。Anthropic 于去年12月收购了该团队，部分 Bun 成员现在专注于改进 Claude Code 的性能。

因此，大多数 Web 生态系统使用 Vite 作为构建工具；Next.js 使用 Turbopack，而大多数使用全栈 React 框架的 React 应用都采用 Next.js。基本上，大多数使用 Next.js 的开发者很可能也在使用 Vite 作为构建工具。

2. Cloudflare 对 Next.js 做了什么

这里有一个朴素的想法：如果 Next.js 使用 Vite 来生成构建输出会怎样？那样的话，构建输出将是标准化的，并且可以在任何云提供商上良好运行，因为对 Vercel 没有任何专有或未记录的内容。

而 Cloudflare 做的就是：用 Vite 替换 Turbopack，并将这个新包称为 “vinext”：

公告中稍后才提到这个项目是实验性的，完全不保证能正常工作：这是一个 “风险自担” 的项目。尽管如此，单凭这项开发成果的实现方式，就感觉像在科技界引发了一场地震。

3. AI 让不可能变为可能

在宣布该项目的博客文章中，Cloudflare 声称仅用一位工程师就以轻松部署到 Cloudflare 自身基础设施的方式 “重建” 了整个项目，并且仅花费了 1100 美元的代币。来自 Cloudflare 的声明：

“上周，一位工程师和一个 AI 模型从头重建了最受欢迎的前端框架。其成果，vinext（发音为 ‘vee-next’），是 Next.js 的直接替代品，基于 Vite 构建，可一键部署到 Cloudflare Workers。在早期基准测试中，它构建生产应用的速度最高快 4 倍，客户端包体积缩小多达 57%。我们已经有客户在生产环境中运行它。

整个项目大约花费了 1100 美元的代币”。

Cloudflare 所做的是：

• 采用 Next.js 的公共 API
• 使用 Vite 重新实现了行为
• 创建了行为与 “原始” Next.js 实现相匹配的构建输出

经过 10 年发展，Next.js 的核心约有 194,000 行代码（LOC）**。而vinext大约有 67,000 行代码，这表明其精简得多的实现：例如，vinext 不需要支持旧的 Next API，并且目前支持 94% 的 Next.js API（可以安全地假设他们跳过了剩余 6% 中复杂的边缘情况）。

** Next.js 仓库更接近 200 万行代码：100 万是捆绑的依赖项（例如 React 包、CSS 构建等），测试有 308,000 行代码，Turbopack 有 311,000 行代码。

在 AI 之前，这种重写需要数年的工程时间才能完成。理论上，Cloudflare 所做的事情一直都有可能，但似乎从未实际可行。我的意思是，为什么要让一个工程师团队可能花费数年时间来为 Next.js 应用生成标准化的构建输出？即使他们这样做了，开发者社区也会怀疑 Cloudflare 是否会维护该项目。

这就是分叉或重写开源项目的关键：商业开源的一个主要价值主张是确保它们会得到维护。Vercel 在过去 10 年中证明了自己是 Next.js 的可靠守护者。如果没有 AI，人们可能会认为任何新的重写最终都会力竭而终。

另外但相关的是，Cloudflare 现在证明了重写现有软件的成本因 AI 而变得低约 100 倍，而且这种经济性很可能也适用于维护。考虑到重建一个最复杂的开源项目之一是如此轻而易举，这预示着未来的维护也将变得轻而易举且成本低得多。如果一个工程师可以兼职维护项目，Cloudflare 可能就不再需要为维护单独预算一个工程团队了！

Cloudflare 有一个按工程年数衡量的项目，却在一个工程周内完成了！它只用了一位工程师，使用 OpenCode（开源编码代理）、Opus 4.5 和一堆代币，然后 “boom”，vinext 诞生了。

4. “AI 生成的粗糙内容”仍是问题

不过，关于 vinext 的质量存在疑问。Vercel 自然不满意，并抨击了 vinext 明显的弱点：它不安全，不适合生产使用。Vercel 首席执行官 Guillermo Rauch 立即将 Cloudflare 的努力与 “氛围编程” 的刻板印象联系起来——即那种粗制滥造、缺乏理解的产物：

Guillermo 说得有道理：任何在Cloudflare 发布公告开头几句话后就停止阅读的人，都会认为它已准备好投入生产，因为公告的第一段以这句话结尾：

“我们已经有客户在生产环境中运行它。”

然而，Cloudflare 直到公告发布超过 1000 字（约 2-3 页）后才透露这个相当关键的信息：“运行在生产环境中” 意味着 vinext 已部署到一个测试站点上：

“我们想明确说明：vinext 是实验性的。它甚至不到一周大，尚未经过任何有意义的大规模流量实战检验。(...)

我们一直在与 National Design Studio 合作，该团队旨在使每个政府界面现代化，在其一个测试站点，CIO.gov 上。”

哦。所以，Cloudflare 口中的 “客户在生产环境中运行” 显然意味着 “客户在没有有意义流量的情况下运行一个测试站点在生产环境中”。对于这家通常以其声明准确性为豪的基础设施巨头来说，这可是头一遭！

当 Cloudflare 的首席执行官和首席技术官像宣传一个成熟、久经考验的产品一样宣传 vinext 时，这个细节同样缺失。在此背景下，我认为 Vercel 提出安全漏洞问题是完全合理的。

尽管如此，所有这些都没有改变从这个项目中得出的核心教训：AI 有能力将工程时间大幅减少高达约 100 倍，并以相对可忽略的财务成本交付够用的产出。只需记住，安全性和可靠性问题可能需要大量额外的时间和精力来解决。

5. 对商业开源的新攻击向量？

如果说科技界存在宿敌，那么 Cloudflare 和 Vercel 就是一个典型例子。双方都力争成为开发者部署代码的最受欢迎平台，其首席执行官们经常在公开场合向对方开炮。去年三月就发生过一次这样的口角，当时有相关报道：

“事情在社交媒体上发酵，开发者们对事件的严重程度感到困惑，也困惑于 Next.js 为何似乎保持沉默，以及为什么 Cloudflare 的站点因其修复 CVE 导致自身问题而崩溃。就在那时，Cloudflare 的首席执行官 Matthew Prince 加入了讨论，指责 Vercel 不关心安全：

鉴于安全事件仍在持续，Cloudflare 负责人的这种行为感觉有点 “不够光明正大”。批评竞争对手是公平竞争，但为什么不等到事件结束后再说呢？这一击打中了，而 Vercel 的首席执行官 Guillermo Rauch 不是那种忍气吞声的人，于是他进行了反击。

Cloudflare 的首席执行官随后用一张卡通图暗示，尽管 Vercel 比其竞争对手 Netlify 大得多，但 Cloudflare 比它们俩加起来还大 100 倍，可以随心所欲地将它们踩在脚下。”

Cloudflare 重写Next.js并非为了服务公共利益：他们这样做是因为他们希望 Next.js 站点部署到 Cloudflare 上，但在此之前这样做意义不大，因为 Next.js 产生的是为 Vercel 基础设施优化的专用构建输出。通过这一改变，Cloudflare 声称根据其自身测量，在托管 Next.js 应用时提供了更优越的性能。

我只想补充一点，性能对开发者来说很重要，但其他事情也很重要。成本、可靠性、开发者体验以及开发者对公司的喜爱程度，都是选择供应商时的因素。此外，供应商关于自身服务的性能测量必须持保留态度。

从这一事件中退一步看，AI 似乎正在质疑现有商业开源护城河的价值。Vercel 巧妙地制定了开源策略，帮助其将开源投资转化为商业收入：

1. 构建并维护 Next.js，提供最佳的开发者体验（DX）。
2. 优化 Vercel 以服务于 Next.js 特定的（且未记录的）构建输出。
3. 大多数刚开始使用 Next.js 的开发者会决定部署在 Vercel 上，以在 DX 和性能方面获得最大收益。
4. ……数年重复，直到公司价值数十亿美元！（Vercel 估值在去年10月达到 90 亿美元）。

支撑这一成功的基础是以下几个假设：

1. 由于持续投资，Next.js 将保持开发者构建 React 应用程序的第一选择。
2. 重写 Next.js 以使其可在另一个云供应商上部署且高性能是昂贵的。
3. 即使有人完成了第 2 点，开发者也会持怀疑态度，不会转换。

Vercel 可以投资第 1 点，以保持 Next.js 一流，同时知道第 2 点发生的风险很小。然而，Cloudflare 现在已经 “克隆” 了 Next，并且可以轻松跟进未来的所有更改，并将其移植回 vinext。

但 AI 使得“搭便车”任何商业开源项目变得轻而易举，这对商业开源初创公司来说是一个巨大的问题。它将构建和维护Next.js的所有努力和投资都置于一个地方，而 Cloudflare 则享受这份艰苦工作的成果（Next.js 公共 API），这个成果可以轻松部署到 Cloudflare，并且现在它可以在价格上 undercut Vercel。对于所有未来的 Next.js 更改，Cloudflare 只需使用 AI 将其同步到 vinext！

WordPress 也有类似的问题，WP Engine 在 2024 年 “搭便车” 其工作并在价格上 undercut 他们。正如我当时的分析：

“在许可的开源项目上搭便车对其他供应商来说诱惑太大，无法抗拒。WP Engine 利用了一个常见的漏洞，即对 WordPress 几乎不投入研发，却将其作为托管服务出售。这意味着他们可以轻松地 undercut 像 Automattic 这样投入大量研发费用的大型企业的价格。或者，像 WP Engine 这样的公司可以收取与 Automattic 相同或更高的费用，但能够在营销上投入更多，同时保持相似的盈利能力。“节省”研发费用给了 “搭便车者” 大量的增长选择——这些选择对 Automattic 来说并不一定开放，因为他们需要像现在一样投入大量研发。

商业开源供应商面临结束 “搭便车” 的压力。Automattic 可能正面临较低的收入增长，因为客户选择了像 WP Engine 这样提供类似服务的供应商——通过更低的价格或更多的营销支出获得这些客户。这场法律斗争可能是迫使 WP Engine 停止分食 Automattic 市场份额的努力，或者也许能让 WP Engine 卖给 Automattic，这将巩固其在托管 WordPress 中的领先地位，同时根据其自身数据，将收入每年增加 4 亿美元。”

Vercel 通过Next.js 设法避免了 “搭便车” 问题，但现在 AI 使重写变得轻而易举，这已不再可能。

6. 防御还是进攻？

商业开源公司应该如何应对竞争对手可以轻松重写他们作为服务销售的托管解决方案背后的软件这一威胁？

一个显而易见的回应是让测试集私有化，使 AI 难以复制。让 Cloudflare 能如此轻松地重写 Next 的一个因素是该项目全面的测试套件。来自他们的公告（强调是我加的）：

“我们还要感谢 Next.js 团队。他们花了数年时间构建一个框架，将 React 开发的可能性提升到了新高度。他们的 API 接口文档如此完善，测试套件如此全面，是这个项目得以实现的重要原因。”

数据库解决方案 SQLite 以其惊人的测试套件而闻名。一些人不知道的是，虽然核心 SQLite 测试是开源的，但其最全面的测试套件——TH3——是闭源的。SQLite 将其高级基础设施作为可购买的服务进行货币化。这是一个公平的权衡：对于大多数贡献者来说，基本的开源测试已经足够好。对于真正关心正确性的企业用户或客户来说，向服务创建者购买高级测试服务是合理的。

开源画布项目 tldraw 宣布将把其测试套件迁移到闭源仓库；这一举动非常合理。以下是 Simon Willison 的评论：

“在过去的几个月里，很明显，一个全面的测试套件足以从头开始构建任何开源库的全新实现，甚至可能用不同的语言。”

结果，tldraw 的公告最终被证明是个玩笑，但现在谁还在笑呢？一个拥有优秀测试的开源项目很容易成为 AI 代理完全重写的目标。

能否为 AI 时代创建新的许可证？现有的开源许可证是在假设人类阅读开源代码并修改它的情况下创建的。代理打破了这一假设。

我们是否会看到新的许可证类型出现，禁止 AI 代理修改项目的源代码？这似乎相当牵强且难以实施，但并非不可能。

AI 代理仍然是非常新的事物，并在科技界逐渐成为主流。一旦它们进入其他行业，如果法律框架被修改以同样适用于 AI 代理，我一点也不会感到惊讶。如果发生这种情况，将为开源许可证区分代理和人类打开道路。

如果代码可以轻松移植，那么护城河是什么？运营一个流行开源项目的团队不能再假设分叉或完全重写是昂贵的，因此专注于其他护城河是有意义的，例如：

• 出色的（付费）支持。如果做得好，AI 可以使其在更高质量下变得更加容易。
• 更小的开放核心，更大的闭源部分。“开放核心” 作为商业模式在商业开源中一直占据主导地位：保持软件核心开源，而高级企业功能则是源码可用或闭源。我预计会有更多公司将其附加服务转为闭源，而非源码可用。
• 面对面的联系和社区。拥有现实世界社区的项目将形成一种超越代码的联系感。例如，很难想象 vinext 会突然出现聚会——而 Next.js 社区有很多。
• 基础设施和硬件仍然是巨大的护城河。在一个软件易于复制的世界里，基础设施仍然是护城河。商业开源可能对那些拥有并运营优于竞争对手的基础设施层的玩家最有意义：能够提供更低的成本、更高的可靠性、更低的延迟、更高的性能，或这些组合。

7. AI 世界现实

AI 最好的用例之一就是完全重写经过充分测试的产品。我估计 AI 至少将 vinext 的创建速度提升了 100 倍，这是巨大的。但总体而言，我们并没有看到 AI 工具带来如此巨大的效率提升。正如 Laura Tacho 在旧金山实用工程师峰会上分享的那样，平均自我报告的效率 “AI 收益” 大约在 10% 左右。

我怀疑这种巨大的效率提升差距是因为 AI 在那些 “无需动脑的任务” 上效率高出许多倍，在这些任务中，正确性可以通过测试来验证，而那些更开放或涉及更多创造力的任务则不然。

总的来说，测试对于高效使用 AI 至关重要。在《实用工程师》播客中，Peter Steinberger 强调了 “闭合循环” 在他的开发者工作流中的重要性，即指示 AI 进行自我测试，并确保 AI 有可运行的测试来验证正确性。

自动化测试一直被认为是创建可维护代码的最佳实践。现在，拥有一个具有广泛测试的代码库是让 AI 代理高效进行重构、重写——甚至添加新功能并验证事物没有被破坏的基准！

供应商将开始部署 “迁移 AI 代理” 以将客户迁移到其自身技术栈。这在 Cloudflare 的公告中被忽略了，但它很重要：

vinext 包含一个为你处理迁移的 Agent Skill。它可与 Claude Code、OpenCode、Cursor、Codex 和数十种其他 AI 编码工具配合使用。安装它，打开你的 Next.js 项目，然后告诉 AI 进行迁移：

> npx skills add cloudflare/vinext

然后在任何支持的工具中打开你的 Next.js 项目，说：

> migrate this project to vinext

该 skill 处理兼容性检查、依赖项安装、配置生成和开发服务器启动。它知道 vinext 支持什么，并会标记任何需要手动注意的内容。

这是 Cloudflare 非常聪明的一步，是真正的 “AI 原生” 行动。他们不仅使用 AI 迁移了 Next.js，还构建了一个 “AI 插件”（一个 skill）来帮助客户将现有代码库迁移到 vinext——并部署到 Cloudflare！

这一步肯定会效仿其他供应商，因为对人类来说繁琐的迁移工作，用代理来完成要轻松得多。

AI 正在让科技行业在商业行为上变得更加无情。Laura Tacho 在实用工程师峰会上说了一些有趣的话：

“AI 是一个加速器，一个乘数，它正在推动组织向不同方向发展。”

AI 似乎正在加速争夺客户的竞争无情性以及这一过程的速度。在一周内，Cloudflare 重建了 Next.js，并正在全力攻击 Vercel：声称他们 “氛围编程” 的替代品性能更优、适合生产，并在发布公告的末尾埋藏了 vinext 仍是实验性的关键信息。

我感觉供应商们正意识到利用 AI 获取优势的时间有限，其中一些会决定像 Cloudflare 这样使用它。

另一方面，AI 对非商业开源可能是个好消息。AI 对商业开源构成威胁，因为它移除了使代码难以完全重写的现有护城河。然而除此之外，AI 可能帮助非商业开源蓬勃发展：

• 借助 AI，分叉一个开源项目并让分叉与原项目保持同步变得容易。
• 指导 AI 将一个开源项目重写为另一种语言或框架变得轻而易举。
• ……并且 AI 为分叉添加功能也同样容易。

基于这些原因，我相信未来会有更多的分叉和重写出现，整体上也会有更多的开源项目和代码。

要点总结

就个人而言，我无法想象软件领域变化如此之快。在一周内重写 Next.js，即使是一个尚未完全达到标准但基本可用的版本？就在几个月前，这还是不可想象的。

变化发生在去年十二月左右，当时 Opus 4.5 和 GPT-5.2 推出，并证明能够编写大部分代码。曾经昂贵的东西现在变得便宜了——比如重写完整的项目——而我们仍然需要学习软件工程中 “新” 的昂贵部分是什么。

这一切对所有人来说都是新领域。要在科技行业取得成功，你需要能够利用变革，就像 Cloudflare 在这个案例中显然通过充分利用新技术创造的机会所做的那样。尚不清楚 vinext 会有多受欢迎，也不清楚 Vercel 在更广泛的 Next.js 生态系统周围拥有多大护城河，但我怀疑要让 Cloudflare 成为一个可行的 Next.js 平台即服务提供商，仅靠重写 Next.js 是不够的。

由 mimo-v2.5 模型翻译，花费 18046 tokens

我曾对“大型语言模型将杀死SaaS（软件即服务）”的各种论断持怀疑态度。这一想法背后的逻辑是：

1. SaaS是纯软件产品。用户之所以付费给SaaS提供商，是因为购买这个软件比自己构建更便宜。
2. 大型语言模型极大地减少了构建定制软件所需的时间和成本。
3. 因此，大多数SaaS提供商将倒闭，因为大多数公司/团队将通过提示大型语言模型来编写他们需要的软件，例如工单管理、会议安排、客户关系管理等。

我之所以持怀疑态度，是因为像人力资源软件Workday这样的SaaS不仅仅是软件。以Workday为例，它需要跟上不同国家的合规要求（例如假日工资），保证准确性（例如符合当地法规的工资单），并且随着时间的推移，软件需要不断更新以适应外部和内部环境的变化。

然而，这周我亲身经历了现在用大型语言模型替换SaaS是多么的轻而易举。在我的网站 pragmaticengineer.com 上，有一个推荐语板块，展示关于这个出版物的真实的LinkedIn和X帖子。它使用了名为 Shoutout.io 的小服务，每年花费120美元，看起来像这样：

这是它的后端界面：没什么特别的，只是用来添加、编辑、重新组织和删除推荐语。

我作为客户已经四年了，可能每年只登录一次。我上次登录是为了获取年度发票用于报销。不幸的是，账单部分坏了，所以我发邮件给客服，他们却给我发了一个失效的链接而不是发票。这很令人沮丧：为什么要为一个账单系统损坏的SaaS付费？我甚至无法得知他们明年会收我多少钱。

于是我问自己，能否用大型语言模型快速重建我自己的用例。我的用例比SaaS本身简单得多：

• 以类似的方式展示现有的推荐语
• 方便地添加新的推荐语，例如将推荐语存储为某种JSON格式
• 让它看起来美观

令我惊讶的是，使用Codex完成这项工作，从开始到结束总共花了正好20分钟。我采取的步骤非常直接：

• 询问Codex制定一个计划，如何移除这个第三方依赖并将所有推荐语托管在我的代码库（一个部署在Netlify上的GitHub仓库）中
• 调整计划：我推动采用模块化方法，将推荐语放在单独的JSON文件中，并通过编译时构建步骤将其生成为HTML
• 在本地以及Netlify上添加了这个构建步骤作为触发器
• 测试了解决方案
• 调整了用户体验并生成了模式定义
• 部署了它

最终结果在视觉上与之前相同，只是我不再有渲染这一切的第三方依赖了！

这对SaaS产品和软件工程师意味着什么？

对软件工程师意味着：

• 开发者（可能）比普通用户更习惯使用命令行进行未来的更新。要添加新的推荐语，我将需要让我的AI代理将其插入我的代码库，然后我需要验证它看起来是否良好。对我来说这不是什么大事，但对于不习惯验证大型语言模型代码输出的人来说，这可能是个障碍。
• 开发者“移植”一个SaaS服务要比其他人快得多。我最初让Codex复制用户界面，但它搞错了，因为它试图使用flexbox模型。我不得不告诉它这不是我想要的UI布局，然后决定使用哪个框架来实现UI布局。非开发者可能也能弄明白这些，但会花费更长时间。
• 老实说，重写第三方功能很有趣，也引人入胜。我推荐这样做。我接手这个项目的一部分原因是我预计这将是一个有趣的挑战。我以为所需的努力会比实际更多，我也学到了更多关于这些工具工作效果如何的知识。我还使用了Codex以便更多地体验它。

对SaaS软件可能意味着：

• 重建一个完整的SaaS感觉仍然比重建你特定的用例要困难得多。我根本没有以任何方式“重建”Shoutout。Shoutout拥有10倍甚至更多的功能，比如从10个不同平台添加引用、身份验证、账单（对我来说坏了）、以及其他功能。
• 不提供持续价值的SaaS服务面临被客户替换的风险。Shoutout在展示我的推荐语后没有提供持续的价值，这种静态特性意味着它很容易被替换。相反，如果我付费是为了让平台保持合规、提供分析或警报功能，以及做其他帮助我业务的实时事情，那么重建它就会困难得多。
• 买卖SaaS业务可能变得不那么有利可图。我最初在2021年注册的Shoutout原始版本是由一位独立开发者在2020年创建的。2022年，这位开发者卖掉了这个微型SaaS给一个产品工作室。然后，在2025年，Shoutout再次被转卖给新的开发者。从我的角度来看，除了账单系统坏了之外，什么都没变。我猜这个SaaS的买家认为收入可以在零投资的情况下持续增长。但也许当人们对一个破损的产品感到厌倦并离开时——特别是当这样做的成本更低时——这种想法就不再成立。

“破窗”不被修复比以前更难以接受。我离开Shoutout的旅程始于它的账单系统损坏。例如，下面是我进入账单部分查看发票时所看到的：

除此之外，客服在回复我邮件时还发送了一个失效的链接。这足以让我决定替换这个依赖，并且我很惊讶用大型语言模型完成这件事如此容易，而且我知道我想要构建什么。*在客服两小时后给我发来一个有效链接时，我已经完成了SaaS的迁移工作。*

由 mimo-v2.5 模型翻译，花费 5968 tokens

我正在逐渐接受一个极有可能的现实：未来我发布的大部分我自己的代码将由人工智能编写。它已经写得更快了，而且效果与我亲自敲代码相似。对于我不太熟悉的语言或框架，它甚至比我做得更好。

这感觉就像某些宝贵的东西被突然夺走了。我花了大量精力才擅长编程，学会如何写出能工作的代码，读懂和理解复杂的代码，以及在代码出错时调试修复。我依然记得大学时第一门“真正”的编程课（学C语言）有多吓人，第一份工作中面对复杂代码库时有多迷茫，也记得自己花了数年时间练习，从其他开发者、书籍和博客中学习，才变得更好。一旦你变得相当出色，你就拥有了通过写出能工作的代码来证明其价值的、容易验证的本领！

关于构建软件，我最美好的一些记忆都与编写代码有关。那种将几个想法同时梳理并敲打出来的“沉浸其中”状态，那种进入心流、编译代码、运行后看到“是的”，它如预期般工作了的感觉！

公平地说，这曾经是一种爱恨交加的关系，基于编写复杂代码所需的专注程度。然后还有所有时间预估引发的冲突：当你沉浸其中、致力于解决一个难题时，时间的流逝是不同的。

现在，这一切看起来都将成为历史。

我在想，面对编写复杂代码曾经很难这一事实，我是否还会获得同样的满足感？是的，AI很方便，但也伴随着一种失落。

又或者，随着智能体的出现，“沉浸其中”将转变为思考更高层次的问题，同时指导编写更复杂的代码？

以上摘自我分析文章《当AI编写几乎所有代码时，软件工程会发生什么？》的一个章节。请点击此处阅读全文。

由 mimo-v2.5 模型翻译，花费 1622 tokens

嗨，我是 Gergely，为您带来《Pragmatic Engineer Newsletter》的特别免费版。每期，我都会从资深工程师和工程领导者的视角，剖析大型科技公司和初创企业。今天，我们将讨论上周 The Pulse 刊物中四个话题之一。完整版订阅用户早在七天前就收到了下文。如果您是通过邮件转发看到这篇文章，可以 在此订阅。

距离 Cloudflare 上次遭遇重大中断并导致半数互联网瘫痪仅两周，同样的事情再次发生。上周五，12月5日，数千个网站再次宕机或部分中断，Cloudflare 全球性服务中断持续了25分钟。

和上次一样，Cloudflare 迅速在同一天发布了 完整的事后分析报告。据估计，Cloudflare 28%的 HTTP 流量受到影响。这次最新中断的原因是 Cloudflare 进行了一次看似无害，却是全局性的配置变更，导致全球范围内 Cloudflare 的大量服务中断，直到变更被回滚。事件经过如下：

• Cloudflare 正在部署一个针对严重 React 安全漏洞的修复程序。
• 该修复导致一个内部测试工具出现错误。
• Cloudflare 团队使用一个全局终止开关禁用了该测试工具。
• 在进行这项全局配置变更时，该终止开关意外引发了一个错误，导致 Cloudflare 网络出现大量 HTTP 500 错误。

在这次最新中断事件中，Cloudflare 再次栽在了全局配置变更上。 之前的中断事件发生在 11月，起因是一次全局数据库权限变更。在那次事件的事后分析中，Cloudflare 团队提出了以下待办事项：

“像对待用户生成的输入一样，加强对 Cloudflare 生成的配置文件摄入过程的防护。”

这一变更旨在让 Cloudflare 的配置文件不再像现在这样立即传播到整个网络。但是，让所有全局配置文件都实现分阶段发布是一项庞大的工程，可能需要数月时间。显然，目前还没有时间来完成这项工作，它再次让 Cloudflare 付出了代价。

对 Cloudflare 来说不幸的是，客户很可能无法接受在短短几周内，又发生一次原因类似的严重中断。如果 Cloudflare 被证明不可靠，客户至少应该计划引入备用 CDN，而备用的 CDN 供应商会尽力说服新客户将其作为主要 CDN。

Cloudflare 的价值主张建立在无需客户为备用 CDN 预算的、坚如磐石的可靠性之上。是的，在中断发生当天就发布事后分析报告有助于恢复信任，但频繁发生的大规模中断无论如何都会侵蚀这份信任。

公平地说，该公司正在加倍努力实施分阶段配置发布。 在其事后分析报告中，Cloudflare 是自己最严厉的批评者。首席技术官 Dane Knecht 反思道：

“[全局配置变更在全球范围内发布] 仍然是我们整个组织的首要任务。特别是，下面概述的项目应有助于控制此类变更的影响：增强的发布与版本控制： 类似于我们如何通过严格的健康检查来缓慢部署软件，用于快速威胁响应和通用配置的数据也需要具备同样的安全性和影响范围缓解功能。这包括健康验证和快速回滚能力等。简化的应急操作能力： 确保在面对其他类型的故障时，关键操作仍然可以完成。这适用于内部服务，也适用于所有 Cloudflare 客户与 Cloudflare 控制平面交互的所有标准方法。“失败时开放”的错误处理： 作为弹性工作的一部分，我们正在替换所有关键 Cloudflare 数据平面组件中错误应用的硬性失败逻辑。如果配置文件损坏或超出范围（例如，超出功能上限），系统将记录错误，并默认为已知正常状态或直接放行流量而不进行评分，而不是丢弃请求。某些服务可能会在特定场景下为客户提供选择失败时开放或关闭的选项。这将包括漂移预防功能，以确保持续强制执行此策略。
此类事件，以及它们如此集中地发生，对于我们这样的网络来说是不可接受的。”

全局配置错误常常引发大规模中断

存在一种模式，即显式或隐式的全局配置错误会导致大规模中断，近年来一些最大的中断事件都是由单一变更部署到整个机器网络所引发的：

• DNS 及 DNS 相关系统（如 BGP）： DNS 变更默认是全局的，因此 DNS 变更导致全球性中断也就不足为奇了。Meta 2021年长达7小时的中断就与 DNS 变更有关（更具体地说是边界网关协议 BGP 变更）。而 AWS 10月的中断则 始于其内部 DNS 系统。
• 操作系统更新同时在全球范围内执行： Datadog 2023年的中断给公司造成了500万美元损失，起因是 Datadog 的 Ubuntu 机器在全球范围内同一时间窗口执行了操作系统更新。这导致了网络问题，而 Datadog 在 3 个不同的云提供商上运行其基础设施，跨越 3 个网络，这使得情况更加恶化。同样的 Ubuntu 更新也在 2024年导致了 Heroku 的全球性中断。

全局复制配置： 2024年，一项配置策略变更被全局发布，并立即导致每个 Spanner 数据库节点崩溃。正如 Google 在其 事后分析中总结的那样：“鉴于配额管理的全局性质，此元数据在几秒钟内即完成了全球复制。”

为所有配置文件实施渐进式发布是一项巨大的工程。这也是一项看不见的工作，因为当它做好时，其益处将是无法察觉的，除了在没有事故发生时，这要归功于更好的基础设施！

世界上最大的系统可能不得不实施更安全的配置发布方式——但并非每个人都需要这样做。 分阶段配置发布对于较小的公司和产品来说意义不大，因为这种基础设施工作会减缓产品开发速度。

它不仅减慢构建速度，也拖慢每一次部署，这种阻力本身就是为了减慢一切。因此，除非成熟系统的稳定性比快速迭代更重要，否则它们没有太大意义。

软件工程是一个权衡无处不在的领域，普遍适用的解决方案并不存在。适用于一年前只有其 1/100 负载和用户的系统的开发方式，今天可能不再适用。

这是本周《The Pulse》涵盖的四个话题之一。 完整版 还额外涵盖：

1. 行业动态。AWS 糟糕的容量规划、Meta 转向“封闭 AI” 方法、即将到来的 RAM 短缺、初创企业招聘放缓、在 Amazon 和 Meta 拿到 60万美元年薪需要多久、苹果高管跳槽 Meta 等。
2. Oxide 工程团队如何使用 LLM。他们发现 LLM 非常适合阅读文档和进行轻量级研究，对编码和代码审查效果一般，对于撰写文档——或任何类型的写作——则是一个糟糕的选择！
3. Linux 内核正式支持 Rust。距离一位 Linux 基金会研究员 预测 将对 Rust 提供更多支持仅八个月，Rust 现已成为 Linux 内核的一等语言。总结 Rust 对 Linux 支持的优缺点。

阅读完整的《The Pulse》期刊。

由 mimo-v2.5 模型翻译，花费 6451 tokens

嗨，我是Gergely，本期为Pragmatic Engineer通讯的额外免费期刊。每一期，我都会从资深工程师和工程领导者的视角，探讨大型科技公司与初创企业的话题。今天，我们将聚焦上周《The Pulse》期刊中四个主题中的一个。完整订阅者已于七天前收到下文。如需每周收到此类文章，请在此订阅。

一年前，亚马逊成为首家要求员工每周五天全部返回办公室工作的科技巨头。当时，我分析了这一变化的原因，以及其他工作场所是否会效仿，放弃普遍实行的每周2-3天到岗的混合办公政策。

如今，Meta旗下Instagram部门的员工，继本周社交媒体平台宣布后，成为了最新一批被要求全面返回办公室的员工。

Instagram的5天重返办公室政策

据Substack的同行Alex Heath报道，Instagram员工在周一收到了这封出乎意料的邮件，他获取了该邮件的副本。这封邮件由Instagram首席执行官Adam Mosseri内部发出，内容如下：

“1. 返回办公室：我认为，当我们亲自在一起时，更有创造力和协作精神。（...）

2. 减少会议：我们都在低效的会议上花费了太多时间，这拖慢了我们的速度。每六个月，我们将取消所有常规会议，只重新加入那些绝对必要的会议（...）

3. 多演示，少幻灯片：大多数产品概述应该用原型展示，而不是幻灯片。

4. 加快决策：我们将通过DRI建立更正式的解除障碍流程，我将每周参加优先事项进展解阻会议。”

Meta的这一决定影响了公司约四分之一的员工，很难想象其他部门不会效仿Instagram；毕竟，Mosseri备忘录中的内容很可能适用于整个公司。

五年前，首席执行官马克·扎克伯格预测，到目前为止Meta将有50%的员工远程工作，但这并未实现。事实上，随着Instagram新的5天重返办公室政策，如果两年后Meta还有5%的员工远程工作，我会感到惊讶。

Instagram推行重返办公室政策的原因似乎根植于领导层认为办公室工作更具生产力的信念，正如Mosseri信息中的首要要点所示。该信息全文如下：

“我认为，当我们亲自在一起时，更有创造力和协作精神。在疫情前我就这么觉得，每次我去我们纽约办公室时，那里的亲临文化很强，我都能感受到这一点。

从2月2日起，我要求我管理范围内所有在美国办公室且有固定办公桌的员工全职（每周五天）返回办公室。具体细节如下：

• 您仍然可以在需要时灵活地在家工作，因为我理解有时您可能无法来办公室。我相信你们都会运用自己的最佳判断来适应这个时间表。
• 在纽约办公室，直到我们缓解了空间限制，才会要求你们全职返回。一旦我们确定了时间表，我们会分享更多信息。
• 在Menlo Park总部，我们将于1月26日从MPK21搬迁至MPK22，以便每个人都有固定的办公桌。我们还提供从Menlo Park办公室转到旧金山办公室的选项，适用于通勤时间相同或更短的人员。我们将直接联系相关人员获取更多信息。
• 跨职能合作伙伴将继续遵循其各自组织的规范。
• 目前远程工作的员工不受影响”。

从我从远处对Mosseri的观察来看，他似乎是个相当直率的人。很明显，他认为办公室工作能带来更多活力。为Mosseri辩护的话，我听许多初创公司创始人和领导者说过类似的话，他们表示远程工作带来了许多麻烦：更难发现积极性和绩效问题，信息传递更慢，团队动员也更困难。

毫无疑问，运营一家全远程公司需要付出巨大的努力。在招聘、入职、绩效管理、团队庆祝活动甚至全公司会议等方面，存在着常被忽视的劳动，这些都不容易。

Linear是一家拥有近50名员工的全远程公司，他们最近公布了其运营细节。他们引入了“协作中心”的概念，为团队组织线下活动并定期举行离线会议，同时谨慎地招聘符合公司文化的人。

我的感觉是，科技公司的远程工作政策将越来越取决于其领导者的偏好。许多开发者更喜欢远程工作：干扰更少，深度专注更多，通勤更少。我们大多数人可能和在办公室被打断时一样高效，甚至更高效。

偏好全远程的领导者可以指出灵活性和从更大人才库中更易招聘等明确优势。与此同时，最习惯亲临办公的人，总能找到足够理由来证明5天重返办公室的合理性，就像Mosseri的理由一样。混合办公的支持者则强调专注时间和效率的平衡。

在当前的就业市场中，任何薪酬接近市场顶端的公司，或许都能推行每周五天重返办公室政策。Meta就属于这种情况。尽管我确信许多开发者会不喜欢这个变化，但替代方案是进入就业市场，接受降薪加入新公司，并重新建立内部人脉网络。

由于我们正处于一个异常的就业市场中，换工作比以前就业市场火热时更困难。从这个角度看，Instagram具备外部条件的优势。对于Meta的开发者来说，一个好处是大型科技公司的工作经验能打开更多大门，即使是在这个严峻的就业市场中。

需要注意的是，在难以招到合适人才的地方，5天重返办公室政策不太可能出现。因此，从事人工智能的工程师以及从事AI产品的工程师应该相对安全，因为这些职位需求极高，正如AI工程师更高基本工资的趋势所表明的。基于此，很少有公司会希望迫使这些员工离职加入竞争对手。

许多订阅者将此通讯费用计入其学习与发展预算。如果您有此类预算，这里有一封您可以发送给经理的邮件模板。

由 mimo-v2.5 模型翻译，花费 4425 tokens

以下是来自 The Pulse #154。 的五个话题之一。完整订阅用户已于两周前收到下文。如需每周在收件箱中收到此类文章，请在此订阅。

许多订阅用户将《Pragmatic Engineer 通讯》计入其学习与发展预算。如果您有此类预算，可以考虑向您的经理发送此邮件。

关于 2025年11月 Cloudflare 服务中断事件，一个有趣的情况是，实时宕机和监控服务 Downdetector 自身也发生了宕机，从而暴露了其对 Cloudflare 的关键依赖。乍看之下，这似乎有些矛盾；毕竟 Downdetector 是一个监控服务正常运行时间的服务，那么如果它要承担像 Cloudflare 这样的关键依赖，并可能因此导致此类事件发生，它为什么要这么做呢？

Downdetector 是采用多区域、多云架构构建的， 这一点我通过与 Downdetector 背后公司 Ookla 的工程高级总监 Dhruv Arora 交谈得到了确认。多云弹性对大多数产品来说意义不大，但 Downdetector 的设计初衷也包括检测云服务商的宕机。为此，它必须采用多云架构！

即便如此，Downdetector 仍然使用 Cloudflare 提供 DNS、内容分发网络（CDN）和机器人防护服务。那么，它为何要承担这单一的关键依赖，而不是将所有内容都托管在自己的服务器上呢？

CDN 的优势不容忽视， 例如：

• 显著降低带宽成本 — 存储在 CDN 上的资源访问速度更快
• 更快的加载时间，因为 CDN 上的资源由更靠近用户的边缘节点提供服务
• 能够应对突发的流量高峰，而这对于 Downdetector 来说很常见，尤其是在发生宕机事件时！如果没有 CDN，这些流量高峰可能会使其服务过载
• 提供 DDoS 防护，防止恶意攻击者通过分布式拒绝服务攻击使网站离线
• 减少基础设施需求，因为 Downdetector 可以在更少的服务器上运行

Downdetector 的使用模式表明，它是一个被消费者高度使用的服务，而公司并未真正从中盈利（Downdetector 可免费使用）。因此，Downdetector 可以选择放弃使用 Cloudflare，但这样做会导致成本激增、网站加载变慢，而收入却不会增加。

最终，Downdetector 对 Cloudflare 的依赖可能是一种基于其商业模式的务实选择，而移除其对 Cloudflare 的上游依赖可能会变得非常昂贵！

Dhruv 确认了这一点，并分享了更多关于 Downdetector 设计选择的细节：

“在 DNS 和 CDN 层面构建冗余将需要巨大的开销。 尤其是 Cloudflare 的机器人防护是世界一流的，构建类似功能需要付出巨大努力。某些超大规模云服务商已经内置了这类冗余。我们会研究可以采取哪些措施，但对于一个两位数规模的团队来说，构建这样的核心基础设施是一个相当艰巨的任务：不仅对我们如此，对任何中型团队都是如此。

我们认识到，未来还有很多可以改进的地方。例如，在此次宕机期间，Cloudflare 的控制面板无法访问，但其 API 是可用的。因此，如果我们有更多的基础设施即代码实践，可能有助于更快地恢复 Downdetector 的服务。

我们还注意到，此次宕机并非全球范围，因此我们能够转移流量并减少影响。

另一个有趣的细节：Cloudflare 的机器人防护在此次宕机期间出现了故障，开始拦截合法流量。因此，我们的团队不得不暂时将其关闭”。

非常感谢 Dhruv 和 Downdetector 团队分享的这些细节。

由 mimo-v2.5 模型翻译，花费 2713 tokens