醫院滿意度自動分類器

1

案例背景：為什麼做這個分類器

醫院門診每天用 Google Form 收集病人滿意度問卷。表面上是「收集回應 → 看回應 → 改進」的簡單循環，實際運作時有三層卡關：

三個痛點堆出來的工作量

1

每天通知淹沒信箱：Google Form 設「每筆回應寄通知」後，信箱被「您的表單《XX 門診》病人就醫經驗暨滿意度調查表有新回覆」這類通知塞滿，光看通知就花掉早上 30 分鐘

2

點開通知信只看到「有 1 則新回覆」：沒有摘要、沒有內容預覽，要再點一次「查看回應」才能看到實際填的內容。每封通知至少 3 次點擊才知道在講什麼

3

343 則回應的摘要頁，看不出誰急、誰重要：Google Form 的摘要把所有題目都列成圓餅圖，沒有按「急迫性」或「嚴重度」排序。實際病人反映「公廁有異味、老鼠尿」這種要 24 小時內處理的案件，埋在一堆「等候時間略長」「衛教單張很實用」之間

痛點實況

Gmail 信箱被 Google 表單的『有 N 則新回覆』通知塞滿，5/5、5/8、5/9 連續多日 — **痛點 1**：Gmail 信箱被表單通知塞滿，每筆回應一封，根本看不完

點開通知信只看到『有 1 則新回覆，查看回應 / 查看摘要』，沒有實際內容 — **痛點 2**：點開通知信只看到一個「查看回應」按鈕，完全不知道病人反映了什麼

Google 表單摘要顯示 343 則回應，各題用圓餅圖呈現，看不出哪個案件急需處理 — **痛點 3**：343 則回應的摘要頁，圓餅圖一堆，看不出哪個案件急、哪個重要

此案例的閱讀定位

這個案例是第 10 章「資料庫循環三步法」的完美落地。INPUT（Google Form 回應）→ PROCESS（Gemini 自動分類）→ STORE（Sheets 多分頁 + Email 警示）三步全到位。讀者讀完即可套用同樣方法論到自己領域：學校行政意見箱、社團活動回饋、研究室問卷、客戶 NPS（Net Promoter Score，淨推薦值，問客戶「願意推薦給朋友嗎」的 0-10 分滿意度調查，企業常用指標）。

2

工作流程：從寫指令到部署上線的四個階段

整個系統建置流程約 1 - 2 週（每天 1-2 小時），核心是「先用 Gemini 把分類邏輯想清楚，再交給 Claude Code 寫程式碼」。中間用到的「Google Apps Script（縮寫 GAS）」是 Google 內建的自動化工具，免費、寫一段程式就能讓表單、試算表、Gmail 串起來。

1

Gemini 設計助手

用「五要素框架」寫初步指令

用 Gemini 的「設計助手」（一個專門幫忙寫提示詞的小工具），以五要素框架（角色 / 做什麼 / 給誰看 / 主題範圍 / 依據資料）寫出第一版指令。

2

Claude Code

用過去資料訓練分類規則

把 343 則歷史回應丟給 Claude Code，讓它依「11 主類 × 43 子類」「4 級急迫性」「3 級重要性」分類，人工校對後反覆精修分類規則。

3

Claude Code

整合成規格文件

把分類規則 + Gemini 呼叫邏輯 + 觸發條件整合成一份規格文件（SPEC.md，SPEC 是 specification 規格書的縮寫，.md 是 Markdown 純文字檔的副檔名）。讓 Claude Code 自己審查規格是否完整，反覆修正到沒有遺漏。

4

Claude Code + GAS

產程式 + 部署

規格凍結後，Claude Code 一次產出完整 GAS 程式 + 部署說明書。照著貼到 Google Apps Script 編輯器、設定何時自動執行（GAS 叫「觸發器 Trigger」，可設成「每筆表單提交時跑一次」）、按授權鈕（首次跑會跳出 Google 帳號授權頁，按同意才能讓程式存取你的試算表與 Gmail），即可上線。

對應第 10 章「三步循環」

本案例完整體現第 10 章 §2 介紹的三步循環架構：

① INPUT

資料怎麼進來

病人在門診現場掃 QR Code 或診後收簡訊，進到 Google Form 填滿意度問卷。每次提交自動觸發 GAS。

② PROCESS

AI 怎麼處理

GAS 把回應內容傳給 Gemini API（讓你的程式呼叫 Google Gemini AI 的接口），請它依「11 主類 × 43 子類」分類、判定急迫性（P0-P3，P0 最急 24 小時內處理、P3 最不急 1 個月內處理）與重要性（高/中/低），並產生判定理由。

③ STORE

結果存到哪

