一周1300多个PR，揭秘Stripe内部AI工程最佳实践

想象一下这个场景：你在地铁上刷着 Slack，看到一个需要修复的 bug。你点一个 emoji 表情，等到了办公室，代码已经写好、测试通过，Pull Request 等着你审查。这不是科幻小说，这是 Stripe 工程师每天的真实工作状态。更震撼的是，Stripe 每周有大约 1300 个代码合并请求完全由 AI agent 完成，工程师只负责审查，一行代码都不用自己写。

当我第一次听到这个数字时，我的反应是：这怎么可能？1300 个 PR，每周？要知道很多小型工程团队一个月可能都合并不了这么多代码。但当我深入了解 Stripe 的 Minions 系统后，我意识到这不仅可能，而且代表着软件工程的一个根本性转变。我们正在从"工程师写代码"转向"工程师管理 AI 写代码"，这个转变的速度比我想象的要快得多。

Stripe 的软件工程师 Steve Kaliski 在最近的一次访谈中分享了他们如何构建和使用这套系统。Steve 在 Stripe 工作了六年半，一直专注于开发者工具和支付基础设施的建设。他提到一个非常有意思的观察："我已经不记得上次是从文本编辑器开始工作是什么时候了。"他的工作通常从 Google 文档、Jira 工单或者 Slack 对话开始，这些才是更自然的工作起点。等到需要真正动手写代码或做最后调整时，才会进入文本编辑器。这种工作方式的转变，让启动一项工作的激活能量大大降低。

什么是 Minions

Minions 是 Stripe 自研的全自动编码 AI agent（智能代理）。它们被设计成"一次性完成"任务的系统，从接到指令到提交代码、通过测试、创建 PR，整个过程完全无人参与。Steve 解释说，在 AI 时代之前，当他作为工程师想要修改 Stripe 的代码时，会面对一个巨大的代码库，包含数百个服务，这些服务根本无法在个人电脑上运行。所以 Stripe 很早就投资建设了优秀的开发者工具，提供了托管的开发环境 devbox（开发盒子），工程师可以快速启动一个环境，里面已经有所有代码和运行中的服务。

Minions 的核心思路是：我可以提供一个 prompt（提示词）来启动这样一个环境，然后 minion 会尝试一次性解决这个 prompt，使用 Stripe 内部所有可用的工具、内部文档、CI 系统、测试数据等等。它会循环执行这个过程，直到解决问题。这种"一次性"的设计哲学非常重要，因为它意味着从用户提出需求到代码准备好审查，中间不需要任何人工干预。

从使用体验来看，一个典型的 minion 运行流程是这样的：工程师在 Slack 频道里发一条消息，比如"我想改进 docs.stripe.com/payment/machine 这个文档页面，让代码示例更清晰"。然后在这条消息下点击一个特定的 emoji 反应，比如"create minion pay-server"。系统就会自动创建一个新分支，启动开发环境，minion 开始工作。你可以点击"follow along"链接实时查看进度，看到它正在配置环境、检查代码库、执行修改、运行测试、提交代码。整个过程可能需要几分钟到十几分钟，但工程师不需要盯着看，可以去做其他事情。等 minion 完成后，你会收到通知，打开 PR 审查代码即可。

我觉得这种交互方式的转变意义深远。过去我们总是强调"开发者体验"，但往往局限在 IDE 好不好用、命令行工具是否顺手。而 Minions 让我重新思考：真正好的开发者体验应该是什么？也许不是让写代码变得更容易，而是让"不写代码"变得可能。当你可以用自然语言描述需求，系统就能自动完成实现，这才是开发者体验的终极形态。

为什么 Stripe 要自己构建

市面上已经有很多优秀的 AI 编码工具，比如 Cursor、Claude Code、GitHub Copilot 等等。为什么 Stripe 还要花力气自己构建 Minions？Steve 给出了一个非常务实的回答：从零开始快速搭建原型和在 Stripe 的代码库上贡献代码，是完全不同的两回事。

