Gemini 21 個工作流實戰：檔案分析、簡報圖表、AI Studio App、Opal、Stitch 與 Gemini Notebook

這套教學以一條完整交付鏈為主：先讓 Gemini 讀懂圖片、音訊、外文文件和試算表，再把已核對資料轉成簡報、Canvas 圖表和 Deep Research；其後才進入 Gmail／Docs 協作、AI Studio 估價 App、Opal 流程、Stitch UI、Gem 和 Gemini Notebook。21 個工作流可逐項練習，也可以按實際任務只選其中兩三個。

關鍵原則是：每一次生成之前先寫成功條件，每一次匯出之後做獨立核對。AI 可以縮短第一稿時間，但不能代替資料擁有人、編輯、財務、設計、開發或私隱負責人的批准。

圖像與預覽披露：本文 6 張步驟圖和 2 段無聲預覽全部由編輯部依 2026 年 7 月第一方文件，以虛構資料重建。畫面沒有第三方作者、頻道、帳戶、人物或真實業務資料，也不是任何第三方教學的原始畫面。產品介面與資格可能繼續更新。

一、開始前：建立四份虛構資料和一張驗收表

不要以正式公司檔案第一次測試。建立一個 TRAINING 資料夾，放入：

1. 簡報照片：一張自製投影片，內含 5 個條列、日期和一個刻意容易混淆的數字。
2. 會議音檔：60–90 秒、兩位虛構角色、兩個 action items、不同日期和一個專有名詞。
3. 外文文件：兩頁虛構產品說明，包含功能、限制、警告和版本。
4. 試算表：20 列虛構採購資料，欄位為日期、部門、項目、數量、單價、金額、預算上限。

另外建立驗收表：來源檔名、版本、預期總數、預期例外、實際輸出、人工核對人、狀態。所有工具都使用同一批資料，這樣才能分辨是工具差異、提示差異，還是資料本身有問題。

共用任務規格
資料：只使用 TRAINING 資料夾內四份虛構檔案。
語言：繁體中文；保留英文產品名。
禁止：外部搜尋、補寫不存在的數字、建立對外檔案、讀取其他 Drive 資料。
輸出：每項結果附來源位置、假設、漏項和待人工確認。
狀態：draft → checked → approved；只有 approved 可交給下一個工具。

二、工作流 1–5：多模態檔案分析

1. 簡報照片轉可編輯文字

1. 上載自製照片，說明語言、閱讀方向和預期區塊數。
2. 要求按「標題、條列、註腳、數字」分欄，不要先摘要。
3. 把 OCR 結果逐字對回畫面，特別檢查 0／O、1／I、百分號、小數點和負號。
4. 確認原文後才要求摘要或重寫；保留一份未改寫逐字版本。

2. 會議音檔轉逐字稿與 action items

先要求逐字稿、候選說話者和不確定詞，再另一步整理 action items。口音、重疊語音、專有名詞和含糊日期最容易出錯；每個任務都要有負責角色、截止日期、原句時間和「未指定」狀態，不能讓模型自行分配。

3. 外文文件做功能、限制與警告摘要

不要只問「這是甚麼」。要求把功能、使用條件、限制、警告、版本和頁碼分欄；無法翻譯的術語保留原文。若摘要將用於採購或安全決定，交由熟悉語言和產品的人覆核。

4. 試算表分析比例與預算例外

先提供欄位、單位和公式：金額應等於數量乘單價；預算例外是金額大於預算上限。要求先回報資料列數、空白、文字格式數字和計算不一致，再計算各部門比例。把模型算出的總額與 Excel／Sheets 公式獨立對數。

5. 長文件、網站或影片的目的式分析

上載或加入資料後，明確寫你要解決的問題，而非「幫我總結」。官方說明提醒，超出上下文或內容太長時可能漏掉分散在不同位置的關係。先列目錄和可讀取範圍，分段提問，最後再做全局比較；影片時間點必須重播確認。

請先做資料品質報告，不要立即下結論：
1. 實際讀到哪些檔案、頁數／時間長度、工作表和欄位？
2. 哪些位置模糊、空白、重複、格式不一致或無法讀取？
3. 列出你會使用的計算公式與單位。
4. 列出 5 個人工抽查點。
我確認後，你才開始摘要和分析。

