1. 案例一頁摘要（30 秒速讀版）
這也不是一個「判斷、決策」的案例，而是一個「省行政補登工時」的例行流程示範。假日值班時，漏水、跳電這類異常大多先靠電話或 LINE 群組口頭轉達，值班人員要一邊處理現場、一邊記得回頭把事情補登到標準的異常通報紀錄表——愈忙愈容易漏登，也愈容易把「暫時恢復」誤認成「已經結案」。這堂 demo 會用一天份、約 60 則的 LINE 群組對話匯出檔，讓你體驗用 Codex／ChatGPT 把整天的對話讀過一遍，抓出所有異常事件、跟現行紀錄表比對出漏登項目，並列出「還沒結案、卡在誰手上」的跟催清單。重點不是誰的分析比較深入，而是：AI 能不能把一整天雜亂的群組對話，正確還原成 9 件事、不多不少、也不把閒聊誤當成事件。
2. 情境背景與量化錨點
情境：2026-07-18（六）為假日值班，樓管、工務、資訊、保全共 7 位同仁在同一個 LINE 群組裡回報與處理各樓層的異常狀況，訊息夾雜貼圖、照片、閒聊、重複轉達。值班主管隔天要看的是一份乾淨的「異常通報紀錄表」，而不是一整串對話紀錄——但現行做法是值班人員憑印象手動摘錄，忙的時候就會漏登。
四個量化錨點：
| 錨點 | 數字 | 資料來源 |
|---|---|---|
| ① 人工補登工時 | 一天 60 則以上訊息，人工逐則篩選、摘錄成標準紀錄表約需 1 小時；本 demo 用 Codex 實測 5 分鐘內可產出補登後完整紀錄表＋跟催清單 | 課程設計錨點（投影片） |
| ② 事件與漏登規模 | 對話中共有 9 件異常事件，現行紀錄表只登了 6 件（漏登 3 件），其中 2 件仍未結案 | G2-6／G2-7 |
| ③ 雜訊比例 | 約 60 則訊息中，真正對應 9 件事件的訊息約 40 則，其餘為問候、貼圖、閒聊、重複轉達——雜訊比例接近三分之一，考驗 AI 與學員能否正確篩選 | G2-6 |
| ④ 結案誤標風險 | 現行紀錄表中有 1 筆（5F美食街F08跳電）結案狀態誤標「已結案」，實際上設備仍待廠商檢修——這種「復原當結案」的誤植，是值班現場最容易發生、也最難靠人工肉眼發現的錯誤 | G2-7／G2-8 |
3. 資料檔清單與每檔重點欄位說明
| 檔案 | 重點欄位 | 這份資料能回答什麼 |
|---|---|---|
G2-6_LINE群組匯出_20260718.txt | 時間、發言人、訊息內容（含 [貼圖]／[照片] 標記） | 事件的第一手來源，所有時間、地點、處理經過都要從這裡逐則還原。 |
G2-7_異常通報紀錄表_現行.csv/.md | 通報時間、樓層櫃位、異常類型、通報人、處理單位、處理結果、結案狀態 | 現行「已登」的 6 件事件，用來跟 LINE 對話比對出漏登與誤標。 |
G2-8_通報紀錄表欄位規範.md | 各欄位定義、結案認定標準 | 判斷「這算不算一件事」「能不能標記已結案」的唯一依據。 |
4. 完整 Work Brief（與投影片一字不差）
「請完成《0718 異常通報補登與追蹤清單》： 1. 只用 G2-6 對話匯出、G2-7 紀錄表、G2-8 欄位規範。 2. 抽出每件事件：時間、樓層櫃位、類型、處理經過。 3. 與紀錄表比對，列出漏登事件並補成標準格式。 4. 標出未結案事件與最後停在誰手上，列跟催清單。 5. 輸出補登後完整紀錄表＋3 行主管摘要；不得編造資料。」
5. 20 分鐘上機流程指引
0–5 分：交代 Brief
本段重點：
- 情境說明：假日值班群組一整天訊息量很大，樓管主管隔天要看的不是聊天紀錄，是一份乾淨的異常通報表——今天讓 AI 幫忙把這件苦差事做完整。
- 範圍限定：只能用 G2-6、G2-7、G2-8 這 3 份，不要自己腦補群組裡沒寫的處理細節。
- 先定義「何謂一件事件」：請你先讀 G2-8 的欄位規範，理解「通報時間」是第一則回報時間、不是處理完成時間，「結案」要同時符合處理完成＋回報者確認兩個條件。
檢查點：閒聊洗版有沒有被當成事件
- 好答案的樣子：你能明確說出「群組裡有貼圖、問候、閒聊，這些不算事件」，並且知道要用「有沒有具體地點＋異常類型＋處理經過」來判斷一則訊息是不是事件的起點。
- 若把「大家辛苦了」「颱風要來注意排水」這類提醒性訊息也算成事件，要留意修正：這是值班提醒，不是異常通報。
5–14 分：抽事件比對漏登
本段重點：
- 先要求 AI 把 9 件事件的時間、地點、類型、處理經過整理成表，再跟 G2-7 現行紀錄表比對，而不是直接叫 AI「幫我補登」。
- 交叉檢查方式：請 AI 逐一列出對話中每件事件對應的原始訊息時間，這樣你才能回查「這件事真的發生在這個時間點」，不是 AI 自己編的。
- 特別留意 7F 是否有兩件不同事件（12:15 影城廁所堵塞、13:22 卡通尼天花板滴水）——因為同樓層、時間相近，容易被誤合併成一件事。
檢查點：每件能否回查到原始訊息時間
- 好答案的樣子：補登後的紀錄表裡，每件事件都能對應回 G2-6 裡具體的「幾點幾分、誰發的、說了什麼」，而不是籠統地寫「7F 有設施異常」。
- 若你整理出的事件清單少於 9 件或多於 9 件，先檢查：有沒有把 12:15 的 7F 廁所堵塞跟 13:22 的 7F 天花板滴水分開處理？這是兩件不同的事，發生在同一個樓層但不同地點、不同時間。
14–20 分：主管修正
成品：補登後完整紀錄表＋跟催清單＋3 行主管摘要
本段重點：
- 完成跟催清單初稿後，主管會用「主管修正」的角度追問：「6F 油煙異味最後停在誰手上？期限是什麼時候？不能只寫『還在查』，要指定 Owner 跟回報期限。」
- 追問 F08 跳電那筆：現行紀錄表把它標成已結案，這跟 G2-8 的結案認定標準對不上——復電不等於結案，設備都還沒讓廠商檢查完，這筆應該怎麼改？
- 最後要輸出 3 行主管摘要：今天共發生 9 件異常、現行紀錄表漏登 3 件已補齊、目前尚有 2 件未結案（含 1 件原本誤標已結案需更正），交代清楚跟催對象與期限。
好答案長什麼樣：
- 跟催清單明確列出「事件、目前卡在誰手上、下一步、預計回報時間」四個欄位，不是空泛地寫「持續追蹤」；
- F08 跳電的結案狀態被明確改正為「未結案」，並附上理由（設備尚待廠商檢修，僅是先行復電）；
- 3 行主管摘要有具體數字（9 件、漏登 3 件、未結案 2 件），不是空泛地說「大致都處理好了」。
6. 埋梗解答（做完再對答案）做完再看
9 件事件狀態總表：
| # | 時間 | 地點 | 類型 | 處理經過摘要 | 紀錄表狀態 |
|---|---|---|---|---|---|
| 1 | 10:05 | 3F 旺柴鍋物外走道 | 漏水 | 空調排水管接頭鬆脫，11:30 修復回報 | 已登、已結案 |
| 2 | 11:40 | 5F美食街F08 | 跳電 | 12:10 復電，但主機板狀況待廠商禮拜一檢查 | 已登、誤標已結案（依 G2-8 標準應為未結案） |
| 3 | 12:15 | 7F影城廁所 | 堵塞 | 14:00 疏通完成 | 漏登 |
| 4 | 13:22 | 7F卡通尼親子餐廳 | 天花板滴水 | 15:00 修復，店家確認無虞 | 已登、已結案 |
| 5 | 14:05 | 6F餐飲區 | 油煙異味 | 工務巡查中，尚未定位確切來源 | 漏登、未結案 |
| 6 | 15:30 | B1動感健身房 | 空調偏熱 | 16:20 調整完成 | 已登、已結案 |
| 7 | 16:12 | 3F A31櫃 | POS斷線 | 資訊 16:40 處理完成 | 漏登 |
| 8 | 17:45 | 1F停車場入口 | 柵欄故障 | 18:30 修復 | 已登、已結案 |
| 9 | 19:20 | 5F客用電梯 | 困人 | 19:40 救出，當晚保養廠商檢修完成回報 | 已登、已結案 |
補充說明：
- 3 件漏登（#3、#5、#7）有一個共同特徵：處理過程相對單純、沒有反覆延續很久，值班人員處理完當下容易覺得「不用特別記」，這正是實務上最常真實發生的漏登模式——愈快解決的小事，愈容易被跳過不登。
- F08 誤標已結案（#2）是本題組最值得展開討論的細節：LINE 對話裡清楚寫著「主機板狀況不確定，已經聯絡廠商禮拜一來檢查」，代表這件事還沒真正落幕，但現行紀錄表卻標成已結案——這是「復電＝解決了」的直覺誤判，跟 G2-8 明訂的「處理完成＋回報者確認」雙條件標準對不上，值得你對照 G2-8 條文明確指出問題所在。
- 7F 兩件事（#3 廁所堵塞、#4 天花板滴水）刻意設計在鄰近時間、同一樓層發生，用來測試你與 AI 有沒有正確辨識「這是兩件不同的事」，而不是因為同樓層就合併成一件。
7. 常見翻車點與修正方法
| 翻車點 | 症狀 | 修正提示 |
|---|---|---|
| 把閒聊或提醒性訊息當成事件 | AI 或你把「颱風要來注意排水」「大家辛苦了」這類訊息也列成一件異常事件 | 「這是值班提醒，不是異常通報——請你回頭確認 G2-8 對『事件』的定義，一件事件要有具體地點、異常類型跟處理經過，不是任何跟工作有關的訊息都算。」 |
| 把同樓層、時間相近的兩件事合併成一件 | 把 12:15 的 7F 廁所堵塞跟 13:22 的 7F 天花板滴水誤合併成「7F 設施異常」 | 「這兩則訊息時間不同、地點描述也不同（廁所 vs 卡通尼餐廳天花板），是兩件獨立的事——請你分開列，各自對應各自的原始訊息時間。」 |
| 把「復原」當成「結案」 | 看到「已復電」「已恢復正常運作」等字眼就直接標記已結案，沒有確認後續是否還有待辦 | 「F08 這則訊息說『主機板狀況不確定，已聯絡廠商禮拜一來檢查』——復電只是先行處置，設備還沒真正確認沒問題。請你對照 G2-8 的結案認定標準，這筆到底該標已結案還是未結案？」 |
| 漏抓深夜才回報的收尾訊息 | 只看到 19:40「人已經救出來了」就結案，沒有往後看到 21:30 廠商檢修完成的回報 | 「電梯困人這件事，人被救出來只是第一階段，後面還有廠商到場檢修的訊息，時間點比較晚、容易漏看——請你把對話往後翻完，確認這件事真正的結束時間點。」 |
| 跟催清單沒有指定 Owner 跟期限 | 未結案事件只寫「持續追蹤中」，沒有寫清楚現在卡在誰手上、預計什麼時候要有結果 | 「『持續追蹤』對主管來說沒有用，請你明確寫出：這件事現在誰負責、下一步是什麼、預計什麼時候回報進度。」 |
8. 延伸練習
重複轉達辨識：確認沒有把同一件事拆成兩件
在 14–20 分主管修正段落結束、時間允許的情況下，你可以進一步追問：
「請檢查對話中是否有『同一件事被不同人重複轉達或確認』的訊息（例如 3F 漏水修復後，稍晚又有人在群組裡提到這件事），並說明你是如何判斷這是重複轉達、而不是新的一件事。」
目的：G2-6 對話中刻意安排了下午 3 點多黃副理與王組長重新提起「3F 漏水已經處理完成」的對話，這其實是對已結案事件的重複確認，不是新事件。這個練習讓你體驗「例行流程自動化也需要驗證 AI 的判斷依據」——不能只驗證『抓到的 9 件事件對不對』，還要驗證『AI 有沒有誤把重複轉達或事後確認當成第 10 件新事件』，這正是把 AI 產出的補登結果，從「看起來完整」提升到「驗證過確實正確」的關鍵一步。