前两天看到 Karpathy 发了一条推，说 App Store 模式过时了。
一开始觉得他在乱说
App Store 不是活得好好的吗？
看完他的案例，我懂了 😊
Karpathy 的案例
他想追踪自己的有氧训练
目标是用 8 周把静息心率从 50 降到 45。
按传统思路：去 App Store 找一个"有氧实验追踪器"。
但找不到。因为这种需求太个性化了，没人专门做这个 App。
他怎么做的？
用 Claude 1 小时"氛围编程"了一个定制仪表板:
- 逆向工程跑步机的云 API
- 提取数据、处理、过滤
- 创建 Web UI 追踪实验
就 300 行代码。
第一个洞察:不会有专门的 App
Karpathy 说："App Store 的长尾离散应用概念感觉不对且过时。"
为什么？
因为这种定制化的小需求:
- LLM 几秒钟就能生成代码
- 不需要去 App Store 找、下载、学习
- 用完即弃，不用长期维护
App Store 的问题：
- 找不到完全匹配的 App
- 功能冗余或缺失
- 需要学习怎么用
- 要付费、要看广告
LLM 的优势：
- 完全定制化
- 无需学习
- 实时更新
- 免费、无广告
第二个洞察:传感器+执行器
Karpathy 说："99% 的产品还没有 AI-native CLI。"
什么意思？
现在的产品:
- 给你一个网页
- "打开这个 URL，点击这里，然后那里"
- 在 2026 年！
Karpathy 的反问:
"我是计算机吗?你来做。或者让我的 Agent 做。"
他提出的新架构:
传感器（输入） → LLM（编排胶水） → 执行器（输出）
传感器：把物理状态变成数字
- API、数据库、文件
- Twitter、YouTube、天气API
LLM:理解意图，- 编排传感器和执行器
- 不用自己写所有功能
执行器：输出结果
- 界面、通知、存储
- 代码、脚本、决策
核心思想:
产品要提供 AI-native 的接口
让 Agent 能直接调用
而不是让人类点击。
Tips
-
LLM 是胶水 – 不用自己写所有功能，让 LLM 编排现有的传感器和执行器
-
接口要 AI-native – 设计产品时先考虑 Agent 怎么用
再考虑人怎么用 -
从 1 小时到 1 分钟 – 现在是 1 小时生成工具
未来是 1 分钟即用
Karpathy 说现在还需要 1 小时（2 年前要 10 小时）
但理想状态是:
- 说一句"帮我追踪有氧运动"
- 简短 Q&A
- 应用就绪
最大的启发
看完 Karpathy 的观点
我最大的启发是：
AI-native 不只是技术升级
是产品设计的范式转变。
不是把现有产品加个 AI 功能
而是:
- 重新思考用户怎么表达需求
- 重新设计产品怎么被调用
- 重新定义"使用"这个动作
就像 Karpathy 说的：
"我是计算机吗?你来做。"
未来不是人类去适应产品
是产品来适应人类。
对我的启发
看完这个
我在想:
我们的产品是不是也该 AI-native 化?
比如:
- API 要不要提供 CLI 版本?
- 文档要不要机器可读?
- 操作要不要支持自然语言?
不是加个 AI 功能就够了
而是从设计上就考虑 Agent 怎么用。
灵感来源：
Karpathy《App Store 模式过时论》
https://x.com/karpathy/status/2024583544157458452
