Cursor x Stripe：AI 如何创造「好的软件」，而不只是「更多软件」？

用 Lisp 写的 AI 聊天机器人、拿 Smalltalk 搭建第一家公司、因为讨厌 SQL 而选择了 MongoDB……

这些经历，全部出自 Patrick Collison——全球支付巨头 Stripe 的 CEO 兼联合创始人，他是「软件行业实业家」，堪称开发者的天花板。

最近，他与 AI 编程工具 Cursor 的 CEO Michael Truell 坐在一起讨论了编程的未来。

从上世纪 70 年代的编程语言遗产，到 Stripe 内部从未披露的重大技术决策，再到 AI 对生产力、生物科技乃至人类未来的深远影响。

Patrick 复盘了 Stripe 早期的技术选型，为何选择了 Ruby 和 MongoDB，以及后来几乎要迁移到 Java 的内部挣扎。他还首次公开了 Stripe 正在进行的 V2 版本 API 重写计划。

更重要的是，他分享了自己作为一名顶级 CEO 和资深程序员，究竟如何使用 AI、如何看待 AI 对编程范式的影响，以及对 AI 编程工具的终极期望——不仅仅是产出更多代码，而是创造更优质、更具美感的软件。

从 Smalltalk 和 Lisp 开始的编程启蒙

很多人可能不知道，Patrick 的技术生涯起点相当「复古」。

他的第一个创业项目，代码库竟然是用 Smalltalk 构建的。

我不觉得这有什么需要解释的，它就是最好的编程语言。

Patrick 对 Smalltalk 的推崇溢于言表。故事要从他更早接触的 Lisp 说起。在创建第一家公司之前，他曾沉浸于 Lisp 和 Lisp Web 框架。当团队最初尝试用 Rails 构建产品时，他发现开发体验远不如 Lisp 那般丝滑。

他认为，基于「Continuation」的 Web 框架才是构建 Web 应用的正确方式。然而，当时的 Ruby 生态里没有成熟的 Continuation 框架。寻寻觅觅之下，他发现 Smalltalk 中正好有一个新出炉的优秀实现。

这一发现，为他打开了新世界的大门。

他意识到 Smalltack 不仅仅是一门语言，更是一个极其强大的开发环境。它继承了 Lisp 的许多精髓，比如一个完全交互式的环境和强大的调试器。

你可以在处理某个 Web 请求的过程中，或者在深入某个堆栈跟踪时直接编辑代码。比如，一个 Web 请求出错了，你可以直接修改代码修复这个错误，然后从堆栈的上一层恢复执行，整个请求就能顺利完成。

这与当时主流的开发流程形成了鲜明对比。传统方式下，开发者需要添加日志、进行二分查找定位问题、部署修复版本，整个反馈循环可能长达一小时。而在 Smalltalk 环境中，你只需检查堆栈帧，看到哪个变量值不对，修复它，跳回上层，点击「继续」，一切就搞定了。

尽管选择 Smalltalk 这样的小众语言，在招聘上看起来是个「糟糕的决定」，但 Patrick 发现这并非障碍。「没人懂 Smalltalk，但教起来很容易。聪明人学语言很快。」

最终，这家公司因为商业模式不够清晰而失败，与技术选型无关。后来，他们为 Stripe 选择了 Ruby，Patrick 回顾说，「也许 Smalltalk 带来的收益，并没有我当时想象的那么巨大。」

而在接触 Smalltalk 之前，Patrick 的另一个早期项目，则与 AI 直接相关。他用 Lisp 写了一个 AI 聊天机器人，一个运行在当时风靡一时的 MSN Messenger 上的小程序。

这个机器人的原理很简单，是一个基础的贝叶斯下一词预测器。其特别之处在于，它的训练数据主要来自与用户在 MSN 上的实时对话，而非通用的文本语料库。

它从未真正通过图灵测试，Patrick 坦言，但对于那些没有戒心的用户来说，他们经常会和它进行很长时间的对话。

