20261103｜國泰世華｜信用卡授權中心24小時智慧排班系統需求訪談

目前的訪談已經確定系統的基本目標：為信用卡授權作業單位的 15 位同仁，自動產生每月 24 小時輪班表，並考慮工時法規、人員安排及歷史班表查詢。

我們先完成需求訪談與工作說明書（SOW），暫不建立系統或寫入 Google Drive。

接下來有五個關鍵問題。這些問題會直接影響排班演算法、資料結構與前端功能。

[提交訪談回答]

可先回答確定的項目，其餘留待下一輪討論。

這五題完成後，下一輪會進一步確認臺灣勞動法規適用條件、休息與加班計算、例外排班處理，以及 HTML 系統的實際使用環境。

工作說明書預計包含： 專案目標與範圍、功能需求、排班規則與優先順序、模擬資料規格、前端操作流程、系統架構、驗收標準，以及 Google Drive 歸檔與交接規範。

其中最重要的是第一題：每個時段需要幾位授權人員同時值勤？ 這會決定現有 15 人編制能否在合理工時與休假條件下滿足每月排班需求。

AI 的工作過程（點開看）

已搜尋 8 個網站

處理時間為 8s

20261103｜國泰世華｜信用卡授權中心智慧排班系統需求訪談（二）

第一輪訪談已確認五項基本需求。第二輪應優先確認各班最低人力、班次時間、休假制度及人員輪調方式。這四項將直接決定 15 人編制是否足以支援全年無休的授權作業。

一、第一輪已確定的需求

項目	已確認規格
使用單位	信用卡授權作業單位
排班人數	15 位同仁
服務時間	每日 24 小時、全天候運作
排班週期	每月自動產生班表
班別制度	固定三班制，每班 8 小時
人力配置	白天與夜間需求不同，具體人數待確認
排班限制	必須考慮輪班間的休息時間
排班核准	系統產生班表，由主管確認
歷史資料	初期採模擬資料，支援查詢前一個月班表
前端介面	HTML，可選擇人員並查詢班表
資料模擬	建立 15 位虛構員工的基本資料
專案交接	未來歸檔於 Google Drive「國泰世華」資料夾，附交接文件

目前尚未決定的關鍵事項，是 15 人是否足以提供所需的人力覆蓋率，以及系統如何在法規、人員休假與排班公平性之間進行取捨。

二、法規初步確認

依臺灣《勞動基準法》，一般正常工時每日不得超過 8 小時、每週不得超過 40 小時；正常工時與延長工時合計每日原則上不得超過 12 小時，另須遵守加班時數限制。

輪班制在更換班次時原則上至少應有連續 11 小時休息。符合公告適用範圍並完成法定程序，才可能採行不低於 8 小時的例外安排。[工時制度及工作彈性化措施介紹-勞動部全球資訊網中文網; 條文內容 資料來源：勞動部勞動法令查詢系統-勞動基準法]

因此，工作說明書會將法定限制、銀行內部規定及主管排班偏好分開定義，避免系統產生表面上完整、實際上無法執行的班表。

三、第二輪訪談：請回答以下五題

依目前選擇估算（每班 8 小時、每天均維持相同需求）

小時

每日最低值勤人時

人

每週 40 小時基準所需人數下限

此為純工時估算，尚未納入休假、國定假日、交接、教育訓練及實際排班可行性。

---

其他補充（選填）

[多行文字欄位預留文字：例如：週末各班人數不同、某些同仁只能上日班、實際交接時間等]（無法取得目前的值。）

[提交第二輪訪談回答]

四、後續工作說明書的規格範圍

完成本輪訪談後，將進一步整理為可供開發與驗收的工作說明書，包括：

• 排班引擎： 工時、休息、休假、輪調規則，以及人力不足的例外處理。
• 資料設計： 15 位模擬員工、班別、歷史班表、排班版本與主管核准紀錄。
• HTML 使用介面： 月曆班表、個人班表、人員篩選、上月紀錄與違規提示。
• 作業流程： 產生草案、檢查限制、主管確認及保存歷史版本。
• 驗收條件： 人力覆蓋、合法工時、跨月休息檢查、資料正確性及排班結果可重現。
• 交接與歸檔： 系統規格、模擬資料、操作說明、測試結果及 HANDOFF.md。

第二輪最需要確認的是各班最低人數。只要這項資訊確定，就能初步判斷 15 人編制是否具備足夠的工時容量，並辨識哪些排班需求可能彼此衝突。

AI 的工作過程（點開看）

已搜尋 4 個網站

處理時間為 35s

20261103｜國泰世華｜信用卡授權中心排班系統可行性評估與第三輪需求訪談

一、初步結論：15 人具備充足的基本排班容量

根據第二輪訪談，15 位同仁足以支援目前設定的每日三班、共 5 個值勤人力名額。不過，仍須確認銀行內部休假規定、15 人是否全部投入輪班，以及夜班如何輪調，才能判定每月班表是否真正可行。

已確認的班別配置

班別	時間	每班人數	每日人時
早班	07:00-15:00	2	16
中班	15:00-23:00	2	16
夜班	23:00-次日07:00	1	8
合計	24 小時	5	40

基本人力容量試算

280

每週需求人時

600

15 人每週正常工時容量

46.7%

值勤需求占正常工時容量

---

假設每人每週正常工時上限為 40 小時，尚未扣除休假、教育訓練、其他工作與不可排班時間。

以 30 天月份為例，排班需求為 150 個八小時班次，合計 1,200 人時。如果平均分配給 15 人，每人約需值勤 10 班、80 小時。

這意味著需要確認一個重要問題：其餘工作時間，這 15 位同仁是否還負責其他信用卡授權相關業務？

若 15 人都以排班值勤為唯一工作，系統必須處理大量未被指派至最低值勤名額的工作日；若部分工時用於其他作業，則需要將這些工作列為排班限制。

