10 人 + AI = 十亿美元公司？

摘要

NVIDIA 创始人兼 CEO 黄仁勋（Jensen Huang）一段引发全网热议的言论点燃了本期讨论：过去 15 年几乎所有人都在说孩子必须学编程，而黄仁勋却说恰恰相反——"我们的工作是创造计算技术，让没有人需要编程"。YC 合伙人 Gary、Jared、Harj（Harge）和 Diana 在本期 The Light Cone 节目中深入探讨了这一问题：在 LLM（Large Language Model，大语言模型）时代，还需要学计算机科学吗？AI 程序员现在可靠吗？我们能否见证只有 10 人的独角兽公司？讨论从 SWE-bench 基准测试与 ImageNet 的历史类比出发，分析 AI 编程的现状与局限；深入探讨设计世界与现实世界的差异、自然语言编程的可行性、Paul Graham "写作即思考"的哲学；Jared 提出了一个争议性论点——即使未来真的可以用英语写代码，你仍然应该学编程，因为学编程会让你变聪明。节目还讨论了杰文斯悖论（Jevons Paradox）为何意味着编程效率提升不会减少程序员需求，以及"公司是家庭还是运动队"的文化模型之争。最终结论是：学编程仍然是必要条件，因为品味（Taste）和工匠精神（Craftsmanship）只能通过深入工程实践来培养。

黄仁勋的争议性言论

节目以黄仁勋在公开场合的一段话开场。他指出，过去 10 到 15 年间，几乎所有站在台上的人都在强调学习计算机科学和编程的重要性，但他的观点恰恰相反："我们的工作是创造计算技术，让没有人需要编程。编程语言就是人类语言——现在世界上的每个人都是程序员。"

四位 YC 合伙人围绕这段话展开讨论。核心问题是：下一代创始人、年轻人或任何正在规划职业方向的人，是否还应该学习计算机科学？毕竟，多年来人们一直被劝告"学编程"，无论你是技术创始人还是非技术创始人。现在 LLM 和 AI 是否会自动化所有这些工作？

AI 程序员的现状：从 Sweep 到 Devon

Diana 分享了她所投资的公司的情况，包括 Sweep 和 Curse/Fume 等。目前，这些 AI 编程助手主要在解决初级开发者的任务——修复一个 HTML 标签、修补一个小 Bug 等。但当需要构建更复杂的系统（例如构建可扩展的后端分发系统）时，AI 尚无法胜任。

Jared 指出，需要为黄仁勋的言论提供一些背景：就在三个月前，AI 几乎完全无法进行有用的编程，基本接近零通过率。真正引发当前 AI 编程热潮的转折点，实际上比 Devon 的发布更早——大约八个月前，普林斯顿 NLP 小组发布了 SWE-bench（SWE-bench）基准测试数据集。

SWE-bench 与 ImageNet 的历史类比

Diana 将 SWE-bench 与 ImageNet 进行了类比。ImageNet 是斯坦福大学李飞飞（Fei-Fei Li）实验室发布的划时代数据集，包含大量图像和众多类别，任务是让算法识别图像内容。在 2006 年，让计算机识别一张猫的图片并判断"这是一只猫"是一个几乎不可解的问题——因为猫的形态千变万化：黄色、黑色、不同姿态、躺卧或蜷缩，看起来完全不同。

在 ImageNet 之前，传统机器学习方法更多依赖统计学手段——支持向量机（Support Vector Machine, SVM）、手工编码的信号处理特征提取器（Feature Extractor）、频域变换、小波变换等。这些方法在 ImageNet 上的错误率高达 30%—50%，而人类感知的错误率仅约 5%。

随后，多伦多大学的 Alex Krizhevsky 等人使用 GPU 训练的 AlexNet 横空出世，性能远超所有传统技术。Jared 回忆那天的新闻席卷了整个编程互联网，并认为当下 AI 竞赛的浪潮，本质上仍然是在 AlexNet 2012 年所开启的那波浪潮之上。

关键启示是：SWE-bench 对 AI 编程的意义，正如 ImageNet 对图像识别的意义——它提供了一个可量化的基准，使人们能够衡量进步、竞争优化。不过，当前 SWE-bench 的最佳成绩约为 14%，远低于人类熟练程序员的表现。

SWE-bench 的局限性：修 Bug ≠ 构建系统

Harj 指出 SWE-bench 的一个重要局限：它由现有代码仓库中的小型 Bug 修复任务组成，与从零开始构建一个全新系统截然不同。即使 AI 能解决 SWE-bench 的一半问题，距离"给出应用描述就能自动构建整个应用"仍然相差甚远。编程所面临的问题集合比 SWE-bench 所涵盖的要大得多——SWE-bench 只是一个理想化世界中的子集。

设计世界 vs 现实世界

Harj 提出了一个深刻的工程哲学观点：在工程中存在两类问题模型。第一类是"设计世界"——完美的工程公差、完美的仿真数据、物理定律完美运行。第二类是"现实世界"——充满混乱和摩擦。AI 和 LLM 在"设计世界"中表现出色，但当遭遇现实世界的混乱时，往往会捉襟见肘。

