峨眉書院・文書組
道場的紀錄與運作全面數位化：人的資料有正本、檔案找得到、對內有前門、對外有門面、史料傳得下去，而且整套不依賴任何一個人。
看不懂圖上的詞（戰術、印、層）？先讀 看圖指南。這份文件給沒有參與過討論的人看：不需要先懂技術名詞，照順序讀下去就懂。這是總藍圖：只講全景，六個工具各自的定位、現況、彼此怎麼相互支援。每個工具的細部做法在各自的子策略地圖。
六個工具各管各的、互相引用、不重複存。三層定位一張表：
| 層 | 做什麼 | 成員 |
|---|---|---|
| 儲存層 | 管資產的正本 | 道籍（人）・知識庫（檔案） |
| 媒體層 | 說故事 | 道峨眉（當期，像雜誌）・文獻平台（典藏，像藏經閣） |
| 管道層 | 送信、開門 | LINE・Gmail・道務平台 |
每個工具有自己的子策略地圖（目錄見文末）。工具之間的關係圖：
| 工具 | 現況 | 下一步 |
|---|---|---|
| 道籍系統（儲存層） | 運轉中：功能大致做齊，進入收尾鞏固期 | 收尾既有模組、觀察使用率；未來可複製給友單位。→ 道籍系統策略地圖（子圖） |
| LINE 小幫手（管道層） | 運轉中 | 跟著道籍系統的功能一起長 |
| 知識庫／文獻庫（儲存層） | 藍圖定稿，動工前 | 照五步路線圖施工：開碟→搬家→個資出清→發鑰匙→入住。→ 知識庫策略地圖（子圖） |
| 道務平台（管道層） | 草稿站已建：視覺定稿、六頁導覽、四卡入口；首頁公告管理已出書面設計規格，待審閱 | 知識庫第 4 步之後接資料夾、設權限、發布。→ 道務平台實作地圖（子圖） → 首頁公告管理設計規格 |
| 道峨眉季刊（媒體層） | 運轉中：70+ 頁，Google 收錄推進中 | 照常出刊；素材之後改從知識庫取 |
| 文獻平台（媒體層） | 未動工（刻意：先有內容再蓋平台）；收錄標準與雛形已定稿 | 等知識庫策展出第一批內容再蓋。→ 文獻平台實作地圖（子圖） |
知識庫管「存」，不管「傳」。現況的痛：訊息靠各 LINE 群人工轉發，該知道的沒收到、不該收的重複收、舊公告要爬群組紀錄。解法是單一發布口：發布的人只發一次、選「給誰」，機器分三路送到：
| 角色 | 做什麼 |
|---|---|
| 發布的人 | 寫一次、選群組（全體有職務者／點傳師／某組／某區）、勾管道，就結束了 |
| 道籍系統 | 名單引擎：群組裡現在是誰它最清楚，職務異動自動跟上 |
| LINE 小幫手 | 推短通知、提醒、要行動的（道親的主要介質） |
| Gmail 群組信箱 | 寄正式的：開會通知、附件公文、要留痕的（主要給幹部與對外）。Google 群組天生自帶信箱，寄群組地址＝全員收到 |
| 道務平台 | 公告欄留底，事後查得到，不用爬群組 |
| 知識庫 | 跟活動相關的公告隨活動流歸年夾 |
零新基建：23 個群組一魚三吃。道籍同步一次名單，三處同時到位：
| 用在 | 管什麼 |
|---|---|
| Drive 權限 | 這份檔案誰能看 |
| LINE 推播 | 推給誰 |
| Email 名單 | 寄給誰 |
排程掛道籍 backlog＋道務平台公告欄（第 4 步後開組頁時一起做），不進五步、不算新工程。
| 受眾選法 | 用在 | 引擎 |
|---|---|---|
| 選圈（群組） | 公告、檔案權限，名單跟職務走 | 23 個群組 |
| 選條件（動態名單） | 青年營隊這類「一種人」 | 道籍撈年齡・區・參與史（行為＝最好的標籤，越用越準） |
沒綁 LINE 的不會漏接：名單按區拆給窗口，一人三五個名字精準去邀。撈受眾＝動用個資，只在道籍的權限與稽核內做。
實體會議是原生管道，數位掛在它的月節奏上（會後 48 小時寄發歸檔），不另創節奏：
| 實體會議（原生） | 對應數位群組 | 數位補強 |
|---|---|---|
| 策劃會（幹部） | 窗口＋經理＋點傳師 | 紀錄歸 209會議碟 |
| 聯絡圈（講師壇主） | 講師群＋壇主群 | 摘要 Gmail 寄發＋平台留底 |
| 小聯絡圈（基層） | 各區群組 | 窗口轉達＋LINE 重點推播 |
數位補實體做不到的三件事：缺席補課・留底可查・精準到人。一場月會動線：開會 → 紀錄 → 寄發留底（傳）→ 歸 209 碟（存）→ 查大事（找）→ 進特刊課題（承）。哪圈對哪群為初排，待校。
藍圖畫完不等於系統活著。六個工具目前真正活著的是三個（道籍、LINE、季刊），另外三個還在施工或排隊。整體算「完整建立」要看得到三個訊號，外加一個結構性條件：
這套系統的目的，是把人從整理檔案裡放出來，去辦活動、去成全人。如果上線之後文書組花在檔案上的時間反而變多，不管系統多漂亮都算失敗。這條紅線用三個機器自己量得到的數字看（不叫任何人填工時表），每季跟使用回顧一起看一眼：
| 指標 | 方向 | 誰在量 |
|---|---|---|
| 機器自動歸位率 | 要往上 | 月巡檢報告自帶（自動分好 vs 需要人工判的比例） |
| 被問路次數 | 要往下 | 文書組隨手記的提問表 |
| 巡檢例外件數 | 要往下 | 月巡檢報告自帶（歸錯、需人工修的） |
| 紅線配套 | 規則 |
|---|---|
| 維運預算 | 文書組例行維運每月 ≤ 半天。超標＝系統的 bug：修系統（改規則、補路標、加自動化），永遠不是加人 |
| 加碼兩問 | 任何人提議新增「人要做的事」，先答：機器能不能做？不做會怎樣？答不出來就不加 |
系統最大的敵人不是亂，是好意的加碼。
整套系統目前繫在一個人身上，這是「完整建立」判準裡承認過的結構風險，但一直沒有解法。解法從拆解開始：不找一個「接班人」接下全部，而是拆成三種角色，各自的門檻差很多：
整套系統存在的最終理由：前人歸空，組織不因此失去他，他的奉獻換一種形式留下來，繼續成全後面的人。
仙佛在訓文裡常藉一個人、一件事來印證一個道理。這層關係目前只存在讀過的人腦中。解法：讀訓文的人隨手在一張表上加一列，把三把鑰匙掛上去。
總圖到此為止。往下鑽的子地圖照三層分類：儲存層管資產的正本、媒體層說故事（當期與典藏兩種節奏）、管道層送東西開門。管道本身沒有自己的資產與目標，整層共用一張策略（就是上面「資訊怎麼傳到人身上」那一節），不逐條成圖：
| 層 | 成員 | 子地圖 |
|---|---|---|
| 儲存層（管資產） | 道籍系統（人） | 道籍系統策略地圖 ✅ |
| 知識庫／文獻庫（檔案） | 峨眉知識庫策略地圖 ✅ | |
| 媒體層（說故事） | 道峨眉起（當期，像雜誌；未來頻道、Podcast） | 峨眉媒體策略地圖 ✅ |
| 文獻平台（典藏，像藏經閣，素材正本在知識庫，上架的是策展後的呈現） | 文獻平台實作地圖 ✅ | |
| 管道層（傳遞與入口） | LINE 小幫手（推）、Gmail 群組信箱（寄）、道務平台公告欄（留底） | 整層策略＝本圖「資訊怎麼傳到人身上」節，不另立圖 |
| 道務平台（門：各組頁與捷徑） | 管道層唯一有實作要規劃的。→ 道務平台實作地圖（子圖） | |
| └ 首頁公告管理（道務平台第一支細部規格） | 首頁公告管理設計規格 ✅ 對話設計已確認，待審閱書面規格 |