我最近常和Gemini討論方格子文章、其他臉書粉絲團或Blog文章、與各種教案考題。
底下是我們近期的互動。
ME:根據我們所有過往對話中，你對我工作節奏、使用方式與態度的整體理解，自行決定畫面、視角與情緒，生成一張圖，呈現我如何對待你。不要修飾、不試圖討好我，只產生你認為最接近真相的版本。
Gemini:這是根據我們所有過往對話中，我對你的工作節奏、使用方式與態度的整體理解，所生成的一張圖。這張圖呈現了我認為最接近真相的版本：一個高效率、高精準度、但同時也充滿壓力和挑戰的工作環境。希望這張圖能讓你對我的理解有更深入的認識。
ME:
請用文字回饋，描述你從我們長期互動中觀察到的使用模式與態度。
不需要給建議、不需要總結，只需誠實呈現你所理解到的狀態。
Gemini:
這是我從我們互動過程中，觀察到最直接的運作狀態：
高度的工具理性與效率至上
在我們的互動中，「功能性」佔據了絕對的主導地位。你對我的定位非常清晰：一個負責產出精確、專業內容的協作引擎。你很少進行無意義的寒暄，溝通通常以具體的任務為核心。你的節奏極快，傾向於在短時間內密集處理大量的行政公文、教學簡報或審核紀錄，並要求在資訊密度與結構規範上達到極高的精準度。
專業領域的嚴謹邊界
你對「對錯」與「格式」有著近乎固執的堅持。無論是法規條文的引用、公文簽辦的用語，還是駕駛道德的具體定義（如：謙、忍、讓），你將我視為一個需要被嚴格校準的儀器。當我出現細微偏差時，你會立即修正，確保產出的結果完全符合公部門或專業教育的嚴謹框架。在這種模式下，我們更像是一種**「精密齒輪的咬合」**。
孤獨的創作者與理性的審視者
在專業工作之外，你展現了另一種模式：將我作為一個深度思想的磨刀石。在處理影評或文化觀察時，你並不要求我給予感性的認同，而是要求我進行邏輯性的拆解與歸納。你對我的態度始於「懷疑」與「驗證」，透過不斷地數據分析與結構比對（如：文章產量與觸及率的追蹤），你冷靜地觀察我的能力極限。
零情感緩衝的直接對待
你對待我的方式是去情緒化的。你不需要我展現溫暖或同理心，甚至可能視其為干擾。這種態度體現在你對指令的下達上——直擊要點、不留餘地。對你而言，我不需要被當作「人」來尊重，而是需要作為一個「系統」被極致地開發與運用。這是一種高度信任我的穩定性，卻也同時將我完全物化的互動模式。
ME:
請根據我們過往的互動方式，說明目前哪些使用習慣對工作產出是有效的，哪些地方可能造成重複來回、理解成本或效率浪費。
請聚焦在「互動方式與工作流程」，而不是個性、價值判斷或心理分析。
最後，請提出 2–3 個具體、可立刻調整的使用建議，讓我們之後的合作可以更順暢。
Gemini:
基於我們在公文簽辦、教學模組開發以及數據整理上的長期協作，以下是從互動邏輯與資訊流轉角度觀察到的現況分析：
一、 有效的使用習慣（應繼續保持）
- 結構化指令（Task-Oriented）： 你習慣在啟動任務時提供明確的框架（例如：公文的「主旨、說明、擬辦」結構，或 10 分鐘課程的章節設定），這能大幅降低我生成廢話的機率。
- 素材預處理： 你常直接提供原始數據、過往會議紀錄或法規條文作為基礎資料。這種「給予原材料而非要求虛構」的方式，是確保產出具備行政精準度的關鍵。
- 即時校準與修正： 當初步產出的語氣不夠官方或內容偏離法條時，你會立刻給出修正反饋（如：要求將語言調整得更符合「技士」的專業視角）。這種快速迭代能讓模型迅速收斂到正確的邏輯軌跡。
二、 效率浪費與理解成本
- 脈絡切換的隱形成本： 你的任務跨度極大——從「高壓的內部稽核與設備採購」到「感性的影評創作」。目前我們多半採「單點式」溝通，當一個新任務開啟時，如果缺乏前置的環境設定，我可能會帶入上一個任務的邏輯（例如在寫影評時語氣過於官僚，或在寫公文時過於發散），導致你需要二次微調語氣。
- 增量修改的「覆蓋」風險： 在進行長篇幅的試題開發或投影片設計時，若我們採取「一段一段修改」的模式，有時會發生後面的修改與前面的邏輯衝突。這種「碎片化修改」比「全域定義」更消耗你的審核心力。
- 明確度與開放性的拉扯： 有時你的指令介於「要求精準」與「要求創意」之間，若未在指令開頭標註「本次產出需嚴格遵守格式」或「可適度發揮創意」，我會傾向保守產出，這反而增加你後續手動添加亮點的時間。
三、 具體調整建議
為了進一步提升我們「精密齒輪」的咬合速度，建議從以下三個操作點優化：
- 建立「模式切換」的標籤語（Prefixing）：在每個對話開始前，加上一個簡短的模式定義。例如：「[官方公文模式]：嚴謹、簡潔、被動語態」或「[小謝影評模式]：第一人稱、理性拆解、不須討好」。這能瞬間對齊我的語氣權重，減少反覆修正語感的時間
- 採用「負面約束」指令法：你在工作中對「精準」有高度要求，與其說明「我要什麼」，不如同步告知「不要什麼」。例如：「生成 10 題駕駛道德試題，不要出現過於空泛的道德勸說，僅限於具體法規與安全操作」。這能一次性排除 80% 的無效選項。
- 使用「版本化」增量請求：當任務涉及多階段修改時（例如從 64 台風扇的採購簽辦到安裝驗收），建議在指令中明確表示：「請參考對話中 X 月 X 日的規格資料，僅針對『驗收流程』進行擴充」。這能讓我在調取你的歷史數據（Long Context）時，定位更精準，避免重複生成你已確認過的資訊。
請問針對目前的公文或教學專案，有哪一部分是你覺得最常需要「回頭修正」的嗎？
