一周1300多個PR，揭秘Stripe內(nèi)部AI工程最佳實踐

想象一下這個場景：你在地鐵上刷著 Slack，看到一個需要修復的 bug。你點一個 emoji 表情，等到了辦公室，代碼已經(jīng)寫好、測試通過，Pull Request 等著你審查。這不是科幻小說，這是 Stripe 工程師每天的真實工作狀態(tài)。更震撼的是，Stripe 每周有大約 1300 個代碼合并請求完全由 AI agent 完成，工程師只負責審查，一行代碼都不用自己寫。

當我第一次聽到這個數(shù)字時，我的反應是：這怎么可能？1300 個 PR，每周？要知道很多小型工程團隊一個月可能都合并不了這么多代碼。但當我深入了解 Stripe 的 Minions 系統(tǒng)后，我意識到這不僅可能，而且代表著軟件工程的一個根本性轉(zhuǎn)變。我們正在從"工程師寫代碼"轉(zhuǎn)向"工程師管理 AI 寫代碼"，這個轉(zhuǎn)變的速度比我想象的要快得多。

Stripe 的軟件工程師 Steve Kaliski 在最近的一次訪談中分享了他們?nèi)绾螛?gòu)建和使用這套系統(tǒng)。Steve 在 Stripe 工作了六年半，一直專注于開發(fā)者工具和支付基礎設施的建設。他提到一個非常有意思的觀察："我已經(jīng)不記得上次是從文本編輯器開始工作是什么時候了。"他的工作通常從 Google 文檔、Jira 工單或者 Slack 對話開始，這些才是更自然的工作起點。等到需要真正動手寫代碼或做最后調(diào)整時，才會進入文本編輯器。這種工作方式的轉(zhuǎn)變，讓啟動一項工作的激活能量大大降低。

PS：我的出海新書已經(jīng)上架了，我特意申請了公眾號讀者專屬的優(yōu)惠鏈接，可以享受半價折扣，歡迎感興趣的朋友購買。

同時我還特地建立了實名制的讀者群，我會在群里定期解答一些問題和開展線上線下活動，歡迎購書的朋友實名制入群，大家一塊交流，共同出海！

什么是 Minions

Minions 是 Stripe 自研的全自動編碼 AI agent（智能代理）。它們被設計成"一次性完成"任務的系統(tǒng)，從接到指令到提交代碼、通過測試、創(chuàng)建 PR，整個過程完全無人參與。Steve 解釋說，在 AI 時代之前，當他作為工程師想要修改 Stripe 的代碼時，會面對一個巨大的代碼庫，包含數(shù)百個服務，這些服務根本無法在個人電腦上運行。所以 Stripe 很早就投資建設了優(yōu)秀的開發(fā)者工具，提供了托管的開發(fā)環(huán)境 devbox（開發(fā)盒子），工程師可以快速啟動一個環(huán)境，里面已經(jīng)有所有代碼和運行中的服務。

Minions 的核心思路是：我可以提供一個 prompt（提示詞）來啟動這樣一個環(huán)境，然后 minion 會嘗試一次性解決這個 prompt，使用 Stripe 內(nèi)部所有可用的工具、內(nèi)部文檔、CI 系統(tǒng)、測試數(shù)據(jù)等等。它會循環(huán)執(zhí)行這個過程，直到解決問題。這種"一次性"的設計哲學非常重要，因為它意味著從用戶提出需求到代碼準備好審查，中間不需要任何人工干預。

從使用體驗來看，一個典型的 minion 運行流程是這樣的：工程師在 Slack 頻道里發(fā)一條消息，比如"我想改進 docs.stripe.com/payment/machine 這個文檔頁面，讓代碼示例更清晰"。然后在這條消息下點擊一個特定的 emoji 反應，比如"create minion pay-server"。系統(tǒng)就會自動創(chuàng)建一個新分支，啟動開發(fā)環(huán)境，minion 開始工作。你可以點擊"follow along"鏈接實時查看進度，看到它正在配置環(huán)境、檢查代碼庫、執(zhí)行修改、運行測試、提交代碼。整個過程可能需要幾分鐘到十幾分鐘，但工程師不需要盯著看，可以去做其他事情。等 minion 完成后，你會收到通知，打開 PR 審查代碼即可。

