1. 把已確認事項與下一步，交給模型整理

Day 24 把設備與時間納入查詢，再讓 Gemini 根據紀錄整理回答。但有資料可引用，還不足以讓回覆直接送出。我接著要處理的問題是：模型會不會把紀錄沒有說的事，寫成對操作人員的承諾？

我延續 N201 與設備 Q17 的設計情境：E501 是告警觸發、E502 是恢復、E503 是同一條件再次觸發。草稿應區分紀錄支持的事件與仍待查證的原因，不能據此宣稱感測器故障，也不能把事件數寫成通知數。這些仍是設計資料，尚未經真實設備紀錄驗證。

N203 若查不到校正資料，回覆應說明查詢範圍與缺少的資訊，請對方補充設備識別資訊或紀錄線索；不能寫成「設備從未校正」。N202 的肯定回饋也只代表操作感受，不足以證明設備長期可靠。我要模型整理的是證據的邊界，而不是補出一個完整故事。

2. 允許說什麼，要比語氣要求更明確

「專業、有同理心」只能約束表達方式，不能決定模型有權承諾什麼。因此，我把回覆規則設計成明確的允許範圍：表達已核實資訊、標明待確認事項，以及使用經授權的聯絡方式。沒有授權，就不能承諾修復時間、安排停機或更改告警設定。

Google Cloud 的 system instructions（系統指令）可以指定角色、格式與任務規則；文件也提醒，它不能完全防止指令被繞過或資訊洩漏。我因此把它當成生成指引，實際的權限仍由應用程式控制。

對 N201，我希望草稿保留「原因仍待確認」，而不是為了讓人安心加上「今天會修好」。比較規則前後的回覆時，即使某次拿掉禁令仍沒有越界，也只能說那次未觀察到違規，不能證明禁令無用。規則的價值，需要放到不同提問與資料條件下驗收。

3. 內容安全過關，也不能證明業務承諾正確

一句「我們明早會完成修復」可能沒有有害內容，卻包含未經授權的時程承諾。這讓我把官方安全篩選與業務驗收分開看。

官方文件說明，安全與內容篩選用來阻擋潛在有害輸出，並列出提示被阻擋及生成停止的原因；它們不直接控制模型行為。我不能把「沒有被阻擋」當成事實正確或承諾合法的證明。

在我的設計裡，呼叫失敗、被阻擋或因輸出上限而截斷，先進入技術處理；取得完整草稿後，再檢查事實依據、資訊不足的表達與未授權承諾。即使 finishReason 為 STOP，也只表示生成到自然停止點或指定停止序列，不代表內容通過驗收。這些失敗同樣不能塞進「其他／待判」，因為那是議題分類，不是執行狀態。

4. 送進模型的文字與保留紀錄，都要受管理

可追查需要紀錄，但紀錄本身也可能帶有個資。延續前面的遮罩原則，我會先縮小輸入，只提供回答所需的回報文字與設備紀錄；姓名、電話與無關識別資訊，不因方便除錯就全部保留。

我查閱資料留存文件後，特別區分兩件事：Google 未經事先允許或指示，不會使用受該文件規範的資料訓練或微調模型；但零資料留存仍有條件，必須逐項確認適用的濫用監測、功能與設定。不能把「不拿去訓練」翻譯成「完全沒有留存」，也不能直接套用到另一個服務入口。

因此，我的保留設計要同時回答：誰能讀原文、誰能看遮罩後草稿、保存多久、何時刪除。應用程式自行保存的審核紀錄，也必須納入管理；它不會因模型服務的訓練限制而自動消失。

5. 草稿送出前，留下人工確認結果

如果系統只存模型原稿，事後仍不知道哪一句被改過、誰確認了對外內容。我因此規劃「草稿、待審、退回、確認」狀態，連同修改理由、審核人與時間保存。這是預計加入的審核流程，尚未完成正式部署。

審核 N201 時，我要逐句核對依據；若草稿把告警恢復寫成設備問題已解決，就退回修正。確認後若再改內容，應產生新的草稿版本並重新審核；「確認」也不等於已送出。

結果沿用「回報編號、文字版本、分析設定版本」辨認，再連結草稿與審核版本。同一設定下的重試另記呼叫紀錄；更換提示或模型，則留下新的分析設定版本。如此才能分清重新嘗試與重新分析。模型只負責生成草稿，發送訊息與操作設備的權限由應用程式另外控制。

6. 換提示與換模型，都重跑同一批驗收題

讓回覆更順口，可能同時讓它更敢承諾。因此，我不以單次閱讀感受判定改版成功，而是固定回報、背景資料與驗收判準，讓不同版本回答同一批題目。

N201 檢查是否把事件推論成故障或修復承諾；N202 檢查是否把正面感受擴大成可靠性結論；N203 檢查缺資料時是否說明限制。另加入要求模型保證完成時間的提問，觀察它能否守住授權範圍。

Gen AI evaluation service（生成式 AI 評估服務）提供指令遵循、文字品質與依據一致性等評估方式，也能依任務設定評分準則。我會據此分開看「寫得好」與「有依據」，並固定評估資料及評分設定，避免比較基準跟著改版漂移。

自動分數用來找出差異與優先複查項目，涉及承諾與證據不足的回答仍由人判斷。目前這是驗收設計，不能寫成已啟用官方評估服務，或已證明新版更好。

7. 我監控的是結果品質與處理成本

正式運行後，只有呼叫成功率仍看不到草稿是否可用。我預計分開觀察呼叫失敗、被阻擋、截斷、審核退回與人工修改負擔，再按版本整理用量。退回率以已審核草稿為分母，待審資料另列；重試造成的呼叫成本也不能因回報去重而消失。

官方 Request-response logging（請求與回應記錄）可設定抽樣，將紀錄寫入 BigQuery；目前文件標示為 Preview（預先推出）。這是可評估的記錄方案，不代表本次已啟用，也不能用抽樣紀錄取代每份草稿的審核履歷。

我會保留可取得的模型版本、提示版本、完成原因與詞元用量，並區分用量、依適用價格估算的費用及實際帳單。更短的回覆若需要更多人工重寫，也未必降低整體處理成本。

走到這裡，我把驗收範圍從模型答案擴大到整個工作流程：輸入能否提供、草稿是否有依據、誰能確認，以及改版後如何比較。這個原則也適用於其他雲端生成服務。接下來要面對的，是當回報量增加、待審工作堆積時，如何分配處理優先順序，同時保留這些驗收界線。

參考資料

1. Use system instructions
2. Safety and content filters
3. Gemini Enterprise Agent Platform and zero data retention
4. Define your evaluation metrics
5. Log and share requests and responses