# 目錄
## 1. 介紹與基礎概念

* Introduction
* Discussing Internet Standards, REST and OAuth2

---

## 2. n8n 自架環境與第一個 AI Workflow（Chatbot）

* Getting Started – Setup n8n on Hostinger (self-hosted)
* Create First Workflow Example (AI – Chatbot)
* Add an AIAgent Node to Workflow
* Add OpenAI Chat Model sub node to AiAgent Node
* Add Credentials to OpenAI Chat Model sub node
* Add a System Prompt to AIAgent Node
* Add Memory Sub Node to AiAgent (to Add Context)
* Test ChatBot WorkFlow

---

## 3. Hostinger 與 n8n 操作說明

* Logging on to Hostinger and n8n

---

## 4. Workflow 範例二：WhatsApp Panic App（註冊流程）

* Create Workflow Example 2 (WhatsApp Panic App Registration)
* Create Google Spreadsheet
* Add and Setup OnSubmission Form Trigger Node
* Add and Setup Google Sheets Node
* Setup Credentials for Google Sheets Node (using OAuth2)

---

## 5. Workflow 範例三：WhatsApp Panic 通知系統

* Create Workflow Example 3 (WhatsApp Panic Notifications)
* Add WhatsApp Trigger Node and Setup Credentials
* Setup other Workflow Nodes (WhatsApp Panic Notifications)
* Test WhatsApp Panic App Notifications Workflow

---

## 6. Workflow 範例四：履歷審核／面試排程（Human in the Loop）

* Create Workflow Example 4 (CV Approval / Interview Scheduler)
* Setup Google Drive Node and Configure Credentials
* Setup Loop Node
* Setup Human in the Loop Node
* Setup AIAgent Node for Scheduling Interview on Google Calendar
* Test CV Approval / Interview Scheduler Workflow – Human in the Loop

---

## 7. 架構優化與進階應用

* Abstract Sub-WorkFlow to Create Separation of Concerns
* Extra Information

---

## 8. 其他實用整合技巧

* Use WhatsApp to Converse with ChatBot
* Use a WebHook Trigger Node to Trigger your Workflow
* Use the HttpRequest Node to Make Requests to External Web APIs
* Integrate JavaScript Code into Workflow using Code Node

---

## 9. 結尾
* Outro

---
# 1. 介紹與基礎概念
## 課程定位與目標

* n8n 是一個開源的工作流程自動化平台，用來串接各種 App、API、服務以自動化任務
* 課程設計從新手到能做出實務解決方案，強調不用大量寫程式也能做出複雜流程
* 講師 Gavin Lon 以四個範例工作流程帶學，逐步示範整合 WhatsApp、Google Sheets、Google Drive、Gmail、AI agent 等服務

## n8n 的核心概念

* 透過圖形化介面把「節點（node）」串成「工作流程（workflow）」來自動化任務
* 節點代表一步操作，工作流程代表一連串自動化步驟
* 設計流程的思考方式和寫程式類似：條件判斷、迴圈、分離關注點、抽象化
* 需要更細緻功能時也可在流程中嵌入程式碼，但範例主軸是低碼/少碼

## 先備網路整合標準：REST 與 OAuth 2

* REST 常用於呼叫 Web API，使用標準網路協定與常見資料格式（JSON/XML）交換資料
* OAuth 2 用於安全授權與權限取得，例如讓 n8n 以 Gmail 身分在流程中寄信
* 這些標準讓不同系統即使由不同團隊、不同時間、不同地點開發，也能安全互通
* n8n 把底層複雜度抽象掉，讓開發者聚焦在流程的業務規則

## 範例 1：AI 排行聊天機器人（可延伸到 WhatsApp）

* 用 ChatGPT 類模型做一個「依提示產出排行清單」的聊天機器人（如電影前五名、最大哺乳類等）
* 作為入門範例，重點是熟悉 n8n 工作流程與把 AI 納入流程
* 之後示範把 WhatsApp 接進來，讓使用者能用 WhatsApp 和聊天機器人互動

## 範例 2：WhatsApp 緊急求助通知（WhatsApp Panic App）

* 用 WhatsApp 觸發緊急求助流程，從 Google Sheets 讀取使用者地址並通知值班人員
* 背景動機是提供低成本求助方式，讓沒有私人保全的人也能透過手機與網路求援
* 使用者在緊急狀況可只傳送簡短代碼（例如「1」）以節省時間
* 值班人員收到包含地址的通知後，可派遣應變人員前往處理

## Panic App 的兩段流程設計

* 註冊流程：使用者填表提供 WhatsApp 號碼、姓名、地址等資料，寫入 Google Sheets；WhatsApp 號碼作為識別鍵
* 求助流程：WhatsApp Trigger 收到「1」後啟動，查表對應號碼取得地址，再把求助通知發給值班人員

## 範例 3：履歷/CV 自動處理與「Human-in-the-loop」

* 把履歷 PDF 放入指定 Google Drive 資料夾，流程讀取檔名與檔案 ID 並逐一處理
* 透過迴圈逐份下載履歷，將 PDF 由二進位轉成文字後交給 AI 產生特定格式的摘要
* 摘要用 email 寄給負責人，信中提供「核准/拒絕」兩個按鈕讓人做決策
* 流程會暫停直到人按下核准或拒絕，體現人類參與的審核關卡

## 範例 3 的後續自動化：核准後排面試

* 若核准，流程繼續並用 AI agent 協助在面試官的 Google Calendar 安排面試
* 若拒絕，跳過排程步驟並進入下一份履歷的迴圈處理
* 若資料夾有多份履歷，迴圈會對每份執行一次，逐一完成篩選與排程

## 範例 4 與延伸內容的鋪陳

* 文中提到共四個完整範例，但此段主要詳述前三個與基礎標準，第四個細節未在這段文字中展開
* 影片結尾會再補充一些更酷但較不細講的工作流程點子，目的是刺激觀眾發想自己的自動化需求

## 節點串接示意：以 Panic App 為例

* WhatsApp Trigger 節點接到 Google Sheets 查詢節點，再接到讀取/處理節點，最後接到 Gmail 發信節點
* 透過把節點依序串接，達到「收到求助→查表取地址→通知值班」的自動化任務
* WhatsApp 與 Google 服務能在同一流程中無縫整合，根本原因是 REST、OAuth 2 等互通與授權標準

---
# 2. n8n 自架環境與第一個 AI Workflow（Chatbot）
## 在 Hostinger 以自架模式部署 n8n

* 使用 Hostinger 的 VPS（Virtual Private Server）搭配預先配置的 n8n 範本，安裝相對簡單
* 流程是先選方案與付款週期（例如 1 個月／12 個月／24 個月），再選機房地區與作業系統
* 登入並填寫帳單資訊後完成設定，可選擇取消不需要的加購項目（如惡意掃描）
* 系統會自動安裝，完成後到 VPS 管理頁面進入 n8n 應用管理

## 建立 n8n 擁有者帳號

* 在 n8n 應用的管理頁面建立 owner 帳號
* 設定之後登入 n8n 會用到的密碼
* 可依需求自訂 n8n 的基本設定與介面外觀

## 建立工作流程與資料夾整理

* 先建立資料夾集中管理新的工作流程（例如「my workflows」）
* 進入資料夾後建立新 workflow，會看到工作畫布（canvas）

## 工作流程的 Trigger 概念

* 每個 workflow 必須從 Trigger 開始
* Trigger 可能是手動觸發、Webhook、表單提交等
* 建立 AI Agent 節點時，通常會自動加上「When chat message received」作為 Trigger

## AI Agent 節點介面與資料流


* 畫布呈現由左到右的資料流：Trigger 接收訊息 → 傳給 AI Agent
* AI Agent 的「User Message / Prompt」通常會用表達式讀取輸入（例如從 JSON 的 chatInput）
* 若尚未有輸入資料，執行節點會失敗或顯示無輸入狀態

## 產生輸入與常見錯誤

* 可先在聊天輸入區輸入問題，讓 Trigger 產生輸入資料
* 常見錯誤是 AI Agent 尚未連接 Chat Model（缺少模型子節點），會提示必須連接並啟用

## 連接 OpenAI Chat Model

* 在 AI Agent 的 Chat Model 連接點新增子節點
* 從清單中選 OpenAI Chat Model，讓 AI Agent 具備可用的 LLM

* 在模型下拉選單可挑選目標模型（示範使用 GPT-4.1 mini）

## 建立 OpenAI 憑證與 API Key

* 在 OpenAI Chat Model 的憑證欄位選擇建立新憑證
* 需要填入 API key 才能呼叫 OpenAI

* 到 OpenAI 平台建立帳號並在儀表板建立新的 secret key
* 新建 key 只會顯示一次，需立刻複製貼回 n8n 並儲存

## 測試執行與輸出過於冗長的問題

* 連接模型與填好憑證後，可在 AI Agent 直接執行節點測試
* 範例提問「前五名國家橄欖球隊」會得到含大量說明的回覆
* 需求是只要清單結果，避免多餘文字以節省 token

## User Prompt 與 System Prompt 的差異

* User Prompt 是使用者的問題或指令，用來描述想要的內容
* System Prompt 是在使用者互動前設定的規則，用來控制風格、格式、邊界與行為
* 透過 System Prompt 可要求更精簡、只輸出清單、限制格式等

## 在 AI Agent 設定輸出格式的方向

* AI Agent 介面可調整 Prompt/參數來影響模型回應
* 可啟用「要求特定輸出格式」之類的設定，讓輸出符合預期結構
* 目標是讓回覆只輸出項目名稱，不附帶額外說明文字

---
## 在 n8n 新增 system prompt 的位置與用途

* 透過新增選項加入「System message」來設定 system prompt
* system prompt 用來定義 AI 的角色與行為規範

## 用 Markdown 結構化 system prompt 內容

* 用標題區分段落，讓開發者更易閱讀與維護
* 角色區塊：定義 AI 是提供精簡排行清單的助理
* 指令區塊：規定輸出格式與內容限制

## 輸出格式規則設定

* 每個排行項目必須獨立一行
* 每個項目只包含名稱，不包含額外資訊或描述

## 用範例引導輸出格式（One-shot / Few-shot）

* 在 prompt 中提供輸出範例，讓模型學到期望的格式
* 例子包含「前五名國家橄欖球隊」與「前五名電影」
* 這屬於 few-shot（提供多個例子），介於 zero-shot 與更多例子的 few-shot 之間

## 工作流程資料流與回傳格式

* Chat Trigger 的輸入流向 AI agent，再交由 LLM（例如 OpenAI）生成回覆
* 回傳內容會依 system prompt 的格式規則輸出
* 可在節點中查看輸出結果與 JSON 格式

## 問題：沒有記憶就沒有對話脈絡

* 初次詢問「前五名電影」可正常回答
* 追問「下一個五名」會失敗，因為缺乏前一次問題的上下文
* 造成回覆要求使用者重新提供類別或背景

## 為聊天機器人加入 Memory

* 在 AI agent 下方的 Memory 連接點加入記憶模組
* 選擇「Simple memory」作為基本記憶方案


* Context window length 設定記住最近幾次互動（範例使用 5）
* Session ID 用來維持同一段對話的連續性，確保記憶能套用到同一會話

## 加入 Memory 後的效果驗證

* 問「前五名橄欖球國家隊」後再問「下一個五名」可正確延續脈絡並補出第 6–10 名
* 更換主題（例如作者排行）後再問「下一個五名」也能延續該主題的上下文

## 聊天機器人與 Agent 的差異定位

* 這裡做的是可對話的 chatbot，重點是回答問題並保留上下文
* 真正的 agent 會採取行動完成任務（例如安排面試並寫入行事曆）

---
# 3. Hostinger 與 n8n 操作說明
## 在 Hostinger（n8n）建立與命名工作流程

* 登入 Hostinger 後進入 n8n 管理介面
* 在個人空間建立資料夾（例如 my workflows）集中管理
* 將上一段建立的工作流程重新命名為「Example 1 - Chatbot」

# 4. Workflow 範例二：WhatsApp Panic App（註冊流程）

* 新增另一個工作流程命名為「Panic App Registration」
## 建立 Google Sheets 作為註冊資料庫

