Stripe 執行長科里森：在沙發上隨口做的技術決定，15 年後還在買單

本文整理自 a16z Podcast（原播出於 Cursor Podcast）2026 年 2 月播出的單集。

{{< youtube motX94ztOzo >}}

{{< spotify "episode/6VlwZO6PyspXvBBHmaaNFG" >}}

---

2010 年，兩個愛爾蘭兄弟坐在沙發上，討論新公司要用什麼資料庫。「選 Mongo 吧。」「好。」這段對話大概花了十秒鐘。15 年後，這個隨口做的決定仍然是 Stripe 基礎架構的核心，而這家公司的最新估值已經達到 1,590 億美元。

Stripe 是全球最大的線上支付基礎設施公司之一，為超過 500 萬家企業處理金流，從新創公司到道瓊工業指數成分股中九成的企業都是它的客戶。執行長派翠克．科里森（Patrick Collison）在接受 AI 程式碼編輯器 Cursor 執行長 Michael Truell 的訪談時，坦率地回顧了這些早期技術決策的來龍去脈。他用了一個生動的比喻：新創公司的初期就像宇宙大爆炸，那些疲憊、過度攝取咖啡因的創辦團隊隨手做出的技術選擇，日後將決定數百名工程師的職業生活。科里森認為這個比喻完全適用於 Stripe，而且他有更根本的主張：現代開發環境從 1980 年代的 Smalltalk 和 Lisp 機器倒退了 20 年。

愛爾蘭少年的非主流技術品味

要理解 Stripe 的技術選擇，得先認識做決定的人。科里森 1988 年出生於愛爾蘭蒂珀雷里郡，16 歲就用 Lisp 寫了一套程式語言「Croma」，拿下愛爾蘭青年科學展冠軍。他的弟弟約翰．科里森（John Collison）同樣早慧，在愛爾蘭高中畢業考（Leaving Certificate）拿下史上最高分。兩兄弟 2007 年共同創辦了第一家公司 Auctomatic，一個針對 eBay 大賣家的工具，隔年以 500 萬美元被收購。當時派翠克才 19 歲，約翰 17 歲。

科里森早期深受 Lisp 影響。他讀了彼得．諾維格（Peter Norvig）的《Paradigms of AI Programming》，用 Lisp 寫了一個 MSN Messenger 聊天機器人，靠貝氏機率做下一個詞的預測。機器人沒有通過嚴格的圖靈測試，但在對方不起疑心的情況下，確實騙過不少人，讓他們聊了很長的對話。他也花了大量時間研究遺傳演算法，甚至用它來最佳化鍵盤配置，結果算出來的最佳解基本上就是 Dvorak 鍵盤。科里森和弟弟至今都用 Dvorak，這意味著沒人能借用他們的電腦。

創辦第一家公司時，科里森最初用 Ruby on Rails，但跟 Lisp 比起來覺得開發過程很痛苦。他想找一個支援 continuation-based web framework 的語言，發現 Smalltalk 剛好有一個新寫的框架。試用之後他發現，Smalltalk 不只有 continuation，更有一個極其強大的互動式開發環境，讓他能做到一件在現代開發流程中幾乎不可能的事情。

在執行中修復錯誤，然後繼續跑

Smalltalk 的開發環境有什麼特別？科里森描述的場景是這樣的：你正在處理一個 web request，遇到了一個錯誤。在現代的開發流程中，你得加 log、做二分搜尋找問題、部署修正版本，整個過程可能花一個小時。但在 Smalltalk 裡，你可以直接檢查當前的 stack frame，看哪個變數的值不對，當場修改程式碼，然後跳回 stack 的上層，按下「繼續執行」，整個 web request 就會順利完成。

