昨天，我們終於把 CORS、Proxy 這些東西處理完了。
登入也能登入了，Cookie 也會乖乖帶著跑，前端跟後端總算可以正常講話。
所以今天，總算可以開始做這套系統真正的核心功能了。
廣播？
對。
畢竟這東西叫「校園文字廣播系統」。
寫到第 18 天還沒有開始做廣播，好像多少有點說不過去。
確實。
所以今天要開
broadcast的 Model 了？
……
先等等。
又怎麼了？
在寫之前，我突然想到一個問題。
我們到底為什麼需要「廣播」？
蛤？
因為這是廣播系統啊。
這不是廢話嗎？
你前幾天也很常講廢話啊。
咳。
我的意思是，如果今天重新做一套系統，我們真的還需要把 21 年前那套廣播的使用方式原封不動搬過來嗎？
先回去看看現在的系統。
| 編號 | 呼叫人 | 呼叫
日期 | 呼叫
時間 | 事由 | 呼叫
對象 | 確認
狀態 | 確認者 | 報到
狀態 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 33 | 教學組幹事 | 10-02 | 11:12 | 請通知副班長確實於今日16:30將教室日誌交回教務處班級櫃 | 進行回覆 | 準時 | 高二114班資訊股長 | |
一則廣播大概就是這樣。
誰發的、發了什麼、什麼時候發，然後還有查看回覆、準時之類的操作。
放在二十年前，這套邏輯其實很合理。
老師有事情要通知學生，就丟一則廣播；學生看完之後，再透過系統留下回覆。
但現在問題來了。
如果學生看完廣播之後有問題呢？
回覆啊。
那如果學生今天不是對某則廣播有問題，只是單純想找老師呢？
……
如果老師只是想提醒某個學生：
「欸，你等等記得來找我。」
這也要發一則正式廣播嗎？
好像有點怪。
對。
我們其實把兩種完全不同的需求，塞進同一套系統裡了。
假設老師發了一則廣播：
明天早上 07:30，請資訊股長到資訊中心領取設備。
結果資訊股長明天早上剛好要值日。
他真正想做的事情可能只是問：
老師，我明天早上要值日，可以 07:40 再過去嗎？
老師回：
可以。
結束。
這整段對話沒有什麼需要正式公告的，也沒有必要再發第二則廣播。
它需要的就只是一個很普通的即時通訊（Messaging）。
而且這件事情不應該只能從廣播開始。
學生本來就可能有事情需要主動找教師。
所以新版系統裡，我想加入一套簡單的即時通訊功能：
學生 ←────────→ 教師
即時通訊
學生可以主動聯絡教師，教師也可以回覆學生。
如果問題是從某則廣播延伸出來的，那就直接把那則廣播引用進對話裡。
例如：
┌──────────────────────────┐
│ 關於這則廣播 │
│ 明天 07:30 至資訊中心…… │
└──────────────────────────┘
老師我明天早上要值日，
可以 08:40 再過去嗎？
可以。
這樣不是自然多了嗎？
那既然都能直接傳訊息了……
我們還要廣播幹嘛？
……
好問題。
假設老師今天傳了一句：
明天記得把同意書交給我。
學生沒看到。
隔天老師問：
你怎麼沒交？
學生：
我沒看到訊息。
然後事情就開始變得有趣了。
因為這時候我們在意的，已經不只是：
「老師有沒有把這句話送出去？」
而是：
「這項資訊有沒有正式通知到對方？」
甚至更進一步：
「對方有沒有確認自己知道這件事？」
這就是我認為廣播不能直接被即時通訊取代的原因。
即時通訊適合讓人把事情講清楚。
但有些事情，我們需要留下的不只是一串聊天紀錄。
我們需要知道：
這些東西，才是「廣播」真正有價值的地方。
所以我想把新版的兩套機制切得更清楚一點：
即時通訊 Messaging
│
├── 日常溝通
├── 提醒
├── 詢問
└── 針對廣播進一步討論
廣播 Broadcast
│
├── 正式通知
├── 明確發布者
├── 明確通知對象
└── 可以查核通知與確認狀態
簡單來說：
即時通負責溝通，廣播負責責任。
聽起來很帥。
但「負責責任」是什麼鬼中文？
……
反正你懂就好。
既然要讓廣播負責這件事情，那還有一個問題要拆開。
假設學生點開了一則廣播。
系統可以知道：
已讀
那這是不是代表他已經確認收到？
我認為不是。
因為「我打開了這個頁面」和「我知道這件事情，而且確認收到」其實是兩回事。
所以新版的廣播至少需要把兩件事情分開：
已讀
↓
已確認
至於「已送達」到底該怎麼算——是寫進資料庫就算、送到瀏覽器才算，還是真的要讓使用者的裝置收到才算——這又是另一個坑，今天先不挖。
目前我們真正需要處理的，是「看過」跟「確認過」的差別。
其中「已讀」可以由系統記錄。
但「已確認」必須是使用者主動做出的操作。
例如：
[確認收到]
按下去之後，我們才能留下：
蘇同學
2026/10/02 14:39
已確認收到
那我直接在聊天室打「收到」呢？
不算。
為什麼？
因為聊天是聊天，確認是確認。
你今天可能打：
收到，我等等問一下。
也可能打：
好。
甚至：
6。
我要怎麼知道哪一句代表你正式確認了？
用 LLM（大語言模型）？
你不要什麼都想丟給 LLM。
自然語言可以拿來溝通，但如果這個狀態之後需要被查核，那就應該讓它成為一個明確、結構化的操作。
所以：
聊天室：「收到」
≠
廣播：[確認收到]
這兩件事情，我打算刻意分開。
這裡還有一個很容易混在一起的東西。
假設今天的廣播是：
明天因颱風停課。
學生按下「確認收到」。
這代表：
我知道明天停課。
而不是：
我同意明天停課。
所以這個確認比較接近 Acknowledgement（知悉／確認收到），而不是 Agreement（同意）或 Approval（核准）。
同樣地，它也不代表：
我已經完成廣播要求的事情。
所以我想先替新版廣播劃一條界線：
廣播負責的是「通知責任」，不是「執行結果」。
老師可以透過系統確認學生是否已經知道「星期五以前要交同意書」，但學生到底有沒有真的把同意書交出去，是另一件事情。
假設廣播內容是：
請於星期五以前繳交同意書。
學生星期一按了「確認收到」，只能證明他知道星期五以前要交。
不能代表他已經交了。
所以這幾件事情也要分開：
Read
我看過了
Acknowledged
我知道了
Agreed
我同意
Completed
我做完了
至少目前的廣播，我只打算處理前兩個。
其他真的有需求，再另外設計。
不然一顆「確認」按鈕承擔四種意思，遲早會出事。
不過，只要開始談「確認」，其實馬上又會冒出另一個問題。
如果一則已經有人確認過的廣播，被老師修改了呢？
學生原本確認的是修改前的內容，還是修改後的內容？修改之後需不需要重新確認？
……
好。
這個坑我們之後再挖。
兩套系統分開，不代表它們互不相干。
反而我希望它們可以很自然地互相連接。
例如學生看到：
┌──────────────────────────────┐
│ 明日 07:30 請至資訊中心集合 │
│ │
│ 江老師 · 10/02 14:32 │
│ │
│ [詢問教師] [確認收到] │
└──────────────────────────────┘
如果內容很清楚：
[確認收到]
結束。
如果有問題：
[詢問教師]
系統就直接打開自己與發布教師原本的對話，並引用這則廣播。
注意，是打開跟教師的對話。
不是每發一則廣播，就建立一個五百人的大型聊天室。
好險。
不然我大概不是在重寫數位校園。
是在重寫 Discord。
而且反過來也一樣。
即時通可以用來提醒：
你還有一則廣播尚未確認。
但真正的確認操作，仍然回到廣播本身完成。
這樣兩套系統的責任就不會混在一起。
寫到這裡，我覺得可以回答一開始的問題了。
我們到底為什麼還需要廣播？
因為即時通訊解決的是：
「人跟人之間怎麼把事情講清楚？」
而廣播解決的是：
「重要的資訊，怎麼留下明確的通知與確認紀錄？」
所以新版數位校園不會只是一套廣播系統。
它會有兩種互補的通訊方式：
校園通訊
┌─────────┴─────────┐
│ │
Messaging Broadcast
即時通訊 廣播
│ │
把事情講清楚 把責任講清楚
好，所以規則想完了。
明天總可以開始寫廣播了吧？
嗯……
還有一個小問題。
……
既然只有老師可以發廣播……
等等。
我們現在確實已經知道「你是誰」了。
但——
我們好像還沒真正處理「你能做什麼」。
……
你是不是有個 RBAC 放在那邊十幾天沒動了？
……
好像是。
明天把它挖出來。
iThome鐵人賽
看影片追技術