我覺得這種交互方式的轉(zhuǎn)變意義深遠。過去我們總是強調(diào)"開發(fā)者體驗"，但往往局限在 IDE 好不好用、命令行工具是否順手。而 Minions 讓我重新思考：真正好的開發(fā)者體驗應該是什么？也許不是讓寫代碼變得更容易，而是讓"不寫代碼"變得可能。當你可以用自然語言描述需求，系統(tǒng)就能自動完成實現(xiàn)，這才是開發(fā)者體驗的終極形態(tài)。

為什么 Stripe 要自己構(gòu)建

市面上已經(jīng)有很多優(yōu)秀的 AI 編碼工具，比如 Cursor、Claude Code、GitHub Copilot 等等。為什么 Stripe 還要花力氣自己構(gòu)建 Minions？Steve 給出了一個非常務實的回答：從零開始快速搭建原型和在 Stripe 的代碼庫上貢獻代碼，是完全不同的兩回事。

Stripe 的代碼庫規(guī)模驚人，包含數(shù)億行代碼，分布在幾個大型代碼倉庫中。大部分后端代碼用 Ruby 寫的，但不是常見的 Rails 框架，而是配合 Sorbet 類型系統(tǒng)，這是一個相對小眾的技術(shù)棧。整個代碼庫使用了大量 Stripe 自研的內(nèi)部庫，這些庫對于大語言模型來說是完全陌生的。更關(guān)鍵的是，這些代碼每年處理超過 1 萬億美元的支付交易量，運行在生產(chǎn)環(huán)境中。同時，Stripe 還要面對金融機構(gòu)的復雜依賴關(guān)系，以及嚴格的監(jiān)管合規(guī)要求。

這些約束條件讓問題變得復雜得多。LLM 在構(gòu)建全新軟件時表現(xiàn)很好，特別是當系統(tǒng)約束相對較少的時候。但在 Stripe 這樣規(guī)模、復雜度和成熟度的代碼庫上迭代，難度要高得多。人類工程師需要建立復雜的心智模型才能有效地修改代碼，而讓 AI agent 在有限的上下文窗口內(nèi)形成正確的直覺、使用正確的工具，挑戰(zhàn)非常大。

我深有同感。我自己在做產(chǎn)品時也遇到過類似問題。當你的代碼庫還很小的時候，AI 工具確實能幫你快速搭建原型。但隨著代碼庫增長、業(yè)務邏輯變復雜、技術(shù)債務累積，AI 工具的效果就會大打折扣。它可能給你生成看起來正確的代碼，但實際上違反了你們內(nèi)部的最佳實踐，或者用了已經(jīng)廢棄的庫，或者沒有考慮到特定的邊界情況。這時候你需要的不是一個通用的 AI 助手，而是一個"懂你的代碼庫"的專屬 AI。

Stripe 的解決方案是在開發(fā)者工具基礎設施上的長期投資。多年來，他們建設了完善的開發(fā)者生產(chǎn)力工具，覆蓋源代碼管理、開發(fā)環(huán)境、代碼生成、CI 系統(tǒng)等開發(fā)生命周期的各個階段。Minions 緊密集成了這些工具。這印證了一個重要原則：對人類有用的工具，對 LLM 也有用。

降低激活能量的意義

Steve 提到了一個讓我深有感觸的概念：激活能量（activation energy）。在化學反應中，激活能量是指啟動反應所需的最小能量。在軟件開發(fā)中，激活能量就是從"有一個想法"到"開始動手"之間的那道門檻。

在大型組織中，這個門檻特別高。一個好想法要變成現(xiàn)實，中間可能有無數(shù)摩擦?？赡苁锹毮苷系K：你需要某個技術(shù)領(lǐng)域的專業(yè)知識，但你沒有。可能是操作障礙：你不知道如何組織人員、如何有效溝通來推進下一步。也可能只是因為人們被日常工作束縛，沒有想到新的做事方式。

