Software 3.0——自然语言成为可编程接口

Software 3.0 是 Andrej Karpathy 对一种新计算范式的命名：人不再主要通过逐条规则或训练数据“编程”，而是把任务、材料和约束写进自然语言上下文，由大语言模型解释并执行。源稿强调，这不只是让旧流程更快，而是改变了什么算程序、什么算接口、以及人应把注意力放在哪里。[^1]¹

三代软件的编程材料

源稿以安装软件为例：旧路径试图写一个覆盖所有操作系统、硬件和依赖组合的安装脚本；3.0 路径则把一段说明交给 AI 助手，让它检查环境、安装依赖，并在出错后继续调试。这里改变的不是“有没有代码”，而是谁生成代码、人在何处施加约束。[^1]¹

flowchart LR
    A[Software 1.0\n人写规则] --> D[确定性程序]
    B[Software 2.0\n人备数据与目标] --> E[学习出的权重]
    C[Software 3.0\n人写意图与上下文] --> F[模型解释并调用工具]
    F --> G[测试、审查与现实验收]
    G -.反馈约束.-> C

从“做一个 App”到“直接完成任务”

应用的消解展示了这一范式的产品后果。Karpathy 曾用 AI 辅助完成 MenuGen：前端、后端、识别、图像生成、账号、支付和部署都齐全；后来他演示，只需把菜单照片和一句“把菜的样子画在菜单上”交给模型，就能直接得到目标图片。源稿据此判断，中间那套完整 App 在这个具体任务上可能被输入—输出直连折叠掉。[^1]¹

这并不意味着所有应用都会消失。账号、权限、审计、长期状态、支付与多人协作仍可能需要稳定系统；“一句话完成”更适合目标可清楚表达、输出可直接检查的任务。Software 3.0 改写的是默认起点：先问能否直接完成任务，再决定是否值得建造长期中介层。

人的工作上移到规格与验收

源稿同时给出一个反例：AI 曾用邮箱地址关联 Google 登录用户与 Stripe 支付。两个系统可能使用不同邮箱，因此这个看似顺手的实现会丢失付款归属。经验丰富的工程师会要求统一用户 ID，因为问题的关键不是代码语法，而是跨系统身份合同。[^1]¹

因此 Software 3.0 与意图工程并不等于“人不必理解”。人的工作转向：

1. 写清规格与不可变身份；
2. 设计可验证的边界与失败模式；
3. 判断什么值得构建；
4. 对结果、安全和后果承担责任。

这也解释了为什么源稿把 AI 称为能力尖锐的实习生：它能快速施工，但建筑师仍要决定地基、接口与验收标准。把实现交出去而保留理解，与认知卸载中“把理解本身一并外包”是两条不同路径。

边界

• “三代”是理解编程媒介变化的框架，不是严格替代史；规则代码、神经网络和语言模型会长期共存。
• MenuGen 是一个具体任务案例，不能证明所有 App、SaaS 或稳定后端都已失去价值。
• 自然语言降低表达门槛，但不会自动产生正确规格；概率性执行仍需测试、安全审查与责任归属。
• 源稿中的项目经历、访谈说法和技术判断按频道材料整理，本页没有把它们升级成独立行业统计或普遍预测。

关联

• 生产方式：意图工程 · 氛围编码 · 应用的消解
• 能力边界：参差智能 · 异类智能 · 机械可解释性
• 人的保留项：认知卸载 · 自我资产与杠杆

[^1]: Karpathy说你写的App根本不该存在。.md

注释

1. Karpathy说你写的App根本不该存在。 ↩