最近看了 Andrej Karpathy 的一场分享。

其中有个细节，我印象很深。

Karpathy 用 AI 做了一个小应用：用户拍下餐厅菜单，应用识别菜名，再生成对应的菜品图片。

这个想法来自一个很生活化的烦恼——很多时候，我们看得懂菜单上的字，却不知道端上来的菜究竟长什么样。

他不会写 Swift，但借助 AI，只用了几个小时，就做出了一个能在手机上运行的 Demo。

听到这里，很多人的第一反应可能是：软件开发真的被彻底改变了。

但接下来的故事更有意思。

核心功能只花了几个小时，真正把它变成一个可用产品，却又花了一周。

用户怎么登录？支付怎么接入？额度怎么管理？服务怎么部署？第三方平台怎么配置？出现问题后怎么排查？

这些事情并不“智能”，也没有演示视频那么令人兴奋，却占据了绝大多数时间。

有时，AI 会生成一大段操作说明，告诉他打开哪个网页、点击哪个按钮、展开哪个菜单，再复制哪一段内容。

Karpathy 忍不住问：

既然计算机已经知道下一步该做什么，为什么还要由人来替它点击？

这个问题，几乎概括了我们当前所处的阶段。

AI 已经可以写代码、做计划、查资料、生成内容，但我们周围的软件、流程和基础设施，仍然建立在一个旧假设上：

每一步操作，最终都要由人亲自完成。

所以，这场分享真正讨论的，不是 AI 会不会替代程序员。

它在讨论一个更大的变化：软件本身，正在改变。

而当 AI Agent 开始成为软件的新用户，今天的产品、文档和数字基础设施，也要跟着改变。

01

软件正在经历第三次变化

过去几十年，人类给计算机编程的主要方式并没有发生根本变化。

程序员使用 C、C++、Java、Python 等语言，把规则一条条写下来。用户点击某个按钮，系统执行某个动作；数据满足某个条件，程序进入下一步；出现某种异常，触发提前设置好的处理逻辑。

Karpathy 把这种软件称为软件 1.0。它的本质是，人先理解问题，再把解决方法翻译成计算机能够执行的明确指令。

这种方式很可靠，也很强大，但并不适合解决所有问题。

比如，如何通过摄像头判断前方是行人、车辆还是路牌？人很难提前写完所有规则。现实世界里总有新的边界情况。

于是，软件 2.0 出现了。

人不再直接编写全部规则，而是准备数据、设定目标，让神经网络通过训练得到一组参数。过去，程序的核心是一行行代码；在软件 2.0 中，真正发挥作用的是模型的权重。

Karpathy 在特斯拉负责自动驾驶时，亲眼经历过这种迁移。随着神经网络能力提高，原本依靠人工规则完成的摄像头信息融合、环境识别和行为判断，逐渐被模型接管。

软件 2.0 并不是简单地辅助传统代码，而是在一点点“吃掉”原来的软件架构。

现在，类似的变化又发生了一次。

大语言模型可以总结文章、写代码、解释概念、分析表格、调用工具，甚至连续执行多个步骤。

更关键的是，我们不再需要用传统编程语言逐条描述过程。只要用自然语言说明目标、背景和约束，模型就能尝试完成任务。

Karpathy 把这种形态称为软件 3.0。

软件 1.0，是人编写代码；

软件 2.0，是人准备数据，通过训练生成参数；

软件 3.0，则是人使用自然语言，直接给模型编程。

自然语言本身开始成为一种编程接口。这意味着，可以调动计算机的人，突然变多了。

软件 3.0 并没有让专业能力消失。它只是把“谁有资格编程”的门槛，向外推了一大步。

应该如何理解大语言模型？有人把它比作电力。

大型 AI 公司投入巨额资金训练模型，通过 API 把智能能力提供给企业和个人，再按照使用量收费。我们希望它低延迟、高可用、随叫随到。主流模型一旦宕机，很多人的工作也会跟着停下来，像是发生了一次小型的“智能停电”。

这个类比很形象，但并不完整。

电力是一种相对标准化的商品，但不同大模型的能力、行为、工具生态和使用体验差异很大。它们不是简单的“智能水龙头”，而是在逐渐形成复杂的软件生态。

因此，Karpathy 认为，大语言模型更像一种新的操作系统。

模型负责理解任务和调度能力，上下文窗口像工作内存，外部工具像操作系统能够调用的程序，而 Cursor、Perplexity 等产品，则像运行在这个新系统之上的应用。