* 登入 Google Sheets 並建立新的空白試算表
* 將試算表命名為「panic app registration」
* 建立欄位標題：First name、Last name、Email、Address 1、Address 2、WhatsApp number
* Address 1/2 以非正式聚落為例：Address 1 可放門牌或屋號、Address 2 放區塊/區域（如 Block B）
* WhatsApp number 作為唯一識別欄位，用來對應每位註冊者

## 在 n8n 新流程加入 Trigger：On Form Submission

* 在畫布中央按加號新增節點，工作流程必須從 trigger 開始
* 選擇「On form submission」作為觸發方式並建立註冊表單
* 設定表單標題（例如 Register user for security response）
* 設定表單描述（註冊後可透過 WhatsApp 在緊急狀況發出求助）

## 表單欄位設定與驗證規則

* 依照 Google Sheets 欄位建立表單元素：First name、Last name、Email、Address 1、Address 2、WhatsApp number


* 所有欄位都設定為必填（required）
* Email 欄位使用 email 類型以自動驗證格式，格式錯誤會阻止送出

* WhatsApp number 以可實際測試的有效號碼填入，用於後續 WhatsApp 求助流程測試與識別

## 執行表單節點以產生測試資料

* 在 On form submission 節點中按 Execute step 生成可填寫的表單頁
* 填入測試資料並提交表單，確認表單送出成功
* 回到節點輸出查看提交結果，確認輸出欄位與內容正確

## Pin 資料用於後續節點測試

* 將表單提交的輸出資料 pin 起來
* 之後測試後續節點時，不必每次重新填表即可重用同一份輸入資料
* 方便逐步建構流程並單獨測試每個節點

## 串接 Google Sheets：Append Row

* 在畫布上將 On form submission 節點接到 Google Sheets 節點


* 選擇 Google Sheets 節點的操作為「Append row」把註冊資料新增成一列
* 提到已先設定好連線憑證，並準備示範如何建立這些憑證以連到指定試算表

---
## 目標與節點角色
* 在 n8n 的「Append row in sheet」節點建立新憑證，讓 workflow 有權限把資料新增到你的 Google 試算表
* 節點輸入端有 pinned data，可直接用來測試新增一列，不必重跑前面的表單輸入

## 建立 Google Sheets OAuth2 憑證的必要欄位

* n8n 會用 OAuth2，需要填入 Client ID 與 Client Secret
* 這兩個值需到 Google Cloud Console 建立後再貼回 n8n

## 在 Google Cloud Console 建立專案

* 進入 console.cloud.google.com 並登入
* 建立新 Project，並切換到該專案作為目前專案

## 啟用 Google Sheets API

* 進入「APIs & Services」→「Library」

* 搜尋並啟用「Google Sheets API」

## 建立 OAuth Client ID 與 Consent Screen

* 進入「APIs & Services」→「Credentials」→「Create Credentials」→ 選「OAuth client ID」
* 先建立/設定 OAuth consent screen，填入 App name、支援/聯絡信箱、選 External audience、同意政策並建立

* 建立 OAuth client 時選 Web application，並準備填入 redirect/callback URI

## 設定 Callback URI 並取得 Client ID/Secret

* 從 n8n 憑證畫面複製 Callback/Redirect URI
* 回到 Google Cloud 的 OAuth client 設定，把 URI 貼到 Authorized redirect URIs
* 建立後複製 Client ID 與 Client Secret，貼回 n8n 對應欄位並儲存

## 加入測試使用者並完成授權同意

* 在 OAuth consent screen 的 Audience/Users 新增 Test user（通常加自己登入用的 Google 帳號）
* 回到 n8n 憑證畫面點「Sign in with Google」
* 在同意畫面勾選/允許需要的權限後完成授權，n8n 顯示連線成功

## 選擇目標試算表與工作表

* 在 n8n 的 Document/Spreadsheet 欄位改用「By ID」

* 從 Google 試算表網址複製 Spreadsheet ID（只取 ID 本身，不要包含多餘 URL 片段）


* 貼回 n8n 後，Sheet 下拉選單應能讀到工作表（例如 Sheet1）

## 欄位對應與動態表達式

* n8n 會讀取試算表第一列欄位名稱並顯示成可對應的欄位
* 從 Input JSON 把各欄位拖拉到對應欄位（First name、Last name、Email、Address1、Address2、WhatsApp number 等）
* 對應值使用 Expression 形式，確保每次執行都能帶入不同資料

## 以 Pinned Data 測試新增列

* 欄位對應完成後，直接執行「Append row」節點
* 回到試算表確認新資料列已新增且落在正確欄位下

## 解除 Pin 並用正式 URL 跑整條流程

* 解除前一節點的 pinned data，改用實際表單提交來觸發


* 在 workflow 啟用 Active
* 使用 Production URL 開啟表單並送出資料
* 回到試算表確認正式提交的資料也能成功新增為新列

---
# 5. Workflow 範例三：WhatsApp Panic 通知系統
## 建立「Panic App Notification」工作流程的目的

* 新建工作流程命名為「panic app notification」
* 功能是處理使用者緊急求助：使用者透過 WhatsApp 傳訊息觸發流程
* 流程會用使用者的 WhatsApp 號碼到註冊用的試算表查找資料
* 若找到對應註冊資料，就把包含地址等資訊的通知寄給值班人員，由值班人員派遣支援

## 以 WhatsApp 訊息作為 Trigger 的設計

* 每個工作流程都從 trigger 節點開始
* 使用者在緊急狀況不需要打長訊息，只要傳單一字元（例如「1」）
* 流程會從 WhatsApp 訊息中取得發送者 WhatsApp 號碼，作為查表的唯一識別

## 在 n8n 加入 WhatsApp Business Cloud Trigger

* 新增節點並選擇 WhatsApp Business Cloud
* 選擇事件類型為「On messages」以接收訊息觸發

* 需要建立並設定 WhatsApp 的 OAuth 2 憑證，才能連接 Meta/WhatsApp

## 建立 WhatsApp 憑證的整體流程（Meta Business）

* 前往 Meta Business（Facebook Business）後用 Facebook 帳號登入
* 建立 Business Portfolio（商業組合/商業帳戶）

* 進入設定後在 Apps 區新增 App（Client app）
* 設定 use case 為「Connect with customers through WhatsApp」
* 建好 App 後回到 App Dashboard 取得 App ID 與 App Secret

## 在 n8n 建立 OAuth 憑證並綁定

* 在 n8n 的 WhatsApp 節點新增 credential
* 將 Meta App 的 App ID 填入 Client ID
* 將 Meta App 的 App Secret 填入 Client Secret
* 儲存後憑證建立成功，並套用到 WhatsApp trigger 節點

## 在 Meta 的 WhatsApp API Quick Start 取得測試資源

* 進入 Use cases → Quick start → Start using the API
* 系統會提供測試用 WhatsApp 號碼與 Phone Number ID
* 這個測試號碼用來接收你送出的訊息以觸發工作流程

## 產生 Access Token 並加入測試收訊者

* 在 Quick start 產生 access token 以便送測試訊息
* 管理 phone number list，新增要接收測試訊息的 WhatsApp 號碼
* Meta 會發送驗證碼到該 WhatsApp 號碼，完成驗證後才能用來測試

## 發送測試訊息確認 WhatsApp Cloud API 可用

* 透過 Quick start 介面直接送出測試訊息（範例為 Hello World）
* 成功收到訊息代表已具備從 Meta Cloud API 發送訊息的能力
* 也可用 cURL 或 Postman 執行同樣的測試請求

## 在 n8n 執行 Trigger 節點並進入監聽狀態

* 回到 n8n 畫布，確認 trigger 節點已綁定正確的 WhatsApp OAuth 憑證
* 執行 trigger 節點讓它開始「listen」等待訊息
* 從 WhatsApp 送出單一字元（例如「1」）到測試號碼以觸發流程

---
## 釘選測試資料以便後續節點測試

* 試算表輸出包含使用者唯一識別值與 WhatsApp 號碼（WA_ID）
* 將包含 WA_ID 的輸出資料 pin 起來，避免每次都要從 WhatsApp 再觸發一次流程

## 新增 Google Sheets 節點查找使用者資料

* 在畫布新增 Google Sheets 動作節點並選擇「Get row(s) in sheet」
* 使用既有的 Google Sheets 帳號憑證（例如 Google Sheets account 3）
* 到 Google Cloud Console 確認專案內已啟用 Google Sheets API

## 以 Spreadsheet ID 連接註冊名單試算表

* 在 Google Sheets 節點的 Document 欄位改選「By ID」
* 從註冊名單試算表網址複製 Spreadsheet ID（只保留 ID 本體）

* Sheet 欄位用下拉選單選到 Sheet1，表示已成功讀取文件結構

## 以 WhatsApp number 欄位過濾並取得該使用者整列資料
* Filter 的 Column 選「WhatsApp number」

* Value 改用 Expression，拖入前一節點的 WA_ID 作為比對值
* 執行節點後會輸出該使用者的姓名、地址、WhatsApp number 等欄位資料

## 第二次查表：依區塊找出值班人員 Email


* 準備另一份試算表：Block Name 對應 On-duty Email
* 再新增一個 Google Sheets「Get row(s)」節點，Document 改成另一份表的 Spreadsheet ID
* Filter 的 Column 選「Block Name」
* Value 用 Expression，拖入使用者資料列中的 address two（例如 Block B）做比對
* 執行後輸出該 Block 對應的值班 email

## 啟用 Gmail API 以便從工作流程寄信

* 在同一個 Google Cloud 專案的 API Library 啟用 Gmail API

* 到 Credentials 建立新的 OAuth Client（Web application）
* 從 n8n Gmail 憑證畫面複製 Redirect URL，貼回 Google Cloud 的 Authorized redirect URIs

* 複製 Client ID 與 Client Secret 回填 n8n，並進行 Sign in with Google 完成授權

## 新增 Gmail「Send message」節點並組裝通知內容

* 新增 Gmail 節點選「Send message」
* To 欄位用 Expression，拖入「值班人員查表」節點輸出的 email
* Subject 固定填「Panic」
* Message 改用 Expression，拖入「使用者查表」節點輸出的 first name、last name、address one、address two
* Email type 選 text

## 節點測試與驗證結果

* 先用 pinned data 執行 Gmail 節點，確認信件成功送出且內容包含姓名與地址
* 到收件匣確認主旨為 Panic，內文含使用者姓名與地址資訊

## 上線測試整條 WhatsApp → 查表 → 寄信流程

* 取消釘選測試資料，改用真實 WhatsApp 訊息觸發流程
* 將 workflow 切換為 Active
* 從 WhatsApp 傳送指定訊號（例如「1」）到測試號碼觸發
* 確認流程會用 WA_ID 找到使用者資料、用 address two 找到值班 email，並寄出 Panic 通知信

---
# 6. Workflow 範例四：履歷審核／面試排程（Human in the Loop）
## 工作流程目標：自動安排第一輪面試（Senior C Developer）

* 應徵者把履歷 PDF 放進指定 Google Drive 資料夾
* 工作流程逐一處理每份履歷，擷取重點摘要
* 摘要用 email 寄給面試流程負責人
* email 內提供「Approve / Decline」兩個按鈕讓負責人決策
* 若 Approve，AI agent 會在下週找最早可用時段，排一小時實體面試到主管 Google Calendar
* 若 Decline，略過排程並處理下一份履歷

## Human-in-the-loop 的核心設計

* 流程在關鍵節點暫停，等待人類做出批准或拒絕
* 人類負責判斷是否進入面試，AI 負責加速資訊整理與後續排程
* 透過摘要降低人工閱讀完整履歷的時間成本

## 準備資料：Google Drive 履歷資料夾與 PDF

* 使用 ChatGPT 生成多份履歷內容並匯出成 PDF（範例為 8 份）
* 建立/指定一個 Google Drive 資料夾作為履歷投遞位置
* 工作流程會以該資料夾為來源批次處理所有 PDF

## 建立工作流程與 Trigger

* 在 n8n 建立新 workflow，命名為「interview scheduler」
* 使用「Trigger manually」作為觸發節點，方便測試用按鈕手動啟動
* 也提到可改成監控 Google Drive 資料夾變動自動觸發，並在處理後移動檔案避免重複處理