分類結果寫回 Sheets 對應欄位 + 多個分析分頁（月報-類別、月報-急迫性、待辦清單）。P0 與「高重要性」案件自動 email 通知值班主管。

為什麼「五要素框架」是關鍵起點

多數人寫 AI 指令直接寫「請幫我分類滿意度回應」，結果 AI 給出的分類東一塊西一塊，無法直接用。「五要素框架」把指令拆成 5 個面向，強迫你先想清楚誰在做、做什麼、給誰看、什麼主題、依據什麼資料，寫完後的指令直接可用、也容易日後修改。

3

關鍵指令節錄：5 段最有啟發的對話

從整段建置歷程中挑出 5 段對話，代表這套系統設計過程中最關鍵的判斷點。

指令 1 · 階段 1 Gemini 設計助手

用「五要素框架」寫第一版指令

不要直接寫「請幫我分類」，先用「五要素框架」把要 AI 做的事拆清楚。Gemini 內的「設計助手」（一個專門幫忙寫指令的小工具）會把你的需求重組成五要素結構，英文叫 PARTS（取 Persona 角色、Act 做什麼、Recipient 給誰看、Theme 主題、Source 依據資料五個字的字首，下方表格有完整對照）。

設計一個 agent，能幫忙完美、有資安保護的建置自動化流程： INPUT：醫院顧客在官網填寫滿意度表單（Google Form） PROCESS：Gemini 自動讀詢問內容，分類如下方補充。 OUTPUT：分類結果寫回 Sheets + 急件 email 通知值班主管。

Gemini 設計助手 Gem 用 PARTS 框架回應，把原始 prompt 重組為結構化指令 — **Gemini 的回應**：用 PARTS 框架重組原始 prompt 成結構化指令，並建議輸出格式與 Google Sheets 整合方式

五要素框架（PARTS）

英文 / 字母	中文 / 意思	本案例對應
PPersona	AI 的角色	資深 Google Cloud 解決方案架構師 + GAS 開發專家
AAct	做什麼	建置 AI 自動分類 + 通知 + 統計分析系統
RRecipient	給誰看 / 給誰用	具備醫療品管與資訊管理概念的專案管理者
TTheme	主題範圍	醫院顧客滿意度 AI 自動化分類、通知、統計分析
SSource	依據資料	過去 343 則歷史回應 + 11 主類 × 43 子類分類表

關鍵心法：寫 AI 指令前先過「五要素框架」。寫得清楚後，後續所有 AI（Gemini / Claude / Claude Code）拿到同樣指令都能產出一致結果，日後要改也容易。

指令 2 · 階段 2 Claude Code

用歷史資料訓練分類規則

分類規則不要憑空寫，要用歷史資料反覆校對。把 343 則回應丟給 Claude Code，要它先分類、列出邊界案例，人工校對後修分類表。指令中用到的 SLA（Service Level Agreement，服務等級協議，承諾多久內必須處理完）與 Critical / Important / Nice-to-have（必須做 / 應該做 / 有就更好）都是專案管理常見用語。

請依照附上的 343 則歷史滿意度回應，設計一份完整的分類系統： 1. 主類別（Category）：建議分 8 - 12 個主類，例如「醫師專業」「服務態度」「等候時間」「環境衛生」等 2. 子類別：每個主類下分 3 - 5 個子類，例如「醫師專業」下分「醫術精湛/判斷」「醫療技術」「醫德問題」等 3. 急迫性（Urgency）：4 級（P0 24 小時內 / P1 1 週內 / P2 2 週內 / P3 1 個月內），分別給出 SLA + 判定條件 + 範例 4. 重要性（Importance）：3 級（Critical / Important / Nice-to-have），分別給出衝擊範圍 + 判定條件 + 範例 5. 邊界案例：列出 5 - 10 則你判讀後不確定該歸哪類的回應，標明你的疑慮，給我人工校對最後給我一張完整的分類表，我會逐項校對後再請你修正。

Claude Code 產出 11 主類 × 43 子類分類表，含代號、主類、子類、判定依據 — **分類表（部分）**：Claude Code 產出 11 主類（醫師專業、服務態度、等候時間、環境衛生、清潔衛生、餐飲膳食、人員溝通、人員配置、病人權益、員工權益、正面回饋等）× 43 子類

急迫性 4 級（P0-P3)+ 重要性 3 級（高/中/低）的判定依據與範例 — **急迫性與重要性表**：急迫性分 4 級，P0（最緊急，24 小時內要處理，例如涉及病人安全、感染風險）→ P3（最不急，1 個月內處理即可，例如政策與結構性議題）；重要性分 3 級，「高」=影響病人安全或多人權益，「低」=個人偏好

