營運痛點：7,000 則評論，沒有人回得完
園區 Google 商家累積超過 7,100 則評論、其中 4,800 則帶有文字內容，實務上卡在三個問題：
- 回不完：評論持續累積，人工逐則閱讀、判斷、撰稿的成本高到只能挑著回。
- 回不穩：不同人回覆的語氣、資訊（票價、時間、預約電話）不一致，公開留在 Google 上就是品牌形象。
- 不敢自動回：客訴、安全事故、法律爭議與個資，一旦讓 AI 直接公開發布，錯一次就是公開事故。
系統策略：AI 只負責草稿，發布權留在人手上
本專案的核心設計是「AI 提速、人類把關、系統設閘門」，而不是全自動回覆：
- AI 產草稿不發布：Gemini 讀取新評論，產出回覆草稿、分類與風險等級，寫入 Google Sheet。
- Sheet 就是操作台：客服人員只在 Google Sheet 上作業，不需要進入 n8n 改任何節點。
- 核准才送出：人工把狀態改為「核准送出」後，發布流程才會撿走該列。
- 閘門獨立於 AI 判斷：即使 AI 說可以自動回，星等、風險等級、禁用詞與個資檢查仍會各自否決。
商業價值與影響力
- 把回覆從「寫稿」變成「審稿」：人工作業從逐則撰寫，降為檢查與微調草稿，同樣人力可覆蓋更多評論。
- 對外資訊一致：票價、營業時間、預約電話等答覆統一來自單一知識庫設定檔，不再因人而異。
- 公開發布風險可控：高風險評論一律留給人工，系統層級擋下，不依賴當班人員的判斷力。
- 營運成本近乎為零：正式草稿流程使用 Gemini Free Tier 額度，n8n 自架於本機，無額外授權費用。
核心功能
已上線運作
- 新評論擷取與去重：每次執行先讀回 Sheet 既有
review_id再擷取評論，避免流程重啟或重新匯入後重複建立。 - AI 草稿與風險分級：Gemini 產出回覆草稿、分類與 Low／Medium／High／Critical 風險等級。
- 品質閘門（Quality Gate）：驗證 AI 回傳結構、風險判斷與自動回覆許可的一致性，不合格即攔下。
- 個資遮罩：草稿寫入 Sheet 前先過濾電話等敏感字串。
- 人工核准發布：每 10 分鐘檢查一次 Sheet，只發布通過全部安全條件的核准列，成功後回寫狀態與回覆時間。
- 覆蓋保護：送出前先讀取 Google 上既有的業主回覆，若已有不同回覆則不覆蓋，轉交人工。
已完成、待外部審核
- Facebook／Messenger 客服模組：關鍵字路由表、回覆模板、Messenger FAQ 設定與 Meta Webhook Worker 範本均已完成，等待 Meta App Review。
技術亮點
- 雙層授權設計：AI 的
allow_auto_reply只是建議值，最終由程式端硬性閘門決定——只有 4★／5★ 且風險 Low／Medium 的評論才可能進入發布流程。實測 30 則中，AI 對 12 則 1–2 星裡的 10 則標記可自動回覆，全數被星等閘門攔下。 - Prompt 單一來源：
config/review-system-prompt.txt為唯一來源，本機測試腳本直接讀取、n8n workflow 內嵌副本由同步指令產生，檢查腳本會驗證三方逐字一致，不一致即失敗。此機制修正了先前三份 prompt 各自漂移、其中一份缺少園區知識的問題。 - Workflow 一致性檢查：
npm run check驗證 n8n workflow 內嵌的 jsCode 與n8n/*.js原始檔完全相同，並檢查節點執行模式、接線與停用狀態，避免兩邊各改一份。 - 時間閘門防回填：流程設有啟用時間點，只處理啟用之後建立的新評論，避免一次把數千則歷史評論送進 AI。
- 成本路線取捨：原本的本機每日整批腳本沒有去重機制，排程後每次會把全部評論重送 AI，成本不可接受；該路線已明確停用並加上執行保護，改以 n8n 增量流程為正式路線。
法規與風險處理
知識庫原本載明「園區不開放寵物及導盲犬入園」，此內容會由 AI 自動公開張貼於 Google 評論回覆，等同對外公開聲明一項與《身心障礙者權益保障法》第 60 條衝突的政策。已改為不表態、統一導向專線由專人說明，並同步修正全部相關文件與路由表。
此處理讓自動回覆不再對外聲明該政策，但不改變現場實際做法——這一點在專案文件中被明確標記為仍待營運端確認的殘留風險，而非視為已解決。
系統架構
Google Business Profile（新評論）
│
▼
n8n 草稿流程（台北時間 08:00–17:00 每小時，共 10 次）
├── Read Existing Review IDs（讀 Sheet 既有 ID）
├── Fetch / Normalize / Dedupe（擷取、正規化、去重）
├── Gemini（草稿 + 分類 + 風險等級）
├── Quality Gate（結構與風險一致性驗證）
└── Redact（個資遮罩）
│
▼
Google Sheet「reviews」中控表 ←── 客服人員審核 / 修改 final_reply / 改狀態為「核准送出」
│
▼
n8n 發布流程（每 10 分鐘）
├── 僅取 status = 核准送出
├── 風險 Low／Medium、長度、禁用詞、敏感資料檢查
├── 讀取 Google 既有業主回覆（避免覆蓋）
└── 發布 → 回寫 status = 已回覆 / replied_at
技術棧
- 自動化編排：n8n（本機自架，2.x）
- AI 模型：Google Gemini（正式流程，Free Tier）；OpenAI 版流程保留但未啟用
- 外部 API：Google Business Profile API（帳號管理 / 商家資訊 / v4 評論）、Google Sheets API、Google Drive API
- 驗證機制：Google OAuth 2.0（consent screen 已發布正式版，refresh token 不再 7 天過期）
- 本機工具：Node.js (ESM) 腳本群——OAuth、評論擷取、AI 分類測試、品質驗收、自動回覆閘門、稽核紀錄匯出
- 輔助工具：Google Apps Script（Sheet 端輔助）、Cloudflare Worker（Meta Webhook 範本）、本機審核 Dashboard（HTML）
驗證與實測
- 真實資料抽樣測試：自 7,157 則評論中分層抽樣 30 則（1★8、2★4、3★4、4★4、5★10，刻意加重低星），送 AI 的內容僅含星等與評論文字，不含評論者姓名。抽查票價類分類全數正確；含「咬傷／危險／身分證」的評論被標為 Critical 並禁止自動回覆。
- 端到端受控測試：完整跑過擷取 → AI 草稿 → 品質閘門 → 遮罩 → 寫入 Sheet 的全程，確認各節點實際回傳值，而非僅確認流程部署成功。
- 首筆公開回覆：經人工逐字確認後受控發布第一筆真實 Google 公開回覆，Google API 回傳成功並回寫狀態與時間；發布後立即恢復安全鎖。
資安原則
Google OAuth refresh token、AI API Key 等憑證僅存放於 n8n Credential 或本機環境變數，不寫入專案檔或文件。含真實顧客姓名的評論輸出檔一律 gitignore；專案初期曾被追蹤的測試輸出檔已從版控移除。
💡 AI 協作筆記：本專案之 [風險分級 Prompt 設計 / 雙層自動回覆閘門 / n8n 流程編排與一致性檢查 / 法規風險檢核] 係透過與 AI 深度對話共同完成，展現了高效能的 AI 輔助開發模式。