三、工作流 6–7：可編輯簡報與 Canvas 圖表

6. 由已核對資料建立六頁簡報

在 Gemini Canvas 指明要建立 slide presentation，列出受眾、六頁結構、每頁一句目的、主色、資料來源和禁止事項。先要求大綱，批准後再生成；完成可匯出至 Google Slides 或 PDF。若你的 Docs／Slides 有內建 Gemini，亦可能由 Ask Gemini 建立或編輯內容，但這是另一個受方案與語言限制的入口。

7. 在 Canvas 建立可核對圖表

圖表提示必須包含欄位、聚合方式、排序、單位、缺值和預期總額。要求先顯示來源表和計算結果，再選圖表；不要由模型憑美觀決定。交付前核對軸、圖例、標籤、比例總和和無障礙文字。Google 現行 Canvas 文件只列出匯出至 Docs／Slides、投影片匯出 PDF、複製內容及把 Python 程式碼匯出 Colab，沒有記載原生圖表可直接匯出 PNG；只有自訂 Canvas App 才可在程式碼自行實作下載，且發布前必須實測。

建立 6 頁可編輯簡報草稿，先只顯示大綱：
受眾：第一次接觸這份採購資料的部門主管。
頁面：封面、資料範圍、部門比例、超預算項目、限制、下一步。
視覺：深藍與淺灰；不用品牌 logo；每頁最多 45 字。
資料：只使用已標記 checked 的表格；每個數字附來源欄位。
禁止：新增趨勢、節省或預測數字。
完成後列出逐頁事實、圖像權利、閱讀順序和待決定項。

四、工作流 8：Deep Research 由計劃開始

Deep Research 適合需要多個網頁和證據的問題，不適合查一個簡單事實。建立報告前，先限定地區、日期、定義、來源優先序、排除項和交付格式；檢查研究計劃，刪掉無關支線，再開始。官方說明指出報告可用 Search，並按設定加入上載檔案、Drive、Gmail 或 Notebook；加入內部來源時要重新評估資料範圍。

研究問題：香港 20–100 人專業服務公司採用生成式 AI 的三種低風險起步方法。
時間：優先 2025–2026；較舊資料只作背景。
來源：香港政府／監管機構、供應商第一方文件、原始研究。
排除：沒有日期的二手文章、搜尋摘要、無法打開的引用。
先輸出研究計劃和未知數，等我批准。
報告把事實、來源主張、你的推論分欄；每個數字附分母、地區和日期。

完成後逐條打開引用。若來源只支持相似說法而非相鄰句子，便把主張降級或刪除。高風險醫療、法律、財務或人事決定不可只依靠 AI 報告。

五、工作流 9–13：Gmail、Docs 與 Connected Apps 不要混淆

9. 在 Gmail 找到正確郵件

若帳戶有 Gemini in Gmail，可按日期、寄件範圍、未讀狀態或主旨搜尋，也可用 side panel 摘要 thread。Connected Apps 在 Gemini 網頁版亦可找郵件，但工作／學校帳戶由管理員控制。無論入口，先打開原郵件確認寄件者、時間、附件、最新回覆和是否還有效。

10. 草擬、翻譯或回覆郵件

Gmail 內建 Help me write／Gemini 可提供草稿或建議回覆，資格和語言各異。提示要列收件目的、關係、必須包含和禁止承諾；發送前核對 To／Cc／Bcc、附件、日期、金額、語氣和機密內容。不要把「Gemini Apps Connected App 能找到郵件」誤寫成「一定能直接建立或發送草稿」。

11. 在 Docs 把段落重整成表格

在支援的 Google Docs 內打開 Ask Gemini，選取一段文字，要求整理成指定欄。先 Preview，再 Insert；插入後逐格核對，不要因格式整齊而忽略遺漏。若帳戶沒有 Docs side panel，可在 Canvas 完成草稿後 Export to Docs，再人工整理。

12. 為 Docs 加入已核對的新資料

要求使用 Google Search 時要明確寫出，並保留第一方連結和查核日期。新資料先放在「候選」段落，逐條打開來源後才移入正文。Connected Apps 官方文件亦列出不能直接建立某些 Docs、Sheets、Slides 或 PDF 的限制，不要以一個按鈕名稱推斷所有帳戶都能寫入。

