使用者不滿意卻不回報怎麼辦？挫折飛輪讓產品自動變好
使用者不會告訴你哪裡不好，但 log 會。每天一句 prompt、3 分鐘看排行榜，30 天修了 110 個問題。這篇講怎麼做。
梵谷《搖搖籃的女人》（La Berceuse），1889 年。油彩、畫布。梵谷以鮮豔的色彩平面描繪友人奧古斯汀·魯蘭夫人手持搖籃繩索的姿態，是他在亞爾期間的系列肖像之一。現藏於紐約大都會藝術博物館。
你的使用者在哪裡跌倒？他們不會告訴你
你有沒有想過：為什麼「回報問題」按鈕幾乎沒人按？
不是因為你的產品完美。是因為使用者碰到問題時，第一反應是怪自己：「大概是我不太會用」「可能是我 prompt 下得不好」。他們不會按回報按鈕，他們會安靜地離開。
一個團隊找到了解法：不等使用者開口，從 log 裡主動偵測不滿。30 天內找到並修了 110 個問題，沒有一個是使用者回報的。
他們叫這套方法挫折飛輪（Frustration Flywheel）。
挫折飛輪怎麼運作
一句 prompt 就能啟動：
「請你掃描過去兩天的所有日誌，做出 top10 的使用者不滿的排行榜」
就這樣。沒有複雜架構，沒有自研模型。
三個關鍵數字
| 數字 | 意義 |
|---|---|
| 5 條 | 監控規則的上限。超過 5 條就無法 debug |
| 3 分鐘 | 每天看排行榜的時間。挑 60% 來修，40% 太 minor 不動 |
| 10% | 誤判率。但誤判被修了也不會造成傷害 |
我的追問與發現
「只有挫折飛輪夠嗎？」
不夠。需要兩個飛輪一起轉：
- 行銷飛輪：拉人進來（寫文章、做影片、進客戶面前宣傳）
- 挫折飛輪：留住人（偵測不滿、修復問題）
只有行銷 = 漏水的桶子。只有挫折飛輪 = 沒人可以留。
「沒有 log 怎麼冷啟動？」
從最近 3 次重度使用的 session 開始逆推。只要有人在用，問題就會浮出來。關鍵不是資料量，是有沒有人在用。
「自動偵測到的問題可以讓 AI 直接修嗎？」
程式碼 bug 可以。內容不行。 內容的修正必須經過人的判斷 — AI 提案，人核准。因為 10% 的誤判在偵測階段無害，但如果自動改了內容，就可能把對的改成錯的。
你可以怎麼用
不需要大型系統。最小啟動版：
- 有 log 嗎？ 如果你的服務有任何形式的使用紀錄（對話紀錄、搜尋紀錄、點擊紀錄），你就有飛輪的燃料
- 每天一句 prompt — 叫 AI 掃描 log，列出 top10 不滿
- 每天 3 分鐘 — 看排行榜，挑出要處理的
- 每週回顧 — 哪些問題反覆出現？是不是該加一則 QA、改一段流程、或修一個 bug？
延伸連結
想了解怎麼設計使用者回饋介面？→ 什麼是誠實的介面設計？ 想了解怎麼建知識庫接住這些問題？→ 怎麼設計零伺服器的 QA 系統？
一句話帶走
每個地雷背後是 20 個沉默的使用者。挫折飛輪不是高深技術，是一個紀律：每天花 3 分鐘，看你的使用者在哪裡跌倒。
📚 完整學習對話紀錄（想看完整脈絡可展開）
背景：一段團隊會議的啟發
前陣子參加了一場團隊會議，有位同事分享了他們怎麼打造一套自動化的「不滿偵測系統」。這套系統在 30 天內找到並修復了 110 個 bug — 沒有一個是使用者回報的，全部都是從 log 裡自動偵測出來的。
我聽完覺得這套思路太有價值了，回來後請 Claude 幫我分析、萃取背後的原則。以下就是我的提問和整理。
核心概念：挫折飛輪（Frustration Flywheel）
整個機制的核心是一個循環：
AI 每天掃描 log → 產生 top10 不滿排行榜
→ 人花 3 分鐘看一遍 → 挑出要修的
→ AI 修復 → 隔天排行榜更新 → 循環繼續這個飛輪一旦轉起來，產品會自動越來越好，因為每天都在把使用者最痛的問題往前推。
我的提問：為什麼使用者不回報問題？
這是我聽完後的第一個疑問。我們的產品不是有「回報問題」的按鈕嗎？為什麼 110 個 bug 沒有一個是使用者主動講的？
關鍵洞察：使用者覺得是自己的錯
會議中有一句話讓我印象非常深刻：
「使用者會覺得是自己不太會用，不太會下 prompt，就算了，他不會回報的。」
這就是為什麼傳統的「回報問題」按鈕幾乎沒用。使用者碰到問題時，第一反應不是「這個產品有 bug」，而是「我是不是哪裡操作錯了」。他們怪自己，不怪產品。所以他們不會按那個按鈕，他們會默默離開。
這代表什麼？代表你必須主動從 log 中偵測，而不是等使用者告訴你。
我又追問：具體怎麼做？
知道「要主動偵測」是一回事，但具體怎麼做？我追問了實作細節。
實作方式：一句 prompt + 5 條規則
整套偵測系統的核心，就是一句 prompt：
「請你掃描過去兩天的所有日誌，做出 top10 的使用者不滿的排行榜」
就這樣。沒有複雜的架構，沒有自研的 ML 模型，一句 prompt 就啟動了。
監控規則的原則：最多 5 條。超過 5 條就無法 debug，規則之間會互相干擾，出問題的時候你根本不知道是哪條規則造成的。
人每天看一次排行榜，花大約 3 分鐘。挑出大約 60% 來修。剩下 40% 是太細微的問題 — 修了反而增加系統複雜度，收益卻很小。
誤判率大約 10%。但重點是：誤判被修了也不會造成傷害。這個特性讓整個系統可以大膽運作。
我又追問：挫折飛輪和行銷飛輪的關係？
光有挫折飛輪夠嗎？還是需要搭配什麼？
兩個飛輪必須並存
行銷飛輪：拉人進來（寫文章、做影片、進客戶面前宣傳）
挫折飛輪：留住人（偵測不滿、修復問題、改善體驗）只有行銷飛輪 = 漏水的桶子。你拼命灌水進來，但水從破洞流出去。
只有挫折飛輪 = 沒有人可以留。產品體驗再好，沒人來用也沒意義。
兩個飛輪必須同時轉。行銷飛輪負責進水，挫折飛輪負責補洞。
我又追問：這些原則哪些可以直接用？
會議裡聊了很多東西，但不是每一條都適合我現在的狀況。我請 Claude 幫我分成三類：可以直接用的、需要再討論的、用之前必須修正的。
三位專家的分析
可以直接用
- 每天一句 prompt → top10 排行榜 → 3 分鐘人工審查：這是核心迴圈，零成本就能啟動。
- 監控規則最多 5 條：超過 5 條就 debug 不了，這個限制簡單粗暴但有效。
- 行銷飛輪 + 挫折飛輪並行：拉新和留存不能分開做。
- 使用者不會回報 → 必須主動偵測：這是整個思路的前提，忘記這個前提就會回到老路。
需要再討論（先存起來）
- BM25 + WASM 做客戶端搜尋：概念有趣，但我現在的規模用簡單的 JS 搜尋就夠了，等到搜尋需求明確再評估。
- 多知識庫路由：等 QA 累積到 200 條以上再來考慮。現在知識庫還小，一個就夠。
- AI 在客戶端環境內處理：對小型客戶來說，去識別化的做法比較實際，不需要在地端跑 AI。
用之前必須修正
- 「全部自動修」→ 改成「AI 提案，人核准」：程式碼自動修沒問題，但內容不行。內容的修正必須經過人的判斷，因為上下文和語氣只有人能把關。
- 「10% 誤判無所謂」→ 偵測可以，自動修內容不行：誤判在偵測階段無害，但如果自動把誤判的「問題」修進內容裡，就會造成真正的錯誤。
- 「Claude 有 5 層原始碼保護」→ 這是民間簡化說法：實際的安全機制是 pretraining + Constitutional AI + interpretability + principal hierarchy + red-teaming，不能用「5 層保護」這種口語化說法去理解 AI 安全。
冷啟動問題
沒有 log 就沒有不滿資料，飛輪轉不起來怎麼辦？
解法：從最近 3 次重度使用的 session 開始。不需要等到大量數據累積，只要有人在用系統，問題就會浮出來。關鍵不是數據量，而是有沒有人在用。有使用就有摩擦，有摩擦就有 log，有 log 就能偵測。
我學到的
最深刻的一句話：
「每個地雷背後是 20 個沉默的使用者。」
挫折飛輪不是什麼高深技術，它只是一個紀律：每天花 3 分鐘，看你的使用者在哪裡跌倒。
技術門檻幾乎是零 — 一句 prompt、一份 log、一個人願意每天看 3 分鐘。但大多數團隊不做，因為他們在等使用者開口。而使用者永遠不會開口，他們只會安靜地離開。
這讓我重新思考自己的產品開發方式：與其花時間設計精美的「意見回饋」表單，不如花同樣的時間去讀 log。答案一直都在那裡，只是沒人去看。