Google AI 一人團隊實戰：Gemini、Flow、Gemini Notebook、AI Studio 與 Opal 工作流

「一人公司」很容易被理解成把四個職位交給四個聊天機械人，然後等待自動完成。更實際的設計是把工作拆成五層：研究、角色 SOP、媒體製作、來源知識庫和自動化編排。每一層都有清楚輸入、權限、輸出格式、成本和人工關卡；工具只執行指定工作，真人仍負責決定與發布。

媒體與版本披露：本文封面、6 張步驟圖與 2 段預覽均為 1280×720、使用虛構資料的重製示意畫面，不是來源截圖或片段，也不含人物、作者、帳戶或平台宣傳。產品名稱、模型、資格、Credits、地區和介面會更新，本文以 2026 年 7 月第一方文件作版本校正。

先把「AI 員工」改寫成五層系統與四個受限角色

四個常見角色可以是內容策劃、腳本、視覺和電郵，但角色名並不重要。重要的是每個角色收到甚麼、不可做甚麼、輸出欄位和誰驗收。角色之間不要直接傳一整段未核實文字；應傳遞有版本的 brief、來源表和通過狀態。

步驟一：用 Canvas 由規格建立可編輯內容

Gemini Canvas 可協助建立和修改文件、app、投影片和程式內容，實際入口和匯出方式取決於帳戶可用功能。可靠流程是：先要求規格和故事線，批准後建立最小版本，再逐頁核對。不要把「可以匯出」理解為版面已經適合簡報或正式網站。

任務：建立一份 8 頁繁體中文簡報，向香港小型零售團隊解釋新的會員活動。
受眾：店長和前線同事；閱讀時間 6 分鐘。
輸入：已批准活動規則、常見問題、品牌色和三張已授權產品圖。
輸出：先交頁面規格和故事線；批准後才在 Canvas 建立可編輯投影片。
每頁：一個訊息、最多 45 個中文字、講者備註列證據來源。
限制：不要虛構折扣、日期、店舖或客戶見證；不要使用未授權人物或商標。
驗收：手機預覽可讀、沒有文字溢出、所有規則與原文件一致、圖片有替代文字、最後一頁列下一步和查詢渠道。

Canvas-to-Slides 的驗收次序

1. 逐頁確認只有一個主訊息，標題不重複。
2. 核對所有日期、折扣、產品主張和行動指示是否來自批准文件。
3. 在 16:9、投影和窄屏預覽檢查溢出、裁圖和字體替換。
4. 圖片只用自有或獲授權素材，生成圖亦要檢查人物、商標和文字。
5. 講者備註清楚分開「頁面文字」「補充解釋」「來源」。
6. 匯出後在真正 Slides 或 PowerPoint 再打開，逐頁檢查物件是否仍可編輯。

若 Canvas 產生 app 或 code，還要測試 loading、空狀態、輸入驗證、錯誤、鍵盤、手機、Console 和分享權限。原型可用不代表已完成私隱、安全、資料庫和部署設計。想進一步練習可參考Gemini Canvas 與 Deep Research 完整指南。

步驟二：建立四個 Gem，但用同一份 SOP 骨架

Gem 的價值是把每次都要重講的角色、流程和輸出格式固定。它是 reusable instructions 加可選 context，不是可自行負責的員工。先建立一個角色，拿五個測試 brief 驗收，再複製骨架給其他角色；不要同時做四個卻沒有基準。

名稱：內容策劃 Gem
角色：把已批准研究轉成原創內容 brief，不直接發布。
必要輸入：受眾、渠道、目標、來源包、品牌語調、禁用主張、截止日期。
流程：
1. 先列已收到和欠缺的輸入；欠缺便提問。
2. 從來源包抽取可用事實，每項附檔名或連結。
3. 提出三個互不重複的角度，說明受眾價值和風險。
4. 獲批准後建立結構、證據表、視覺 brief 和交接清單。
禁止：複製來源句子、冒充客戶見證、補寫價格、跳過批准、公開機密資料。
輸出格式：JSON 式欄位加可閱讀摘要；所有未知值標示「待確認」。
驗收：來源可追溯、角度原創、聲稱有證據、格式完整、沒有敏感資料。

四個角色的清楚邊界

• 內容策劃：提出原創角度和證據缺口，不抄熱門標題或作者身份。
• 腳本：把已批准 brief 轉成場景、旁白和畫面，不自行新增數字或產品承諾。
• 視覺：交構圖、比例、色彩、禁用元素和可及性規格，不假裝生成圖已可商用。
• 電郵：交主旨、預覽字、正文和 CTA 變體，遵守品牌、同意、退訂和聲稱政策。

