一个让创造者最害怕的故事
2026 年 4 月底，Andrej Karpathy 在 Sequoia Capital 的 AI Ascent 年度大会上做了一场 29 分钟的炉边对话。没有发布新产品，没有秀肌肉，甚至没有放 PPT。但他说了一句话，让我反复琢磨了很久：
“That app shouldn't exist.”（那个 App 不该存在。）
他说的是自己做的 App。这篇文章，正是我反复消化这句话之后，对“我们到底该建什么”的一次系统梳理。
这位主角恐怕不需要太多介绍。OpenAI 联合创始人，Tesla Autopilot 前负责人，“Vibe Coding”这个词的发明者。今年 5 月，他加入了 Anthropic，负责领导预训练研究。
故事是这样的：2025 年，Karpathy 给自己做了一个小工具，叫 MenuGen。需求很直接——你走进一家餐厅，服务员递来菜单，上面没有图片，30% 到 50% 的菜你根本不知道是什么。于是他做了一个 App：拍下菜单照片，用 OCR 识别菜名，调用图像生成器生成菜品图片，再重新渲染菜单展示给你。整套系统跑在 Vercel 上，听起来有需求、有技术方案、有完整工程实现。
然后，事情发生了。
他看到了 Software 3.0 版本的做法，直接愣住了。你拿出手机拍下菜单，把照片丢给 Gemini，说一句：“用 Nano Banana 把菜品图片叠加到菜单上。”它直接返回一张图片，就是你刚拍的那张菜单，但每道菜旁边已经渲染好了对应的菜品图。
没有 App。没有 OCR。没有图像生成 API 调用。没有 Vercel 部署。没有前端，也没有后端。一个提示词、一张照片输入、一张照片输出，完事。
Karpathy 亲口承认：在 Software 3.0 的框架里，MenuGen 的所有代码都是多余的。它是旧范式里的产物。那个 App 不该存在。
这句话，出自它的创造者之口。
那么问题来了：你现在正在做的产品、正在搭建的系统、正在花钱开发的项目，有没有可能也是一个“不该存在”的 App？
一、三代软件，三次革命
要理解“你的 App 为什么可能不该存在”，先要回到 Karpathy 在 Sequoia Ascent 2026 上提出的完整框架。
Software 1.0 是传统编程。人类写明确的代码，确定性很强，精确，但面对边缘情况非常脆弱。程序就是代码。
Software 2.0 是机器学习。你创建数据集和目标，神经网络把程序“学习”到权重里。权重就是程序。
Software 3.0：人类写提示词；LLM是解释器，上下文窗口是程序。
Software 1.0：规则时代——我告诉你怎么做
想象你是一家工厂的老板，雇了一个极其听话但完全没有常识的工人。你必须把每个操作步骤都写清楚：
- 如果温度超过 80 度，就停机。
- 如果订单数量大于 100，就通知仓库。
- 如果客户投诉包含“退款”二字，就转接主管。
每一个场景、分支、例外，你都要提前想到并写成规则。这就是 Software 1.0。我们用了半个世纪。企业的 ERP、OA、财务软件，大部分都属于这一类。
它的优势是确定性：同样的输入永远得到同样的输出。致命弱点也很明显：规则永远穷举不完。现实太复杂，你写不完所有 if-else。
Software 2.0：模式时代——我给你看，你自己学
后来我们换了一种思路。不再告诉计算机“怎么做”，而是给它看大量例子：这是猫，这是狗，看过十万张之后，让它判断新照片是猫还是狗。
神经网络从数据里“学”到模式，把模式编码成模型权重。推荐算法、语音识别、人脸识别都属于 2.0。它能处理 1.0 无法穷举的复杂模式，但需要大量标注数据，训练成本极高，而且模型像黑盒子一样难以解释。出了问题，你不知道为什么，只能调参数再祈祷。
Software 3.0：上下文时代——你说人话，它去执行
现在进入第三阶段。上下文窗口变成 RAM，模型权重变成 CPU，提示就是编程。
以前你写代码编程，后来你用数据编程，现在你用自然语言编程。你的“程序”不再是一个 Python 文件，而是塞进上下文窗口的所有东西：提示词、说明书、知识库文档、示例、记忆、工具列表。LLM 读取这些“程序”，然后执行。
上下文窗口成为新的编程界面。你不再只为计算机写确定性指令，你在给一个智能解释器提供上下文，它能阅读、推理、调用工具、检查环境、调试错误，并自动适应。
Karpathy 用安装 OpenClaw（一个 AI 编程工具）的过程举例。传统思维里，你会写一个 shell 脚本来安装它，但脚本处理不同平台和配置时会极其复杂。在 Software 3.0 范式下，安装方法变成一段文字描述——复制粘贴给 AI Agent，它会智能地执行安装、调试错误、持续运行，直到一切正常，并自动适配你的机器。
用 Karpathy 的话说：“你要复制粘贴给 Agent 的那段文字是什么？这就是现在的编程范式了。”
这不仅是写 Prompt。三个时代之间的核心差异不是速度，而是抽象层级的跃迁。每次跃迁，人类需要控制的细节减少一个数量级，但所需的判断力和理解力却增加一个数量级。这一点至关重要，整篇文章的核心推论都建立在这句话上。
回到 MenuGen，这次把它展开看。
用户拍照
↓
前端界面（React）
↓
上传到后端服务器（Vercel）
↓
OCR文字识别（提取菜名）
↓
遍历每个菜名 → 调用图像生成API → 生成菜品图片
↓
后端拼接渲染结果
↓
前端展示新版菜单
这套系统包含什么？
- 一个前端应用
- 一个后端服务
- 一个 OCR 模块
- 一个图像生成 API 对接
- 一个渲染引擎
- 云部署和运维
放在旧范式里，这是一个完整的产品。
Software 3.0 版本（新范式）
用户拍照 → 一句话提示词 + 照片 → Gemini → 返回一张图
没有前端、后端、OCR、API 对接，也没有部署。
一个提示词 + 一个多模态模型 = 整个App。
Karpathy 完整的 MenuGen 应用，被一个单独的 Gemini 提示词完全淘汰。一次神经网络推理就完成了同样的事。用他的话说：“那个 App 不该存在。”
这个故事真正揭示的是商业问题，不只是技术问题
MenuGen 死掉，不是因为 Karpathy 技术不行——他可能是全世界最懂 AI 的 50 个人之一。它死掉，是因为它解决问题的方式需要太多“中间层”。
OCR 是中间层，图像生成 API 是中间层，Vercel 部署是中间层，前端渲染也是中间层。而 Software 3.0 的核心突破在于：当神经网络足够强大时，所有中间层都是多余的。
这提供了一个新视角：不要把 AI 看作“加速现有应用”的工具，而要看到“应用本身的消失”。创业者和内部开发者必须首先回答一个问题：“这个产品是否还应该存在？”
这已经是 Software 3.0 时代最重要的商业判断题。
三、三类“不该存在”的产品
把 MenuGen 的教训泛化之后，我发现三类产品在 Software 3.0 范式下极有可能“不该存在”。如果你正在做这类产品，或者正在向企业推销这类系统，值得认真想一想。
类型一：信息聚合型产品——将被“对话”取代
特征是核心价值来自“把分散的信息收集到一个地方，方便用户查看”。
典型代表：行业资讯聚合 App、新闻摘要、竞品监控；企业内部数据看板、BI 报表、运营日报；旅行攻略聚合平台。
为什么不该存在？它的核心逻辑是收集 → 筛选 → 展示。在 Software 3.0 下，你可以直接对 LLM 说：
“帮我总结今天我所在行业的五条最重要的新闻，用三句话概括每一条，标注信息来源。”
不需要 App，不需要订阅、登录、刷新。一句话，一个对话框。
信息聚合类产品的“中间层”——爬虫、分类算法、推荐引擎、前端展示——全部是多余的。如果你现在正在做一个“企业 AI 新闻监控系统”，停下来问自己：客户为什么不能直接问一个 Agent？
类型二：表单填写型产品——将被 Agent 自动化
特征是核心价值来自“引导用户一步步完成某个流程”。
典型代表：企业报销系统（填表 → 上传发票 → 审批）、入职流程管理（填信息 → 签合同 → 开账号）、客户需求工单系统（描述问题 → 分类 → 派单）。
为什么不该存在？因为“填表”这个动作本身就反人类。表单之所以存在，是因为 1.0 时代的系统需要结构化数据输入。在 Software 3.0 下，一个Agent可以直接说：
“我看到你拍了一张出租车发票，金额 87 元，日期 6 月 15 日。我帮你生成了报销单，审批人是张经理。需要我提交吗？”
用户甚至不需要打开一个 App。Agent 在后台完成了所有“表单”该做的事。
如果你正在给企业开发“智能表单系统”，想一想：客户真正需要的，是不是一个能帮他们消灭表单的 Agent？
类型三：单点工具型产品——将被多模态融合
特征是核心价值来自“对某一种特定输入做一种特定处理”。
典型代表：证件照生成工具、简历格式化工具、音频转文字工具、图片背景去除工具。
MenuGen 就是这个类型。它做的事情是：照片 → 文字 → 图片 → 拼接。每一步都是一个独立工具。当多模态模型足够强时，这些独立工具的功能会全部被“内化”。
你不再需要一个专门的“音频转文字”App——给 LLM 一段音频，它直接给你文字。也不再需要一个专门的“去背景”App——给 LLM 一张照片说“去掉背景”，它直接给你结果。
神经网络做的工作越多，你需要的应用层就越少。
四、三类“更应该存在”的产品
如果你读到这里开始焦虑，先深呼吸一下。Software 3.0 并不意味着所有产品都会消失。恰恰相反，有三类产品在新范式下会变得更加重要。
类型 A：具身连接型——连接物理世界的系统
特征是核心价值在于把 AI 的判断力传递到物理世界。
LLM 可以分析数据、生成文本、理解图片，但它不能直接控制工厂设备，不能直接操作仓库机械臂，也不能直接打开店铺的门。
举例来说：
- 制造业设备预警 Agent：不只分析数据，还要通过企业微信推送给维修班长，班长走到设备旁，打开 Agent 生成的维修工单执行操作。
- 仓储物流 Agent：不只优化路径，还要把指令下发到 WMS 系统，控制分拣机器人运动。
- 智慧农业 Agent：不只预测天气影响，还要控制灌溉系统的阀门开关。
在上一篇文章中，我提出过“场景手术法”。那三个成功案例——五金厂设备预警、电商差评挽回、合同自动审核——都属于具身连接型。
AI 的判断力 × 物理世界的执行力，才是真正不可替代的系统。这类产品不会被“一句话提示词”取代，因为它嵌入了现实世界的物理约束和组织流程。
类型 B：私有知识型——数据不出企业的系统
特征是核心价值在于在企业私有数据上运行 AI，而不是依赖通用模型的通用知识。
Gemini 能用一个提示词替代 MenuGen，是因为 MenuGen 处理的是公开、通用的信息——菜单菜名和菜品外观。但如果你需要的是这些：
- 基于企业过去 3 年的历史合同，判断新合同的风险条款；
- 基于某工厂 28 年老师傅的口述经验，诊断设备故障；
- 基于某品牌独有的客服话术库，生成品牌调性一致的客户回复。
这些信息，通用模型不知道，它们只存在于企业内部。
这就是RAG知识库和私有化部署的真正价值：不是因为模型不够好需要“增强”，而是因为企业的核心竞争力——那些隐性的、私有的、独一无二的知识——本身就不在公共互联网上。
你的私有知识库，就是你在 Software 3.0 时代的“程序源代码”。谁掌握了企业的私有知识，谁就掌握了 AI 落地的护城河。
类型 C：人机协作型——AI 出初稿、人做决策的系统
特征是核心价值不是替代人类，而是让人类做出更好的决策。
品味、判断力和规格设计仍然是人类的瓶颈。Agent 仍然会犯结构性错误，比如试图通过电子邮件地址来匹配 Stripe 和 Google 账户。
Karpathy 在 Sequoia 演讲中专门讲了 LLM 的“参差不齐的智能”（jagged intelligence）：LLM 可以在代码中找到零日漏洞，重构十万行代码库，但也会告诉你步行去 50 米外的洗车店——因为强化学习在可验证的领域训练很卖力，而在其他领域就跳过了。
这意味着 AI 极度擅长某些事，比如可验证、有明确正误判断的任务；但在需要常识、语境判断和承担责任的任务上，表现参差不齐。
所以最有价值的产品设计不是“全自动化”，而是：AI 负责初稿和重复劳动，人类负责审核和关键决策。
上一篇文章中合同审核的案例就是这个模式。Agent 完成 95% 的初审工作，但最终的法律判断由律师拍板。
这类产品不会被取代，因为它的价值锚点不是“AI 的能力”，而是“人 + AI 的协作效率”。
判断公式：你的产品“该不该存在”？
┌──────────────────────────────────────────────────────────────┐
│ │
│ Q1：这件事能被“一句话 + 通用LLM”直接完成吗？ │
│ → 如果能：你的产品是MenuGen。不要做App，做Prompt模板。 │
│ │
│ Q2：这件事依赖企业私有数据吗？ │
│ → 如果是：做私有化RAG系统。 │
│ → 这是一句话提示词无法替代的领地。 │
│ │
│ Q3：这件事需要嵌入现有业务系统和物理流程吗？ │
│ → 如果是：做集成Agent + 人机协作工作流。 │
│ → 客单价最高、壁垒最深。 │
│ │
│ Q1回答“是” → 不要做这个产品 │
│ Q2回答“是” → 做这个产品，护城河在数据 │
│ Q3回答“是” → 做这个产品，护城河在集成和关系 │
│ Q2+Q3都回答“是” → 最佳选择，高壁垒高客单价 │
│ │
└──────────────────────────────────────────────────────────────┘
五、Vibe Coding 已死，Agentic Engineering 登场
理解了 Software 3.0 的框架之后，还要面对另一个问题：在这个新范式下，“做产品”和“写代码”本身会变成什么样？
2025 年 2 月，Karpathy 发明了“Vibe Coding”这个词——你不需要逐行写代码，用自然语言描述你想要什么，AI 帮你生成代码，跑起来看效果，再调整、再迭代。到 2025 年 12 月，他 80% 的代码由 AI 生成；而到 2026 年 4 月，他在 Sequoia Capital 的 AI Ascent 活动上宣布 vibe coding 已经“过时”，取而代之的是他称为“agentic engineering”的更严格学科。
他亲手杀死了自己创造的概念。
为什么？因为 vibe coding 的失败模式在专业环境中迅速暴露出来。当开发者“完全跟着感觉走”、不再阅读代码差异时，他们引入了严重的技术债务、安全漏洞和未文档化的业务逻辑。
Vibe Coding 就像 Software 3.0 的试用期。它让每个人都能做软件了，但做出来的软件经不起生产环境考验。
Vibe Coding 与 Agentic Engineering：地板与天花板
Karpathy 说，vibe coding 是为了提升每个人在软件方面能做什么的底线。每个人都可以 vibe code 任何东西，这很棒。Agentic engineering 则是为了保持专业软件之前已有的质量标准。你不能因为 vibe coding 就引入安全漏洞。
翻译一下：
- Vibe Coding 提升了地板：原来不会编程的人，现在也能做出一个能跑的 Demo。
- Agentic Engineering 提升了天花板：原来需要 10 个人干 3 个月的项目，现在一个懂得协调 Agent 的工程师，可能 2 周就搞定了。
但表面区分低估了真正差异，那是关于责任和意图的差异。Vibe coding 关乎可及性——任何人，包括从未写过一行 Python、从未想过调用栈的人，现在也能构建软件。Agentic engineering 却是一门专业学科，你协调的是容易出错的、随机的 AI Agent，而不是被动接受生成的代码。核心技能包括规格设计、差异审查、评估设计、安全监督和质量品味。
这和我第一篇文章中提出的“场景手术法”高度对应：
- Vibe Coding = 给手术室装了最先进的设备
- Agentic Engineering = 培养了真正会动手术的外科医生
设备再好，不会用就是摆设。
对 FDE 和创业者来说，这意味着什么？
Karpathy 最近指出，在顶尖层次，技术精通度“甚至比以前更是一个乘数”。一个深刻理解系统架构的开发者，可以利用一个 Agent 团队实现 10 倍甚至 100 倍生产力，而一个新手只会更快地生成坏掉的代码。
这就是 2026 年最残酷也最真实的分化：
| 维度 |
Vibe Coder |
Agentic Engineer |
| 产出 |
能做 Demo |
能做生产系统 |
| 责任 |
“看看它跑不跑” |
“我对代码质量负责” |
| 客单价 |
很难收费（太多人能做） |
高客单价（稀缺能力） |
| 壁垒 |
几乎为零 |
行业 know-how + 系统设计能力 |
| 角色 |
爱好者 |
FDE 超级个体 |
如果你只停留在 Vibe Coding 阶段，你永远只能做 Demo。Agentic Engineering，才是 FDE 的真正战场。
六、中国市场的特殊性：为什么 Software 3.0 在这里更猛
Karpathy 的框架是从硅谷视角出发的。但当我把这个框架映射到中国市场，会发现一个更猛烈的推论：在中国，Software 3.0 的冲击力可能比美国还大。
原因有三个。
原因一：AI 直接打穿了“定制开发”的成本
在中国企业服务市场，有一个沉疴：每家企业的需求都不一样，标准化 SaaS 卖不动，定制开发又太贵。
传统模式下，给一家中型制造企业做一套管理系统：需求调研 2 个月，开发 6-12 个月，人员 5-8 人团队，费用 200-500 万。
Software 3.0 + Agentic Engineering 模式下：需求调研 2 周，开发 1-2 个月，人员 1-2 个人，费用 20-50 万。
成本降了一个数量级。这意味着大量原来“做不起定制系统”的中小企业，突然有了 AI 化改造的可能性。而这些企业需要的不是“买一个 SaaS”，而是“有一个人来帮我做一个恰好适合我的系统”。这个“一个人”，就是 FDE 超级个体。
原因二：中国的企业数据“看起来有但用不了”
80% 的 AI 项目无法交付预期的商业价值，这是非 AI 类 IT 项目失败率的两倍。最重要的发现是：模型不是问题。MIT 将 95% 的失败率追溯到组织如何使用 AI 的学习差距，而非模型质量。
这个结论在中国市场更加尖锐。我走访过的许多中国中小企业，数据状况是这样的：
- 有 ERP 系统，但很多数据靠人手工录入，准确率存疑；
- 有微信聊天记录，但从未被结构化；
- 有老师傅的经验，但只存在于脑子里；
- 有客户信息，但散落在三四个不同的 Excel 表里。
这些企业“看起来”有数据，但这些数据不是“AI-ready”的。AI 通常是能工作的，问题出在上游：脏数据没有明确的负责人，试点项目的范围设定是为了取悦指导委员会而非解决真实工作流问题，以及对那些 AI 本应帮助其工作的人缺乏变革管理计划。
这就是 FDE 的巨大价值——你不只是“搭系统”，你还要帮企业把数据变成可用的知识。
原因三：中国不需要 Palantir，需要的是“FDE 游击队”
美国的 AI 落地路径是：大企业买 Palantir 这样的平台，平台派 FDE 驻场交付。
中国的企业服务生态不一样。中国有 4000 多万家中小企业，每家的需求都很个性化，不可能每家都去买一个百万级的平台。中国需要的不是一个超级平台，而是大量深入各个行业、一个人就能完成交付的 FDE 超级个体。
Software 3.0 让这件事成为可能：一个人 + 一台电脑 + Agno/Cursor/Dify + 行业 know-how，就是一个完整的 AI 交付能力。
七、实操框架：在 Software 3.0 时代，你该建什么
基于以上所有分析，我给出一个完整的判断框架，帮助你在 Software 3.0 时代做出正确的产品决策。
决策树：三个问题，决定你做什么
你有一个AI产品/项目的想法
│
▼
┌─────────────────────────────────┐
│ Q1：这件事能被一句话+通用LLM搞定吗？│
└────────┬──────────────┬─────────┘
│ │
是 否
│ │
▼ ▼
┌──────────────┐ ┌──────────────────────┐
│ 不要做App │ │ Q2：需要私有知识吗？ │
│ 做Prompt模板 │ └───┬─────────────┬────┘
│ 做教程/课程 │ │ │
└──────────────┘ 是 否
│ │
▼ ▼
┌───────────────┐ ┌──────────────────┐
│ 做RAG知识库 │ │ Q3：需要嵌入物理 │
│ + 私有化部署 │ │ 流程/现有系统吗？ │
└───────────────┘ └──┬──────────┬────┘
│ │
是 否
│ │
▼ ▼
┌──────────────┐ ┌────────────┐
│ 做集成Agent │ │ 再想想 │
│ + 人机协作流 │ │ 可能不该做 │
└──────────────┘ └────────────┘
四类场景的商业价值排序
| 排序 |
类型 |
护城河 |
客单价 |
可复制性 |
典型案例 |
| ★★★★★ |
私有知识 + 物理集成 |
最深 |
最高（10万+） |
中 |
工厂设备预警 Agent |
| ★★★★ |
私有知识型 |
深 |
高（5-20万） |
较高 |
企业合同审核 Agent |
| ★★★ |
物理集成型 |
中 |
中（3-10万） |
中 |
仓储分拣优化 Agent |
| ★★ |
通用能力型 |
浅 |
低（难收费） |
极高 |
通用客服对话机器人 |
| ★ |
信息聚合型 |
无 |
极低 |
— |
新闻摘要 App（不该做） |
八、给三种人的行动建议
如果你是创业者或产品经理
立刻做这件事：拿出你现在的产品功能列表，逐条过一遍 Q1 问题。如果超过 50% 的功能可以被“一句话 + 通用 LLM”替代，你的产品正在成为 MenuGen。
不是说你的产品明天就会死，而是说你应该立刻把精力和资源，集中到那些“通用 LLM 搞不定”的功能上。
如果你是技术人员或开发者
这个职业正在被重构。程序员越来越不只是代码编写者，而是 Agent 的协调者。
最重要的技能升级路径是：
- 从“写代码”到“写规格说明书”（告诉 Agent 做什么）
- 从“调试 Bug”到“审查 AI 输出”（判断 Agent 做得对不对）
- 从“一个人完成所有工作”到“协调多个 Agent 协作”
Vibe coding 提升了任何个人能构建的下限，而 agentic engineering 保持了专业软件的天花板。对于一个强大的 agentic engineer 来说，上限远远超过了旧有的“10 倍工程师”神话。
如果你想成为 FDE 超级个体
Software 3.0 时代的 FDE，核心价值不是“会用工具”。工具是平权的，ChatGPT、Claude、DeepSeek、Agno、Cursor，所有人都能用。
FDE 的核心价值在于：
- 诊断能力：你能看出企业真正的痛点在哪里（场景手术法）
- 架构能力：你知道哪些应该用 Agent 做，哪些应该让人做（人机协作设计）
- 集成能力：你能把 Agent 嵌入企业现有的系统和流程里，而不是做一个独立 Demo
- 信任能力：你能用可量化的数据证明 AI 落地的 ROI，而不是讲故事
这四个能力加在一起，就是一个“不该消失”的人。就像那些“不该消失”的产品一样，你的价值在于不可替代性。
尾声：上下文窗口就是你的程序
Karpathy 在 Sequoia 的演讲里有一个类比让我反复回味：Software 3.0 是你通过提示、上下文、工具、示例、记忆和指令来编程 LLM 的框架。上下文窗口是程序，LLM 是解释器。
现在，我想把这个类比延伸到个人 IP 和商业定位上。
如果上下文窗口是程序，那么你的“人生上下文”也是一段程序。你过去 10 年在某个行业积累的经验、你亲手做过的每一个成功和失败的项目、你踩过的坑、交过的学费、得罪过的客户、复盘过的教训，都是你的上下文。
这些上下文，通用 LLM 没有。ChatGPT 没有，Claude 没有，DeepSeek 也没有。只有你有。
在 Software 3.0 时代，AI 是解释器，你的行业 know-how 是程序。所以别焦虑 AI 太强，要确保你的“上下文”足够有价值。
MenuGen 消失了，因为它的上下文太浅，不过是菜名和通用图片。但一个深入制造业 28 年的老师傅的诊断经验、一个跨境电商老板 10 年沉淀的供应链关系、一个律师审了 5000 份合同积累的风险直觉——这些上下文，永远不该消失。
你的任务是：
- 用“场景手术法”找到你最深的上下文
- 用 Software 3.0 的方式——RAG、Agent、私有化系统——把它封装起来
- 让它成为一个永远不会被“一句话提示词”替代的产品
这才是 AI 时代最深的护城河。不是因为你用了多少 AI 工具，而是因为你拥有多少 AI 无法复制的上下文。
如果你也在思考这些问题，欢迎来云栈社区和更多开发者一起讨论。
发表于 昨天 17:15
|
查看: 18|
回复: 0
