Vibe coding 讓上線變簡單、變現變難

Vibe coding 讓 app 更快做出來，但也讓你更難賣出去。

我這陣子一直在看 vibe coding 這波浪潮，老實說，越看越覺得哪裡不對勁。大家講得很順：買台筆電、訂個模型、把想法打進去，app 就出來了。聽起來很爽，像是終於不用跟工程師磨半天。可問題是，真正難的從來不是「能不能把 code 寫出來」。難的是後面那一串：產品會不會壞、別人看不看得懂、值不值得付錢、上線後有沒有人鳥你。

所以我看到現在這種熱度，第一個感覺不是興奮，是有點偏掉了。很多人把「送出第一版」當終點，實際上那只是最醜的起跑線。我以前也看過這種戲碼，從 no-code、模板商店，到「週末做出一個產品」的神話，工具越來越強，門檻越來越低，大家就以為市場也跟著變大了。沒有。很多時候剛好相反，市場只會更吵，複製更快，最後活下來的是那些真的知道自己在解什麼問題的人。

我不是反 vibe coding，我是反幻想。如果你是 founder，這波東西很有用；如果你以為它可以直接取代產品思考、分發、維運，那你只是把學費延後繳，而且通常還會繳得更貴。

這篇我拆的是 Business Insider 的 Emily Stewart 寫的文章，〈Vibe Coding Made It Easy to Build Apps — Now the Market Is Flooded〉。她引用了 Appfigures 的數據，也訪談了 Rebecca Kaden、Charity Majors、Kate Minogue、Amjad Masad、Kylan Gibbs 這些人，核心意思很直白：瓶頸真的移位了。建置變便宜，脫穎而出沒有變便宜。

以前卡的是寫 code，現在卡的是你到底懂不懂產品

“For the first time in 20 years, the wall between having an idea and actually building it has come down.”

這句是 Eli Cohen 說的，我完全懂他在講什麼。幾年前，一個 app idea 很容易死在「我想得到」和「我付得起」之間。現在這條縫小很多了。像 Claude、OpenAI、Replit 這些工具，真的把 idea 到 prototype 的距離壓到很短，短到有點不合理。

白話翻譯就是：寫 code 不再是很多小軟體產品的主要門檻了。這件事我自己也看得很清楚，很多非工程背景的 founder，從「我需要找人做」變成「我週末就先做一版 skeleton」；這不是嘴砲，是實際發生的事。

但坑也在這裡。當 code 變便宜，市場不會更獎勵 code，市場只會更獎勵判斷力。真正贏的人，是知道要做什麼、不要做什麼、哪裡該砍掉的人。vibe coding 很會幫你做第一稿，但它不會自動長出 taste、strategy、product sense。

我之前就踩過這種坑：一開始很愛把 AI 當補師，什麼都叫它先起草。結果東西是有了，問題也一起長出來。功能越堆越多，方向越來越散，最後不是產品，是一坨看起來很像產品的東西。

實操寫法很簡單：先用 AI 迅速做出可測試的 prototype，但在下第一個 prompt 之前，你要先定義你到底在驗證什麼。是需求、流程契合、定價，還是留存？如果你答不出來，你不是在做產品，你只是把 software-shaped noise 生出來而已。

• 先做能驗證一個使用者行為的最小版本。
• 上線前先寫下唯一要看的指標。
• 第一版要預設可丟棄，不要戀愛。

App store 變成公共實驗室，不是什麼溫柔市場

Stewart 在文裡引用 Appfigures 的數據：2026 年第一季有 414,000 個新的 iOS 和 Android app 上架，比 2025 同期多 115%。這不是小幅成長，這是直接灌進去。文章還說，這些裡面只有 118 個達到所謂的 high-traction，也就是美國下載量超過 50,000。命中率 0.02%。

這句話的白話版是：app store 越來越不像市場，越來越像一個公開實驗室。大家上線的速度比以前快很多，但大多數上線的東西根本不是 business，只是 experiment。是 draft，是證明你做得出來，不是證明有人會買。

我看過太多 founder 把「我們上線了」誤認成「我們找到市場了」。以前這種錯誤就很貴，現在更貴，因為別人也都能上線。你如果真的解到痛點很好，但現在你面對的是一百個也能做出看起來不錯的 app 的人。上線門檻下降，相關性門檻上升。

