App Store模式過時，未來屬于即興創(chuàng)作！Karpathy激進言論被懟慘

編輯｜杜偉

多年前，蘋果用「There’s an app for that」開啟了移動互聯(lián)網(wǎng)的黃金時代。從那之后，一個個應(yīng)用圖標(biāo)統(tǒng)治了我們的數(shù)字生活。

而如今，隨著 LLM、Agent 的快速發(fā)展，這一切正在發(fā)生變化。

就在昨天，AI 大神 Karpathy「現(xiàn)身說法」，并拋出了一個激進的觀點：未來的應(yīng)用不應(yīng)該是被「下載」的，而應(yīng)該是被「即興創(chuàng)作」的

他以自己正在進行的有氧運動為例，沒有選擇去應(yīng)用商店搜索任何一款「心率管理工具」，而是直接命令 AI 逆向工程了跑步機的云端 API，為自己量身定制了一個為期八周的、極其私密的實驗儀表盤。

這釋放出了一個明顯的信號：軟件的本質(zhì)正在從現(xiàn)成的商品降維成瞬時的服務(wù)。

那么問題來了：當(dāng)應(yīng)用可以隨用隨建，我們還需要那個臃腫的應(yīng)用商店嗎

以下為 Karpathy 全文內(nèi)容翻譯（第一人稱）：

我對即將到來的高度定制化軟件時代非常感興趣。

最近我在做 cardio（有氧運動）時有點松懈，所以決定認(rèn)真做個為期八周的實驗性訓(xùn)練，目標(biāo)是讓靜息心率從 50 降到 45。主要方式就是達(dá)到 Zone 2（二區(qū)）有氧的累計分鐘目標(biāo)和每周一次 HIIT（高強度間歇訓(xùn)練）。

僅僅用了一個小時，我就用 vibe coding（氛圍編程）搞出了這個超定制化的儀表盤，專門追蹤這個實驗的進度。

過程中使用的 AI 助手 Claude 得逆向工程伍德威跑步機的云 API，拉取原始數(shù)據(jù)，處理、過濾、調(diào)試，還得建個網(wǎng)頁前端來追蹤實驗。過程并不是一帆風(fēng)順，我得盯著改 bug，比如它搞混了英制公制單位，日歷匹配日期也出了錯。

不過，我還是覺得大方向很明確：

首先，App Store（應(yīng)用商店）永遠(yuǎn)不會（也不該）出現(xiàn)這類應(yīng)用。我不該為了這個去搜索、下載個「有氧實驗追蹤器」。這東西也就三百行代碼，LLM Agent（大語言模型智能體）幾秒鐘就能生成。靠一堆離散應(yīng)用構(gòu)成的「應(yīng)用商店」這種想法，在 LLM 能當(dāng)場為你生成應(yīng)用的今天，顯得既別扭又過時

其次，整個產(chǎn)業(yè)必須重新配置成一套傳感器和執(zhí)行器的服務(wù)，而且它們得具備 Agent Native（面向智能體原生）的易用性。我的伍德威跑步機就是個傳感器，它把物理狀態(tài)轉(zhuǎn)成數(shù)字信息。它不該維持給人看的前端界面，LLM Agent 也不該去逆向工程它。它就該有個 API 或命令行，讓 Agent 能輕松調(diào)用。我對此有點失望，進度也慢下來了。

整個行業(yè)在這方面的進展太慢，99% 的產(chǎn)品 / 服務(wù)仍沒有 AI-Native CLI（AI 原生命令行界面），99% 的產(chǎn)品 / 服務(wù)還在維護那些 .html/.css 的說明文檔，它們給出一網(wǎng)頁的指引，告訴你打開這個網(wǎng)址，點那里，點這里…… 都 2026 年了，直接干或者讓 Agent 干都可以。