## 加入 Google Drive 節點：搜尋檔案

* 新增 Google Drive 節點並選擇「Search files and folders」
* 目標是列出指定資料夾內所有履歷 PDF 的檔名與檔案 ID
* 節點輸出會包含每個檔案的 ID 與名稱，供後續迴圈逐份處理

## 建立 Google Drive OAuth 2 憑證（Google Cloud Console）

* 進入 Google Cloud Console 並選定專案（示範沿用既有專案）
* 在 API Library 啟用 Google Drive API
* 到 Credentials 建立 OAuth Client ID，應用類型選 Web application


* 設定 Authorized redirect URI（從 n8n 複製提供的 redirect URL）
* 取得 Client ID 與 Client Secret，回填到 n8n 建立 credential
* 使用 Google 帳號登入並授權存取後，連線成功即可在 workflow 中讀取 Drive

## 用資料夾 ID 與進階查詢只抓 PDF


* 從 Google Drive 資料夾 URL 取得 folder ID
* 在 n8n 的 Search Query 使用該 folder ID 作為 parents 條件


* 設定 search method 為 Advanced search


* 用 mimeType=application/pdf 過濾非 PDF 檔案
* 設定 return all 以取得資料夾內全部履歷 PDF

## 執行與 Pin 搜尋結果以便後續測試

* 執行 Google Drive 搜尋節點確認能回傳所有履歷檔案的 ID 與檔名
* 將輸出結果 pin 起來，避免每次測試都要重新跑搜尋步驟

---
## 目標與整體流程

* 逐份處理多個 PDF 履歷檔，每次只處理一份
* 每份履歷先下載、抽取文字、摘要，再送給人員審核
* 審核結果（同意/拒絕）決定該份履歷是否繼續往下走流程

## 為何需要 Loop 節點

* 需要「一份履歷一個迭代」的順序處理，避免同時並行導致人審節點混亂
* 使用 Loop 可確保每次只處理一個 PDF，完成後才進下一個
* 每次迭代代表一份 CV 的下載、抽取、摘要、送審

## 設定 Loop Over Items / Split In Batches

* 選用「Loop over items / Split in batches」類型節點
* Batch size 設為 1，確保一次只取一個 PDF
* 節點會產生預設的 Replace me 等節點，示範中先刪除以保持流程乾淨
* Done 連接點代表所有批次都跑完後的後續動作，Loop 連接點代表每個批次都會跑一次的分支

## 測試 Loop 的輸出行為

* 執行 Loop 節點後可看到它會先取清單中的第一個項目（例如 Janet Winslow CV PDF）
* 後續會依序輪到下一個項目，直到所有 PDF 都處理完

## 每次迭代下載 PDF

* 在 Loop 分支上新增 Google Drive「Download file」節點
* 下載方式用「By ID」


* File 欄位改成 Expression，拖入迭代項目的檔案 ID
* 執行後會取得該 PDF 的 binary 檔案內容供下一步使用

## 從 PDF 抽取文字

* 在 Download file 後串接「Extract from file」節點並選「Extract from PDF」
* 執行後會把 PDF 內容轉成文字輸出（通常在 text 欄位）
* 抽出的 text 將作為下一步 AI 摘要的輸入
* 為方便後續搭建與測試，可先把抽取結果 pin 起來

## 下一步準備建立 AI Agent

* 在抽取文字後新增 AI Agent 節點
* AI Agent 會以抽取到的 text 作為輸入進行摘要
* 摘要結果將用於後續的人工審核與通知流程

---
## 建立 AI Agent 節點與選擇模型

* 新增 AI Agent 節點


* 加入 Chat Model，選用 OpenAI Chat Models
* 指定使用 GPT-4.1 Mini
* 使用已設定好的 OpenAI 帳號與憑證連線模型

## 設定 User Prompt 並注入 PDF 解析文字

* 將 AI Agent 的 prompt 來源設為「Define below」
* 貼上用來分析履歷（CV）的使用者訊息提示詞
* 以拖拉方式把「從 PDF 抽出的文字內容」節點插入 prompt 指定位置
* 確認 prompt 欄位顯示為可用狀態（綠色）

## 設定 System Prompt 角色與規則

* 新增 System Message 並貼上系統提示詞（Markdown 結構）
* 指定角色為軟體公司 HR，目標職位為資深 C# 開發
* 要求擷取資訊：姓名、Email、C# 年資、資格亮點、工作經驗亮點、是否推薦
* 設定關鍵規則：C# 為最重要技能，若無 C# 經驗則不可推薦

## 要求結構化輸出與 Output Parser

* 開啟「Require specific output format」
* 新增 Structured Output Parser 節點


* 提供 JSON 範例格式作為 one-shot 範例


* 欄位包含：fullName、email、cSharpYearsExperience、notableQualifications、notableWorkExperience、recommended

## 執行測試並驗證 AI 輸出

* 執行 AI Agent 節點確認可輸出符合 JSON 結構
* 例子輸出包含姓名、Email、C# 年資、資格與經驗摘要
* 依內容判斷 recommended 為 true 並建議進入第一輪面試

## 加入 Human-in-the-loop 以 Gmail 寄信審核

* 新增 Human in the loop 節點並選 Gmail


* Resource 選 Message，Operation 選「Send and wait for response」
* 設定收件者為面試負責人信箱
* 設定 Email 主旨為「Approval required」

## 組合 Email 內容與動態欄位

* Message 欄位切換為 Expression 以支援動態插值
* 內容包含：Applicant details、Notable qualifications、Notable work experience
* 使用條件判斷字串輸出推薦語
* recommended 為 true 時顯示推薦
* recommended 為 false 時顯示不推薦

## 設定審核按鈕並等待回覆

* 在 Approval options 選「Approve and Disapprove」
* 執行節點後工作流進入等待狀態（waiting for input）


* 收件者在 Email 中看到 Approve 與 Decline 按鈕

* 點擊後回傳結果至流程，輸出含 approved 布林值

## 使用 If 節點依審核結果分流
* 新增 If 節點判斷 JSON.data.approved
* approved 為 true 走 True 分支
* approved 為 false 走 False 分支

## True 分支新增 AI Agent 以排程面試

* 在 True 連線新增 AI Agent 節點
* 目標是自動安排 1 小時面試
* 後續規劃使用 Google Calendar API 作為工具由 AI Agent 建立行程
* 新 AI Agent 需要替換預設 user prompt 為排程用提示詞

----
## Prompt 來源與使用方式

* 面試排程用的 prompt 已先寫好並放在 GitHub（interview scheduler AI agent prompt）
* 為了省時未另外做 system prompt，而是把所有規則寫成一段 user prompt
* 因為流程不是從 chat trigger 開始，所以在 AI agent 節點用「define + expression」把 prompt 貼到 user message 欄位
* prompt 內大量使用雙大括號動態欄位，會帶入應徵者姓名、email 等資料

## Prompt 的任務角色設定

* 指定 AI 的角色是「協助在 Google Calendar 排面試」的助理
* 面試雙方包含面試官與應徵者，兩者 email 都會被用在事件建立中

## Prompt 指令：抓取下週行事曆事件（Fetch events）

* 要求呼叫「Get Calendar events」工具
* 抓取範圍限定為「下一個日曆週的週一 00:00 到週五 23:59」
* 若今天仍在本週，必須跳過本週，只看下週
* 以「當前日期」作為計算下一週區間的基準

## Prompt 指令：找空檔（Find availability）

* 解析抓回的事件，找出最早可用的 1 小時空檔
* 只在工作時段 08:00–18:00（當地時間）內選擇
* 不得與既有事件重疊
* 日期只允許下週週一到週五

## Prompt 指令：建立面試事件（Schedule event）

* 找到空檔後，呼叫「Create calendar event」工具建立行事曆事件
* 工具名稱必須和 prompt 內引用的名稱一致，否則模型無法正確呼叫

## 在 AI agent 加入 Google Calendar 工具：Create event

* 在 AI agent 的 tools 區按加號新增 Google Calendar tool
* 操作選擇建立事件（create）


* 需要建立 OAuth 2 憑證以授權存取 Google Calendar API
* 在 Google Cloud Console 啟用 Google Calendar API 後建立 OAuth Client（Web application）
* 設定 redirect URI，取得 client ID 與 client secret 回填到 n8n 憑證並完成授權同意

## 工具命名對齊 Prompt：create calendar event

* 建立事件的工具需手動命名為「create calendar event」
* 目的是讓工具名稱與 prompt 指定的呼叫名稱一致

## 再新增 Google Calendar 工具：Get events

* 另外新增第二個 Google Calendar tool 用來抓取既有事件
* 操作選擇取得多筆事件（get many）
* 工具命名為「get calendar events」以對齊 prompt 中的工具名稱
* 兩個工具可共用同一組 Google Calendar OAuth 憑證（同一帳號授權）

---
## Create Calendar Event 節點的 AI 參數化設定

* Start 與 End 原本是 now 與 now+1h，改成由 AI 依提示自動決定
* 在 Start 欄位點星星按鈕，讓 AI 產生值
* 在 End 欄位點星星按鈕，讓 AI 產生值
* Calendar 欄位選擇對應的 Gmail 帳號，指定要寫入哪一個 Google Calendar

## 在日曆事件中加入需要顯示的欄位

* 新增 Attendees 欄位並加兩筆，分別代表面試官與面試者
* 每個 Attendee 欄位都點星星按鈕，讓 AI 從提示中抽出 email
* 新增 Description 欄位並點星星按鈕，讓 AI 生成事件描述
* 新增 Summary 欄位並點星星按鈕，讓 AI 生成事件標題/摘要

## Get Calendar Events 節點的 AI 參數化設定

* Calendar 欄位同樣選擇對應 Gmail 帳號，確保查同一個行事曆
* 設定 Return All 取得完整事件結果
* After 與 Before 欄位點星星按鈕，讓 AI 決定查詢的時間範圍
* 目的為讓 AI 先讀取既有行程，避免排到衝突時間並用於決定下週面試時段

## 執行時遇到的錯誤與修正

* 執行 workflow 出現「chat model sub node must be connected and enabled」
* 代表 AI agent 尚未掛上 Chat Model，無法運作


* 在 AI agent 加入 OpenAI Chat Model 並選擇 GPT-4.1 mini 後即可正常執行

## 測試結果驗證

* workflow 執行成功後會為該 CV 自動排定下週的面試事件
* 在 Google Calendar 可看到已建立的事件，例如「Interview with Janet…」並帶有 8–9 a.m. 時段
* Attendees 會帶入提示中提供的 email（示範用假 email）
* 因測試時 pin 了資料，Human-in-the-loop 未被迫等待審核而直接通過

## 取消釘選資料以回到真實流程

* 為正式跑完整批 CV，需要把先前 pin 的資料全部 unpin
* 包含 Human-in-the-loop 的 Send a message 節點等任何被釘選的節點輸出
* 取消釘選後，流程會在每份 CV 進入人工審核時真正停下等待回覆

## 依核准/拒絕結果接回 Loop 的流程調整

* Human-in-the-loop 的 True 分支接到 AI agent，完成排程後再接回 Loop 節點以處理下一份 CV
* Human-in-the-loop 的 False 分支直接接回 Loop 節點，略過 AI agent，不建立面試事件
* 兩條分支都回到 Loop，確保不論核准或拒絕都會繼續處理下一份履歷

## 完整批次執行的預期行為

* Loop 以 batch size=1 逐份取出 CV
* 每份 CV 先經人工審核
* 核准才會排面試並寫入日曆
* 拒絕則跳過排程直接進下一份
* 全部 CV 跑完後才會走到 Loop 的 Done 分支（若有接後續通知節點）

---
## 整體執行方式：8 份履歷逐一處理並卡在人類決策

* 工作流程會把資料夾內 8 份履歷依序處理
* 每份履歷都會寄出一封「需要決策」的 email
* 流程每次都會暫停，直到人類按下 Approve 或 Decline 才會繼續下一份

## 先修正 Prompt 內的 email 避免退信

* prompt 裡 attendees 的 email 若是假的會造成 mail delivery error
* 示範改成兩個有效 email，避免流程因退信干擾測試
* 實務上 email 應該由前面節點輸出欄位動態帶入，不會硬寫死

