技術手冊 v1.0｜半自動行政專案管理
Google Workspace＋NotebookLM × Gemini 行政專案工作流
從收到公文、填表啟動、自動建檔，到 NotebookLM 知識庫與 Gemini 成果產出
本手冊說明如何建立一套適合學校行政現場的半自動專案管理系統。核心精神是：由人判斷是否成立專案，系統自動建立資料夾、文件、追蹤表與提醒；NotebookLM 負責整理專案脈絡，Gemini 協助生成公告、表單、報告與交接資料；正式公告、經費核銷、公文回覆與成果送出仍由人確認。
目錄
一、系統總覽與設計原則
一份公文進來，不只是下載附件，而是啟動一個可追蹤、可整理、可交接、可產生成果的行政專案。
01
人先判斷
由主任或承辦人判斷公文是否需要成立行政專案。不是每一份公文都自動啟動，避免系統製造過量資料夾。
02
系統建骨架
表單送出後，Apps Script 建立 Drive 專案資料夾、子資料夾、專案紀錄 Docs、待辦追蹤表、成果檢核表與 Calendar 提醒。
03
AI 做整理
NotebookLM 根據來源資料回答問題、檢查缺漏；Gemini 協助產出公告、表單題目、成果報告、簡報大綱與交接提醒。
收到公文→
填啟動表→
自動建專案→
資料歸位→
NotebookLM 建知識庫→
Gemini 產出草稿→
人工確認結案
核心設計句
這套系統不是讓 AI 代替主任做決定，而是把固定、重複、容易漏掉的建檔、提醒、整理、草稿產出先標準化，讓行政人員保留正式判斷、溝通協調與責任確認。
二、工具分工與資料流
| 工具 | 角色 | 負責事項 | 注意事項 |
|---|---|---|---|
| Google Forms | 專案入口 | 承辦人填寫公文專案啟動表，並上傳原始公文與附件。 | 欄位名稱要固定，Apps Script 才能正確讀取。 |
| Google Sheets | 總控與追蹤 | 儲存表單回應、行政專案總控表、待辦追蹤表、成果檢核表。 | 狀態欄位建議使用下拉選單，避免資料混亂。 |
| Google Drive | 資料倉庫 | 集中保存公文、附件、計畫書、照片、經費、成果與檢討。 | 資料夾命名與權限要一致。 |
| Google Docs | 專案紀錄 | 記錄公文摘要、重要期限、執行歷程、缺漏檢查與結案建議。 | 這份文件後續要加入 NotebookLM 作為來源。 |
| Google Calendar | 期限提醒 | 建立活動日、成果期限、經費核銷期限與提前提醒。 | 提醒過多會失效，先放關鍵日期。 |
| Gmail | 內部通知 | 專案成立後寄信給承辦人，附上資料夾與文件連結。 | 第一版只寄內部通知，不自動寄正式公告。 |
| NotebookLM | 專案知識庫 | 依據公文、計畫、會議紀錄、照片說明、成果資料回答問題與檢查缺漏。 | 來源資料品質決定回答品質。 |
| Gemini | 成果生成助理 | 產出公告、表單題目、會議追蹤表、成果報告與簡報草稿。 | 正式文件、金額、期限與權責需人工確認。 |
三、建置前準備
準備 1
建立 Google Drive 總資料夾
先在「我的雲端硬碟」或學校共用雲端硬碟中建立一個總資料夾。第一版測試建議放在自己的雲端硬碟，確認無誤後再搬到共用雲端硬碟。
校務行政工作流
├─ 00_系統設定
├─ 01_公文專案啟動表
├─ 02_專案總控表
├─ 03_專案資料夾
├─ 04_表單回覆資料
├─ 05_範本文件
├─ 06_Apps Script
└─ 99_封存專案
注意：若放在共用雲端硬碟，Apps Script 可能受學校 Google Workspace 權限限制。若出現 DriveApp.getFolderById 錯誤，先改用「我的雲端硬碟」測試。
準備 2
取得三個必要 ID
| ID | 取得方式 | 用途 |
|---|---|---|
| Drive 總資料夾 ID | 打開資料夾，複製網址中 /folders/ 後面的字串。 | Apps Script 建立專案資料夾的位置。 |
| 行政專案總控表 ID | 打開 Google Sheet，複製網址中 /d/ 後面的字串。 | 寫入所有專案總覽資料。 |
| Calendar ID | Google Calendar 設定 → 整合日曆 → 日曆 ID。 | 建立期限提醒事件。 |
簡化建議：Calendar ID 可先使用
primary，代表使用主要日曆；等流程穩定後再建立「行政專案追蹤日曆」。四、公文專案啟動表
表單
表單定位與欄位設計
公文專案啟動表是整套流程的入口。承辦人收到公文後，先判斷是否需要建立專案，再填寫表單。表單送出後，系統才建立專案資料夾與相關文件。
| 欄位名稱 | 題型 | 必填 | 用途 |
|---|---|---|---|
| 公文主旨 | 簡答 | 是 | 供專案紀錄與成果報告引用。 |
| 來文單位 | 簡答 | 是 | 記錄公文來源。 |
| 公文日期 | 日期 | 是 | 保留公文時間脈絡。 |
| 公文文號 | 簡答 | 否 | 供查詢與成果報告使用。 |
| 專案名稱 | 簡答 | 是 | 用於資料夾與文件命名。 |
| 專案年度 | 下拉 | 是 | 例如 115、116。 |
| 承辦處室 | 下拉 | 是 | 例如教務處、學務處、總務處、資訊組。 |
| 承辦人 | 簡答 | 是 | 專案責任人。 |
| 承辦人Email | 簡答 | 是 | 寄送內部通知使用。 |
| 是否有經費 | 單選 | 是 | 決定成果檢核表是否列出經費項目。 |
| 活動日期 | 日期 | 否 | 建立活動日曆提醒。 |
| 成果繳交期限 | 日期 | 否 | 建立成果期限提醒。 |
| 經費核銷期限 | 日期 | 否 | 建立經費期限提醒。 |
| 公文或附件上傳 | 檔案上傳 | 建議是 | 上傳原始公文、附件、核定表或相關資料。 |
欄位名稱不可任意更改：Apps Script 會依據欄位名稱讀取資料，例如「專案名稱」「專案年度」「承辦處室」「承辦人Email」「公文或附件上傳」。若更名，程式也要同步修改。
五、Apps Script 半自動啟動器
程式
Apps Script 要做的事
Apps Script 掛在「公文專案啟動表_表單回應」試算表上。觸發器設定為「試算表／提交表單時／onFormSubmit」。
自動建立
- 專案主資料夾
- 10 個標準子資料夾
- 專案紀錄 Docs
- 待辦追蹤表
- 成果檢核表
自動整理
- 複製上傳的公文與附件
- 寫入行政專案總控表
- 建立 Calendar 提醒
- 寄內部通知信
不自動做
- 不自動寄正式公告
- 不自動送出成果報告
- 不自動判斷經費合規
- 不處理敏感個資判斷
觸發器設定
Apps Script 左側「觸發條件」
→ 新增觸發條件
→ 選擇要執行的函式：onFormSubmit
→ 選擇部署作業：Head／上端
→ 事件來源：試算表
→ 事件類型：提交表單時
→ 儲存
基本設定區塊
const CONFIG = {
ROOT_FOLDER_ID: '你的Google Drive總資料夾ID',
CONTROL_SHEET_ID: '你的行政專案總控表ID',
CALENDAR_ID: 'primary 或 行政專案追蹤日曆ID',
ADMIN_EMAIL: '錯誤通知管理者Email，可留空',
TIMEZONE: 'Asia/Taipei'
};
測試順序：先測 Drive 資料夾 ID，再測總控表 ID，再測 Calendar ID，最後才測表單送出。這樣比較容易定位錯誤。
六、階段一：收到公文與啟動專案
階段 1
判斷是否成立行政專案
收到公文後，不是所有公文都要成立專案。若符合下列條件之一，就建議填寫公文專案啟動表。
- 需要辦活動、研習、比賽或成果發表。
- 需要繳交成果報告、照片、簽到表或回饋資料。
- 涉及經費、採購、核銷、憑證或報價。
- 需要跨處室、跨年級、導師或外部單位合作。
- 需要會議紀錄、工作分工或後續追蹤。
- 明年可能再辦，值得留下經驗。
執行步驟
- 閱讀公文主旨與附件，判斷是否成立專案。
- 打開「公文專案啟動表」。
- 填入公文主旨、年度、處室、承辦人、期限等資料。
- 上傳原始公文與附件。
- 送出表單，等待系統自動建立專案資料夾與文件。
- 檢查是否收到 Gmail 內部通知。
注意：表單上傳檔案建議使用 PDF、Word、Excel 或圖片。若公文含學生個資、輔導、特教、醫療等敏感資料，不建議直接上傳到一般雲端流程，需依校內規範處理。
七、階段二：Drive 專案資料夾與檔案歸位
階段 2
確認資料夾與檔案位置
專案成立後，第一個動作是檢查專案資料夾是否完整，並將資料放入正確位置。資料歸位做得好，後面的 NotebookLM 與成果報告才會準確。
115_資訊組_AI融入教學研習
├─ 00_原始公文與附件
├─ 01_計畫書與核定資料
├─ 02_工作分工與會議紀錄
├─ 03_表單與回覆資料
├─ 04_經費與採購核銷
├─ 05_活動照片與照片說明
├─ 06_成果資料與成果報告
├─ 07_公告通知與對外文字
├─ 08_簡報與成果展示
├─ 09_檢討與下次改進
└─ 99_系統產生文件
| 資料類型 | 放置位置 | 注意事項 |
|---|---|---|
| 原始公文、附件、核定函 | 00_原始公文與附件 | 保留原始檔，不要只留截圖。 |
| 計畫書、核定資料、預算表 | 01_計畫書與核定資料 | 正式版與草稿版可用檔名區分。 |
| 會議紀錄、工作分工、協調紀錄 | 02_工作分工與會議紀錄 | 決議事項要能回填待辦追蹤表。 |
| 表單、回覆、名冊、統計 | 03_表單與回覆資料 | 名冊若有個資，注意權限。 |
| 經費表、報價、憑證、核銷資料 | 04_經費與採購核銷 | AI 只能協助整理，金額與合規需人工確認。 |
| 活動照片、照片說明表 | 05_活動照片與照片說明 | 照片要有日期、活動階段、圖說。 |
| 成果報告、附件清單 | 06_成果資料與成果報告 | 正式送出前需主任或承辦人確認。 |
| 校內公告、家長通知、LINE 文字 | 07_公告通知與對外文字 | 對外文字不可完全依 AI 草稿直接送出。 |
| 成果簡報、展示資料 | 08_簡報與成果展示 | 可由 Gemini 產生大綱後人工美化。 |
| 檢討與下次改進 | 09_檢討與下次改進 | 這是日後交接與 NotebookLM 行政導師的關鍵資料。 |
八、階段三：待辦追蹤與期限提醒
階段 3
整理待辦追蹤表
待辦追蹤表是整套半自動流程的管理核心。Apps Script 會先建立預設任務，承辦人再依實際公文內容修正。
| 欄位 | 用途 | 填寫原則 |
|---|---|---|
| 任務編號 | 追蹤任務 | 例如 T001、T002。 |
| 階段 | 分類工作 | 公文、籌備、執行、經費、成果、結案。 |
| 任務名稱 | 描述任務 | 用動詞開頭，例如「整理公文要求」。 |
| 負責人 | 明確責任 | 避免只寫「大家」。 |
| 期限 | 完成時間 | 若公文未明示，先標示「需確認」。 |
| 提醒日期 | 自動提醒依據 | 建議比正式期限早 3～7 天。 |
| 狀態 | 進度控管 | 未開始、進行中、待確認、完成。 |
承辦人要做的事
- 打開自動建立的待辦追蹤表。
- 依公文實際要求刪除不需要的預設任務。
- 新增公文特有任務，例如「上傳成果平台」「填報補助系統」。
- 補上負責人、期限、提醒日期。
- 每週至少更新一次狀態。
第二階段可自動化：每日檢查待辦追蹤表，若提醒日期等於今天且狀態不是完成，就自動寄 Gmail 給承辦人。
九、階段四：建立 NotebookLM 專案知識庫
階段 4
NotebookLM 的具體操作
NotebookLM 不是取代 Drive，而是把 Drive 裡的重要文件變成可以詢問的「專案知識庫」。重要專案建議建立一本與 Drive 專案資料夾同名的 NotebookLM 筆記本。
什麼專案需要建立 NotebookLM？
建議建立
- 有成果報告。
- 有經費或核銷。
- 有多份附件。
- 有活動照片與照片說明。
- 有會議紀錄或跨處室合作。
- 明年可能再辦或需要交接。
不一定需要
- 單純轉知。
- 一次性簡單回覆。
- 沒有附件。
- 沒有成果要求。
- 不需追蹤、不需交接。
NotebookLM 建立步驟
- 到 NotebookLM 建立新筆記本。
- 筆記本命名與 Drive 專案資料夾一致，例如：115_資訊組_AI融入教學研習。
- 第一批加入：原始公文、附件、實施計畫、核定經費表、專案紀錄 Docs。
- 籌備階段加入：會議紀錄、分工表、公告文字、表單題目。
- 執行階段加入：活動紀錄、照片說明表、簽到表、回饋統計。
- 成果階段加入：成果報告草稿、經費整理、檢討與下次建議。
- 將 NotebookLM 筆記本連結貼回行政專案總控表。
第一次提問範例
請根據目前來源資料，整理這個行政專案的重點。
請分成：
1. 辦理依據
2. 主要任務
3. 重要期限
4. 需要繳交或保存的成果資料
5. 涉及的處室或人員
6. 經費或核銷注意事項
7. 目前資料中不清楚、需要人工確認的地方
缺漏檢查提問
請根據目前專案資料，檢查成果報告還缺什麼。
請分成：
1. 已具備資料
2. 明顯缺漏資料
3. 建議補充資料
4. 需要人工確認資料
5. 不適合放進成果報告的資料
重要：NotebookLM 的答案必須回到來源資料。若來源沒有的法規、數字、金額、日期或承諾，不應直接採用。
十、階段五：Gemini 文件與成果產出
階段 5
Gemini 的使用方式
Gemini 負責把已整理好的資料轉成可用草稿。建議先由 NotebookLM 整理脈絡，再把摘要、缺漏清單與專案資料交給 Gemini 產出文件。
| 產出類型 | 用途 | 放置位置 |
|---|---|---|
| 公文摘要 | 協助承辦人快速理解任務。 | 99_系統產生文件／專案紀錄 Docs |
| 校內公告 | 通知教師、導師或工作人員。 | 07_公告通知與對外文字 |
| 表單題目 | 建立報名表、回饋表、照片上傳表。 | 03_表單與回覆資料 |
| 會議追蹤表 | 將會議決議轉成待辦。 | 02_工作分工與會議紀錄／待辦追蹤表 |
| 成果報告草稿 | 快速產出正式報告初稿。 | 06_成果資料與成果報告 |
| 成果簡報大綱 | 彙報或研習分享。 | 08_簡報與成果展示 |
| 交接提醒 | 給下一任承辦人使用。 | 09_檢討與下次改進 |
成果報告提示詞
你是一位學校行政成果報告助理。
請根據以下專案資料，產出成果報告初稿。
請包含：
1. 計畫名稱
2. 辦理依據
3. 辦理目的
4. 辦理時間與地點
5. 參與對象與人數
6. 執行內容
7. 經費使用概況
8. 成果效益
9. 活動照片建議位置
10. 檢討與改進建議
11. 附件清單
請標示哪些內容根據來源資料整理，哪些地方需要主任或承辦人補充確認。
不要自行編造沒有資料支持的數字、金額或成果。
校內公告提示詞
請根據本專案資料，產出校內公告草稿。
要求：
1. 說明活動或計畫目的
2. 清楚列出對象、日期、地點、期限
3. 說明承辦人與聯絡方式
4. 語氣正式、簡潔、適合校內行政公告
5. 不新增來源資料沒有提到的承諾
6. 標示需要人工確認的日期、地點或金額
流程建議：NotebookLM 負責「根據資料整理脈絡」，Gemini 負責「轉成可用草稿」。不要讓 Gemini 在資料不足時自行想像。
十一、階段六：執行中資料累積
階段 6
活動或專案進行中怎麼維持資料完整
行政專案常見問題是：活動做完才開始找資料。這套流程要求「從第一天開始累積成果」。
| 時間點 | 應做事項 | 放置位置 | 注意事項 |
|---|---|---|---|
| 籌備前 | 整理公文要求、建立待辦、建立表單。 | 99、03、02 | 表單題目要對應成果報告需要的數據。 |
| 會議後 | 將決議轉成待辦追蹤表。 | 02、待辦追蹤表 | 沒有負責人與期限的決議，要標示待確認。 |
| 活動前 | 確認名冊、場地、通知、器材、經費。 | 03、04、07 | Calendar 提醒要檢查。 |
| 活動中 | 收集照片、簽到、現場紀錄。 | 05、03 | 照片要補圖說，不然成果報告難用。 |
| 活動後 3 日內 | 整理回饋、照片說明、經費資料。 | 03、04、05 | 不要等成果期限前才整理。 |
| 成果前 7 日 | 用成果檢核表檢查缺件。 | 成果檢核表 | 缺件要寄提醒或列入待辦。 |
照片說明表建議欄位
照片檔名｜日期｜活動階段｜照片說明｜可用於成果｜備註
IMG_001.jpg｜115/05/18｜課程實作｜教師分組操作 NotebookLM 建立專案知識庫｜是｜可放成果報告第 3 頁
十二、階段七：成果報告與結案交接
階段 7
成果前檢查與結案保存
成果報告不是最後才開始寫，而是把前面累積的公文、表單、照片、經費、會議與檢討整理成正式文件。
成果送出前檢核
- 原始公文與附件已保存。
- 計畫書或核定資料已保存。
- 活動照片有圖說。
- 簽到表、參與名冊或表單回覆已整理。
- 經費資料與憑證狀態已人工確認。
- 成果報告中的日期、金額、人數、名稱已人工確認。
- 成果附件清單已整理。
- 檢討與下次建議已保存。
結案後要留下什麼？
正式成果
成果報告、成果簡報、附件清單、送出版本。
檢討紀錄
本次問題、延誤原因、資料缺漏、可改善流程。
交接提醒
下次承辦人一開始要先做什麼、哪些表單與公告可沿用。
交接提醒提示詞
請根據本專案所有資料，整理一份給下一任承辦人的交接提醒。
請分成：
1. 下次要提早處理的事
2. 容易漏掉的資料
3. 可沿用的表單、公告或文件
4. 經費與成果報告注意事項
5. 建議時程
6. 本次最值得保留的經驗
十三、維運、測試與故障排除
維運
測試函式與常見問題
建議內建測試函式
function testDriveFolder() {
const folder = DriveApp.getFolderById(CONFIG.ROOT_FOLDER_ID);
Logger.log(folder.getName());
}
function testControlSheet() {
const ss = SpreadsheetApp.openById(CONFIG.CONTROL_SHEET_ID);
Logger.log(ss.getName());
}
function testCalendar() {
const calendar = CalendarApp.getCalendarById(CONFIG.CALENDAR_ID);
Logger.log(calendar ? calendar.getName() : '找不到日曆');
}
| 問題 | 可能原因 | 處理方式 |
|---|---|---|
| 觸發器找不到 onFormSubmit | 程式未儲存、語法錯誤、函式名稱拼錯。 | 先放最小測試版，確認函式出現在觸發器選單。 |
| 沒有「試算表」事件來源 | 從 Google 表單本身開 Apps Script。 | 改從表單回應試算表 → 擴充功能 → Apps Script 進入。 |
| DriveApp.getFolderById 錯誤 | 資料夾 ID 錯誤、貼成完整網址、權限不足、共用雲端限制。 | 用 testDriveFolder 測試；先放我的雲端硬碟。 |
| 表單上傳檔案沒有複製 | 欄位名稱不同、試算表中的連結格式未被解析。 | 確認欄位名為「公文或附件上傳」；檢查執行記錄。 |
| Calendar 沒建立事件 | Calendar ID 錯誤或日期格式無法解析。 | 先用 primary 測試，確認日期欄位是日期格式。 |
| Gmail 沒寄出 | 承辦人Email 空白、權限未授權、每日寄信限制。 | 確認表單欄位與授權狀態。 |
十四、權限、個資與安全邊界
不建議放入一般流程
- 學生完整姓名加身分證號。
- 輔導、特教、醫療、家庭敏感資料。
- 未授權公開的個案紀錄。
- 涉及人事考核、申訴、法律爭議的敏感文件。
- 尚未核定或不可外流的經費與採購資料。
可以優先導入
- 公開公文與一般附件。
- 研習、活動、成果報告資料。
- 去識別化照片說明與回饋統計。
- 校內公告、工作分工、會議待辦。
- 不含敏感個資的檢討與交接紀錄。
三層權限原則
- 資料夾權限：專案資料夾只分享給承辦人與必要協作人員。
- AI 來源權限：加入 NotebookLM 的資料先確認是否適合成為 AI 來源。
- 正式送出權限：公告、成果、經費、公文回覆一律由人審核後送出。
十五、第二階段擴充建議
| 功能 | 價值 | 風險 | 建議優先順序 |
|---|---|---|---|
| 待辦到期自動提醒 | 大幅降低漏期限。 | 低。 | 第一優先。 |
| 總控表狀態顏色 | 主任快速掌握進度。 | 低。 | 第一優先。 |
| NotebookLM 來源清單產生器 | 協助承辦人知道該放哪些資料。 | 低。 | 第二優先。 |
| 依專案類型產生不同任務範本 | 更符合研習、採購、校外教學等情境。 | 低中。 | 第二優先。 |
| Gemini API 摘要公文 | 減少人工摘要時間。 | 中，需處理權限與費用。 | 第三優先。 |
| 自動寄正式公告 | 節省時間。 | 高，容易出現責任與錯誤送出問題。 | 不建議第一版。 |
十六、建議導入節奏
第 1 週：MVP 測試
完成表單、Apps Script、資料夾、總控表與 Calendar 提醒。用 1～2 份模擬公文測試。
建檔測試第 2 週：真實專案試跑
選擇一個低風險行政案，例如研習或一般活動，完整跑一次從填表到成果檢核。
小規模修正流程第 3 週：建立標準作業
整理欄位、提示詞、資料夾命名、權限設定與常見錯誤，形成校內 SOP。
SOP可交接