參考附錄
與工作說明書、報價單共用的參考資料。
一、法定駕駛工時
汽車運輸業管理規則第 19 條之 2 對大型車駕駛人的派遣有明確規定，以下為系統檢核所依據的條文內容：
| 項目 | 規定 |
|---|---|
| 每日最多駕車時間 | 不得超過 10 小時 |
| 連續駕車 | 連續駕車 4 小時，至少應有 30 分鐘休息（可分段，每段至少 15 分鐘） |
| 特殊情況 | 最多連續駕車時間不得超過 6 小時，且休息須一次休滿 45 分鐘 |
| 兩工作日之間 | 應有連續 10 小時以上休息時間 |
條文出處：全國法規資料庫 汽車運輸業管理規則第 19-2 條。系統以此為預設值，若貴司內部另有更嚴格的規定，可在後台調整門檻。
二、位置回報怎麼做才不耗電
司機 App 最常見的抱怨是耗電。持續高頻定位確實會把電吃光，但本案不需要那樣做。
| 情境 | 回報頻率 | 理由 |
|---|---|---|
| 任務執行中 | 每 30 至 60 秒 | 後台需要知道車到哪了 |
| 已接受未出發 | 每 5 分鐘 | 只需確認人車就位 |
| 無任務 | 不回報 | 沒有業務需要，也避免不必要的個資蒐集 |
順帶處理掉的一件事
「無任務時不回報」除了省電，也是個資的界線：系統只在司機執行公司任務時知道他在哪，下班後不追蹤。
這一條建議寫進給司機的說明裡。司機端的配合度往往決定系統上不上得了線，而抗拒多半來自「公司要監視我」的疑慮。
三、技術選型
| 項目 | 選擇 | 理由 |
|---|---|---|
| 司機 App | 跨平台框架，一套程式碼 | Android 與 iOS 同時交付，日後改一次兩邊都更新，維護成本差一倍 |
| 後端 | Python（非同步） | 位置回報是高頻小封包的 I/O，非同步處理最省資源 |
| 資料庫 | PostgreSQL | 任務狀態變更需要交易保證；位置與軌跡查詢用得上地理索引 |
| 推播 | Firebase Cloud Messaging | 雙平台通用，本案量級在免費額度內 |
| 地圖 | 依需求選用 | 只顯示位置的話成本極低；若需路線規劃再依實際用量評估 |
若貴司已有既定的技術棧或指定的維護廠商，這一節可配合調整，不影響報價。
四、與現成 GPS 產品的關係
市面上有不少車隊 GPS 定位服務，月費在每車數百元的量級。它們解決的是「車在哪」，本案解決的是「這趟任務怎麼流轉」，兩者不衝突。
| 現成 GPS 服務 | 本案系統 | |
|---|---|---|
| 回答的問題 | 車現在在哪、跑了多少里程 | 這張單指派給誰、進行到哪一步、誰在什麼時候回報的 |
| 資料來源 | 車機硬體 | 司機 App 的操作與回報 |
| 派工 | 多半沒有，或很陽春 | 本案主體 |
| 工時檢核 | 無 | 有，見附錄一 |
若您車上已經裝了 GPS
告訴我是哪一家、有沒有提供 API。能取得資料的話，車機的位置比手機準確也更省電，本案可以改讀車機資料，司機 App 就只負責任務流轉。
這會讓司機 App 更簡單、也更省電。介接的工作量視對方 API 而定，確認後我再報這一項。
AXLID · 致 案主 · 案號 TK26081814OPCY76
· v0.1.0 討論稿 · 2026-08-18
作品：xuzheng.com.tw、chihuahuatrip.tw
作品：xuzheng.com.tw、chihuahuatrip.tw