Andrej Karpathy 在 Stanford 的这场演讲，表面上是一场关于 Transformer、GPT 和提示工程的技术分享，真正值得留下的核心判断只有一句：软件正在从“人来设计算法”，转向“人来设计数据和语言程序”。模型能力越强，工程师越需要把注意力从代码细节上移到任务定义、反馈回路、上下文和验证机制上。
先说明一个观看时容易踩到的坑：视频页面标题写着 “Andrej Karpathy at Stanford: The Foundation that Became Anthropic”，但实际字幕内容并没有围绕 Anthropic 的创建史或 Claude 展开，主体是一场 Karpathy 讲解 Software 1.0、Software 2.0、Software 3.0、Transformer 与 Prompt Engineering 的演讲。下面的文章以视频实际内容为准，不沿着页面标题补写不存在的故事。
一、从写算法，到训练程序
Karpathy 把过去几十年的软件发展拆成了三个阶段。
Software 1.0 是最熟悉的编程方式：工程师把问题拆成明确步骤，再用 C++、Python、Java 或其他语言把算法写出来。程序员告诉计算机每一步应该做什么，计算机按照这些确定的指令运行。Linux 这样的复杂系统，就是在这个范式里逐渐建成的。
这种方法对规则清晰的问题非常有效。排序、网络协议、数据库索引、编译器、操作系统，都可以通过人类设计算法来实现。困难出现在那些规则无法被完整写出的任务上。图像中的猫可以有无数姿态、光照和背景，棋局的好坏依赖长链路判断，自动驾驶需要处理开放环境中的大量例外。面对这些问题，工程师很难把“识别一只猫”写成一套覆盖所有情况的 if-else。
Software 2.0 由此出现。它把神经网络看成一种新型程序：程序员不再手写最终的决策规则，而是准备数据集、定义训练目标、运行优化过程，最后得到一组神经网络权重。权重就是程序，只是这份程序无法直接用文本手工编写。
Karpathy 用自己在 Tesla 做自动驾驶的经历解释了这个过程。团队先训练一个模型，把它部署到真实环境中；系统运行后会产生大量遥测数据，模型在困难场景中的表现会暴露问题；工程师再收集这些困难样本、完成标注，将其中一部分放入测试集，另一部分加入训练集，重新训练模型。这个循环不断重复，模型能力随着数据和反馈一起迭代。
这套流程的重点不在“模型训练”四个字，而在 data engine，也就是数据引擎。数据采集、难例发现、标注策略、测试集设计、线上监控，构成了 Software 2.0 的真正生产系统。只会调模型结构，却没有持续获得高价值数据的团队，很难长期保持优势。
这里还有一个重要边界：Software 2.0 没有消灭 Software 1.0。训练脚本、数据管道、评测程序、部署系统、监控服务，依然需要大量传统代码。更准确的理解是，两种软件叠加在一起：传统代码负责组织流程，神经网络负责处理难以显式表达的判断。
二、Software 3.0：程序写在 Prompt 里
Karpathy 认为，最近一轮变化来自大型语言模型。语言模型最初的训练目标看起来很朴素：根据前面的内容预测下一个词。模型规模扩大、参数量增加、训练数据覆盖整个互联网后，这个预测任务开始表现出超出直觉的能力。
模型可以生成文章、回答问题，也可以在上下文中完成任务。给它一段材料，再给出几组“问题—答案”示例，模型就可能按照这个格式继续回答。这里没有发生传统意义上的梯度更新，模型参数没有被重新训练；任务行为通过上下文被临时激活了。
这就是 in-context learning。模型内部已经学到大量语言模式和任务模式，Prompt 负责从中挑出一条合适的路径。Karpathy 将这种方式称为 Software 3.0：Software 1.0 由人设计算法，Software 2.0 由人设计数据集，Software 3.0 则由人设计 Prompt，让模型运行一段自然语言程序。
他的那句名言“最热门的新编程语言是英语”，重点不在英语本身有多神奇，而在编程接口发生了变化。过去的程序接口要求调用者严格遵守函数签名、参数类型和控制流；语言模型接口允许工程师用自然语言描述角色、目标、约束、输入格式和输出格式，再由模型完成剩余部分。
这也解释了为什么 Prompt Engineering 很快成为一项正式工作。Prompt 不是一句“请帮我写得更好”，它可以是一份运行时程序，包含状态定义、工具协议、输出 Schema、异常处理、安全边界和任务分解方式。Bing 的 Sydney、智能家居助手、自然语言驱动的后端，都可以被看作通过文本实例化出来的虚拟系统。
视频里有一个很直观的例子：让 ChatGPT 假装成为 Linux 终端。用户输入 pwd、ls、cd 等命令，模型根据前文维护一个虚构的文件系统；当用户创建 jokes.txt，后续 ls 和 cat 会反映前面的状态。现实中没有真正的磁盘，也没有真正执行 shell，模型只是在上下文中维护一套关于系统状态的模拟。
这个例子很有启发性，也暴露了风险。只要任务停留在文字模拟层，结果可以很像真的；一旦把结果交给真实系统执行，模拟与事实之间的差距就会变成故障。模型说“命令已经执行”并不等于命令真的执行，模型给出的 IP、文件、计算结果和 API 响应，都必须经过外部工具或独立验证。
三、Prompt 不是魔法，结构决定上限
Karpathy 展示了一个数学题：一个杂耍演员能抛 16 个球，其中一半是高尔夫球，高尔夫球中一半是蓝色，蓝色高尔夫球有多少个？模型直接回答时可能得到错误结果，因为它很快完成了文本续写。加入“请一步一步思考”的提示后，准确率明显提高；进一步要求“为了确认答案正确，让我们一步一步算出来”，表现还会提升。
这里的关键不在于给模型增加人格，而在于给推理过程增加结构。模型每生成一个 token，能够使用的计算空间有限。把复杂任务拆成多个中间步骤，相当于允许模型在更长的序列里逐步展开计算。对于需要多步推理的系统，Prompt 设计已经接近程序设计：要决定中间变量是什么、检查点在哪里、何时允许继续、何时必须回滚。
同一逻辑也适用于知识问答。模型如果没有明确约束，往往会生成互联网平均水平的回答。要求它以某个领域专家的视角回答，可以改变输出分布，但这并不意味着模型真的获得了专家身份。Prompt 只是选择了模型内部某一片知识和表达模式，事实准确性仍需要来源、检索和评测支撑。
因此，一个可靠的 Prompt 至少应包含以下信息：任务目标、输入边界、判断标准、输出格式、失败处理和禁止事项。若系统需要调用工具，还要额外描述工具的参数、权限、幂等性和结果校验方式。把这些内容都塞进一段自然语言，当然可以工作；长期运行时，最好把它们拆成可版本管理、可测试、可观测的配置和模块。
四、Transformer 为什么能成为通用底座
演讲的后半部分回到 Transformer 的技术基础。Karpathy 先回顾了 2012 年前后的深度学习转折点。当时的计算机视觉系统往往由大量手工特征拼接而成：颜色直方图、纹理描述子、几何特征，再接一个分类器。自然语言处理、语音、视觉和强化学习各自拥有独立的术语和方法，跨领域阅读的门槛很高。
大规模神经网络证明了一个可复制的事实：只要拥有足够大的数据、模型和计算资源，同一类学习框架可以迁移到多个领域。2017 年的 Transformer 进一步推动了架构收敛。图像可以切成 patch，语音可以切成频谱片段，强化学习可以把状态、动作和奖励组织成序列，分子或其他结构化信息也可以编码成 token。核心架构相似，变化主要出现在数据切分、编码方式、位置表示和训练目标上。
Transformer 的通用性来自两个阶段的交替。
第一阶段是 communication。每个 token 通过 query、key、value 与其他 token 交换信息，注意力权重决定哪些信息值得被聚合。第二阶段是 computation，每个位置独立经过多层感知机，对自身的表示做变换。多头注意力可以理解为多组并行的消息传递机制，多层堆叠则让信息在更深的计算过程中反复交流。
这个架构同时具备三个优势：表达能力强，能够实现复杂函数；优化相对稳定，残差连接和 LayerNorm 帮助梯度传播；硬件效率高，计算图相对扁平且宽，适合 GPU 并行。深度学习的规模竞争里，硬件效率会直接影响模型能做到多大，因此第三点往往和模型理论能力同样重要。
Karpathy 还用 nanoGPT 说明了一个训练语言模型的最小闭环：把文本编码成整数序列，切成固定长度的上下文块，用前面的 token 预测下一个 token，再通过交叉熵损失训练。生成时，模型输出一个 token，再把它放回上下文，继续预测下一个 token。上下文窗口就是模型能直接访问的短期记忆，窗口有长度上限，超过之后就必须裁剪、压缩或借助外部存储。
这也是 Agent 系统必须认真处理的工程问题。模型上下文不是无限记忆，长对话、工具调用记录、检索结果和中间推理如果全部堆在 Prompt 里，成本、延迟和噪声都会快速上升。更合理的系统需要把短期上下文、长期记忆、工作区文件、数据库状态和可重新获取的外部资料分开管理。
五、从“会回答”到“能完成任务”还差什么
Software 3.0 很容易让人产生一种错觉：既然语言可以编程，写几段 Prompt 就能替代后端系统。视频中提到的“GPT 作为后端”项目，确实展示了一个有趣方向：前端把状态和自然语言路由交给模型，模型返回新的 JSON 状态。待办事项可以通过“删除最后两项”这样的表达来操作，传统路由代码被模型部分吸收。
但生产系统不能只看演示效果。模型输出需要 Schema 校验，状态更新需要事务边界，权限操作需要显式授权，重要动作需要幂等与审计。自然语言提供了灵活性，也带来了歧义。对于删数据、发消息、改配置、控制机器人等动作，模型最多负责提出计划，执行层仍应由确定性代码把关。
从架构角度看，Agent 并非“一个更聪明的聊天框”，更接近一个由模型驱动的控制回路：模型读取状态，提出下一步动作，工具执行动作，系统返回观察结果，模型再做判断。这个回路是否可靠，取决于状态建模、工具契约、反馈信号和失败恢复，而非 Prompt 的文采。
Karpathy 在演讲中提到外部记忆和 scratch pad。模型拥有有限上下文时，可以把中间结果写入外部记事本，后续再按需读取。这个想法今天已经变成 Agent 的工作区、向量检索、任务数据库、运行日志和长期记忆。真正有效的记忆系统并非把所有历史都保存下来，而是明确什么值得保存、以什么结构保存、何时检索、如何确认内容仍然有效。
对于机器人云平台，这个判断尤其重要。机器人诊断 Agent 不应只把所有日志拼成一段长 Prompt，然后期待模型自动找出答案。更稳的做法是把机器人状态、任务上下文、告警时间线、传感器摘要、历史工单和诊断工具拆成结构化对象；模型负责选择调查路径和组织解释，规则引擎、时序库与设备接口负责提供事实。这样既能利用自然语言的灵活性，也能保留工程系统需要的确定性。
六、真正的 Software 3.0 工程师
看完这场演讲，最值得带走的能力清单有五项。
第一，能把模糊目标写成可验证的任务。模型并不自动知道“好答案”是什么，工程师需要把成功条件、边界案例和失败状态定义出来。
第二，能设计数据与反馈回路。对于传统模型，这是 data engine；对于 Agent，这是工具调用日志、人工修正、失败样本、评测集和线上观测。没有反馈回路，Prompt 只能靠感觉迭代。
第三，能把 Prompt 当成版本化程序。角色、上下文、工具、输出协议和安全规则都应可追踪，改动后需要回归测试，不能只靠“这次看起来不错”。
第四，能区分模型判断与系统事实。模型可以推测、归纳和规划，数据库、传感器、API 与执行器负责确认事实。两者边界越清晰，系统越容易调试。
第五，能在必要时回到底层。Karpathy 自己既讲 Prompt，也讲 attention 的矩阵运算和 nanoGPT 的 300 行实现。抽象层越高，越需要知道下面发生了什么，否则出了问题只能凭感觉改提示词。
这场演讲真正有价值的地方，恰好不在“英文成为新编程语言”这句容易传播的话。更深的变化是：软件系统的核心资产正在从静态代码扩展为“目标、数据、上下文、反馈和工具”的组合。未来的工程师既要会写代码，也要会设计模型可以执行的任务环境。
视频页面的标题把观众引向 Anthropic，字幕却把内容带回 Software 3.0。这个错位反倒提醒了一件很现实的事：任何 AI 内容都要先核对一手材料，再接受标题和摘要的叙事。对模型如此，对视频如此，对工程系统返回的每一条“看起来合理”的结果，也如此。
视频来源：Andrej Karpathy at Stanford: The Foundation that Became Anthropic（实际内容：Software 3.0、Transformer 与 Prompt Engineering）
频道：DarrowStation
原视频：https://www.youtube.com/watch?v=v-IeZBwO2UM
评论前必须登录！
立即登录 注册