這章要學會什麼
- 做出後臺「會員管理」：用信箱或名稱查詢，看到會員的角色、狀態、使用授權、自己登記的服務跟審核異動歷程。
- 做出停權／復權跟管理員角色異動：原因一定要填、不能對自己動手、全部寫進稽核紀錄，並且讓舊的登入狀態在短時間內失效。
- 說明停權這個動作怎麼同時擋住三個不同的入口。
- 走完一次服務版本升級：新版本一定要重新審核、重新映射工具、會員也要重新申請授權，舊版本的使用權不會自動轉移。
- 下架前先看到影響範圍評估，並驗證下架後所有歷史資料（呼叫紀錄、審核紀錄、使用權、工具映射）都完整保留。
先備知識
要先完成第 11 章：每次呼叫都重新檢查會員狀態、使用權、版本狀態。要記得第 4 章的登入流程（密碼正確但帳號被停用時的提示訊息）與管理員角色的初始設定；以及第 5～7 章「建立新版本→送審→核准→申請→核准」的整條流程。
觀念白話講
平台上線之後，管理員每天要回答的三個問題
| 問題 | 本章的功能 |
|---|---|
| 「這個帳號馬上不能用了」 | 會員管理：停權／復權 |
| 「這支服務要改版，舊的怎麼收尾」 | 新版本重新審核與授權；下架前先看影響評估 |
| 「上週是誰把這個人的授權撤掉的、為什麼」 | 會員詳細頁的審核與異動歷程 |
停權要同時擋住三個入口
停權不是只改一個欄位這麼簡單。會員可能同時處於三種「已經在用」的狀態，每一種都要被個別擋下：①重新登入——密碼驗證通過後才檢查帳號是否停用，這時候會直接告知已停權；②既有的網頁登入狀態——登入憑證裡記著一個「安全戳記」，每隔一段固定時間會拿它跟資料庫比對一次，發現不同就自動登出，本課程把這個間隔設得很短（1 分鐘），間隔越短生效越快，但也代表每分鐘要多查一次資料庫，是個取捨；③已經發出的通行證——完全不受這個間隔影響，因為每一次 AI 呼叫本來就會即時查一次會員狀態（第 11 章做的）。
所有管理動作，都遵守同樣三條規則
停權、復權、角色異動、撤銷授權、下架，全部遵守：①原因一定要填——沒有原因的異動，事後根本無法判斷對錯；②不能對自己動手——管理員不能停權自己、不能改自己的角色，避免不小心把最後一位管理員鎖在門外，也避免有人偷偷替自己加權限；③狀態不對就直接拒絕——已經停權的人再停權一次、已經是管理員的人再設為管理員，都會得到明確的提示，不會重複寫入稽核紀錄。角色異動同樣會換掉安全戳記：被加入或移出管理員角色的人，舊的登入狀態立刻失效，要重新登入才會套用新角色。
版本更新：新版本是全新的審核對象
第 5 章定下的原則是「網址、方法、規格任一項要改，就建立新版本並重新送審」。版本一改變，後面每一層都要重新走一次：新版本的網址或參數可能不一樣，要重新看過；工具名稱是唯一的，舊名稱仍然屬於 v1，AI 可能已經記住舊名字，所以要用新名稱重新映射；使用權綁定的是特定版本，會員同意的是 v1 的用途跟資料範圍，並不會自動涵蓋 v2；兩個版本會並存一段時間讓會員慢慢轉移，之後再下架舊版。
下架不刪資料
下架只是把版本狀態改成「已下架」。之後：呼叫紀錄、審核紀錄全部保留，仍然可以查詢統計；使用權狀態表面上仍是「有效」，但實際呼叫一律被擋下——這是刻意的設計，使用權記的是「當時核准了什麼」，不是「現在能不能用」，能不能呼叫完全由版本狀態決定，所以不必去改使用權本身；工具映射也保留在資料表裡，只是不再出現在工具清單中，讓舊的歷史紀錄仍然對得上工具名稱。
老師示範做了什麼
示範情境：某位會員的帳號疑似外流，管理員停權後確認三個入口都被擋下，事後復權；接著服務從 v1 升級到 v2，會員重新申請使用權；最後下架 v1 並確認所有歷史資料都還在。
老師實測了幾個反向情境：停權時原因留白會被拒絕；在自己的詳細頁按停權會被拒絕（不能對自己動手）；正常填理由停權成功後，畫面明確提示「不能登入、網站登入狀態 1 分鐘內失效、所有新的 AI 呼叫立刻被拒絕」；再停權一次會提示「這位會員已經是停權狀態」。老師也驗證了停權前就已登入、且已取得通行證的情況：AI 呼叫立刻得到「會員已停權」；重新登入被拒絕；停權前的登入狀態立刻（不到一分鐘內）馬上還能用，過了驗證間隔之後就被轉到登入頁——證明三個入口的失效時間點確實不同，但最終都會被擋下。
自己動手的步驟
步驟一：會員管理服務
停權／復權的規則寫在一個共用方法裡：原因空白就拒絕、對自己動手就拒絕、狀態沒有改變就拒絕；都通過才真正把「啟用狀態」跟「安全戳記」一起換掉、同時寫一筆稽核紀錄——這三件事要在同一次存檔裡完成，不會出現只成功一半的狀態。角色異動用同樣的規則跟同樣要換安全戳記的做法。動作完成後要記得清掉這位會員的工具清單快取，讓復權後也能立即恢復。
步驟二：安全戳記驗證間隔
把「多久重新比對一次安全戳記」的間隔設成 1 分鐘（框架預設值長得多）——間隔越短，停權生效越快，代價是每位在線會員每個間隔都要多查一次資料庫。
步驟三：會員清單與詳細頁
查詢時用參數化的方式比對信箱或名稱，避免有心人把輸入內容當成查詢指令的一部分注入進去。詳細頁的歷程查詢要同時找出「這位會員自己做的事」跟「別人對這位會員、他的申請、他的使用權做的操作」，依時間排序，只顯示最近幾十筆——完整查詢留給下一章的稽核工具。
步驟四：下架影響評估
下架前，先查出這個版本目前有效的使用權（附上持有者名稱）、對應的工具名稱、累積的呼叫紀錄與審核紀錄筆數、以及同一支服務有沒有更新的已發布版本——把這幾點整理成畫面上清楚的四點提示，讓管理員在真正按下下架之前，先知道會影響到誰。
常見錯誤
| 症狀 | 原因 | 怎麼處理 |
|---|---|---|
| 停權後，會員原本開著的網頁還能繼續操作一陣子 | 安全戳記驗證間隔還沒到，這段時間內是正常現象 | 本課程設成 1 分鐘；AI 呼叫不受這個間隔影響，是即時生效的 |
| 角色異動後，對方畫面上的選單沒有立刻改變 | 角色資訊是登入當時就寫進登入狀態裡的，要等安全戳記驗證後重新登入才會套用新角色 | 提醒對方在間隔時間過後重新登入 |
| 升版後會員說新版本的工具叫不到 | 使用權綁定特定版本，v1 的授權不涵蓋 v2 | 會員要對 v2 重新提出申請並取得核准 |
| 想把新版本映射成跟舊版本一樣的工具名稱，卻被拒絕 | 工具名稱是唯一的，舊名稱仍然屬於舊版本 | 新版本一律用新的工具名稱，舊工具會隨舊版本下架而自然消失於清單 |
怎麼驗收＋反向驗證
- 會員停權能擋住新的呼叫：先取得通行證，管理員停權（填原因）後，同一張通行證的呼叫得到「會員已停權」；重新登入顯示停權提示；會員詳細頁的歷程有這筆停權紀錄跟原因。
- 服務下架不會刪除歷史資料：下架前後比對呼叫紀錄、審核紀錄、使用權、工具映射的筆數，全部維持不變；只有工具清單裡看不到、呼叫得到「協定層級找不到」。
- 新版本需要重新審核跟授權：新版本建立後是草稿狀態，要送審核准才會發布；發布後，會員舊的通行證只看得到舊版本的工具，對新版本申請並獲准後才會出現新工具。
- 反向驗證：管理員嘗試停權自己、改自己的角色、或者原因留白，都必須被拒絕。