Spotify 把 AI 變噪音

我拆 Spotify 的 AI 路線，講它為什麼越加越亂，最後給你一個能直接拿去做 discovery-first 功能的模板。

我用 Spotify 很久了，久到我看得出它什麼時候開始走鐘。原本我只是想打開 app 聽歌，後來變成 podcasts、audiobooks、DJ、推薦、搜尋、現在又一堆 AI。問題不是它不能加功能，問題是它每加一次，就把原本很直覺的「找歌、聽歌」弄得更吵。我最受不了的是，AI 看起來很忙，實際上常常只是把雜訊包裝得比較像科技。

我最近會去看 TechCrunch 的 Ivan Mehta 這篇 Spotify’s AI bet: more of everything, less of what you want，因為它把這種不對勁講得很準。這不是單純在罵 Spotify，而是在拆一個很多產品團隊都會犯的毛病：把 AI 當成功能桶，而不是當成使用者結果。Spotify 只是比較誠實地把這個毛病做大給你看。

Spotify 不是在幫你聽得更好，是在幫它自己長更多內容

“The latest wave, announced at its investor day, skews heavily toward using AI to generate content rather than using AI to help users find content they actually want.”

翻譯一下就是，Spotify 這波 AI 的重心偏向「生內容」，不是「幫你找到想聽的內容」。這差很多。前者是在擴充供給，後者是在降低選擇成本。你如果是做 discovery-first 的產品，AI 應該先幫使用者縮小範圍、過濾噪音、提高命中率，而不是先把庫存灌爆。

我自己看產品時很常遇到這種誤判。團隊一看到 AI，就開始想：可以多做摘要嗎？可以多生 clip 嗎？可以多產出變體嗎？但真正的問題通常不是「還不夠多」，而是「我到底該先看哪個」。使用者要的是判斷，不是產量。

Spotify 這裡最大的風險，是它把 app 的重心從「消費人類做的音訊」慢慢推到「平台自己也能生成音訊」。一旦生成、改寫、摘要、推薦、解釋全部都塞進同一個體驗，使用者感受到的就不是更聰明，而是更擠。

實操寫法很簡單：你在寫 AI feature spec 之前，先寫一句使用者承諾。若這句話是「讓使用者做更多」，你多半在做供給；若這句話是「讓使用者更快找到對的東西」，你才是在做 discovery。這兩件事不要混在一起，不然你的指標會騙你。

• 先判斷 AI 是在減少選擇，還是在增加選項。
• 量 task completion，不要只看 feature usage。
• 把 creation AI 和 discovery AI 分開排 roadmap。

內容變多，不代表價值變多

“Now Spotify has signed a deal with Universal Music Group (UMG) that allows fans to create AI covers and remixes of existing songs.”

這種平台最常見的毛病就是：只要能生出更多東西，就以為平台變強了。其實很多時候只是變吵。跟 Universal Music Group 的合作，可能有版權分潤、可能有藝術家補償，這些都重要；但它沒有解掉 discovery 的核心問題。內容一多，使用者還是得自己撥開一堆 AI 翻唱、remix、變體，才找得到原作或真正值得聽的東西。

我以前做過一個產品，某個模組開始自動產生「相關內容」，產量瞬間上來，團隊很嗨，因為 DAU 看起來也動了。但使用者抱怨也同步上升，因為介面變得很模糊：每個東西都像某個東西的旁支，沒有一個東西是你可以一眼認定它重要的。那種感覺很像走進雜貨店，結果每個架子都貼著「你可能也會喜歡」。很煩。

Spotify 現在就在踩這個坑。文中提到 AI 生成音樂的速度可能快到平台自己都管不住，這不是技術炫不炫的問題，而是 curation 跟不上 production。只要 ranking、標示、過濾沒做好，feed 就會變成垃圾抽屜。使用者一旦不信任 surface，discovery 就死了。

實操上，我會先做 content quality gate，再做 generation feature。只要你的產品可以多生十倍內容，你就需要更強的排序、更清楚的標示、還有抑制低訊號內容的機制。沒有這些，你不是在擴張價值，你是在擴張清理成本。

• Generated content 要一致標示，別讓人猜。
• Search 和 browse 要保留 original / human-made 路徑。
• 給使用者一個明確的排除選項，不要只會塞給他看。

Spotify 一邊做助手，一邊把使用者推去當測試員

“The company is also releasing an experimental desktop app that connects to a user’s email, notes, and calendar, pulls in relevant information, and generates a personalized audio briefing.”

看到這段我真的有點想翻白眼。現在不只是音樂、podcast、audiobook，而是 app 要去碰你的 email、notes、calendar，然後把你的生活整理成一段 audio briefing。這個方向不是不能做，但它對 permissions、context、準確性、可解釋性要求很高。做得好很有用，做不好就很像把你的私人資料丟進一台會講話的碎紙機。

文中也提到這個 app 可以在允許下做 research、用 browser、整理資訊、協助完成任務。這已經是 agentic AI 的語言了。白話一點，就是它不只想「講給你聽」，它還想「幫你做」。我不反對，但我很反感那種先把產品包裝成很聰明，結果底層可靠性還沒過關的做法。

我做過 assistant 類功能，最常見的劇本就是 demo 很漂亮。第一次跑，找得到正確 email，摘要也像那麼回事。真的上線後，edge case 才是本體：權限不乾淨、上下文過期、抓錯 note、把舊會議當新決策。最後使用者變成要盯著 assistant，這就很荒謬了，因為 assistant 本來是要減少盯人的。