Stripe 的代码库规模惊人，包含数亿行代码，分布在几个大型代码仓库中。大部分后端代码用 Ruby 写的，但不是常见的 Rails 框架，而是配合 Sorbet 类型系统，这是一个相对小众的技术栈。整个代码库使用了大量 Stripe 自研的内部库，这些库对于大语言模型来说是完全陌生的。更关键的是，这些代码每年处理超过 1 万亿美元的支付交易量，运行在生产环境中。同时，Stripe 还要面对金融机构的复杂依赖关系，以及严格的监管合规要求。

这些约束条件让问题变得复杂得多。LLM 在构建全新软件时表现很好，特别是当系统约束相对较少的时候。但在 Stripe 这样规模、复杂度和成熟度的代码库上迭代，难度要高得多。人类工程师需要建立复杂的心智模型才能有效地修改代码，而让 AI agent 在有限的上下文窗口内形成正确的直觉、使用正确的工具，挑战非常大。

我深有同感。我自己在做产品时也遇到过类似问题。当你的代码库还很小的时候，AI 工具确实能帮你快速搭建原型。但随着代码库增长、业务逻辑变复杂、技术债务累积，AI 工具的效果就会大打折扣。它可能给你生成看起来正确的代码，但实际上违反了你们内部的最佳实践，或者用了已经废弃的库，或者没有考虑到特定的边界情况。这时候你需要的不是一个通用的 AI 助手，而是一个"懂你的代码库"的专属 AI。

Stripe 的解决方案是在开发者工具基础设施上的长期投资。多年来，他们建设了完善的开发者生产力工具，覆盖源代码管理、开发环境、代码生成、CI 系统等开发生命周期的各个阶段。Minions 紧密集成了这些工具。这印证了一个重要原则：对人类有用的工具，对 LLM 也有用。

降低激活能量的意义

Steve 提到了一个让我深有感触的概念：激活能量（activation energy）。在化学反应中，激活能量是指启动反应所需的最小能量。在软件开发中，激活能量就是从"有一个想法"到"开始动手"之间的那道门槛。

在大型组织中，这个门槛特别高。一个好想法要变成现实，中间可能有无数摩擦。可能是职能障碍：你需要某个技术领域的专业知识，但你没有。可能是操作障碍：你不知道如何组织人员、如何有效沟通来推进下一步。也可能只是因为人们被日常工作束缚，没有想到新的做事方式。

我在自己的创业经历中经常遇到这种情况。有时候团队讨论出一个很好的改进点，大家都觉得应该做，但就是一直没有人开始。不是因为任务太难，而是因为启动它需要太多步骤：创建任务、分配给某人、等他有空、排期、开会讨论细节、写设计文档、开始编码...这个流程走下来可能要几周。很多时候不是执行难，而是启动难。

Minions 的价值就在于把激活能量降到接近零。在 Slack 对话中看到一个用户反馈，觉得应该更新文档或者做一个原型？点一下 emoji，工作就开始了，往往工作也会自己完成。即使没有完全完成，至少代码开始运行、测试开始执行，你可以中途介入、进行调整，利用那种"生成性动力"。Steve 说，这种感觉就像你可以在半路跳进一辆已经启动的车，而不是从零开始推车。

更重要的是，低激活能量意味着高并行度。Steve 提到，他可以在同一时间启动多个 minion，让它们在隔离的环境中同时处理不同的任务。这在传统开发模式下几乎不可能。你的本地机器资源有限，开太多分支会让电脑卡得像飞机起飞。但在云端环境中，你可以同时运行十几个 minion，每个处理一个独立的任务。想象一下，你在周一早上启动五个 minion 处理五个不同的 bug，到中午时它们都完成了，你只需要逐个审查和合并。

