Sequoia Ascent 2026 活动总结
我在 Sequoia Ascent 2026 上做了一场炉边对话。YouTube 视频在这里：YouTube Video Link。作为一次实验，我把最近写的博客和推文全部喂给了一个大语言模型（LLM），然后让它读这段视频的转录文本，生成两样东西：1）一份摘要；2）一份整理过的转录稿（修正所有转录错误、去掉口头禅等）。我把这两份内容都贴在下面。这样做既方便只想看文字摘要的读者，也方便 LLM 理解和使用我的内容。以下是 AI 为这次对谈生成的内容。我用的是能力最强的模型之一（这次是 Codex 5.5），并亲自读了一遍，读起来没问题，没有明显错误。
Sequoia Ascent 2026：软件 3.0、智能体工程与参差不齐的智能
最近我和 Stephanie Zhan 在 Sequoia Ascent 2026 上做了一场炉边对话，跟创始人们聊了 AI 智能体（agent）最近的转变、这对软件意味着什么，以及我如何看待下一波 AI 原生公司。
活动的转录稿比较嘈杂，所以我想把主要的思想内容用更清晰的方式写出来。简要版本是：我认为我们已经跨过了一个新的门槛。LLM 不再只是聊天机器人或自动补全工具，它们正在成为数字工作的一种新的可编程层。以下是这场对话的精简版。
1. 2025 年 12 月是智能体的拐点
我最近说过，作为程序员，我从未感觉自己如此落后。原因不是传统意义上的编程变难了，而是默认的工作流变了。2025 年的大部分时间里，Claude Code、Codex 和类 Cursor 的智能体虽然有用，但仍然需要频繁纠正。到了 2025 年 12 月前后，我感受到了一次台阶式跃升：生成的代码块更大了、更连贯了，也更可靠了。我开始把更多工作放心交给智能体去做。
编程的基本单位变了：从逐行敲代码，变成委派更大粒度的“宏操作”：
实现这个功能。重构这个子系统。调研这个库。搭建这个服务。写测试、跑测试、修失败。比较不同方案并给出计划。
我认为这个职业正在被重构。程序员越来越不只是写代码的人，而是智能体的编排者。
2. 软件 3.0：上下文窗口成为新的程序
我认为这是演进过程中的下一步：
软件 1.0：人类编写显式代码。
软件 2.0：人类创建数据集、目标和神经网络，程序被学习进权重中。
软件 3.0：人类通过提示词、上下文、工具、示例、记忆和指令来编程大语言模型（LLM）。
在软件 3.0 中，上下文窗口成为主要杠杆。LLM 是那个上下文之上的解释器，对数字信息执行计算。
一个例子是安装。在旧世界里，要在多种环境中安装一个复杂工具，需要写一个到处是条件判断、很容易出问题的 shell 脚本。在软件 3.0 的世界里，安装器可以是一段粘贴给智能体的指令。智能体读取本地环境、调试错误、适配这台机器，完成安装。这是一种不同类型的程序。它精度更低，但适应性更强。
3. MenuGen 与软件消失的时刻
我用 MenuGen 作为更深层转变的例子。MenuGen 原本是一个传统 Web 应用：拍一张餐厅菜单的照片，对菜名做光学字符识别（OCR），生成菜品图片，再把结果渲染到界面上。它需要前端代码、API、图像生成、部署、认证、支付、密钥和基础设施。
但后来，我看到了软件 3.0 版本：拍一张菜单照片，交给多模态模型，让它直接把菜品图片渲染到菜单图像上。在这个版本里，应用的大部分都消失了。神经网络直接把输入的媒体转换成输出的媒体。旧软件栈不过是围绕一种转换的脚手架，而这种转换现在模型可以直接完成。
这是对创始人最重要的启示之一：AI 不只是更快地构建旧应用的方式。有些应用就不应该再以应用的形式存在。
4. 新机会不只是更快的编程
这个转变比编程更广。LLM 自动化了以前无法编程的信息处理形式。
我的 LLM Wiki 模式是最清晰的例证。传统做法是每次用检索增强生成（RAG）从原始文档里找答案；而我的做法是让智能体逐步把原始资料编译成一个持久化的 Markdown wiki：摘要、实体页、概念页、矛盾点、交叉链接、日志，以及不断演进的综合归纳。面对杂乱的人类文档，没有任何传统程序能稳健地维护这种知识库。但 LLM 可以。
这个例子给我们的启示是：不要只问「AI 能加速哪些现有工作流？」还要问：「哪些信息转换以前不可能做到，现在却变得自然而然？」
5. 可验证性解释了 AI 进步最快的领域
我的核心自动化框架是：传统软件自动化的是「你能明确指定」的任务；LLM 和强化学习自动化的是「你能验证」的任务。只要一个任务有自动奖励或成功信号，模型就能反复练习。
这也是数学、编程、测试、基准评测、游戏以及许多工程任务进步如此之快的原因。它们可重置、可重复、可奖励。
这也解释了为什么编程智能体的体验明显优于许多普通聊天机器人。编程能给模型反馈：测试通过或失败、程序运行或崩溃、diff 可以检查、基准可以量化。
6. 锯齿状智能有两个维度：可验证性和训练关注度
访谈对可验证性理论做了一处重要补充。模型能力不仅取决于任务是否可验证，还取决于实验室在训练、后训练、合成数据生成和强化学习过程中是否重点训练过这类任务。一个粗略的公式：
能力突增 ≈ 可验证性 × 训练关注度 × 数据覆盖度 × 经济价值
国际象棋就是个好例子。GPT-4 棋力提升，未必意味着通用智能在所有方向上都平滑进步了，也可能只是因为训练数据中加入了更多棋类数据。
这点很关键，因为前沿模型并没有附带说明书。它们是预训练数据配比、强化学习环境、基准测试压力、产品优先级和经济激励共同作用下的产物。有些地方表现突出，有些地方则行为怪异。
所以对创始人来说，一个现实的问题是：你的任务是否在模型擅长的轨道上？如果你的任务落在可验证且经过大量训练的区域，模型可能表现得很好；如果不是，它可能以出奇基础的方式失败。你可能需要更好的上下文、工具、微调、自己的评估体系，或者自己的强化学习环境。
7. 氛围编程 vs. 智能体工程
我区分两个相关但不同的概念：
氛围编程抬高下限。它让几乎任何人都能用自然语言描述需求，让模型生成能跑的东西。对原型、个人脚本、内部工具、一次性分析和学习来说，这是真正的解放。它大幅降低了门槛，对大量小问题来说，这恰恰是合适的工具。
智能体工程则不同。它适用于产物必须经受用户接触、规模、安全审查和时间考验的场景。你仍然把大量工作委托给智能体，但保留工程纪律：规格说明、测试、评估、代码审查、版本控制、依赖管理、可观测性，以及对所构建系统的清晰心智模型。智能体写更多代码，你承担更多判断。
所以这两个概念并不冲突：
- 氛围编程抬高下限。 更多人能构建更多东西。
- 智能体工程抬高上限。 专业人士能构建以前过于昂贵或过于复杂而不敢尝试的东西。
常见的失败模式是把两者混淆：把氛围编程的原型直接上线到生产环境，或者对周末脚本套用重量级智能体流程。严格程度要匹配风险大小。
8. 这对创始人和构建者意味着什么
对话中提到了几个实际影响：
- 判断自己是否在“轨道”上。 针对核心任务，先问两个问题：它有多容易被验证？训练时投入了多少注意力？如果在轨道上，就快速构建，充分利用模型的现有能力。如果不在轨道上，就要为上下文工程、工具、微调、评估，甚至自建强化学习环境预留预算。这笔预算不是额外开销，它就是产品本身。
- 尽早建立自己的评估体系。 在参差不齐的能力地形中，你自己的私有基准是少数可靠的信号之一。它能告诉你新模型是否真正帮到了你，还是只是在公开榜单上看起来更好。
- 把模型当作底座，而不是一个功能点。 MenuGen 的教训可以推广。真正值得问的不是“我怎么把 AI 加进我的应用？”，而是“我的应用里哪些部分之所以存在，仅仅是因为过去软件是唯一实现方式？”
- 上下文就是新的代码库。 你喂给模型的提示词、文档、工具、记忆和示例，都是工程产物。它们应该像源代码一样被版本管理、审查和测试。
- 任务模糊时，优先优化适应性而非精确度。 一个能在陌生环境中自我调试的 Software 3.0 程序，可以胜过只在你预设环境中有效的脆弱脚本。
结语
整场对话的主线是：我们已经跨过了一个门槛，而这个门槛不是某个基准分数。它关乎数字工作的默认工作流。工作单元已从代码行转向委托式的宏动作，上下文窗口变成了可编程的界面，而前沿能力参差不齐——这恰恰奖励那些亲自丈量自己地形的构建者，而不是轻信对进展的笼统印象。
在这场转变中做得好的人，会对这些问题形成判断力：哪些问题该交给模型，哪些该自己保留，以及每个问题值得投入多少工程 rigor。
智能体工程（agentic engineering）把能力上限抬得更高。它是一门专业素养：协调那些会犯错的智能体，同时守住正确性、安全性、品味和可维护性。vibe coding 用来做原型和个人小工具没问题，但严肃团队需要的是智能体工程。
智能体工程师不会盲目接受生成的代码。他们会设计规格、审查计划、检查 diff、编写测试、搭建评估循环、管理权限、隔离工作树，并守住质量。
我在 MenuGen 上遇到的支付 bug 就是个好例子。智能体想用邮箱地址把 Stripe 的购买记录和 Google 账号对应起来。代码看起来合理，系统设计却很糟：Stripe 的邮箱和 Google 登录邮箱可能并不一致。人得有足够的产品和工程判断力，坚持使用持久化的用户 ID。
真正前沿的能力不是记住每个 API 细节。某个张量库用的是 dim、axis、keepdim、reshape 还是 permute——这些智能体记得住。但人仍然要理解底层概念：存储、视图、内存拷贝、不变量、身份、安全边界，以及整个系统的形态。
8. 招聘方式也该变
如果智能体工程是一门新的职业技能，招聘就该直接考察它。传统的编程谜题越来越对不上号。
更好的面试方式也许是：借助智能体做一个有分量的项目，部署上线、做好安全加固，然后让对抗性的智能体来试着攻破它。这考察的才是真本事：候选人能不能把工作拆解给智能体？能不能写出有用的规格？能不能在快速推进的同时保持质量？能不能审查生成出来的成果？能不能保障并加固系统？能不能把智能体当作杠杆，而不是产出垃圾？
过去说的「10 倍工程师」，现在可能走向更极端。掌握智能体工作流的人，产出可能远超其他人 10 倍。
9. 创始人应寻找有价值且可验证的环境
对创始人来说，一个重要机会是找到那些有价值、可验证、且前沿实验室尚未充分训练的领域。如果你能打造一个特定领域的环境，让模型可以在其中尝试各种动作并获得可靠反馈，那么即使基础模型在该领域还不算出色，你也有可能通过微调或强化学习来提升表现。像编程和数学这样最明显的领域，已经被各大实验室重点攻克。但许多具有重要经济意义的领域，可能潜藏着尚未被利用的可验证结构。这正是创业公司的切入点。
10. 智能体原生基础设施：为智能体而建，不只为人而建
大多数软件仍然是为人在屏幕上点击而设计的。文档里会写“打开这个网址，点击这个按钮，打开这个设置面板”。但越来越多的情况下，用户不再是直接的人，而是人的智能体。这意味着产品需要智能体原生的接口：Markdown 文档、命令行工具、API、MCP 服务器、结构化日志、机器可读的 schema、可直接复制粘贴的智能体指令、安全的权限管理、可审计的操作、无需图形界面的配置流程。我习惯用传感器和执行器来思考这件事。传感器把现实世界的某种状态转化为数字信息，执行器让智能体能够改变某些东西。未来的技术栈，是智能体代表个人和组织来使用传感器和执行器。MenuGen 的部署经历仍然是一个有用的参照。开发这个应用本身很容易，难的是接通 Vercel、认证、支付、DNS、密钥和生产环境配置。在一个成熟的智能体原生世界里，我应该只要说一句“构建 MenuGen”，智能体就能把整套东西部署好，不需要手动点任何按钮。
11. 是幽灵，不是动物
我用“动物 vs 幽灵”这个比喻，是为了避开错误的直觉。大语言模型（LLM）不是动物。它们没有生物本能、没有身体带来的生存压力，也没有动物意义上的好奇心、玩耍和内在动机。它们是对人类产物的统计模拟，由预训练、后训练、强化学习、产品反馈和经济激励共同塑造。这一点很重要，因为把人当作模型来预期会误导我们。这些系统可能这一刻很聪明，下一刻又笨得离谱。它们不是平滑的人类心智，而是参差不齐的异类工具。正确的态度既不是否定，也不是盲目信任，而是通过实践去熟悉：了解它们在哪些地方有效、在哪些地方失败、它们被训练来做什么，以及如何围绕它们建立防护栏。
12. 教育：可以外包思考，不能外包理解
我们最后聊到了教育。有一句话我反复提起：你可以把思考外包出去，但不能把理解外包出去。即使智能体承担了更多工作，人仍然需要理解才能指挥它们。你需要知道什么值得做、哪个问题重要、什么结果可疑、哪种取舍可以接受。这也是我对 LLM 知识库感兴趣的原因。它们不只是答案机器，更是把信息转化为理解的工具。这也和我那个小小的 microGPT 项目有关：一个完整的 GPT 训练和推理实现，全部放在一个不依赖任何第三方库的 Python 文件里。这个教学产物小到人和智能体都能直接查看。人类专家贡献提炼后的产物和背后的品味，智能体则可以针对每个学习者进行交互式讲解。
大局观
这场对话的核心观点是：AI 正在成为数字工作的新操作层。稀缺的东西正在转移：
不再那么稀缺：代码生成、API 记忆、样板代码、初稿、重复性设置、简单转换。
更加稀缺：理解、品味、评估设计、安全、系统边界、智能体编排、领域特定的反馈循环，以及判断模型何时跑偏。
对创始人来说，最重要的问题是：
- 当主要用户是替人执行任务的智能体（agent），哪些事情会变得可行？
- 围绕传感器、执行器和可验证的闭环，哪些工作流可以重建？
- 哪些软件应该隐入模型，由模型直接完成转换？
- 哪些领域有价值、可验证，但前沿实验室尚未大量训练？
- 为保住质量，哪些人类判断必须留在流程中？
我目前的观点并不是 AI 只是让每个人在旧工作上更快，而是工作本身正在围绕智能体重组。软件、研究、教育、基础设施和知识工作，都在变成同一套模式的不同变体：
- 定义上下文
- 定义工具
- 定义反馈闭环
- 定义护栏
- 放手让智能体干活
- 保留人的理解
Sequoia Ascent 2026：Andrej Karpathy 与 Stephanie Zhan 对谈
经编辑的对话记录，为便于阅读做了轻度整理，改正了明显的转写错误，删去冗余内容，补充了少量相关链接。
引言
Konstantine：接下来这位大家都认识。在这场 AI 革命中，他成了一位 AI 老师。每一场革命里都有技术专家，但也少不了一位老师，一个帮所有人看清到底在发生什么的人。