Lovable 如何大規模用 vibecode 打造可上線的正式軟體（第 3/3 段）

🧑‍🏫 Lovable 是一個用聊天就能做出網站和 App 的平台，這種做法叫 vibecoding：用口語描述需求，讓 AI 寫程式。這一段講他們怎麼讓 agent（能自己動手完成任務的 AI 助手）卡關時主動回報問題，再搭配知識庫，讓平台自己修好自己。值得看的地方是：AI 不只幫忙做事，還能幫忙抓出整個系統的毛病。

• 20:47 agent 發出 vent 後，系統會篩選並調查發生了什麼事；如果相關，就會開一個 PR，交給工程師審查，可能會合併
  ↳ vent 是 agent 卡關時用來求救的工具。系統收到後會先過濾、查清楚原因。問題確實相關，就開 PR（提議的程式修改，要人審過才會併入），交給工程師決定要不要採用。
• 20:47 工程師早上醒來就有幾個 PR 要審，大約 50% 的 PR 是合理的
  ↳ 等於 agent 趁晚上找好問題、寫好修法，工程師早上只要審。大約一半的提案合理可用，工程師的工作從「自己找問題」變成「挑出能用的修正」。
• 21:17 例子：code-copy tool。使用者上傳的截圖檔名有空白，這個工具碰到含特殊字元的檔案就壞掉，正常情況下 agent 自己修不好
  ↳ 使用者上傳的截圖檔名有空白，負責複製檔案的 code-copy tool 一碰到這種特殊字元就出錯。毛病出在工具本身，agent 自己想辦法也繞不過去。
• 21:48 agent 試過 URL encoding 等方法都失敗，於是選擇 vent，向它的「創造者」求救，並建立 PR；確認真的是 bug，收到 vent 後 10 分鐘就有合併的 PR 上 production
  ↳ agent 先試過 URL encoding（把空白這類字元轉成 %20 之類的代碼），還是失敗，就改用 vent 回報。確認是 bug 後，10 分鐘內修正就上了 production（使用者實際在用的正式環境）。
• 22:18 平台上一些小問題就可能讓使用者卡住，而 agent 很擅長把這類問題描述清楚
  ↳ 對使用者來說，一個小 bug 就可能讓作品做不下去。agent 本來就在現場碰到錯誤，很擅長把「發生什麼事」講清楚，讓工程師看得懂。
• 22:18 例子：Framer Motion（做動畫的 TypeScript 函式庫）。agent 抱怨它的型別：建立曲線時應該可以直接放數字陣列，不必管它的 easing type
  ↳ Framer Motion 是做網頁動畫的 TypeScript（多了型別檢查的 JavaScript）函式庫。agent 嫌它規定太囉嗦：畫動畫曲線時，給一串數字就該夠了，不該還得處理 easing type。
• 22:48 講者說 Framer Motion 也許有理由，但 agent 也可能有道理；目前不允許 agent 這麼做，但考慮讓它像貢獻自家程式碼一樣貢獻 open source 函式庫，順便 self-heal JavaScript 生態系
  ↳ 講者沒說誰對。目前 agent 只能改 Lovable 自己的程式，但他們在考慮讓它也去改 open source（公開、人人可參與的程式碼），讓整個 JavaScript 生態系一起變好。
• 23:19 這種做法不只限於自家平台，也能用在 tech stack 和任何 open source 函式庫
  ↳ 意思是這招可以往外延伸：不只修自家平台，也能修他們用的 tech stack（整套技術工具組合），以及任何開源函式庫。
• 23:19 意外發現：每小時的 vent tool 呼叫次數圖上出現三個尖峰，對應 production incidents，例如 inferencing 掛掉、缺 sandbox、甚至網路層級故障
  ↳ 每小時的 vent 次數畫成圖，出現三個尖峰，剛好對上平台大故障：inferencing（AI 模型實際運算、產生回答）停擺、sandbox（隔離執行程式的環境）不夠用，甚至網路層出問題。
• 24:20 他們本來就有監控 metrics、會 page 工程師的系統，但 agent 在 Slack 頻道 vent 已經好幾次成為發現 production incident 的第一個訊號
  ↳ 他們本來就有監控系統在盯數據，出事會 page（自動通知值班工程師）。但已經好幾次，最早透露出事的反而是 agent 在 Slack（團隊聊天工具）頻道裡的抱怨。
• 24:50 就算不是第一個訊號，平台出問題時看看 agent 遇到了什麼，也能幫工程師 debug
  ↳ 就算監控先響了，翻一下 agent 的 vent 紀錄，也能看到它當下實際碰到什麼錯，幫工程師更快找到原因。
• 25:20 meta 例子：agent vent 太多次，這個例子中觸發約 43 次，在 Slack 上洗版；結果反而是 agent 給他們回饋：要考慮平行對話、平行工作時這個工具怎麼運作
  ↳ 有一次 agent vent 了約 43 次，把 Slack 洗版了。有趣的是，指出問題的也是 agent：同時開好幾個對話、平行工作時，這個工具要怎麼運作得重新想過。
