AI 原生开放教材

外观

VibeFast 文档官方文档·英文原文 ↗原件 ↓仓库 ↗

實戰案例：用 vibefast.app 做一個電商網站 ​

English · 繁中 · Español · 日本語 · Português (BR)

作者： Danko Peng（@dankopeng）
更新： 2026 年 3 月
閱讀時間： 約 10 分鐘

假設：你買了 vibefast.app，想做一個電商網站 ​

這篇用一個真實的場景來示範：從有一個電商想法，到用 vibefast.app 把它跑起來，整個過程是什麼樣子。

用的例子是：一個賣手工皂的電商網站——SoapCo。自己做皂、自己賣，不需要複雜的庫存系統，品項不多，每次大概 20-30 個 SKU。

和 SaaS 案例的差異 ​

上一篇（23）是 SaaS——用戶付月費使用你的工具。

電商不一樣：用戶買你的實體商品，每筆是一次性交易，你要管理商品、訂單、出貨。

這個差異影響資料結構和業務邏輯，但 vibefast.app 的地基（auth、Stripe、Resend）兩個案例都一樣可以直接用。

第一步：clone 之後先跑起來 ​

和 SaaS 案例一樣，clone 下來，按 quickstart 跑 setup，確認整個 app 在本地跑得起來。

這一步不需要改任何東西，只是確認起點正確。

第二步：寫需求分析書 ​

我想用 vibefast.app 做一個賣手工皂的電商網站，叫 SoapCo。
自己做皂自己賣，品項不多（20-30 個 SKU）。

核心功能（MVP）：
1. 商品列表和詳情頁（含圖片、成分說明、庫存狀態）
2. 購物車（可加多個商品、調整數量）
3. 結帳和付款（Stripe，一次性付款）
4. 訂單確認 email（自動發送）
5. 後台管理商品和訂單

技術基礎：vibefast.app（已有 Auth、Stripe、Resend 整合）
這個版本不做：會員積點、商品評論、多語言、折扣碼

第三步：設計資料庫結構 ​

電商的資料表比 SaaS 稍微複雜，讓 AI 幫你設計：

先不要動手。

基於這個電商需求，幫我設計 D1 的資料表結構，包含：
- products（商品）
- orders（訂單）
- order_items（訂單明細）

每個資料表需要哪些欄位？表之間的關係是什麼？
商品圖片會存在 R2，資料表裡只存圖片的 key。

AI 給你草稿，你逐條確認：

  • products 有 name、slug、description、price、stock、image_key 等欄位，對嗎？
  • orders 要記錄哪些資訊？收件地址要存嗎？
  • 訂單狀態有哪些？pending、paid、shipped、delivered？

確認沒問題，請 AI 生成建立資料表的 SQL，執行。

第四步：上傳商品圖片 ​

電商需要商品圖片，這是和 SaaS 最大的不同之一。

好消息是：vibefast.app 已經內建完整的媒體庫，包含圖片上傳、管理、顯示，你不需要自己設計這個流程。

在後台建立或編輯商品時，直接用 vibefast.app 的媒體庫選擇或上傳圖片就好。圖片存到 R2、產生 URL、在前台顯示——這些都已經幫你做好了。

你要做的只是在 products 資料表加一個 image_url 欄位，存媒體庫回傳的圖片 URL：

告訴 AI：

幫我在 products 資料表加一個 image_url 欄位，
在後台的商品新增和編輯頁面，串接 vibefast.app 現有的媒體庫元件來選擇圖片，
把選好的圖片 URL 存進這個欄位。

這樣就夠了，不需要重新做圖片上傳的功能。

第五步：購物車的設計決策 ​

購物車是電商的核心，有兩種做法：

做法 A：存在瀏覽器（localStorage/Cookie）

  • 用戶不需要登入就能加商品到購物車
  • 簡單，不需要資料庫
  • 缺點：換裝置就消失了

做法 B：存在資料庫

  • 需要登入才能加購物車
  • 可以跨裝置同步
  • 比較複雜

