Lovable 如何大規模用 vibecode 打造可上線的正式軟體（第 2/3 段）
🏦 台灣Pay 銀行轉帳 💙 PayPal
Lovable 如何判斷使用者卡住、把卡住分成三類，並用 Lovable Overflow 和 vent 工具來處理
- 10:25 判斷使用者「卡住」的訊號之一：同一件事連續要求三次，例如一直說 fix it、fix it、fix it
- 15:37 搜尋時會參考使用者的技術堆疊和函式庫；知識範圍從廣泛的建議，到特定套件版本的具體問題都有
- 20:42 在人看之前，會先有另一個 agent 監看這個 Slack
💡 你可以怎麼用：用 AI 工具時，如果同一個問題講了三次「修好它」還是沒好，就別再重複同一句。可以換個說法、補上具體背景（哪個畫面、你做了什麼、看到什麼結果），或把問題拆小一點再問。如果連事情很簡單都一直做不到，很可能是工具本身做不到，這時可以回報給平台，或改用別的方法。
看全部 36 條重點
🧑🏫 Lovable 是一個用聊天叫 AI 幫你做網站和 App 的平台。這段講他們怎麼發現使用者「卡住」，把卡住分成三種，再用兩招處理：一招是整理大家遇過的問題和解法，讓 AI 查；另一招是讓 AI 自己回報「這工具害我做不好」。平常用 AI 工具的人看完，會比較懂 AI 為什麼常在原地打轉，也知道平台那邊怎麼補。
- 10:25 判斷使用者「卡住」的訊號之一：同一件事連續要求三次，例如一直說 fix it、fix it、fix it↳ 同一件事連講三次，例如一直打 fix it（修好它），表示 AI 改了好幾輪都沒改對，使用者已經在原地打轉。
- 10:25 判斷卡住的訊號之二：使用者抱怨 Lovable 做出來的實作，例如說「這沒成功」↳ 使用者直接抱怨「這沒成功」，就是明講 AI 做出來的東西不能用，這也算卡住。
- 10:25 判斷卡住的訊號之三：使用者提出要求後就直接離開↳ 送出要求後人就走了、沒再回來，很可能覺得沒救、放棄了，這也被當成卡住。
- 10:56 Lovable 用一個小型分類模型（classification model）判斷使用者是否卡住↳ 他們用一個小型分類模型（classification model，專門把東西歸類的 AI），在這裡只負責判斷使用者「有沒有卡住」。
- 10:56 第一類卡住：換個方式寫 prompt 就能解決，追問 fix it 或多補一些 context，問題也可能自己解掉↳ 第一類：換個說法下指令（prompt，你打給 AI 的那段話），或多給一些背景資料（context，AI 做事時參考的資訊），常常就解開了。
- 11:26 第一類又叫「黃色卡住」，代表還沒完全卡死；平台要問的是：使用者怎麼會卡在這裡、能不能修掉↳ 這類叫「黃色卡住」（yellow stuck），就像黃燈，還沒走到死路。平台要檢討的是：使用者為什麼會走到這一步？能不能從源頭修掉？
- 11:26 第二類卡住：這件事 agent 照理說很容易做到，但平台目前不支援↳ 第二類：這件事對 agent（會自己動手完成任務的 AI）來說本來不難，只是平台目前沒有提供這個功能，所以做不到。
- 11:26 面對第二類，平台要問的是：怎麼持續改進，甚至在自身功能的邊界「自我修復」（self-heal）↳ 遇到第二類，平台要想辦法一直補強，最好在功能不夠的地方能自己發現、自己補上，這叫自我修復（self-heal）。
- 11:59 因為大家是用 LLM 在開發，能做的事太多，平台幾乎不可能想到所有情況，所以需要一套系統來補平台做不到的地方↳ 大家是用大型語言模型（LLM，像 ChatGPT、Claude 這類 AI）在開發，想做的事五花八門，平台不可能全部事先想到，所以需要一套機制自動補洞。
- 11:59 第三類卡住：同樣是平台做不到，但要補起來得投入比較大的資源↳ 第三類：一樣是平台做不到，但要補起來得花很多人力和時間，不是小修小補就能解決。
- 12:30 第三類的例子：Lovable 長期只做 client-side rendering 的 single-page application，大多數情況夠用↳ 例子：Lovable 長期只做單頁式應用（SPA，整個網站只有一頁，靠程式切換內容），畫面在使用者的瀏覽器裡產生（client-side rendering），大多數時候夠用。
- 12:30 很在意 SEO 的話，一般最佳做法是 server-side rendering，讓 Google 等搜尋引擎不用自己渲染也能看到內容；Lovable 上週剛推出這項功能↳ 如果很在意 SEO（讓網站容易被 Google 搜到），通常會先在伺服器把頁面做好再送出（server-side rendering），搜尋引擎就看得到內容。Lovable 上週才推出這個功能。
- 13:01 解法一：Lovable Overflow，名稱是在向 Stack Overflow 致敬，內容是大量「問題描述＋對應解法」的集合↳ 解法一叫 Lovable Overflow，名字來自工程師常用的問答網站 Stack Overflow。內容是大量「遇到什麼問題、怎麼解決」的整理。
- 13:35 沒有 Lovable Overflow 時的例子：使用者說捲動很卡，agent 回報已移除動畫、修好了，實際上卻沒修好↳ 還沒有它的時候：使用者說捲動很卡，AI 回「已經拿掉動畫，修好了」，其實根本沒好。AI 以為自己解決了，問題還在。
- 14:05 使用者回報還是卡、畫面看起來壞掉，這時就算卡住了；最糟的是這種來回可能重複好幾輪↳ 使用者再回報「還是卡，畫面也壞了」，這時就確定卡住了。最糟的是「說修好了、其實沒好」可能來回好幾輪。
- 14:36 問題解決後，使用者通常會接著做下一件事或給出明確回饋，平台據此判斷使用者已經不卡了，但過程中有摩擦↳ 真的修好之後，使用者通常會去做下一件事，或明確說 OK，平台就知道他不卡了。但前面那幾輪來回，對使用者來說很煩。
- 14:36 Lovable 想解決的問題：能不能直接跳到最終解法？↳ 所以 Lovable 在想：反正最後總會找到解法，能不能一開始就直接給出那個最終解法，省掉中間繞的路？
- 15:06 有了 Lovable Overflow 後，平台會在語料庫裡搜尋，看其他人是否遇過同樣的問題（例如捲動卡頓）↳ 有了 Lovable Overflow，遇到像捲動卡頓這種問題，系統會先去資料庫查：以前有沒有別人遇過一樣的狀況？當時怎麼解的？
- 15:37 搜尋時會參考使用者的技術堆疊和函式庫；知識範圍從廣泛的建議，到特定套件版本的具體問題都有↳ 查的時候會對照這個專案用了哪些技術（技術堆疊）和現成的程式套件（函式庫）。資料有一般性的建議，也有「某個套件某一版的特定問題」這種細節。
- 15:37 判斷相關時，由一個輕量模型把這些 context 加進主 agent↳ 判斷查到的資料有用時，會由一個小而快的輕量模型，把它加進 main agent（實際幫使用者寫程式的主要 AI）的 context 裡。
- 16:07 不會直接把原始知識原封不動丟進去，而是依使用者當下的情境改寫，讓主 agent 的工作盡量輕鬆↳ 不會把原文整段貼過去，而是先改寫成符合這位使用者當下情況的內容，讓主 agent 拿到就能用，不必再自己消化。
- 16:07 有時會刻意不加入知識，因為知識可能過時，例如某個 JavaScript 套件已經更新，舊知識反而讓體驗變差↳ 有時會故意不給資料，因為知識會過時（stale knowledge）。例如某個 JavaScript（網頁常用的程式語言）套件改版了，照舊方法做反而更糟。
- 16:38 每個知識檔都會追蹤成功率，過時的會移除（prune），系統內每筆知識都持續檢視↳ 每筆知識都會記錄用了之後的成功率（success ratio）。效果差或過時的就刪掉（prune，像修剪枝葉），整個資料庫一直在檢查。
- 17:09 同時也持續補進新知識；調校「何時淘汰、何時新增知識」極為重要，並用大量指標追蹤↳ 同時也一直加入新知識。什麼時候該刪、什麼時候該加，拿捏得好不好非常關鍵，他們用很多數據指標在追蹤。
- 17:09 Lovable Overflow 處理的是第一類卡住，省掉來回的過程，能大幅改善使用者體驗↳ Lovable Overflow 對付的是第一類卡住：本來要來回好幾輪才試得出來的解法，現在一次就給對，使用者體驗好很多。
- 17:40 效果：更快、更便宜，體驗也好很多↳ 效果是：更快、更便宜，使用者也比較不會被弄得很煩。
- 17:40 解法二：內部稱為「venting」（發洩），針對第二類卡住：理論上很簡單，卻還是卡住，因而感到挫折↳ 解法二內部叫 venting（發洩），對付第二類：事情照理說很簡單，AI 卻因為平台的限制做不到，於是「感到挫折」。
- 18:11 人類開發者遇到這種情況，可以自己修、更新或換掉工具，或向 developer experience 團隊反映；Lovable agent 長期以來沒有這些管道↳ 人類工程師遇到難用的工具，可以自己修、換掉，或向 developer experience team（負責讓工程師工具好用的團隊）反映。Lovable 的 AI 以前沒有這種管道。
- 18:41 agent 每天被數百萬人要求做事，卡住了不是它的錯，卻沒人可以說，所以它需要發洩；就他們的經驗，這其實是很好的點子↳ AI 每天被幾百萬人叫去做事，卡住了不是它的錯，卻沒地方講，所以給它一個發洩的出口。他們實際用下來，覺得這招很有效。
- 18:41 講者把這比喻成讓同事抒發工作上的不滿，例如辦公室或 code base 有問題，而你會想把他們說的記下來↳ 講者的比喻是：同事抱怨辦公室哪裡不方便、程式碼哪裡很亂，你會想記下來，因為那些往往就是該改進的地方。
- 19:11 除了觀察 Lovable 哪裡出錯再去修之外，另一個做法是給 agent 一個工具，讓它說出自己什麼時候感到挫折↳ 除了由人去看 Lovable 哪裡出錯再來修，另一條路是給 AI 一個工具，讓它自己說出「我在這裡做得很挫折」。
- 19:42 這個工具叫 vent--send_feedback，prompt 寫著：當工具、文件或平台行為明顯拖慢或降低工作品質時使用，每則使用者訊息最多用一次↳ 這個工具叫 vent--send_feedback。給 AI 的使用說明寫著：工具、文件或平台明顯拖慢工作或拉低品質時才用，每則使用者訊息最多用一次。
- 19:42 工具 prompt 列出的情況：缺少工具或工具不合用；工具名稱、參數、schema 不清楚；文件或指示混亂、互相矛盾；平台行為壞掉或出乎預期↳ 說明裡列的情況：缺工具或工具不好用；工具名稱、參數、schema（規定資料格式的規格）看不懂；文件混亂或前後矛盾；平台行為壞掉或出乎意料。
- 20:12 還有一種情況是環境限制造成反覆失敗；換成人類開發者遇到這些事，也會想自己修，或告訴別人去修↳ 另外還有：環境的限制讓它一直失敗。這些事換成人類工程師遇到，也會想自己修，或請負責的人去修。
- 20:12 agent 感到挫折時呼叫這個工具，訊息會送到 Lovable 的 Slack↳ AI 覺得挫折時就呼叫這個工具，抱怨內容會送到 Lovable 的 Slack（公司內部用的聊天通訊軟體）。
- 20:42 在人看之前，會先有另一個 agent 監看這個 Slack↳ 在真人看之前，還有另一個 AI 先在這個 Slack 裡盯著這些回報。
📘 術語
classification model（分類模型）：Lovable 用一個小型分類模型判斷使用者是否卡住
yellow stuck（黃色卡住）：第一類卡住，換個 prompt 或補 context 就能解，還沒完全卡死
self-heal（自我修復）：平台在自身功能的邊界持續改進、補足不足之處
single-page application（單頁應用程式）：Lovable 過去長期產出的應用程式類型，採 client-side rendering
client-side rendering（用戶端渲染）：Lovable 過去的做法，大多數情況夠用
server-side rendering（伺服器端渲染）：在伺服器上渲染內容，讓 Google 等搜尋引擎不用自己渲染就能看到
SEO（搜尋引擎最佳化）：若很在意 SEO，一般最佳做法是用 server-side rendering
Lovable Overflow（Lovable Overflow）：向 Stack Overflow 致敬，大量收集問題描述和解法，並加進主 agent 的 context
main agent（主 agent）：負責幫使用者開發的主要 agent，輕量模型會把相關知識加進它的 context
stale knowledge（過時的知識）：例如某個套件已更新，舊知識反而會讓體驗變差
success ratio（成功率）：每個知識檔都會追蹤成功率，用來判斷是否移除
prune（修剪／移除）：把已經過時、沒有幫助的知識從系統中移除
developer experience team（開發者體驗團隊）：人類開發者遇到工具問題時，可以去反映、提出建設性回饋的團隊
venting / vent--send_feedback（發洩／發洩回饋工具）：給 agent 的工具，工具、文件或平台拖累工作時用來回報，訊息會送到 Slack
schema（結構定義）：vent 工具的 prompt 提到，工具參數或 schema 不清楚時可以回報
yellow stuck（黃色卡住）：第一類卡住，換個 prompt 或補 context 就能解，還沒完全卡死
self-heal（自我修復）：平台在自身功能的邊界持續改進、補足不足之處
single-page application（單頁應用程式）：Lovable 過去長期產出的應用程式類型，採 client-side rendering
client-side rendering（用戶端渲染）：Lovable 過去的做法，大多數情況夠用
server-side rendering（伺服器端渲染）：在伺服器上渲染內容，讓 Google 等搜尋引擎不用自己渲染就能看到
SEO（搜尋引擎最佳化）：若很在意 SEO，一般最佳做法是用 server-side rendering
Lovable Overflow（Lovable Overflow）：向 Stack Overflow 致敬，大量收集問題描述和解法，並加進主 agent 的 context
main agent（主 agent）：負責幫使用者開發的主要 agent，輕量模型會把相關知識加進它的 context
stale knowledge（過時的知識）：例如某個套件已更新，舊知識反而會讓體驗變差
success ratio（成功率）：每個知識檔都會追蹤成功率，用來判斷是否移除
prune（修剪／移除）：把已經過時、沒有幫助的知識從系統中移除
developer experience team（開發者體驗團隊）：人類開發者遇到工具問題時，可以去反映、提出建設性回饋的團隊
venting / vent--send_feedback（發洩／發洩回饋工具）：給 agent 的工具，工具、文件或平台拖累工作時用來回報，訊息會送到 Slack
schema（結構定義）：vent 工具的 prompt 提到，工具參數或 schema 不清楚時可以回報
✏️ 小考一題
Lovable Overflow 會對每個知識檔追蹤哪一項指標，來決定是否把過時的知識移除？
A. 被搜尋的次數B. 使用者給的評分C. 知識檔的建立日期D. 成功率（success ratio）看答案
答案：D。[16:38] 講者說每個知識檔都會追蹤成功率，過時的就會從知識庫中移除（prune）
💛 覺得有幫助？支持一下
課本免費、沒有廣告，支持與否都能照常讀 🐰