排班真正難的不是把人塞進格子，而是同時回答「生意需要誰」和「誰適合站在這裡」

我原本只是想讓排班少靠一點感覺

排班這件事表面上很像一個很單純的問題。

今天預估有多少客人？

需要幾個人？

把人排進格子裡就好了。

但真的往下做，很快就會發現，店長腦中其實同時在處理很多不同的東西：

今天生意會多忙？

哪個時段會爆？

吧台是不是會比平常忙？

誰會切肉？

誰其實還不能獨立站這個崗？

誰這週已經太多工時？

誰平日晚上要上課？

哪個人可以補，但排下去會產生加班？

這些事情以前都靠一個熟悉門市的人，在腦中自己完成。

所以真正要解的不是：

「AI 能不能排一張班表？」

而是：

能不能把店長原本腦中那些需求、人、技能、法規與例外，整理成一套可以反覆運作的判斷流程。

相似營運日，其實只是前哨

我前面先做的，是「相似營運日」。

邏輯很簡單。

如果今天預估 130 個客人，我不想只拿「上週同一天」來比。

我會去歷史資料裡找來客量接近的日子，例如落在今天預估值 ±25% 的那些營運日，再看那些日子的實際人時。

不管它星期幾。

因為對我來說，「今天到底像哪一天」比「今天是星期幾」重要。

這可以很快給主管一個參考：

每 100 客需要多少人時？

Min 是多少。

Median 是多少。

Max 是多少。

它可以幫主管知道：

今天這個人力配置，到底落在什麼位置？

但做到這裡，我反而更確定一件事。

這不是智慧排班。

它只是在回答：

「大概需要多少人時。」

真正的智慧排班，還要回答：

需要的是什麼人？

需求側不能只看營業額

一開始很直覺會想到：

營業額越高，應該需要越多人。

但這個邏輯很快就會出問題。

同樣 10 萬營業額，可能是很多桌低客單，也可能是少量高客單。

對外場、吧台、洗碗、切肉造成的工作量完全不同。

所以我比較想把需求模型拆成：

客流 / 訂單數 → 總人時需求 → 時段拆分 → 崗位需求。

營業額還是有價值。

但它比較像輔助訊號，不應該直接代表工作量。

真正的主體是：

這個時段會有多少客人
會出多少單
品項組成是什麼
哪些崗位會被拉高需求
有沒有大桌、活動或特殊事件

最後形成的不是：

「晚上需要 8 個人。」

而是：

「18:00–22:00 外場需求多少、吧台需求多少、切肉需求多少。」

這才開始接近現場真正的問題。

另一邊不是「有哪些人」，而是「誰能站哪裡」

如果只有需求側，還是排不了班。

另一邊是人。

這裡我不想叫店長自己維護一堆人員資料。

HR 已經知道：

誰是正職、兼職。

誰是月薪、時薪。

這週已經排了多少工時。

Learning Hub 已經知道：

誰會什麼崗位。

誰的技能成熟度多少。

誰還在訓練。

所以這些資料不應該再輸入一次。

它們本來就應該自己流進排班系統。

而且人員匹配不能只是：

切肉 92 分的人，比切肉 85 分的人優先。

前面還要先有一道資格 Gate。

先回答：

這個人現在到底能不能獨立站這個崗？

不能，就直接排除。

能，再去比較：

技能成熟度、工時、正兼職、偏好、加班成本與其他限制。

順序應該是：

資格 → 適合度。

不是只靠一個漂亮的分數把所有東西混在一起。

我不想讓店長維護標籤

這也是我覺得整套系統很重要的一個地方。

假設店長知道：

「小明最近開始上夜校，平日不要排晚班。」

我不想讓他：

登入後台 → 找小明 → 編輯 → 新增標籤 → 選日期 → 儲存。

那只是把 Excel 換成另一個介面。

我比較想要的是：

店長直接說：

「小明最近上夜校，平日不要排晚班。」

然後系統自己理解：

這是在講誰。

這是一個偏好還是硬限制。

影響哪些星期。

什麼時候開始。

有沒有期限。

最後把這句話轉成結構化的 Label / Constraint。

所以我說的「0 手動維護」，不是「人永遠不用輸入任何東西」。

而是：

人只負責告訴系統現實發生了什麼，不需要替系統整理成資料格式。

