2026年 Vibe Coding 軟體收費：賣斷、訂閱還是按次

最後更新於 2026 年 7 月 28 日；行業數據核實自 RevenueCat 2026 年報告及 Apple、Google Play、支付平台官方文件。

本週建議動作：先把第一版產品限定為一種主收費模式。 離線單功能工具先試賣斷；持續更新或需要帳戶服務的軟體先試訂閱；AI 調用量差異大的產品，採用訂閱加按次額度。只有在取得真實付款與單用戶成本後，才增加第二種方案。

這個判斷適用於三類人：已用 Vibe Coding 做出第一個工具、但不懂如何定價的零基礎創作者；準備發布 AI 應用、需要控制接口調用與維護成本的個人開發者；以及計劃上架 iOS 或 macOS 軟體、正在評估發布環境的副業新手。

供給增長與收入集中

會做出軟體，不等於有人願意付費。RevenueCat 在 2026 年發布、主要分析 2025 年資料的訂閱應用報告，涵蓋超過 115,000 個應用、超過 160 億美元收入及超過 10 億筆交易。報告顯示，2022 年至 2026 年初，每月新推出的訂閱應用數量增加約 7 倍；但 2020 年以前推出的應用，仍佔 2026 年 1 月訂閱收入約 69%，2025 年或之後推出的應用只佔約 3%。詳情可參考 RevenueCat 2026 訂閱應用報告原始資料。

市場指標	報告資料	對 L1 開發者的含義
每月新訂閱應用增長	約 7 倍	功能相似的產品更多，單靠「用 AI 做出來」不足以吸引用戶
2020 年前應用收入佔比	約 69%	老產品有較長時間累積品牌、評價、資料與留存
2025 年後應用收入佔比	約 3%	新產品需要更快驗證需求，不能只等待自然下載
頂部 25% 應用年增長	超過 80%	收入分化明顯，平均數不能代表普通新手的結果
底部 25% 應用變化	收縮約 33%	沒有留存或獲客能力時，訂閱收入可能迅速下滑

這些數字不是叫你放棄，而是提醒你先問一個更重要的問題：你的軟體是否解決一項用戶會反覆遇到、而且不想自己處理的工作？

Vibe Coding 降低的是製作門檻。它沒有自動解決獲客、信任、客服、退款、更新與收費問題。你可以很快做出介面，但用戶仍然會比較：

你的結果是否比手動處理更快。
軟體是否穩定，不會在關鍵時刻失效。
付款後是否持續得到新價值。
出問題時，是否有人處理帳戶、資料與退款。

使用頻率與價值週期

收費方式首先由「用戶多久需要一次結果」決定。

例如，將圖片批量改名、把檔案轉換成特定格式、計算固定公式的離線工具，使用者可能一個月只開啟幾次。只要功能完整、可安裝、沒有持續伺服器成本，賣斷通常較容易解釋。

相反，以下產品更接近訂閱：

每日更新資料的工作面板。
跨裝置同步的筆記或專案工具。
持續產生新內容的學習服務。
需要多人協作、權限管理與版本紀錄的雲端軟體。
需要後端保存帳戶、檔案與使用歷史的 AI 應用。

訂閱不是「每月自動收錢」這麼簡單。它代表你每個月都要繼續提供價值。若產品三個月沒有更新、資料不再改善、客服沒有回應，用戶就有充分理由取消。

賣斷也不是沒有維護。你仍要處理作業系統更新、簽名、相容性、錯誤修正與下載問題。差別在於：賣斷主要依賴持續找到新客戶；訂閱則更依賴續費、留存與長期價值。

新增用戶成本

你需要把每位新用戶帶來的成本拆成三層，而不是只看付款金額。

第一層是固定成本。 例如開發工具、帳戶、基本監控、網域、客服流程與發布環境。這些成本不一定隨用戶數即時上升。

第二層是按用戶增加的成本。 例如資料儲存、備份、帳戶管理與同步。用戶越多，資料保存量與客服量通常越高。

第三層是按使用量增加的成本。 例如 AI 模型調用、影片處理、圖片生成、轉錄、伺服器運算與大量傳輸。這一層最容易讓永久買斷失去控制。

