AI 伴侶的記憶應該可供編輯嗎？專案細節的實用修正流程

為什麼日常專案記憶需要修正控制項

記憶能藉由延續偏好或專案脈絡，使進行中的對話更加實用，讓使用者無需反覆提及。目前的產品文件將記憶描述為個人化設定的來源，同時也承認它可能無法保留所有細節，或者可能會記錯細節。OpenAI 的記憶指南說明，記住的資訊可能來自不同來源，且可用的控制項也有所不同。Google 的 Gemini 記憶指南同樣指出，記憶可以為專案建議提供參考，並引導使用者直接在聊天中修正 Gemini。

當系統將過去的可能性視為已定案的計畫時，一個小小的錯誤就可能演變成反覆出現的困擾。想像有人在討論週末的木工專案：他們曾考慮使用雪松，但後來選擇了樺木。如果伴侶隨後建議雪松飾面，彷彿該選擇已成定案，問題不在於系統記住了這段對話，而是在於使用者需要一種方式來檢視記住的主張、進行修改，並查看修改後的內容是否被採用。

這是一項設計建議，而非聲稱每款對話型產品都已提供相同的控制功能。微軟的人機互動指南將高效率的修正、系統行為的解釋以及傳達使用者操作的後果列為獨立的設計考量。應用於記憶功能時，這些原則表明修正應該簡單易行，且其實際效果應容易驗證。微軟研究院的人機互動指南

使用者應該能夠檢視哪些內容

一個實用的記憶檢視介面應該用日常語言呈現各項主張：「針對桌上收納盒，你選擇了樺木」，或「你正在考慮製作一個關於街區招牌的系列攝影」。介面應避免將不確定的語氣轉化為確定事實。在可顯示底層對話的地方，來源連結或簡短的上下文預覽可以幫助使用者判斷摘要是否準確。記憶檢視介面還應明確指出，它可能只是選擇性的摘要而非完整記錄；OpenAI 的文件明確指出其記憶摘要是高層級的概述，並表示它可能不會顯示所有細節或來源。

對於每個項目，應以使用者能理解的方式顯示其狀態：已儲存並可用於未來的個人化設定、待確認、已修正或已停止使用。這些標籤是一種建議的介面模式。其基本原則得到微軟指南的支援，即解釋系統採取行動的原因，並傳達使用者的操作將如何影響未來的行為。這不需要公開內部模型的運作機制，只需要提供足夠的資訊讓使用者回答：「你記住了什麼？如果我編輯它，會有什麼改變？」

五步驟修正流程

實用的修正流程可以從出現錯誤的地方開始。如果助理說：「既然下個月要向藝廊投稿……」，使用者應該能夠在該回覆旁開啟促成該記憶的來源或選擇修正操作。記憶解釋應指出相關的主張，但不能暗示助理完全掌握其輸出背後的每一個原因。目前的 OpenAI 記憶控制項可能會顯示促成個人化設定的來源，同時指出這些來源可能無法展現所有影響因素。OpenAI 記憶來源與修正指南

接著，使用者選擇最小幅度的有用操作：編輯主張、刪除它，或將其標記為不確定。編輯操作可能會將「將系列作品投稿至藝廊」改為「考慮是否將系列作品投稿」。當完全不再需要該細節時，刪除操作是合適的。標記為不確定則可以在不將初步想法提升為堅定承諾的情況下，保留有用的脈絡。該「不確定」選項僅為設計建議；除非在特定產品中得到驗證，否則不應將其宣稱為該產品的功能。

在儲存之前，應顯示修改後的確切文字，並在編輯改變了原意或可能大幅重塑後續建議時要求確認。小幅度的拼字修正可能不需要單獨的確認步驟；但將確定計畫替換為未定案的可能性時可能就需要。這種區分是從修正與消除歧義的指南中推導出來的：微軟建議讓修正變得容易，並在系統對使用者目標不確定時與使用者互動。確認機制應該保護使用者的意圖，而不是為每次例行編輯增加阻礙。

確認後，顯示一個簡明的結果，例如：「已更新。在未來的專案對話中，我會將藝廊投稿視為尚未定案。」如果使用者刪除了該項目，請說明它已從現用記憶中移除，並清楚說明該產品的實際影響範圍。除非已知屬實，否則不要聲稱所有痕跡都已完全消失。現有系統說明了為什麼精確性很重要：OpenAI 解釋說已儲存的記憶及其原始聊天內容可以分開儲存，而 Gemini 的指南則指出可以在聊天中修正記住的細節，且刪除相關聊天記錄可能需要短暫時間才能影響個人化設定。這些特定產品的行為不應被泛化為放之四海皆準的刪除承諾。OpenAI 記憶指南與 Gemini 記憶指南