他举了工程系统中的热修复（Hot Fix）为例——那些让系统运转的"魔法数字"、自动驾驶汽车中因传感器位置而存在的各种系数。牛顿的物理定律是优美的方程式，但现实世界充满了取决于材料的各种摩擦系数，这个世界是无限的。因此，Harj 认为 LLM 无法真正涵盖和管理整个现实世界。

英语作为编程语言的未来

Gary 进一步探讨了黄仁勋所设想的未来：程序员变得像今天的产品经理（Product Manager）——用英语写产品规格说明（Spec），然后由 AI 将其翻译成可运行的代码。这一愿景触及了硅谷工程师与非工程师之间长期存在的根本争论：编程究竟是纯粹的实现（Implementation），还是创意本身就蕴含在实现过程之中？

Paul Graham 是后一观点的坚定倡导者。他从早期就大力推崇 Lisp 语言，原因是 Lisp 极其灵活，而他的哲学是：好的想法只有在动手构建的过程中才会浮现。这种哲学同样延伸到写作——写作本身就是思考（Writing is Thinking）。Gary 回忆在 YC 面试时与 Paul Graham 共事的经历：有时他会看到某位创始人的过往履历非常出色，认为对方一定已经想清楚了只是没在面试中说出来，但 Paul Graham 总是纠正他——"如果他们没有说出来，那他们自己也不知道。"

自然语言转 SQL 的启示

Gary 提出了另一个反例：自然语言转 SQL（Natural Language to SQL）的想法已经存在多年，却从未真正普及。问题不在于技术实现有多难，而在于你无法仅仅通过"把想法翻译成 SQL 查询"来获得答案——你需要知道该问数据什么问题，需要在脑中对关系型数据库（Relational Database）有概念模型，才能提出正确的问题。如果存在一个"思考"的前置步骤，那你就不能简单地从二进制代码一路抽象到自然语言来外推。

Harj 认同这一观点，指出 AI 确实能够实现从英语到 SQL 的翻译，但最难的部分不是翻译——而是数据建模（Data Modeling）。数据工程团队之所以庞大，正是因为真实世界的数据建模极其混乱：谁和谁对话、工作流如何运转，这些都必须由人来梳理思考。如果数据模型错了，一切都会出错。

学编程让你变聪明：Jared 的争议性论点

Jared 提出了本期最具争议性的观点：即使黄仁勋的预测完全成真——未来你真的可以用英语构建出色的应用——你仍然应该学习编程，因为学习编程会让你变聪明。

他引用的证据是：大量研究表明，LLM 学会逻辑思考的方式，正是通过阅读 GitHub 上的所有代码，本质上学会了编程。程序员们一直直觉上觉得学编程让自己变聪明了，但在人类身上很难证明，而现在 LLM 的学习过程为此提供了实际证据。Diana 补充道，对于某些类型的问题，让 LLM 先写代码来解决问题，比让它直接解决问题效果要好得多——工具使用（Tool Use）是这些系统的一种奇异的涌现行为（Emergent Behavior）。

初级编程工作的消亡与十人独角兽

众人一致认为，有一件事是毫无争议的：部分编程工作将被 LLM 取代，特别是初级工程工作——那些不涉及高创造力或高人类推理的"胶水代码"（Glue Code）。外包开发公司和大厂初级员工大军所从事的工作最可能被替代。

一个潜在后果是：如果初级 AI 软件工程师已不远，软件公司的员工数量将大幅减少，可能趋同于独角兽和十亿美元公司只有约 10 名员工。Sam Altman 最近也发表了类似观点——未来独角兽可能只有 10 名或更少员工。

Harj 回顾历史，WhatsApp 被 130 亿美元收购时只有约 15 名员工，Instagram 被 10 亿美元收购时约 20 名员工。但这些只是零星的闪光，从未形成持续趋势。也许现在到了形成趋势的临界点。

员工数量与地位的迷思

Gary 指出一个有趣现象：新入行的创始人往往想要更多员工，因为员工数量与社会地位正相关。而有经验的创始人则痴迷于拥有尽可能少的员工——因为管理大公司后，你会意识到那有多痛苦。这也是硅谷长期以来"小团队"迷因的根源。

Harj 提到 Paul Graham 早在 2005 年就倡导这一理念，远早于硅谷的潮流，这既是远见也是个人偏好——他只是不想和数百人待在一个办公室里。

千人公司的失控临界点

Gary 分享了与 Zynga 创始人 Mark Pincus 的对话：当一家公司达到约 1000 人时，即使是最强势、最敏锐的 CEO，也会失去对公司施加意志的能力。Gary 回顾他日常接触的拥有数千名员工的创始人，这确实是他们的真实日常体验——你清楚地知道公司必须朝某个方向走，却被困住、无法推动执行。

Patrick Collison 的蜕变：从工程师到组织架构师