關鍵心法：分類規則先「用歷史資料訓練」再上線，比憑空想分類表可靠太多。AI 會主動列出邊界案例讓你校對，這是它最有用的功能之一。

指令 3 · 階段 3 Claude Code

讓 Claude Code 自己審查指令是否完整

把分類規則整合成完整指令後，別急著開始寫程式。請 Claude Code 用「審稿者」角度檢查指令是否充分完整、無遺漏，並建議要放成什麼形式（CLAUDE.md、skill.md 還是規格文件）。

根據你對我資料的了解，我寫了一份你的任務指令，請協助： 1. 審核內容是否足夠充分完整無遺漏。 2. 是適合做成一份 claude.md 放資料夾，還是做成 skill.md，我不太懂這些差別。 [貼上完整指令]

Claude Code 把使用者的指令改寫成五要素結構，並開始撰寫完整 GAS 程式碼 — **Claude Code 的回應**：把使用者的指令改寫為「資深 Google Cloud 解決方案架構師與 GAS 開發專家（角色）+ 建置醫院顧客滿意度 AI 自動化分類、通知與統計分析系統（主題）+ 建置與部署指南（任務 & 對象）」，接著直接給完整 GAS 程式碼

Claude Code 內容審核產出 7 個缺口建議 — **Claude Code 的審核結果**：列出 7 個指令中缺漏的細節（API 金鑰怎麼藏起來，API 金鑰是呼叫 AI 服務的密鑰，等同密碼，外洩後別人會用你的帳號計費或濫用；AI 跑錯時怎麼處理、太多人同時用怎麼辦、歷史資料怎麼引用、輸出格式長什麼樣等），建議補齊

Claude Code 回答 CLAUDE.md 與 skill.md 的差異，建議用 SPEC.md — **三種文件的差別**：Claude Code 解釋 `CLAUDE.md`（給 AI 看的長期記憶）、`skill.md`（給 AI 帶工具書）、`SPEC.md`（規格書）三者差別，建議這個案例用「規格書 `SPEC.md`」比較合適

關鍵心法：讓 Claude Code 在寫程式前先審指令。它會主動列出你沒想到的缺口（權限、出錯怎麼辦、輸出格式），補完再開始寫程式可省下大量返工時間。

指令 4 · 階段 4 Claude Code

把規格書一次餵給 Claude Code 寫程式

審核完畢、指令凍結後，把規格書（SPEC.md）整份丟給 Claude Code，讓它一次寫完 Google Apps Script 程式 + 部署說明書。指令中指定的 gemini-2.5-flash 是 Google 一個輕量快速的 Gemini 模型版本，分類任務不需用到旗艦模型，flash 已綽綽有餘且省額度。

請依附上的 SPEC.md（已凍結）實作一套 Google Apps Script 系統。技術要求： - 觸發：Google Form 提交時自動執行 - 處理：呼叫 Gemini（模型用 gemini-2.5-flash）依規格書規則分類 - 寫回：把分類結果（類別、急迫性、重要性、判定理由、處理狀態、首次時間戳記）寫回原試算表 - 多分頁：自動建立「月報-類別」「月報-急迫性」「待辦清單」三個分析分頁 - 通知：急迫性 P0 + 重要性高的案件自動 email 通知值班主管 - 錯誤處理：Gemini 跑錯時記錄到「處理狀態」欄位，標記重試，最多 3 次請給我： 1. 完整 .gs 程式碼，功能分塊寫（表單提交 / 呼叫 Gemini / 寫回 Sheets / 寄通知 / 更新月報） 2. 部署說明書（取得 Gemini 金鑰、貼程式碼、設定何時自動執行、按授權鈕） 3. 設定參數說明（收件人 email、Gemini 金鑰存放位置等）

Claude Code 產出的 README.md，含 Step 1 取得 Gemini API 金鑰、Step 2 打開 Apps Script、Step 3 建立 gs 檔等部署步驟 — **Claude Code 產出的部署 README**：依步驟操作即可上線，每步都有具體操作指令（網址、按鈕位置、貼上的程式碼）

關鍵心法：SPEC 凍結後再實作，Claude Code 不會偏題；明確要求「分模組」「附 README」「附參數說明」，產出的程式可立即上線且日後好維護。

指令 5 · 上線後維護

把分類結果開放回原試算表審視

上線後要人工抽樣校對 AI 分類品質。把判定理由、處理狀態、重試次數等過程資料都寫回原試算表，方便每天打開就能檢視。

