提示歷史就是產品資料

提示歷史有個品牌包裝的問題。它聽起來像是一項便利功能。但它其實是產品資料。

這很重要，因為提示不一定只是像「把天空變粉紅」那種可愛的小指令。它們可能包含客戶姓名、尚未發布的產品、法律情境、醫療脈絡、私密渴望、活動（行銷）策略、個人細節，以及來源圖片的說明。提示甚至可能比生成出來的圖片更具揭露性，因為它會在系統把內容「潤飾」之前，先說出使用者當時想要什麼。

如果產品會儲存提示歷史，就應該把它當作保留的客戶內容來處理。不要當作中繼資料。不要當作遙測（telemetry）。不要叫做「使用情境」（usage context）。這些標籤也許在技術上很方便，但它們不會改變資料所揭露的本質。把提示稱為「中繼資料」並不會讓它不再有能力毀掉某人的一整個下午。

提示歷史也會帶來內部存取的疑問。客服人員能讀嗎？管理員能搜尋嗎？工程師能查詢嗎？會被匯出到分析（analytics）嗎？會出現在儀表板（dashboards）嗎？會出現在電子郵件通知中嗎？如果答案是「會」，那產品就已經把提示納入了作業層面的可見範圍。

有時候，儲存的提示是有用的。創意工具可能需要草稿、可重複使用的配方、重新生成、團隊協作，或稽核軌跡。這沒問題，只要這項功能是刻意設計、而且清楚可見。

問題在於「意外的提示歷史」：因為儲存提示讓除錯更容易，或因為某個框架記錄了請求內容（request bodies），或因為一個快速的 MVP 以那種一貫體面的方式變成了正式上線的產品。

對於私密的影像生成，零提示歷史是一種乾淨的產品立場。它表示系統會處理提示以產出結果，同時在之後只保留不含內容的作業性紀錄。這種取捨會犧牲一些便利性，但也能移除一大類信任焦慮。

開發者應該有意識地做決策。如果會儲存提示，就要說清楚，並圍繞刪除機制來設計。如果不會儲存提示，就要設計佇列、日誌、支援工具與分析，確保它們不會在幕後悄悄地重建提示歷史。

提示歷史不是中立的筆記本。它是客戶意圖的紀錄。

延伸閱讀：不保留提示的私密影像生成、如何看待 AI 影像的零保留，以及 你的資料。