这段经历让他深入了解了 Lisp，Peter Norvig 的《Paradigms of AI Programming》（人工智能编程范式）成了他的启蒙读物。有趣的是，他当时并未深入研究神经网络，反而对遗传算法兴趣浓厚。他甚至用遗传算法写了一个优化器，来寻找最优的键盘布局，最终的结果与他正在使用的 Dvorak 布局惊人地一致。

这可能就是我没有创造出 ChatGPT 的原因吧，当然可能还有 70 个其他原因。他笑着说。

编程的未来：回归「集成开发环境」

早在 2008 年，Patrick 就曾预测，主流的 C 风格编程语言会越来越多地从那些古老、小众的语言中借鉴思想。十几年过去，这个预言在 JavaScript 和 Python 生态中得到了验证。

但他认为，我们借鉴得还远远不够。

一个被遗忘的核心思想是：IDE 应该是一个真正的「开发环境」，而不仅仅是一个文本编辑器。

这正是 Lisp Machines 和 Smalltalk 所拥有的，也是 Mathematica 在某种程度上所体现的。我们最终走向了运行时 (runtime) 和文本编辑相分离的开发模式，我认为这是一个巨大的错误。

他渴望看到一种回归。在这种理想的环境中，当他将鼠标悬停在一行代码上时，他希望看到：

• • 这行代码或这个函数的运行时性能特征。
• • 覆盖在代码之上的日志和错误信息。
• • 当鼠标悬停在一个变量上时，能看到它在生产环境中最常见的值。

这是一种与运行时深度、丰富的集成。VS Code 在某种程度上朝这个方向迈出了一步，但 Patrick 认为可以走得更远。

这自然引出了对 Brett Victor 和他著名的 Dynamicland 项目的讨论。Patrick 是 Brett 的忠实粉丝和支持者，但他对 Brett 极力推崇的「图形化和视觉化表达」持保留意见。

我认为这在某些领域非常有效，比如他用来演示思想的那些动态系统。Patrick 解释说，但对于像 Stripe 内部的许多抽象系统，我很难想象出有用的空间化、连续性表达是什么样的。即便能找到，我也不确定它有多大用处。

这或许反映了不同人的思维偏好，Patrick 承认自己更倾向于符号化和词汇化 的推理方式。

而当被问及五年后，程序员在 Cursor 这样的 AI 原生编辑器中看到的主要内容是否还是代码时，Patrick 表现出了极大的好奇。

Cursor 的 CEO Michael 认为，未来可能会演变成一种更高阶、更不正式的「语言」，程序员更多地描述「做什么 (what)」，而非「怎么做 (how)」。

Patrick 对此深表赞同。过去 20 年，我们在编程范式上的实验其实并不多。我们今天讨论的很多东西都来自 70、80 年代。这或许也解释了为什么像 Cursor 这样的新工具能取得成功，因为 Cursor 是很久以来第一个真正认真对待『开发环境』这件事的团队。

Stripe 的技术路线：API、Ruby 与 MongoDB

从程序员到 CEO，角色转变的核心是从「编写代码」到「编程组织」。Patrick 认为，编程思想对于组织管理极具价值，其中最重要的就是：

极其严肃地对待 API 和数据模型。

如果让我重来一次 Stripe，我会花比我们已经花费的更多的时间在 API 和数据模型上。

原因在于康威定律 (Conway’s law)。API 和数据模型不仅塑造了组织结构，更在深层次上塑造了公司的战略和商业成果。

他举了一个经典的例子：iOS 应用生态系统为何在很长一段时间内比 Android 更成功、更具活力？一个关键原因就是，iOS 最初提供的框架和抽象（API 设计）远优于 Android。许多早期的 iOS 类名以 NS 开头，代表着 NeXTSTEP，这些设计竟然延续了超过二十年。

在 Stripe，这个定律同样适用。Stripe 已经 15 岁了，许多 15 年前设计的 API 至今仍在使用。这既是好事也是坏事，Patrick 说，它们经受住了时间的考验，但我们也至今仍在承受它们最初的缺陷。

这引出了一个令人着迷的话题：Stripe 创立之初的「技术大爆炸」，那些在创始人疲惫、过劳、咖啡因过量状态下做出的、「随意」的技术决策，是如何影响至今的？

