如果软件可以由 AI 现场生成，那应用商店会不会消失？
知名 AI 工程师、神经网络布道者 Andrej Karpathy，前两天又发了篇长帖，引起热议。最主要的意思是：
以后可能不用专门去应用商店“找”App 了，你只要说清楚想干嘛，AI 现场给你做一个——而且可能只要 1 分钟就做好了。
图注：节选自 Andrej Karpathy 新帖子
他拿自己做的实验，举了个例子：
打算用 8 周时间，把静息心率从 50 降到 45（静息心率，是人在完全放松状态下每分钟的心跳次数，常被用来衡量心肺功能）。
一般人遇到这种需求，大概率是去应用商店搜“Cardio Tracker”之类的 App。但 Karpathy 另辟蹊径——没请开发者，也没下载现成的 App；而是直接用一个 AI Agent，临时做了一个专门追踪这次训练计划的仪表盘。
这个 Agent 反向解析跑步机云端接口，拉原始数据、清洗、调试，再生成一个网页前端，1 小时搞定。而两年前，这大概要 10 小时。
但 Karpathy 并不满足于“只用 1 小时”，他在想：为什么还要 1 小时？
他分析认为，时间并没怎么花在“理解需求”上，而是主要花在了补基础设施：接口不友好、缺乏 AI 原生 API、单位制和日历逻辑要人工修 bug 等等。
他吐槽道：
“99% 的产品和服务仍然没有 AI 原生的 CLI。99% 的产品和服务仍然维护着 .html/.css 的文档，好像我不会第一时间把内容复制粘贴给我的 Agent 去完成任务似的。”
换句话说，现在的最大阻力不在模型能力，而在生态还没准备好。
于是，他大胆预判：如果设备本身，提供 Agent 可直接调用的 API、如果常见功能有成熟技能库、如果 AI 已经掌握个人长期数据；那么这件事，理论上只剩下“描述需求 + 自动拼装”，未来可能只需 1 分钟。
其实，这早已埋下了伏笔。Karpathy 于 2023 年写的“名言”：“目前最热门的新编程语言是英语”，现在还挂在他主页置顶。
当自然语言本身就是编程接口，软件就不一定非要先被做成一排排固定产品，等人去下载。它可以在对话里被拼出来，在具体场景中存在，用完就消失。
在 Karpathy 看来，如果“说一句需求”，比“进应用商店挑一个”更快，那默认入口迟早会变。
当语言成为编程接口，Karpathy 眼中的软件未来
除了预判未来 AI 可以迅速定制软件，这篇帖子的核心观点，还可以拆成以下几条：
软件正在从“标准化产品”，变成“按需生成的临时工具”，更短暂、更个性化。
这要求硬件和软件提供 AI 原生 API，让机器和机器直接对话，而不是依赖人为操作界面。
企业可能不再大量购买 SaaS，而是动态生成工具。而且传统 UI，也可能被 Agent 编排替代。
应用商店不会消失，但它的角色会弱化，未来更可能是“经过验证的基础层 + AI 个性化扩展”的混合模式。
真正的竞争力，不再是谁“懂 AI”，而是谁能最快把 AI 部署成实际可用的系统。
以下为帖子原文，InfoQ（AI 前线）在不改变原意的情况下，对其进行了整理编辑。
我对高度定制化软件即将到来的时代会是什么样子，非常感兴趣。
举个今天早上的例子，我最近在有氧训练上有点松散，于是决定做一个更认真、更有纪律的实验：
在 8 周内，把静息心率从 50 降到 45。主要方式是完成一定总时长的 Zone 2 有氧训练，并且每周做 1 次 HIIT。
1 小时后，我用 Vibe Coding 做了一个为这次实验量身定制的超专属仪表盘，用来追踪进度。Claude 不得不反向解析 Woodway 跑步机的云端 API，拉取原始数据，进行处理、过滤、调试，并创建一个 Web 前端界面来跟踪这个实验。
过程并不完全顺畅，我需要发现并指出一些 bug，让它修复，比如它搞错了公制和英制单位，也把日历里的日期和星期匹配错了。
不过，我依然觉得整体方向是清晰的：
永远不会（也不应该）有一个专门为这种事情存在的应用商店 App。
我不应该为了这个去找、下载、使用某个“有氧实验追踪器”。这不过是大约 300 行代码，一个 LLM Agent 几秒钟就能生成。那种在应用商店里从一长串离散应用中挑选一个的模式，在 LLM Agent 可以现场即兴生成只属于你的应用时，显得有些不对劲，也有点过时。
其次，这个行业，需要重构一套服务体系：由传感器和执行器组成，并具备对 Agent 原生友好的使用方式。
我的 Woodway 跑步机，本质上就是一个传感器：它把物理状态转化为数字信息。它不应该维护一个面向人类的前端界面，而我的 LLM Agent 也不应该去反向工程它；它应该提供一个可以被 Agent 轻松使用的 API 或 CLI。整个行业在这方面推进得非常缓慢，这让我有点失望（也直接拖慢了我的进度）。
99% 的产品和服务仍然没有 AI 原生的 CLI。99% 的产品和服务仍然维护着 .html/.css 的文档，好像我不会第一时间把内容复制粘贴给我的 Agent 去完成任务似的。他们在网页上给出一串操作说明，让你打开某个 URL、点击这里或那里去做某件事。
现在都 2026 年了，为什么还要我手动操作？要么系统自动完成，要么交给我的 Agent。
所以，总的来说，我今天确实对这件事只花了 1 小时感到满意（两年前大概要 10 小时）。
但更让我兴奋的，是去思考：它本来应该只需要 1 分钟。
要实现 1 分钟，需要什么条件？让我只需说一句：“嗨，能帮我在接下来 8 周追踪有氧训练吗？”在简短的问答之后，应用就自动搭建完成。AI 已经掌握大量我的个人背景信息，会主动收集额外所需数据，调用和检索相关技能库，并维护我所有这些小应用和自动化流程。
简而言之，从一组离散应用中挑选的“应用商店”概念本身正在迅速过时。未来将是由 AI 原生的传感器和执行器组成的服务体系，通过 LLM 这层“胶水”进行编排，生成高度定制、短暂存在的应用。只是，这个未来还没有真正到来。
应用商店不会消失，但软件即时刻？
Karpathy 和这篇文章，让网友们吵翻了。
有人觉得，他说出了自己这两年的直觉。一个叫“AIM Network”（下面简称 AIM）的媒体形容道：
“我们过去收集软件的方式，就像收集书一样：精挑细选、下载安装、定期更新，然后慢慢被遗忘。这种习惯可能已经不太适合未来。
......未来的流程可能不再是‘下载—安装—配置—适配’，而是‘描述—生成—使用—丢弃’。软件将变得短暂、个性化、一次性。”
AIM 还提出：未来，“软件即当下时刻”，而不是“软件即产品”——软件不再是一个被打包、上架、定价的产品，而更像一段即时生成的服务。
不过，他们也没把话说满：应用商店不会突然消失，而是进化成全新的“应用商店 2.0”、“应用商店 3.0”版本。原因很现实：它承担的是信任、审核和安全机制。
未来更可能出现的画面是：不再卖一堆细碎的 App，而是提供可靠的底座，让 Agent 在上面自由拼装。底层还是一套经过验证的基础能力，上面叠加由 AI 即时生成的个性化扩展。
换句话说，要消失的，未必是软件本身，而是“软件必须以固定产品形态存在”这件事。
未来更可能是混合模式：经过验证的基础软件层之上，叠加可定制的 AI 生成扩展，并配合受控的 Agent 权限机制，即“经过筛选的基础能力+个性化智能”。
换句话说，未来消失的可能不是“软件”，而是“软件作为固定产品”的概念。
此前，Karpathy 仅用 243 行 Python 代码，就写出了一个能跑的 GPT。由此可见，大模型不再是高不可攀的黑箱技术，而是越来越标准化、可复用的能力模块。
当模型本身越来越“平民化”，真正的竞争优势，就会转向别处：比如基础设施是否顺滑、算力是否充足、Agent 工作流是否成熟等等。竞争不只在模型，更在部署速度。
还有一点，如果说 Karpathy 给的是一个方向：“语言正在变成接口，工具可以即兴生成”；那 AIM 补上的，是一串连锁反应：一旦生成速度足够快，分发逻辑、SaaS 结构，甚至企业 IT 预算怎么花，都会跟着松动。
也有很多网友质疑。
有人觉得 Karpathy 作为一个 AI 从业者，在自卖自夸，就像：“你是个厨师，但并非每个人都想成为或愿意成为厨师。”
Karpathy 表示，人们还在用“软件稀缺”的旧思维看问题，而当软件变得极度廉价、可随时生成时，传统意义上的“应用”本身可能都会失去存在意义。
还有人觉得，首先要想清楚自己要什么，本身就很耗费精力，锐评道：“你奶奶会自己做 App 吗？”
Karpathy 回复道：“奶奶根本没必要懂什么 App，甚至不用知道有 App 这回事；（这些）该由她的 LLM 代理知道。”
然后，站 Karpathy 的人，说未来 AI 就是好的设计师。
反对者则表示：“构建软件最困难的部分是弄清楚客户真正想要什么。但你声称一个 LLM 能从一位连问题领域词汇都不具备的人的随意语音提示中破解它？”
对于未来的 APP 形态，你怎么看？
参考链接：