這兩件事差很多。

LLM 可以理解人話，但它不是排班員

我不想讓 LLM 自己決定誰該上班。

它在這裡比較像翻譯器。

店長說：

「這週五小明請假，晚上有大桌，吧台跟外場各多一個，優先用兼職，正職不要加班。」

LLM 的工作是把這句話翻成：

小明週五不可排
18:00–22:00 吧台需求 +1
18:00–22:00 外場需求 +1
兼職優先
避免正職加班

然後真正的排班引擎重新計算。

也就是：

LLM 負責理解人的語言。

Scheduling Engine 負責算。

Constraint Engine 負責擋。

店長負責最後確認。

這個邊界我會刻意留得很清楚。

法規不能交給「模型覺得應該可以」

4 週變形工時、連續工作天數、休息與例休，這些東西不應該讓模型自由理解。

它們應該是明確規則。

能排就是能排。

不能排就是不能排。

所以系統裡應該有一層 deterministic Constraint Engine。

LLM 可以理解：

「正職這週盡量不要再加班。」

但它不能自己決定：

「我覺得這樣應該還合法。」

法規與硬限制必須是可驗證的。

這樣才能把「AI 建議」和「正式班表」分開。

AI 改班表，也不能直接改

如果店長說：

「週五晚上多一個吧台，優先兼職。」

我也不想讓系統直接把某個人塞進去。

應該先出 Diff。

例如：

原本 18:00–22:00 吧台 1 人

建議增加某位兼職 4h

影響

本週工時 +4h
不產生加班
崗位資格符合
法規安全

然後店長按：

套用變更

正式班表才真的被改掉。

這跟我做其他系統的邏輯其實一樣：

AI 可以提出動作，但最後改變正式狀態的那一下，要讓責任的人看得見。

真正的智慧不是排完，而是排完會學回來

如果系統每週都重新算一次，但永遠使用同一套規則，那其實只是一個很高級的排班計算機。

真正有意思的是下一段。

系統可以自動拿回：

原本預估客流
實際客流
原本建議人時
店長最後採用的人時
實際出勤
實際人時

然後問：

這一輪到底估得準不準？

例如：

預估 650 客。

建議 184h。

店長最後排 178h。

實際 622 客。

實際出勤 176h。

這些資料本來就存在 POS 與 HR。

所以不需要叫店長再多填一份「今天排得好不好」。

系統自己就能拿實際結果回來校準下一輪。

這時候「相似營運日」也會自己變強。

今天發生過的真實營運，明天就會成為新的歷史樣本。

Learning Hub 到這裡才真的開始有第二種價值

我很喜歡這個專案的一個地方，是它會讓原本不同的系統開始接起來。

Learning Hub 原本看起來是訓練系統。

它記錄：

誰學過什麼。

誰通過什麼。

誰在哪個崗位成熟度比較高。

但到了 Smart Scheduling，這些資料不再只是「學習紀錄」。

它開始直接影響：

誰能被排去哪裡。

也就是：

Learning Hub 產生能力事實。

Smart Scheduling 使用能力事實。

同樣地：

POS 產生營運事實。

HR 產生工時與身份事實。

Smart Scheduling 只是把這些事實重新安排成一個新的決策流程。

這也是我現在越來越在意的方向。

不是每做一個新系統，就多一座孤島。

而是原本系統產生的資料，會開始成為下一個系統的輸入。

所以我真正想做的不是「AI 自動排班」

如果最後只是按一個按鈕，AI 自動吐出一張班表，我反而覺得沒那麼有趣。

我真正想做的是：

POS 告訴系統生意需要什麼。

Learning Hub 告訴系統誰具備什麼能力。

HR 告訴系統誰現在還有多少工時空間。

店長用人話補充只有現場知道的脈絡。

系統先把需求與人做匹配。

法規把不可能的選項擋掉。

AI 把少數衝突與候補送到店長面前。

店長只處理真正需要判斷的地方。

最後，實際營運結果再回來修正下一輪。

所以 Smart Scheduling 對我來說，最後不是「排班工具」。

它比較像是在做一件事：

把一個原本只能存在店長腦中的營運判斷，拆成可以被資料、規則、AI 與人一起承擔的流程。

而這才是我真正想做的。