此處的 46.7% 是工時容量利用率，不能直接視為銀行實際的人力利用率或生產力。

二、排班法規與特殊風險

查核勞動部及《勞動基準法》後，有三項必須寫入工作說明書的規則。

1. 換班休息間距： 第 34 條規定，更換班次時原則上至少連續休息 11 小時，例外縮短至 8 小時須符合公告適用範圍及法定程序。[條文內容 資料來源：勞動部勞動法令查詢系統-勞動基準法; 勞動基準法第34條第2項但書適用範圍-勞動部全球資訊網中文網]
2. 每月換班制度： 第 34 條原則上規定每週更換一次班次，但經勞工同意可另行安排。因此，已選定的每月輪換制度，還需要確認同仁同意及銀行內規。[條文內容 資料來源：勞動部勞動法令查詢系統-勞動基準法]
3. 例假及休息日： 一般工時制度每七日應有兩日休息，其中一日為例假、一日為休息日。若採合法的彈性工時制度，計算方式可能不同。[勞動基準法-全國法規資料庫; 勞動基準法第36條所定之例假、休息日，如何與一般正常工時或彈性工時配套執行？-勞動部全球資訊網中文網]

此外，夜班跨越午夜，系統必須使用完整日期與時間計算，不能只比較班別名稱。

例如：

跨月換班範例

11 月 30 日 23:00

夜班開始

12 月 1 日 07:00

夜班結束

如果 12 月 1 日立即安排早班，便會出現時間重疊；即使安排當天中班，也只有 8 小時的換班休息間距，原則上未達 11 小時。

因此，系統需要讀取前一個月最後幾日與下一個月最初幾日的班表，以檢查月初、月底的連續工時及休息安排。

三、工作說明書 V0.3：目前需求狀態

功能或規則	狀態
15 位模擬員工	已確定
三班時間及最低人數	已確定
每月自動產生排班	已確定
每月輪換班別	已確定，須核對勞工同意與內規
主管確認班表	已確定
排班不足顯示缺額	已確定
休假及工時計算	待取得適用制度
15 人其他工作安排	待確認
同仁能力、資格限制	待確認
HTML 介面及資料保存	部分確定
正式資料來源	暫採假資料
Google Drive 歸檔	待規格完成後執行

下一階段需要釐清的是，這套系統究竟只管理每天 5 個最低值勤名額，還是要安排 15 人的完整工作與休假時間。兩者的開發範圍差異相當大。

四、第三輪需求訪談

本輪共有五題，主要確認系統的實際排班範圍及管理方式。

---

補充說明（選填）

[多行文字欄位預留文字：例如：銀行內部特殊排班要求、特休申請方式或目前的實務困難]（無法取得目前的值。）

[提交第三輪訪談回答]

不確定的問題可以保留未回答，後續會列入工作說明書的待確認事項。

第三輪完成後，預計形成工作說明書 V0.4，進一步確定功能模組、資料欄位、排班演算法的限制條件、主管操作流程，以及實際驗收方式。

建議第一版先以 15 位虛構員工與完整月份的模擬資料進行驗證。 先確認是否能產生符合人力需求、休息規定及每月輪換要求的班表，再決定是否需要正式資料庫及銀行內部系統整合。

AI 的工作過程（點開看）

規劃工時框架

我先查核官方勞動規範，區分例假、休息日、輪班間隔、國定假日與待命時間。接著檢視三組人力和每週班次容量，修正整組每月輪調可能造成的休假彈性不足問題。

規劃工時框架

已搜尋 6 個網站

處理時間為 1m 22s

20261103｜信用卡授權中心｜智慧排班系統工作說明書 V0.4

文件版本：V0.4 日期：2026/11/03 狀態：需求確認階段

建議將本專案定義為「15 人完整工時管理與 24 小時授權值勤自動排班系統」。

根據三輪訪談，已具備編製工作說明書的主要條件，可以確定第一版的功能範圍、資料架構與驗收標準。目前尚有三項關鍵業務規則，需要進行第四輪、也是最後一輪的需求確認。

本版僅進行規格設計，不建立程式、不產生模擬資料，也不變更 Google Drive。

一、專案目標與範圍

本系統預計協助銀行信用卡授權中心，管理 15 位同仁的每月工作安排，確保每日 24 小時都符合最低值勤人數，並自動處理休假、工時限制、月度班別輪換，以及主管核准流程。

第一版採用單機 HTML 操作介面，使用虛構員工資料、模擬班表及本機檔案匯入匯出功能，不連接銀行內部人事系統。

已確認的核心需求

類別	規格
排班人數	15 位，均具備所有班別的值勤資格
排班期間	每月產生完整班表
早班	07:00-15:00，最低 2 人
中班	15:00-23:00，最低 2 人
夜班	23:00-次日 07:00，最低 1 人
完整工時	包括授權值勤、其他工作及休假
工時制度	一般每週正常工時 40 小時
休假制度	每七日一例假、一休息日
輪調制度	每位同仁每月固定班別，次月依早、中、夜順序輪換
人力不足	顯示缺額，由主管決定處理方式
核准方式	系統產生班表，主管確認
資料來源	第一版全部使用模擬資料
系統部署	單機 HTML，使用檔案匯入與匯出
歷史查詢	至少支援上一個月班表
專案歸檔	未來放置於 Google Drive「國泰世華」資料夾

二、15 人編制可行性分析

以一週七天、每人正常工時 40 小時計算

280

每週最低授權值勤人時

600

15 人正常工時容量

320

扣除最低值勤後剩餘人時

46.7% 授權最低值勤需求 53.3% 其他可安排工時

320 人時為理論差額，尚未扣除國定假日、特休、請假、教育訓練及其他不可用時間，也不代表必須安排滿 600 人時。