13. 在 Docs 產生插圖草稿

先寫用途、比例、構圖、品牌、禁止人物／logo／水印和可讀文字要求；產出後檢查權利、錯字、手部、背景和資料圖形。資訊圖的數字與文字宜在設計工具重新排版，不把模型生成的小字當作正確內容。

六、工作流 14：AI Studio Build 建立估價 App 原型

不要只寫「幫我做估價器」。先把輸入、計算、顯示、邊界、錯誤和版本定成規格。以虛構影像服務為例：

建立一個只使用虛構價格的估價 App 原型。
輸入：服務類型 enum、拍攝小時 1–12、剪輯版本 1–5、加急 boolean。
計算：基礎費 + 小時費 + 額外版本費；加急乘數只套於服務費。
顯示：港元、未連稅、逐項明細、估價有效日期和「非正式報價」。
驗證：空白、0、負數、13 小時、文字、極大值、重複提交。
禁止：付款、登入、真實客戶資料、外部資料庫。
先列測試案例和預期值，再生成最小版本。

現行 AI Studio Build mode 可建立全端 Web 或 Android App，亦可管理 server-side secret、匯出 GitHub／ZIP 或部署。這不代表生成程式碼自動符合安全和業務規則。打開 Code 和 console，搜尋硬編碼 key、未驗證輸入、client-side 權限、依賴錯誤和未處理 exception；再用獨立計算表對數。分享 App 時，使用者的 API 呼叫可能計入建立者的配額，付費模型可能產生成本。

七、工作流 15–18：Opal 串流程，Stitch 做 UI 與互動原型

15. Opal 建立內容處理流程

由空白或 Gallery remix 開始，先建立 User Input → Generate → Output 三步：輸入一個虛構主題，生成 3–5 分鐘大綱，再輸出標題候選、證據需求和待決定項。逐步查看 sidebar 的 prompt 和引用，不要只看最後卡片。

16. Opal 加入媒體節點與人工批准

加入 image generate 或其他 asset 時，明確傳遞比例、用途、禁止元素和上一節點已批准文字。可要求最終 Output 回傳 status: needs_review、版本和檢查項，但這只是治理欄位，不是 Opal 原生、可強制停住的人工批准控制。由人到流程外核對，批准後才在另一個受控系統發布或發送；console 有錯、輸入缺欄或生成失敗時，不可沿用上次結果。分享前核對一般存取是 Private、Anyone with link 還是 Public。

17. Stitch 由業務目標建立多屏 UI

先寫目標、使用者、主要任務和限制，再描述畫面。以虛構旅費 App 為例，包括新增支出、貨幣換算、分帳、總覽和錯誤狀態；指定繁體中文、色彩、底部導覽、鍵盤和對比要求。不要只追求「漂亮」。

18. Stitch 建立 prototype 與設計交接

2026 年的 Stitch 已演進成 AI-native infinite canvas，包含 design agent、interactive prototype、DESIGN.md、voice critique，以及面向開發工具的 MCP／SDK／exports。先探索多個方向，再收斂一個 flow；按 Play 重跑 happy path、返回、取消、錯誤、空狀態和小屏。最後輸出設計規則和 annotations，交給開發測試，不把 prototype 當完成的產品。

八、工作流 19：建立可重用 Gem

Gem 用來固定「怎樣回答」，不是固定「哪些來源是真確」。建立時寫 Persona、Task、Context、Format，另外加入 refusal、引用和驗收規則。Knowledge 只放獲批准、已移除敏感資料的檔案；若使用 Drive，檢查 Connected Apps 和 Keep Activity。

Gem 名稱：內部簡報審稿助手
角色：嚴謹編輯，不替使用者補事實。
任務：按受眾、頁面目的、證據和可讀性審查簡報大綱。
輸出：逐頁問題、嚴重度、來源需要、具體修正、仍需決定。
規則：數字沒有來源便標紅；不同版本衝突便停止；不改變批准事實。
拒絕：不建立公開連結、不讀取未指定 Drive 檔案、不輸出個人資料。
測試：用一份完整大綱和一份故意缺來源的大綱比較行為。

在右側 preview 測試後要按 Save；預覽本身不代表已保存。再用兩個完全不同主題測格式是否一致，以及 Gem 會否把某個測試案例的細節錯帶到另一個案例。