最後，讓使用者在自然的後續對話中測試這項變更。他們可能會詢問收納盒的飾面構想。如果助理使用了樺木，使用者就獲得了修正已影響後續重用的具體訊號。如果它再次提到雪松，請提供返回該記憶項目的途徑，或標記不相符之處的方法。重要的設計選擇是讓記憶的重用具備可觀察性，同時避免向使用者保證一次成功的回覆就代表系統永遠不會再犯同樣的錯誤。

何時編輯、刪除或確認

當記住的想法仍然有用但其文字或細節有誤時，請使用編輯：「層架寬 80 公分」，修正為「層架寬 90 公分」。當該項目不再用於引導未來回覆時，請使用刪除——例如已放棄的專案偏好。當提議的記憶模稜兩可，或者某個變更可能將探索性意見轉化為決定時，請使用確認。清晰的介面應明確區分這些操作，而不是將「不要提那個」與「移除記憶」等同視之。OpenAI 的文件也有類似的區分：要求系統不要提及某事會改變個人化行為，但本身並不會刪除底層來源。

介面也可以針對價值取決於當下情境的細節提供「不確定」或「下次再問我」。例如，某人平時可能偏好簡短的圖說，但針對特定作品集頁面則希望有較長的描述。這是一種保持彈性的建議方法，而非經過驗證的功能聲明。指導性問題在於：該記憶是表達了穩定的偏好、暫時的選擇，還是應該保持開放的可能性？

旨在實現從容、高可用性的互動

讓修正控制項靠近它所影響的記憶或回覆。使用熟悉的字詞，例如「編輯」、「刪除」和「確認」，避免讓使用者撰寫特殊的提示詞來修復常規的事實錯誤。微軟的指南明確要求高效率的修正和精細的反饋。蘋果當前的生成式 AI 設計指南也建議簡化微調或還原操作，並在使用者調整生效時發出提示訊號。蘋果生成式 AI 人機介面指南

對於重大編輯，提供簡潔的修改前後對比檢視。不要在背景靜默合併衝突版本，或用推斷的偏好取代使用者的修正。如果使用者說：「我這個收納盒選擇了樺木，但我戶外專案還是喜歡雪松」，請保留這兩種主張的適用範圍，而不是將其簡化為普遍的木材偏好。這是一種設計推論：微軟建議在不明確時限制服務範圍，其關於審慎更新的指南也支援避免隨著時間推移產生破壞性的變更。

輕量級的變更歷史記錄可以幫助人們從意外編輯中復原，特別是針對他們可能想要還原的專案事實。但歷史記錄應該易於理解且在使用者的控制之下。如果介面提供復原功能，請說明它會還原什麼，以及還原的主張是否會再次生效。蘋果的指南特別指出復原和清晰的回饋是微調生成結果的實用模式；將該模式應用於記憶編輯是一種合理的延伸，而非聲稱該指南規定了特定的記憶歷史記錄功能。

如何判斷該流程是否有效

使用日常專案場景和可觀察的任務來評估流程。在回覆中出現錯誤細節後，使用者能否找到它？他們能否將「已決定」更改為「考慮中」，確認更新後的文字，並了解系統接下來將使用什麼資訊？他們能否移除過時的選擇，而不會將該操作與要求助理暫時不要提及它混淆？這些是針對提議設計的測試問題，而非已報告的測試結果。

有效的檢驗可以追蹤使用者是否完成了這些任務、他們是否理解編輯和刪除之間的差異，以及修正後的細節是否反映在後續的相關回覆中。它還應檢查失敗路徑：找不到細節、兩條記憶衝突、修正尚未反映，或使用者在儲存前取消。在這些情況下，介面應承認當前狀態並提供明確的下一步，而不是在無法驗證變更時顯示「已修正」。這遵循了提高修正效率和傳達操作後果的指南；這些指標本身僅為建議。

讓記憶可修正，並讓修正結果清晰可見

AI 伴侶的記憶應該是可編輯的，因為日常專案的細節會改變，且記住的摘要可能不完整或有誤。健全的修正流程能讓使用者檢視特定主張、編輯或刪除它、在需要時確認含義，並了解變更預期將如何影響未來的個人化設定。這種體驗透過對每個操作提供可見且準確的回饋來贏得信任——而不是暗示記憶絕無差錯，或單次修正就能保證日後的每一次回覆都完全正確。

繼續探索這個主題