判斷：整體總工時足夠，但班別分組方式可能造成局部人力不足。

例如，若 15 人被分成三組，每組 5 人，並且每個月整組輪換，則每週的配置如下：

班別	每週最低需求班次	5 人每週最多正常工作班次
早班	14	25
中班	14	25
夜班	7	25

理論上各班都有餘裕，但也會有相當多的人力需要安排其他工作。

如果採用依最低人力比例分組，例如 6 人早班、6 人中班、3 人夜班，並將三組整組輪調，則原本的 3 人夜班組輪換到早班時，每週最多只有 15 個正常工作班次，卻需要覆蓋 14 個值勤班次。這會使休假、臨時請假與教育訓練安排非常緊迫。

所以，工作說明書必須進一步區分「每人固定月班別」與「每月固定整組輪換」的差異。

三、功能規格

建議第一版分成六個模組，並將需求編號，供開發、測試及驗收使用。

編號	模組	必要功能
F01	人員管理	建立、編輯及查詢 15 位虛構員工，設定班別與工作狀態
F02	自動排班	選擇月份，自動產生所有員工的授權值勤、其他工作及休假安排
F03	規則檢查	檢查最低值勤人數、正常工時、例假休息日、換班休息間距及跨月衝突
F04	班表查詢	查看全體月班表、指定員工班表、每日各班人力與上月紀錄
F05	主管核准	產生草案、顯示缺額與違規、主管確認、保存已核准版本
F06	資料交換	JSON 匯入／匯出完整資料，CSV 匯出班表，支援備份與還原

排班演算法的處理順序

建議依照下列順序執行排班：

讀取資料

員工、上月班表、休假、月份及規則設定

確定每人本月班別

依輪換順序及人力需求分配早、中、夜班

先安排休假，再安排授權值勤

遵守工時限制，滿足每日最低人數

安排其他工作時間

將其餘可工作時段分配至其他授權相關業務

檢查限制及產生報告

缺額、工時、跨月衝突、休假與班別分配統計

提交主管確認

核准並匯出，或退回重新產生

演算法須以法規及必要人力需求為硬性限制。當條件無法同時滿足時，系統應回報不可行原因與缺額，不得自行忽略限制或產生看似完整的班表。

若主管確認含缺額的班表，系統必須保留「尚未解決缺額」狀態，不能將其標示為全部符合要求。

四、資料結構規格

建議第一版使用下列資料表的概念設計 JSON 結構，未來可轉換為資料庫。

資料類別	主要欄位
員工資料	員工代碼、虛構姓名、值勤資格、是否參與排班、輪換群組
班別資料	班別代碼、開始時間、結束時間、最低人數
工作紀錄	員工、開始與結束時間、工作類型、所屬排班月份
休假資料	員工、日期、例假／休息日／特休／其他假別
排班結果	排班月份、版本、產生時間、各班人員、缺額
核准紀錄	版本、確認者、確認時間、確認結果、未解決事項
規則設定	工時上限、休息間距、輪換順序、最低人數、規則版本

特別注意：其他工作應有明確工作時段，不能只記錄「今天有工作」。 否則無法正確檢查工時及換班間隔。

單機 HTML 的設計邊界

第一版建議使用瀏覽器本機儲存功能保存操作中的草案，並以 JSON 匯出作為正式備份。CSV 主要用於檢視與分析，不宜作為唯一備份格式，否則可能遺失排班規則、休假類型、核准紀錄及版本資訊。

因為是單機操作，第一版的主管核准屬於操作紀錄，尚不具備銀行正式系統所需的身分驗證與不可竄改稽核能力。

五、法規與內規待確認事項

以下以一般工時制度作為第一版規格基準。

規則	V0.4 處理方式	依據
每日正常工作上限 8 小時	預設硬性限制	勞基法第 30 條 [勞動部勞動法令查詢系統-條文內容]
每週正常工作上限 40 小時	預設硬性限制	勞基法第 30 條
每七日一例假、一休息日	預設硬性限制，須跨月檢查	勞基法第 36 條 [勞動部勞動法令查詢系統-條文內容]
每月更換班別	依需求設計，須確認勞工同意	勞基法第 34 條 [條文內容 資料來源：勞動部勞動法令查詢系統-勞動基準法]
換班休息 11 小時	更換班次時原則上適用，不預設例外縮短	勞基法第 34 條
連續工作期間休息	納入休息安排規則	勞基法第 35 條 [勞動部勞動法令查詢系統-條文內容]
國定假日與特別休假	初版納入資料類型，實際安排依規定	勞基法第 37、38 條 [勞動基準法-全國法規資料庫]
其他工作時間	須納入工時統計與休息檢查	業務需求

11 小時規定主要適用於輪班制員工更換班次時，不能直接解釋為所有固定班別之間均一律適用的法定 11 小時規則。初版可另設較嚴格的內部休息門檻，但必須標明為系統管理規則。

另一項需要確認的，是授權人員在 8 小時班內如何實際休息及由誰代理值勤；否則即使排班表滿足最低人數，也可能無法確保休息期間的服務不中斷。

六、工作假設

以下條件尚未經訪談確認，僅供原型設計使用。

1. 所有員工均為全職，不考慮兼職、跨部門支援或不同工時契約。
2. 早、中、夜三班的最低人力需求，在平日、週末及國定假日均相同。
3. 其他工作可安排在員工當月所屬班別時段內，且計入正常工作時間。
4. 暫不自動安排加班、休息日出勤或跨班支援，以免引入未確認的授權與工資計算規則。
5. 每位員工每個曆日以一個主要班次或休假狀態為原則，夜班跨日使用實際日期時間判斷。
6. 模擬資料至少包含前一個月、本月及次月必要的跨月銜接紀錄。