上載知識文件前要去重、標日期、版本和擁有人；移除秘密、個人資料和已過期價格。用已知答案、相反例子、缺資料和惡意指令測試 Gem。如果它在缺文件時仍自信補寫，應在 SOP 加「只使用提供來源，找不到寫待確認」。

步驟三：在 Flow 做媒體，不再沿用舊 Whisk 路徑

Google 在 2026 年 2 月宣布把 Whisk 和 ImageFX 的相關能力移到 Flow。新工作流應由 Flow 現行介面開始：建立 project、產生或加入合法素材、以 frames／ingredients 等當下可用功能建立鏡頭，再檢查模型、比例、音訊、Credits 和標記。不要寫成「另開 Whisk 可永久免費多生成」。

一張可審核的鏡頭卡

用途：教學頁首的 6 秒抽象 B-roll；16:9。
場景：沒有品牌的香港小型辦公室，桌上是抽象工作流程卡。
鏡頭：固定中景，緩慢向前；不快速變焦，不切換視角。
動作：五張流程卡依次亮起，位置全程一致。
聲音：無旁白；只保留很輕的辦公室環境聲。
禁止：真人身份、logo、帳戶、可讀客戶資料、亂碼字幕、額外手指、移除水印。
驗收：首尾構圖穩定、縮圖清楚、沒有閃爍、形變、跳接或來源不明素材。

Flow 的可用國家、年齡、方案、模型和 AI Credits 會改變，生成成本亦按功能而異。開始批量工作前先用一個低風險鏡頭測試，記錄提示、模型標籤、日期、每次 Credits、成功率和重做原因。Google 說明生成內容包含不可見 SynthID，部分方案或地區另有可見水印；不要裁走或刪除應保留的來源標記。

步驟四：AI Studio 做模型與 TTS 試驗，Notebook 做來源大腦

AI Studio 適合比較提示、模型和設定；它不是把原型自動變成穩定 production API 的捷徑。TTS 可先用一小段虛構腳本測試聲音、語速、發音和風格，但官方開發文件仍把相關模型列為 Preview。正式產品要預留模型變更、失敗重試、延遲、成本、地區、披露和備用聲音。

Google 在 2026 年 7 月開始把 NotebookLM 品牌更新為 Gemini Notebook；舊網址、文件和分批介面仍可能顯示 NotebookLM。它適合把一個專案的合法來源集中，提供帶引用回答，再產生報告、心智圖、音訊或影片等 Studio 成品。每個 notebook 應保持單一目的，避免市場資料、客戶機密和公開素材混在一起。

AI Studio TTS 聆聽清單

• 人名、品牌、英文縮寫、粵語書面詞和數字是否讀對。
• 音量、停頓、速度和情緒是否一致，句尾有否被截斷。
• 同一提示重跑是否有足夠穩定性，失敗時能否回退。
• 聲音使用、AI 披露和所在地規則是否符合用途。
• 不要用他人聲音作未獲同意的模仿或誤導。

Gemini Notebook 來源工作流

1. 一個專案一個 notebook，建立來源 manifest 和截至日期。
2. 只加當下相關、獲授權文件；重複或過期版本先刪除或標記。
3. 先問它實際讀到哪些來源，再問內容問題。
4. 重要回答逐一點開引用，核對原文和上下文。
5. 音訊、影片、心智圖和投影片只當草稿，回到來源驗收。
6. 分享前用另一個最低權限帳戶測試可見來源和輸出。

更多來源限定的實例可看Gemini Notebook 八個工作與學習場景，以及Gemini Notebook／NotebookLM 完整工作流。

步驟五：用 Opal 編排流程，但每個高風險點要停

現行 Gemini Help 把 Opal 驅動的實驗工作流描述為 Gems from Google Labs；資格可能限個人 Google 帳戶、18 歲以上、桌面網頁、英文，而且不供工作或學校帳戶。即使你的帳戶有入口，也不應假設香港、語言或資料處理與別人相同。開始前查看當下 Help、Drive 和 Privacy Hub。

輸入：一條使用者有權處理的公開影片網址，或一份已授權逐字稿。
步驟一：先確認存取、字幕、語言、日期和使用權；失敗便停止。
步驟二：抽取主題、問題、結構和可核對主張；不複製標題、身份、話術或受保護段落。
步驟三：用第一方來源更新產品、價格、限制和時間敏感事實。
步驟四：建立全新文章角度、H2 結構、證據表和媒體重製清單，等候人工批准。
步驟五：撰寫繁體中文草稿；把事實、推論、建議和未知分開。
步驟六：執行身份、版權、引用、私隱、重複圖片、模糊畫面和內部連結 QA。
輸出：草稿、來源、QA 結果、未解問題；永不自動發布。

