本章目標

本章以一間有兩位醫師的台灣自費診所為例，建立可在手機上完成的預約 MVP。完成後，使用者可以選擇服務、醫師與時段，取得預約編號並使用安全連結取消；櫃檯可以查看每日預約、報到與未到紀錄。

這不是病歷系統，也不處理問診、診斷、處方或健保申報。把範圍守住，是這個案例最重要的產品決策。

為什麼這一章重要

電話和 LINE 人工預約看似簡單，卻會讓櫃檯反覆確認同一批資訊：哪位醫師有空、使用者是否改期、休診日是否已同步，以及臨時取消後能不能釋出時段。直接做一張表單仍會產生超額預約，因為兩個人可能同時選到最後一格。

本章的成功標準是：

• 公開頁只顯示可預約時段，不揭露任何患者資料。
• 同一時段不超過設定容量。
• 休診、過期與已滿時段在前端和後端都不可預約。
• 使用者不必建立密碼帳號，也能用不可猜測的管理連結查看或取消自己的預約。
• 櫃檯人員使用個人帳號登入，且操作有紀錄。

思考模型：班表產生可預約時段，預約占用容量

不要手動建立未來一年每一格時間。將資料分成：

• 週期班表：例如王醫師每週一、三下午看診。
• 例外：休診、請假、臨時加診。
• 時段：由班表在指定範圍內產生的可預約單位。
• 預約：使用者占用某個時段的紀錄。

狀態採：

booked -> confirmed -> checked_in -> completed
   |          |             |
   +----------+-------------+-> cancelled
   +---------------------------> no_show

第一版不需要每個狀態都自動化，但資料模型要能區分「取消」與「未到」，否則後續無法改善提醒流程。

開始之前

準備 Lovable Cloud 或 Supabase，將介面設為繁體中文、時區固定 Asia/Taipei。所有人物、手機與預約資料使用虛構內容。

先讓 Plan Mode 檢查範圍：

我要建立單一院所、兩位醫師的自費診所預約 MVP。請先規劃，不要實作。
訪客可選服務、醫師和時段，填姓名、台灣手機與 Email 後建立預約；櫃檯可查看今日名單、確認、報到、完成、取消與標記未到。
系統要處理固定班表、休診、時段容量、同時搶最後一格，以及不可猜測的查詢／取消連結。
不要蒐集病歷、症狀、診斷、處方、身分證字號或健保卡號，也不要加入 AI 問診。
請提出資料模型、狀態圖、角色權限、並行防護、個資最小化、建置順序與驗收矩陣。

步驟 1：建立服務、醫師與班表

核心資料包括：

• services：名稱、預估分鐘數、是否公開、預約說明。
• practitioners：顯示名稱、簡介、是否接受預約。
• practitioner_services：哪些醫師提供哪些服務。
• schedules：星期、開始與結束時間、slot 長度、容量、生效期間。
• time_off：醫師、開始／結束時間、原因分類。
• appointment_slots：醫師、服務、開始／結束、容量、狀態。
• appointments：時段、姓名、正規化手機、Email、狀態、管理 token 雜湊、建立時間。

資料庫保存標準時間，顯示與排程一律轉為 Asia/Taipei。介面明確顯示年月日、星期與上午／下午，避免只寫「03/05 09:00」。

步驟 2：產生有限範圍的時段

每晚產生未來 30～60 天的時段即可。產生器要避免重複，並先套用班表，再排除 time_off。修改班表不應偷偷刪除已有預約的時段；遇到衝突要列入櫃檯待辦。

建立三組測試資料：正常開放、只剩一格、休診。先驗證時段資料，再做漂亮日曆。

圖 24-1：公開頁先選服務，並在最上方清楚標示測試環境與非急診提醒。

步驟 3：完成手機預約流程

流程使用漸進式選擇：服務 → 醫師 → 日期 → 時段 → 聯絡資料 → 確認。每一步保留目前選擇，返回上一步不清空資料。

表單只收姓名、手機、Email。備註欄若保留，旁邊寫明「請勿填寫病情、病歷或其他敏感醫療資訊」。頁面也要說明：本系統不提供急診或醫療建議，緊急情況請使用適當的緊急醫療管道。

請建立診所公開預約流程，以 390px 手機畫面為優先。
依序選服務、醫師、日期與時段，最後才填姓名、台灣手機與 Email。
只顯示未過期、未休診且仍有容量的時段；日期用 Asia/Taipei 顯示完整年月日與星期。
表單不要詢問症狀、病史、診斷、身分證字號或健保卡號。
成功頁要顯示預約編號、服務、醫師、時段、取消方式與非急診提醒。

實際選擇初診諮詢、林醫師與日期後，畫面同時呈現「僅剩 1 位」「尚有名額」與不可選的「已額滿」。這些狀態仍要由後端在送出時重新確認。

圖 24-2：同一日期的時段清楚區分剩一格、仍有容量與額滿。

圖 24-3：表單只收姓名、手機與 Email，並提醒不要輸入病情、病歷或健保資料。

使用虛構聯絡資料完成送出後，成功頁顯示不可猜測的預約編號、服務、醫師、台北時區與聯絡取消方式。

圖 24-4：預約成功畫面保留必要資訊及非急診提醒，不顯示醫療內容。

步驟 4：用後端操作占用時段

create_appointment 必須在後端：

