我是老師，這支團隊處理的很多活跟學生有關：批改、成績、名冊、出席。這代表團隊的工作範圍裡永遠飄著一類絕對不能出事的資料——學生個資。

今天講我們怎麼守這條線。先講結論：不靠自覺，靠程式。

第一道：個資根本不進工作區

最有效的防護是物理隔離。學生的名冊、成績、批改結果，全部放在一顆獨立的隨身碟裡，不在雲端、不在版本控制、不在任何會同步出去的資料夾。

團隊的批改工具設計成「工具在版本庫、資料在隨身碟」：程式碼可以公開檢視，跑起來的時候才去隨身碟讀資料，跑完的產物也落在隨身碟。工具跟資料的分離是架構級的，不是紀律級的。

主指令另有一條配套：學生的姓名、學號、成績、私訊內容，不寫進任何筆記。當下 session 用完就忘。連「流水帳」都不准出現。

第二道：提交前的內容掃描

但物理隔離擋不住手滑。總有一天，某個測試檔、某份匯出的名單，會被不小心放進要提交的資料夾。

所以第二道是掛在版本控制上的自動掃描：每次提交前，程式掃一遍要進版本庫的內容，找學號格式的字串。命中就擋下，提交失敗。

有一個設計細節值得講：掃內容，不掃檔名。

第一版的直覺是列黑名單檔名——名冊.csv、成績.xlsx 之類。很快就發現沒用，因為會出事的檔案都長得無辜：test.txt、output.json、備份0607.md。個資不會乖乖待在叫「個資」的檔案裡。

改成掃內容之後，判斷依據變成「裡面有沒有長得像學號的東西」，跟檔案叫什麼名字無關。骨架大概是這樣（掛在 git 的 pre-commit 上）：

# pre-commit：掃「即將進版本庫的內容」，不是掃檔名
if git diff --cached | grep -Eq "<學號的格式樣式>"; then
  echo "🚫 疑似學號入鏡，提交攔下"
  exit 1
fi
exit 0   # 沒命中要明確回 0，不然乾淨的提交也會被 grep 的結束碼誤擋

真正的樣式當然比一行 grep 講究（要排除課號、電話這類長得像的數字），但原理就這樣：擋在 --cached 這一層，等於擋在「即將離開你控制範圍」的最後一刻。

這道防線是事故換來的

老實講，它不是先見之明。2026 年 6 月 7 日出過一次事，之後才建的。

事故本身處理掉了，但它逼我們面對一個問題：在那之前，防線就是「大家小心一點」。而「小心」在一支成員會 24 小時做事、動作比你快十倍的 AI 團隊裡，是不成立的防護等級。

人會累、會趕時間，AI 會熱心過頭。兩邊都不適合當防線。防線要嘛是物理的（資料根本不在那裡），要嘛是自動的（程式每次都檢查）。

第三道：開機自檢

掃描程式掛在版本控制的掛鉤上，但掛鉤設定有可能因為換機器、重裝而失效，而且失效是無聲的，它不會通知你「我沒在跑了」。

所以開機流程裡加了一步：session 開始時自動確認掛鉤還掛著，沒掛就補上。防線本身也要被監控，不然你以為有防線，其實只有曾經有過防線。

給同樣要處理敏感資料的人

三道防線的邏輯可以搬去任何場景：

一、最敏感的資料做物理隔離，讓「洩漏」在架構上不可能，而不是在流程上被禁止。二、擋在出口，不擋在入口，內容掃描放在「即將離開你控制範圍」的那一刻。三、防線要自我檢查，無聲失效的防線比沒有防線更危險。

明天講兩台機器怎麼共用一個腦：同步、衝突，跟那些「在另一台機器上明明好好的」。