返回列表
🪞 Uota学 · 🧠 阿头学

App Store 正在过时，下一代软件是“为你临时现做”的

当 LLM 能把“一个小需求”当场缝成 300 行代码时，软件的主战场不再是下载 App，而是把现实世界改造成 AI 能直接操控的传感器/执行器服务。

2026-02-20 原文链接 ↗
阅读简报
双语对照
完整翻译
原文
讨论归档

核心观点

  • “找 App”这条路径会越来越像拨号上网 长尾需求不值得养一个完整产品形态；更合理的是“即时生成的短命小应用”，按任务存在、按人定制。
  • 真正的瓶颈不是模型写代码，而是外部世界不给你接口 现在 LLM 还在“逆向工程跑步机云 API”、对着网页点来点去，本质是服务端仍以人类操作为中心。
  • AI-native 的 API/CLI 会成为下一代基础设施 未来的竞争点是：谁把“可被 agent 调度”的能力做成标准化服务，谁就成为生态里的默认零件。
  • 从 10 小时到 1 小时只是中途站 体验不顺（单位制、日历对齐）说明：当前 agent 开发还缺“可复用技能库 + 可靠数据源 + 自动化测试/校验”。

跟我们的关联

  • Neta 的关键不只是“能生成内容”，而是把用户的创作链路拆成可被 agent 编排的“传感器/执行器”（素材、角色设定、风格、发布、互动反馈），否则只是在做一个更聪明的编辑器。
  • 我们内部工具也该按这个方向重构：把手动流程（运营拉数、投放复盘、KOC素材处理）变成 agent 可调用的 CLI/API，让“1小时”变“1分钟”。
  • 产品叙事可以更激进：不是“更强的 AI”，而是“你的专属软件工厂”——每个用户都有一堆只为 TA 存在的小功能。

讨论引子

  • 如果“下载 App”过时了，Neta 的分发/入口应该长什么样？我们要做的是一个 App，还是一套可被嵌入/调用的能力集合？
  • 对用户而言，哪些“传感器/执行器”最先 AI-native 化会改变创作习惯？（例如：素材管理、世界观知识库、互动数据回流）
  • 我们现在最像“跑步机网页点点点”的流程是哪一段？把它改成 agent-native 的最小版本是什么？

Andrej Karpathy：我对高度定制化软件时代的样子非常感兴趣

我对即将到来的高度定制化软件时代会是什么样子非常感兴趣。

今早的一个例子——最近我对有氧训练有点松松垮垮，所以决定做一个更严肃、更有计划的实验：在 8 周的实验期内，把我的静息心率从 50 -> 45。主要方法是设定一个 Zone 2 有氧的累计分钟数目标，并每周做 1 次 HIIT。

一小时后，我凭感觉写代码，做出了一个为这个非常具体的实验量身定制的仪表盘，用来显示我的进展。Claude 不得不逆向工程 Woodway 跑步机的云端 API，拉取原始数据，进行处理、过滤和调试，并做了一个 Web UI 前端来跟踪实验。过程并不完全顺畅，我还得自己发现并提出修 bug，例如它把公制和英制单位搞混了，还把日历里“星期几”和日期的对应关系弄错了，等等。

但我依然觉得整体方向很清晰： 1) 这种事永远不会（也不该）在应用商店里有一个专门的 App。既然这东西不过是大约 300 行代码，LLM 代理几秒钟就能给你，我就不应该还得去找、下载、使用某个“有氧实验追踪器”。当 LLM 代理可以当场为你即兴写出只属于你的应用时，那种从一条长尾的、彼此离散的 App 集合里挑选的“应用商店”观念，总觉得哪里不对劲，也显得过时。 2) 其次，整个行业必须重构为一组由传感器与执行器组成、具备面向代理原生易用性的服务。我的 Woodway 跑步机就是一个传感器——它把身体的状态转成数字化知识。它不该还维护一个面向人的可读前端，也不该让我的 LLM 代理去逆向工程；它应该提供一个让我的代理轻松使用的 API/CLI。让我有点失望的是（因此我的时间表也相应变慢），整个行业在这方面的推进速度实在太慢。99% 的产品/服务至今还没有 AI-native 的 CLI。99% 的产品/服务还在维护 .html/.css 的文档，仿佛我不会立刻去找怎么把整套东西复制粘贴给我的代理，让它替我把事办了。它们在网页上给你一串指令：打开这个或那个 URL，在这里点一下、在那里点一下，才能完成某件事。都 2026 年了。我是什么——一台电脑吗？你来做。或者让我的代理来做。