我在自己的創(chuàng)業(yè)經(jīng)歷中經(jīng)常遇到這種情況。有時候團隊討論出一個很好的改進點，大家都覺得應該做，但就是一直沒有人開始。不是因為任務太難，而是因為啟動它需要太多步驟：創(chuàng)建任務、分配給某人、等他有空、排期、開會討論細節(jié)、寫設計文檔、開始編碼...這個流程走下來可能要幾周。很多時候不是執(zhí)行難，而是啟動難。

Minions 的價值就在于把激活能量降到接近零。在 Slack 對話中看到一個用戶反饋，覺得應該更新文檔或者做一個原型？點一下 emoji，工作就開始了，往往工作也會自己完成。即使沒有完全完成，至少代碼開始運行、測試開始執(zhí)行，你可以中途介入、進行調(diào)整，利用那種"生成性動力"。Steve 說，這種感覺就像你可以在半路跳進一輛已經(jīng)啟動的車，而不是從零開始推車。

更重要的是，低激活能量意味著高并行度。Steve 提到，他可以在同一時間啟動多個 minion，讓它們在隔離的環(huán)境中同時處理不同的任務。這在傳統(tǒng)開發(fā)模式下幾乎不可能。你的本地機器資源有限，開太多分支會讓電腦卡得像飛機起飛。但在云端環(huán)境中，你可以同時運行十幾個 minion，每個處理一個獨立的任務。想象一下，你在周一早上啟動五個 minion 處理五個不同的 bug，到中午時它們都完成了，你只需要逐個審查和合并。

我認為這種"批量并行"的工作方式會徹底改變軟件工程的節(jié)奏。過去我們習慣了線性工作：一個任務接一個任務。現(xiàn)在我們可以像項目經(jīng)理一樣思考：同時啟動多個工作流，管理它們的進度，在需要的時候介入。工程師的角色正在從"執(zhí)行者"轉(zhuǎn)向"編排者"。

開發(fā)者體驗的雙向價值

在演示中，Steve 特別強調(diào)了一個觀點：好的開發(fā)者體驗對人類和 AI agent 都有價值。這個觀點聽起來簡單，但含義深刻。

Stripe 的 devbox 系統(tǒng)不是為 AI 設計的，而是多年前為了解決人類工程師的實際需求而建設的。Stripe 的代碼庫太大了，無法在本地機器上運行所有服務。所以他們建立了云端開發(fā)環(huán)境，工程師通過 SSH 連接到這些環(huán)境工作。一個工程師可能同時有五六個 devbox 在運行，每個對應一個不同的任務。這些環(huán)境在 10 秒內(nèi)就能準備就緒，預先克隆了龐大的 git 倉庫，預熱了構(gòu)建緩存和類型檢查緩存，啟動了代碼生成服務。

這種基礎設施原本是為了人類工程師的并行工作、可預測性和隔離性而建設的。但當 AI agent 出現(xiàn)時，這些特性突然變得更加重要。Minions 天然地繼承了這些優(yōu)勢：每個 minion 在獨立的 devbox 中運行，互不干擾；可以輕松并行運行多個 minion；環(huán)境是標準化的，不會因為個人配置不同而產(chǎn)生問題。

我想起之前和一個朋友聊天，他在一家大公司負責開發(fā)者工具。他說他們團隊最難的事情不是技術(shù)實現(xiàn)，而是爭取資源。產(chǎn)品團隊總是優(yōu)先做面向用戶的功能，開發(fā)者工具的優(yōu)先級永遠排在后面。我當時給他的建議是：把開發(fā)者工具項目和 AI 計劃捆綁在一起。現(xiàn)在 AI 是最熱門的方向，如果你說"我們需要改進開發(fā)者體驗來支持 AI agent"，批預算就容易多了。

