以下的文章是Andrej Karpathy近日发表的两篇X/Twitter，阐述了其对于未来APP的想法。这和我整个春节对于AI Coding以及OpenClaw尝试后的感悟一致。过去的APP的功能是离散的，基于大众的最大公约需求开发的；未来的APP的功能是连续的，基于个人的长尾需求快速生成。以下是

一个关于AI定制的真实案例

最近，我对有氧运动有些懈怠，于是决定进行一项更系统、更认真的尝试：在8周内，将我的静息心率从50bpm降至45bpm。我的主要策略是，通过Zone 2有氧运动和每周一次HIIT来达到设定的总时长目标。

仅仅1小时后，我就用代码为这项特定实验，搭建了一个高度定制化的仪表盘，用于实时追踪我的进展。令人惊叹的是，Claude Code甚至不得不逆向破解Woodway跑步机的云API，才能获取原始数据，再进行处理、过滤、调试，并最终生成一个Web UI前端。

当然，整个过程并非一帆风顺。我发现并要求修复了一些bug，比如单位制（公制/英制）混淆、日期匹配错误等。

但即便如此，我依然坚信大方向是明确的：

1. 告别“应用商店”：
   
    这种高度个性化的需求，永远不会（也不应该）在应用商店里找到对应的App。当一个LLM代理能在几秒钟内为你生成一个包含数百行代码的定制程序时，你还需要去下载一个专门的“有氧运动追踪器”吗？由用户自行选择、下载独立App的“应用商店”模式，在LLM代理可以按需为你量身定制应用时，显得有些过时和不合时宜。
2. 重塑“人机交互”：
   
    其次，整个行业的产品和服务必须重塑，提供原生支持AI agent的交互方式。我的Woodway跑步机本质上是一个传感器，它将物理状态转化为数字信息。它不应该只提供一个面向人类的复杂前端，也不应该让我的LLM代理去逆向破解它，它应该直接提供易于代理调用的API/CLI接口。

令我有些失望的是，这种进步在整个行业中发生的速度如此缓慢（这无疑也拖慢了我的实验进程）。99%的产品和服务都还没有AI原生的CLI接口。99%的产品和服务还在使用传统的网页前端，仿佛我不会直接把整个网页内容复制粘贴给AI代理，让它去完成任务一样。

到了2026年，它们还在给你一堆网页指令，让你打开某个URL，点击这里或那里去完成一件事。
难道我是个机器人吗？与其让我亲力亲为，不如让我的AI代理代劳！

从1小时到1分钟的未来

所以，今天我能用1小时完成这个项目（两年前可能需要10小时），确实令人印象深刻。但更令我兴奋的是，它本该只需1分钟！

要怎样才能让它变成1分钟呢？【那当然是更便宜的算力了 — 译者注】

那样我就可以简单地说一句：“你好，你能帮我追踪未来8周的有氧运动吗？”经过几轮简短的问答，一个定制化的应用程序就能立即投入使用。

届时，AI将早已拥有大量的个人背景信息，它会收集所需的额外数据，调取相关的技能库，并智能管理我所有的个性化应用和自动化流程。

在很多人眼中，命令行界面（CLI）或许是“老派”甚至有些“笨拙”的技术。然而，它恰恰是AI代理掌控未来、高效协同的关键所在！

CLI：AI代理的“母语”

你可能会感到惊讶，但CLI之所以如此令人兴奋，正是因为它是一种“传统”技术。这意味着AI代理可以原生且无障碍地使用它们、自由组合它们，并通过整个终端工具包与之深度交互。

案例：AI agent的效率飞跃

• 即时仪表盘：
  
   想象一下，让你的Claude Code/Codex代理安装一个Polymarket的CLI工具，然后要求它为你即时生成一个特定数据（比如crypto实盘价格）仪表盘、自定义界面或复杂逻辑。agent会瞬间帮你完成。
• 代码仓库管理：
  
   又或者，安装GitHub CLI，让代理直接在终端穿梭于代码仓库之间，查看问题、管理拉取请求、参与讨论，甚至直接审查代码本身。

我自己就亲身体验了一把：Claude Code仅用了大约3分钟，就迅速构建了一个终端仪表盘，清晰展示了Polymarket上交易量最高的市场及其24小时变化。

更妙的是，这个成果你可以轻松转化为网页应用，或者作为更大自动化流程中的一个核心模块，发挥更大威力。

你的产品，准备好迎接AI代理了吗？

如果你正在开发任何产品或服务，是时候严肃思考了：你的产品能否被AI agent无缝访问和使用？

• ✓ 你的（为人类设计的）传统文档，至少能导出为Markdown格式，让AI轻松读取吗？
• ✓ 你是否已经为你的产品编写了AI友好的“技能”或API接口？
• ✓ 你的产品/服务是否提供了CLI或其他可编程接口，供代理直接调用？
• ✓ 你是否主动考虑了AI代理如何与你的产品进行深度整合与自动化？