⚖️
利益揭露：Y Build 是我們做的。所以我們公開了完整方法、原始計時和確切的提示詞 —— 你可以自己複現。這些數字，正是我們在相信任何廠商自家基準之前會想看到的東西。
這個實驗
「氛圍編程（vibe coding）」工具都承諾同一件事：描述一個應用，得到一個應用。但演示總是停在一個能跑的預覽上 —— 從不停在一個真正部署、帶資料庫、帶可以發給客戶的 URL 的產品上。所以我們做了那個無聊的版本。
我們拿一份規格，做了三遍 —— 分別用 Bolt.new、Lovable 和 Y Build —— 並用碼錶和螢幕錄影記錄了一切。
我們做了什麼
規格：一個預約應用 —— 登入、一個日曆、一張 Postgres 支撐的預約表、一個管理員清單，以及一個綁定自有網域的公開預約頁。三者用完全相同的提示詞，如下。
Build a bookings app. Users sign in with email. A calendar shows open 30-min slots. Booking writes to a Postgres `appointments` table. Add an admin page listing today's bookings. Deploy it to a public URL on a custom domain.
結果：從提示到線上 URL
三者都很快到達可用預覽。差距出現在部署 —— 也就是演示會跳過的那一段。完整成績單如下。
| Metric | Bolt.new | Lovable | Y Build |
|---|---|---|---|
| 到達可用預覽的時間 | 18 min | 22 min | 14 min |
| 到 MVP 所需提示數 | 9 | 12 | 7 |
| 到線上 URL 的額外時間 | +12 min | +9 min | +3 min |
| 手動設定步驟 | 6 | 4 | 0 |
| 本次建構成本 | $20/mo | $25/mo | $12/mo |
表 1 —— 每個工具同規格 3 次執行取中位數。完整日誌見「方法論」。
從提示到公開 URL 的分鐘數
越低越好
Build time ■ Deploy time ■
圖 1 —— Y Build 的領先幾乎全在部署：零手動設定步驟。
截圖 · 三種部署流程，帶標註
真實的產品截圖建立信任 —— 它們就放在這裡。
自己來建構一遍
在 Y Build 裡建構這個預約應用 —— 免費開始
同一段提示，你的帳戶。一次性部署到你自己的網域。
30 天的成本
預覽定價掩蓋了真實帳單：資料庫、託管附加項，以及保持上線所需的席位。在一個月的輕量流量下，差距進一步拉大。
「建構打成了平手。部署才是全部故事 —— 而它恰恰是沒人做基準測試的那一段。」
各工具的強項
它們都不差，只是為不同的活兒調校：
- Bolt.new —— 當你打算部署到別處時，最適合做全端原型。
- Lovable —— 首版 UI 最漂亮；非常適合以設計驅動的 MVP。
- Y Build —— 到達一個真正部署、綁定你自己網域的產品，步驟最少。
方法論
如何複現
同一台機器、同一網路、全新帳戶。一名操作者，每個工具跑 3 次，碼錶從首次提示開始、到公開 URL 透過 HTTPS 解析時停止。我們取中位數以削弱運氣成分。原始螢幕錄影與提示日誌：github.com/ybuild/lab-03。
結論
一句話結論
如果你在做原型，挑一個你喜歡其 UI 的就行。如果你要把一個真實產品發布到真實網域，部署上的差距就是決定性的 —— 這也正是我們當初把 Y Build 做成現在這樣的原因。