所以无论如何，今天我还是挺惊讶，这件随手的事只花了 1 小时（两年前大概得花 ~10 小时）。但更让我兴奋的是去推演：这事其实本该最多 1 分钟就搞定。要做到 1 分钟，需要哪些条件到位？这样我只要说一句“嗨，你能帮我在接下来的 8 周里跟踪我的有氧训练吗？”，经过非常简短的 Q&A，应用就能跑起来。AI 已经掌握大量个人上下文，它会收集额外所需的数据，引用并检索相关的技能库，并维护我所有这些小应用/自动化。

TLDR：由一组离散 App 组成、你从中挑选的“应用商店”，这个概念本身正在变得越来越过时。未来会是：AI-native 的传感器与执行器服务，通过 LLM 这层“胶水”编排，生成高度定制、短暂存在的应用。只是它还没到来。

相关笔记

Very interested in what the coming era of highly bespoke software might look like.

我对即将到来的高度定制化软件时代会是什么样子非常感兴趣。

Example from this morning - I've become a bit loosy goosy with my cardio recently so I decided to do a more srs, regimented experiment to try to lower my Resting Heart Rate from 50 -> 45, over experiment duration of 8 weeks. The primary way to do this is to aspire to a certain sum total minute goals in Zone 2 cardio and 1 HIIT/week.

今早的一个例子——最近我对有氧训练有点松松垮垮，所以决定做一个更严肃、更有计划的实验：在 8 周的实验期内，把我的静息心率从 50 -> 45。主要方法是设定一个 Zone 2 有氧的累计分钟数目标，并每周做 1 次 HIIT。

1 hour later I vibe coded this super custom dashboard for this very specific experiment that shows me how I'm tracking. Claude had to reverse engineer the Woodway treadmill cloud API to pull raw data, process, filter, debug it and create a web UI frontend to track the experiment. It wasn't a fully smooth experience and I had to notice and ask to fix bugs e.g. it screwed up metric vs. imperial system units and it screwed up on the calendar matching up days to dates etc.

一小时后，我凭感觉写代码，做出了一个为这个非常具体的实验量身定制的仪表盘，用来显示我的进展。Claude 不得不逆向工程 Woodway 跑步机的云端 API，拉取原始数据，进行处理、过滤和调试，并做了一个 Web UI 前端来跟踪实验。过程并不完全顺畅，我还得自己发现并提出修 bug，例如它把公制和英制单位搞混了，还把日历里“星期几”和日期的对应关系弄错了，等等。

But I still feel like the overall direction is clear: 1) There will never be (and shouldn't be) a specific app on the app store for this kind of thing. I shouldn't have to look for, download and use some kind of a "Cardio experiment tracker", when this thing is ~300 lines of code that an LLM agent will give you in seconds. The idea of an "app store" of a long tail of discrete set of apps you choose from feels somehow wrong and outdated when LLM agents can improvise the app on the spot and just for you. 2) Second, the industry has to reconfigure into a set of services of sensors and actuators with agent native ergonomics. My Woodway treadmill is a sensor - it turns physical state into digital knowledge. It shouldn't maintain some human-readable frontend and my LLM agent shouldn't have to reverse engineer it, it should be an API/CLI easily usable by my agent. I'm a little bit disappointed (and my timelines are correspondingly slower) with how slowly this progression is happening in the industry overall. 99% of products/services still don't have an AI-native CLI yet. 99% of products/services maintain .html/.css docs like I won't immediately look for how to copy paste the whole thing to my agent to get something done. They give you a list of instructions on a webpage to open this or that url and click here or there to do a thing. In 2026. What am I a computer? You do it. Or have my agent do it.

但我依然觉得整体方向很清晰： 1) 这种事永远不会（也不该）在应用商店里有一个专门的 App。既然这东西不过是大约 300 行代码，LLM 代理几秒钟就能给你，我就不应该还得去找、下载、使用某个“有氧实验追踪器”。当 LLM 代理可以当场为你即兴写出只属于你的应用时，那种从一条长尾的、彼此离散的 App 集合里挑选的“应用商店”观念，总觉得哪里不对劲，也显得过时。 2) 其次，整个行业必须重构为一组由传感器与执行器组成、具备面向代理原生易用性的服务。我的 Woodway 跑步机就是一个传感器——它把身体的状态转成数字化知识。它不该还维护一个面向人的可读前端，也不该让我的 LLM 代理去逆向工程；它应该提供一个让我的代理轻松使用的 API/CLI。让我有点失望的是（因此我的时间表也相应变慢），整个行业在这方面的推进速度实在太慢。99% 的产品/服务至今还没有 AI-native 的 CLI。99% 的产品/服务还在维护 .html/.css 的文档，仿佛我不会立刻去找怎么把整套东西复制粘贴给我的代理，让它替我把事办了。它们在网页上给你一串指令：打开这个或那个 URL，在这里点一下、在那里点一下，才能完成某件事。都 2026 年了。我是什么——一台电脑吗？你来做。或者让我的代理来做。