產品形態	新增用戶後的主要成本	較適合的第一版模式	風險評分
完全離線工具	主要是更新、客服與發布	賣斷	低
一般雲端軟體	儲存、資料庫、備份、同步與客服	訂閱	中
AI 應用	API 調用、伺服器、儲存、濫用控制與人工審核	訂閱加按次額度	高
團隊協作工具	權限、通知、版本紀錄與資料保存	按席位訂閱	中至高

如果你讓用戶永久買斷一個需要持續調用 API 的產品，至少要先回答四件事：

每位用戶每日可以使用多少次。
額度用完後是等待、購買還是降級。
是否有濫用偵測與帳戶限流。
退款時，已消耗的高成本服務如何計算。

沒有這些限制，買斷只是把未來成本延後。它不代表真正的高毛利。

首次轉化與長期留存

RevenueCat 的資料顯示，硬付費牆在第 35 天的下載到付費轉化中位數約為 10.7%，免費增值模式約為 2.1%；但硬付費牆的差異也更大，產品定位與首屏價值沒有做好時，結果可能相差很遠。報告同時顯示，年度訂閱的第一年留存並沒有因硬付費牆而必然勝出：免費增值約 28%，硬付費牆約 27%。

這代表「第一次比較容易收費」不等於「長期收入穩定」。

AI 應用尤其需要小心。報告中，AI 應用每位付費者首月實現生命週期價值中位數為 18.92 美元，非 AI 應用為 13.59 美元；但 AI 應用年度留存率低於非 AI 應用，月訂閱留存約為 6.1% 對 9.5%，年度留存約為 21.1% 對 30.7%。

因此，AI 應用不應只用高首月收入來判斷模式成功。你還要記錄：

用戶每月實際使用次數。
每位活躍用戶的模型與伺服器成本。
用戶取消的原因是價格、使用不足還是品質問題。
人工審核、錯誤修正與客服所需時間。

發布渠道與到手收入

網頁付款、App Store 與 Google Play 的到手收入不能直接比較。

在 App Store，小型開發者計劃通常可將付費軟體與內購抽成降至 15%；自動續訂訂閱在同一訂閱群組累積滿一年後，官方說明的開發者所得比例可提高至 85%，仍需扣除適用稅項。相關規則可查看 App Store 小型開發者計劃及自動續訂訂閱所得說明。

Google Play 的規則則按地區、安裝狀態、交易類型與計劃而變。官方頁面列出，部分市場在 2026 年 6 月 30 日起採用新收費安排；其他市場仍可能適用首年收入 15%、超過門檻後 30%等分層規則。數位商品與雲端服務在應用內交易時，也通常受其付款政策約束。相關內容可參考 Google Play 服務費與付款政策。

網頁付款的彈性較高，但退款、爭議款、稅務、付款失敗與客服由你自行處理。以支付平台官方文件為例，退款可能需要從可用餘額扣除；餘額不足時，退款可能暫停，部分退款亦可能產生費用。可參考支付平台退款與取消付款文件。

發布渠道	收費彈性	你要承擔的工作	適合情況
網頁	最高，可做訂閱、一次付款與額度	付款、退款、稅務、客服與風險控制	B2B 工具、雲端服務、已有流量
App Store	受內購與審核規則影響	審核、產品頁、內購設定與退款協調	iOS 或 macOS 應用
Google Play	地區與付款政策差異較多	商店政策、付款整合與退款流程	Android 應用或多平台產品
直接發佈離線工具	可設計永久授權	簽名、更新、啟用碼與相容性	沒有持續 API 或伺服器成本的工具

如果你要上架 iOS 或 macOS，發布環境也是成本的一部分。Xcode 用於建置、測試與提交 Apple 平台應用；官方文件亦說明，應用上傳需要符合當期 SDK 與系統要求。可參考 Apple Xcode 官方文件。

你不一定要立刻購買長期閒置的 Mac。先確認產品是否有人願意付款，再按預計測試、簽名、修正與提交時間準備短期雲端 Mac，通常更容易控制前期現金支出。若你要比較遠端帳戶與連線設定，可先查看 VPSSpark 幫助中心；若測試用戶分布在不同地區，也可參考 VPSSpark 美國東部方案說明，先確認你的遠端測試連線條件。