## 執行工作流程後的停點：Send email／Send a message

* 啟動「Execute workflow」後流程開始跑
* 流程會停在寄信相關節點，這就是 human-in-the-loop 的等待點
* 每次暫停代表當前履歷的審核信已寄出，等待人類回覆決策

## Email 審核內容：摘要＋推薦＋按鈕

* 每封信包含 AI 摘要的履歷重點（姓名、email、C# 年資、經驗、資格等）
* 信中提供 Approve 與 Decline 按鈕作為唯一操作介面
* 信內也包含 AI 的推薦結論（例如推薦／不推薦）

## Approve 的結果：AI agent 排入下週最早 1 小時面試

* 人類按 Approve 後流程繼續
* AI agent 會依 prompt 規則在面試官 Google Calendar 下週週一到週五、08:00–18:00 找最早可用 1 小時空檔
* 找到空檔後建立行事曆事件並排入面試

## Decline 的結果：跳過排程直接處理下一份

* 人類按 Decline 後不會建立行事曆事件
* 流程直接進入下一份履歷的迴圈處理
* 示例中拒絕原因包含：不符合 C# 年資、技能不匹配、缺乏工作經驗等

## 逐次審核的示範決策走向

* 前幾位候選人因年資與經驗較符合而多數被 Approve
* 遇到不符合需求者（例如沒有 C# 經驗、轉向 Python、零工作經驗）則 Decline
* 每次按下按鈕後流程立即從暫停處恢復並進入下一輪

## 最終結果驗證：Google Calendar 生成面試行程

* 流程結束後到行事曆確認排程結果
* 例子中總共排了 6 場面試，每場 1 小時，集中在週一連續時段
* 行事曆事件標題與描述會包含「Interview with {候選人姓名}」等欄位，顯示 AI 已正確帶入與組裝資訊

---

# 7. 架構優化與進階應用
## 目的：把 AI 排面試相關節點抽成子工作流程

* 主流程節點越來越多，畫布像蜘蛛網一樣難維護
* 將「AI agent + 工具節點 + 模型子節點」抽出成 subworkflow 讓主流程更乾淨
* 子流程可重複被不同主流程呼叫，降低耦合並方便平行修改

## 建立新的子工作流程並搬移節點

* 開新分頁建立新 workflow 作為子工作流程
* 在主流程中先移除/斷開原本 AI 排程區塊的連線
* 選取 AI 排程相關節點群組並複製
* 在新 workflow 中貼上這些節點
* 將子工作流程命名為可描述用途的名稱，例如 AI agent interview scheduler

## 在子工作流程加入 Execute Subworkflow Trigger 與輸入參數


* 在子工作流程新增 Trigger：「When executed by another workflow」
* 在 Trigger 節點新增要由主流程傳入的欄位
* 範例新增 full name（string）
* 範例新增 email（string）
* 將 Trigger 節點接到子流程內的 AI agent 起點，讓子流程接到參數後開始排程

## 在主工作流程改用 Execute Subworkflow 呼叫子流程

* 在主流程新增「Execute Subworkflow」節點
* 在節點內選擇剛建立的子工作流程


* 主流程會看到子流程要求的參數欄位（full name、email）
* full name 改用 Expression，從主流程的資料來源拖入申請者姓名
* email 可先用固定值測試，實務上應從資料來源動態帶入

## 常見錯誤：子流程內引用了已不存在的欄位

* 改成子流程後，原本 prompt 中引用的欄位路徑會失效
* 典型現象是 prompt 或欄位表達式顯示紅色，執行錯誤提示 reference node 不存在
* 修正方式是把子流程內所有需要用到的姓名/Email 都改成引用 Trigger 參數
* 將 prompt 中「Interview with …」等片段改拖入 full name 參數，確保表達式變綠

## 驗證子流程呼叫成功

* 重新執行主流程，流程會到 human-in-the-loop 節點等待審核
* 審核通過後會呼叫 Execute Subworkflow 節點
* 子流程執行成功代表 AI 排程邏輯已被成功抽離並可被主流程正常使用

## 清理主流程並接回 Loop

* 子流程可用後，主流程中原本被抽走的 AI agent 與其工具/模型節點可以刪除
* 將「Execute Subworkflow」節點後的輸出接回 Loop，讓每個申請者排程完成就處理下一份
* 讓主流程保留：人審判斷與迴圈控制，排程細節交由子流程負責

## 觀察結果與提示

* 跑完整批後，日曆會出現多個面試事件，表示子流程在迴圈中被多次呼叫成功
* 排程是否完全避免衝突取決於提示詞與限制條件是否夠明確
* 這段示範重點是工作流程拆分與可重用性，不是保證排程策略永遠正確

---

# 8. 其他實用整合技巧
## 額外示範的目的與範圍

* 這段不再逐步帶做工作流程，只展示一些延伸用法
* 目標是說明 n8n 能用不同介面與不同資料來源來驅動同一類型的流程

## 範例：把排行聊天機器人改用 WhatsApp 當介面

* 原本用 n8n 內建的 chat message received 觸發器與機器人對話
* 改成接上 WhatsApp trigger 後，可直接用 WhatsApp 對機器人提問
* 示範在桌面版 WhatsApp 發問並收到排行回覆（例如最快的車、電影明星）
* 因為有加 memory，所以追問「下一個五個」仍能延續前一題脈絡

## 介面不侷限於 WhatsApp

* 同樣的聊天機器人也能換成 Discord、Telegram 等不同平台作為輸入介面
* 核心流程不變，只是替換觸發器與訊息通道

## 範例：註冊流程不一定要用 n8n 內建表單

* 原本的 panic app registration 用 n8n 產生的表單節點收集資料
* 若想把註冊表單放在自家網站或第三方網站，可改用 Webhook 接收 HTTP POST 資料
* Webhook 節點會提供專屬 URL，外部表單可把資料送到該 URL 觸發流程


* 示範用 Postman 對 Webhook 發送資料後，註冊資訊成功寫入 Google Sheets

## 範例：用 HTTP Request 節點呼叫自訂 API 取得資料

* 透過 HTTP Request node 對指定 API endpoint 發出 GET 請求
* 範例 endpoint 回傳電影清單、類型、評分與影評情緒等資料
* 回傳資料可作為聊天機器人或 AI agent 的資料來源

## 在流程中加入程式碼節點做資料整理

* 由於 API 回傳資料層級較深，直接給 AI agent 不易有效提示
* 使用 Code node（JavaScript）把巢狀結構攤平成較可讀的格式
* 程式碼用途是「格式轉換」，讓後續 AI agent 更容易消化資料並產生回覆

## 另一種作法：把 HTTP Request 當成 AI agent 的工具

* 除了用 HTTP Request node，也可把 HTTP request tool 加到 AI agent 的 tools
* 實測用 tool 取得資料時，AI agent 能直接理解回傳內容，較不需要額外寫 JavaScript 攤平


* prompt 指示 AI 用 HTTP request tool 取回電影資料，再用資料回答使用者問題
* 示範詢問驚悚類電影推薦，AI 先取資料再根據資料給出推薦清單與理由

