← PRAC 2-3 多觸發條件
PRAC 2-4 · CAPSTONE PROJECT
完整專案：週報自動生成器
Part 2 的整合專案。把 PRAC 2-1 到 2-3 學到的所有技術組合成一個端對端的自動化系統：每週五自動從多個來源收集資料，用 AI 生成週報，發送給指定名單。
●
專案目標：建立一條每週五下午 5:00 自動執行的流程，從 Google Sheets、Google Calendar、Gmail 收集本週資料，用 AI 生成結構化週報，自動發送 Email。同時加入錯誤處理和執行確認機制。
系統架構
Schedule 觸發
週五 17:00
→
讀取 Calendar
本週會議
+
讀取 Sheets
本週任務完成
+
讀取 Gmail
本週重要郵件
資料彙整
Text Aggregator
→
AI 生成週報
OpenAI / Claude
→
Email 發送
+ Notion 存檔
STEP BY STEP · 建置步驟
1
準備資料來源
確認以下三個資料來源已設定好授權：（1）Google Calendar — 你的工作行事曆；（2）Google Sheets — 你的任務追蹤表，至少有「任務名稱」和「完成日期」欄位；（3）Gmail — 需要設定搜尋條件來篩選「重要」郵件（建議用標籤）。
2
建立主 Scenario 並設定觸發器
在 Make 建立新 Scenario，觸發器選「Schedule」，設定為：每週、週五、17:00。如果要立即測試，先選「Run once」，觸發後再改回排程。
3
加入三個資料讀取節點
並行加入三個「搜尋/讀取」節點，分別從三個來源收集本週資料：
節點 1：Google Calendar - Search Events
- Calendar: [你的行事曆]
- Time range: 本週一 00:00 ~ 本週五 23:59
（用 Make 的 date formula: {{formatDate(now; "YYYY-MM-DD"}} 搭配減法）
節點 2：Google Sheets - Search Rows
- Spreadsheet: 任務追蹤表
- Filter: 完成日期 >= 本週一
節點 3：Gmail - Search Emails
- Search query: label:important after:{{本週一}} before:{{本週五}}
提示：Make 提供日期函數（如 addDays、formatDate）來計算相對日期。點選節點的日期欄位，輸入 {{}} 後可以看到可用的函數清單。
4
用 Text Aggregator 彙整資料
加入「Tools」→「Text Aggregator」節點，把三個來源的資料整合成一個文字塊，作為 AI 的輸入。設定格式：
彙整模板：
=== 本週會議 ===
{{calendar_events}}
=== 完成的任務 ===
{{completed_tasks}}
=== 重要郵件 ===
{{important_emails}}
5
加入 AI 週報生成節點
加入 OpenAI 節點，用以下 Prompt 生成週報：
System:
你是一位工作週報撰寫助理。根據提供的原始資料，生成一份清晰的工作週報。
格式要求：
- 使用繁體中文台灣用語
- 標題：{{本週週次}} 工作週報
- 結構：本週完成事項 / 重要溝通摘要 / 待辦延續 / 下週重點
User:
以下是本週的工作原始資料：
{{aggregated_data}}
請生成週報。如果某個類別沒有資料，寫「本週無」。
6
加入錯誤處理機制
在 AI 節點和 Email 節點上右鍵，設定 Error Handler：選擇「Break」，然後在錯誤路由中加入一個 Gmail「Send an Email」節點，發送錯誤通知給自己。錯誤 Email 的主旨設為「[週報系統] 自動化流程失敗」，Body 包含錯誤節點名稱和錯誤時間。
7
發送週報 + 存入 Notion
最後加入兩個並行節點：（1）Gmail「Send an Email」—— 把 AI 生成的週報以 HTML 格式發送給週報訂閱名單；（2）Notion「Create a Page」—— 把週報存入 Notion 的「週報存檔」資料庫，方便日後搜尋查閱。
提示：Notion 頁面標題可以用 {{formatDate(now; "YYYY-MM-DD")}} 帶入日期，讓每份週報有唯一標題。
8
測試完整流程
點「Run once」執行完整流程測試。確認：資料讀取節點成功取得本週資料 → AI 節點生成了合理的週報內容 → Email 正確送出 → Notion 存入了新頁面。確認無誤後啟用排程。
完成驗收 · VERIFY
手動觸發一次流程 → 你的信箱收到了格式完整的週報 Email → Notion 存入了對應日期的週報頁面 → 測試錯誤處理：暫時斷開一個連接，重新執行，確認你收到了錯誤通知 Email。
PART 2 SUMMARY · 你完成了什麼
Part 2 工作流程自動化入門——已完成
觸發器設計
條件路由
AI 節點整合
多觸發流程
錯誤處理
資料彙整
排程自動化
Make 實戰操作
PORTFOLIO
把這個成果存到「我的作品集」，結訓時可一鍵匯出。
SOLO · 自我演練
把工作流圖（截圖或節點清單）貼給 LLM，叫它扮「資深技術主管專做自動化審查」，挑出 1 個節點寫「他不會這樣設計的原因 + 風險場景」——決定要不要調整。
5 分鐘
進階選配 · 不計入課程時數（給想加練的學員）
把 LLM 對話截圖存到學習資料夾，或貼到自己的工作群組／社群求 review。這些痕跡在轉職投履歷時可作為作品集素材。
REAL TASK · 換成你的版本
把週報自動化套到你每週真的要交的那份報告
- 你每週要交的報告是哪一份？資料來源散在哪幾個地方？
- 哪一段最花時間（蒐集 / 整理 / 寫文 / 校對）？
- 把那段切出來設計工作流節點，預期省下多少分鐘
DEBUG · 把這個缺錯誤處理的工作流設計修好
工作流程：
1. 每週五下午 5 點自動觸發
2. 讀取 Google Sheets 上的週工作紀錄
3. 送給 AI 整理成週報格式
4. 把週報寄到主管的信箱
解法參考（先寫自己的版本再展開）
原版的問題：
1. 沒有處理「Google Sheets 當週無資料」的情況——工作流會繼續跑、送空白週報給主管
2. 沒有處理 AI 呼叫失敗或超時的情況——整個流程直接中斷，沒有通知也沒有重試
3. 沒有處理信箱寄送失敗的情況——週報已生成但無法得知是否送達
參考改法：
1. 每週五下午 5 點自動觸發
2. 讀取 Google Sheets 當週工作紀錄
→ 若工作表為空或列數 < 3：停止並發送 Slack 通知「本週 Sheets 無資料，工作流已暫停」
3. 送給 AI 整理成週報格式（逾時設為 30 秒）
→ 若 AI 呼叫失敗或逾時：重試 1 次；仍失敗則發送 Slack 通知「AI 整理失敗，請手動處理」並附上原始資料連結
4. 把週報寄到主管信箱
→ 若寄送失敗：發送 Slack 通知「週報寄送失敗，請手動轉寄」並附上週報草稿連結
5. 完成後記錄執行結果到 Sheets 的「執行紀錄」分頁（時間、狀態、週報字數）
關鍵改動：每個步驟加 fallback 路徑（空資料→停止通知；AI 失敗→重試→通知；信件失敗→通知+草稿）；加執行紀錄（下次除錯有憑據）。工作流設計的鐵則：成功路徑 1 條，失敗路徑至少 1 條。
GALLERY · Part 2 LLM 多角色巡迴
叫 LLM 扮不同職位同事審你的「會議轉待辦 / 文書模板 / 提案骨架」三選一
- 從 Part 2 產出選一件最有把握的（會議轉待辦、文書模板、或提案大綱）當作 v1。
- 把作品貼給 LLM 扮 1 位角色（建議 PM—會盯交付與時程），請它回答「如果要直接用，還缺 ___」或「___ 要素讓輸出特別好用」。看是否點到本節核心。
- 寫一句「我的文字工作流下次會改進的點是 ___」貼下方。
進階選配 · 不計入課程時數（給想加練的學員）
完整 3 角色巡迴：除 PM 外，再請 LLM 扮 (2) RD/技術主管—會挑邏輯與資料正確性；(3) 設計師—會看可讀性與結構清晰度。每位都要回答「如果要直接用，還缺 ___」或「___ 要素讓輸出特別好用」。整理三位視角的共同點與衝突點，把回饋截圖貼到個人作品集資料夾（雲端硬碟連結 / 截圖檔皆可），轉職時可作為文字工作流壓測的證據。
DOCUMENT ANALYSIS · 文件分析工作流情境演練
4 個真實文件，看 AI 怎麼啃下來
週報流程搭完後，下一個常見戰場是「一份厚文件丟進來，限你 30 分鐘給老闆 10 行摘要」。這 4 個情境涵蓋長 PDF、手寫圖、競品對比、合約審閱四種高頻任務。每組附上分析 Prompt 與上傳提示，直接展開複製貼進 AI 工具就能測。
情境 A
40 頁市場研究報告 PDF｜抽結論 + 頁碼引用
情境 A｜長 PDF 報告
● 文件規格：40 頁 PDF，含圖表、數據表、結論章節，檔案約 8 MB。
● 目的：2 小時內向主管口頭報告「這份研究對我們下一季策略有什麼用」。
● 輸出要什麼：5 個核心結論，每個結論後標示原文頁碼（方便被問時翻回去查），用條列呈現，不要散文。
分析 Prompt + 上傳提示
[上傳提示] 把整份 PDF 拖進對話視窗，等待處理完成再發送本訊息。若檔案 > 10 MB，先用 PDF 工具切成兩份再分次上傳。建議使用支援長 context 的工具（200K tokens 以上）。
## 角色
你是市場策略分析助理，專長是從長篇研究報告中抽出「對決策有用」的核心結論，並保留可追溯性。
## 任務
閱讀我上傳的 40 頁市場研究報告，抽出 5 個最核心的結論。
## 限制
- 每個結論必須標註來源頁碼，格式：「結論文字（p.XX）」或跨頁「（p.XX-YY）」
- 若某結論橫跨多頁的論述，標出最主要的那 1-2 頁，不要塞一整串頁碼
- 結論必須有「可行動性」：讀完能導出下一步，不是純描述市場現況
- 禁止使用原文沒出現的數字或主張；若不確定，改寫成「報告指出⋯⋯」並加頁碼
- 每個結論 80 字內
## 輸出格式
編號 1-5，每個結論一段，結尾加（p.XX）。最後加一行「讀完這 5 點可先做的 1 個動作：⋯⋯」。
預期輸出格式
條列 1-5，每點以「結論句子 + （p.XX）」收尾；最後一行為「讀完這 5 點可先做的 1 個動作」。頁碼必須是原 PDF 的實際頁數（不是章節編號）。
AI 結果回收 · RECYCLE
情境 B
一張手寫白板照｜OCR + 結構化筆記
情境 B｜白板照片
● 文件規格：一張 iPhone 拍的白板照，內含會議中畫的流程圖、待辦清單、決議箭頭，手寫字混中英文，有部分字跡潦草。
● 目的：會議結束 10 分鐘內丟進群組，讓沒參加的人看得懂。
● 輸出要什麼：先輸出 OCR 原文（供使用者檢查辨識錯誤），再輸出結構化筆記（主題／決議／行動項／Open Issues 四段）。
分析 Prompt + 上傳提示
[上傳提示] 把白板照直接拖進對話視窗。若照片有反光或過暗，先在手機用「掃描文件」模式重拍一張正面無反光版本。支援視覺辨識的工具都能處理（多模態模型）。
## 角色
你是會議紀錄整理助理，擅長從手寫白板照還原討論脈絡。
## 任務
先做 OCR，再做結構化筆記。兩階段分開輸出。
## 限制
- 第 1 階段「OCR 原文」：一行一行還原白板上的文字與箭頭走向，保留原位置感（上下左右大致對應）。辨識不確定的字用 ⟨?字⟩ 標註，不要自動腦補
- 第 2 階段「結構化筆記」：固定四段——【主題】【決議】【行動項：誰／做什麼／期限】【Open Issues】。每段不超過 5 條
- 若白板上沒寫期限，行動項的「期限」欄填「未定」，禁止自己編日期
- 手寫縮寫（例：「PM 下週交」）必須保留原樣並在括號加推測解釋
- 兩階段之間用「=== 以下為結構化筆記 ===」分隔
## 輸出格式
第 1 段：OCR 原文（逐行）
第 2 段：四段式結構筆記
最後一行：「需使用者確認的辨識疑點：⋯⋯」條列列出 ⟨?⟩ 標記的位置。
預期輸出格式
兩段式：先「OCR 原文」（逐行、不確定處用 ⟨?⟩），再「結構化筆記」（主題／決議／行動項／Open Issues 四區塊）。結尾列出需人工確認的辨識疑點清單。
情境 C
三份競品 PDF｜功能矩陣 + 弱點分析
情境 C｜競品 PDF 比較
● 文件規格：3 家競品的官方產品白皮書／規格書 PDF，每份 10-20 頁，各自結構不同。
● 目的：週五下班前交一份內部比較報告，讓業務與產品團隊用同一份資料對外報價與打規格戰。
● 輸出要什麼：一張功能矩陣表（欄＝競品、列＝比較維度），下接「每家弱點 3 條」，最後一段「我方最佳切入點」。
分析 Prompt + 上傳提示
[上傳提示] 把 3 份 PDF 同時拖進對話視窗，並在檔名前加 A_、B_、C_ 前綴（例：A_競品甲_白皮書.pdf），方便 AI 在輸出時用 A/B/C 指代。建議選長 context 的工具以免截斷。
## 角色
你是競品分析師，擅長用固定維度把異質資料壓成可讀的矩陣。
## 任務
對比上傳的 3 份競品白皮書，產出矩陣 + 弱點 + 切入點三段式報告。
## 限制
- 先在開頭列「比較維度」共 6 項：定位／核心功能／價格策略／目標客群／整合能力／上手曲線
- 所有儲存格內容必須引自原文，引用處以「A p.X」「B p.Y」標註頁碼；若某競品該維度文件未提，填「—（未載明）」
- 禁止自己補市場常識、禁止主觀形容詞（例：「很強大」「略顯不足」）
- 弱點分析每家 3 條，每條附引用頁碼，寫法：「現象（A p.X） → 我方可攻擊的角度」
- 最後「我方最佳切入點」只列 1 條，要同時利用 A 的弱點 × B 的弱點 × C 的弱點，避免單打一家
- 整份不使用模型版本號或自我介紹
## 輸出格式
第 1 區：Markdown 表格（7 欄：維度／A／B／C，頁碼寫在儲存格內括號）
第 2 區：每家弱點 3 條，共 9 條
第 3 區：我方最佳切入點 1 條，80 字內
預期輸出格式
3 區塊：(1) 6×4 Markdown 表格，儲存格含頁碼引用；(2) 每家弱點 3 條共 9 條，每條標頁碼；(3) 我方最佳切入點 1 條（80 字內）。未載明的維度標「—」。
情境 D
合約 PDF 審閱｜不利條款 + 位置標示
情境 D｜合約審閱
● 文件規格：一份 15-30 頁中文合約 PDF（例：供應合約、授權合約、NDA），條款編號式結構，中英夾雜可能。
● 目的：在正式簽核前 24 小時，先讓法務主管看到「有哪些條款要改」而不是整份重讀。
● 輸出要什麼：按「對己方不利程度」由高到低排序的紅旗清單，每條含條號、原文節錄、風險描述、建議改法。明確標示「位置」而非「意見先行」。
分析 Prompt + 上傳提示
[上傳提示] 把合約 PDF 拖進對話視窗。若是掃描版（圖片式 PDF），先用 OCR 工具轉成可選取文字的 PDF 再上傳，否則 AI 只能靠視覺猜測、誤差很大。
## 角色
你是合約審閱助理，立場是「己方」。你的第一件事是「標紅關鍵條款」，第二件事才是提出修改建議——不能先表達主觀意見。
## 任務
通讀合約，產出「紅旗條款清單」。
## 限制
- 第 1 階段：僅標出「位置」——列出所有可能對己方不利的條款，格式：「第 X 條 第 Y 款（p.Z）：原文節錄不超過 30 字」。這階段不寫意見
- 第 2 階段：對第 1 階段每條給出「風險描述」與「建議改法」，用三段式：【原文】【風險】【建議改法】
- 不利條款的判準包含但不限：單方終止權、責任上限過低、智財歸屬、保密無期限、違約金不對等、管轄地對己方不便
- 嚴禁使用「這條沒問題」這類主觀意見；若某條看起來中性，不列入清單即可
- 排序：按對己方損失大小由高到低，而非按條號順序
- 不要自己虛構沒在合約中出現的條文
## 輸出格式
先輸出第 1 階段（位置清單、不帶意見），再用「=== 以下為風險與建議 ===」分隔，再輸出第 2 階段（每條三段式）。最末加一行「建議在法務會議先討論的前 3 條」。
預期輸出格式
兩階段：先純「位置清單」（條號 + 原文節錄 + 頁碼，不帶意見），再「風險 + 建議改法」三段式。按損失大小排序，末尾標示「先開會討論的前 3 條」。
CHALLENGE & QUIZ · 延伸挑戰 + 通關檢測
用真文件跑一次，再自測有沒有抓到要領
看完 4 個範例情境還不夠。文件分析的手感是「看 AI 錯在哪裡」練出來的。下面 3 個挑戰會逼你用自己的文件跑一輪、做準確度校驗、比較不同工具差異。跑完再做 5 題自測。
🎯
延伸挑戰（預計 20 分鐘）
實戰拿你下週真的要讀的一份文件（週會簡報、客戶提案、合作草約任選一），套用情境 A 或 D 的 Prompt 跑一次分析。驗收：輸出是否直接可貼到會議紀錄或法務便條，不需再排版。
準確度校驗從 AI 的輸出裡隨機挑 3 個結論，翻回原文去驗證。記錄：(1) 完全正確幾條、(2) 頁碼錯幾條、(3) 內容被自行腦補幾條。這會告訴你哪種任務可以放心交給 AI、哪種要自己再讀。
工具切換同一份文件、同一段 Prompt，分別丟進 ChatGPT、Claude、Gemini 各跑一次。觀察：哪個工具對長 PDF 引用頁碼最穩？哪個對手寫圖 OCR 最準？哪個容易在合約審閱時「裝懂」？把差異寫成 3 行筆記，存起來以後選工具用。