最近， Andrej Karpathy 的一个个人实验在开发者圈子里被广泛讨论。很多人把关注点放在了“AI 写代码更快了”这个效率话题上，但我觉得，速度只是最表面的变化。这个实验真正戳中的，是我们对软件形态和生产方式的固有想象。
Karpathy 只是想解决一个具体问题：在8周内将自己的静息心率从50降到45。为此，他并没有去应用商店寻找现成的App，而是让AI帮他快速搭建了一个训练追踪面板。这个面板没有宏伟的蓝图，不考虑上架发布，更不是为了验证什么创业方向。它只是一个目标明确、生命周期有限的个人工具。在过去，这种个性化、阶段性的需求很可能因为“不值得做成一个产品”而被忽略或忍受；而现在，AI 让在现场即时组装一个刚好够用的工具成为可能。
所以，这件事的意义远不止“1小时干完过去10小时的活”。它揭示了一个更深层的转变：软件生产的起点正在改变。传统的模式是“先有产品，再寻找应用场景”；而未来的趋势会更像是“先有具体场景，再即时组合出软件”。这才是讨论“应用商店是否过时”时，我们更应该关注的底层逻辑。
这并非要全盘否定应用商店。对于高频、标准、稳定的需求，成熟的产品和集中的分发平台依然有其价值。但大量个性化、低频、甚至一次性的需求，其满足路径正在发生迁移——从“在商店里找一个差不多能用的App”，转向“让 AI Agent 就地搭建一个正好贴合需求的工具”。应用商店不会消失，但它正在失去作为所有数字需求“默认入口”的垄断地位。
Karpathy 在原文中还指出了一个更现实的瓶颈：为了获取设备数据，Agent 不得不去反向工程接口；为了完成某个操作，它需要阅读面向人类的网页说明，并模拟人类的点击流程。这里的障碍并非来自模型能力本身，而是外部系统与服务的设计哲学仍然停留在“给人看、给人操作”的时代，尚未真正进入“给 Agent 调用”的时代。
看清了这层障碍，许多关于“为什么AI体验还不能一键达成”的困惑就迎刃而解了。你会发现，如今绝大多数服务仍将核心能力深藏在图形界面之后：API文档是供人阅读的HTML页面，业务流程是一连串等待人工点击的按钮，权限管理依赖于临时的弹窗确认。即便模型再强大，遇到这些“人机交互层”的关卡时，也不得不被迫降速，扮演一个笨拙的“模拟用户”。
因此，我更倾向于将当前趋势理解为一场 “接口文明”的迁移。未来的竞争不仅在于谁的模型更聪明，更在于谁能够更早地将服务改造为 Agent-First 的形态：能力可被自动发现、权限可安全托管、调用过程可审计、失败操作可回滚。只有当这套面向智能体的基础设施逐渐完善，“请帮我把未来8周的训练做成一个可追踪系统”这样的需求，才能真正接近“一句话交付”的理想状态。
这并非空想，市场上已经有一批产品在朝这个方向积极探索。例如，Replit Agent 致力于缩短从“自然语言描述”到“可运行应用”的路径；Retool 和 Airtable 正在企业内工具领域大幅降低软件化的门槛；Glide 让业务人员也能快速组装轻量级应用；像 Glaze 这类新兴产品则特别强调高度定制与快速落地。它们或许尚不完美，但共同指向一个清晰的未来：软件正从“固定成品”向“按任务即时编排”演变。
所以，应用商店不会一夜之间消亡，但它作为中心的地位确实在松动。它将继续服务于那些标准化、大众化的需求，却不再是解决所有数字问题时条件反射般的第一选择。一个更可能普及的场景是：你先用自然语言描述问题，系统为你临时生成或组合出专属软件；待任务结束，该软件也可随之“功成身退”，无需常驻。
从这个视角回看，Karpathy 实验最宝贵的启示，并非简单的效率对比，而是一句关于软件本质的提醒：
软件，不再只是“被下载的东西”，它正在变成“被编排的过程”。
对于关注这一趋势的 开发者 而言，理解从“产品”到“过程”的范式转移至关重要。这也正是像 云栈社区 这样的技术论坛所关注的前沿动向，在这里，我们可以持续探讨 AI Agent 等技术与产业变革的深度融合。
延伸阅读与参考
| 
发表于 昨天 03:42
|
查看: 9|
回复: 0