自動化流程最好以狀態機理解：待輸入 → 權限通過 → 來源通過 → 大綱通過 → 草稿通過 → 媒體通過 → 待發布。任何一關失敗都回到上一個可控步驟，而不是叫模型「自行修好後發布」。若工作流處理影片，字幕只代表語音，不代表已理解畫面；視覺教學仍需合法、清晰和人工選取的圖片。

把四個角色串起來：交接只傳批准成果

內容策劃 Gem 先讀研究包並提出三個原創角度；真人選一個後，腳本 Gem 才產生場景和證據欄。視覺 Gem 接收的是批准場景，不是整段聊天；電郵 Gem 接收的是批准賣點、合規限制和 landing page。每個角色輸出都包含版本、來源、未知和下一位接收者。

成本與效益：不要只計「第一次生成用了幾分鐘」

「完全免費」和「一人頂一隊」都不能作營運假設。建立基準：人工由 brief 到交付需要多久、錯誤和退回多少次。試行時記錄 Gemini／Flow／其他服務用量、生成等待、Credits、重試、人工核對、版面修正和未採用資產。若第一稿快十分鐘但要兩小時修正，就不能只報告生成時間。

• 速度：由批准 brief 到可交付版本的總時數。
• 品質：每百項事實錯誤、引用錯位、版面問題和媒體棄用率。
• 成本：方案、Credits、儲存、API、人工審核和重做。
• 風險：敏感資料、權利不清、錯誤發布和不可回復操作。
• 可維護性：SOP、知識版本、模型更新和替代流程是否完整。

私隱、權限與公司使用

個人帳戶、Workspace 帳戶、Gemini Apps Activity、Connected Apps、Drive 和 Opal 資料可能有不同處理。不要由產品名稱推斷資料一定不被保留或使用。公司使用前確認獲批准帳戶、管理員設定、資料地區、合約、保留、分享和刪除；只給最小檔案與最小連接。

• 不要把密碼、cookie、session、API key 或付款資料放入 Gem 知識或 Opal 輸入。
• 文件上載前刪除隱藏分頁、註解、修訂記錄和不相關個人資料。
• 公開 Canvas 或工作流前，以無痕和非擁有人帳戶測試可見內容。
• 生成媒體保存提示、日期、模型標籤、素材權利和人工批准。
• 敏感或受規管內容使用獲公司批准的受管流程；詳情參考香港生成式 AI 私隱指南。

30 日導入計劃

1. 第 1–3 日：選一個低風險、每週重複、成果清楚的流程；建立人工基準。
2. 第 4–7 日：整理合法來源、資料分類、角色 SOP 和五個測試案例。
3. 第 8–12 日：只建立一個 Gem 和一個 Canvas 成品；記錄所有失敗。
4. 第 13–17 日：加入 Notebook，測試引用、過期來源、缺資料和分享權限。
5. 第 18–21 日：以 Flow 做一個媒體資產，驗收 Credits、權利、標記和重做率。
6. 第 22–25 日：若帳戶符合資格，以 Opal 串兩至三步，所有寫入和發布仍停在人工關卡。
7. 第 26–28 日：讓未參與設計的同事依 SOP 重跑，找出隱藏知識。
8. 第 29–30 日：比較時間、成本、錯誤和風險；只擴大真正通過的部分。

發布前總清單

• 沒有把 Gem 稱為能承擔責任的員工，也沒有承諾功能完全免費。
• Canvas 成品的事實、溢出、手機、無障礙、圖片權利和分享權限已驗收。
• Gem 知識有日期、版本、擁有人；欠缺資料時會停止而非補寫。
• Flow 使用當下介面；沒有沿用獨立 Whisk 舊路徑或移除 provenance。
• AI Studio TTS 以 Preview 風險管理，完成真人聆聽和備用測試。
• Gemini Notebook／NotebookLM 的重大引用已打開，Studio 成品已回查來源。
• Opal 資格、語言、帳戶和資料處理已確認；任何發布仍由真人批准。
• 人物、作者、帳戶、來源宣傳、通知、密碼和其他識別沒有進入圖片或影片。
• 六張圖各自有明確步驟價值，兩段預覽沒有重複、模糊或 loading。
• 總時間、Credits、重做和可發布比例已有實測，不使用空泛效率倍數。

總結：一人團隊的核心是治理，而不是工具數量

Gemini、Flow、AI Studio、Gemini Notebook 和 Opal 可以把研究、製作和交接放在同一生態，但越多連接不等於越成熟。最可持續的做法是先有一份批准 brief，再用 Gem 固定角色，用 Canvas 和 Flow 產生可檢查成品，用 Notebook 保存合法來源，最後才用 Opal 編排重複步驟。每一層都能停止、退回和由人驗收，才是真正可營運的「一人團隊」。