Harj 以 Stripe 联合创始人 Patrick Collison 为例，讲述了一个工程师到领导者的转变。19 岁时，Patrick 是那种极度专注的工程师原型，只想攻克硬核工程问题，把周围太多的人视为分心。但当他创建 Stripe 后，他意识到实现抱负的方式是将工程思维应用于公司本身——把公司当作另一个需要工程化构建的产品，而人是核心组件。他拥抱了成为高效领导者、管理者这一角色。Harj 强调，如果 Stripe 今天创立，Patrick 不会出于"尽量不招人"的内在动机行事，而是会做期望值计算——是独自做更好，还是集结人力共同推进更好。

公司是家庭还是运动队？

Jared 分享了他自身创业经历中最痛苦的领悟：把创业公司当作"家庭"是一个有毒的观念。他引用了 Airbnb 创始人 Brian Chesky 的转变——早期 Chesky 曾强调公司是家庭，但后来明确否定，认为家庭有太多旧伤疤和不可言说之事，不应用作公司模型。更健康的方式是运动队模型：我们有一个明确目标，我们需要赢。家庭追求的是爱和归属，而创业公司存在的意义是解决问题并获胜。

Diana 从自身经历出发，分享了从 Niantic 小型亲密团队到 Pokémon Go 爆红后膨胀为 500 人工程大军的巨大冲击——从"部落和家庭"到"最大化每个人产出"是完全不同的管理方式，这种转变非常困难。

通过招人学习成长

Gary 指出，就像 Jared 说的编程让人更聪明一样，创始人在招聘、建设团队、处理冲突、解雇员工、激发他人最佳表现的过程中，也经历着一种学习——或许"更聪明"不是最准确的词，但"更高效"肯定是。你可以在建设公司和团队的过程中深刻了解人性。

Harj 补充，Patrick Collison 的故事并非孤例——YC 最优秀的创始人都是这样的。人们有时好奇 YC 如何敢投资没有管理经验的 18 岁年轻人，期望他们有朝一日能建造大公司，原因正是：他们把一切当作工程问题来对待。

Larry Ellison：将业务问题当作编程问题

Harj 分享了 Oracle 创始人 Larry Ellison 的故事。 Ellison 曾完全忽视公司的财务职能，认为那是世界上最无聊的事，直到 Oracle 因为不掌控预算和开支而几近破产。他被迫亲自介入，而唯一的方式就是把财务当作编程问题——全是数字、全是流程，像写代码一样优化它。 Ellison 不仅解决了问题，还开始享受流程优化本身，这反过来反哺了 Oracle 的业务——Oracle 的核心生意就是帮企业解决混乱流程、卖出解决方案软件，而 Ellison 正是因为自己经历了这个问题，才能构建出他人同样需要的方案。

Harj 观察到，YC 的 B2B 技术创始人普遍将销售组织当作编程优化问题来对待，这几乎成了一种刻板印象。

杰文斯悖论：效率提升反而增加需求

Jared 提出了一个关键经济学概念——杰文斯悖论（Jevons Paradox）：当你让任何服务变得更高效、更便宜时，需求反而会增加，消费量随之上升。

经典例证：Excel 让财务分析更高效，但并没有减少财务分析师的数量，反而增加了；打字机被文字处理器取代后，打字员的角色消失了，但对文字处理技能的需求却大幅增长。同理，软件变得更便宜、程序员变得更高效，但并没有减少对程序员的需求，反而增加了——YC 的申请数量就是明证。Paul Graham 15 年前写文章时无法想象 YC 一年会收到超过 1 万份申请，而如今已超过 5 万份。创办公司变得前所未有地容易，但成为一名优秀创始人的门槛也随之水涨船高——需要更好的品味和更多的工匠精神。

"递黄油机器人"与人的解放

Gary 引用了《瑞克和莫蒂》中的经典梗：桌上的小机器人问主人"我的使命是什么？"，回答是"递黄油"。机器人绝望地说"天哪"。Gary 指出，现实世界中有太多人——不是机器人，而是人类——做着极其机械化、毫无创造力的朝九晚五工作。我们应该庆幸，现在有了更多软件、更强大的工具、甚至即将到来的机器人技术，可能会将这些人从"递黄油"的命运中解放出来，让他们去做更有创造性的事。

他的愿景是：不是少数几家公司各自价值万亿美元，而是数千家公司各自价值十亿美元或更多。有些可能有 1000 名员工，有些可能只有 10 人，甚至可能只有一位创始人。但最终目标是为真实客户解决真实问题，将人从机械劳作中解放。

最终结论：学编程仍然是必选项

四位合伙人一致同意：学编程（Learn to Code）仍然是必要的。Jared 直言"Jensen 非常聪明，但他并非每次都对"。过去 10 年，每年诞生的独角兽数量持续增长，正是因为技术让更多人能够将想法变为现实，AI 只会加速这一趋势。但与此同时，编程和编码仍然是基本门槛（Table Stakes），因为大量的基础知识和良好品味需要通过学习工程和计算机科学来获得——你只有通过深入研究才能培养出构建卓越产品所需的品味与工匠精神。

正如 Gary 所说，YC 最希望看到的，是那些作为工匠（Craftspeople）的人——他们才是将要建造未来的人。