1. 我從 Day 19 的限制，重新定義這次任務

Day 19 我把情緒分類與人工判斷逐則比對，也提醒自己：負面占比不能直接說明設備出了什麼問題。接著，我想讓 Gemini 協助整理回報中的議題，讓人知道下一步該讀哪段文字、確認哪件事。
我沿用三則回報：N201「溫度顯示已恢復，但告警一直重複，值班時很困擾。」N202「更新後操作順暢，交班時更容易確認設備狀態。」N203「請確認這台設備最近一次校正的時間。」這條設備回報流程仍是設計情境，尚未代表真實設備的驗證成果。
這次任務是摘要與議題整理。N201 可以引導人去確認告警，卻不能只憑文字判定感測器故障；N203 可以被整理成校正資訊詢問，也不能因此認定設備沒有校正。我要先把這個界線寫清楚，再請模型回答。

2. 我先固定規則，再送入每則回報

實作主線從 Studio 選擇模型、設定系統指令開始。Google Cloud 的模型清單列出不同模型的能力定位；我會依文字整理需求選擇，並保存實際模型識別碼與可取得的版本資訊，讓之後比較有共同條件。

系統指令可以寫成：

你協助整理設備操作人員的回報。使用繁體中文，只依提供的文字摘要與分類。未提及的設備狀態、時間與故障原因，請標示資訊不足，不要自行補充。

官方文件說明，系統指令可設定角色、格式及任務規則，但不能完全防止模型偏離要求。因此，我會把它當成需要驗收的規則，不把「已經寫進提示」當成「一定做得到」。

每次送入的提示，再放入回報編號、本文與這次任務。若只要摘要，就先驗收摘要；分類則另訂要求。我也會記錄外部搜尋或工具是否啟用，避免同一則文字在不同資料條件下比較。

3. 摘要要保留問題，也要保留回報編號

我會先要求每則產出一句摘要，並保留編號。以 N201 為例，我希望摘要能表達「人員回報溫度顯示恢復，但重複告警仍影響值班」，而不是只剩「設備已恢復正常」。

兩者差在資訊範圍。「溫度顯示已恢復」是原文陳述，沒有證明設備整體正常；「告警一直重複」與「很困擾」則是後續需要處理的線索。摘要若省略它們，文字雖然變短，人工閱讀的方向卻可能被帶偏。

Google Cloud 的提示設計文件將任務、指令與脈絡分開說明，也把反覆修改提示並評估回答視為提示設計的一部分。對這個需求，我會具體要求「保留人員提到的狀態、困擾與待確認事項」，再逐則檢查有沒有遺漏。

若要整理整批重點，每項也要附相關回報編號。不能只給「告警問題較嚴重」這類結論，卻讓人找不到它依據哪些文字。

4. 我把議題名稱和判斷標準一起寫清楚

接著，我會比較自由分類與固定清單的輸出。自由分類可以協助探索文字中有哪些議題；但要累積統計，就需要一致名稱，否則「告警干擾」與「警報問題」可能被算成兩類。

我為這條流程訂出四個選項：

按這份定義，N202 雖然表達肯定，議題仍可整理為操作介面。這也讓我分清兩個問題：情緒分類回答「人員如何表達感受」，議題分類回答「主要談的是什麼」。

N201 同時提到顯示與告警，我會約定以主要困擾或明確請求作為單一議題的選擇依據；仍無法決定時，就留待人工確認。這是我訂的業務規則，不是模型內建的標準。即使提示列出清單，輸出後仍要核對名稱與判斷內容。

5. 理由必須指回原文，資訊不足就留下來

除了議題，我會要求一句簡短理由，以及支持它的原文片段。N201 若整理為告警處理，理由可以指出人員提到重複告警影響值班，片段則引用「告警一直重複，值班時很困擾」。

驗收時，我先確認片段存在於送出的文字，再看它是否支持分類。若理由變成「感測器老化造成誤報」，即使寫得很流暢，也超出了原文。模型提供的理由只是待查證的說明，不能當成故障證據或內部思考紀錄。

官方將 grounding 說明為讓模型輸出連結可驗證的資訊來源，以降低無依據生成的機會。我在這一步借用它的原則，要求摘要與分類回到回報本文；尚未因此啟用搜尋或建立檢索系統。

同樣地，N203 沒有提供校正時間，整理結果就應保留「需要查詢校正紀錄」，不能補出日期。未知資訊留下來，後續人員才知道要補問或查表。

6. 我用不同文字驗收，才決定提示是否改善

N201～N203 可以檢查流程是否符合設計，卻不足以證明提示能處理更多回報。我會另外準備未參與提示調整的文字，例如「畫面比較好用了，但告警聲還是讓人分心」，檢查主要議題的選擇，也確認摘要保留了兩部分。

另一種文字是「這台最近怪怪的，幫我看一下」。它沒有交代明確現象，較適合留待確認，而不是被模型擴寫成溫度異常。

Google Cloud 的評估資料文件要求依任務準備提示與回答，並可加入人工參考答案；也建議資料能代表實際會處理的輸入。我會先用這個方式整理驗收表，不把本篇寫成已啟用官方評估服務。

表中分別記錄議題是否符合定義、摘要是否遺漏重點、原文片段是否正確，以及是否補入無依據內容。調整時盡量一次改一項主要條件，保存提示版本後重跑。分類改善了，仍要確認摘要沒有退步，不能只挑最好的一則回答展示。

7. 下一步，我要把這份任務交給程式

到這裡，我希望留下的成果是能重複使用的任務定義：固定規則、議題清單、判斷方式、輸出欄位與驗收資料。每則結果都能查回送出的文字，也能說明資訊不足時如何處理。

這接回 Day 13 的資料品質要求，也延續 Day 19 對分類可靠性的追問。即使模型能寫出自然的摘要，我仍要知道它保留了什麼、省略了什麼，以及哪些結論有人確認過。

Day 21 再把這份任務搬進程式，處理認證、回應與失敗紀錄。開始批次呼叫之前，我要先能說清楚：什麼回答可以採用，什麼回答需要退回，什麼資訊必須交由人員查證。

參考資料

1. Google models
2. Use system instructions
3. Introduction to prompting
4. Grounding overview
5. Prepare your evaluation dataset