情境

國小教師的三大重工：行政通知改寫、作文批閱回饋、教學圖像設計。每件事都重複發生，每次都從零開始。

做法

各建一個單一任務 Gem：用「角色×任務×輸入×輸出×限制」公式寫使用說明，右側預覽用真實資料迭代到穩定。

結果

公文一份資訊出三版本；作文回饋有結構化草稿可修訂；圖卡提示詞不再每次重想。研習教師當場複製三個 Gem 帶回學校。

情境

段考前想讓學生做一份即時計分的小測驗，但學校測驗平台申請流程慢，用紙本又沒有即時回饋。

做法

把 10 題題庫（題幹/選項/正解/解析）連同介面需求（逐題作答、答完顯示解析、最後總分與錯題清單）交給 Canvas 生成，自己先完整作答一輪驗收計分邏輯。

結果

10 分鐘內產出一個手機可操作的測驗網頁，用連結分享給全班，不需要學生登入、不收集個資，當堂就看到全班錯題分布。

情境

國文課教到古代生活場景（如市集、驛站），教科書只有文字描述，網路上找不到版權清楚又符合場景的圖片。

做法

把課文中對場景的具體描述整理成生成提示詞（主題、風格、需出現的物件、限制不出現的現代元素），生成後檢查畫面是否有明顯的時代錯置或刻板印象，才收進教材。

結果

產出一張可用的場景示意圖，投影時明確標注「AI 生成示意圖，非史實照片」，並藉機讓學生討論「這張圖畫對了什麼、可能畫錯了什麼」。

情境

常見用法停在「請 AI 幫我寫教案」，每次產出品質不穩，且無法累積。

做法

三段式：Chrome 端 Gemini 跑「文本分級→生詞語法抽取→輸入稿格式化」三個固定提示詞，成果連同原文匯入 NotebookLM，追問後生成字卡/測驗/心智圖。

結果

同一篇文章整理一次，延伸成閱讀教學、詞彙教學與課堂任務三種素材；教材庫隨學期累積。

情境

文本自主學習的困境：學生不知道該問什麼，AI 又可能一本正經地講錯。

做法

課文與背景資料入庫；學習單設三層提問鷹架（知識/分析/評定）；學生提問並記錄引用；最後回原文驗證並標注 AI 錯誤。

結果

學生的提問明顯出現層次遞進；「抓到 AI 講錯」成為課堂高光時刻，驗證習慣自然建立。

情境

通知自動化只是起點——知道之後要「產出什麼」才是真正花時間的部分：改寫教材、寫評語、整理申請文件。

做法

三條 Flow 共用五步驟骨架（Starter→讀取→AI 分析→產出草稿→人工確認）；教材框架與評語規則由人設計，AI 只填空。

結果

「重打整理」變成「人工確認」；教師時間從格式重工移轉到專業判斷。

情境

行政人員想要「在 LINE 輸入 /行程 就回今天會議」的對話式助理——Workspace Studio 做不到外部服務串接。

做法

在 Gemini Canvas 描述需求生成 GAS 程式碼；部署 Web App 接 LINE Webhook；簽章驗證＋先回「處理中」再主動推播結果的兩段式設計。

結果

斜線指令助理上線；同一骨架（入口→驗證→服務層→格式化→回應）複製出查信、待辦、提醒多種指令。

情境

校園故事素材（訪談/老照片/繪本）豐富但零散，要在五天內轉譯成學生的數位作品。

做法

Day1 用在地案例建立「AI 能與不能」判準；Day2 素材入 NotebookLM 練三層提問並找知識缺口；Day3 拍攝規劃＋Gemini 生成無法實拍的歷史示意圖＋剪輯上傳＋Sites 彙整。

結果

每組產出影片與成果頁；AI 生成畫面全部標注；知識缺口清單轉化成追加訪談的行動。

情境

法務與行政的高頻痛點：同樣的法規問題反覆被問，每次都重新翻條文。

做法

六步驟工作流：資料匯入（法規/契約/內規）→ 資訊提取（條文/術語/風險）→ 內容比對（版本/適用性）→ 初步組織（FAQ/檢核表）→ 組織共享 → 串接 Gems 對話式查詢。

結果

重複問詢大幅下降；新人查找速度提升；FAQ 標注「需人工確認」的邊界清楚。

情境

教材已在 Classroom 課程內，複製到外部 AI 視窗再貼回來是重複搬運。

做法

建測試課程上傳講義；分別生成測驗、規準、音訊摘要；與手動流程計時對比；逐項驗證產出品質。

結果

與教材綁定的產出（測驗/規準）效率優勢明顯；通用素材則維持在外部工具製作再派發。