我认为这种"批量并行"的工作方式会彻底改变软件工程的节奏。过去我们习惯了线性工作：一个任务接一个任务。现在我们可以像项目经理一样思考：同时启动多个工作流，管理它们的进度，在需要的时候介入。工程师的角色正在从"执行者"转向"编排者"。

开发者体验的双向价值

在演示中，Steve 特别强调了一个观点：好的开发者体验对人类和 AI agent 都有价值。这个观点听起来简单，但含义深刻。

Stripe 的 devbox 系统不是为 AI 设计的，而是多年前为了解决人类工程师的实际需求而建设的。Stripe 的代码库太大了，无法在本地机器上运行所有服务。所以他们建立了云端开发环境，工程师通过 SSH 连接到这些环境工作。一个工程师可能同时有五六个 devbox 在运行，每个对应一个不同的任务。这些环境在 10 秒内就能准备就绪，预先克隆了庞大的 git 仓库，预热了构建缓存和类型检查缓存，启动了代码生成服务。

这种基础设施原本是为了人类工程师的并行工作、可预测性和隔离性而建设的。但当 AI agent 出现时，这些特性突然变得更加重要。Minions 天然地继承了这些优势：每个 minion 在独立的 devbox 中运行，互不干扰；可以轻松并行运行多个 minion；环境是标准化的，不会因为个人配置不同而产生问题。

我想起之前和一个朋友聊天，他在一家大公司负责开发者工具。他说他们团队最难的事情不是技术实现，而是争取资源。产品团队总是优先做面向用户的功能，开发者工具的优先级永远排在后面。我当时给他的建议是：把开发者工具项目和 AI 计划捆绑在一起。现在 AI 是最热门的方向，如果你说"我们需要改进开发者体验来支持 AI agent"，批预算就容易多了。

Steve 也提到了这个策略。他说很多公司问他们如何开始做 AI 编码，他的回答总是：先把开发者体验搞好。如果你的开发环境很糟糕、文档很差、工具链很乱，那就算给你最好的 AI agent 也没用。但如果你已经有了完善的开发者工具，那接入 AI agent 就是水到渠成的事。这形成了一个良性循环：为人类建设更好的工具，AI 就能更好地使用这些工具；为 AI 改进工具，人类也会从中受益。

云环境的关键作用

关于云开发环境的重要性，我想多说几句，因为这是很多人容易忽视的一点。

Steve 半开玩笑地说，不管你的 MacBook Pro 有多强大，当你开三四个工作树（worktree）时，电脑就开始像飞机起飞一样轰鸣，根本不行。我对此感同身受。我自己就有四台 Mac Mini，其中一台基本上就是"永不合上的笔记本"，专门用来跑长时间任务。这听起来有点荒谬，但确实解锁了我的生产力。

Steve 提到他甚至可以在上班路上用手机刷 Slack 时启动一个 minion，等到了办公室，工作已经进行到一半了，他可以直接接手。这种工作方式在传统的本地开发模式下是不可能的。你的笔记本在包里，怎么运行代码？但在云端环境中，你的开发环境 24 小时在线，随时可以启动新任务。

我认为在多线程的 AI 辅助工程工作中，云环境和虚拟环境是解锁速度的关键。但我看到很多大型工程团队还没有在这方面投资。他们的工程师还在本地机器上挣扎，试图同时运行多个 AI 工具、多个工作树。这就像试图在一辆自行车上跑高速公路。

如果你是 CTO 或工程副总裁，想要在明年真正释放团队的生产力，投资云开发环境应该是首要任务。这不仅仅是为了 AI，也是为了团队的整体效率。想象一下，新员工入职第一天，点一个按钮就能得到一个完整配置好的开发环境，而不是花三天时间配置本地环境。想象一下，你的工程师可以同时在五个项目上并行工作，而不是在本地来回切换分支。这些投资的回报会远超你的想象。

代码审查的规模化挑战

