一周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 對話開始，這些才是更自然的工作起點。等到需要真正動手寫代碼或做最后調整時，才會進入文本編輯器。這種工作方式的轉變，讓啟動一項工作的激活能量大大降低。

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

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

什么是 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）。在化學反應中，激活能量是指啟動反應所需的最小能量。在軟件開發中，激活能量就是從"有一個想法"到"開始動手"之間的那道門檻。

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

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

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 計劃捆綁在一起�，F在 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 時，我的第一個問題是：你們怎么審查這么多代碼？這是一個非�，F實的挑戰。

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 會不會改變軟件工程，而是你的團隊什么時候開始擁抱這個變化。

結尾

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

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

歡迎關注深思圈，一起探索更大的世界。