上述假設應能透過設定調整，不宜直接寫死在演算法中。

七、驗收標準

第一版交付後，建議以 28、30、31 天月份，搭配跨月換班及人力不足案例進行驗收。

測試編號	驗收情境	通過標準
T01	正常月份產生班表	15 人全月工作、休假狀態完整，無未安排日期
T02	每日最低人力	早班 2、中班 2、夜班 1，且每人不得同時重複值勤
T03	正常工時	所有正常排班符合每日 8 小時、每週 40 小時限制
T04	例假與休息日	所有員工符合適用的每七日休假規則
T05	月度輪換	每人依確認後的輪換制度轉換班別
T06	跨月休息	月底與月初連接時不發生工時重疊或違反換班休息規則
T07	人力不足	系統明確顯示日期、班別、缺額及原因
T08	主管確認	可儲存草案與已確認版本，保留確認時間及未解決事項
T09	歷史查詢	能查詢指定員工上個月的完整班表
T10	資料交換	JSON 匯出再匯入後，資料與規則一致；CSV 可正確開啟
T11	可重現性	相同資料、規則及指定隨機種子能重現相同排班結果
T12	異常資料	遺漏員工、無效時間或衝突紀錄均有明確提示

應另外建立人力不足、多人同日請假及假日值勤的負面測試案例，確認系統不會為了完成排班而違反硬性限制。

八、第四輪：最後三項關鍵規格確認

這三題會直接影響排班演算法及第一版的完成定義。

[提交第四輪回答，整理正式工作說明書 V1.0]

九、預定交付項目與專案歸檔

正式開發階段預計交付單機 HTML 排班系統、15 人模擬資料、跨月班表、JSON／CSV 匯入匯出、測試案例與結果、操作說明、正式工作說明書，以及 HANDOFF.md 交接文件。

Google Drive 將以「國泰世華」為上層資料夾，建立獨立的信用卡授權中心排班專案。交接文件須記錄資料結構、排班規則、演算法處理順序、測試結果、尚未完成的功能與後續擴充方式。

目前的專案決策：建議保留單機 HTML 作為第一版，先驗證完整工時與值勤安排是否一致，再評估多人操作與正式銀行系統整合。

第四輪三項問題確認後，正式 SOW V1.0 即可作為開發與驗收的主要依據；銀行內規及員工月度輪調同意等尚待查核事項，則列為正式上線前必須完成的確認條件。

我會整合四輪已確認的決定，並特別檢查「每月整組輪換」與「其他工作固定白天」是否會造成工時或休息時間衝突。正式工作說明書會把已確定的規格與上線前待確認條件分開記載。

AI 的工作過程（點開看）

已搜尋 5 個網站

處理時間為 15s

經四輪訪談，工作說明書 V1.0 已具備明確的開發範圍。不過，第四輪確認的「其他工作固定白天」與「每人整月固定早、中、夜班」之間存在排班衝突，必須在規格中明確處理。

例如，夜班人員 07:00 下班後，無法再從 07:00 開始執行其他日間工作；中班人員 15:00 上班，也不能在同一天另外完成 8 小時日間工作。若允許不同工作類型合併安排，系統必須檢查總工時及換班休息間距。勞動部亦明確指出，輪班人員更換班次時，原則上應有連續 11 小時休息。[條文內容 資料來源：勞動部勞動法令查詢系統-勞動基準法; 六、輪班換班間距： （一）原則： ▼ 勞動基準法第34條第2項前段 ▲ 勞工工作採輪班制者，其]

因此，V1.0 採用以下設計決定：保留使用者確認的業務規則，但將衝突排班列為不可自動核准的情況；系統須提出缺額與原因，交由主管決定。 不預先放寬法規或改變既定班別。

以下為正式工作說明書全文。

**document: **

信用卡授權中心智慧排班系統

工作說明書（Statement of Work, SOW）

版本： V1.0
編製日期： 2026 年 11 月 3 日
專案對象： 信用卡授權作業單位
專案階段： 需求確認完成、待開發
規格依據： 四輪需求訪談
開發狀態： 尚未開始
文件用途： 開發依據、測試驗收、專案交接

---

第一章　專案背景與目標

1.1 專案背景

信用卡授權中心採取每日 24 小時、全年無休的作業模式，需要安排 15 位同仁輪流執行授權作業，並兼顧其他日間工作、例假、休息日及其他依法應安排的休假。

目前希望建立一套自動排班系統，減少主管每月編製班表的工作負擔，同時提高人力配置透明度，降低工時違規、休息不足及值勤缺額的風險。

1.2 專案目標

本專案預計達成六項目標：

1. 自動產生 15 位同仁每月完整工作與休假班表。
2. 確保每日三個班別達到最低授權值勤人數。
3. 支援三組人員每月依早、中、夜順序輪換。
4. 自動檢查工作時間、休假與換班間距限制。
5. 支援主管確認、缺額顯示、歷史查詢及資料匯出。
6. 建立可供後續維護與擴充的程式、測試及交接文件。

1.3 第一版開發定位

第一版為單機操作的功能驗證原型。

採用 HTML、CSS 與 JavaScript 建立操作介面，使用 15 位虛構員工及模擬資料，不連接銀行正式人事系統、授權系統或內部資料庫。

原型需具備實際運作的排班演算法、規則檢查與資料匯入匯出功能，不以靜態畫面代替排班功能。

---

第二章　已確認業務需求

2.1 人員與班別

班別	工作時間	最低值勤人數	每日最低人時
早班	07:00-15:00	2	16
中班	15:00-23:00	2	16
夜班	23:00-次日 07:00	1	8
合計	24 小時	5	40

上述人數為最低值勤要求，不代表各班只能安排相同人數。

2.2 人員配置與輪換

15 位員工分為 A、B、C 三組，每組 5 人。