当我听到 Stripe 每周合并 1300 个 AI 写的 PR 时，我的第一个问题是：你们怎么审查这么多代码？这是一个非常现实的挑战。

Steve 的回答很务实。他说，如果工程师花在写代码上的时间变少了，自然就有更多时间审查代码，或者和用户交流等等。但更重要的是 CI 环境的作用。Stripe 有非常好的测试覆盖率，有大量端到端的合成测试来模拟与产品的交互，这些都能为代码审查提供信心。

他强调了一个关键点：不管代码是 Steve 写的还是 Steve 的机器人写的，你都需要那个 CI 环境来提供信心，确保代码变更是安全的。部署时要使用蓝绿部署，这样可以回滚。所有这些都是超级关键的，而且与代码作者是谁无关。

这个观点让我重新思考"AI 写的代码是否可信"这个问题。很多人担心 AI 写的代码质量不够好，会引入 bug。但其实问题的关键不在于谁写的代码，而在于你的质量保证体系是否完善。如果你有完善的测试、完善的 CI/CD、完善的监控和回滚机制，那么不管是人写的代码还是 AI 写的代码，都能保证质量。反过来说，如果你的质量保证体系很弱，那么即使是人写的代码也可能有问题。

Steve 还提到了一个有趣的预测：如果编码变得容易，而编码历来是产品开发的瓶颈，那么瓶颈就会转移到其他地方。如果编码实际上变得"免费"，代码审查就会变得非常有挑战性。或者，一开始获得足够的想法可能是个大问题，或者分配这些想法也会成为问题。注意力会转移到其他领域。

我非常同意这个观点。我们正在进入一个"编码不再是瓶颈"的时代。那么新的瓶颈是什么？可能是产品想法、可能是需求梳理、可能是架构设计、可能是用户研究。软件工程的关注点会从"怎么实现"转向"做什么"和"为什么做"。这需要工程师培养新的技能：更好的产品思维、更强的沟通能力、更深的业务理解。

机器对机器支付：AI agent 作为经济主体

Steve 在访谈中展示了一个非常前瞻性的场景：AI agent 作为经济主体进行交易。这个场景让我看到了 AI agent 的另一个维度。

在演示中，Steve 要求 Claude 帮他的产品经理 Jen 计划一个生日派对。整个过程是这样的：AI agent 先访问 Jen 的网站了解她的兴趣（她是一个抹茶爱好者和烘焙师），然后搜索纽约的相关场地，生成派对邀请的 PDF，通过 Lob 这样的服务将邀请邮寄出去，最后为了抵消过程中消耗的 token 产生的碳排放，向 Stripe Climate 捐了一笔钱。

整个过程中，AI agent 使用了 Browser Base、Perplexity AI、Lob 等多个第三方服务，每次使用都进行了微支付。这些服务不需要 Steve 提前注册、登录、绑定信用卡、选择套餐。AI agent 直接以按需付费的方式使用这些服务，用多少付多少。最后生成了一张"agent 收据"，显示了使用的每个服务和相应的费用。整个生日派对计划总共花费了 5.47 美元，包括 1.65 美元的碳抵消。

这个场景背后是 Stripe 和 Anthropic 合作设计的机器支付协议（Machine Payment Protocol）。这个协议让 AI agent 可以像经济主体一样行动：不仅消耗 token，还可以为服务付费。

我认为这个方向极其重要，虽然现在看起来还很早期。想象一下未来的商业模式：一个 API 服务的主要客户不是人类，而是 AI agent。这个服务不需要漂亮的 landing page、不需要详细的文档网站、不需要客户支持团队，它只需要一个高度优化的 API 和清晰的定价。AI agent 可以自动发现这个服务、理解如何使用它、评估是否值得付费，然后完成交易。

