階段 4：用自然語言客製診所規則
選一項不涉及病人的排班規則，先寫成可驗收需求，再讓 Claude App 的 Code 功能在既有安全通道內修改；這是成就感最高，也最需要控制範圍的一段。
17
學完這一課，你會做到
- 把口語規則轉成清楚的輸入、限制與驗收
- 要求 Claude 保留既有功能與安全設定
- 用正常、邊界與衝突三種情境驗收客製功能
開始前先定位
你在這裡一日工作坊：本機四階段實作
先用 repo 內建的瀏覽器 localStorage 跑起模板、完成排班與客製規則；這一段不安裝資料庫，也不要求雲端同步。
完成證據Checkpoint 4
一項客製規則已在本機練習模式通過正常、邊界、衝突與回歸驗收；Claude App 的 Review changes 只包含預期範圍。請 Claude 說明後單獨核准清楚命名的 commit，再另行核准 push，並…
本課先不做不要讓自由客製穿越安全邊界
若需求開始涉及登入、角色、Security Rules、病人資料、HIS、付款或跨診所資料，立刻停止。這些不是多寫一句 prompt 就能安全完成的功能，需另行設計、審查與測試。
本課名詞階段 4客製規則邊界測試回歸
適合今天做的客製
| 需求 | 今日可做 | 先不要做 |
|---|---|---|
| 某虛構醫師週三不排班 | 加入排班限制與提示 | 連接真實人事資料 |
| 每診至少兩名虛構助理 | 顯示人數不足警示 | 自動決定真實人事安排 |
| 班次備註 | 新增不含個資的短文字欄位 | 記錄病人、療程或請假原因 |
| 列印週班表 | 改善列印畫面 | 寄送到外部未核准服務 |
客製規則範本
目標：當任一班別的虛構助理少於 2 人時，顯示「人力不足」警示。
背景：現有週班表可新增與修改班別，目前仍使用本機練習模式。
限制：不要自動替人排班；不要加入病人欄位；不要填 Firebase config、不要新增 SQLite 或修改資料層；如需資料結構變更先停下說明。
驗收：0、1 人時顯示警示，2 人以上不顯示；重新整理後結果一致；既有醫師排班與休假功能仍通過。請先列出計畫、風險與測試案例。三層驗收
- 正常情境：資料符合規則時，畫面與操作如預期。
- 邊界情境：剛好在門檻值，例如恰好兩名助理。
- 衝突情境：休假、重複排班或空白資料時，不應產生錯誤結果。
- 回歸檢查：再做一次階段 3 的核心流程，確認沒有被客製功能破壞。
階段 4 完成畫面對照：規則區會列出助理不足的班別。圖中週一早診只有 1 名助理，因此顯示 1/2；加入第 2 名後，該班警示必須消失。
- 0 人與 1 人時顯示「人力不足」，並標出日期、班別與目前人數。
- 恰好 2 人時不再警示；這是本階段最重要的邊界測試。
- 警示只提供資訊，不會擅自替任何人排班。
Checkpoint 4
一項客製規則已在本機練習模式通過正常、邊界、衝突與回歸驗收；Claude App 的 Review changes 只包含預期範圍。請 Claude 說明後單獨核准清楚命名的 commit，再另行核准 push，並到 GitHub 核對最新版本。下一課會先用 Vercel 讓這個 localStorage 版本上線。
參考資料
介面與方案會改版；實際操作仍以各工具官方頁面為準。延伸資料用來幫助理解，不取代本課安全原則。
低壓力自我檢查
客製備註欄最安全的課堂測試內容是？
準備好再標記完成完成狀態會留在這台裝置，下次回來可接著學。