DealScout 運動折扣平台複盤

想買雙打折的運動鞋，得手動翻遍十幾個品牌官網，費時費力還常常撲空。 我在這件事裡負責一人 AI 協作開發，包辦了從自動抓取各大官網折扣、整理資料，到設計網頁的所有工作。

成果速覽

• 成功串接 Nike、Adidas、On、Hoka、Arc'teryx 等十多個運動品牌，收集並整理超過 5,000 件折扣商品。
• 專案目前已正式停用，沒有上線商業化，在完成核心體驗驗證後因後續維護成本過高而收手。
• 採用輕量化的產品設計，利用瀏覽器暫存功能取代傳統的會員與金流系統，在極低預算下完成概念驗證。

解決找折扣鞋款的痛點

每當我想買雙特價球鞋或戶外裝備時，總是要在各大品牌的官網之間切換，促銷資訊零散得令人頭痛。 這讓我起心動念開發了 DealScout，這是一個專門幫大家尋找運動品牌折扣的平台。 為了用最快的速度測試這個想法有沒有人要用，我刻意簡化了功能。 我略過了繁瑣的註冊帳號流程，改用瀏覽器內部的暫存空間，也就是讓使用者直接在瀏覽器裡把商品加入收藏夾，用最簡單的「尋寶」方式開始體驗。

note技術細節：輕量化 MVP 的前端架構

前端採用 Next.js 14（App Router）搭配 Tailwind CSS，快速建構出響應式介面。 為了在極簡狀態下驗證產品核心價值，刻意不實作後端資料庫會員系統，而是直接利用瀏覽器當地的 localStorage 儲存收藏夾資料。

派出一支不眠不休的資料收集軍隊

要讓平台上的特價資訊保持最新，背後需要一套自動化程式，定時去各家品牌官網「讀取」資料。 這就像是雇用了一位虛擬助理，每天幫你翻看各大報紙的促銷版面。 然而，許多現代網站使用了高度動態的網頁技術，只下載純文字常會拿到一片空白。 因此，我讓這個助理學會模擬真人操作瀏覽器的行為，等待網頁畫面完全載入後，才把正確的折扣資訊抄錄下來，並且貼心地設定隨機逗留時間，避免對別人的伺服器造成負擔。

note技術細節：Scrapy 與 Playwright 混合爬蟲設計

後端採用 Python FastAPI 提供 API，並以 APScheduler 處理排程。 針對重度依賴 JavaScript 渲染的品牌官網，使用 Scrapy 結合 Playwright 進行瀏覽器真實渲染。 爬蟲內建隨機 User-Agent 與 2 到 5 秒的延遲，並嚴格遵守 robots.txt 規範。

讓有需要的人在搜尋時一眼看到

好不容易收集了上千件折扣商品，如果沒人看得見就失去意義了。 為了讓大家在搜尋折扣時能直接找到我，我採用了網頁在伺服器先做好才送到手機的技術，也就是在伺服器端把資料填入網頁樣版、產生完整的靜態網頁。 當搜尋引擎的機器人來造訪時，可以直接讀到完整的商品內容與價格，而不是拿到一個空殼網頁。 這就像是把商品直接擺在櫥窗最顯眼的地方，而不是藏在倉庫深處。

graph TD
    A[運動品牌官網] -->|自動收集程式| B(資料庫)
    B -->|計算省下多少錢| C[後端 API 服務]
    C -->|即時渲染網頁| D[前端網頁伺服器]
    D -->|搜尋引擎最佳化| E(搜尋引擎與使用者)

note技術細節：Next.js SSR/ISR 策略與資料庫

專案部署於 Vercel，品牌頁面使用 ISR（增量靜態生成）與 SSR（伺服器端渲染）來提升 SEO 自然流量。 資料庫使用 Supabase（PostgreSQL），搭配 SQLAlchemy 與 asyncpg 進行非同步資料庫操作。

為什麼我決定在驗證後按下停止鍵

在成功串接了十多個品牌、累積了 5,000 多件商品後，我遇到了這類型產品最棘手的痛點：維護成本。 只要任何一個品牌官網改版，原本寫好的收集規則就會失效，網頁上的價格與連結就會出現錯誤。 這代表我需要花費大量的時間，不間斷地手動檢查並修復每一條規則。 最後我決定理智收手，這雖然是一個未上線的專案，但它讓我深刻體會到，寫程式往往只是最簡單的一步，如何持續應對外部變更並控制營運成本，才是產品能走得長遠的關鍵。

這個專案的相關經驗，也記錄在我的 專案複盤-MOC 之中。

note技術細節：資料清理與維護挑戰

資料庫移轉使用 Alembic 管理。在爬蟲運作中常因前端結構改變導致 XPath 或 CSS 選擇器失效。 此外，部分品牌官網有圖片跨域保護，需要透過代理伺服器或圖片快取機制解決。 最終評估人天維護成本（維護十多個 Spiders）過高，決定將專案停留在 MVP 驗收階段。