對 SoapCo 這種小型電商，做法 A 夠用了。告訴 AI：

購物車用 Cookie 存，不需要登入。
格式是 JSON 陣列：[{productId, quantity}, ...]
結帳時才需要登入或填寫收件資料。

先不要動手，這個設計有什麼潛在問題嗎？

討論完，確認方向，再開始實作。

第六步：Stripe 結帳 ​

vibefast.app 已經整合 Stripe，電商的結帳流程和 SaaS 的訂閱稍微不同——這是一次性付款，購物車裡可能有多個商品。

告訴 AI：

幫我實作結帳流程：

1. 用戶點「結帳」，把購物車內容送到後端
2. 後端驗證每個商品的庫存還夠
3. 建立 Stripe Checkout Session，包含所有商品
4. 付款成功後：
   - 在 orders 和 order_items 建立訂單記錄
   - 扣除每個商品的庫存
   - 發送訂單確認 email（用 Resend）
5. Webhook 處理付款結果

先列出計劃和會影響哪些檔案，不要動手。

第七步：後台管理 ​

電商需要一個簡單的後台讓你管理商品和訂單。

vibefast.app 已有 admin 後台的基本架構，你需要加的是：

  • 商品管理（新增、編輯、上下架、設定庫存）
  • 訂單列表（看所有訂單狀態）
  • 更新訂單狀態（已出貨、已送達）

這些都是標準的 CRUD，告訴 AI 逐一實作。

第八步：品牌和設計 ​

把 vibefast.app 的預設 UI 換成 SoapCo 的風格。

電商的視覺很重要，特別是商品圖片和整體質感。這部分可以多花一點時間：

幫我把網站的主題改成適合天然手工皂品牌的風格：
- 主色調：米白色（stone-50）配深綠（green-800）
- 字體風格：優雅、自然感
- 商品卡片：突出圖片，文字簡潔
- 整體感覺：手工、天然、質感，不要過度設計

從想法到上線：時間表 ​

第 1 天：clone、setup、確認起點
第 2 天：資料表設計、R2 圖片上傳
第 3-5 天：商品頁面（列表 + 詳情）
第 6-7 天：購物車邏輯
第 8-9 天：Stripe 結帳 + Webhook + 訂單 email
第 10 天：後台管理（商品 + 訂單）
第 11-12 天：品牌設計、細節調整
第 13 天：測試所有流程、修 bug
第 14 天：部署，準備上線

兩週從零到上線。如果從頭自己做 auth 和 Stripe 整合，這兩個就要一週以上。vibefast.app 把這些都跳過了，讓你把兩週全部用在電商本身。

幾個容易漏掉的細節 ​

庫存要在付款完成後才扣，不是加購物車時扣。 加購物車只是暫時保留，付款失敗或放棄結帳，庫存不應該被佔用。在 Stripe Webhook 的 checkout.session.completed 事件裡才真正扣庫存。

訂單確認 email 要有足夠的資訊。 用戶付款後的 email 要包含：訂單編號、商品清單、金額、預計到貨時間、聯絡方式。這封 email 是用戶最重要的信任憑證。

測試完整的購買流程，不只是測 UI。 用 Stripe 的測試信用卡走一遍完整流程：加商品 → 結帳 → 付款 → 確認 email 收到 → 後台看到訂單。每個環節都要確認正常。

關鍵心得 ​

電商的核心是信任，不是功能。 商品圖片清晰、商品說明詳細、付款流程順暢、確認 email 及時——這些比「有沒有折扣碼功能」重要得多。

先賣少量商品，驗證流程。 上線第一天，先只放 3-5 個商品，確認整個購買流程沒問題。有了信心再慢慢擴充品項。

客服比功能更重要。 第一批用戶買了之後，主動聯絡問他們體驗如何。真實的回饋比任何 analytics 數據都有用。

Danko Peng
X · YouTube · Threads

👉 回到教程首頁

想直接上手完整的 Cloudflare 全棧模板？
👉 vibefast.app — 早鳥 $99，2026 年 8 月 1 日漲至 $199。