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

🧑‍🏫 這段是 Lovable 的分享。Lovable 是讓不會寫程式的人，用聊天的方式做出網站和 app 的平台。這段講它怎麼從一個 GitHub 專案，長成有 5,000 萬個專案的規模。後半段點出重點：AI 能很快做出第一版，但使用者「卡住」才是最痛的地方，也是整場要解決的問題。

• 00:18 講者這場要談 Lovable，以及平台如何 self-heal（自我修復）。
  ↳ 這場的主角是 Lovable，主題是 self-heal（自我修復），也就是平台遇到問題時能自己修好。這段先鋪背景，還沒講到具體怎麼修。
• 00:18 Lovable 的 UI 很簡單：左邊是聊天區，用來向 Lovable 提出需求；右邊是預覽畫面。
  ↳ 畫面分成左右兩半。左邊像傳訊息，你打字說想要什麼；右邊直接顯示做出來的樣子。整個過程不用看程式碼，只看結果。
• 00:51 Lovable 是讓人打造軟體的地方，從 landing page、內部工具，到較複雜的網站與 web application 都能做。
  ↳ Lovable 是做軟體的工具。小到 landing page（介紹產品或活動的單頁網站），大到公司內部工具、完整的 web application（在瀏覽器裡用的應用程式）都能做。
• 00:51 使用者類型很廣：有小孩在用，也有 Fortune 500 企業的人在用，工具非常有彈性，也非常容易上手。
  ↳ 從小孩到 Fortune 500（美國《財星》雜誌評選的五百大企業）的員工都在用。意思是門檻低到小孩也能上手，彈性又大到大企業用得上。
• 01:25 從創立至今 UI 幾乎沒變，但背後的能力和驅動它的模型已經大幅改變。
  ↳ 外觀一直是「左邊聊天、右邊預覽」，但背後的 AI 模型和能力已經進步很多。介面看起來一樣，能做到的事卻差很多。
• 01:25 35 個月前，共同創辦人 Anton 建立了 GitHub repository「GPT-Engineer」，一度是成長最快的 repo（在最短時間內拿到最多 stars）。
  ↳ GitHub 是工程師放程式碼、分享專案的網站，repository（repo）就是一個專案的存放空間，stars 類似按讚收藏。GPT-Engineer 當時用最短時間拿到最多星，是 Lovable 的起點。
• 02:01 GPT-Engineer 爆紅是因為它是最早展示「用模型端到端打造軟體」的例子之一（講者說可能是第一個）。它是 terminal 程式，demo 是要求做一個 snake game，它會自己產生檔案並把程式跑起來。
  ↳ 它紅在最早證明「AI 能從頭到尾自己做出能跑的程式」。terminal 是用打指令操作電腦的文字視窗。叫它做貪食蛇遊戲，它會自己產生檔案，把遊戲跑起來。
• 02:31 當時主要是開發者在用 AI 做程式碼生成，目的是在現有工作流程裡提升效率；2023 年夏天，主流用法是在 IDE 裡做 code complete。
  ↳ 當時用 AI 寫程式的主要是工程師，目的是讓原本的工作更快。IDE 是工程師寫程式用的軟體；code complete 是你打一半，AI 幫你補完，像輸入法的選字建議。
• 03:02 Lovable 想做不一樣的事：做給完全不會寫程式的人。這群人他們稱為「the 99%」，相對於會寫程式的 1%。
  ↳ Lovable 反過來，鎖定完全不會寫程式的人，稱為「the 99%」。意思是會寫程式的人只佔約 1%，他們想服務的是另外那一大群人。
• 03:35 一開始行不通，時機太早、模型還不夠成熟，撐不起「聊天＋預覽、只看產出結果」這種抽象層。講者認為大約一年半前才開始合理。
  ↳ 一開始做不起來，因為 AI 還不夠強，撐不起「只聊天、看結果、不碰程式碼」的做法。這種把底層細節藏起來的操作層叫 abstraction layer（抽象層）。講者認為約一年半前才開始可行。
• 03:35 從那之後，大約每三個月基礎模型就會進步一次，讓他們的用例變得更合理。
  ↳ 之後，基礎模型（像 ChatGPT、Claude 這類通用 AI 大模型）大約每三個月進步一次。每進步一次，「讓不會寫程式的人做軟體」這件事就更做得到。
• 04:44 講者詢問內部的 AI agent 才發現：使用者最大的族群是 founders，但如果按職能分類，自認是 engineers 的人最多。這並不是平台當初設計的目標客群。
  ↳ 講者用公司內部的 AI agent（能自己查資料、跑任務的 AI 助手）分析用戶。結果創業者最多；但按職業分，自稱工程師的人最多。這不是他們原本設定的客群。