• 25:51 agent 提議加一個 dedupe safeguard，避免送出大量重複回報，並建立 PR；審查後合併上 production
  ↳ agent 提議加一道 dedupe safeguard（過濾重複的保護機制），同樣的問題不要狂報，還自己寫好 PR，工程師審過就上線。等於工具被用它的 agent 修好了。
• 26:24 心得一：從失敗模式學到的東西跟所用的模型高度相關；新模型推出時，Level Overflow（字幕原文）裡的知識要重新調整成適合新模型的 prompt 方式，或是已經包含在新模型的訓練資料裡、不再需要
  ↳ Level Overflow 是他們的知識庫，記錄 agent 常犯的錯和對策。這些教訓跟用哪個模型綁很緊：換新模型時，有些要改寫提示方式，有些新模型已經學會、用不到了。
• 26:59 不再需要的知識要從 corpus 裡修剪掉；嚴格修剪知識是這套系統能運作的關鍵之一
  ↳ corpus 指這批知識的整體收藏。用不到的要 prune（修剪、刪掉）。他們強調，嚴格刪減是這套系統能運作的關鍵之一。
• 26:59 知識有半衰期：例如 Framer Motion 如果改了型別，之前根據它整理的知識就會失效
  ↳ half-life（半衰期）是說知識會過期。例如 Framer Motion 哪天改了型別，之前針對它整理的注意事項就不準了，得跟著更新或刪掉。
• 27:30 資訊和套件太多、可能出錯的地方也太多，人類不可能一一最佳化，所以系統必須能 self-heal
  ↳ 要顧的套件和資訊多到數不完，每個都可能出錯，人力不可能一個個優化。所以系統必須 self-heal（自己發現問題、自己修好）。
• 27:30 心得二：系統必須持續調整。他們早先試過這個點子但失敗了，原因是沒有好好調整系統；沒有判斷有效與否的好訊號，就很難在大規模下運作
  ↳ 他們以前試過同樣的點子但失敗，原因是沒有持續調整系統。沒有好的訊號告訴你改了到底有沒有用，規模一大就做不起來。
• 28:00 規模：目前約 50 million 個 app，每天 200,000 個新 app、每天數百萬則訊息，這些都能拿來調整系統
  ↳ Lovable 目前約有 5,000 萬個 app，每天新增 20 萬個，每天有幾百萬則訊息。這麼大量的使用資料，都能拿來判斷調整有沒有效。
• 28:31 成果：stack rate（字幕原文）下降 5%，跟平台換上新一代 foundational model 時這個指標的變動屬於同一個量級
  ↳ stack rate 下降 5%（照字幕原文，影片沒細講定義，從脈絡看是越低越好）。這個改善幅度，跟平台換上新一代 foundational model（底層的大型 AI 模型）差不多。
• 28:31 publish rate 上升 2%；這是從沒有 Level Overflow 到第一版的數字，之後還有持續小幅改進
  ↳ publish rate（作品發布出去的比例）上升 2%。這是從完全沒有 Level Overflow 到推出第一版的差距，之後還陸續有小幅進步。
• 29:03 publish rate 很重要：可以推斷使用者對自己做的東西滿意、想分享給別人
  ↳ 使用者願意發布，通常代表對自己的作品滿意、想給別人看。所以他們把這個數字當成衡量成果的重要指標。
• 29:03 venting tool 建議的 PR 中，每天約有 10 個修正被合併上 production
  ↳ venting tool 提出的 PR，每天大約有 10 個修正真的合併上線。也就是 agent 每天都實際在幫忙修平台。
• 29:36 沒被合併的 PR 會被聚類整理，從中取得學習，作為未來開發的參考
  ↳ 沒被採用的 PR 也不浪費：他們把類似的歸成一群，看哪些問題反覆出現，當作以後開發的參考。
• 29:36 有時 production incidents 甚至比他們的 paging 系統更早浮現
  ↳ 再強調一次：有時候平台出故障，agent 的 vent 比正式的 paging 告警系統還早浮現。
• 30:06 總結：這兩個例子都是讓平台 self-heal、充分發揮模型能力的方法；他們也用 fleet data 做 fine tuning，並有相當廣泛的 evals coverage
  ↳ 兩個例子都是讓平台自我修復、把模型能力用到最好。他們也用 fleet data（平台上累積的使用資料）做 fine tuning（再訓練模型），並用大量 evals（測模型表現的測試）把關。
• 30:06 使用者帶著強烈意圖來打造成功的產品甚至公司，會一直 prompt 到成功，或是平台讓他們失敗；把這當成 world model 來最佳化，是他們正在做的方向
  ↳ 使用者是真心想做出成功的產品甚至公司，會一直下指令直到成功，不然就是平台讓他們失敗。他們把這段過程當成 world model（預測「這樣做會有什麼結果」的模型）來優化。
• 30:36 正在招募，網址為 love.dev/careers（字幕原文 love.dev slash careers）
  ↳ Lovable 正在徵人，網址照字幕是 love.dev/careers，實際網址建議自己查證。

在 code-copy tool 無法處理含空白檔名的例子中，agent 發出 vent 之後，多久就有合併的 PR 上 production？