實操寫法：如果你要從 recommendation 走到 agentic action，先切清楚「只讀幫忙」和「代表我執行」兩條線。先做 read-only，輸出要可稽核，要能看到來源，要能修正，而且不會把整個流程打斷。講白一點，不能解釋自己怎麼來的系統，不要急著讓它替人工作。

我也很在意一件事：很多團隊會因為 feature 不知道放哪裡，就另外開一個 app。這有時候是對的，但很多時候只是主產品裝不下那個功能。若 personalized briefing 真有用，為什麼不是在核心 app 裡？如果一定要獨立 surface，那你最好有很硬的理由，不要只因為它掛著 AI。

當 app 開始跟自己對話，找東西只會更累

“Spotify is adding natural-language discovery for audiobooks and podcasts, similar to how Google has been pushing people toward conversational search.”

自然語言搜尋聽起來很方便，但它也可能只是 catalog 太肥之後的止痛貼。當內容太多，使用者就被迫改成問問題來找東西。這表面上很順，實際上你是把導航責任丟給模型對 intent 的猜測，而不是讓資訊架構本身站得住。

文中還提到，很多人可能已經在 ChatGPT 或 Gemini 裡這樣找內容了，但 Spotify 不想讓使用者離開 app。這很正常，沒人想把流量送出去。問題是，你把 conversation 留在 app 裡，前提是 app 得真的比通用聊天工具更會找，而且能直接把人帶到正確內容。做不到的話，這只是把迷路留在自己家裡。

我對這類功能一直很保留，因為 Spotify 已經有 AI DJ，現在又疊上 chat、search、generation。功能一層壓一層，最後介面就像一個會講話的圖書館，但你還是找不到書在哪裡。這種產品不是更有智慧，是更像在自我解說。

實操上，我會把 conversational search 當 shortcut，不要當整個導航系統。browse、search、filter、collection 都要保留，而且要清楚好用。只要唯一找東西的方法變成問 chatbot，你的資訊架構其實已經輸了。

• 保留直接導航，不要把所有路徑都藏進對話框。
• 把 conversational search 限定在長尾 query。
• 測試使用者能不能從錯誤 AI answer 裡順利回來。

每個功能都叫 AI，最後只剩噪音

“The company is no longer focused solely on consumption — it’s actively nudging users to create content, too, even if it’s just for themselves.”

這句我覺得最準。Spotify 不再只是讓我聽，它還想讓我做、問、摘要、改寫、整理，順便把生活也一起音訊化。產品野心可以有，但當每個新功能都用同一個 AI 理由包裝，AI 就不再是設計選擇，而是反射動作。

這時候使用者會感受到拖曳感。不是因為 AI 一定不好，而是因為功能之間沒有清楚階層。哪些是幫我消費，哪些是幫我創作，哪些是幫我決策，這三件事如果全擠在同一層，產品就會變成一個迷宮，裡面還有個語音導覽。

我很常看到團隊把 AI 當萬用膠水，哪裡卡就往哪裡抹。結果每個 surface 都說自己有 AI，卻沒人說得清楚這個 AI 到底替誰省了什麼。使用者不一定會說「你們的產品策略不一致」，但他們會很直接地說：「我找不到東西。」這句就夠致命了。

實操寫法：每個 surface 先定一個 primary job。這頁只做一件事，真的。想加 creation，就把它隔開；想強化 discovery，就別讓生成內容把版面塞滿；想做 automation，就先證明它不會亂動資料。只因為公司想講 AI 故事而存在的功能，該砍就砍。

可抄的模板

# Discovery-first AI feature checklist

## 1) 這個 AI 先解哪個問題？
- [ ] 找內容更快
- [ ] 降低選擇成本
- [ ] 幫使用者創作更多內容
- [ ] 自動整理資訊
- [ ] 其他：__________

## 2) AI 是在減少雜訊，還是在增加輸出？
- 減少雜訊：yes / no
- 增加輸出：yes / no
- 如果輸出增加，curation 怎麼做？

## 3) 這個功能的主要 surface 是哪裡？
- 主 app
- 獨立 workspace
- 實驗頁面
- 背景自動化

## 4) 上線前一定要成立什麼？
- AI 生成內容要清楚標示
- 有來源可追溯
- 錯誤回答能回復
- 有手動 override / filter
- 行為有 audit trail

## 5) 我們要量什麼？
- 找到正確項目的時間
- 任務完成率
- 重複使用率
- 品質訊號
- 抱怨 clutter / confusion 的比例

## 6) 我們不做什麼？
- 不為了有 AI 而加 AI
- 不把核心導航藏進聊天框
- 不在沒有 ranking / moderation 前先做 generation
- 不讓使用者替模型擦屁股

## 7) Launch 前最後確認
- [ ] 這個功能能用一句話講清楚
- [ ] UI 一眼看得出 AI 在做什麼
- [ ] 使用者可以關掉或縮小範圍
- [ ] 沒有 AI 這層，產品還能運作
- [ ] 我們說得出為什麼它該在主產品裡

這份模板就是我會直接丟給產品、設計、工程一起看的版本。它逼你先回答難題，再讓 demo 上場，不然很容易做出 feature theater。Spotify 這篇分析，原始報導來自 Ivan Mehta 的 TechCrunch 文章；我上面拆的是我的產品判讀跟可直接套用的決策框架。

來源：TechCrunch by Ivan Mehta。Spotify、ChatGPT、Gemini 這些名字我都有對照原文脈絡來講，原創部分是我對 discovery-first 產品設計的拆解與模板整理。