过去，我们常把大模型理解成某个软件中的新增功能：在原有页面右下角放一个聊天框，在原有流程旁边增加一个“AI 生成”按钮。

但如果大模型真的是一种新的操作系统，那么它带来的变化不会停留在增加一个功能。它会改变软件如何接收指令、如何组织信息，以及用户如何参与决策。

今天，我们与大模型交互的主要方式仍然是聊天框。Karpathy 认为，这很像早期计算机的命令行。

它足够通用，却未必适合所有任务。审核代码修改时，我们更希望看到清晰的增删对比；研究一个问题时，我们需要来源、引用和结构；处理图片、视频、设计或数据时，纯文字交互更不是最高效的方式。

所以，AI 时代真正通用的图形界面，可能还没有出现。

聊天框只是入口，不会是终点。

大语言模型很容易让人高估。

它读过海量资料，能够迅速生成结构完整的内容，在一些数学、编程和推理任务中，甚至表现得超过大多数普通人。

但与此同时，它也会犯一些让人难以理解的错误。它可能解决了复杂问题，却在简单计算上出错；可以写出一段像模像样的分析，也可能编造不存在的事实。

一个新同事入职后，会慢慢了解公司的客户、历史、流程和人际关系。工作时间越长，这些背景会沉淀成判断力。

大模型很难自然完成这个过程。每次新对话开始，它都像重新入职一次。

它不知道团队之前做过什么决定，不知道一个客户过去踩过哪些坑，也不知道某个看似简单的需求背后，隐藏着怎样的利益和风险。

所以，大模型并不是拿来就能工作的成熟员工。它更像一个能力很强、学习很快，但每天都会失去部分记忆的新同事。

你必须重新给它交代背景、提供材料、说明边界。

这也是为什么，AI 时代真正重要的能力不只是写提示词，而是组织上下文。

对企业来说，上下文散落在文档、邮件、会议纪要、聊天记录和老员工的经验里。

很多公司使用 AI 效果不好，并不是模型不够聪明，而是组织自己也没有把知识整理清楚。

从这个角度看，AI 不只是一种效率工具，也像一面组织体检镜。

它会逼着企业回答：我们的知识，究竟是公司的资产，还是少数人脑中的秘密？

市场很喜欢谈全自动 Agent。给它一个目标，它自己制定计划、寻找资料、调用工具，最后把结果交给人。

这种演示很吸引人。但 Karpathy 对完全自主的系统保持谨慎。

他曾经在特斯拉工作多年，也很早体验过自动驾驶。2013 年，他坐过一次几乎全程不需要人工干预的自动驾驶汽车。那次体验非常顺畅，很容易让人相信：自动驾驶很快就会成熟。

但十多年过去，这个问题仍然没有被彻底解决。

在一条固定路线、一次精心准备的演示里表现完美，和在开放世界中长期、稳定、安全地运行，是两件完全不同的事。

AI Agent 也是如此。它可以快速生成一千行代码，但人仍然要确认这些代码有没有漏洞，会不会破坏原有功能，是否符合安全和合规要求。

生成只需要几秒，验证可能需要几个小时。这时，真正的瓶颈已经不在 AI，而在人类这一侧。

Karpathy 提出了一个很实用的概念：自主性滑块。

任务越清晰、风险越低、结果越容易验证，就越适合把滑块向右推；任务越复杂、影响越大、错误成本越高，就越需要人留在闭环里。

真正成熟的人机协作，不会建立在盲目信任上，也不会建立在处处设防上。

它更像驾驶：路况简单时，可以让系统承担更多；情况复杂时，人随时准备接管。

很多人认为，自然语言交互会让传统界面逐渐消失。

既然用户可以直接说出需求，为什么还需要按钮、菜单和复杂页面？

但在 Karpathy 看来，图形界面不会因为 AI 而失去价值。相反，它可能变得更加重要。

原因是，AI 生成得越快，人就越需要高效地理解和检查结果。

在代码编辑器中，新增内容和删除内容会以清晰的方式显示。用户不需要逐字阅读模型的解释，只要看差异，就能快速判断是否接受。

在搜索和研究产品中，来源会被标注出来，方便用户核查信息。

这些设计看起来只是交互细节，实际上决定了人机协作能不能顺畅运行。

AI 产品的核心体验，不应只关注“模型能生成什么”。更重要的是，用户如何看懂它做了什么，如何修改，如何撤销，以及如何在关键节点重新取得控制权。

