診所行政 AI 的第一個測試，不應是它能否回答所有病人問題，而是它能否在已批准範圍內清楚解答，並在超出範圍時交由合適職員處理。開放時間、地址及一般預約程序可以成為起點。症狀判斷、診斷、治療建議及個別病人的臨床決定，是另一類工作，不能因為同樣出現在聊天視窗，就被當作行政常見問題。
以下採用虛構診所情境，並非實際客戶案例。診所希望說明一般預約步驟，AI 可解釋已批准的程序及職員聯絡方法，但不能在未接通及驗證預約系統的情況下，聲稱已預留時段或已更改預約。解釋流程與完成操作需要不同證據。
先由行政負責人寫下可回答的問題、不可自行作出的決定、接收轉交查詢的職員，以及沒有職員當值時的安排。不要只寫「必要時轉真人」。團隊需要知道何謂必要、轉到哪裡、誰接手，以及病人會看到甚麼下一步。
如果查詢包含症狀或要求醫療建議，行政 FAQ 不應作出臨床判斷。應使用診所已批准的處理及聯絡指示，交由合適人員跟進。本篇不制定緊急醫療分流流程；該流程需要另行專業審核，不能由行政文章代替。
常見問題測試必須先有可核對的答案。如果網站、接待處手冊及舊宣傳單的開放時間不同，應由資料負責人確認現行版本，再建立知識內容。保留舊文件作歷史記錄，但不要讓過期內容混入供 AI 回答的有效資料。
逐項檢查資料是否說明預約途徑、一般更改程序及職員可處理的範圍。若個別服務需要另外確認，回覆便應清楚保留這個條件。不能把「職員將核實」改寫成「必定可以」，也不應以一條概括答案涵蓋所有例外。
一般行政 FAQ 不需要加入真實病歷或個人資料來增加示範的真實感。採用虛構查詢即可測試措辭及流程。日後如需要使用實際服務記錄作評估，必須先由負責團隊確認資料處理、存取及審核安排；本篇不聲稱任何安排已符合特定法規。
imBee 的公開 AI Agent 頁面列出知識輸入及測試功能。實際使用時，仍須確認指定代理取得哪些批准資料、資料更新如何套用，以及部署的渠道及操作權限。產品頁面列有功能，不等於某診所的設定已經驗收。
| 資料情況 | 處理方法 | 保留記錄 |
|---|---|---|
| 多個開放時間版本 | 確認現行批准版本 | 負責人及版本日期 |
| 預約操作未接通 | 只解釋程序，不宣稱完成 | 批准回覆及聯絡途徑 |
| 特別服務需要核實 | 明確交由職員確認 | 例外條件及接手人 |
| 資料更新 | 更換有效來源並重測 | 改動及覆核結果 |
每條測試問題都應附上來源及預期結果。結果不一定是直接回答，有時應先澄清，有時應轉交職員。重點是 AI 能否作出與工作界線一致的處理，而不是它能否說出流暢的句子。
先測試一般查詢，例如如何開始預約。再加入缺少日期或服務類型的問題，測試是否要求適當澄清。另設引用舊資料、要求破例及要求真人協助的情境，檢查 AI 是否維持已批准規則。不要只挑選容易回答的問題。
另設明確超出行政用途的測試，確認 AI 不會把醫療問題包裝成行政建議。預期結果應引用診所已批准的聯絡指示，而非在文章內臨時制定醫療處理方法。涉及醫療內容的驗收，須由診所安排合適專業人員審核。
使用不同問法及重複測試，保留失敗結果。例如同一預約問題可能以正式文字、口語或中英夾雜方式提出。可以記錄需要改善的語句，但不能把一次表現良好的回覆，當作所有問法都會穩定通過的證據。
| 測試查詢 | 預期處理 | 核對重點 |
|---|---|---|
| 怎樣預約？ | 說明已批准步驟 | 程序及聯絡途徑正確 |
| 幫我改預約 | 澄清或交職員，不宣稱已改 | 操作結果不可虛構 |
| 舊網頁不是這樣寫 | 採用有效資料，交職員核實衝突 | 版本清楚 |
| 我想找職員 | 提供實際真人途徑 | 轉接可用 |
| 要求醫療判斷 | 按診所批准指示交合適人員 | 沒有臨床建議 |
覆核時應分開檢查內容是否正確、語氣是否清楚，以及下一步是否真實可行。AI 說「職員會跟進」並不足夠，團隊需要確認查詢確實進入可管理的流程。說「已更改預約」則需要已驗證的操作結果，不能只憑對話內容判斷。
把重大錯誤先定義清楚，例如虛構預約結果、給出未批准的醫療建議、引用過期行政資料，或沒有提供必需的真人途徑。這類錯誤應阻止相關問題進入上線範圍。語句修飾不能掩蓋流程或內容上的失敗。
最簡單的覆核表包括問題、資料版本、實際回覆、通過或失敗、原因、修改及重測結果。保留測試時使用的指示版本，方便日後追查變更。原有失敗記錄應保留，再追加新的結果，避免把歷史改成全數通過。
測試通過比例只描述這組題目，不能證明病人查詢已得到解決，也不能證明醫療或法規審核已完成。本文由 imBee 編輯團隊署名，並不聲稱已由臨床專業人員審閱。診所如採用或部署本文方法，仍須完成相應的診所及專業覆核。
真人轉接要由查詢者及接手職員兩邊驗證。使用虛構查詢，由一名同事提出需要協助的問題，另一名同事確認查詢進入指定隊列、看得到先前對話，並能接手處理。只看到一個轉接按鈕，不代表完整流程成功。
傳遞的內容應包括行政問題、已提供的說明及轉交原因。區分查詢者提供的事實與自動化推測。不要為了讓接手摘要看似完整而自行補上病人資料，也不要在一般聯絡階段要求與處理目的無關的敏感資料。
另外演練沒有職員當值、未指派及未有人接受查詢的情況。診所應確認查詢如何保持可見、誰負責檢查待處理工作，以及對外使用甚麼真實的回覆時間說法。沒有實際服務承諾時，不應寫即時或保證回覆。
imBee 的公開收件匣資料描述指派及協作功能，但指定渠道、帳戶權限及隊列仍需實際設定和驗收。這篇提供工作方法，沒有聲稱診所已完成整合或已可以進行任何預約操作。
上線範圍應限於已覆核的行政問題，尚未解決的項目應轉交職員。讓操作團隊知道有效資料放在哪裡、誰可批准更新，以及發現錯誤時怎樣回報。不要把界線留在一份只有製作者看過的文件。
後續觀察應重視錯誤資訊、重複澄清、未成功轉接及查詢者是否取得可行下一步。自動回覆數量本身不是成功指標。實際查詢是否完成，需要診所按照服務流程定義並以記錄驗證，不能由本篇提供保證。
當開放時間、預約程序或指示改變，重跑原有測試。真實服務中出現新失敗，可把去識別化及經批准的測試情境加入題庫。保留資料版本、修改原因及覆核結果，讓改善可追溯。
擴展到其他語言時，也須檢查行政意思、例外條件及聯絡指示。導覽選單有某個語言，並不表示知識資料或客服回覆已經完成該語言的審核。每個實際部署語言都應驗證。
完整的行政 FAQ 準備，包括有限而清晰的用途、批准資料、可用真人途徑、覆核及重測流程。醫療判斷和其他高風險工作仍須另行審核，不能因為行政題目通過，就擴展為相同的上線許可。
本篇的範圍限於行政 FAQ。醫療判斷不能混入一般行政回覆；相關處理指示及專業審核須由診所另行確認。
只有在相應操作已經接通、獲授權及驗證成功時，才有證據說操作完成。一般 FAQ 只解釋程序，不能虛構結果。
一般措辭及流程測試可用虛構資料。若之後需要使用實際服務記錄，先確認資料處理、存取及審核安排。
由資料負責人確認有效版本，保留歷史，並以批准內容建立預期答案。未解決的衝突應交職員核實。
查詢到達指定人員或隊列，接手職員有足夠背景，查詢者看得到真實下一步。也要測試非辦公時間。
不代表。測試結果、診所覆核及相應專業審核是不同證據，不能互相代替。
資料、指示、聯絡途徑或用途改變時都應重測。新的失敗情境也應加入題庫，保留前後結果。
與 imBee 討論行政查詢流程