Patrick 坦言，这个比喻非常真实。Stripe 的两个最根本的技术基石，至今未变：

1. 1. Ruby：选择 Ruby 是为了在 Smalltalk 的「异端」和 Java 的「主流」之间找到一个平衡点。尽管 Stripe 内部曾有过关于是否要迁移到 Java 的激烈讨论和长篇文档，并且确实将一些对吞吐量要求极高的核心服务用 Java 和 Go 进行了重写，但 Ruby 至今仍是 Stripe 的主要语言。
2. 2. MongoDB：这个选择更具个人色彩。Patrick 对 SQL 有一种「原则性的反对」。他认为，SQL 这种关系型数据库要求开发者将应用领域的复杂概念（比如 Stripe 的「货币」概念）「压平」到一组受限的原始类型中，存在巨大的「转换错配」。他更喜欢面向对象的数据库，而 MongoDB 在当时是一个相对主流、又能提供所需灵活性的选择。

当然，这个选择也带来了巨大的挑战。为了让 MongoDB 达到金融级别的容错性、分布式、持久性和可靠性，Stripe 的工程师团队付出了巨大的努力，构建了大量的基础设施。最终，他们做到了。去年，Stripe 核心 API 的可用性达到了 99.99986%，全年宕机时间仅为 44 秒，这在行业内是顶尖水平。

重构：Stripe V2 API 背后的哲学

如果说早期的技术选型是「大爆炸」的初始条件，那么 Stripe 近年来最大的一项工程，则是一次深思熟虑的「宇宙重塑」。

Patrick 讲述了 Stripe V2 API 的重构计划。

时间回到 2022 年，Stripe 团队意识到，一些核心的抽象已经无法支撑公司长远的发展。于是，他们决定启动一次彻底的 API 升级。幸运的是，Stripe 的 API 从 2010 年开始就一直带有 /v1 的前缀，这为未来的版本迭代预留了空间。

这次重构的核心思想是：统一。

例如，过去 Stripe 的 API 会区分和分别表示「终端客户」、「子账户」、「收款方」等概念。在新的 V2 API 中，这些都被统一为同一种「实体」表示。这极大地简化了模型，并释放出巨大的商业潜力，比如让用户可以在不同国家间无缝地使用同一个账户。

这项工作的难度不在于定义新的 API 本身，而在于如何让新旧 API 共存、如何构建转换层、如何为数百万客户提供平滑的升级路径。

在某些方面，这感觉有点像芯片架构的指令集迁移。指令集本身不难设计，难的是所有与之相关的共存问题。

当被问及如何确保 V2 的设计是正确的时，Patrick 分享了两个宝贵的经验：

1. 1. 由经验丰富的人主导：API 的设计者们都是在旧系统中工作多年，深刻理解其缺陷和痛点的人。虽然有工作组，但最终有一个「单一负责人」来理解和掌握全局，Patrick 认为这至关重要。
2. 2. 通过实践检验设计：为了防止过度工程化，团队逼迫自己用新的 API 去亲手编写各种业务场景下的集成代码。只有当你真正去使用它时，你才能感觉到它「对不对」。

他还给出了两个通用的设计原则：

• • 尽可能地统一一切可以统一的东西。
• • 任何可能成为 N-M（多对多）关系的东西，就直接设计成支持它。 因为你以为绝不可能出现的情况（比如一个公司被两家公司共同拥有），最终总会以某种方式出现。

目前，这个庞大的重构项目已经完成了约 60-70%，新的 API 已于今年开始陆续发布。

如何使用 AI，以及它对世界意味着什么

作为 Cursor 的重度用户，Patrick 自然也深度思考 AI 的应用。

他个人使用 AI 的方式很直接：

• • 获取事实性信息：他经常使用 LLM 的聊天工具来回答具体的经验或事实问题。最近，他甚至会在读书时开启 Grok 的语音模式，随时提问，让 AI 在后台被动收听并回答。
• • 编写代码：主要通过 Cursor 这样的工具来辅助编程。