第一版收費決策

你可以用以下四個指標做初步評分。每項從 0 至 2 分評估，分數不是收入預測，而是幫你排除不合適的模式。

價值頻率：用戶是否每週或每日需要結果？
持續成本：每次使用是否會增加 API、伺服器或儲存支出？
留存必要性：產品是否必須持續更新才有用？
渠道限制：是否需要 App Store 或 Google Play 內購？

判斷方式很直接：

價值頻率低、持續成本低、渠道以離線安裝為主：優先賣斷。
價值頻率高、需要同步或內容更新：優先訂閱。
AI 調用量差異大、重度用戶成本明顯較高：訂閱加按次額度。
如果四項都不確定：先不要設計三層套餐，回到最小可用版本測試付款。

五步完成最小驗證

第一步：寫出單一目標用戶。
不要寫「所有需要 AI 的人」。改成「每天需要整理大量客戶訊息的自由工作者」或「每週要把多份報告轉成固定格式的顧問」。

第二步：展示可交付結果。
讓潛在用戶看到輸入與輸出。不要只展示介面、動畫或技術架構。用戶付費的是結果，不是你的程式碼生成過程。

第三步：只測一種主收費模式。
離線工具可先測一次付款；雲端服務可測單一訂閱；AI 應用則測一個基礎訂閱加有限額度。不要同時推出賣斷、月費、年費、終身版與企業版。

第四步：記錄單用戶成本。
至少分開記錄模型調用、伺服器、儲存、支付抽成、退款與人工客服。沒有實際使用資料前，不要把成本假設成零。

第五步：設定停損與調整條件。
例如收集一批真實試用者後，觀察是否有人完成付款、是否在首次使用後取消，以及高用量用戶是否帶來負毛利。達不到條件，就縮小功能或改為按次額度，不要盲目加大廣告與開發投入。

常見問題

Vibe Coding 做出來的軟體真的可以賣錢嗎？

可以，但能否收費不取決於你是否使用 Vibe Coding，而取決於軟體是否替特定用戶完成一項值得付費的工作。先找出明確結果，例如節省整理時間、產出報告或降低重複操作，再用單一主收費模式測試真實付款，不要把完成原型誤當成已有市場。

AI 應用應該一次性收費，還是採用訂閱？

如果 AI 應用每次使用都會產生模型、伺服器或儲存成本，單純賣斷通常會讓你承擔長期履約風險。較穩妥的做法是以訂閱支付基本服務，再以按次額度控制高用量功能。若產品完全離線、沒有持續成本，才適合優先考慮賣斷。

個人開發者第一次替軟體定價，應該從哪種模式開始？

先看用戶多久需要一次結果，而不是先猜哪種模式收入最高。低頻、結果固定的工具可先賣斷；需要同步、更新或帳戶服務的產品先試訂閱；使用量差異很大的 AI 功能則採訂閱加額度。第一版只保留一條主路徑，方便判讀數據。

有 API 調用成本的軟體可以永久買斷嗎？

可以，但你必須把 API 成本轉嫁、限制或預付進產品設計。若用戶買斷後可以無限調用，而每次請求都增加你的支出，使用量越高，產品越可能由收入來源變成負債。較安全的方案是設定額度、超額按次收費，或把高成本功能放進訂閱層。

由收費模式反推雲端 Mac 方案

如果你的產品是完全離線工具，現有電腦可能已足夠；若你要長期進行大量編譯、測試或需要實體裝置連線，購買設備才可能更合適。可是對尚未驗證付費需求的 L1 開發者而言，直接購買 Mac 會先承擔設備折舊、閒置時間與維護成本；Windows 或 Linux 開發環境也可能在 iOS 簽名、Xcode 測試與 App Store 提交流程中遇到額外切換。

更穩妥的做法，是先按預計的建置、簽名、測試與審核週期準備短期雲端 Mac。等你的軟體有真實付款、明確留存，以及可計算的單用戶成本，再決定是否轉為長期設備。這樣不是把成本推遲，而是先讓發布環境跟著產品驗證進度走。