Appearance
PRD：C2B 二手車限額盲拍媒合平台
說明： 台灣首創純 C2B 二手車競價平台，透過限額盲拍機制讓消費者賣車給合格車商。賣家前期需支付認證與上架費，成交後由買家吸收退還。 版本： 0.1.0 | 最後更新：2026-04-14 狀態： draft 影響角色： 架構師 / UX / 前端 / 後端 / Admin
1. 產品概述與背景
1.1 專案定位
本平台打造台灣首創的**純 C2B（Consumer to Business）**二手車競價媒合平台，商業模式參考韓國現行成熟系統。
有別於現行台灣市場的交易型態：
- B2B：車商對車商，C 端無法直接受益
- B2C：車商主導定價，消費者議價能力弱
本平台專注於解決一般消費者（C 端）賣車痛點，透過第三方公正認證與限額盲拍機制，讓全台優質車商（B 端）公平競價，實現價格透明、交易公正的車輛收購流程。
1.2 目標受眾
| 角色 | 說明 |
|---|---|
| C 端（賣家） | 欲出售自有車輛的一般大眾 |
| B 端（買家） | 具備合法營業登記、已繳納保證金的二手車商 |
| Admin（平台管理員） | 負責審核、監控、財務對帳的平台內部人員 |
1.3 核心載體（Phase 1）
- 主要載體： 響應式網頁（RWD Web）
- C 端入口： 支援透過 LINE 瀏覽器開啟，未來評估整合 LINE Mini App 或 LINE LIFF
- B 端與 Admin： 以 Web 後台為主，適合辦公室大螢幕操作
1.4 痛點分析
| 對象 | 現有痛點 | 本平台解法 |
|---|---|---|
| C 端賣家 | 單一車商估價，議價空間不透明 | 多家車商盲拍競價，確保市場最高價 |
| C 端賣家 | 認證費用自行承擔，賣不掉也虧本 | 認證與上架費由賣家先付，成交後轉由買家手續費吸收並退還給賣家 |
| B 端車商 | 搶標競爭激烈，易衝動出高價 | 限額機制控制參與數，減少非理性競標 |
| 交易雙方 | 資金安全無保障 | 銀行第三方監管專戶確保履約 |
2. 商業模式說明
2.1 收費架構
C 端（賣家）——前期支付認證與上架費，成交後由買家吸收並退還
| 項目 | 金額 | 說明 |
|---|---|---|
| 第三方認證費 | 約 1,500 元 | 賣家支付，成交後由買家吸收 |
| 上架費 | 約 3,500 元 | 賣家支付，成交後由買家吸收 |
| 棄標違約費 | 待定 |
B 端（車商）
| 項目 | 金額 | 說明 |
|---|---|---|
| 年度保證金 / 會費 | 3 萬－6 萬元 / 年 | 確保車商資格，違約時扣除 |
| 得標手續費 | 約 10,000 元 / 台 | 競標成功並完成交易後收取 |
2.2 平台盈收來源
- B 端年度保證金 / 會費
- B 端每筆成交手續費
- C 端棄標違約費（待定）
2.3 資金安全機制
採用銀行第三方監管專戶（類似履約保證），確保：
- 平台無法私自挪用買賣雙方資金
- 得標車商匯款後由信託專戶托管，交車完成後撥付 C 端
3. 核心機制：限額盲拍流程
3.1 流程總覽
[C 端申請認證]
↓
[第三方機構鑑定，出具報告]
↓
[Admin 審核，車輛上架]
↓
[B 端首輪盲拍（限額 N 家，例如 20 家）]
↓
[滿額或時間到期，首輪結束]
↓
[系統通知第 2～5 名：「獲得二次競價機會」]
↓
[次輪加價（第 1～5 名最多 2 次出價機會）]
↓
[第1名可加價（若第 1~5 名價格高於第1名，則第1名可加價）]
↓
[競價結束，揭示最高出價金額給 C 端]
↓
[C 端三選一：同意出售 / 重新上架 / 拒絕出售]
↓
[同意出售 → 匯款倒計時 24 小時 → 完成交易]3.2 首輪盲拍規則
| 規則項目 | 說明 |
|---|---|
| 資訊揭露 | B 端只能看到車輛報告、歷年該車款成交行情區間 |
| 資訊隱藏 | B 端無法看到其他車商出價，也無法看到自己目前排名 |
| 結束條件 | 達到限額車商數（如 20 家），或設定天數到期（如 10-15 天） |
| 修改限制 | 首輪出價送出後不可修改 |
| C 端底價 | C 端可設定「可接受最低底價」，僅自己可見，系統不揭露給 B 端 |
3.3 次輪競價（加價階段）規則
| 規則項目 | 說明 |
|---|---|
| 通知對象（階段一） | 首輪第 2 名至第 5 名的車商 |
| 通知對象（階段二） | 若階段一中，2~5名的出價高於原第 1 名，則額外通知「原第 1 名」 |
| 通知內容 | 「目前有更高出價，您獲得二次競價機會」（不揭露最高金額） |
| 加價限制 | 第 2 至第 5 名合計最多 2 次出價機會；若觸發階段二，原第 1 名有 1 次反超加價機會 |
| 選擇權 | 車商可選擇針對當前報價進行定額或自訂加價，亦可選擇放棄 |
設計意圖： 讓第 2-5 名先互相加價，避免單一車商哄抬並維持多方競爭；若被原先落後者超越，再給予原第 1 名最終加價權，確保 C 端能獲得市場最高價。不揭露當前最高金額，防止最低加一元惡意搶標。
3.4 決標與 C 端決策
競價結束後，系統向 C 端展示最高出價金額，C 端有三個選項：
| 選項 | 行為 | C 端費用 |
|---|---|---|
| A. 同意出售 | 交易成立，進入金流與交車流程 | 免費 |
| B. 重新上架（降價重拍） | 賣家可調降底價或延長時間，免費重新進行下一檔期競標 | 免費 |
| C. 拒絕出售（棄標） | 交易不成立，前置預付費用不退，且需繳納違約金 | 待定 |
3.5 決策期限
- C 端收到最高出價後，應設定決策時間限制（建議 48-72 小時，待確認）
- 超時未決策視同選項 B（重新上架）或另行定義（待確認）
4. 各角色功能需求
4.1 C 端（消費者 / 賣家）模組
入口設計： 以 LINE 為主要入口，降低操作門檻。
4.1.1 註冊與登入
| 功能 | 說明 |
|---|---|
| LINE 快速登入 | 使用 LINE OAuth，一鍵授權 |
| 手機號碼驗證 | 輸入手機號碼，接收 OTP 驗證碼 |
| 身份綁定 | LINE 帳號與手機號碼雙重綁定，防止重複帳號 |
4.1.2 我要賣車（申請認證）
User Stories：
| ID | 身份 | 需求 | 目的 |
|---|---|---|---|
| US-C01 | 作為 C 端賣家 | 我想填寫車籍資料並預約認證 | 以便啟動賣車流程 |
| US-C02 | 作為 C 端賣家 | 我想設定競標天數、限額家數與最低底價 | 以便控制拍賣條件 |
| US-C03 | 作為 C 端賣家 | 我想查看目前有幾家車商出價 | 以便了解競標熱度（不顯示金額） |
| US-C04 | 作為 C 端賣家 | 競標結束後查看最高出價 | 以便做出賣或不賣的決策 |
功能清單：
- 填寫基本車籍資料（車牌、廠牌、型號、年份、里程、車色等）
- 上傳車輛照片（外觀、內裝、里程表）
- 預約第三方鑑定機構（如 GOO、超跑鑑定）的檢測時間與地點
- 查看認證進度與報告結果
- 設定競標條件：
- 競標天數（選項：10 天 / 15 天，待確認可否自訂）
- 限額車商家數（預設 20 家，待確認是否可調整）
- 可接受最低底價（僅 C 端可見）
4.1.3 競標動態大廳
- 顯示目前已出價車商數量（不顯示金額與車商名稱）
- 顯示剩餘競標天數與剩餘名額
- 競標結束後揭示「最高出價金額」
4.1.4 決策中心
- 點選「同意出售」——確認按鈕需二次確認防誤觸
- 點選「降價重拍」——輸入新底價，確認後免費重新上架
- 點選「取消出售（棄標）」——顯示違約費用告知與確認流程
4.1.5 交車與合約指引
- 交易成立後顯示完整交車 SOP（過戶所需文件、流程說明）
- 顯示信託專戶到帳確認狀態
- 提供平台客服聯繫方式
4.2 B 端（車商 / 買家）模組
介面設計： Web 網頁版，適合辦公室作業與大螢幕查看車況。
4.2.1 車商資格審查與註冊
| 功能 | 說明 |
|---|---|
| 上傳營業登記 | 合法營業登記證掃描件，Admin 審核 |
| 綁定銀行帳戶 | 用於匯款與退款 |
| 保證金繳納 | 上傳繳費證明，或線上匯款至指定帳戶 |
| 審核狀態通知 | 審核通過 / 退件通知 |
4.2.2 車輛尋寶區（競標列表）
列表顯示資訊：
- 車輛基本資料（廠牌、型號、年份、里程、車色）
- 第三方認證報告（可展開查看完整報告）
- 車輛內外觀照片
- 原車主去識別化資訊（職業類別、性別，不揭露姓名、聯絡方式）
- 該車款「歷史成交行情區間」（嚴禁提供平台預估價，防止哄抬）
- 剩餘競標名額
- 剩餘競標時間
4.2.3 盲拍出價系統
| 功能 | 說明 |
|---|---|
| 輸入競標金額 | 數字輸入框，顯示歷史行情作為參考 |
| 送出確認 | 二次確認對話框，送出後首輪不可修改 |
| 次輪加價通知 | 接收系統推播「取得二次競價機會」 |
| 次輪出價框 | 提供修改（提高）出價的輸入框，只能往上加，不可降低 |
4.2.4 訂單與得標管理
- 查看所有已出價案件的進度狀態
- 得標通知（站內通知 + 推播）
- 顯示「第三方監管專戶」匯款帳號與金額
- 匯款倒數計時器（24 小時限制），顯示剩餘時間
- 歷史成交紀錄
4.3 平台管理端（Admin）模組
4.3.1 會員管理
C 端管理：
- 查詢 C 端會員資料
- 黑名單設定與查詢（如異常棄標行為）
B 端車商管理：
- 車商資格審核（通過 / 退件 / 補件）
- 保證金狀態追蹤（餘額、扣款紀錄、補繳通知）
- 違約紀錄管理（警告次數、是否觸發停權）
- 永久停權（黑名單）操作
4.3.2 車輛與認證管理
- 對接 / 手動上傳第三方認證報告資料（Phase 1 採人工，Phase 2 自動化）
- 審核車輛上架狀態（通過 / 退件 / 要求補照片）
- 車輛下架（異常情況）
4.3.3 拍賣大廳監控（上帝視角）
- 即時查看所有競標案件的出價狀況
- Admin 可看見每家車商的出價金額（非盲拍模式）
- 人工終止 / 暫停異常競標案
- 查看競標案件完整時間軸
4.3.4 財務與對帳系統
| 功能 | 說明 |
|---|---|
| 保證金管理 | 收取紀錄、扣罰記錄、退還申請處理 |
| 得標手續費對帳 | 每筆成交案件的手續費應收 / 已收狀態 |
| 違約金結算 | B 端棄標扣保證金計算、C 端棄標費用請款 |
| 信託專戶對帳 | 匯款到帳確認、撥付紀錄 |
4.3.5 數據統計與報表
- 每日 / 每月上架量與成交率
- 各車款歷史成交價資料庫（作為 B 端行情參考的資料來源）
- 車商活躍度分析
- C 端棄標率分析
5. 金流與費用設計詳述
5.1 資金流向圖
B 端匯款
↓
[銀行第三方監管專戶]
├── 扣除平台手續費 (10,000元) → 平台收入帳戶
└── 餘款撥付 → C 端指定帳戶5.2 費用觸發時間點
| 費用類型 | 觸發條件 | 繳費方 | 金額 |
|---|---|---|---|
| 年度保證金 | 車商申請加入時 | B 端 | 3-6 萬/年 |
| 得標手續費 | C 端同意出售，交易成立 | B 端 | 約 10,000 元 |
| 認證費+上架費 | C 端申請賣車時 | C 端先付，成交後退還 | 約 5,000 元 |
| C 端棄標違約金 | C 端棄標時 | C 端 | 待定 |
| B 端棄標違約金 | 得標後 24h 未匯款 | B 端（從保證金扣） | 保證金全扣 |
5.3 退費規則
| 情境 | 退費對象 | 退費內容 |
|---|---|---|
| B 端未得標 | B 端 | 無需退費（保證金不動） |
| B 端年度會費到期不續約 | B 端 | 退還保證金餘額（扣除當年費用） |
| C 端重新上架（非棄標） | 無扣費 | 保留預付費用效力，重新上架免再次收費 |
| C 端棄標 | 無退費 | 預付之認證與上架費不退還，另計棄標違約金（金額待定） |
6. 違約處罰機制
6.1 B 端（得標車商）棄標
| 項目 | 規則 |
|---|---|
| 定義 | 得標後 24 小時內未匯款至信託專戶 |
| 處罰 | 沒收全額平台保證金 |
| 紀錄 | 記違約警告一次 |
| 累進處罰 | 累計兩次違約即永久停權（黑名單） |
| 後續處理 | 該次競標不遞補第二名，C 端可免費重新上架 |
設計原因： 不遞補第二名是為了避免競標順序被操縱，確保所有車商公平競標機會。
6.2 C 端（賣家）棄標
| 項目 | 規則 |
|---|---|
| 定義 | 競標結束後，C 端選擇「拒絕出售」 |
| 費用 | 預付之認證與上架費不予退還，額外違約金金額待定 |
| 收費時間 | 確認棄標後結算 |
| 黑名單機制 | 頻繁惡意棄標是否設限，待確認 |
6.3 異常行為防範
| 異常行為 | 防範機制 |
|---|---|
| B 端圍標（多帳號壓低競價） | 實名制審核 + 營業登記驗證，一間公司一帳號 |
| B 端最低加一元惡意搶標 | 次輪不揭露第一名金額 |
| C 端虛假委託（無誠意賣車） | 棄標費設計 + 棄標次數紀錄 |
| Admin 洩露出價資訊 | 操作 Log 完整記錄，敏感操作需二人授權（待確認） |
7. 開發分階段計畫
Phase 0：企劃與架構確認（目前階段）
目標： 確認所有商業邏輯無 Bug，產出 Phase 1 精確報價。
交付物：
- 詳細系統企劃書（本文件）
- UI/UX Wireframe（線框圖）
- 資料庫架構設計
- 第三方金流 / 認證機構對接規格
- Phase 1 開發報價單
完成指標：
- 所有商業邏輯通過 stakeholder 確認
- 無開放問題（Open Questions）殘留
Phase 1：MVP 核心網頁版上線
目標： 小規模封測，驗證市場接受度。
開發範圍：
| 模組 | 說明 |
|---|---|
| C 端 Web | 完整賣車申請、競標動態、決策中心 |
| B 端 Web | 車商後台、盲拍出價、次輪加價、得標匯款 |
| Admin Web | 審核、監控、財務對帳基礎功能 |
| 盲拍核心邏輯 | 限額機制、首輪盲拍、次輪加價邏輯 |
| 通知系統 | 站內通知 + LINE 推播（B 端次輪通知） |
Phase 1 刻意不做（降低成本）：
- 銀行信託專戶 API 串接（人工確認匯款）
- 第三方鑑定機構 API 串接（人工上傳認證報告）
- 原生 APP
驗收標準：
- 完成至少 5 筆完整端對端測試（C 端申請 → B 端競標 → 成交）
- 邀請 5-10 家相熟車商與 10-20 位消費者封測
- 收集市場反饋
Phase 2：系統自動化與行銷放量
目標： 規模化，降低人工成本，導入行銷資源。
開發範圍：
| 模組 | 說明 |
|---|---|
| 銀行信託 API | 全面串接銀行第三方監管專戶 API |
| 鑑定機構 API | 串接第三方鑑定單位（GOO 等）API，自動匯入報告 |
| LINE LIFF / Mini App | C 端 LINE 原生整合，提升使用體驗 |
| 原生 APP | 依市場需求評估 Android / iOS |
| 行銷模組 | 導入行銷合作資源，開放公開報名 |
| 數據分析儀表板 | 進階報表、行情資料庫自動更新 |
8. 非功能性需求
8.1 安全性
| 需求 | 說明 | 優先級 |
|---|---|---|
| 盲拍資訊隔離 | B 端出價資料僅 Admin 與系統可查閱，嚴禁對 B 端用戶揭露競標中資訊 | Must |
| 底價保密 | C 端最低底價僅儲存於後端，前端 API 不得回傳此欄位 | Must |
| 身份驗證 | 所有 API 需 JWT Token 驗證，敏感操作需重新驗證 | Must |
| B 端帳號實名制 | 一間公司限一帳號，透過營業登記証防圍標 | Must |
| 操作日誌 | Admin 所有敏感操作（查看出價、終止競標）需完整 Log 記錄 | Must |
| 資料加密 | 銀行帳號、個人資料傳輸需 HTTPS，儲存需加密 | Must |
8.2 效能
| 需求 | 目標值 | 說明 |
|---|---|---|
| 頁面載入時間 | < 3 秒（首頁） | 4G 網路環境 |
| API 回應時間 | < 500ms（P95） | 出價送出等核心操作 |
| 並發用戶 | 支援 500 同時在線（Phase 1） | 封測階段需求 |
| 系統可用性 | 99.5%（Phase 1） | 競標期間禁止計劃性停機 |
8.3 可用性
| 需求 | 說明 |
|---|---|
| 響應式設計 | 支援 Mobile / Tablet / Desktop |
| LINE 環境相容 | C 端介面需能在 LINE 內建瀏覽器正常顯示 |
| 操作防誤 | 出價送出、同意出售等不可逆操作需二次確認 |
| 狀態同步 | 競標剩餘名額、剩餘時間需即時或定時更新（建議 Polling 或 WebSocket） |
8.4 合規性
| 需求 | 說明 |
|---|---|
| 個人資料保護 | 符合台灣個人資料保護法（個資法） |
| 車主隱私 | C 端個人資訊對 B 端去識別化（不揭露姓名、聯繫方式至成交前） |
| 金融法規 | 信託專戶操作需符合銀行法相關規定，建議取得法律意見書 |
9. 使用者故事（User Stories）拆分規劃
9.1 C 端（消費者 / 賣家）
- US-C01：身為賣家，我希望可以使用 LINE 快速註冊與登入平台，以便免去記住帳號密碼的麻煩。
- US-C02：身為賣家，我希望能夠清楚輸入車況資料並上傳照片，以便順利申請第三方認證。
- US-C03：身為賣家，我希望可以自訂競標條件（天數、參與家數、最低底價），以便控制拍賣的節奏與預期收益。
- US-C04：身為賣家，我希望可以在競標期間看到目前已經出價的車商家數，以便掌握目前愛車的熱門程度。
- US-C05：身為賣家，我希望在競標結束後，系統能列出最高出價金額供我三選一（同意出售、重新上架、拒絕出售），以便完成最終交易決策。
9.2 B 端（車商 / 買家）
- US-B01：身為車商，我希望可以在平台上查看目前可競標的車輛列表，以及認證報告和歷史成交區間，以便判斷是否參與競標。
- US-B02：身為車商，我希望能在首輪盲拍中出價，並可以在送出前二次確認，以免誤打金額。
- US-B03：身為車商，如果我落入出價第 2 到第 5 名，我希望收到二次競價的通知，以便有機會再次加價爭取買到這台車。
- US-B04：身為得標車商，我希望在系統後台清楚看到第三方監管專戶的匯款帳號及倒數計時（24 小時），以便及時完成履約避免違約受罰。
9.3 Admin 端（管理員）
- US-A01：身為管理員，我希望可以在後台審核入駐車商的營業登記與保證金，以便控管平台車商質量防範違約。
- US-A02：身為管理員，我希望能在拍賣大廳總覽即時監控所有競標中的案件與每家車商出價，以便在發生異常狀況時手動介入。