Steve 也提到了這個策略。他說很多公司問他們?nèi)绾伍_始做 AI 編碼，他的回答總是：先把開發(fā)者體驗搞好。如果你的開發(fā)環(huán)境很糟糕、文檔很差、工具鏈很亂，那就算給你最好的 AI agent 也沒用。但如果你已經(jīng)有了完善的開發(fā)者工具，那接入 AI agent 就是水到渠成的事。這形成了一個良性循環(huán)：為人類建設更好的工具，AI 就能更好地使用這些工具；為 AI 改進工具，人類也會從中受益。

云環(huán)境的關(guān)鍵作用

關(guān)于云開發(fā)環(huán)境的重要性，我想多說幾句，因為這是很多人容易忽視的一點。

Steve 半開玩笑地說，不管你的 MacBook Pro 有多強大，當你開三四個工作樹（worktree）時，電腦就開始像飛機起飛一樣轟鳴，根本不行。我對此感同身受。我自己就有四臺 Mac Mini，其中一臺基本上就是"永不合上的筆記本"，專門用來跑長時間任務。這聽起來有點荒謬，但確實解鎖了我的生產(chǎn)力。

Steve 提到他甚至可以在上班路上用手機刷 Slack 時啟動一個 minion，等到了辦公室，工作已經(jīng)進行到一半了，他可以直接接手。這種工作方式在傳統(tǒng)的本地開發(fā)模式下是不可能的。你的筆記本在包里，怎么運行代碼？但在云端環(huán)境中，你的開發(fā)環(huán)境 24 小時在線，隨時可以啟動新任務。

我認為在多線程的 AI 輔助工程工作中，云環(huán)境和虛擬環(huán)境是解鎖速度的關(guān)鍵。但我看到很多大型工程團隊還沒有在這方面投資。他們的工程師還在本地機器上掙扎，試圖同時運行多個 AI 工具、多個工作樹。這就像試圖在一輛自行車上跑高速公路。

如果你是 CTO 或工程副總裁，想要在明年真正釋放團隊的生產(chǎn)力，投資云開發(fā)環(huán)境應該是首要任務。這不僅僅是為了 AI，也是為了團隊的整體效率。想象一下，新員工入職第一天，點一個按鈕就能得到一個完整配置好的開發(fā)環(huán)境，而不是花三天時間配置本地環(huán)境。想象一下，你的工程師可以同時在五個項目上并行工作，而不是在本地來回切換分支。這些投資的回報會遠超你的想象。

代碼審查的規(guī)模化挑戰(zhàn)

當我聽到 Stripe 每周合并 1300 個 AI 寫的 PR 時，我的第一個問題是：你們怎么審查這么多代碼？這是一個非常現(xiàn)實的挑戰(zhàn)。

Steve 的回答很務實。他說，如果工程師花在寫代碼上的時間變少了，自然就有更多時間審查代碼，或者和用戶交流等等。但更重要的是 CI 環(huán)境的作用。Stripe 有非常好的測試覆蓋率，有大量端到端的合成測試來模擬與產(chǎn)品的交互，這些都能為代碼審查提供信心。

他強調(diào)了一個關(guān)鍵點：不管代碼是 Steve 寫的還是 Steve 的機器人寫的，你都需要那個 CI 環(huán)境來提供信心，確保代碼變更是安全的。部署時要使用藍綠部署，這樣可以回滾。所有這些都是超級關(guān)鍵的，而且與代碼作者是誰無關(guān)。

這個觀點讓我重新思考"AI 寫的代碼是否可信"這個問題。很多人擔心 AI 寫的代碼質(zhì)量不夠好，會引入 bug。但其實問題的關(guān)鍵不在于誰寫的代碼，而在于你的質(zhì)量保證體系是否完善。如果你有完善的測試、完善的 CI/CD、完善的監(jiān)控和回滾機制，那么不管是人寫的代碼還是 AI 寫的代碼，都能保證質(zhì)量。反過來說，如果你的質(zhì)量保證體系很弱，那么即使是人寫的代碼也可能有問題。

Steve 還提到了一個有趣的預測：如果編碼變得容易，而編碼歷來是產(chǎn)品開發(fā)的瓶頸，那么瓶頸就會轉(zhuǎn)移到其他地方。如果編碼實際上變得"免費"，代碼審查就會變得非常有挑戰(zhàn)性。或者，一開始獲得足夠的想法可能是個大問題，或者分配這些想法也會成為問題。注意力會轉(zhuǎn)移到其他領(lǐng)域。