三組人員每月整組輪換，輪換順序固定為早班、中班、夜班、早班。

初始月份分配如下：

群組	第一個月	第二個月	第三個月
A 組	早班	中班	夜班
B 組	中班	夜班	早班
C 組	夜班	早班	中班

三個月為一個完整輪換週期。

員工在同一月份原則上固定所屬班別，月底及月初切換時，須檢查跨月休息時間及已排定的工作紀錄。

所有員工的授權值勤資格相同，不設定資深與資淺搭配的必要條件。

2.3 其他工作

15 位同仁除授權值勤外，亦可能負責其他信用卡作業。

其他工作原則上固定於白天執行。

系統必須將授權值勤及其他工作計入同一員工的總工時，避免同一時段重複安排工作。

對於中班及夜班人員，若日間工作與固定班別、休息時間或其他限制發生衝突，應將該工作標示為未能安排，交由主管決定。

其他工作不預設每人每天均須安排，也不得為了填滿正常工時而自動創造不存在的工作需求。

2.4 工時與休假

採一般工時制度作為第一版基準：

• 每日正常工作時間不超過 8 小時。
• 每週正常工作時間不超過 40 小時。
• 每七日安排一日例假及一日休息日。
• 計算工時與休假時必須連續檢查跨月資料。
• 員工換班休息間距原則上採 11 小時。
• 初版不主動安排加班、休息日出勤或例假出勤。

工時與休假限制應以實際工作起訖時間及銀行適用的法定週期計算。

2.5 主管作業

系統產生班表後，由主管進行確認。

若班表存在人力缺額，系統須顯示日期、班別、缺額人數與原因。

主管可以確認已知缺額的處理狀態，但系統不能因此將尚未補足的人力標示為已符合最低需求。

第一版不開發員工自行換班、線上請假申請或多人同時協作功能。

---

第三章　人力配置與可行性

3.1 基本工時需求

三班每日合計需要 5 個值勤人次，每個班次 8 小時。

因此：

• 每日最低授權值勤需求：40 人時。
• 每週最低授權值勤需求：280 人時。
• 30 天月份最低授權值勤需求：1,200 人時。
• 31 天月份最低授權值勤需求：1,240 人時。

15 位員工以每週 40 小時計算，理論正常工時容量為每週 600 人時。

每週扣除最低授權值勤需求後，尚有 320 人時的理論差額，可供其他工作使用。

此數字尚未扣除特休、國定假日、請假、教育訓練與其他不可用時間。

3.2 固定群組可行性

每組 5 人，正常情況下每週每人最多安排 5 個八小時工作日，故單組每週最多安排 25 個正常工作班次。

早班與中班各需 14 個值勤班次，夜班需 7 個。

三組在正常條件下具備基本值勤容量，但並不代表任何休假組合都能成功排班。

例如多人集中請假、特定日間工作需求、跨月換班或其他工作與授權值勤同日安排，都可能降低實際可用人力。

3.3 其他工作與固定班別的衝突

其他工作固定於白天，將與中班及夜班形成時段衝突。

原型須將以下情況明確區分：

1. 工作時間直接重疊：禁止排入。
2. 工作時間未重疊，但同日總工時超過限制：禁止自動排入。
3. 工作時間未重疊，但違反適用的換班休息限制：禁止自動排入。
4. 工作時間與正常工時相容，但其他工作需求不明：保留未分派工作時數，不自行補滿。
5. 不同工作可在同一個八小時班內分段進行：只有取得明確的工作時段與必要人力需求後，才允許排入。

第一版不得假設中班或夜班人員能在完成固定班別之外，再額外執行完整八小時日間工作。

3.4 可行性判定方式

排班系統需輸出三種結果：

可行： 所有硬性限制符合要求，且值勤人力完整。

部分可行： 法規與時間限制均符合，但存在值勤缺額、其他工作未分派或未完成的休息替補安排。

不可行： 已設定的條件彼此衝突，無法產生符合硬性限制的完整班表。

部分可行及不可行結果必須提供具體原因，不可只顯示排班失敗。

---

第四章　法規與內規

4.1 法規參考

第一版以臺灣《勞動基準法》為主要法律依據。

法規	檢查重點
第 30 條	正常工作時間
第 32 條	延長工作時間及相關限制
第 34 條	輪班更換與換班休息間距
第 35 條	連續工作期間的休息
第 36 條	例假及休息日
第 37 條	國定假日
第 38 條	特別休假

正式開發前應再次查核適用版本，並確認銀行是否具有其他經核准的特殊工時安排。

4.2 待確認的適法性事項

L01：每月輪換同意

勞基法第 34 條以每週更換班次為原則，經勞工同意可另行安排。因此須確認每月輪換的相關同意程序。

L02：換班休息間距

每月換班時，原則上須符合連續 11 小時休息要求。初版不預設銀行適用 8 小時例外。

L03：法定休息日週期

應確認銀行實際採用的每七日週期起訖日，不能每逢新月份就重新計算。

L04：班內休息與人力替補

勞基法第 35 條對連續工作與休息有相關要求；輪班或連續性工作得依法調配休息時間。

原型需顯示最低值勤人數是否可能受到人員休息影響，正式上線前應確認替補安排。

L05：國定假日與特別休假

須確認銀行的國定假日出勤、補休、特休及其他休假規定，第一版先提供資料欄位及檢查介面。

4.3 法規規則管理原則

法定硬性限制不得由主管任意關閉。

銀行內部較嚴格的限制可以透過設定檔管理。

未取得適用法規依據或必要核准程序的例外，不得直接納入自動排班引擎。

---

第五章　系統功能規格

F01　員工資料管理

系統需預先建立 15 位虛構員工。

每位員工至少包含：

