待過的現場・大專院校學生宿舍管理
學校宿舍點名系統：刷卡紀錄很完整，但它證明不了學生在哪裡
我們為一所大專院校的學生宿舍做過點名與警示系統，走校園門禁整合的路子：不換既有刷卡機，直接讀取門禁資料庫的紀錄。這一頁不列功能，寫的是這一行外人不會知道的事，以及動工前該先弄清楚什麼。
這一行，外人不會知道的事
- 刷卡只能證明人在機器前。刷卡機記下的是卡號、時間與機器位置。學生刷完往哪裡走，紀錄不會寫。把「刷過卡」直接當成「人已經在宿舍」，是最常見的誤會。
- 門禁設備與資料庫都不是我們的。通常由廠商安裝維護，資料庫多半封閉，讀取方式與授權要先談，且不能影響門禁本身的運作。
- 點名用哪一台機器，要先講定。不同位置的刷卡機，意義不同，不能只看機器的名稱。
- 點名時段與名冊一定會變。晚點名的時間、住宿名單、臨時請假，每天都在動。寫死在程式裡，學校就得每次找廠商。
- 日期怎麼算，要先說清楚。晚歸的紀錄算前一天還是當天，連續沒刷卡以整天計還是以小時計，不先定，同一份資料會得出不同名單。
動工之前，我們會先問的事
每一題的答案，都會改變系統該怎麼做。
- 點名要以哪一台刷卡機為準？這台機器只設在大廳嗎？
- 點名時段是固定的，還是每天、每學期都不同？誰有權限改？
- 名冊從哪裡來？學務的學生資料與門禁系統裡的一致嗎？
- 門禁資料庫能不能開唯讀帳號？廠商願意配合到什麼程度？
- 缺勤與異常名單寄給誰？夜裡有沒有人實際在看信？
- 晚歸、外宿、請假的學生，現在怎麼登記？有沒有書面紀錄可以對照？
我們在這個現場做了什麼
做法的核心是不動既有設備，只在旁邊讀資料、算結果。系統給的是提醒，判斷留給宿舍管理人員，目的是協助他們掌握出入狀況。
- 門禁資料：定時讀取門禁資料庫的原始刷卡紀錄，包含刷卡時間與刷卡機編號。刷卡機不更換、不加裝。
- 點名判定：點名機與時段存在後台參數裡可以調整。時段內在指定的點名機刷卡的學生記為已點名，時段外的刷卡不計入當晚結果。
- 連續無刷卡通報：點名結束後，檢查名單內的學生前兩個整天是否有任何刷卡紀錄。兩天都沒有的，列入缺勤警示。
- 排程寄信與後台查看：點名失敗名單與缺勤警示依排程經 SMTP 寄出。點名成功、點名失敗與缺勤警示也都能在後台查詢。
如果你也在這一行，可以先想的事
- 先不要讓系統判斷學生去了哪裡。刷卡紀錄只是線索，當成定論，會讓人跳過該查的事。
- 先確認讀得到資料，再談功能。資料庫讀不到，點名規則再好也派不上用場。
- 不必用系統取代夜間巡視。系統排出名單，查證仍由人處理。
- 名單含學生個資，收件對象要先定。誰能收到、保存多久，上線前講清楚。
適合來談的人：大專院校的學務處、總務處與宿舍管理單位，以及需要為校園門禁做整合或二次開發的弱電工程商與系統整合商。
常見問題
學校宿舍點名系統需要更換現有的刷卡機嗎？
不需要。系統讀取既有門禁系統資料庫裡的刷卡紀錄，刷卡機維持原狀。能不能讀、要怎麼讀，要先確認該門禁系統的資料庫結構與授權。
現有門禁系統不好加規則，可以做門禁系統二次開發嗎？
可以先評估。系統只讀取門禁資料，產生點名與缺勤結果，不改動門禁硬體與控制功能。是否可行，要先確認該系統的資料庫與授權。
學生刷完卡就離開，系統能確定他有沒有回寢室嗎？
不能確定。刷卡紀錄只能證明學生在那台刷卡機前刷過卡。系統給的是提醒，最後由宿舍管理人員查證。
宿舍想做刷卡自動點名，應該從哪裡開始？
先問清楚點名結果給誰看、何時要看，再確認門禁資料能不能讀。先在一個棟別試用，比一次全校上線穩。
這個案例實際用的技術：ASP.NET Core（.NET 8）、Dapper、SQL Server、Angular、Serilog、SMTP。技術跟著問題走，不是重點。