我非常同意這個觀點。我們正在進入一個"編碼不再是瓶頸"的時代。那么新的瓶頸是什么？可能是產(chǎn)品想法、可能是需求梳理、可能是架構(gòu)設計、可能是用戶研究。軟件工程的關(guān)注點會從"怎么實現(xiàn)"轉(zhuǎn)向"做什么"和"為什么做"。這需要工程師培養(yǎng)新的技能：更好的產(chǎn)品思維、更強的溝通能力、更深的業(yè)務理解。

機器對機器支付：AI agent 作為經(jīng)濟主體

Steve 在訪談中展示了一個非常前瞻性的場景：AI agent 作為經(jīng)濟主體進行交易。這個場景讓我看到了 AI agent 的另一個維度。

在演示中，Steve 要求 Claude 幫他的產(chǎn)品經(jīng)理 Jen 計劃一個生日派對。整個過程是這樣的：AI agent 先訪問 Jen 的網(wǎng)站了解她的興趣（她是一個抹茶愛好者和烘焙師），然后搜索紐約的相關(guān)場地，生成派對邀請的 PDF，通過 Lob 這樣的服務將邀請郵寄出去，最后為了抵消過程中消耗的 token 產(chǎn)生的碳排放，向 Stripe Climate 捐了一筆錢。

整個過程中，AI agent 使用了 Browser Base、Perplexity AI、Lob 等多個第三方服務，每次使用都進行了微支付。這些服務不需要 Steve 提前注冊、登錄、綁定信用卡、選擇套餐。AI agent 直接以按需付費的方式使用這些服務，用多少付多少。最后生成了一張"agent 收據(jù)"，顯示了使用的每個服務和相應的費用。整個生日派對計劃總共花費了 5.47 美元，包括 1.65 美元的碳抵消。

這個場景背后是 Stripe 和 Anthropic 合作設計的機器支付協(xié)議（Machine Payment Protocol）。這個協(xié)議讓 AI agent 可以像經(jīng)濟主體一樣行動：不僅消耗 token，還可以為服務付費。

我認為這個方向極其重要，雖然現(xiàn)在看起來還很早期。想象一下未來的商業(yè)模式：一個 API 服務的主要客戶不是人類，而是 AI agent。這個服務不需要漂亮的 landing page、不需要詳細的文檔網(wǎng)站、不需要客戶支持團隊，它只需要一個高度優(yōu)化的 API 和清晰的定價。AI agent 可以自動發(fā)現(xiàn)這個服務、理解如何使用它、評估是否值得付費，然后完成交易。

Steve 提到了一個有趣的細節(jié)：Stripe 在與合作伙伴集成機器支付協(xié)議時，會要求用戶反饋。通常用戶會說"我回去寫一下反饋"，但這次不同：30 秒內(nèi)他就收到了兩頁的反饋。原來工程師用 Claude 或 Cursor 讀了 Stripe 的文檔，實現(xiàn)了功能，然后又讓 AI 寫了反饋發(fā)給 Steve。這種情況在那一周發(fā)生了四五次。Steve 說這非常震撼，給了 AI agent 一種"物理存在感"——你必須直接面對 AI agent 作為新用戶的現(xiàn)實。

這讓我想到，我們設計 API 的方式可能需要改變。過去我們?yōu)槿祟愒O計 API，所以會提供詳細的文檔、代碼示例、SDK。未來我們可能需要為 AI agent 設計 API：提供結(jié)構(gòu)化的 schema、清晰的錯誤信息、符合標準的接口。這不是說文檔不重要了，而是說文檔的形式和內(nèi)容可能需要調(diào)整。

我對未來的思考

看完 Stripe 的 Minions 系統(tǒng)，我有幾個深層次的思考。