我自己會怎麼做？我不再拿 app 數量當 KPI，我改看 user pull。你如果連很小一群人都拉不出 repeat usage、referral、paid conversion，那你很快做出來這件事根本不重要。你需要的是 signal，不是 artifacts。

實操寫法：別先問「我做得快不快」，先問「有人會不會回來」。如果 7 天和 30 天留存都沒訊號，先別加功能。先去訪談前 10 個使用者，看他們到底是在忍受你，還是真的需要你。

• 追 7 日與 30 日留存，不要只看 installs。
• 先訪談 10 個早期使用者，再決定要不要加功能。
• 快速砍掉沒有 repeat use 的點子。

真正的難點搬到 distribution，這才是最常讓人破防的地方

Kate Minogue 說 distribution 還是最難的問題，我同意。進 App Store 或 Google Play，不等於有人會來看你。這件事以前就是真的，現在只是更殘酷，因為同一塊注意力被更多 app 搶。

我最想抓出來的是這句：

“When I talk to companies that are building an app, I try to prepare them for having to spend hundreds of thousands of dollars to get scaled distribution of their apps.”

白話就是：marketing 不再是上線後才補的作業，它是產品計畫的一部分。沒人知道你的 app，介面再漂亮也沒用；沒人懂你為什麼存在，AI 生成 code 再快也沒用。

我看過不少團隊把幾個月拿去磨功能，卻對 acquisition channel 一片空白。這整個順序是反的。你如果不知道怎麼接觸使用者，你就不是在做 business，你是在養一個有 deployment pipeline 的興趣。

實操寫法：先設計 distribution，再設計功能。挑一條你真的有機會掌握的路：search、creator partnership、paid ads、community、outbound、ASO，或 B2B sales。然後讓產品長成那條路的樣子，而不是反過來。

這裡可以直接看幾個權威資源：Google Play listing 指引、Apple App Store 資源，還有如果你做的是 commerce 而不是純 consumer app，可以看 Shopify。這些都不會替你解決分發，但至少會提醒你，discoverability 是一個系統，不是一句願望。

“Underpants gnome logic” 這個吐槽，真的很準

Charity Majors，Honeycomb 的 CTO 和共同創辦人，講 vibe coding 環境帶來一種 “underpants gnome logic”。這個笑話很老，但套在現在超準：第一步是收集內褲，第三步是賺錢，中間那步是問號。放到 app 世界就是：第一步是把東西做出來，第三步是變現，中間那段現實會拿扳手敲你。

翻譯一下就是：code generation 只是 product creation 很小的一塊。就算 AI 幫你把第一版做出來，你還是得面對 architecture、maintenance、bug、security、analytics、onboarding，還有那些 demo 結束後才會浮出來的麻煩事。

我以前也常跟人解釋，software 不是一張有按鈕的截圖。只要使用者開始依賴你，你就背上 support burden；只要有 payment，你就背上 trust 和 compliance；只要有 scale，你就會開始遇到 prompt 解不掉的 failure。

所以我對那種「vibe coding 讓工程消失」的說法很保留。它沒有消失工程，它通常只是把工程延後到上線之後。那時候更貴，也更丟臉。

實操寫法：先把維運成本算進去，再談 growth。至少要有 logging、error handling、backup，還有一個能看懂 app 在幹嘛的方法。你如果 debug 不起來，那你根本不算擁有它。

• 第一天就上基本 observability。
• 列出「最先壞的是什麼」清單。
• 安全敏感流程一定保留人工確認。

護城河變薄了，所以 product taste 反而更值錢

Stewart 那篇最尖的一點是：市場一旦飽和，就更難冒出來。這句話聽起來很廢話，但很多 founder 還是會把「競品很多」當需求存在的證據。某些時候是，某些時候只是市場很擠、使用者很亂。

Majors 提到 Slack 難的不是寫 code，而是那個讓它直覺又可擴充的設計。這才是重點。code 是最容易被抄的部分，產品判斷才是最難複製的地方。

白話講，taste 變成商業資產了。不是那種很虛的設計師口味，而是你能不能判斷哪些 friction 有必要、哪些 confusion 會致命、哪些小細節會讓使用者信任你，然後願意回來。AI 可以幫你生選項，但它不會告訴你哪個選項最像「本來就該長這樣」。

我在 internal tool 上也看過一樣的事。兩個團隊都能更快做出 workflow，但最後勝出的通常是那個比較不煩、比較不卡、比較不需要人教的版本。這不是魔法，這是很多小決定累積出來的結果，而且通常是懂使用者的人做出來的。