這種能力來自 Smalltalk 的 first-class stack frames，也就是把呼叫堆疊本身當作可以操作的物件。配合完全互動式的除錯器，開發者和程式的執行狀態之間沒有隔閡。科里森認為 Lisp 機器、Mathematica 和 Smalltalk 都有這種「開發環境」而非「文字編輯器」的本質，而現代開發工具犯了一個根本性的錯誤：把 runtime、編輯器和程式碼執行環境拆成了三個分離的東西。

有人問這家用 Smalltalk 寫的公司後來怎樣了。那家公司被收購時主要是人才收購，程式碼基本上被丟掉了。至於招人困難的問題，科里森說沒人進來之前就會 Smalltalk，但聰明的人學程式語言很快，所以他不認為語言冷門是不用它的理由。公司沒做起來，但原因跟語言選擇無關，純粹是「點子不夠強」。

過去 20 年，開發環境幾乎沒有進步

科里森的核心主張是，他希望看到「開發環境」這個概念的回歸，而不只是一個更好的文字編輯器。他想在 Cursor 裡看到的東西非常具體：當他把滑鼠移到某行程式碼上時，他想看到這段程式碼的 profiling 資訊和執行時特徵；當他 hover 某個變數時，他想看到這個變數在正式環境中最常出現的值；他想看到 logging 和錯誤資訊直接疊在程式碼上面。這些功能在 1980 年代的 Lisp 機器上就已經存在了。

他提到了 Bret Victor 的知名演講「Inventing on Principle」和他的 Dynamicland 計畫。科里森是 Victor 的支持者，但也指出一個差異：Victor 非常強調圖形化和視覺化的表達方式，這在某些動態系統的展示中效果很好，但科里森覺得要為 Stripe 這種任意系統找到有用的空間化、連續性表達並不容易。他自己的思考方式更偏向符號和文字，而非視覺和圖形。不過他強調，Victor 那種打破典範的探索精神本身就非常值得敬佩。

讓科里森困惑的是，過去 20 年開發者人數暴增，Rust、Go 等新語言在語言層面做了很多創新，JavaScript 生態系透過 Web Inspector 也算朝整合環境邁了一步，但在開發環境的根本範式上，實驗的幅度遠比他預期的小。VS Code 往那個方向走了一點，但他認為還可以走得更遠。他半開玩笑地說，也許 Cursor 的成功某種程度上就是因為他們是第一批「在很長一段時間後認真對待這件事」的人。

API 設計就是商業策略

從開發環境的討論轉到 Stripe 的營運，科里森提出了一個更有衝擊力的觀點：如果讓他重來一次，他會在 API 和資料模型上花更多時間。這不只是工程品質的問題，而是商業策略的問題。

他提出了 Conway's Law 的「強版本」。弱版本說的是軟體架構會反映組織結構，這已經是老生常談。但科里森認為，API 和資料模型不只塑造組織結構，更直接決定了商業策略和經營結果。他舉的例子是 iOS 和 Android 生態系。很長一段時間裡，儘管 Android 裝置數量遠多於 iOS，但 app 開發者偏好先做 iOS 版本，iOS 版本的品質也往往更好。科里森認為，這種差異有很大一部分要歸因於 iOS 的 framework 和抽象設計從一開始就比 Android 好。iOS 的早期版本中，許多類別的前綴是 NS，代表 NeXTSTEP，也就是賈伯斯在 NeXT 時期的設計遺產。好的 API 設計可以存活超過 20 年。

這個觀察對 Stripe 自身格外諷刺。Stripe 是以開發者友善的 API 聞名的公司，處理全球超過 1.9 兆美元的交易額。但科里森坦承，他們 15 年前設計的某些核心抽象並不是最好的長期方案，而且至今仍在為此付出代價。

V2 API 遷移：不是產品發表，是指令集遷移

2022 年，Stripe 啟動了一項重大的 API 重新設計。公司從 2010 年起使用的 REST API 都以 /v1 作為路徑前綴，現在他們終於開始使用 /v2。表面上看，這只是版本號加一。實際上，這是一場持續數年的工程戰役。