我認為我們正在經(jīng)歷的不僅僅是工具的升級，而是工作方式的根本轉(zhuǎn)變。過去一百年，軟件工程師的工作本質(zhì)上是"寫代碼"。我們學習編程語言、設計模式、算法，我們的價值體現(xiàn)在能寫出高質(zhì)量的代碼。但在 AI agent 時代，工程師的核心價值可能會轉(zhuǎn)移。我們的價值不再是"會寫代碼"，而是"知道應該讓 AI 寫什么代碼"。

這需要完全不同的技能組合。你需要更強的產(chǎn)品思維，能夠識別哪些問題值得解決。你需要更好的架構(gòu)設計能力，能夠?qū)碗s問題分解成 AI 可以處理的子任務。你需要更深的業(yè)務理解，能夠判斷 AI 生成的解決方案是否真正解決了業(yè)務問題。你還需要更強的審查能力，能夠快速評估代碼質(zhì)量和潛在風險。

從 Stripe 的實踐來看，我覺得"激活能量"這個概念會變得越來越重要。在 AI 時代，執(zhí)行變得容易，但決策變得更難。當你可以輕易啟動十個項目時，選擇啟動哪十個項目就成了關(guān)鍵。當代碼生成的成本接近于零時，代碼質(zhì)量和架構(gòu)的價值就會凸顯。我們會從"做事"的時代進入"做正確的事"的時代。

我也在思考組織結(jié)構(gòu)的變化。在傳統(tǒng)模式下，一個產(chǎn)品經(jīng)理可能需要協(xié)調(diào)五個工程師來完成一個功能。在 AI agent 時代，這個產(chǎn)品經(jīng)理可能直接管理五個 AI agent，工程師的角色轉(zhuǎn)變?yōu)?AI agent 的架構(gòu)師和審查者"。這會讓組織變得更扁平，決策鏈條更短，執(zhí)行速度更快。但也會帶來新的挑戰(zhàn)：如何評估 AI agent 的工作質(zhì)量？如何在 AI 和人之間分配責任？如何培養(yǎng)新一代工程師？

關(guān)于 Stripe 提出的機器對機器支付，我覺得這打開了一個全新的商業(yè)世界。當 AI agent 可以自主交易時，會出現(xiàn)一大批專門為 AI agent 服務的企業(yè)。這些企業(yè)的產(chǎn)品可能人類用戶永遠不會直接接觸，但它們通過服務 AI agent 來間接服務人類。這種"ephemeral（短暫的）交互"模式會創(chuàng)造新的商業(yè)機會：你不需要建立品牌、不需要獲取用戶、不需要提高留存率，你只需要提供一個高質(zhì)量的 API，讓 AI agent 在需要時能找到你、信任你、使用你。

最后我想說，Stripe 的 Minions 系統(tǒng)給我最大的啟發(fā)是：不要等技術(shù)完美了再開始使用。Minions 不是百分之百完美的，Steve 也承認有時候 minion 會失敗、會需要重試。但他們沒有等到技術(shù)完全成熟，而是在現(xiàn)有技術(shù)基礎上構(gòu)建了一個實用的系統(tǒng)，并在使用中不斷改進。每周 1300 個 PR 的數(shù)字證明，即使不完美，AI agent 也已經(jīng)可以創(chuàng)造巨大價值。關(guān)鍵是要開始嘗試，在實踐中學習，在迭代中進步。

軟件工程的未來已經(jīng)來了，只是分布不均勻。Stripe 的工程師已經(jīng)生活在這個未來里，而很多公司還在用傳統(tǒng)方式寫代碼。差距會越來越大。我相信在接下來的兩三年里，使用 AI agent 的團隊和不使用 AI agent 的團隊，生產(chǎn)力差距會達到 10 倍甚至更高。這不是危言聳聽，這是正在發(fā)生的現(xiàn)實。問題不是 AI agent 會不會改變軟件工程，而是你的團隊什么時候開始擁抱這個變化。

結(jié)尾

也歡迎大家留言討論，分享你的觀點！

覺得內(nèi)容不錯的朋友能夠幫忙右下角點個贊，分享一下。您的每次分享，都是在激勵我不斷產(chǎn)出更好的內(nèi)容。

歡迎關(guān)注深思圈，一起探索更大的世界。