• 員工代碼
• 虛構姓名
• 所屬群組
• 可值勤班別
• 是否參與排班
• 目前班別
• 上個月班別
• 可工作狀態
• 已安排休假

使用者可選擇特定員工，查看其月班表及工作時數。

F02　自動排班

使用者選擇月份後，系統依照群組輪換、最低人力需求、休假及工時限制，自動產生班表。

排班範圍包含：

• 授權值勤
• 其他日間工作
• 例假
• 休息日
• 已知其他假別
• 未分派工作時間

系統應能重複產生不同排班方案，並保存排班規則及版本。

F03　規則檢查

必須檢查：

• 每日各班最低人數
• 同一員工的時間重疊
• 每日及每週正常工時
• 例假及休息日
• 連續工作日數
• 月份交界的換班時間
• 其他工作與授權值勤衝突
• 未安排或超額安排工時
• 缺額及休息替補風險

所有異常都必須記錄規則代碼、發生時間、影響人員及原因。

F04　班表查詢介面

HTML 介面至少包含：

1. 全體月班表
2. 個人月班表
3. 每日三班值勤明細
4. 員工群組與輪換資訊
5. 當月工作時數統計
6. 人力缺額與規則檢查結果
7. 上個月歷史班表

夜班必須清楚標示跨日的開始及結束時間。

F05　主管確認

班表狀態分為：

• 草案
• 待確認
• 已確認且符合要求
• 已確認但仍有未解決缺額
• 因硬性限制衝突而不可核准

系統記錄確認人員的模擬代碼、確認時間、班表版本及結果。

原型不宣稱具備銀行正式身分驗證或不可竄改的稽核功能。

F06　資料匯入與匯出

支援：

• JSON 完整資料匯入
• JSON 完整資料匯出
• CSV 班表匯出
• CSV 員工工時統計匯出
• 模擬資料還原
• 歷史版本備份

JSON 備份必須包含員工資料、班表、規則設定、輪換起始月份、跨月紀錄及確認紀錄。

匯入時需檢查資料結構及版本相容性。

F07　異常報告

系統應提供可供主管判讀的異常報告，包括：

• 哪一天缺少人力
• 哪個班別不足
• 缺少幾人
• 哪項限制阻止排班
• 哪些員工仍有可用工時
• 哪些問題需人工處理

系統不得自動以違反硬性限制的方式補足人力。

---

第六章　排班演算法規格

6.1 排班輸入

輸入包括：

1. 目標月份。
2. 15 位員工資料。
3. 三個班別的起訖時間與最低人數。
4. 三組人員當月輪換位置。
5. 前一個月必要的工作及休假紀錄。
6. 已確認休假及不可工作日期。
7. 其他日間工作的需求。
8. 適用工時與休假規則。

6.2 硬性限制

硬性限制至少包括：

• 員工不得在時間重疊的工作中重複出勤。
• 不得超過正常工時限制。
• 不得違反適用的例假及休息日規則。
• 換班時須符合適用的休息間距。
• 員工僅可擔任其具備資格的工作。
• 不得在已核定假期安排一般工作。
• 不得以違反上述規則的方式補足值勤缺額。

每日最低值勤人數為必須盡力滿足的業務要求；當與硬性限制衝突時，須保留缺額並回報。

6.3 最佳化目標

在硬性限制均符合的前提下，建議依序追求：

1. 最小化授權值勤缺額。
2. 維持固定群組與月度輪換要求。
3. 滿足已確認的其他工作需求。
4. 平衡同組員工的值勤班次及休假分布。
5. 降低不必要的工作日變動。
6. 在符合需求的多個方案中，選擇工作分配較均衡者。

第一版的公平性以同一群組、相同資格及相同可用條件的人員進行比較，不強求早、中、夜班每月工作內容完全相同。

6.4 排班流程

步驟一： 載入員工、歷史班表、休假及規則。

步驟二： 計算三組人員本月的早、中、夜班分配。

步驟三： 保留已核定休假，建立必要的例假與休息日安排。

步驟四： 將每日授權值勤需求分配至相對應群組。

步驟五： 在不違反限制的情況下，安排已知的其他日間工作。

步驟六： 檢查每日、每週與跨月工時限制，以及換班間距。

步驟七： 嘗試重新分配尚未滿足的值勤需求。

步驟八： 無法合法補足時，記錄缺額、未分派工作與原因。

步驟九： 輸出班表、工時統計、異常報告與排班版本。

步驟十： 提交主管確認。

6.5 排班可重現性

系統須記錄：

• 排班演算法版本
• 規則版本
• 輸入資料版本
• 目標月份
• 隨機種子（若使用隨機分配）
• 排班結果版本

相同資料、限制條件及隨機種子，應能重現相同結果。

---

第七章　資料架構

7.1 主要資料實體

資料實體	必要資訊
Employee	員工識別碼、姓名、群組、資格、狀態
Shift	班別代碼、時間、最低人數
Assignment	員工、工作起訖、工作類型、排班版本
Leave	員工、假別、日期、核定狀態
Rotation	群組、基準月份、輪換順序
RuleSet	適用工時、休假、輪換及人力規則
Schedule	月份、版本、產生時間、整體狀態
Validation	規則代碼、嚴重程度、異常內容
Approval	確認者、時間、版本、結果

7.2 時間資料

所有工作紀錄均須使用完整日期與時間。

夜班記錄為當日 23:00 開始、次日 07:00 結束。

系統應統一使用臺灣時區，避免跨日及跨月計算錯誤。

7.3 資料保存

原型可使用瀏覽器本機儲存機制保存工作草案。

正式備份由使用者匯出 JSON 檔案完成。

關閉網頁後重新開啟，應能透過有效的備份檔還原資料。

不得將模擬資料誤標為真實銀行員工資料。

---

第八章　使用者介面

8.1 首頁

顯示：