所以今天，我對花了一小時就搞定這件小事感到印象深刻，而兩年前得十小時。但更讓我興奮的是思考：這件事怎么才能真正縮短到一分鐘以內(nèi)？需要什么條件才能讓我簡單說句「嘿，幫我追蹤接下來八周的有氧訓(xùn)練」，簡答幾個問題后，應(yīng)用就搭好了？

那時 AI 已經(jīng)掌握了很多個人信息，它會收集額外需要的數(shù)據(jù)，參考并搜索相關(guān)的技能庫，然后維護好所有的小應(yīng)用和自動化。

長話短說，我認(rèn)為，一堆離散應(yīng)用讓你挑的「應(yīng)用商店」模式本身就已經(jīng)越來越過時了

未來應(yīng)該是：通過 LLM 的「膠水」能力，將 AI-Native 的傳感器和執(zhí)行器服務(wù)編排成高度定制、用完即走的臨時應(yīng)用。只是這個未來還沒完全到來而已。

Karpathy 的觀點引發(fā)了熱議，支持者看好未來的 LLM 定制化應(yīng)用方向。

「這才是事情發(fā)展的真正方向。任何人，在任何地方，都能隨手打造自己需要的東西。」

「總的來說，我同意這個觀點。但很多人還是會去雜貨店買吃的，這總歸是有原因的…… 便利性暫且不論，我仍然認(rèn)為應(yīng)用商店可以充當(dāng)一個額外的安全層，尤其是對那些與網(wǎng)絡(luò)交互的復(fù)雜應(yīng)用而言。如果能朝著「應(yīng)用商店 2.0」的方向發(fā)展，那就太酷了。你可以下載一個應(yīng)用的基礎(chǔ)版本，比如某個健身追蹤器，然后 iOS 允許你通過提示來修改和定制這個應(yīng)用。」

與此同時，更多人對此深不以為然。

「得了吧。你真覺得你奶奶想自己做個 App？更別說還要維護它了。大家都忽略了一點，光是「想清楚自己到底想要什么」這件事本身就已經(jīng)需要消耗大量的心力了。App 存在的整個邏輯，某種程度上是建立在這樣一種信任上的：設(shè)計師們，加上用戶們的集體反饋，能夠設(shè)計出一種工作流或交互范式，它比你單打獨斗想出來的要更好。這在 99% 的情況下都是成立的。就算全球有 1% 的用戶想要為那種超級特定的需求搞定制化應(yīng)用，我都會驚掉下巴。不是說這東西沒用，但它離普通用戶想要的實在差得太遠(yuǎn)了。」

Karpathy 進行了回?fù)簦改棠坍?dāng)然不需要懂什么 App，甚至不需要知道有 App 這回事。她的 LLM 智能體懂就行了。」

「你是廚師，但并不是每個人都是或者每個人都想當(dāng)廚師。」

Karpathy 回復(fù)稱，「我覺得這種反駁本質(zhì)上還是囿于對軟件的匱乏思維。兩年前 AI 連自動補全都做不好，今天它已經(jīng)能差不多一次性生成瀏覽器和 C 編譯器了。再過兩年呢？十年？二十年？當(dāng)軟件變得極其廉價、極其豐富時，現(xiàn)在意義上的離散式「應(yīng)用」將毫無意義。那只是一些為了某個極其特定的目的而臨時組裝、執(zhí)行一次就刪掉的代碼路徑。你根本不需要知道什么，也不需要施加任何創(chuàng)意方向，這一切就能替你完成。如果今天的軟件是代碼磚塊壘成的城堡，那未來更像是沸騰的代碼濃湯。我不確定最終會不會完全是這樣，過程肯定是混合的、漸進的，但從原理上說，它真的可能變得非常瘋狂。」

「請教 Karpathy 一個問題：如果未來是臨時性的、一次性的應(yīng)用，那軟件公司要怎么圍繞這個建立商業(yè)模式？」

你是如何看待 Karpathy 的觀點呢？