實操寫法：不要複製 feature，去複製 user outcome。先問使用者真正想完成什麼，再把步驟砍到最少。如果你的產品需要一大段教學才能說明價值，那很可能你還沒找到對的形狀。

這裡我會參考 Nielsen Norman Group 的 usability 思路，還有 Intercom 對 onboarding 和 support 的討論。它們不會救爛點子，但會逼你老實一點。

AI 最適合當工廠，不適合當你的幻想機器

Amjad Masad，Replit CEO，提了一個我很認同的角度：不是每個 app 都要變成 venture-scale。有些工具只要能讓創辦人賺錢，或至少把日常開銷撐起來，就已經很夠了。這比那種每個 app 都偷偷幻想要變成下一個大平台的戲碼健康多了。

白話就是：AI 降低的是嘗試成本，不是成功成本。這個差別很重要。如果你的目標是做一個小眾但有用的工具，vibe coding 很棒；如果你的目標是做一間耐用的公司，你還是得回答一件事：為什麼使用者在新鮮感退掉之後還要繼續付錢？

我其實喜歡這種變化，因為它把很多虛榮心剝掉了。不是每個 founder 都要追一個超大結局。有人只需要穩定 side business，有人只需要 niche product，有人只是想知道這個 idea 值不值得再花時間。AI 讓這些路都更容易走。

但更容易走，也代表更多人會來試。這就是交換。更多 builder、更多 noise、更多看起來普通的產品，也更多好產品冒出來的機會。你如果真的認真，不是去抱怨 noise，而是去做更清楚的 signal。

實操寫法：先決定你是在做 venture bet、cash-flow product，還是 internal tool。這三種 business 的標準完全不一樣。你如果混在一起做，最後只會拿錯 KPI，然後一路浪費時間。

可抄的模板

# Vibe-Coded App Launch Template（可直接改成你自己的版本）

## 1. 我到底在做什麼
- 產品名稱：
- 目標使用者：
- 一句話承諾：
- 使用者痛點：
- 這不是要解決的問題：

## 2. 我先驗證哪件事
- 假設：
- 成功指標：
- 觀察期限：
- 失敗條件：
- 需要多少人才能判斷：

## 3. MVP 範圍
- 必做功能：
- 可延後功能：
- 明確不做：
- 第一版只支援的流程：

## 4. 建置方式
- 使用的 AI 工具：
- 人工審查點：
- 資料結構：
- 登入 / 付款 / 分析：
- 錯誤處理 / logging：
- 備份與還原：

## 5. 分發方式
- 主力渠道：
- 備用渠道：
- 前 20 位使用者怎麼來：
- 預算上限：
- 上線日期：
- 轉換漏斗：

## 6. 留存設計
- 啟動事件：
- 一週內回訪理由：
- 讓人想再用一次的觸發點：
- 支援流程：

## 7. 維運計畫
- 誰修 bug：
- 怎麼回報問題：
- 監控哪些指標：
- 安全檢查：
- 每月 review 日期：

## 8. 定價方式
- 免費方案：
- 付費方案：
- 價格點：
- 升級觸發條件：
- 取消後怎麼挽回：

## 9. 決策紀錄
- 哪些有效：
- 哪些沒用：
- 哪些該砍：
- 哪些該加碼：
- 下一版只改一件事：

## 10. 上線前檢查
- App listing 完成
- Landing page 上線
- Analytics 裝好
- Support email 可用
- Privacy policy 已公開
- 5 位 beta user 已進來
- 第一次 feedback review 已排程

這份我會直接丟給任何一個準備用 prompts 跟樂觀情緒衝出去的 founder。它逼你把問題從「能不能做出來」改成「這東西能不能真的被用、被付錢、被留下來」。

這就是我看完這波 vibe coding 之後最確定的一件事：它沒有把軟體的難題拿掉，它只是讓難題更快浮出來。你用得好，就會更快上線、更快學到東西；你用得爛，就只會多出一堆看起來完成、實際上只是猜測的 app。

來源致謝：原始材料是 Emily Stewart 的 Business Insider 文章，https://www.businessinsider.com/vibe-coding-build-apps-ai-market-flooded-killer-app-guy-2026-5。文中的數據與引述來自原文；我在這裡做的是拆解、翻譯成白話，外加補上可直接拿去用的 launch 模板。