在旧金山举行的 YC AI Startup School 上普患配资，Andrej Karpathy 发表演讲，深入探讨了软件从 1.0 到 3.0 的演进路径，指出大型语言模型正在重塑软件开发与交互方式，强调人机协作的未来方向，如钢铁侠战衣般增强人类能力，并分析了当下的创业机遇。
6 月 16 日旧金山举行的 YC AI Startup School 上，Andrej Karpathy 发表主题演讲，系统梳理了软件范式的深层变革，并提出未来 AI 系统设计的关键方向。
他指出，软件正在进入一个快速重写与结构重构的时代，而这场变革的核心动力正是大型语言模型的兴起。
此次演讲基于 Karpathy 围绕“软件 1.0 到软件 3.0”的演进路径，深入探讨了自然语言编程、Agent 应用、产品自治性滑块、以及人类在环等关键议题。演讲不仅回顾了过去十年 AI 与软件融合的进程，也展望了一个以人机协同为基础的新软件世界。
Andrej Karpathy 指出，软件行业正处于一个深刻变革的阶段。现在正是进入软件行业的绝佳时机，不仅因为行业发展迅猛，更因为软件本身正在经历前所未有的根本性转变。
过去 70 年，软件的基本范式几乎没有发生实质性变化，而近几年却连续出现两次底层变革，导致现有的软件体系面临大规模重写与重构的任务。以“软件地图”为喻，Karpathy 引用了一个名为 GitHub 地图的可视化工具，展示整个软件世界的结构。这些代码仓库代表了人们写给计算机的所有指令集合，是数字空间中完成任务的基础逻辑。
几年前，新的软件形态开始出现，Karpathy 提出了“软件 2.0”的概念。区别于软件 1.0 时代“手写代码”的方式，软件 2.0 的核心是神经网络的权重，开发者不再直接编写程序逻辑，而是调整数据集并用优化器训练出合适的模型参数。这一过程的本质是通过数据训练出能够执行复杂任务的网络，而非精确指令的堆砌。彼时，神经网络多被视为分类工具，如决策树等模型，但“软件 2.0”的说法更加准确地刻画了这一范式的跃迁。
对应软件 1.0 时代的 GitHub，软件 2.0 也已有平台基础。Hugging Face 被视为这一时代的 GitHub，另一个平台 Model Atlas 则可视化了模型“代码”本身。在这个平台上，例如图像生成器 Flux 的参数以图像节点形式呈现，每次微调一次 LoRA 参数，就如同“提交一次 Git 更新”，系统中便出现一个新的图像生成模型。
因此可以将三代软件的演进总结为：
软件 1.0：用代码编程计算机；
软件 2.0：用权重参数“编程”神经网络；
软件 3.0：用英文 prompt 编程语言模型。
以 AlexNet 为例，这一图像识别模型属于软件 2.0 的代表作品。当下的关键变化在于，大型语言模型（LLM）的出现使神经网络具备了被编程的能力，这是一种全新的计算形态，Karpathy 将其命名为“软件 3.0”。
在软件 3.0 的范式中，prompt 变成了程序，而语言模型则成为通用执行器。最具突破性的是，这些程序不再使用专业语言，而是以自然语言表达，例如英文。这一转变极大地降低了软件交互的门槛，也颠覆了传统开发流程。
例如同样是进行情感分类，可以选择：
编写 Python 脚本（软件 1.0）；训练神经网络模型（软件 2.0）；直接提供一个 prompt 给 LLM（软件 3.0）。这种从代码到权重再到语言的演进，代表着计算范式的逐步抽象与人机交互方式的根本性革新。
few-shot prompt 的出现使语言模型具备了更大的灵活性，稍作修改即可实现完全不同的行为方式，提示词正在成为新时代的编程语言。当前阶段是软件 1.0、2.0、3.0 三种范式并行共存的时期，GitHub 上的代码早已不再是纯粹的编程语言，而是大量混杂着英语自然语言，这标志着一种新型代码形态的诞生，一种以人类母语为基础的新型编程范式已经浮现。
Karpathy 回忆称，当首次意识到这一趋势时，感到震撼不已。他当即在推特上写下并置顶了一句评论：“我们正在用英语编程计算机。”
在 Tesla 开发自动驾驶系统期间，这一趋势变得愈发明显。自动驾驶的系统输入来自传感器数据，经过复杂的软件堆栈处理后输出转向与加速指令。最初系统中充满了 C++ 编写的传统软件代码，即软件 1.0，也混杂着用于图像识别的神经网络模块。但随着 Autopilot 系统持续迭代，神经网络逐渐接管了更多功能，传统代码被不断删除，原本依赖硬编码实现的图像处理被神经网络模型所取代，整个系统由软件 2.0 逐步“吞噬”。
这股“吞噬传统代码”的浪潮再次上演，只不过这一次是软件 3.0 开始取代部分 2.0 的逻辑。三种范式共存的环境中，对工程师提出了新的要求：不仅需要熟练掌握三种工具，更要能在它们之间灵活切换，按需选取最合适的方式去构建系统。
Part1：如何理解大模型？语言模型崛起带来的范式变化，也促使人们重新思考“计算机”的定义与结构。Andrew Ng 曾将 AI 比作“新的电力”，Karpathy 认为这个比喻非常贴切。OpenAI、Gemini、Anthropic 等实验室像是在建设智能电网，付出巨额资本开支（CapEx）训练模型，而用户则通过 API 按量计费使用模型的智能服务，这本质上是一种“按需供能”的模式。
这种供能模式具备公共基础设施的所有典型特征：低延迟、高可用性、一致性好、可扩展性强。就像传统电网允许在主电源失效时切换至太阳能、电池或柴油机发电，LLM 生态中也出现了如 OpenRouter 等工具，实现多模型间的无缝切换。因为语言模型不争夺物理资源，这种“智能多供应商”的架构成为可能。
近期多家主流模型宕机时的现象进一步印证了这一点。当 GPT、Claude、Gemini 同时中断服务时，全球范围内的 AI 用户瞬间陷入“智能限电”状态，这是一场典型的“脑力停电”危机，显示出现代人对这些模型的高度依赖性。
不过 Karpathy 进一步指出，这些模型并不只是“公共事业”层级的工具，它们的训练复杂度与成本也令其具备“晶圆厂”（fabs）的某些特征。训练一个 LLM 所需的资源远超一座发电厂，不仅涉及庞大的数据管线，还包括尖端硬件、专属加速器与长期算法积累，整个过程是深度技术、研发能力和知识产权的高度集中体现。
即便如此，这些比喻仍显不够贴切。因为软件具备可复制性与较低的护城河壁垒，相较硬件体系更易被挑战或重构。如果类比晶圆厂与芯片产业：
拥有自主芯片（如 Google 的 TPU）并自行训练模型的公司类似于英特尔；
仅使用通用硬件运行模型的公司类似于无厂房设计模式（fabless）。
但在 Karpathy 看来，最合适的类比对象是“操作系统”。语言模型并非像电、水那样的静态商品，而是一个日益复杂、具备平台属性的技术栈。正如操作系统有 Windows、macOS、Linux，LLM 生态中也有闭源模型与开源模型并存：GPT、Claude、Gemini 等封闭系统构成“主流平台”，而 LLaMA 等开源模型则代表着 AI 世界的 Linux。
语言模型的底层结构开始呈现出类操作系统的组织形式：模型本体是“CPU”，上下文窗口是“内存”，而模型运行机制承担调度角色，像是在管理一整套任务系统。与传统计算平台类似，一款应用如 VS Code 可以运行在不同的操作系统上；而类似 Cursor 的 LLM 应用也可运行于多个模型之上，只需切换模型引擎即可。
这种形态与 1960 年代的计算环境极为相似。当年，主机部署在数据中心，用户通过远程终端请求资源。如今，LLM 作为一种高成本的集中式计算资源，也只能以云端部署为主，人们通过 API 与其交互普患配资，本质上是一种“时间共享计算”系统。
个人智能尚未真正到来。不是因为没有人尝试，而是因为算力与模型资源尚不具备充分本地化部署条件。某些设备如 Mac Mini 已可在小规模上运行推理任务（batch=1），受限因素主要是内存而非计算能力。但 Karpathy 指出，真正的“个人 LLM”尚未到来，它需要新的硬件架构、接口范式与产品形态来实现“桌面级智能”。
以 ChatGPT 为代表的交互方式，如今更像是通过“命令行终端”使用系统功能。虽然部分任务已有图形界面（GUI），但尚未出现一种统一 GUI 适配所有 LLM 应用的方案。这个“缺失的图形界面”意味着语言模型还未完成从工具到平台的进化。
在 Karpathy 看来，最令人着迷的，是大型语言模型颠覆了技术扩散的历史路径。历史上每一项重大技术——从电力到计算机、从 GPS 到互联网——最初都是政府或军方专属，再逐步传导到企业与个人用户。但 LLM 却反其道而行之，这一次最早被触达、最深度应用的场景，是“煮鸡蛋”这样的日常任务，是写作、查资料、规划旅行这样的大众应用。
这是一种从底层社会结构向上传导的扩散过程，政府与企业反倒成为“追赶者”。ChatGPT 等工具几乎是“从天而降”进入全球用户的屏幕，技术的普及速度之快、应用广度之广，前所未有。
总结这场范式迁移的核心特征：
LLM 实验室是新型“智能工厂”；模型平台构成操作系统生态；当前处于 1960 年代式的集中计算格局；LLM 被当作公共基础设施使用；技术扩散路径发生逆转，大众成为首批用户；模型以终端形式迅速渗透全球桌面环境。
正是在这样的背景下，新一代开发者开始编程这些“新计算机”，进入一个与以往完全不同的工程世界。
Part2：LLM 心理机制在正式开始写 prompt、构建 agent 之前，更重要的是深入理解语言模型的心理机制与结构本质。
Karpathy 用“人的精神的随机模拟体（stochastic simulations of people）”来定义 LLM。它并不是传统意义上的计算系统，而是某种泛人类语言经验与推理模式的集合体，由 Transformer 架构实现，每个 token 的预测消耗相似计算量，模拟出对话与推理过程。
这些模型通过大量网络文本训练形成“泛人类语言模拟器”，自然也表现出一些心理学上的“人格缺陷”：比如在部分推理任务中展现超人能力，却又可能在拼写或逻辑判断中犯下低级错误。
Karpathy 举例称，这些模型可能会坚持认为 “9.11 > 9.9”，或拼错 “strawberry”，难以判断是否包含两个 “r”。这就是语言模型的双重特性——既是全知的“数字雨人”，又是偶尔出错的初学者。
这种“锯齿状的智能”极难预测，它在某些方面表现得像个天才，在另一些方面却像个糊涂虫。语言模型还存在“顺行性遗忘症”（anterograde amnesia），就像一个每天都重启的同事，无法累积经验，也无法巩固记忆。它不具备自然学习能力，不会自己变聪明，必须依赖外部人为地管理其“工作记忆”——即上下文窗口。
这也是很多人误用语言模型的根源所在。它不会记住用户的偏好、风格或历史交流，也无法像人类一样渐进式地构建认知与能力体系。因此，Karpathy 强烈推荐观看《记忆碎片》（Memento）与《初恋 50 次》（50 First Dates）两部影片，它们的主角每天醒来都丧失记忆，这种设定与语言模型的运行机制高度相似：权重固定、记忆短暂，每一次交互都是从零开始的“重启”。
除了记忆局限，语言模型还存在显著的安全隐患。它非常容易受到 prompt injection 攻击，可能在无意识中泄露信息或暴露敏感数据。必须始终牢记：这是一位具备超能力却存在认知缺陷的“超级同事”，如何引导其能力、规避其短板，是工程与产品设计的核心问题。
Part3：Karpathy 看到的机会转向更现实的议题：如何有效使用语言模型？有哪些新兴方向值得关注？Karpathy 提出一类值得重视的产品形态——“部分自治型应用”（partial autonomy apps）。
以写代码为例，虽然可以直接打开 ChatGPT，复制粘贴 bug、提问并获得答案再回贴，但这种方式效率低、上下文管理复杂，交互体验也缺乏结构。更高效的方案是为特定任务设计专用应用，以图形界面与任务流程相结合，从而获得更优解。
Cursor 是目前广泛使用的 LLM 编程应用之一，代表了这类“部分自治型应用”的雏形。其关键特征包括：
自动管理上下文：能识别开发者当前在做什么，并主动加载相关文件内容；编排多模型调用：后台调用嵌入模型构建代码索引，再调用语言模型处理逻辑与补丁，实现多 Agent 协作。Cursor 不仅保留传统 IDE 的交互习惯，还叠加 LLM 的智能能力，实现更自然的工程流。Karpathy 强调，图形用户界面（GUI）在这一类应用中极其关键，不应只依赖文本交互完成任务。
以代码补丁为例，与其让语言模型输出自然语言解释更改内容，不如用视觉化的红绿 diff 标记来展示修改差异。一目了然的界面、快捷键支持、明确的接受/拒绝机制，使得人类可以高效参与决策，并监督模型的“动手能力”。
他进一步提出“自主性滑块”（autonomy slider）概念，允许用户灵活控制 LLM 的干预程度。在 Cursor 中可以：
只使用补全（tap completion）；用快捷键改写选中段落（Command+K）；重写整个文件（Command+L）；或赋予 agent 完全权限在整个仓库中操作（Command+I）。这种“权限调节机制”让用户可根据任务复杂度自由切换在人类主导与 AI 主导之间，有效平衡 agent 的效率与可控性。
另一个成功的例子是 Perplexity，其特征结构与 Cursor 高度类似：
信息集成能力强，界面清晰；能调度多个 LLM 模型协同工作；拥有 GUI，允许用户追溯引用、审阅内容；提供自主性滑块，从简单搜索到十分钟后生成完整研究报告，覆盖从低干预到高自治的多种使用场景。这些产品形态启发一个更深层的问题：未来大多数软件都会演化为“部分自治系统”，那它们究竟应该长成什么样？
对产品经理与开发者而言，核心挑战是：如何让一个产品拥有可控的智能自主性？
需要逐一回答的问题包括：
LLM 能否“看到”用户所能看到的全部信息？LLM 是否能以用户可以接受的方式采取行动？在任何阶段，用户是否都能插手、监督、修正 AI 的行为？这些问题构成了“新型软件产品设计”的起点。在传统软件中，行为路径由硬编码定义；在软件 3.0 时代，产品行为由 prompt、工具调用、上下文感知与多模型编排共同构建，而 GUI 与“自治滑块”则成为承接人机共创逻辑的关键机制。
语言模型不是完美系统，它需要人类“始终在环中”参与运作。就像 Photoshop 的 diff 呈现方式一样，传统软件中大量面向人的按钮、参数、面板，都将因 AI 的接入而面临重构。GUI 的设计必须围绕如何让人类与 AI 更高效地协作重新思考。
生成—验证闭环的速度决定了 LLM 应用的产出效率。加快这一闭环的方式主要有两个：其一是优化验证流程，尤其是通过图形界面。GUI 可以激活大脑的视觉系统，相较于处理文本，图像更易理解、更具审阅效率。其二是为 AI 系上“绳子”，防止其行为过度主动、超出人类可控边界。
Karpathy 指出，agent 的能力虽令人兴奋，但让它一次性在代码仓库里提交 1000 行 diff 并不可取。即使生成速度再快，审阅仍是瓶颈。他倾向于“小步快走”，每次引入最小可控更改，确保每一步都是正确、合理的。AI 过于主动时，系统反而更难使用，也更易出错。
部分博客开始总结如何与 LLM 高效协作的最佳实践。例如写 prompt 时必须具体清晰，否则验证失败就会导致多次无效迭代。越清晰的 prompt，验证效率越高，整体协作流程越顺畅。未来，每位用户都将发展出自己的一套 prompt 写作与 AI 协作风格。
他进一步探讨 AI 时代对教育系统的冲击。与其让 ChatGPT 直接教授知识，不如将教学任务拆分为两个系统：一个为老师使用，用于生成课程内容；一个为学生服务，用于传达课程。课程本身作为“中间产物”，可供审核、统一风格、防止偏题，是“拴住 AI”的有效路径。这种结构性设计更易推广，也更符合 AI 教学系统的实际要求。
Karpathy 将 LLM 应用比作自动驾驶系统，指出两者的核心理念与难点非常相似。他在 Tesla 工作 5 年，深度参与 Autopilot 的“部分自主系统”构建。仪表盘是 GUI，自主性滑块控制介入程度，这些设计理念直接可迁移到 AI agent 系统中。
回忆 2013 年第一次体验自动驾驶情景时，他仍记得乘坐 Waymo 测试车、佩戴 Google Glass 的感受。那段体验带来的震撼让人以为自动驾驶即将全面普及。但 12 年过去了，自动驾驶仍未攻克，依然需要大量远程接管与人工干预。这说明真正改变世界的系统通常要经历一个远比预期更长的技术演化周期。
语言模型的复杂性与自动驾驶不相上下。“2025 是 AI Agent 之年”这样的说法太过草率，更现实的说法是：这是 AI Agent 的十年周期，需要长期迭代、人类持续在环、渐进推进。这种软件形态，不是一次性的 demo 项目，而是必须严肃对待的基础设施演化过程。
他再次引用喜爱的类比对象——钢铁侠战衣（Iron Man suit）。战衣是增强工具，也是 agent，是自主性滑块的具象化表现。理想产品应是人机共驾的“智能战衣”，而非全自主的“AI 机器人”。应聚焦于构建部分自主性产品，内建 GUI、UX、交互逻辑和权限调节机制，让人类主导、AI 协助的模式变得流畅高效。
产品目标应是：构建能加速生成—验证闭环的工具，同时保留未来放权自动化的路径。产品架构中要具备可调节的“自主性滑块”，并设计机制支持随着时间推移逐步释放权限，让系统越来越智能。
此类产品形态潜藏大量机会，是当下值得重点关注的发展方向。
谈及自然语言作为编程语言的革命性意义，Karpathy 表示，过去人们需耗费 5～10 年学习一门编程语言才能参与软件开发，如今只需掌握自然语言。人人都是程序员，只要能说话，就能操控系统，这是前所未有的变革。
他提出“vibe coding”概念——最初是一个洗澡时灵光一现的推文，意外爆红，甚至被制成了 Wiki 条目。vibe coding 是一种基于自然语言与智能系统协作的全新编程方式，它将程序设计过程从写代码转变为“调节系统氛围感（vibe）”和描述意图。
他提到 Hugging Face 的 Thomas Wolf 曾分享过一段孩子们进行 vibe coding 的视频。孩子们在没有代码知识的前提下，通过自然语言描述构建体验，展现出强烈的创造欲与沉浸感。他称这段视频为最喜欢的视频之一，“怎么可能在看到这段视频后，对未来感到悲观？”
vibe coding 是一代人进入软件世界的“入门药物”，它将以极低的门槛唤起数十亿人的创造冲动，带来前所未有的开发者浪潮。他对这一代人感到振奋，并亲自参与尝试。
他用 vibe coding 构建了一个 iOS 应用，即使不懂 Swift，也能通过 prompt 和 LLM 协作完成一款可运行的 app。整个开发过程仅耗时一天，尽管应用功能简单，仍让他感到惊讶：智能协作工具已经将开发门槛降至极低水平，让软件开发进入了一个真正大众化的时代。
Karpathy 在演讲最后部分分享了他以 LLM 为基础进行产品构建的实际经历，进一步佐证了“人人都是程序员”这一观点。他并未学习 Swift，但依然能在一天内构建出一个可运行的 iOS 应用。不再需要五天啃完教程才能开始动手，vibe coding 为“不会写代码的人”打开了全新创作入口。
他还介绍了自己开发的 MenuGen 应用，初衷源自一个真实痛点——看不懂餐厅菜单。他希望菜单能配上图片，便着手开发该工具：用户打开网页、拍摄菜单，系统自动生成菜品图像。每位用户享有 5 美元免费额度。虽然目前这个应用是“巨大亏损中心”，但他依然乐在其中。
最简单的是模型原型，最复杂的是部署运维。MenuGen 的网页功能几个小时便完成，真正耗时的，是上线、集成身份验证、处理支付、配置域名等繁琐流程。他以整合 Google 登录为例，需要引入 Clerk 库，并按指示执行多个跳转、配置步骤。这种体验让他反思：如果系统已经具备 Agent 能力，为何这些重复劳动仍需手动完成？GUI 与流程逻辑依然是为人类而非 Agent 所设计的。
由此引出一个核心议题：是否能开始构建为 Agent 而生的软件系统？
人类与网页交互已有标准接口如 GUI、API；但 AI Agent 作为“类人计算者”，也需获得适配层。他设想，网站能否提供一个类似 robots.txt 的 llm.txt 文件，以 Markdown 结构明确说明页面用途、结构与行为逻辑，为 LLM 提供标准化、高效率的交互入口。
目前大部分技术文档是写给人看的，包含图像、排版等装饰性信息，不利于 LLM 理解。而 Vercel、Stripe 等公司已开始使用 Markdown 编写文档，这种结构天然适配语言模型，是 LLM 可读化的重要方向。
他举例自己学习动画制作框架 Manim 的经历：通过复制整份文档给语言模型，再描述想做的动画，LLM 一次生成了完全符合预期的代码，无需他查阅文档或理解库的结构。这意味着，文档如果格式化得当，非程序员也能借助 LLM 进行专业创作，释放巨大创造潜力。
不过，Karpathy 指出，文档结构改造只是第一步，更关键的是改变内容表达方式。传统说明文档中“点击这里”等描述毫无语义，LLM 无法执行。像 Vercel 正在将所有“点击”类指令替换为可执行的 curl 命令，Agent 就能调用 API 而非依赖 GUI。这是一种主动为 Agent 适配的信息架构更新。
Anthropic 提出的 Model Context Protocol 则进一步定义 Agent 如何以消费者身份与数字信息交互。他非常看好这类协议，Agent 不再只是被动执行模型，而是成为 Web 的活跃角色、第一类信息公民。
为支持这一结构转变，一些工具开始将网页数据转化为 LLM 可用结构。例如将 github.com 改为 get-ingest.com，可自动生成完整目录结构与整合内容文本，适配 LLM 处理逻辑。另一个例子是 Deep Wiki，不仅展示仓库代码，还调用 AI Agent 进行结构分析并自动生成文档页面，大幅提升语言模型的读取效率与理解能力。
他特别欣赏这类只需“改个 URL”就能获得 LLM 可读数据的小工具，称其优雅且实用。虽然 LLM 已能执行点击与界面操作，但这些操作极其昂贵且易错，应主动为其降低交互门槛，提前在基础结构层优化路径。
目前大量 Web 系统并非为 Agent 而设计，开发活跃度低、结构混乱。长尾系统将永远无法自动适配。建立面向 LLM 的中介转接层，是兼容旧系统的唯一路径；而对于现代系统，完全有能力从源头构建适配 Agent 的交互接口。
最后，Karpathy 再次回到他最喜爱的类比——钢铁侠战衣。这不是全自动机器人，而是增强工具，是 agent 与人类协作的终极形态。未来 10 年，整个行业将像这套战衣一样，从辅助开始，逐步放权，构建高度自动化与高可控性并存的智能系统。
本文由人人都是产品经理作者【江天 Tim】，微信公众号：【有新Newin】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash普患配资，基于 CC0 协议。
升富配资提示：文章来自网络，不代表本站观点。