• 目前排班月份
• 本月輪換群組
• 排班完成狀態
• 值勤缺額
• 工時及休假異常
• 待主管處理事項

8.2 月班表

以日期為橫軸、員工為縱軸，呈現 15 人完整月班表。

以明確顏色及文字標籤區分早班、中班、夜班、其他工作、例假、休息日與其他假別。

不能只使用顏色區分狀態。

8.3 個人查詢

使用者可選擇任一員工，檢視：

• 本月班表
• 上月班表
• 本月總工作時數
• 授權值勤時數
• 其他工作時數
• 休假分布
• 所屬群組與下月班別

8.4 異常報告

提供依日期、員工及問題類型的篩選功能。

若發生缺額，清楚顯示所需人數、已安排人數及差額。

8.5 核准與匯出

主管可確認排班版本，並匯出完整班表及檢查報告。

已確認版本不得被新排班結果直接覆蓋。

---

第九章　測試與驗收

9.1 功能驗收

編號	測試內容	通過條件
T01	15 人模擬資料	所有虛構員工及群組資料可正確顯示
T02	三班排班	能產生全月三班及完整員工工作休假紀錄
T03	最低值勤人力	各班足額或明確標示缺額
T04	每月群組輪換	三組依早、中、夜順序正確輪換
T05	每日工時檢查	無超出已設定正常工時上限的自動排班
T06	每週工時檢查	依已設定的法定週期正確計算
T07	例假及休息日	符合採用的一般工時休假規則
T08	跨月換班	能識別違反適用換班休息間距的排班
T09	日間工作衝突	中、夜班人員不會被重複安排重疊工作
T10	人力不足	能呈現日期、班別、缺額與原因
T11	歷史查詢	能讀取上一月份完整班表
T12	資料匯入匯出	匯出再匯入後資料與規則一致
T13	主管確認	保留確認時間、版本及未解決問題
T14	可重現排班	相同輸入及設定得到一致結果
T15	無法滿足的限制	不產生違規結果冒充成功排班

9.2 測試月份

至少測試：

• 28 天月份
• 30 天月份
• 31 天月份
• 連續三個月群組輪換
• 前月底至次月初的跨月換班
• 多位同仁同日請假
• 中、夜班額外日間工作衝突
• 值勤人數不足
• 班內休息替補風險
• 無效或缺漏資料

9.3 驗收通過條件

所有核心功能測試必須通過。

法規與工時的硬性限制不得出現未被檢出的違反情形。

對於特意設計的人力不足及衝突案例，系統須正確回報，不要求所有測試案例都能排出無缺額班表。

資料匯入匯出不得遺失必要欄位。

至少一個正常月份及一組連續三個月輪換測試，須能產生符合全部已確認規則的班表；若真實需求及限制本身無可行解，應提出可重現的不可行性報告，經專案負責人審核後再決定是否調整規格。

---

第十章　交付項目

正式開發階段須交付：

1. index.html：單機排班系統入口。
2. assets/：必要的樣式及程式模組。
3. sample_employees.json：15 位虛構員工資料。
4. sample_schedules.json：跨月份模擬班表。
5. rules.json：可檢視的排班規則設定。
6. test_cases/：正常及異常測試資料。
7. test_results.md：測試項目、執行結果及未通過原因。
8. SOW_V1.0.md：正式工作說明書。
9. USER_GUIDE.md：操作說明。
10. HANDOFF.md：專案交接。
11. AGENTS.md：開發、驗證與文件維護規則。

正式開發時可依必要性調整檔案拆分，但須保留同等功能及可供交接的完整原始碼。

---

第十一章　專案歸檔與交接

11.1 建議專案位置

Google Drive：

國泰世華 / Credit_Card_Authorization_Scheduling

建議依用途區分：

• 01_Requirements
• 02_Sample_Data
• 03_Source_Code
• 04_Testing
• 05_Documentation
• 06_Handoff

11.2 HANDOFF.md 必須包含

1. 專案目標及目前完成狀態。
2. 使用者確認的業務需求。
3. 已採用及尚未確認的排班規則。
4. 專案檔案位置與用途。
5. 系統架構及資料結構。
6. 排班演算法及限制條件。
7. 程式啟動與資料匯入方式。
8. 已執行的測試及結果。
9. 已知缺陷及限制。
10. 下一階段工作及接手順序。

11.3 獨立審查

正式交付前，應由獨立的審查角色檢查：

• 需求與實作是否一致。
• 法規規則是否有可靠依據。
• 排班計算是否正確。
• 測試是否包含不利情境。
• 文件是否足以讓其他開發者接手。

未完成測試或存在未解決的硬性限制違規時，不得標示為通過正式驗收。

---

第十二章　未納入第一版的功能

第一版暫不包含：

• 銀行正式人事系統整合。
• 正式員工身分驗證。
• 員工自助排休及換班申請。
• 多主管同時協作。
• 自動計算薪資及加班費。
• 自動核准加班或休息日出勤。
• 電子郵件或即時通知。
• 正式資料庫與伺服器部署。
• 正式銀行資訊安全稽核系統。

上述功能需另行評估，不得視為本次開發的既定交付要求。

---

第十三章　工作假設與待確認事項

13.1 暫定工作假設

A01： 每組固定 5 人，初始 A、B、C 組依序分配早、中、夜班。

A02： 三班最低人數不因平日、週末及國定假日改變。

A03： 所有員工均為全職、具備相同授權值勤資格。

A04： 其他日間工作時間、必要人數與可分段程度尚未提供，原型先將其視為可選工作需求，並在排班報告中揭露未分派情況。

A05： 不自動安排加班或違反一般工時制度的出勤。

A06： 例假及休息日的週期起訖暫採週一至週日，正式使用前須確認銀行實際制度。

A07： 第一版不自動指派班內休息代理人，只顯示休息替補可能造成的人力缺口風險。