情境

班級內程度差異大，傳統同一張學習單讓快的學生無聊、慢的學生跟不上。

做法

先用教師端 AI 生成 choice board，再依學習目標保留 6 格：閱讀理解、口頭說明、圖像整理、生活應用、小組挑戰、延伸探究。

結果

教師不必一次設計所有分層活動，先取得活動池，再刪除不符合場域的選項並補上評量準則。

情境

學生考錯不一定是不努力，常常是卡在同一個概念誤解，但教師要臨時整理補救活動很耗時。

做法

在 Classroom AI 中輸入單元主題與年級，產生三類常見迷思；教師逐條改成班上可觀察的錯誤表現。

結果

下一節課不再只是講解答案，而是針對迷思設計 10 分鐘澄清活動與二次練習。

情境

學生知道要讀講義，卻常卡在長文本開頭；教師希望提供另一種複習入口。

做法

把教材轉成 audio lesson，要求學生先聽 5 分鐘摘要，再回到講義標出三個還不懂的段落。

結果

音訊不是取代閱讀，而是降低第一次接觸門檻，讓學生更願意回到文本。

情境

大學或成人教育課程中，學生需要把多週教材整理成可複習的結構。

做法

學生先用 Guided Learning 追問核心概念，再用 Canvas 做測驗與字卡，最後用 NotebookLM 產生音訊或視覺整理。

結果

複習從「看完教材」變成「問答、測驗、字卡、回到來源」的循環。

情境

學生在考前晚上才發現自己不懂，但助教與教師不可能 24 小時在線。

做法

教師先提供課程材料，學生用 NotebookLM 產生字卡、練習測驗與學習指南，並要求每次回答都回到來源確認。

結果

低門檻學生也能快速開始複習；教師則把時間放回面對面討論與高階思辨。

情境

學生一開始只有模糊主題，容易直接問 AI 要答案，沒有建立來源蒐集與篩選流程。

做法

先讓 NotebookLM 協助找候選來源，再由學生逐筆判斷可信度、加入或拒絕，最後整理成研究問題與來源表。

結果

研究起步不再是空白頁；學生留下每個來源被採納或排除的理由。

情境

研究生整理多來源資料後，常卡在表格、圖表與報告格式轉換。

做法

把來源與資料表放入 notebook，要求先產出分析假設與欄位說明，再生成圖表或報告草稿供人工修訂。

結果

從資料整理到報告草稿的轉換加速，但分析解釋仍需研究者把關。

情境

研習窗口每天收到報名異動、附件缺漏、家長詢問，真正耗時的是辨識優先順序與提醒。

做法

用 Workspace Studio 描述規則：若郵件含問題或附件缺漏，標記待回覆、擷取姓名與需求，並在 Chat 通知承辦人。

結果

承辦人先看到待處理清單，再決定回覆內容；減少漏信與來回搜尋。

情境

校內要提出 AI 研習方案，承辦人需要同時處理需求評估、技術可行性、學員體驗與申請文件。

做法

設計四個小代理：需求整理、風險檢查、流程設計、文件草稿；每一步都輸出給下一步，但最後由人整併。

結果

多角色思考被拆成可審核的中間稿，承辦人不再面對一份黑箱式長文。

情境

教師想要一個小型閱讀題庫產生器，但需求常在試用後才會改，傳統貼程式碼聊天容易失控。

做法

把驗收條件寫清楚：上傳文本、生成題目、可複製、手機可用；讓 Agent 實作後提供截圖與瀏覽器驗證 Artifact。

結果

開發不只看程式碼，而是看可操作畫面、測試流程與錯誤回報。

情境

教學工具已上線，但表單欄位變動、手機版錯位、匯出格式壞掉等小 bug 不斷出現。

做法

將每個維護任務拆成重現步驟、預期行為、測試資料；Agent 先重現，再修復，最後附測試或截圖 Artifact。

結果

維護工作可並行處理；開發者用 Artifact 快速審查是否真的修好。

情境

教師在 Gemini app 想出活動，但真正派發、收件與回饋都發生在 Classroom。

做法

Gemini app 產生 3 個活動方向；教師選一個後，回到 Classroom 內生成 quiz、rubric 或 choice board，綁定班級與教材。

結果

創意發想與課程管理各用最適合的介面，減少複製貼上與資料錯位。

情境

教師要根據多份資料出題，希望題目有來源依據，又要能快速派發到班級。

做法

先在 NotebookLM 對來源提取重點與易錯概念，再把已確認的題目方向帶到 Classroom 生成 quiz 和 rubric。

結果

題目設計有來源可查，Classroom 內則保留作業與評量流程。