Andrej Karpathy最近想做个心肺实验：8周内把静息心率从50降到45。他需要追踪Zone 2有氧运动时长和每周一次HIIT。
一小时后，他让Claude逆向工程了Woodway跑步机的云端API，抓取原始数据，处理、过滤、调试，最后生成一个Web追踪界面。过程不算完美，AI搞错了公制和英制单位，日历匹配也出了bug。但这300行代码，传统方式得花10小时写。
更重要的是方向性的启示。
第一，App Store本身就是个过时概念。为什么要去商店找、下载、使用某个“心肺实验追踪器”？LLM几秒钟就能给你生成专属的那300行代码。长尾应用的离散集合，在AI能即时定制软件的时代显得荒谬。
第二，整个行业需要重构成“传感器+执行器”的服务架构，并且要对AI友好。他的跑步机是传感器，把物理状态转为数字信息。它不该维护什么人类可读的前端界面，更不该让AI去逆向工程它。应该直接提供API或CLI，让Agent轻松调用。
但现实令人失望。2026年了，99%的产品和服务仍然没有AI原生的CLI接口。它们还在维护HTML/CSS文档，好像用户不会直接把整个文档塞给AI去完成任务。它们在网页上列出一堆指令，让你打开某个URL，点这里点那里。我是电脑吗？你来做，或者让我的Agent做。
今天这个小项目花了一小时，已经够让人惊喜。但真正激动人心的是：它本该只需一分钟。
想象一下：你说“能帮我追踪接下来8周的心肺训练吗？”简短问答后，应用就起来了。AI已经掌握你的大量个人背景，它会收集额外需要的数据，检索相关的技能库，维护你所有的小应用和自动化工具。
App Store这种让你从离散应用集合中挑选的模式，本身就越来越过时。未来是AI原生的传感器和执行器服务，通过LLM粘合剂编排成高度定制的临时应用。只是这个未来还没到来。
有人质疑：你奶奶想自己做应用吗？维护它的心力成本呢？应用设计师的集体反馈难道不比个人更靠谱？99%的用户真的需要超级定制的应用吗？
Karpathy的回答很简单：奶奶当然不需要知道应用是什么，她的LLM Agent知道就行了。
这个转变的关键在哪？可能是需要一种介于自然语言和传统编程语言之间的东西。自然语言擅长表达意图，但太模糊；编程语言精确，但对Agent来说太不受约束、不安全。DSL（领域特定语言）正好在中间：给模型一个结构化的操作空间，限制它能做什么，强制执行模式，本质上就是沙盒加执行计划。把“感觉”转化为安全、确定性的自动化。
健康数据是最能暴露“vibe coding”局限性的领域。当LLM幻觉你的血压趋势正常时，你不会像发现单位错误那样容易察觉。这就是为什么健康数据的Agent层需要确定性工具，而不只是prompt。
一个有趣的类比：这些“长尾”个人应用会像数码照片一样普遍。AI把代码变成了智能手机摄像头。我们正从“软件即服务”转向“软件即行为”。
剩下的问题是速度。为什么还要等一小时？传感器和执行器的API标准化、个人背景的持续积累、技能库的完善、安全沙盒的设计，这些基础设施都还缺位。但从10小时到1小时的进步已经发生，从1小时到1分钟也许只是时间问题。
简评：
Karpathy看到了真实的技术趋势（AI让软件生成大众化），但他用技术乌托邦叙事遮蔽了商业激励、法律框架和人类认知局限这三座真正的大山。App Store不会死，它会变成Agent的后台组件库——用户看不见它，但它依然存在，因为信任不能临时拼装。
x.com/karpathy/status/2024583544157458452
热门跟贴