所謂「批次」排班，是指從一組精簡的輸入——員工姓名、班別名稱、起始日期與天數——一次產生整個日期化名表，而不是一個手動一個手動把人填入個別班次。Shift Schedule Generator正是這樣運作的：它接受一份包含兩個到五十個唯一員工姓名的清單、一到四個班別名稱、一個以 YYYY-MM-DD 格式撰寫、介於 2000 到 2099 之間的實際起始日期，以及一到三十一天的天數範圍，接著以確定性的輪詢方式把每一個每日班次指派給一位員工。完整的日期化表格會顯示在頁面上，而同樣的列也能以 CSV 下載，因此批次輸出是一個可驗證的成果，而不是一連串零散的小編輯。由於規則是固定的——每一個接續的時段會輪到下一位員工，並在清單結尾時繞回開頭——以同樣通過驗證的輸入再次執行，會產生同樣的列，這讓草稿在套用任何真實世界的規則之前，容易審查、分享與修改。
「批次」對排班而言代表什麼
在排班的討論中，「批次」通常與「互動式」相對——一次指派一個班次、互換兩個人，或是在月曆上拖曳一個姓名直到整週看起來合適。相對地，批次產生會一次到位地從原始資料（名單與班次）回傳每一個日期化的指派結果。這個差別在小型團隊需要一個透明的初稿、尚未引入任何限制條件求解器、考勤機或人力資源系統時尤其重要。在日後以不同起始日期或略有不同的團隊再次執行同一個架構時，這個差別也很關鍵，因為確定性的批次輸出在建構上就是可重現的。每當輸入變動就重建整個可見表格的工具，能讓排班保持誠實：沒有隱藏狀態、沒有從前一週殘留的局部結果，也沒有關於某個時段是如何選出的揣測。
產生器接受與拒絕的輸入
產生器強制採用四個有界限的輸入，並拒絕任何會使結果模糊或下載時不安全的內容。每個輸入都會先去除前後空白、進行驗證，並在產生任何指派之前回傳給使用者檢視。
- 員工姓名：至少兩個，最多五十個，每行一個，大小寫不敏感地視為唯一，且限制為六十個字元。「Alex」與「alex」會被視為同一個人，因此第二個項目會被拒絕，而不是被新增為重複項目。
- 班別名稱：一至四個，每行一個，採用與員工姓名相同的有界文字規則。
- 起始日期：YYYY-MM-DD 格式的實際日期，介於 2000 到 2099 之間。該值必須能在 UTC 來回轉換，因此像 2023-02-29 或 2026-04-31 這類不可能的項目會被拒絕。
- 天數範圍：1 到 31 的整數天數，以 UTC 天數推進，這樣日光節約時間的轉換就不會跳過或重複顯示的日期。
產生器還強制採用一條結構規則——員工人數必須至少等於班別數量，這樣演算法就不會把同一個人指派到同一日的兩個不同班次。編輯任何輸入都會清除先前的結果，這能避免當姓名或日期打錯時，過時的表格看起來仍像目前的版本。
輪詢指派規則如何運作
指派規則刻意保持簡單且透明。時段會依日期順序造訪，接著依班別輸入的確切順序進行，而每個時段會輪到清單中的下一位員工，最後一位員工之後會繞回第一位員工。
一個具體例子可以讓這點更明確：假設有三名員工——Alice、Bob、Cara——以及兩個每日班別，名稱為「Morning」與「Evening」，那麼前六個時段依序是 Alice/Morning、Bob/Evening、Cara/Morning、Alice/Evening、Bob/Morning、Cara/Evening，接著該模式會重複。在整個範圍內，每位員工會獲得 ⌈時段數/員工數⌉ 或 ⌊時段數/員工數⌋ 次指派，因此總數最多只會差一次。這就是此工具所聲稱的唯一公平性：總次數平衡，而非現實工作量平衡。
| Day | Shift 1 (Morning) | Shift 2 (Evening) |
|---|---|---|
| 1 | Alice | Bob |
| 2 | Cara | Alice |
| 3 | Bob | Cara |
| 4 | Alice | Bob |
| 5 | Cara | Alice |
這是執行同一個三人、兩班次批次後可能出現的其中一種結果；實際的模式取決於姓名輸入的確切順序，這就是為什麼輸入順序很重要。
逐步產生批次排班
建立批次排班的程序會在目前的分頁中於本機執行於任何現代瀏覽器，因此開始時不需要帳號、登入或上傳。
- 開啟 Shift Schedule Generator 頁面。
- 在第一個輸入中，每行輸入一個員工姓名。至少輸入兩個唯一姓名（大小寫不敏感），最多五十個。在產生之前，請移除空白行與重複項目。
- 在第二個輸入中，每行輸入一個班別名稱。使用一到四個班別，並確認員工人數至少等於班別數量，這樣同一人就不會在同一日被指派到兩個不同班次。
- 在 YYYY-MM-DD 欄位中輸入起始日期。請挑選 2000 到 2099 之間的實際日期；此工具會拒絕像 2023-02-29 或 2026-04-31 這類不可能的值。
- 選擇範圍為 1 到 31 的整天數。更大的數值會被拒絕，以保持表格回應流暢並易於逐列檢查。
- 點擊產生動作。完整的日期化表格會顯示在頁面上，並同時顯示每位員工的指派次數。
- 檢查每一列。如果姓名錯誤或日期打錯，請編輯輸入——先前的結果會自動清除——然後重新產生。
- 當表格看起來正確時，下載 CSV。檔案使用 Date、Shift、Employee 三個標頭，每個儲存格都加上引號，並將任何內嵌的引號加倍，這樣姓名中的逗號與引號就能保持為資料。
- 將結果視為草稿。在工具之外另行套用可用性、資格、休息時段、中場休息、加時上限，以及任何勞動或工會規則，可以透過編輯 CSV 或將其匯入專屬的人力系統來進行。
頁面上的表格與 CSV 所顯示的內容
頁面上的表格與下載的 CSV 保證會顯示相同的列。CSV 開頭為依此順序的三個標頭——Date、Shift、Employee——每個儲存格都會被引號包圍。如果姓名中包含逗號、引號或換行符，內嵌的引號會加倍，這是一般的 CSV 跳脫慣例。下載只會在成功產生排班之後才會建立；暫時性的物件 URL 在下載後或分頁關閉時會被撤銷，因此過時的檔案無法悄悄對應到較新的輸入。這項契約讓 CSV 可以安全地透過電子郵件分享，或貼入試算表作為起點，同時讓原始計算保留在產生它的瀏覽器分頁中。
為何平衡的草稿仍需要真實世界的規則
輪詢草稿只回答一個問題——如果每個人都被視為可互換，誰要覆蓋哪一個日期化的時段——除此之外別無其他。產生器明確不會收集可用性、請假需求、資格、年資、地點、簽約工時、休息、加時、休息時段、人事成本、工會規則、無障礙需求，或特定司法管轄區的勞動要求。它不是限制條件求解器、薪資系統、考勤機、合規稽核或疲勞風險評估。僅靠指派次數的平衡，並不能證明一份名單是安全、在所有相關意義上公平、合法、人力充足，或適合特定工作場所的。
對於實際的名單，請手動或在專屬系統中套用這些缺少的檢查：確認每個人具備其被指派班別的資格、向員工本人直接核實可用性、加入休息與交班註記、檢視連續日模式是否造成疲勞，並依需求核對覆蓋率。如果有人無法執行顯示出來的指派，請編輯下載的工作表，或使用支援必要限制條件的排班工具，而不是單獨信賴輪詢結果。
隱私與資料所在位置
所有員工姓名、班別名稱、起始日期以及產生的排班，都會保留在目前的瀏覽器分頁中。不會有任何員工清單被上傳、儲存在帳號中，或傳送至排班服務；這項嚴格的契約是透明且可測試的：驗證有界限且唯一的輸入、確認實際的 UTC 起始日期、以輪詢順序填入每個時段、讓指派總數差距不超過一、完整顯示結果不截斷，並將這些列完全一致地匯出為安全加上引號的 CSV。控制字元與試算表公式前置詞在匯出前也會被拒絕，因此貼上的 CSV 無法在下游試算表中悄悄觸發重算。這種僅限本機的行為，讓產生器適用於早期規劃或敏感的團隊名單，同時仍保留在實際限制條件變得重要時，將 CSV 移轉到更強大系統的彈性。
如果您正在權衡選項，Create a Microsoft Teams Shift Schedule From a Roster對此有詳細說明。