在 Sheets 加入下列欄位，讓我能即時看到 AI 的判定結果： - 類別 1 / 類別 2 / 類別 3（可同時涵蓋兩個主類） - 急迫性（P0 / P1 / P2 / P3） - 重要性（高 / 中 / 低） - 判定理由（50 字內，寫出 AI 依據什麼下這個判斷） - 處理狀態（等待中 / 已完成 / 重試 / 失敗） - 重試次數 - 首次時間戳記 - 清洗後內容（若原內容需要清洗，把清洗後版本記錄這裡）讓我每天打開 Sheets 就能抽樣校對。如果 AI 判定錯誤，我可以在原表上手動修改，作為下次精修指令的參考。

關鍵心法：AI 系統上線後不是「裝完就忘」，要把判定依據寫回原表，方便人工抽樣校對。發現 AI 判錯的案件累積成「邊界案例集」（也就是「不確定該歸哪類」的案例），定期回頭修指令，系統才會越用越準。

4

成品 Demo：從每天 N 封通知變成 P0 警示

系統上線後，信箱再也不會被「有 1 則新回覆」通知淹沒。只有 P0 即時案件 + 高重要性案件 才會發 email 警示，其他案件自動進待辦清單。

自動警示 Email

Email 標題『[External] [P0+高] 門診滿意度警示：病人反映公廁有異味、不潔及老鼠尿，涉及病安與感染風險』，內含判定理由、類別、急迫性、重要性、填寫時間、病人原始回饋，並附完整資料連結 — **實際收到的警示信**：標題就標明 [P0+高] 與案件摘要，點開可看完整判定理由、類別代碼、處理 SLA（24 小時內），不用再去翻試算表

試算表多分頁自動更新

試算表底部有多個分頁：表單回應 1、月報-類別、月報-急迫性、待辦清單；待辦清單列出 P0 案件含判定理由、類別、急迫性、重要性、原列號 — **待辦清單分頁**：P0 案件自動進這裡，含判定理由（50 字摘要）、類別、急迫性、重要性、首次時間戳記、原列號（回原表查更多細節）

原試算表新增多欄：類別 1/2/3、急迫性、重要性、判定理由、處理狀態、重試次數、首次時間戳記、清洗後內容 — **原試算表新欄位**：每筆回應自動多出 8 - 10 欄，包含類別、急迫性、重要性、判定理由、處理狀態（等待中 / 已完成 / 重試）等，可隨時人工校對

為什麼這個架構適合醫療場景

① 資料留在自己 Google 帳號內：Google Apps Script 與 Sheets 都在使用者自己的 Google 帳號裡，Gemini 的呼叫也是由使用者帳號發出，過院內資安審查的成本最低；② 分類規則可校對：判定理由與重試次數都寫回原表，出錯時人工能立刻定位；③ 免費：Google Apps Script 免費、Gemini 免費額度每分鐘 15 次、每天 1500 次，小醫院綽綽有餘；④ 可分享但各自獨立：同事拷貝這套系統到他自己的 Google 帳號就能用，資料各自獨立、互不干擾。

5

給其他人的提醒：從這次協作學到什麼

把這次建置的關鍵心得整理成 5 條，給想做類似專案的讀者參考。即使你不是醫療同仁，同樣的方法論也適用於：學校行政意見箱、社團活動回饋、研究室問卷分析、客戶 NPS 分流。

寫指令前先過「五要素框架」。角色 / 做什麼 / 給誰用 / 主題範圍 / 依據資料五個面向想清楚，後續指令日後要改也容易。沒過框架直接寫，結果通常東一塊西一塊，改起來費力。

分類規則要用過去的資料訓練，不要憑空想。把過去 N 個月的回應丟給 AI 先分類，人工校對後再回頭修分類表。Claude Code 會主動列出「不確定該歸哪類」的案例，這正是「規則漏洞」最容易出現的地方。

寫程式前讓 Claude Code 自己審指令。它會主動列出你沒想到的缺口（金鑰怎麼藏，即上一節提到的 API 金鑰；出錯怎麼辦、輸出格式長什麼樣），補完再開始寫程式可省下大量返工。

把 AI 判定過程都寫回原表。判定理由、處理狀態、重試次數都列在原試算表上，方便每天抽樣校對。發現判錯的案件累積成「邊界案例集」，定期回頭修指令，系統會越用越準。

通知設計要「分級」，不要「全發」。只有最緊急（P0）+ 最重要的案件才發 email，其他進待辦清單就好。這個原則套到任何自動化系統都通用：讓使用者看到的應該是「需要立即動作的」，而不是「全部」。

這個案例在課程中的位置

本案例延伸第 10 章「資料庫循環系統」，完整體現 §2 的 INPUT → PROCESS → STORE 三步循環。建議讀完第 10 章 §1-§3（工具堆疊）後，回來看這個案例，會更能理解「為什麼選 Apps Script + Sheets + Gemini API 這個組合」「為什麼 SPEC 要寫清楚再進實作」這些原則的價值。