智慧旅運訂單與派車平台

概述

商業專案，工作室負責全端開發。一筆旅運訂單會在客戶、營運人員與司機之間流轉：客戶預約與查看行程，營運派車與處理異常，司機接單、回報位置並完成行程。接手時有些頁面已有 UI，但還沒完整接上 API 與例外狀態。

問題

三端如果各自維護一份狀態，很快就會出現「後台顯示已派車，司機端還看不到」。派車也不只是選一個司機：要依日期、門市、車型與狀態篩選，還要檢查同一司機前後約三小時的行程衝突。GPS 則不能在行程外無限制地公開追蹤。

解法

訂單狀態視為共同的業務狀態，三端只決定要顯示哪些操作。AI 提供訂單解析、派車建議、異常分類與風險提示，最後仍由營運人員確認。GPS 依服務時間、追蹤連結與角色權限決定可見範圍，第一版以 Polling 更新。

客戶端（Next.js / Expo）──┐
營運後台（Next.js）───────┼──▶ API Services（Prisma）──▶ PostgreSQL
司機端（Expo / RN）───────┘          │
                                     ├──▶ Maps / GPS
                                     ├──▶ SMS / Push / Slack
                                     └──▶ LLM（訂單解析、派車建議、異常分類）

主要功能

• 客戶預約、帳號與訂單流程
• 司機登入、個人設定、收入、上線、接單與拒單
• 營運後台派車、批次派車、司機篩選與訂單狀態操作
• 訂單、派車與司機執行狀態的跨端同步
• 地圖標記、導航、行程分享、GPS 回報與公開追蹤
• 客戶評價、異常回報、通知與 Deep Link
• AI 訂單解析、派車建議、異常分類與營運風險提示
• Expo Web 路由、子路徑部署、JWT、Rate Limit 與 Proxy Header

架構

待派車 ──▶ 已派車 ──▶ 已接單 ──▶ 執行中 ──▶ 完成
             │           │
             │           └──▶ 拒單 ──▶ 回到待派車
             └──▶ 取消指派

同一份狀態，三端各自決定顯示哪些操作：
  客戶：查看 / 評價      營運：指派 / 重新指派 / 取消      司機：接單 / 拒單 / 開始 / 完成

司機 App ──▶ 位置回報 ──▶ API
                          │
        讀取條件：服務時間內 ∧ 追蹤連結有效 ∧ 角色有權限
                          │
                          ▼
              營運地圖 / 公開追蹤頁（Polling 更新）

工程決策

同一筆訂單有太多角色在改

把訂單狀態當成共同的業務狀態，而不是每個畫面自行推測。哪些操作可用，由狀態決定；畫面只負責呈現。

AI 建議，人來確認

派車建議會考慮篩選條件與時間衝突，但最後由營運人員確認。這是營運責任的位置，不是模型的。

GPS 不能一直開著

服務時間、追蹤連結與角色權限分開處理，地圖端只讀取符合條件的位置。第一版用 Polling，因為同時在線人數還不需要完整的即時事件基礎設施；之後再把高價值狀態改成 SSE 或 WebSocket。

Web 和 App 不是同一個執行環境

三端共用後端，但 Web 與 Native 的 API 來源、路由和登入清除行為不同。分開設定，並補上 Loading、Error、Refresh、Empty State、Logout 與斷線後重新取得資料。

畫面

客戶、門市、司機與行程識別資訊已去識別化。

技術

TypeScript、Next.js、React、Expo、React Native、Prisma、PostgreSQL、JWT、Maps / GPS、Push Notification、Slack、LLM、Docker、CI。

結果與心得

• 狀態由後端決定、畫面只負責呈現之後，三端不一致的問題才有單一的地方可以修。
• AI 的位置是建議；確認與責任留在營運人員。
• Polling 夠用就先用 Polling。即時基礎設施等同時在線人數真的需要時再上。

公開範圍

只展示訂單、派車、追蹤與權限等部分功能，不含正式 Mobile Store 上架或第三方服務 SLA。