So anyway today I am impressed that this random thing took 1 hour (it would have been ~10 hours 2 years ago). But what excites me more is thinking through how this really should have been 1 minute tops. What has to be in place so that it would be 1 minute? So that I could simply say "Hi can you help me track my cardio over the next 8 weeks", and after a very brief Q&A the app would be up. The AI would already have a lot personal context, it would gather the extra needed data, it would reference and search related skill libraries, and maintain all my little apps/automations.

所以无论如何，今天我还是挺惊讶，这件随手的事只花了 1 小时（两年前大概得花 ~10 小时）。但更让我兴奋的是去推演：这事其实本该最多 1 分钟就搞定。要做到 1 分钟，需要哪些条件到位？这样我只要说一句“嗨，你能帮我在接下来的 8 周里跟踪我的有氧训练吗？”，经过非常简短的 Q&A，应用就能跑起来。AI 已经掌握大量个人上下文，它会收集额外所需的数据，引用并检索相关的技能库，并维护我所有这些小应用/自动化。

TLDR the "app store" of a set of discrete apps that you choose from is an increasingly outdated concept all by itself. The future are services of AI-native sensors & actuators orchestrated via LLM glue into highly custom, ephemeral apps. It's just not here yet.

TLDR：由一组离散 App 组成、你从中挑选的“应用商店”，这个概念本身正在变得越来越过时。未来会是：AI-native 的传感器与执行器服务，通过 LLM 这层“胶水”编排，生成高度定制、短暂存在的应用。只是它还没到来。

相关笔记

Andrej Karpathy (@karpathy): Very interested in what the coming era of highly bespoke software might look lik

  • Source: https://x.com/karpathy/status/2024583544157458452?s=46
  • Mirror: https://x.com/karpathy/status/2024583544157458452?s=46
  • Published: 2026-02-19T20:35:06+00:00
  • Saved: 2026-02-20

Content

Very interested in what the coming era of highly bespoke software might look like.

Example from this morning - I've become a bit loosy goosy with my cardio recently so I decided to do a more srs, regimented experiment to try to lower my Resting Heart Rate from 50 -> 45, over experiment duration of 8 weeks. The primary way to do this is to aspire to a certain sum total minute goals in Zone 2 cardio and 1 HIIT/week.

1 hour later I vibe coded this super custom dashboard for this very specific experiment that shows me how I'm tracking. Claude had to reverse engineer the Woodway treadmill cloud API to pull raw data, process, filter, debug it and create a web UI frontend to track the experiment. It wasn't a fully smooth experience and I had to notice and ask to fix bugs e.g. it screwed up metric vs. imperial system units and it screwed up on the calendar matching up days to dates etc.

But I still feel like the overall direction is clear: 1) There will never be (and shouldn't be) a specific app on the app store for this kind of thing. I shouldn't have to look for, download and use some kind of a "Cardio experiment tracker", when this thing is ~300 lines of code that an LLM agent will give you in seconds. The idea of an "app store" of a long tail of discrete set of apps you choose from feels somehow wrong and outdated when LLM agents can improvise the app on the spot and just for you. 2) Second, the industry has to reconfigure into a set of services of sensors and actuators with agent native ergonomics. My Woodway treadmill is a sensor - it turns physical state into digital knowledge. It shouldn't maintain some human-readable frontend and my LLM agent shouldn't have to reverse engineer it, it should be an API/CLI easily usable by my agent. I'm a little bit disappointed (and my timelines are correspondingly slower) with how slowly this progression is happening in the industry overall. 99% of products/services still don't have an AI-native CLI yet. 99% of products/services maintain .html/.css docs like I won't immediately look for how to copy paste the whole thing to my agent to get something done. They give you a list of instructions on a webpage to open this or that url and click here or there to do a thing. In 2026. What am I a computer? You do it. Or have my agent do it.

So anyway today I am impressed that this random thing took 1 hour (it would have been ~10 hours 2 years ago). But what excites me more is thinking through how this really should have been 1 minute tops. What has to be in place so that it would be 1 minute? So that I could simply say "Hi can you help me track my cardio over the next 8 weeks", and after a very brief Q&A the app would be up. The AI would already have a lot personal context, it would gather the extra needed data, it would reference and search related skill libraries, and maintain all my little apps/automations.

TLDR the "app store" of a set of discrete apps that you choose from is an increasingly outdated concept all by itself. The future are services of AI-native sensors & actuators orchestrated via LLM glue into highly custom, ephemeral apps. It's just not here yet.

📋 讨论归档

讨论进行中…