你手機裡的 50 個 App，有一半活不過這一年

本文整理自 TBPN（The Block Party Network）2026 年 1 月 28 日播出的訪談，由 John Coogan 主持，訪問開源 AI 助手 OpenClaw 作者 Peter Steinberger。這個專案在短短數週內經歷了三次更名：最初叫 Clawdbot，因 Anthropic 的商標要求改為 Moltbot，後再更名為現在的 OpenClaw。

一個健身 App 的死法

Peter Steinberger 在訪談中描述了一個場景，聽起來像科幻片，但他已經在日常生活中這樣做了。

他不再打開 MyFitnessPal 記錄飲食。取而代之的是，他拍一張食物的照片，傳給他的 AI 助手。助手知道他人在麥當勞（因為有位置資訊），知道他拍的是什麼食物（因為有影像辨識），知道他的健身目標（因為有長期記憶），然後自動調整他的運動計畫來彌補這頓。

整個過程不需要打開任何 App。不需要手動輸入卡路里。不需要在五個不同的 App 之間切換。

Peter 用了一個很生動的詞來描述這件事：App 會「融化消失」（melt away）。

不是取代，是讓你根本不需要

這裡的關鍵不是「AI 做了 App 做的事」，而是「AI 讓你意識到你根本不需要那個 App」。

傳統的 App 生態建立在一個前提上：每一個需求對應一個專門的應用程式。想追蹤飲食？下載 MyFitnessPal。想管理行程？下載 Google Calendar。想控制智慧家居？下載米家。想記帳？下載 CWMoney。每一個 App 都是一座孤島，有自己的帳號、自己的介面、自己的資料格式。

AI 助手打破的不是個別 App 的功能，而是這整套「一個需求 = 一個 App」的邏輯。當一個助手能同時存取你的位置、影像、行事曆、健身資料、飲食紀錄，它就不再需要每個領域的專屬介面。它只需要你用自然語言說一句話。

Peter 在訪談中進一步推演：當 App 的使用者介面變得不重要，App 就會退化成 API。而當 AI 可以把資料存在任何地方，連 API 是否還有存在必要都成了問號。

非技術者的覺醒：25 個 Web Service，零行手寫程式碼

Peter 分享了一個讓他自己也驚訝的案例。他在一場聚會上遇到一位來自印第安納州的設計公司負責人，這個人從未寫過程式。

這位負責人在 2025 年 12 月發現了 OpenClaw（當時還叫 Clawdbot），開始透過 Telegram 跟他的 AI 助手對話。到訪談時，他的公司已經建了 25 個內部 Web 服務——全部是透過跟 AI 聊天產生的。他不知道程式碼怎麼運作，他只是把問題描述出來，AI 就把工具建好了。

這個案例的震撼不在於「AI 能寫程式」——這件事大家早就知道。震撼在於：非技術者已經跳過了「學習使用現成 App」這個步驟，直接進入「讓 AI 幫我量身打造」的階段。

Peter 這樣總結這個轉變：你不再需要訂閱那些提供「大家都需要的功能子集」的 SaaS 服務。你可以擁有完全客製化、專門解決你的問題的軟體，而且是免費的。

我的觀察

App Store 模式的黃昏

如果 Peter 的預言有一半成真，受衝擊最大的不是個別 App 開發商，而是平台本身。

Apple 的 App Store 和 Google Play 的商業模式建立在一個核心假設上：使用者需要下載 App，而每一次下載和訂閱，平台都可以抽取 15-30% 的佣金。2025 年，App Store 的全球營收估計超過 900 億美元，Google Play 也有 400 多億。這兩個數字的基礎，是數以百萬計的 App 和數以十億計的下載次數。

但如果使用者開始用 AI 助手取代大量中間層 App——健身追蹤、記帳、食譜、待辦事項、天氣、翻譯——這些 App 的下載量和訂閱收入就會開始萎縮。而 Apple 和 Google 目前還沒有一套成熟的機制，來對「AI 助手透過 API 呼叫後端服務」這件事抽成。

這不是說 App Store 明天就會消失。遊戲、社群媒體、影音串流這類重度體驗型 App 在短期內不會被取代。但那一大片「工具型 App」——也就是你下載了但每個月只開兩三次的那些——它們的處境會越來越艱難。

更深層的問題是：如果軟體的價值從「介面體驗」轉移到「資料與 API」，那現在靠漂亮 UI 吸引下載、靠訂閱制收割的商業模式，根基就動搖了。

臺灣的 App 開發產業要怎麼辦

這個趨勢對臺灣的衝擊可能比矽谷更直接。

臺灣有大量的中小型軟體公司，核心業務就是幫客戶開發 App 或內部系統。從企業內部的簽核系統到面向消費者的電商 App，接案開發一直是臺灣軟體業的主要收入來源之一。

但 Peter 描述的那位印第安納州設計公司負責人，正在示範一個替代方案：不需要找軟體公司開發，直接用 AI 建。而且建出來的東西是高度客製化的，比外包開發的「標準化方案」更貼合需求。

這不代表所有接案開發公司明天就會倒閉。複雜的企業系統、需要高度安全性和合規性的金融科技、需要整合既有基礎設施的專案——這些在短期內仍然需要專業團隊。但那些簡單的「幫我做一個內部工具」、「幫我做一個小型網站」的案子，利潤空間會被大幅壓縮。

臺灣的軟體公司如果還在用「工時 × 人頭 = 報價」的模式做生意，需要認真思考轉型了。未來的價值不在「寫程式碼」，而在「理解客戶的業務邏輯並設計正確的系統架構」——這是 AI 目前還做不好的事。

「超個人化軟體」時代的隱私悖論

Peter 描述的願景很美好：AI 助手比任何 App 都更了解你，因此能提供更精準的服務。但這裡有一個他在訪談中沒有深入討論的矛盾。

要讓 AI 助手取代 MyFitnessPal，它需要知道你的位置、飲食習慣、健身目標、身體數據。要讓它取代你的行事曆，它需要知道你見了誰、去了哪裡、談了什麼。要讓它取代你的記帳 App，它需要知道你的每一筆消費。

把這些資料集中在一個 AI 助手手上，本質上就是在建造一個關於你的超級檔案。

Peter 的回應是「在本地跑」——用 Mac Studio 跑本地模型，資料不出你的電腦。這確實比把所有東西都傳到雲端好。但本地運算有兩個現實限制：第一，本地模型的能力還遠不及雲端的頂級模型；第二，不是每個人都有一台 512GB 的 Mac Studio。

Peter 自己也承認，他的 AI 助手大量依賴雲端 API——Claude、GPT、OpenAI 的語音轉文字服務。所以即使運算在本地，資料仍然會在你和雲端之間來回流動。

更麻煩的是 Peter 在訪談中坦率承認的：prompt injection 問題目前無解。當你的 AI 助手連接了 WhatsApp、Discord、Email，任何一條惡意訊息都可能操控你的助手做出你不想要的事。他原本建造這個專案是給自己用的，只在信任的環境中運行。但當數萬人開始在開放的 Discord 和公開的 Web 介面上使用它，所有他原本不需要擔心的安全問題都浮上了檯面。

這不是要否定個人 AI 助手的方向。這是要指出：在「AI 取代 50 個 App」的美好願景和「一個助手掌握你所有隱私」的風險之間，我們還沒有找到平衡點。2026 年如果真的是「個人 AI 助手元年」，那安全和隱私的基礎設施必須跟上，否則第一次大規模的隱私事故，就足以讓整個趨勢倒退好幾年。