V2 API 解決的核心問題是實體表達的統一。過去 Stripe 對「客戶」「子帳號」「收款人」用了不同的資料結構來表達，這在 15 年前看起來合理，但隨著業務擴展，這些人為的區隔變成了束縛。V2 API 把這些概念統一成同一種實體模型，讓使用者的帳號可以跨國使用、不用重新輸入資料。從商業角度看，這直接改變了 Stripe 客戶能為他們的使用者做到的事情。

但科里森強調，定義新的 API 本身是容易的部分。困難在於讓新舊 API 共存。他用了一個精準的比喻：這更像是晶片架構的指令集遷移，而不是一次產品發表。指令集本身設計起來不難，難的是所有「共存問題」。Stripe 控制自己的程式碼，但不控制客戶的程式碼。數以萬計的企業已經在舊 API 上建構了完整的整合，你不能突然告訴他們全部重寫。

為了避免過度工程化，Stripe 的做法是強迫自己用新的 API 實際撰寫各種商業流程和整合程式碼，確保設計在實務中感覺對。他們也把早期版本給客戶看，收集回饋。科里森從這個過程中得到的一個「老生常談但真的很重要」的教訓是：任何可能是多對多關係的東西，從一開始就該支援多對多。即便你覺得不可能出現某種排列組合，但只要 API 存在夠久，每一種排列組合最終都會被使用者探索到。

截至訪談時，V2 遷移大約完成了 60% 到 70%。科里森說他感到非常樂觀，但不想過早宣布勝利。

44 秒停機，以及對 Cursor 的三個願望

儘管早期技術選擇帶來了種種挑戰，Stripe 的工程團隊確實讓這些選擇運作得很好。科里森提到，Stripe 過去一年的關鍵 API 可用性達到 99.99986%，換算下來全年只有 44 秒的停機時間。他相信這是業界最佳，雖然其他公司不太公布這麼細的數據。要在 MongoDB 上達到這種可靠性，背後是 Stripe 儲存團隊和許多其他團隊多年的基礎建設投資。

訪談結尾，Truell 問科里森希望 Cursor 為 Stripe 做什麼。科里森給了三個願望。第一，他想要更深的 runtime 整合：把 profiling、logging 和正式環境的資料直接疊在編輯器裡的程式碼上，回到他一直提倡的「開發環境」範式。第二，他想要 AI 驅動的重構和美化功能。他提到一個畫面：白天你快速產出程式碼，品質也許不完美，然後 AI 在夜裡悄悄把你的程式碼整理得漂亮、結構正確。如果 AI 能降低未來變更的成本，那對 Stripe 這種大規模程式碼庫的自由度將是巨大的提升。

第三個願望更哲學一點。科里森說 Stripe 很在意他們稱為「craft and beauty」的東西，他們希望自己的軟體不只能用，而且好用、漂亮、值得信賴。他擔心 AI 可能帶來更多「slop」（低品質軟體），而不是更多最好的軟體。他不確定 Cursor 具體該怎麼做，但他希望開發工具能幫助世界創造更高品質的軟體，而不只是更多的軟體。

我的觀察

科里森的故事裡有一個持續出現的張力：他的技術品味是非主流的（Smalltalk、Lisp、自己寫資料庫），但每次創業都會往主流方向妥協一步。從 Smalltalk 退到 Ruby，從自製物件資料庫退到 MongoDB。這不是放棄原則，而是承認：當你要建造一個服務數百萬企業的基礎設施時，你的個人偏好必須和組織的長期可維護性取得平衡。

但即便做了這些妥協，這些「相對主流」的選擇仍然定義了 Stripe 15 年後的技術面貌。Ruby 仍然是核心語言，MongoDB 仍然是核心資料庫。V2 API 遷移仍然只完成了六七成。早期技術決策的半衰期，比大多數創辦人以為的長得多。這也許是科里森這整場訪談最實用的一個提醒：你在沙發上花十秒鐘做的決定，你的工程團隊可能花十年才能改掉。