但他发现，AI 在写作方面表现不佳。我通常会对它们生成的文字感到不满意。也许是因为 RLHF 的规范让它陷入了某种固定的风格，而这种风格与我个人的写作风格不同。

从个人使用扩展到宏观经济，AI 的影响又如何？

作为「进步学」的倡导者之一，Patrick 认为 AI 的出现让这类研究变得更加紧迫。世界不再沿着一条预设的轨道前进，未来充满了更多的不确定性和可能性。他引用 Peter Schwartz 的「施瓦茨窗口」概念，认为我们今天（2025 年）展望 2035 年时，可能未来的窗口是极其宽广的。

然而，一个令人困惑的问题是：为什么我们在生产力数据中看不到 AI 的影响？

Patrick 提到，近期的 GDP 数据并未显示出指数级的飞跃，全球经济也未进入大规模加速增长的时期。这表明，新技术的扩散需要时间，且过程相当复杂。

他引用了 Anthropic 联合创始人 Jack Clark 的一个观点：Jack 预计 AI 将使 GDP 年增长率提高 0.5%。

我将 Jack 视为一个真正的乐观主义者，Patrick 说，每年 0.5% 的增量，在复利作用下其实是一个非常大的数字。有趣的是，这便是他的预测。

除了经济，Patrick 也将「编程」的思维范式应用到了一个更宏大的领域：生物学。

他参与创立的生物医学研究机构 Arc Institute，正在尝试做一件前所未有的事：治愈复杂疾病（如大多数心血管疾病、癌症、自身免疫疾病等）。

他们的核心假设是：我们之所以至今未能攻克这些疾病，是因为缺乏足够强大的实验和认知技术。而过去十年，生物学领域迎来了三项革命性技术：

1. 1. Read (读取)：以单细胞测序为代表的读取技术。
2. 2. Think (思考)：以 Transformer 为代表的深度学习模型。
3. 3. Write (写入)：以 CRISPR 为代表的基因编辑技术。

将这三者结合，人类第一次有能力在单个细胞层面形成一个「读取-思考-写入」的闭环，这本身就像一个新的图灵循环。Patrick 和他的同事们希望，这个系统性的方法能够为攻克复杂疾病带来全新的曙光。

对 AI 编程的终极期盼

在对话的最后，话题回到了编程本身。

如果 AI 真的成功地将编程变得极其高效和高阶，谁会是意想不到的受益者？

Patrick 的回答说：我没有高置信度的答案。他提到了各种可能的理论，比如稀缺的真实资产（比如旧金山的房产）、关键原材料（比如铜）或是头部 IP（比如泰勒·斯威夫特的音乐版权），但他认为未来的不确定性太大，难以预测。

那么，作为 Stripe 的 CEO 和 Cursor 的重要客户，他对 AI 编程工具有何期许？除了继续保持高效，他还提出了三个更深层次的愿望：

1. 1. 运行时集成：实现我们前面讨论过的，代码与运行时信息的深度融合。
2. 2. 智能重构和美化：希望 AI 能像一个不知疲倦的「夜班程序员」，在背后默默地将开发者白天产生的、略显杂乱的代码重构成优美的架构。这能极大地降低未来的修改成本。
3. 3. 追求「手艺」与「美感」：这是最核心的一点。Stripe 内部非常强调一种叫做「Stripe-craft」的文化，即追求软件的精心设计和使用愉悦感。这种愉悦感不仅是表面的像素完美，更是深层次的「它就是好用」。

人们有一种担忧，AI 会导致我们创造出更多平庸、劣质的东西 (slop)，而不是更多最优秀的东西。我不知道 Cursor 具体该怎么做，但如何确保这个世界正在创造更多最优秀的软件，而不仅仅是更多软件，我认为这是一个极其重要和有趣的方向。

这或许是对所有 AI 从业者最好的提醒。在追求效率和生产力的狂飙突进中，我们是否还能保持对「美」和「卓越」的追求？

参考来源

Patrick Collison on programming languages, AI, and Stripe’s biggest engineering decisions | https://www.youtube.com/watch?v=motX94ztOzo