• 05:15 講者認為，在這個抽象層工作、不需要時可以不碰程式碼，其實很不錯。
  ↳ 講者覺得這種方式對工程師也很好：平常只用聊天和預覽工作，需要時才打開程式碼，不需要就完全不碰。
• 05:55 原則一：打造 production-grade 軟體，追逐可能性的前沿。他們原本可以只做 prototyping，但選擇持續在複雜度、規模和野心上推進使用者能做到的程度。
  ↳ prototyping 是先做樣品驗證想法；production-grade 是能正式上線、給真人長期用的品質。Lovable 本來可以只做樣品，卻選擇讓使用者做出更複雜、更大規模的真產品。
• 06:32 原則二：同時要服務非技術使用者，這讓工作更難。如果有專家能和 AI 一起在 loop 裡，事情會比較容易；但這類用例的需求非常大，而且越來越大。
  ↳ 同時還要讓不懂技術的人用得順，這更難。如果旁邊有工程師一起盯著 AI，出錯時有人能判斷；但沒有專家在旁邊的人才是多數，需求還越來越大。
• 07:03 講者引用一句 1900 年代後期的名言：最後 10% 的程式碼要花 90% 的時間，而前 90% 也要花 90%，加起來是 180%。講者說在 AI 時代這依然成立。
  ↳ 這是軟體圈的老笑話：前 90% 花掉 90% 的時間，剩下的 10% 又要再花 90%，加起來 180%。意思是收尾永遠比想像中久，講者說有了 AI 還是一樣。
• 07:35 用 vibe coding 工具、讓 AI 包辦時，很快就能做出第一版，但收尾、確保沒有 bug 反而更花時間。手寫程式時代有這個模式，用 AI 時也一樣，甚至更明顯。
  ↳ vibe coding 是跟 AI 描述需求、讓它包辦寫程式。第一版很快就出來，但要修掉 bug（程式錯誤）、做到真的能用，反而最花時間。用 AI 時這個落差甚至更明顯。
• 08:05 開發過程可以畫成時間軸：一開始在綠區（摩擦少）→ 遇到 bug 等摩擦 → 繼續做 → 可能進入紅區，也就是卡住。
  ↳ 把做軟體想成一條時間線：一開始很順（綠區），接著碰到 bug 開始卡卡的，繼續做下去，可能掉進紅區，也就是完全卡住、不知道怎麼往下。
• 08:05 講者分享自己的經驗：熬夜卡在問題上，可能解不出來，睡一覺隔天再多花些功夫和思考才解決。軟體工程師對這很習慣。
  ↳ 講者自己也常熬夜卡關，當下解不出來，睡一覺隔天再多花點心思才解決。對工程師來說這是家常便飯，大家都習慣了。
• 08:38 非技術使用者在 Lovable 這種不一定看程式碼的抽象層上卡住，情況更糟。開發者可以透過 GitHub 連結深入底層，但很多使用者沒有這種經驗，或根本沒興趣。
  ↳ 不會寫程式的人卡住更慘。工程師可以把專案接到 GitHub，直接看底層程式碼找問題；但很多使用者沒這個經驗，也根本不想碰程式碼。
• 09:09 對這些使用者來說，卡住是最糟的體驗，因為更難脫困。他們可能會找人幫忙、去學寫程式，或試著用 prompt 繞過去；成功了還好，失敗就是最糟的使用體驗。
  ↳ 對他們來說卡住最糟，因為很難自己脫身。只能找人幫忙、去學寫程式，或換說法叫 AI 再試（prompt 就是你打給 AI 的指令）。試成功還好，失敗就是最糟的體驗。
• 09:39 Lovable 在技術面的願景：平台上每個被建立的 app，都應該幫助改善下一個 app。講者今天會舉兩個例子說明做法。
  ↳ 他們的技術目標是：平台上每個做出來的 app，都能幫下一個 app 做得更好。講者接下來會用兩個例子說明怎麼做到。
• 10:10 在舉例之前，講者先定義「卡住」：他們內部有一個叫 is_stuck 的指標。
  ↳ 要解決卡住，得先量得出「卡住」。他們內部有個叫 is_stuck 的指標，用來判斷使用者是不是卡住了。具體怎麼判斷，這段還沒講。

根據講者的說法，用 Lovable 建立的網站每月總造訪量大約是多少？