A08： 主管確認屬原型中的作業狀態紀錄，不等同正式電子簽核。

13.2 正式上線前必須確認

P01：銀行其他日間工作的實際時間、人力需求及是否允許分段執行。

P02：每月整組換班是否已完成必要的員工同意程序。

P03：銀行正式例假、休息日及國定假日的安排規範。

P04：班內休息時如何保持最低授權值勤人數。

P05：實際上線所需的資料權限、身分驗證及稽核要求。

以上事項未確認前，可以開發與測試原型，但不得宣稱已滿足銀行正式上線要求。

---

第十四章　完成定義與專案管制

本專案第一版完成的標準為：

1. 已交付所有必要原始程式及模擬資料。
2. 能在目標瀏覽器環境中開啟並操作。
3. 能依指定月份自動排班。
4. 能正確執行三組每月輪換。
5. 能處理授權值勤、其他工作與休假資料。
6. 能檢查並顯示工時、休假與人力衝突。
7. 能完成歷史查詢及資料匯入匯出。
8. 已執行正式測試並留下結果。
9. 已完成使用說明與交接文件。
10. 獨立審查已確認核心需求、程式及測試結果一致。

本文件未約定實際開發工期、費用、執行人員及正式部署日期，以上應於啟動開發前另行決定。

版本管理

V1.0 為四輪訪談確認的需求基準。

後續如需改變三組輪換制度、日間其他工作安排、工時制度或系統部署方式，應記錄變更原因、影響範圍及新版本，不應直接覆寫本版已確認需求。

文件狀態：V1.0 已編製，尚未經專案委託方正式核定。

目前授權範圍：需求分析與工作說明書編製；不含程式開發、Google Drive 建檔或部署。

五、建議的下一階段決策

我建議 V1.0 作為開發基準，但在進入程式設計時，優先完成兩項驗證。

第一，確認其他日間工作的實際時間與需求。這是目前最可能影響排班結果的未決事項，尤其對中班與夜班人員。

第二，以連續三個月的模擬資料測試三組輪換，確認月末、月初的班別切換、休假及工時規則是否能同時滿足。

法規部分已參照勞動部及全國法規資料庫，主要查證來源為 《勞動基準法》全文、勞動部例假與休息日說明及 換班休息間距例外規定。

本次已完成 SOW V1.0 文字定稿；尚未開發、寫入 Google Drive 或進行實際排班驗收。

我會依照 SOW V1.0 製作可直接開啟的單機 HTML 原型，包含 15 人假資料、三組月輪換、自動排班、個人與全體班表、缺額與工時檢查，以及 JSON／CSV 匯入匯出。會以「其他工作固定白天」為條件，避免自動安排與中、夜班衝突的工作。

前端原型已完成主要畫面與排班邏輯，目前正在檢查產生班表、月份切換、異常提示及檔案匯出。瀏覽器自動化環境限制了直接開啟本機檔案，因此我會改用載入頁面內容的方式測試，並另外檢查程式語法。

AI 的工作過程（點開看）

規劃排班系統

我正在設計單一 HTML 前端，包含月曆、員工篩選、問題檢查、匯入匯出、核准與模擬功能。我會採用可重現的排班演算法，兼顧每日值班需求、每週休息與班次間隔。

調整休息與班次

我會先固定每週兩天休息，再分配早、中、夜班值勤，並以至少 11 小時間隔檢查相鄰工作。非值勤日只在安全時安排日班，跨月資料也會納入驗證。

規劃排班系統並調整休息班次

建立信用卡人員排班前置工作域

完成信用卡排班原型與瀏覽器測試環境驗證

測試本地 HTML 內容載入

完善邊界驗證

我會補上跨月份班次檢查，避免前月末與本月初形成不足 11 小時的間隔；同時強化匯入資料驗證，並準備操作說明與可交付的單一 HTML 檔案。

整理排班原型文件與封裝 ZIP

處理時間為 5m 45s

20261103｜信用卡授權中心｜智慧排班系統 HTML 原型 V1.0

第一版可操作的 HTML 前端已完成。 採用單機設計，無須安裝伺服器，也不需要連接銀行內部系統。

圖像: 信用卡授權中心智慧排班系統的操作畫面

完整專案 ZIP

〔下載 HTML、操作說明及交接文件〕

單一 HTML

〔直接下載 index.html〕

已完成的功能

模組	功能
排班總覽	覆蓋率、授權工時、缺額、待分派工作
自動排班	15 人、三組各 5 人，每月輪換
全體班表	以月曆表格查看所有員工
個人查詢	選擇員工、查看每日安排及工時
規則檢查	工時、休息間距、例假、休息日及值勤缺額
主管確認	確認排班版本，保留未解決風險
資料匯出入	CSV 匯出、JSON 備份及匯入
資料保存	瀏覽器本機儲存

測試結果

已使用 Chromium 執行基本功能測試：

• 2026 年 11 月：授權值勤覆蓋率 100%，共安排 1,200 人時。
• 2026 年 12 月：授權值勤覆蓋率 100%，共安排 1,240 人時。
• 成功顯示 15 位員工及個人月曆。
• CSV、JSON 下載功能可觸發。
• 測試過程未發現 JavaScript 執行錯誤。

上述結果是模擬排班測試，尚未代表銀行正式的法規或營運驗收。

仍待完成的部分

目前其他工作以白天 09:00–17:00 模擬，遇到中、夜班工時衝突時會標示「待分派」。班內休息替補、實際歷史班表的跨月檢查、員工請假與正式法遵驗證，仍屬後續版本工作。

使用方式： 下載 ZIP、解壓縮後，使用 Chrome 或 Edge 開啟 index.html，即可操作完整前端。

本次未寫入 Google Drive，也未部署至公開網站。