Steve 提到了一个有趣的细节：Stripe 在与合作伙伴集成机器支付协议时，会要求用户反馈。通常用户会说"我回去写一下反馈"，但这次不同：30 秒内他就收到了两页的反馈。原来工程师用 Claude 或 Cursor 读了 Stripe 的文档，实现了功能，然后又让 AI 写了反馈发给 Steve。这种情况在那一周发生了四五次。Steve 说这非常震撼，给了 AI agent 一种"物理存在感"——你必须直接面对 AI agent 作为新用户的现实。

这让我想到，我们设计 API 的方式可能需要改变。过去我们为人类设计 API，所以会提供详细的文档、代码示例、SDK。未来我们可能需要为 AI agent 设计 API：提供结构化的 schema、清晰的错误信息、符合标准的接口。这不是说文档不重要了，而是说文档的形式和内容可能需要调整。

我对未来的思考

看完 Stripe 的 Minions 系统，我有几个深层次的思考。

我认为我们正在经历的不仅仅是工具的升级，而是工作方式的根本转变。过去一百年，软件工程师的工作本质上是"写代码"。我们学习编程语言、设计模式、算法，我们的价值体现在能写出高质量的代码。但在 AI agent 时代，工程师的核心价值可能会转移。我们的价值不再是"会写代码"，而是"知道应该让 AI 写什么代码"。

这需要完全不同的技能组合。你需要更强的产品思维，能够识别哪些问题值得解决。你需要更好的架构设计能力，能够将复杂问题分解成 AI 可以处理的子任务。你需要更深的业务理解，能够判断 AI 生成的解决方案是否真正解决了业务问题。你还需要更强的审查能力，能够快速评估代码质量和潜在风险。

从 Stripe 的实践来看，我觉得"激活能量"这个概念会变得越来越重要。在 AI 时代，执行变得容易，但决策变得更难。当你可以轻易启动十个项目时，选择启动哪十个项目就成了关键。当代码生成的成本接近于零时，代码质量和架构的价值就会凸显。我们会从"做事"的时代进入"做正确的事"的时代。

我也在思考组织结构的变化。在传统模式下，一个产品经理可能需要协调五个工程师来完成一个功能。在 AI agent 时代，这个产品经理可能直接管理五个 AI agent，工程师的角色转变为"AI agent 的架构师和审查者"。这会让组织变得更扁平，决策链条更短，执行速度更快。但也会带来新的挑战：如何评估 AI agent 的工作质量？如何在 AI 和人之间分配责任？如何培养新一代工程师？

关于 Stripe 提出的机器对机器支付，我觉得这打开了一个全新的商业世界。当 AI agent 可以自主交易时，会出现一大批专门为 AI agent 服务的企业。这些企业的产品可能人类用户永远不会直接接触，但它们通过服务 AI agent 来间接服务人类。这种"ephemeral（短暂的）交互"模式会创造新的商业机会：你不需要建立品牌、不需要获取用户、不需要提高留存率，你只需要提供一个高质量的 API，让 AI agent 在需要时能找到你、信任你、使用你。

最后我想说，Stripe 的 Minions 系统给我最大的启发是：不要等技术完美了再开始使用。Minions 不是百分之百完美的，Steve 也承认有时候 minion 会失败、会需要重试。但他们没有等到技术完全成熟，而是在现有技术基础上构建了一个实用的系统，并在使用中不断改进。每周 1300 个 PR 的数字证明，即使不完美，AI agent 也已经可以创造巨大价值。关键是要开始尝试，在实践中学习，在迭代中进步。

软件工程的未来已经来了，只是分布不均匀。Stripe 的工程师已经生活在这个未来里，而很多公司还在用传统方式写代码。差距会越来越大。我相信在接下来的两三年里，使用 AI agent 的团队和不使用 AI agent 的团队，生产力差距会达到 10 倍甚至更高。这不是危言耸听，这是正在发生的现实。问题不是 AI agent 会不会改变软件工程，而是你的团队什么时候开始拥抱这个变化。

文章来自微信公众号 “ 深思圈 ”