# 9. 結尾
---
# Terminology
* 工作流程自動化（Workflow Automation）：以流程方式自動執行跨系統任務
* 開源平台（Open-source Platform）：原始碼公開、可自由修改與部署的軟體
* n8n：一種以節點為核心的開源工作流程自動化工具
* 無程式碼（No-code）：不需撰寫程式即可建立系統或流程的方法
* 低程式碼（Low-code）：僅需少量程式即可完成複雜功能的開發模式
* 節點（Node）：工作流程中的單一功能單位
* 工作流程（Workflow）：由多個節點依序組成的自動化任務
* 流程設計（Flow Design）：規劃節點連接順序與邏輯的過程
* 流程圖式開發（Visual Workflow）：以圖形化介面建構流程的方式
* 條件判斷（Conditional Logic）：根據條件決定流程分支的機制
* 迴圈（Loop）：重複執行某段流程的控制結構
* 關注點分離（Separation of Concerns）：將不同功能責任拆分的設計原則
* 抽象化（Abstraction）：隱藏底層細節、只暴露必要介面的設計方式
* API（Application Programming Interface）：系統之間溝通的標準介面
* REST（Representational State Transfer）：以 HTTP 為基礎的網路服務架構風格
* RESTful API：遵循 REST 原則設計的 API
* OAuth 2.0：用於授權第三方安全存取資源的標準協定
* Client ID：OAuth 2.0 中用來識別應用程式的識別碼
* Client Secret：OAuth 2.0 中用來驗證應用程式身分的密鑰
* 存取權杖（Access Token）：授權後用於存取資源的憑證
* JSON（JavaScript Object Notation）：常見的資料交換格式
* XML（eXtensible Markup Language）：另一種結構化資料交換格式
* 互通性（Interoperability）：不同系統能彼此協作的能力
* 節點畫布（Canvas）：以視覺方式排列與連接節點的操作介面
* 觸發器（Trigger）：啟動工作流程的事件或條件
* WhatsApp Trigger：由 WhatsApp 訊息觸發流程的節點
* Google Sheets 節點：與 Google 試算表互動的流程元件
* Gmail 節點：用於寄送電子郵件的流程元件
* 即時通知（Real-time Notification）：事件發生後立即發送的訊息
* 緊急通報系統（Emergency Notification System）：用於緊急狀況的即時求助機制
* 人在迴圈中（Human-in-the-loop）：流程中需要人類決策或確認的設計
* 審核節點（Approval Step）：等待人工核准後才繼續執行的流程步驟
* 檔案觸發（File Trigger）：因檔案新增或變更而啟動的流程
* Google Drive 整合（Google Drive Integration）：與雲端檔案系統互動的能力
* 二進位轉文字（Binary-to-Text Conversion）：將檔案內容轉為可讀文字
* AI 代理（AI Agent）：能在流程中執行推理與任務的智慧元件
* 履歷自動處理（Automated CV Processing）：自動分析與篩選履歷的流程
* 任務暫停（Workflow Pause）：流程等待外部事件再繼續的機制
* 行事曆排程（Calendar Scheduling）：自動在行事曆中建立事件
* 系統整合（System Integration）：將多個獨立系統組合運作
* 商業規則（Business Rules）：流程中反映實際需求的決策邏輯
* 標準化通訊（Standardized Communication）：依共同標準進行跨系統資料交換
* NAT（n8n Automation Tool）：用於建立自動化工作流程的開源工作流引擎
* n8n 自架模型（Self-Hosting Model）：使用者自行在伺服器上部署與管理 n8n 的方式
* VPS（Virtual Private Server）：提供獨立資源與系統權限的虛擬化伺服器
* Hostinger：提供 VPS 與應用模板的一站式雲端主機服務商
* 預設模板（Preconfigured Template）：已完成基本安裝與設定的系統映像
* 工作流程（Workflow）：由多個節點組成、描述自動化邏輯的執行流程
* 節點（Node）：工作流程中的基本單位，負責特定功能
* 觸發器（Trigger）：啟動工作流程的起始節點
* Chat Trigger（On Chat Message）：以聊天訊息作為輸入來源的觸發器
* AI Agent Node：n8n 中用來建立 AI 代理與聊天行為的核心節點
* Canvas（畫布）：用來視覺化編排工作流程的操作介面
* 子節點（Sub-node）：附加在主要節點下、提供額外功能的節點
* Chat Model Sub-node：為 AI Agent 提供語言模型能力的子節點
* LLM（Large Language Model）：可進行自然語言理解與生成的大型模型
* OpenAI Chat Model：n8n 中用於連接 OpenAI 語言模型的節點
* GPT-4.1 mini：OpenAI 提供的輕量化高效語言模型
* 憑證（Credentials）：用來驗證第三方服務存取權限的設定
* API Key：存取 OpenAI API 所需的密鑰
* OpenAI Platform：管理模型、API 與金鑰的官方平台
* Token（權杖）：語言模型計費與生成的基本單位
* 成本控制（Cost Control）：透過限制輸出與提示降低 API 使用費用
* Execute Step：在 n8n 中即時測試單一節點的功能
* JSON Expression：以 JavaScript 表達式方式存取資料的語法
* {{$json.input}}：n8n 中用來引用輸入資料的常見 JSON 表達式
* 資料流（Data Flow）：資料在節點之間傳遞的方向與過程
* UX（User Experience）：使用者在操作系統時的整體體驗
* 預設輸出（Default Output）：模型未經限制時產生的原始回應
* 冗詞輸出（Verbose Output）：包含多餘解釋文字的模型回應
* System Prompt（系統提示）：用來控制模型行為與輸出格式的高優先級指令
* User Prompt（使用者提示）：由使用者提供的實際問題或請求
* Prompt Engineering（提示工程）：設計提示以引導模型產生期望輸出的技術
* 輸出格式控制（Output Formatting）：限制模型回傳內容結構的技巧
* Required Output Format：n8n 中強制指定輸出格式的設定
* 精簡輸出（Concise Output）：只保留必要資訊的回應形式
* 清單式輸出（List Output）：以條列方式呈現結果的輸出格式
* Token Efficiency：以最少 token 完成任務的設計原則
* 開發者控制（Developer Control）：由系統或開發者主導模型行為的能力
* 模型行為設定（Model Behavior Configuration）：透過 system prompt 定義模型角色
* 文字雜訊（Text Noise）：對任務無實質幫助的多餘文字
* 回應裁剪（Response Trimming）：去除不必要內容以優化輸出
* 聊天機器人（Chatbot）：以對話形式與使用者互動的 AI 系統
* 工作流程測試（Workflow Testing）：在部署前驗證流程是否正確運作
* 模組化設計（Modular Design）：以可組合節點建構系統的架構方式
* 系統提示（System Prompt）：用來定義模型整體行為與角色的最高優先指令
* 系統訊息（System Message）：在對話層級中設定模型規則與背景的訊息
* 角色定義（Role Definition）：明確指定 AI 在任務中扮演的身份與職責
* 提示工程（Prompt Engineering）：設計輸入以引導模型產生理想輸出的技術
* Markdown 格式（Markdown）：用於結構化與提升可讀性的輕量標記語言
* 標題標記（Header）：使用 Markdown 定義區塊結構的語法
* 指令區塊（Instruction Section）：明確告知模型輸出規則的提示部分
* 輸出格式約束（Output Formatting Constraint）：限制模型回應格式的規則
* 範例引導（Example-based Guidance）：透過範例示範期望行為的方式
* 單次示例提示（One-shot Prompting）：在提示中提供一個示例來引導模型
* 零樣本提示（Zero-shot Prompting）：不提供範例、直接要求模型完成任務
* 少樣本提示（Few-shot Prompting）：提供多個示例以幫助模型歸納模式
* 排名列表生成（Ranked List Generation）：產生有順序項目清單的任務類型
* 子節點（Subnode）：工作流程中附屬於主要節點的功能模組
* 聊天觸發器（Chat Trigger）：由使用者對話啟動流程的機制
* 聊天模型（Chat Model）：專門處理多輪對話的語言模型
* 憑證設定（Credentials Configuration）：設定 API 存取權限的步驟
* OpenAI 整合（OpenAI Integration）：透過 API 與 OpenAI 模型互動
* JSON 輸出（JSON Output）：以結構化格式呈現模型回應的方式
* 畫布（Canvas）：視覺化配置工作流程節點的介面
* 上下文（Context）：模型用來理解當前輸入的歷史對話資訊
* 對話狀態（Conversation State）：多輪互動中累積的語境資訊
* 記憶模組（Memory Module）：用來保存與讀取過去對話的元件
* 簡易記憶（Simple Memory）：僅保留最近對話的基礎記憶機制
* 上下文視窗長度（Context Window Length）：模型可回顧的對話數量上限
* 會話識別碼（Session ID）：用來區分不同對話線程的唯一識別
* 對話線程（Conversation Thread）：同一 Session 下的連續互動
* 多輪對話（Multi-turn Conversation）：包含多次來回問答的互動形式
* 語境遺失（Context Loss）：缺乏歷史資訊導致模型無法理解指代
* 狀態保持（State Preservation）：在互動中維持對話一致性的能力
* 記憶注入（Memory Injection）：將歷史對話加入模型輸入的過程
* 聊天機器人（Chatbot）：以對話形式回應使用者的系統
* 代理區別（Agent vs Chatbot）：代理能執行行動，聊天機器人僅回應
* 行動能力（Action Capability）：是否能影響外部系統的能力
* 工具連接器（Tool Connector）：讓模型可呼叫外部功能的介面
* 記憶持久化（Memory Persistence）：跨請求保存對話資訊的能力
* 互動回合（Interaction Turn）：使用者與模型的一次問答循環
* 語意延續（Semantic Continuity）：模型在對話中保持主題一致的能力
* 上下文解析（Context Resolution）：理解省略或指代內容的能力
* 會話管理（Session Management）：控制與維護對話流程的機制
* 輸出一致性（Output Consistency）：模型回應符合既定規則的程度
* 專案管理（Project Management）：在平台中組織與命名不同工作流程的結構
* 工作區（Workspace）：用來集中管理多個流程與專案的環境
* 雲端主機平台（Hosting Platform）：提供應用程式部署與存取的服務
* 使用者驗證（User Authentication）：透過帳號憑證確認使用者身分的機制
* 第三方登入（Third-party Login）：使用 Google 等外部帳號進行登入
* 應用程式管理（Application Management）：管理已部署應用的設定與存取
* 表單觸發器（Form Submission Trigger）：由表單提交事件啟動流程的節點
* 線上表單（Web Form）：讓使用者透過瀏覽器輸入資料的介面
* 表單元素（Form Element）：表單中的單一輸入欄位
* 必填欄位（Required Field）：使用者必須填寫才能提交的表單欄位
* 欄位驗證（Field Validation）：檢查輸入資料是否符合格式規則
* 電子郵件驗證（Email Validation）：確保電子郵件格式正確的驗證機制
* 預設提示文字（Placeholder Text）：顯示在輸入框中的引導文字
* 試算表（Spreadsheet）：以列與欄儲存結構化資料的文件
* Google Sheets：Google 提供的雲端試算表服務
* 欄位標題（Column Header）：試算表中每一欄的名稱
* 資料列（Row）：試算表中一筆完整資料紀錄
* 唯一識別碼（Unique Identifier）：用來唯一識別使用者或資料的欄位
* WhatsApp 號碼（WhatsApp Number）：用作使用者識別的通訊帳號
* 表單資料擷取（Form Data Capture）：收集使用者提交資訊的過程
* 節點執行（Node Execution）：單一流程節點的實際運行
* 測試執行（Test Execution）：在設計階段驗證節點輸出的操作
* 節點輸出（Node Output）：節點執行後產生的資料結果
* 資料釘選（Data Pinning）：固定測試資料以供後續節點重複使用
* 釘選資料（Pinned Data）：被鎖定、不隨重新執行而改變的資料
* 隔離測試（Isolated Testing）：單獨測試流程某一段的方式
* 節點串接（Node Connection）：將多個節點依序連結成流程
* Google Sheets 節點：與 Google 試算表互動的流程元件
* 新增資料列（Append Row）：在試算表底部加入新資料的操作
* 憑證（Credentials）：用來驗證系統存取權限的設定
* API 授權（API Authorization）：允許流程存取外部服務的安全機制
* OAuth 2.0 授權流程（OAuth 2.0 Authorization Flow）：取得存取權杖的標準流程
* 權限範圍（Scope）：定義應用可存取資源範圍的設定
* 表單提交回饋（Submission Feedback）：提交後顯示給使用者的訊息
* 使用者註冊（User Registration）：將使用者資料加入系統的流程
* 緊急應用註冊（Emergency App Registration）：為緊急服務建立使用者名單
* 非正式住址（Informal Address）：不含郵遞區號的簡化地址格式
* 社群安全應用（Community Safety Application）：用於社區安全的系統設計
* 測試帳號（Test Account）：用於驗證流程功能的實際帳號
* 表單預覽（Form Preview）：在正式使用前查看表單外觀
* 流程初始化（Workflow Initialization）：流程建立後的第一個啟動階段
* 畫布操作（Canvas Interaction）：在視覺介面中編輯流程的行為
* 流程持續建構（Incremental Workflow Building）：逐步擴充流程功能的方法
* OAuth 2.0：一種標準授權協定，用於讓第三方應用在不暴露密碼的情況下存取使用者資源
* Google Sheets API：Google 提供的介面，用於以程式方式讀寫試算表
* 憑證建立（Credential Creation）：在第三方平台建立存取權限所需識別資訊的流程
* Client ID：OAuth 中用來識別應用程式身分的公開識別碼
* Client Secret：OAuth 中用來驗證應用程式身分的私密金鑰
* Google Cloud Console：用於管理 Google 雲端專案與 API 的控制台
* 雲端專案（Cloud Project）：Google Cloud 中用來集中管理資源與權限的單位
* API 啟用（API Enablement）：在雲端專案中允許特定 API 被使用的設定
* API Library：Google Cloud 中列出所有可用 API 的服務庫
* OAuth 同意畫面（Consent Screen）：使用者授權第三方應用存取資料時顯示的畫面
* External Audience：允許非組織內部使用者進行 OAuth 授權的設定
* Test User：在 OAuth 尚未正式發布前，用來測試授權流程的帳號
* 授權範圍（Scope）：OAuth 中定義應用程式可存取資料範圍的設定
* Callback URI：OAuth 授權完成後回傳結果的指定網址
* Redirect URI：OAuth 流程中將使用者導回應用程式的路徑
* 應用程式類型（Application Type）：OAuth 憑證中定義應用運作形式的設定
* Web Application：以瀏覽器與 HTTP 為主要互動方式的應用類型
* Google 帳戶驗證（Google Authentication）：透過 Google 登入進行身分確認的流程
* 授權成功（Authorization Success）：OAuth 流程完成並取得存取權限的狀態
* 存取權杖（Access Token）：OAuth 流程中用來實際呼叫 API 的臨時憑證
* n8n 憑證管理（Credential Management）：在 n8n 中集中管理第三方連線資訊的機制
* Append Row：在試算表中新增一列資料的操作
* Google Sheets 節點：n8n 中用於操作 Google 試算表的功能節點
* 表單提交觸發器（Form Submission Trigger）：在表單送出時啟動流程的觸發節點
* Pinned Data：在測試流程時固定輸入資料以便重複執行的功能
* Execute Node：在 n8n 中單獨執行某一節點以進行測試的操作
* 文件 ID（Document ID）：Google 試算表在 URL 中的唯一識別碼
* Sheet ID：試算表中單一工作表的識別資訊
* From List：以動態列表方式選擇資源的設定選項
* JavaScript Expression：n8n 中用來動態取得資料的表達式語法
* {{$json}}：n8n 中存取輸入 JSON 資料的預設物件
* 動態欄位對應（Dynamic Field Mapping）：將輸入資料對應到目標欄位的機制
* 拖拉綁定（Drag-and-Drop Binding）：以拖曳方式建立資料對應關係的操作
* 欄位標頭（Column Header）：試算表中用來定義資料意義的第一列欄位名稱
* 表單資料收集（Form Data Collection）：透過表單取得使用者輸入資訊的流程
* 生產環境（Production Environment）：正式對外提供服務的執行環境
* 測試環境（Test Environment）：用於驗證流程正確性的非正式環境
* Production URL：正式環境中觸發工作流程的網址
* Workflow 啟用（Workflow Activation）：將流程切換為可實際執行狀態的操作
* 狀態切換（Active Toggle）：控制流程是否啟用的開關設定
* 資料寫入（Data Ingestion）：將外部資料存入系統或資料庫的過程
* 表單驗證（Form Validation）：檢查使用者輸入是否符合格式規範的機制
* 自動化資料同步（Automated Data Sync）：透過流程自動將資料寫入外部服務的技術
* 事件觸發式流程（Event-driven Workflow）：由外部事件即時啟動的自動化流程
* WhatsApp 通知系統（WhatsApp Notification System）：以 WhatsApp 作為訊息入口的通報機制
* WhatsApp Business Cloud API：由 Meta 提供的官方 WhatsApp 雲端通訊介面
* 訊息觸發器（Message Trigger）：因收到訊息而啟動流程的節點
* 緊急通報流程（Panic Notification Workflow）：處理緊急求助事件的自動化流程
* 使用者識別（User Identification）：根據唯一資訊辨識使用者的機制
* 唯一鍵查詢（Unique Key Lookup）：使用唯一欄位查找資料列的操作
* 試算表查詢（Spreadsheet Lookup）：從試算表中搜尋符合條件資料的動作
* 條件比對（Conditional Matching）：比對輸入資料與既有資料是否一致
* 註冊驗證（Registration Validation）：確認使用者是否已完成註冊的檢查流程
* 即時回應系統（Real-time Response System）：在事件發生後立即反應的系統
* 值班人員（On-duty Operator）：負責接收與處理通知的人員角色
* 郵件通知（Email Notification）：透過電子郵件傳送事件資訊的機制
* 事件派遣（Incident Dispatch）：根據通報資訊派遣應對資源的流程
* 私人保全系統（Private Security System）：非政府的安全應變服務
* 社群安全通報（Community Safety Alert）：社區層級的緊急求助機制
* 最小輸入設計（Minimal Input Design）：在緊急情境下減少使用者操作的設計原則
* 單字元指令（Single-character Command）：以極簡訊息代表明確行為的指令設計
* 高壓情境設計（High-stress UX Design）：針對使用者慌亂狀態設計的介面思維
* 第三方平台整合（Third-party Platform Integration）：與外部服務系統進行串接
* Meta 商業管理平台（Meta Business Manager）：管理 Facebook 與 WhatsApp 商業應用的後台
* 商業資產（Business Asset）：隸屬於商業帳戶的應用與資源
* 商業組合（Business Portfolio）：集中管理多個應用與資產的結構
* 應用程式建立（App Creation）：在平台上註冊新應用的流程
* 用例選擇（Use Case Selection）：指定應用目的以啟用對應功能
* 用戶端應用（Client App）：代表第三方系統與 API 互動的應用
* OAuth 2.0 授權（OAuth 2.0 Authorization）：安全授權第三方存取資源的標準
* 用戶端識別碼（Client ID）：OAuth 中識別應用身分的公開參數
* 用戶端密鑰（Client Secret）：OAuth 中驗證應用身分的私密金鑰
* 存取權杖（Access Token）：授權後用來呼叫 API 的憑證
* 權杖生成（Token Generation）：取得 API 存取憑證的過程
* API 快速入門（API Quick Start）：協助初次使用者設定 API 的流程
* 測試號碼（Test Phone Number）：供開發與測試使用的臨時 WhatsApp 號碼
* 電話號碼 ID（Phone Number ID）：WhatsApp Cloud API 用來識別號碼的識別碼
* 訊息接收端（Message Receiver）：負責接收訊息的 WhatsApp 號碼
* 驗證流程（Verification Flow）：確認號碼或帳戶所有權的安全步驟
* 驗證碼（Verification Code）：用於身分驗證的一次性代碼
* 桌面版 WhatsApp（WhatsApp Desktop）：在電腦上使用的 WhatsApp 應用
* 即時監聽（Listening Mode）：流程節點等待事件發生的狀態
* 模擬測試（Simulation Testing）：以測試資料驗證流程行為的方法
* Curl 指令（cURL Command）：以命令列方式呼叫 API 的工具
* API 測試工具（API Testing Tool）：用於測試 API 請求與回應的軟體
* 端對端流程測試（End-to-end Testing）：驗證整個流程是否正確運作的測試方式
* 使用者識別（User Identification）：透過唯一欄位（如 WhatsApp 號碼）確認使用者身分
* WA_ID（WhatsApp ID）：WhatsApp 平台中用來唯一識別使用者的號碼
* 資料釘選（Pinned Data）：在測試流程中固定節點輸入資料以便後續重複使用
* 節點測試（Node Testing）：單獨執行某一節點以驗證其功能是否正確
* Google Sheets 查詢（Google Sheets Lookup）：從試算表中依條件查找資料的操作
* Get Row Operation：從 Google Sheet 中讀取符合條件的單一資料列
* 條件過濾（Conditional Filtering）：依指定欄位值篩選符合條件的資料
* 欄位比對（Column Matching）：將輸入值與試算表中特定欄位進行比對
* 動態條件（Dynamic Condition）：由流程中即時產生的值作為查詢條件
* WhatsApp Trigger：以 WhatsApp 訊息作為流程啟動來源的觸發機制
* 事件驅動流程（Event-Driven Workflow）：由外部事件觸發執行的自動化流程
* 使用者註冊表（Registration Sheet）：儲存使用者基本資料的試算表
* 區域分流（Zone-Based Routing）：依地理區域或區塊將事件導向不同負責人
* 值班人員（On-Duty Personnel）：負責即時處理事件或通知的指定人員
* 區塊對應表（Block Mapping Sheet）：將區域或區塊對應到負責人的資料表
* 第二層查詢（Secondary Lookup）：在流程中進行第二次資料查找以補充資訊
* 地址解析（Address Resolution）：從資料表中取得完整地址資訊
* 關聯式資料查詢（Relational Lookup）：跨多個資料表取得關聯資訊的流程
* Gmail API：Google 提供用於發送與管理電子郵件的程式介面
* 郵件通知（Email Notification）：以電子郵件方式傳送事件或警示資訊
* Panic Notification：緊急事件觸發後發送的即時警示訊息
* Gmail Send Message Node：n8n 中用於發送電子郵件的功能節點
* OAuth 憑證重用（Credential Reuse）：在多個節點中使用同一組授權設定
* API Scope：定義 API 可執行操作範圍的權限設定
* 郵件主旨（Email Subject）：電子郵件中用於快速識別內容的標題
* 郵件內文（Email Body）：電子郵件中包含詳細資訊的主要內容
* 變數插值（Variable Interpolation）：在文字中嵌入動態資料的技術
* 多來源資料組裝（Multi-Source Data Assembly）：整合多個節點輸出形成完整訊息
* 即時告警（Real-Time Alert）：事件發生後立即通知相關人員的機制
* 自動派遣（Automated Dispatch）：系統自動將事件資訊交付處理單位
* 實體安全流程（Physical Security Workflow）：用於處理實體安全事件的自動化流程
* 工作流程啟用（Workflow Activation）：將流程切換為可接收事件的狀態
* 生產測試（Production Test）：在正式環境中驗證流程端到端運作
* 訊息解析（Message Parsing）：從收到的訊息中擷取關鍵資訊
* 單一指令觸發（Single-Command Trigger）：使用極簡輸入（如「1」）啟動流程
* 容錯設計（Fault Tolerance）：流程在非預期輸入下仍能正常運作的能力
* 節點串接（Node Chaining）：將多個節點依序連接形成完整邏輯
* 流程可擴展性（Workflow Scalability）：支援更多使用者或區域而不需重構的能力
* 多用戶支援（Multi-User Support）：流程可同時處理多位使用者事件
* 多區域通知（Multi-Zone Notification）：依不同區域發送不同通知對象
* 即時監控（Live Monitoring）：持續觀察流程是否正常運作的能力
* 端到端流程（End-to-End Workflow）：從事件輸入到通知輸出的完整自動化流程
* 人在迴圈（Human-in-the-loop）：流程在關鍵決策點暫停，等待人類判斷後再繼續
* 面試自動化流程（Interview Scheduling Automation）：結合 AI 與人工審核的招聘流程
* 履歷處理流程（CV Processing Workflow）：自動讀取、分析並整理求職者履歷
* 指定資料夾監控（Designated Folder Processing）：以特定 Google Drive 資料夾作為輸入來源
* PDF 履歷文件（PDF Resume Files）：以標準化格式提供的求職文件
* 批次處理（Batch Processing）：一次處理多份履歷文件的流程設計
* 迴圈節點（Loop / Iteration）：針對每一份履歷逐一執行相同處理步驟
* AI 履歷摘要（AI Resume Summarization）：由語言模型萃取重點資訊
* 關鍵資訊萃取（Key Information Extraction）：擷取技能、經驗、背景等重要內容
* 招聘決策支援（Hiring Decision Support）：輔助招聘人員快速做出判斷
* 電子郵件審核介面（Email-based Review Interface）：透過 Email 提供摘要與操作選項
* 核准按鈕（Approve Action）：允許候選人進入下一輪面試的人工操作
* 拒絕按鈕（Decline Action）：終止候選人流程的人工操作
* 流程暫停（Workflow Pause）：等待人類輸入前不繼續執行後續步驟
* 條件分支（Conditional Branching）：根據人工選擇走不同流程路徑
* 面試排程代理（Interview Scheduling Agent）：負責安排面試時間的 AI agent
* Google Calendar 整合（Google Calendar Integration）：自動寫入面試行程
* 最早可用時段搜尋（Earliest Available Slot）：尋找下週最早可行的一小時時段
* 實體面試（In-person Interview）：非線上、需排定地點與時間的面試形式
* 人工裁量權（Human Discretion）：由人類負責最終錄取與否的關鍵判斷
* 手動觸發器（Manual Trigger）：透過按鈕手動啟動流程以便測試
* Google Drive 搜尋節點（Google Drive Search Node）：列出指定資料夾內檔案
* 進階搜尋（Advanced Search）：使用條件式查詢精準篩選檔案
* MIME 類型過濾（MIME Type Filtering）：只處理 application/pdf 類型檔案
* 資料夾 ID（Folder ID）：唯一識別 Google Drive 資料夾的參數
* 父資料夾查詢（Parents Query）：限定搜尋結果來源的查詢條件
* OAuth 2.0 驗證（OAuth 2.0 Authentication）：安全授權存取 Google Drive
* Google Drive API：用於存取與管理雲端檔案的 API
* API 啟用（API Enablement）：在 Google Cloud Console 中啟用服務
* 用戶端 ID 與密鑰（Client ID / Client Secret）：OAuth 驗證必要憑證
* 授權重新導向 URI（Redirect URI）：OAuth 授權流程中的回呼位址
* 使用者同意畫面（Consent Screen）：請求使用者授權資料存取
* 檔案中繼資料（File Metadata）：包含檔名與檔案 ID 的結構化資訊
* 測試資料釘選（Pinned Test Data）：固定輸出以利後續節點開發與測試
* 迴圈節點（Loop Node）：在工作流程中重複執行一組節點的控制結構
* Loop Over Items：n8n 中用來逐筆處理輸入項目的迴圈節點
* 批次大小（Batch Size）：每次迴圈處理的項目數量設定
* 單筆處理（Single-Item Processing）：一次只處理一個資料項目的執行模式
* for 迴圈（For Loop）：程式設計中用於依序重複執行的控制結構
* while 迴圈（While Loop）：依條件判斷是否持續執行的迴圈結構
* 人在迴圈中（Human-in-the-Loop）：需要人類審核或決策才能繼續的自動化流程設計
* 文件逐筆審核（Per-Document Review）：每份文件需獨立進行人工審核的流程模式
* CV（Curriculum Vitae）：求職者的履歷文件
* PDF 處理流程（PDF Processing Pipeline）：從下載到解析 PDF 的一連串處理步驟
* 迭代（Iteration）：迴圈中單次重複執行的流程單位
* 並行處理（Parallel Processing）：多個項目同時處理的執行方式
* 序列處理（Sequential Processing）：項目依序、一個接一個處理的方式
* 流程控制（Flow Control）：決定節點執行順序與條件的機制
* Done 連接點（Done Connector）：表示迴圈所有項目處理完成後的出口
* Google Drive 節點（Google Drive Node）：n8n 中用來操作 Google Drive 的功能節點
* 檔案下載（File Download）：從雲端儲存服務取得檔案的操作
* Download File Node：n8n 中專門用來下載檔案的節點
* 檔案 ID（File ID）：Google Drive 中每個檔案的唯一識別碼
* Binary Data（二進位資料）：以非文字形式儲存的檔案內容
* Expression 模式（Expression Mode）：允許使用動態資料與變數的設定模式
* 動態欄位綁定（Dynamic Field Binding）：將流程中即時資料綁定到節點參數
* Extract From File Node：n8n 中用來解析檔案內容的節點
* PDF 文字擷取（PDF Text Extraction）：將 PDF 內容轉換為可讀文字的技術
* 文件解析（Document Parsing）：將結構化或非結構化文件轉成可用資料
* OCR 前處理（OCR Preprocessing）：在文字擷取前對文件進行的準備流程
* 純文字輸出（Plain Text Output）：移除格式後的文字內容
* Text Field：節點輸出中存放文字資料的欄位
* 資料釘選（Pinned Data）：固定測試資料以便重複執行節點
* 節點單步執行（Execute Step）：只執行單一節點以進行測試
* 節點輸入面板（Input Panel）：顯示節點接收資料的介面
* 節點輸出面板（Output Panel）：顯示節點執行結果的介面
* 履歷摘要（CV Summarization）：將履歷內容濃縮成重點摘要的任務
* AI Agent：能自主接收輸入並產生智慧輸出的模型節點
* 文件理解（Document Understanding）：模型理解文件語意與結構的能力
* 工作流程組裝（Workflow Assembly）：逐步建立完整自動化流程的過程
* 節點替換（Node Replacement）：以新節點取代預設或占位節點的操作
* Replace Me 節點（Placeholder Node）：迴圈建立時自動產生的佔位節點
* 節點刪除（Node Deletion）：移除不需要節點的操作
* 人工審核節點（Human Review Step）：需要人類確認或決策的流程節點
* 招聘流程自動化（Recruitment Workflow Automation）：自動處理履歷與審核流程的系統設計
* 流程可讀性（Workflow Readability）：讓流程結構清楚易懂的設計特性
* AI 代理（AI Agent）：可自主規劃並執行任務的智慧程式，能依目標做決策與調用工具
* 節點（Node）：工作流程中的功能模組，用於處理資料或觸發動作
* 工作流程（Workflow）：以節點串接的自動化流程，描述資料如何被處理與傳遞
* 低程式碼（Low-code）：以圖形化配置為主、少量程式即可完成自動化與應用邏輯
* 流程編排（Orchestration）：協調多個服務/節點的執行順序、依賴關係與資料流
* 連線器（Connector）：用來連接外部服務（如 Gmail、Google Calendar、OpenAI）的整合元件
* 憑證（Credentials）：存取外部服務所需的授權資訊（如 API Key、OAuth Token）
* OAuth 2.0（OAuth 2.0）：常用授權框架，讓應用以委派方式存取使用者資源
* API 金鑰（API Key）：用於識別與授權呼叫 API 的密鑰字串
* 聊天模型（Chat Model）：以對話形式輸入輸出、擅長指令理解與生成的語言模型
* GPT-4.1 mini（GPT-4.1 Mini）：OpenAI 的輕量化聊天模型選項，平衡成本與效能
* 系統提示（System Prompt）：用來定義模型角色、規則與行為邊界的最高優先級指令
* 使用者提示（User Prompt）：用來描述當前任務需求與輸入內容的提示文字
* 提示工程（Prompt Engineering）：設計提示結構以提升模型輸出品質與可控性的方法
* 護欄（Guardrails）：限制模型行為的規則集合，用於降低偏差與錯誤輸出風險
* 結構化輸出（Structured Output）：要求模型以固定結構（如 JSON）回傳可機器解析的結果
* 輸出剖析器（Output Parser）：將模型輸出解析成結構化資料並驗證欄位格式的元件
* 一次示例（One-shot）：在提示中提供單一範例以引導模型學習輸出格式與風格
* JSON 架構（JSON Schema）：描述 JSON 欄位型別、必填與約束的規格，用於驗證輸出
* 布林值（Boolean）：只有 true/false 的資料型別，常用於條件判斷
* 條件分支（Conditional Branching）：根據條件結果走不同流程路徑（true/false）
* IF 節點（IF Node）：在流程中依條件運算結果進行分流的節點
* 人在迴圈（Human-in-the-loop）：把人類決策嵌入自動化流程以提升可靠性與治理能力
* 核准/拒絕（Approve/Disapprove）：在人在迴圈中以按鈕回傳決策狀態的互動機制
* 送出並等待回覆（Send and Wait for Response）：發送訊息後暫停流程直到收到人工回應的操作模式
* 工作流程暫停（Workflow Pause）：流程因等待外部事件（如人工核准）而停止後續執行的狀態
* 回呼（Callback）：外部系統在事件發生時回傳資料以續跑流程的機制
* 事件觸發（Event Trigger）：由外部事件（如按鈕點擊、收信）啟動或推進流程的方式
* Gmail 節點（Gmail Node）：用於發送郵件、等待回覆等 Gmail API 整合的流程元件
* Google Calendar API（Google Calendar API）：用於建立與查詢行事曆事件的介面
* 工具呼叫（Tool Calling）：模型根據需求呼叫外部工具/API 以完成任務的能力
* 函式呼叫（Function Calling）：以明確函式簽名讓模型產生參數並觸發特定操作的機制
* 工具鏈（Toolchain）：多個外部工具與模型協作完成任務的整體組合
* PDF 擷取（PDF Extraction）：從 PDF 中提取可用文字內容以供後續分析
* 文件解析（Document Parsing）：將非結構化文件轉為可處理的結構化/半結構化資料
* 履歷（CV/Resume）：求職者的經歷與技能文件，作為篩選與面試依據
* 候選人評估（Candidate Screening）：依職缺要求對履歷進行初步審核與篩選
* 摘要生成（Summarization）：將長文本壓縮為重點資訊的生成式任務
* 招募建議（Hiring Recommendation）：基於條件與內容分析給出的錄用/面試建議結論
* 資料綁定（Data Binding）：把上游節點輸出欄位映射到下游節點輸入欄位的機制
* 表達式（Expression）：在節點欄位中用語法動態引用/運算資料（如 JavaScript 表達式）
* 內嵌條件（Inline If）：在文字模板中用條件運算決定要插入哪段內容的寫法
* 範本訊息（Template Message）：由固定文本與動態欄位組合而成的可重用訊息格式
* 管線（Pipeline）：資料依序通過多個處理步驟形成的端到端處理鏈
* 分離關注點（Separation of Concerns）：將流程切分為獨立職責模組以提升可維護性與可測試性
* 釘選資料（Pin Data）：固定某次執行輸出作為測試輸入，方便逐步開發與除錯
* 步進執行（Step Execution）：只執行單一節點/步驟以驗證輸入輸出是否正確
* 面試排程（Interview Scheduling）：依候選人核准結果自動建立面試事件並寫入行事曆
* 一小時面試（One-hour Interview Slot）：常見面試時長配置，用於行事曆事件的時間區塊設定
* 系統提示（System Prompt）：用於定義 AI agent 的角色、行為規則與整體目標
* 使用者提示（User Prompt）：直接提供給模型的任務指令與操作流程描述
* 動態欄位（Dynamic Fields）：在提示中以變數形式插入即時資料
* 表達式語法（Expression Syntax）：用於在工作流中動態計算或引用資料
* 工具呼叫（Tool Calling）：語言模型主動呼叫外部 API 以完成任務
* Google Calendar API：用於讀取與建立行事曆事件的介面
* 事件建立（Create Calendar Event）：在行事曆中新增排程的操作
* 事件查詢（Get Calendar Events）：取得既有行事曆事件的操作
* 工具命名對齊（Tool Name Alignment）：提示中工具名稱需與實際工具一致
* OAuth 2.0 授權（OAuth 2.0 Authorization）：安全存取 Google Calendar 的驗證機制
* Client ID（用戶端 ID）：OAuth 驗證中識別應用程式的識別碼
* Client Secret（用戶端密鑰）：OAuth 驗證中用於簽署請求的私密金鑰
* 重新導向 URI（Redirect URI）：OAuth 授權流程完成後的回呼位置
* API 啟用（API Enablement）：在雲端專案中啟用特定服務
* 雲端專案（Cloud Project）：Google API 資源與權限的管理單位
* 行事曆事件衝突（Calendar Conflict）：新事件與既有事件時間重疊的狀況
* 可用時段搜尋（Availability Search）：找出未被占用的時間區段
* 工作時間限制（Working Hours Constraint）：限定排程只能在特定時段內
* 下一週範圍（Next Week Window）：僅考慮下個曆週的時間區間
* 本週排除（Current Week Exclusion）：避免在當前週安排事件
* 最早可用時段（Earliest Available Slot）：符合條件的第一個可行時間
* 在地時區（Local Time Zone）：以使用者所在時區計算時間
* 行事曆同步（Calendar Synchronization）：AI 與行事曆資料保持一致
* 多方參與者（Multiple Attendees）：事件中包含面試官與應徵者
* 電子郵件欄位（Email Field）：用於邀請行事曆參與者的聯絡資訊
* 事件標題（Event Title）：行事曆中顯示的活動名稱
* 事件描述（Event Description）：補充活動內容的文字說明
* AI 排程代理（AI Scheduling Agent）：負責自動安排時間的 AI agent
* 任務分解（Task Decomposition）：將排程流程拆解為多個明確步驟
* 規則導向提示（Rule-based Prompt）：以明確規則約束模型行為
* 工具鏈（Tool Chain）：多個工具依序被 agent 呼叫完成任務
* 狀態感知（State Awareness）：模型理解目前時間與既有事件狀態
* 指令明確化（Instruction Explicitness）：以具體條件降低模型誤判
* API 操作模式（API Operation Mode）：如 create、getMany 等操作類型
* 多工具整合（Multi-tool Integration）：單一 agent 使用多個外部工具
* 憑證重用（Credential Reuse）：多個工具共用同一組 OAuth 憑證
* 行事曆讀寫權限（Calendar Read/Write Scope）：允許存取與修改事件的權限
* 自動化排程（Automated Scheduling）：無需人工介入完成排程
* 任務可靠性（Task Reliability）：確保排程結果符合所有限制條件
* 時間邊界檢查（Time Boundary Validation）：防止事件超出允許範圍
* 提示對齊（Prompt–Tool Alignment）：提示內容與實際工具行為一致
* API 回傳解析（API Response Parsing）：解析行事曆事件資料
* 無系統提示設計（No System Prompt Setup）：僅以單一大型提示控制行為
* AI 工具協調（AI Tool Orchestration）：模型負責協調多個工具的使用順序
* 建立行事曆事件（Create Calendar Event）：透過 API 在行事曆中新增排程事件的操作
* 行事曆工具節點（Calendar Tool Node）：n8n 中用來操作行事曆的功能節點
* Start Time（開始時間）：行事曆事件開始的時間欄位
* End Time（結束時間）：行事曆事件結束的時間欄位
* AI 決策欄位（AI-Determined Field）：由 AI agent 根據提示自動填入的欄位
* Star Selector（星號選擇器）：n8n 中用來標示欄位由 AI 決定的設定按鈕
* Prompt-Based Scheduling：根據自然語言提示自動決定排程時間的技術
* 行事曆選擇（Calendar Selection）：指定事件要建立在哪一個行事曆中的設定
* Google Calendar：Google 提供的雲端行事曆服務
* Attendees（與會者）：行事曆事件中參與會議的人員清單
* 多與會者設定（Multiple Attendees）：在單一事件中設定多位參與者
* AI Attendee Extraction：由 AI 從提示中推斷與會者身分與電子郵件
* Event Description（事件描述）：行事曆事件中顯示的詳細說明文字
* Event Summary（事件摘要）：行事曆事件的標題或簡要說明
* 欄位自動填寫（Automatic Field Population）：由 AI 自動產生欄位內容的機制
* Get Calendar Events：查詢既有行事曆事件的工具節點
* 行事曆衝突檢查（Calendar Conflict Checking）：檢查既有事件以避免時間重疊
* After / Before Filter：用來限制查詢事件時間範圍的條件
* AI 時間推理（Temporal Reasoning）：AI 根據上下文判斷合適時間的能力
* Interview Scheduling（面試排程）：自動安排面試時間的流程
* 面試官行事曆（Interviewer Calendar）：負責面試人員的個人行事曆
* 可用時段判斷（Availability Detection）：找出行事曆中可用時間的能力
* Chat Model Sub-node：為 AI agent 提供語言模型推理能力的子節點
* OpenAI Chat Model：連接 OpenAI 語言模型的節點
* GPT-4.1 Mini：適合工具調用與推理任務的輕量語言模型
* 模型附加（Model Attachment）：將語言模型連接至 AI agent 的設定
* Workflow Execution Error：因缺少必要節點導致的流程錯誤
* Human-in-the-Loop Approval：需要人工核准才能繼續流程的設計
* Approval Flag（核准旗標）：表示申請是否通過的人為決策欄位
* Boolean Routing（布林分支）：依 true / false 決定流程走向的控制方式
* True Connector：在條件成立時被觸發的流程出口
* False Connector：在條件不成立時被觸發的流程出口
* Conditional Bypass：在特定條件下略過部分流程的設計
* Interview Creation Logic：僅在核准時才建立面試事件的邏輯
* Loop Continuation：完成一次處理後回到迴圈處理下一筆資料
* Loop Back Connection：將節點輸出重新接回迴圈起點的連線方式
* Sequential CV Processing：依序處理每一份履歷的執行模式
* Data Unpinning：移除測試用固定資料以進入正式執行模式
* Test Mode vs Production Mode：測試執行與正式執行流程的差異
* Workflow Finalization：完成所有節點串接後的最終流程狀態
* Automated Interview Pipeline：從履歷審核到面試排程的全自動流程
* Calendar Event Validation：確認行事曆事件正確建立的檢查步驟
* AI Tool-Oriented Agent：以工具調用為核心能力的 AI agent
* Prompt-to-Action Mapping：將自然語言提示轉換為具體操作的能力
* 人在迴圈（Human-in-the-loop）：流程在關鍵節點暫停，必須由人類做出決策才能繼續
* 履歷批次處理（Batch CV Processing）：一次對多份履歷依序執行相同流程
* 迴圈執行（Loop Execution）：針對清單中的每個項目重複執行工作流
* 人工審核節點（Manual Review Step）：需要人類確認或否決的流程步驟
* 電子郵件審核（Email-based Approval）：透過 Email 接收摘要並進行決策
* 核准操作（Approve Action）：允許候選人進入下一階段流程
* 拒絕操作（Decline Action）：終止候選人後續流程
* 流程阻塞（Workflow Blocking）：在等待人類回應前暫停自動化流程
* 條件式分支（Conditional Branch）：根據核准或拒絕走不同路徑
* 履歷摘要生成（Resume Summarization）：由語言模型提取履歷重點
* 關鍵技能萃取（Skill Extraction）：從履歷中辨識核心技術能力
* 年資判斷（Experience Assessment）：根據履歷估算相關工作經驗
* AI 推薦意見（AI Recommendation）：模型對是否進入面試的建議
* 第一輪面試（First-round Interview）：初步篩選候選人的面試階段
* 自動排程（Automated Scheduling）：由系統自動決定並建立行程
* 行事曆事件建立（Calendar Event Creation）：在 Google Calendar 新增事件
* 時段最佳化（Time Slot Optimization）：選擇最早且符合條件的可用時間
* 連續排程（Back-to-back Scheduling）：多個面試依序無縫安排
* 工作時段限制（Business Hours Constraint）：僅允許在指定工作時間內排程
* 事件避免衝突（Conflict Avoidance）：避免與既有行程時間重疊
* 事件描述自動生成（Auto-generated Description）：自動填入面試相關說明
* 參與者邀請（Attendee Invitation）：將面試官與應徵者加入事件
* 電子郵件地址驗證（Valid Email Requirement）：避免因無效信箱導致寄送失敗
* 動態資料綁定（Dynamic Data Binding）：以流程資料填入事件欄位
* AI Agent（AI 代理）：具備決策與工具使用能力的語言模型實體
* 工具調度（Tool Orchestration）：AI 決定何時呼叫哪個外部工具
* Google Calendar 整合（Google Calendar Integration）：與行事曆系統直接互動
* 狀態可視化（Execution Visualization）：即時顯示流程目前執行位置
* 節點暫停顯示（Paused Node Indicator）：視覺化呈現流程等待中狀態
* 任務完成狀態（Workflow Completion）：所有迴圈與節點成功結束
* 面試資料一致性（Interview Data Consistency）：確保行事曆與履歷資料對齊
* AI 輔助決策（AI-assisted Decision-making）：由 AI 提供建議、人類做最終決定
* 半自動化流程（Semi-automated Workflow）：結合自動化與人工介入
* 招聘流程自動化（Recruitment Automation）：以工作流系統簡化招聘作業
* 任務可靠性（Process Reliability）：確保每位候選人都被正確處理
* 流程可追蹤性（Process Traceability）：每一步決策與結果皆可回溯
* 多候選人處理（Multi-candidate Handling）：同一流程支援多名應徵者
* 資料驅動排程（Data-driven Scheduling）：依據實際行程資料決定時間
* 人工最終裁量（Human Final Authority）：AI 不取代人類最終決策權
* 實務導向 AI 應用（Practical AI Application）：AI 用於真實商業流程
* 低程式碼自動化（Low-code Automation）：以最少程式碼完成複雜流程
* 招聘效率提升（Hiring Efficiency Improvement）：縮短篩選與排程時間
* 流程可重用性（Workflow Reusability）：可套用於其他職缺或招聘情境
* AI 與工具協作（AI–Tool Collaboration）：語言模型與外部系統協同工作
* 子工作流程（Subworkflow）：被其他主工作流程呼叫、負責特定功能的獨立流程
* 主工作流程（Parent Workflow）：負責整體流程協調、可呼叫多個子工作流程的流程
* 工作流程模組化（Workflow Modularization）：將大型流程拆分成可重用模組的設計方式
* 關注點分離（Separation of Concerns）：將不同功能責任拆開以降低耦合度的設計原則
* Execute Subworkflow Node：n8n 中用來呼叫並執行子工作流程的節點
* 子流程觸發器（Subworkflow Trigger）：允許子工作流程被外部流程啟動的起始節點
* 輸入參數（Input Parameters）：由父流程傳遞給子流程的資料欄位
* 參數映射（Parameter Mapping）：將父流程資料對應到子流程輸入欄位的過程
* Full Name 欄位（Full Name Field）：用來傳遞候選人姓名的字串型參數
* Email 欄位（Email Field）：用來傳遞電子郵件地址的字串型參數
* 可重用流程（Reusable Workflow）：可被多個主流程重複呼叫的流程設計
* 流程抽象化（Workflow Abstraction）：將複雜邏輯封裝成高階流程的做法
* 節點群組化（Node Grouping）：將多個相關節點視為一個邏輯單元
* 流程可維護性（Workflow Maintainability）：流程在修改與擴充時的穩定與易維護程度
* 流程可讀性（Workflow Readability）：流程結構是否清楚易懂的特性
* 蜘蛛網效應（Spaghetti Workflow）：節點過多、連線混亂的流程狀態
* 節點抽離（Node Extraction）：將部分節點移出主流程的重構行為
* 流程重構（Workflow Refactoring）：在不改變功能的前提下改善流程結構
* 版本隔離（Version Isolation）：子流程修改不影響主流程的設計特性
* 平行開發（Parallel Development）：不同流程可同時獨立開發的工作模式
* 流程依賴管理（Workflow Dependency Management）：管理主流程與子流程之間的關係
* 介面契約（Interface Contract）：父流程與子流程之間約定的輸入輸出規格
* 動態資料注入（Dynamic Data Injection）：在執行時將變數資料傳入子流程
* JavaScript Expression 驗證：n8n 中以顏色顯示表達式是否合法的機制
* 綠色表達式（Valid Expression）：表示動態資料綁定成功的狀態
* 紅色表達式（Invalid Expression）：表示資料參照錯誤或不存在的狀態
* 參照錯誤（Reference Error）：流程中引用不存在欄位所產生的錯誤
* Prompt 重構（Prompt Refactoring）：因流程結構改變而調整提示內容的行為
* Prompt 參數化（Prompt Parameterization）：將提示中的固定文字改為動態變數
* 硬編碼（Hardcoding）：在流程中直接寫死資料值的做法
* 動態 Prompt（Dynamic Prompt）：由流程資料即時組合而成的提示內容
* Human-in-the-Loop 節點：需要人類回應才能繼續流程的節點
* 流程暫停（Workflow Pause）：等待人工決策時流程停止執行的狀態
* 核准流程（Approval Flow）：根據人工核准結果決定後續行為的流程
* 條件分支（Conditional Branching）：依不同條件導向不同流程路徑的設計
* 流程回圈銜接（Loop Reconnection）：子流程完成後回到主流程迴圈的設計
* 面試排程子系統（Interview Scheduling Subsystem）：專責處理面試時間安排的流程模組
* 行事曆避免衝突（Calendar Conflict Avoidance）：避免重複排程的邏輯設計
* Prompt Engineering（提示工程）：設計高品質提示以提升 AI 行為準確度的技術
* 初學者流程設計（Beginner Workflow Design）：以可理解性優先的流程設計取向
* 功能示範導向（Concept Demonstration）：以說明概念為主而非追求完美實務的設計方式
* 工作流自動化（Workflow Automation）：以節點串接方式自動執行多步驟任務
* 聊天機器人整合（Chatbot Integration）：將對話式 AI 接入工作流
* 即時訊息觸發器（Message-based Trigger）：透過即時通訊收到訊息即啟動流程
* WhatsApp 介面整合（WhatsApp Integration）：以 WhatsApp 作為使用者互動入口
* 記憶模組（Memory Module）：讓聊天機器人保留對話上下文
* 簡易記憶（Simple Memory）：只保留最近幾輪對話的上下文
* 對話上下文（Conversation Context）：理解使用者前後問題的語意關聯
* 多通道介面（Multi-channel Interface）：同一 AI 可透過不同平台互動
* Discord 整合（Discord Integration）：將工作流接入 Discord 機器人
* Telegram 整合（Telegram Integration）：將工作流接入 Telegram 機器人
* Webhook（網路掛鉤）：透過 HTTP 接收外部系統傳入資料
* HTTP POST 請求（HTTP POST Request）：由外部系統送資料到工作流
* 表單資料收集（Form Data Collection）：接收使用者填寫的結構化資料
* 第三方網站整合（Third-party Website Integration）：將外部網站與工作流連接
* 測試端點（Test Endpoint）：供開發與測試使用的 Webhook URL
* 生產端點（Production Endpoint）：正式環境使用的 Webhook URL
* API 呼叫（API Call）：向外部服務請求資料或功能
* HTTP Request 節點（HTTP Request Node）：在工作流中主動發送 HTTP 請求
* REST API（RESTful API）：以 HTTP 為基礎的服務介面標準
* 自訂後端服務（Custom Backend Service）：自行開發並提供資料的 API
* JSON 回應（JSON Response）：API 回傳的結構化資料格式
* 資料階層結構（Hierarchical Data）：巢狀結構的資料格式
* 資料扁平化（Data Flattening）：將巢狀資料轉為平面結構
* Code 節點（Code Node）：在工作流中執行自訂程式碼
* JavaScript 處理（JavaScript Processing）：用 JS 轉換與整理資料
* 資料轉換（Data Transformation）：改變資料格式以利後續處理
* AI Agent（AI 代理）：具備推理與工具使用能力的語言模型
* 工具節點（Tool Node）：提供 AI 可呼叫的外部功能
* HTTP Request 工具（HTTP Request Tool）：供 AI agent 主動呼叫 API
* 工具驅動推理（Tool-based Reasoning）：AI 依需求選擇並使用工具
* 外部資料來源（External Data Source）：非模型本身提供的資訊
* 資料增強生成（Data-augmented Generation）：結合外部資料生成回應
* 領域知識查詢（Domain-specific Query）：針對特定資料集提問
* 情境式推薦（Contextual Recommendation）：依資料與問題給建議
* 電影推薦系統（Movie Recommendation System）：依類型與評分推薦電影
* 情感分析（Sentiment Analysis）：判斷評論文字的正負面傾向
* 資料可讀性（Data Readability）：資料是否易於模型理解
* 低程式碼平台（Low-code Platform）：以最少程式碼完成應用開發
* 視覺化流程設計（Visual Workflow Design）：以圖形方式設計流程
* 系統擴展性（System Extensibility）：可自由整合新介面與服務
* 事件驅動架構（Event-driven Architecture）：由事件觸發流程執行
* 即時互動應用（Real-time Interactive Application）：可即時回應使用者輸入