幸福巴士再補人力：來義可把司機備援、無障礙運輸與即時班次接成原鄉交通韌性服務

屏東縣來義鄉公所於 2026年8月24日發布「幸福巴士－小愛倢（職代）司機徵選公告」。單看標題，它是一則人事招募；但如果把它放進偏鄉公共運輸的實際運作，就會看見另一個更關鍵的問題：一條路線能不能穩定出車，最後仍要回到人。

在都市交通裡，駕駛臨時請假，往往還有其他班次、其他路線或其他運具可以吸收；在原鄉，尤其是就學、就醫、文健站接送與跨鄉鎮生活線，一名駕駛的缺勤，可能直接變成一名學生無法準時到校、一位長者無法按時回診，或一個部落原本預約好的生活接駁被迫中斷。因此，這次「職代司機」徵選值得被看成一個交通韌性訊號，而不是單純的人事消息。

來義的幸福巴士也早已不是單一路線。交通部公路局目前公開的營運資料列出返鄉就學、潮州生活、觀光、醫療、課輔支援與鄉內生活等多種服務；部分路線採預約班次，並要求在乘車前一個工作日前完成預約。這表示營運端同時要處理固定班次、預約需求、不同服務對象、不同目的地與臨時調度。參見交通部公路局｜幸福巴士及幸福小黃營運資訊。

今年4月1日，交通部公路局也公布來義鄉無障礙小巴「小愛倢」正式啟用。官方資料指出，當時來義鄉已有8輛車、8條幸福巴士路線，新車主要支援返鄉就學線延伸至南和國小，也補足文健站與鄉內集會所的交通需求，並具備輪椅上下車與陪同者搭乘所需的無障礙功能。參見交通部公路局｜「愛」你的心超出了「倢」線！來義鄉幸福巴士再添生力軍。

這兩筆資料放在一起，就能看出一個常被智慧交通討論忽略的事實：車輛升級之後，人力備援仍是系統能不能成立的底層條件。

第一層：先把「今天能不能出車」做成一張內部狀態表

原鄉交通數位化不一定要從大型平台開始。最先需要的，反而是一張每天有人更新、人人看得懂的內部狀態表。

最低限度可把資訊分成五組：`vehicle_id`、`driver_status`、`route_status`、`reservation_status`、`backup_plan`。車輛要知道今天可不可用、是否維修、是否為無障礙車；駕駛要知道正常、請假、職代或待命；路線要知道正常、延誤、停駛或改道；預約要知道人數、需求類型與截止狀態；最後還要有一欄寫清楚「如果原排駕駛不能出車，由誰、用哪台車、依什麼優先順序接替」。

這張表不需要先公開全部內容。內部先做到「同一份資料、同一個版本、同一個更新時間」，就能減少電話、LINE群組與紙本紀錄彼此不一致。當營運人員確認後，再把居民真正需要知道的資訊抽出來公開。

第二層：居民端只顯示四件事，不要把後台複雜度丟給族人

對居民而言，真正重要的通常只有四件事：今天有沒有車、我要不要預約、最晚何時預約、臨時異動要找誰。

因此，居民端的數位服務不必一開始就做複雜地圖。手機頁面、LINE選單或簡單Chatbot都可以，只要固定顯示：路線名稱、今日狀態、預約截止、聯絡窗口。若遇道路中斷、車輛故障、駕駛臨時缺勤或班次延誤，則以醒目的「異動」狀態取代舊時刻，而不是讓使用者自己猜哪一份公告才是最新。

公路局的來義路線資料已經提供營運方式、預約條件、票價與聯絡方式，這些可以作為公開資料底座；但「今天是否實際出車」仍應由營運端人工確認。AI可以整理，不應自行宣告班次正常。

第三層：無障礙需求不能只記成「一位乘客」

「小愛倢」的價值不只是新增一輛車，而是讓輪椅使用者、行動不便者、陪同者與需要較安全上下車空間的居民，有更適合的交通選項。這類需求若只用一般預約人數記錄，很容易在調車時被忽略。

因此預約資料可以多一層服務欄位，例如是否需要輪椅升降、是否有陪同者、是否需較長上下車時間、是否需要指定無障礙車。這些欄位的目的不是替乘客貼標籤，而是讓調度端在換車或換駕駛時仍能維持原本的服務條件。

若臨時必須改派非無障礙車，系統不應只顯示「已改車」，而應直接標記「需求無法滿足，需人工聯絡」，由承辦或營運人員確認替代方案。這也是偏鄉交通韌性與一般班表管理最大的差異之一：不是車有到就算完成，而是原本承諾的可近性要被保留。

第四層：駕駛備援要像災防備援一樣，有名單、有優先序、有交接

職代司機徵選最直接提醒的，是「備援人力」不能只存在於主管腦中。可以建立簡單的駕駛能力矩陣，包括可駕駛車型、熟悉路線、無障礙服務訓練、可支援時段與緊急聯絡方式。

當主要駕駛臨時缺勤時，不必從頭打電話找人，而是依序檢查：第一順位是否有同車型且熟悉路線的備援；第二順位是否能換車但維持服務；第三順位是否要調整班次；最後才是停駛。每一次異動也保留原因與處理結果，日後就能看出哪些路線最容易因人力不足受影響。

長期而言，這些紀錄可以幫助公所判斷，到底是「總人數不足」、特定時段不足、特定車型缺駕駛，還是某些路線過度依賴單一人員。這比只看全年總班次更能反映真實的服務風險。

第五層：AI與RAG適合做查詢層，不適合當出車裁判

當路線、預約、車輛與人力資料逐步結構化後，就很適合接到RAG或Chatbot。族人可以問：「明天去潮州要不要預約？」「醫療線星期幾有？」「輪椅可以搭哪一台？」「今天班次有沒有異動？」系統先查官方路線與當日狀態，再整理成簡單回答。

但這裡要鎖住一個防呆：模型只能回答資料庫已確認的狀態。 如果後台今天尚未人工確認，就應回覆「今日狀態待確認，請洽來義鄉公所」，而不是根據平日時刻表推測「應該有車」。涉及道路封閉、天候、臨時換班與車輛故障，更必須以營運人員或官方災防訊息為準。

這種設計也適合55原鄉共用。每個鄉不必採同一套品牌或介面，但可以共用最低欄位：路線、班次、預約規則、車輛狀態、無障礙能力、駕駛備援、最後確認時間與真人窗口。如此未來不論接網站、App、LINE、電話客服或AI助手，都不必重新整理一次資料。

從「有車可搭」走向「服務不容易斷」

偏鄉交通最容易被看見的是新車通車、路線增加與補助經費；比較不容易被看見的，是每天讓服務不斷線的人力安排、預約確認、換班、調車與臨時聯絡。

來義鄉這次「小愛倢」職代司機徵選，正好提供一個很實際的觀察入口。當一個原鄉已經有多條就學、生活與醫療路線，也有無障礙車輛後，下一階段的數位化應該從「有沒有系統」轉向「系統能不能在臨時缺人、缺車、改班時仍維持服務」。

對55原鄉而言，最值得複製的不是一套昂貴平台，而是一個簡單原則：把人力、車輛、路線、預約與替代方案放在同一張可更新的服務地圖上。 當居民能快速知道今天有沒有車、怎麼預約、臨時異動後要找誰，數位公共服務才真正從網站資訊走進日常生活。

主要來源

• 屏東縣來義鄉公所｜幸福巴士－小愛倢（職代）司機徵選公告
• 交通部公路局｜幸福巴士及幸福小黃營運資訊
• 交通部公路局｜「愛」你的心超出了「倢」線！來義鄉幸福巴士再添生力軍