1. 檢查時段仍開放、未過期且未被休診覆蓋。
2. 鎖定該時段或使用能防止競爭的資料庫操作。
3. 計算 booked/confirmed 等有效預約數。
4. 尚有容量才建立預約。
5. 產生高熵管理 token，只將原始 token 顯示一次，資料庫保存雜湊。

前端看到「剩一格」不代表一定成功；若同時被別人訂走，顯示友善訊息並回到替代時段，而不是建立超額預約。

步驟 5：安全地查詢與取消

訪客透過包含管理 token 的連結查看單筆預約。後端以雜湊比對，且回應只包含該預約的必要資訊。token 不應出現在分析工具、公開錯誤訊息或櫃檯列表網址。

取消時再次顯示預約資料並要求確認。成功後更新 cancelled_at、釋出容量並寫入事件。重複取消回傳「已取消」，不能拋出技術錯誤。

若診所有取消期限，例如看診前 4 小時，將規則放在後端並顯示聯絡方式；不要只停用前端按鈕。

步驟 6：建立櫃檯今日列表

櫃檯登入後看到今天的預約，依時間排序，並可切換全部、待報到、已報到、已完成、未到。操作按鈕要符合狀態，例如 cancelled 不可報到。

新增 appointment_events，每次狀態變更保存預約、事件、操作者、時間、舊狀態、新狀態與原因。事件只新增，不覆寫歷史。

圖 24-5：櫃檯依時間查看遮罩名單；每種狀態只提供合理操作，取消項目不能報到。

權限：

步驟 7：處理休診與衝突

管理者新增休診時，系統先列出受影響預約，不直接刪除。確認後關閉空時段，已有預約則建立「待聯絡改期」工作。工作人員逐筆聯絡並記錄結果。

請新增休診管理流程。
管理者建立 time_off 前先列出受影響的 appointment slots 與有效預約。
空時段可以關閉；已有預約不得刪除，改為建立 reschedule_required 事件與櫃檯待辦。
每次處理都要記錄操作者、時間、原時段、新時段或取消原因。
櫃檯不能修改醫師班表，只有管理者可以。

步驟 8：驗證而不是展示

使用兩位訪客、櫃檯與管理者測試：

1. 兩人競爭容量 1 的時段，只有一人成功。
2. 休診、過期與已滿時段從前端隱藏，直接呼叫後端也失敗。
3. 錯誤 token 不能讀取或取消預約。
4. 重複送出不建立兩筆相同預約。
5. 取消後容量立即可用，事件保留。
6. 櫃檯能報到但不能改班表或提升角色。
7. 管理者建立休診時不會刪掉已有預約。
8. 公開 API 不會列出姓名、手機或 Email。

請驗證診所預約 MVP。
模擬兩位訪客同時預約最後一格，並測試過期、額滿、休診、重複送出、錯誤管理 token、重複取消與跨權限操作。
用訪客、櫃檯和管理者三種身分驗證資料存取。
逐項列出預期、實際、資料庫事件與畫面證據；不要使用真實患者資料。

實作練習

建立「初診諮詢」與「回診」兩種服務、兩位醫師與一週班表。準備正常時段、容量 1 時段與休診日。完成公開預約、token 查詢、取消、櫃檯報到與休診衝突處理。

預期成果是所有容量變更都有一致資料來源，訪客無法列舉預約，櫃檯能完成日常工作，但系統沒有蒐集任何醫療內容。

常見錯誤

• 日曆漂亮但沒有並行防護： 最後一格必須由後端決定。
• token 直接存明文： 資料庫外洩時會變成可用的管理連結，應保存雜湊。
• 休診直接刪除時段： 會遺失既有預約，應先產生待辦。
• 備註變成問診欄： 第一版應拒絕蒐集醫療細節。
• 所有櫃檯共用帳號： 無法知道誰改了狀態。

上線前檢查清單

• [ ] 時區固定且跨午夜、星期顯示正確。
• [ ] 最後一格並行測試通過。
• [ ] 休診與已有預約衝突有人工流程。
• [ ] 管理 token 高熵、只顯示一次並保存雜湊。
• [ ] 訪客不能列舉或讀取他人預約。
• [ ] 櫃檯與管理者權限分離。
• [ ] 狀態變更均有不可覆寫事件。
• [ ] 未蒐集病歷、症狀、診斷或健保資料。
• [ ] 隱私說明、取消規則與緊急情況提醒可見。
• [ ] 桌面與手機流程都已驗證。

延伸閱讀

• Lovable Cloud
• Lovable security
• Supabase Row Level Security
• 全國法規資料庫

名詞解釋與延伸提問

• Slot（時段）：可被預約的固定時間單位。
• Time off（休診例外）：覆蓋正常班表的請假或停診期間。
• 高熵 token：難以猜測、具有足夠隨機性的秘密字串。
• 資料最小化：只蒐集完成明確目的所需的資料。

你可以接著問 Lovable：「請依我的醫師班表、取消期限與櫃檯角色，產生專屬的並行測試與權限矩陣。」下一章會加入改期、LINE 提醒、報到與資料保存治理。

嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。

如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：

📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。

📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。

🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。

如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！

🎁 免費送 Lovable 額度給讀者！

我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。

參加方式：

1. 訂閱本系列文章
2. 分享任一篇系列文章
3. 私訊分享截圖及你的 Lovable 帳號 Email

確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！