好的 AI 产品，可能不是拥有最炫的聊天框，而是能够把模型复杂的工作过程，转化成人类容易理解、容易判断的形式。

对于职场人来说，这也意味着一种新的能力正在变得重要：验证能力。

AI 可以缩短执行时间，却不会自动替人承担责任。

过去，数字世界主要有两类使用者。

一类是人。人通过网页、按钮、菜单和图形界面使用软件。

另一类是程序。程序通过 API 调用功能、交换数据。

现在，第三类使用者出现了：AI Agent。

Agent 既不像传统用户，也不像传统程序。它可以理解自然语言，能够做一定程度的判断，也可以调用工具。

但今天绝大多数软件并不是为它设计的。

传统文档经常写：先打开网页，点击右上角的设置，再展开菜单，进入某个页面，选择某个选项。

这套说明对人很自然。但对 Agent 来说，它需要先识别页面结构、理解按钮位置，再控制浏览器模拟点击。整个过程速度慢、成本高，也很容易因为页面变化而失败。

如果软件直接提供命令、API 或结构化工具，Agent 就不必模仿人类操作鼠标。

这也是为什么，一些公司开始重新整理文档，把内容转换成更适合模型读取的 Markdown 格式。Anthropic 推出的 MCP，也是在尝试让模型能够用更标准的方式连接外部数据和工具。

既然用户变了，产品就要跟着变。

未来，一个成熟的软件可能需要同时准备三套入口：面向人的图形界面，面向传统程序的 API，以及面向 Agent 的上下文、工具和操作协议。

这并不意味着每一个产品都要立即重做。但那些流程复杂、信息密集、需要跨系统操作的产品，会更早感受到变化。

企业服务、开发工具、数据分析、客户支持、财务流程和知识管理，很可能是这轮重构最先发生的地方。

当计算机已经理解下一步该做什么，却仍然需要人类充当“鼠标操作员”时，新的产品机会往往就在那里。

自然语言成为新的编程接口，最容易让人产生两种相反的情绪：一种是兴奋，另一种是焦虑。

我更倾向于把这次变化理解为一次价值迁移。

过去，一个人的价值可能主要体现在执行速度上。谁能更快写完代码、更快整理表格、更快做完一份报告，谁就更有优势。

当 AI 把执行成本大幅降低后，价值会逐渐向任务的上游和下游移动。

上游是定义问题、补充背景、拆解任务；下游是判断质量、处理例外、承担责任。

对于 26—35 岁的职场人来说，真正需要警惕的，不是 AI 会不会完成你手里的任务，而是自己是否长期停留在“等待任务、接收要求、完成动作”的位置上。

AI 越强，越需要有人把模糊目标变成清晰任务，把复杂问题拆成可以执行的步骤，再把不同资源组织起来。这正是从执行者走向管理者时必须建立的能力。

对于 36—45 岁的管理者和资深专家来说，挑战则是另一种。

过去积累的经验依然重要，但需要从个人经验变成组织能力。

真正难以替代的，不是“只有我知道”，而是我能识别复杂问题、提炼规律，并建立一套让更多人受益的工作系统。

AI 可能会放大两类人的差距：一类人只是重复过去的经验，另一类人能够把经验转化为方法、流程和判断标准。

Karpathy 把今天的大语言模型比作 20 世纪 60 年代的计算机。

算力昂贵，系统集中在云端，用户通过简单终端访问，真正成熟的个人计算形态还没有出现。

这个比喻让我意识到，我们今天看到的 AI 产品，可能仍然非常早期。

聊天框、代码助手、搜索工具和各种 Agent，只是第一批应用。

接下来真正困难的，不是让模型再多写一些代码，而是重新设计模型与人、软件和组织之间的关系。

软件怎样向 Agent 提供信息？人怎样快速验证 AI 的工作？哪些权限可以交出去？哪些责任必须留下来？组织如何把隐性经验变成可使用的上下文？

这些问题没有模型参数那么引人注目，却会决定 AI 最终能不能进入真实工作。

每一次技术革命开始时，人们都容易盯着最显眼的技术指标。但真正改变生产力的，往往不是技术第一次出现的时刻，而是人们终于愿意围绕它重新设计工作方式的时刻。

AI 会写代码，只是开始。

接下来真正困难、也真正有价值的工作，是重新设计软件，重新设计流程，也重新设计我们自己在其中的位置。