九、工作流 20–21：Gemini Notebook 找來源並產生簡報

20. Discover／Deep Research 找候選來源

建立 Notebook，先加入 3–8 個已批准第一方來源，再使用 discover sources 或 Deep Research 找缺口。搜尋結果只是候選：檢查作者機構、原始發布日期、司法管轄區、版本、授權和是否重複，批准後才匯入。公開影片來源在 Notebook 的處理範圍與視覺能力有限；依賴畫面的操作應另加獲授權截圖或文字紀錄。

21. 由選定來源建立 infographic 與 Slide Deck

在 Studio 選 Infographic 或 Slide Deck，指定繁體中文、受眾、目的、長度、設計和焦點。官方現行 Slide Deck 說明可選 Detailed Deck 或 Presenter Slides，亦可下載 PDF／PPTX；生成和修訂都有配額。重要限制是修訂投影片時不會重新查閱來源，而且暫不能在修訂中新增或刪除投影片，因此每輪修訂仍要回看原始來源。

十、21 個工作流總表

十一、60 分鐘最小實作路線

1. 0–10 分鐘：建立虛構檔案、資料字典和預期答案。
2. 10–20 分鐘：完成工作流 1 或 4，先做資料品質報告，再做分析。
3. 20–30 分鐘：把 checked 結果交給工作流 6 或 7，對回同一總額。
4. 30–40 分鐘：選工作流 14 建一個不連外的最小 App，或選 19 建一個 Gem。
5. 40–50 分鐘：用正常、空白、錯型和越界案例測試；記錄所有失敗。
6. 50–60 分鐘：由另一人按驗收表重跑，標記 approved／rejected／needs changes。

先完成一條小路徑，比在 60 分鐘內點遍 21 個功能更有價值。當一個模組的輸入、輸出、例外和責任穩定後，才接下一個工具。

十二、私隱、成本與發布前 QA

• 資料：只使用有權處理內容；個人資料先刪除或匿名化，正式環境按公司核准工具和保留政策。
• 帳戶：記錄個人／Workspace、方案、管理員設定、Keep Activity 和 Connected Apps。
• 準確：引用、時間戳、圖表和程式測試分開核對；沒有來源便降低主張或刪除。
• 成本：AI Studio project、API key、模型、配額和部署成本有監察；分享 App 前估算其他使用者呼叫。
• 權限：Gmail、Docs、Drive、Calendar、Notebook、Opal 和 App 分享均以低權限帳戶測試。
• 程式：secret 只在 server，依賴、輸入、授權、錯誤、日誌、資料庫和 rollback 均有測試。
• 設計：手機、鍵盤、對比、文字縮放、空狀態、錯誤狀態和替代文字通過。
• 媒體：畫面清晰、有意義、不重複、不含人物或帳戶識別，並標明重建；沒有 loading 或 motion blur。
• 交付：輸出附版本、日期、來源、已知限制、人工批准人和下次覆核日期。

Google 明確提醒 Gemini 可能產生不準確內容，也不應當作醫療、法律、財務等專業意見。Connected Apps 和 Workspace 功能的資料處理亦因帳戶而異；處理機構資料前，應查閱最新 Privacy Hub、Workspace 管理政策和公司內部規則。

十三、常見問題排查

延伸閱讀

• Google AI 生態 30 個工作流選擇指南：先判斷 Gemini、AI Studio、Gemini Notebook 和 Opal 的分工。
• Gemini 工具箱完整教學：深入 Canvas、Deep Research、檔案與 Connected Apps。
• Google AI Studio Build 網站實作：把原型規格、修改和 QA 做得更完整。
• Gemini Canvas UI 到可編輯 Figma：補充設計交接與可編輯稿流程。
• Gemini Notebook 完整工作流：管理來源、研究與各類 Studio 成品。
• 自訂 Gem 與 Canvas 實作：學習固定指令、測試和可重用輸出。

21 個工作流的共同骨架只有六步：定義 → 匿名化 → 生成 → 對源 → 測試 → 批准。只要其中一步沒有負責人和證據，下一個工具只會把未核對內容包裝得更完整。由虛構資料開始、小步交接、逐項驗收，才是把 Gemini 由示範變成可靠工作流程的方法。