你的AI助手已經忘記了你告訴它的一半內容

本文是AI驅動開發系列文章的第七篇。在上一篇文章中，我討論了上下文及其管理，並承諾提供一些實用的技巧。最初，這篇文章旨在介紹我在構建Octobatch和Quality Playbook（兩個開源專案）時使用的具體上下文管理技術——在這些專案中，我與AI協作規劃並編排所有工作，每一行程式碼都由Claude Code和Cursor等AI工具編寫。但在撰寫過程中，我發現自己將這些技術應用到了編寫文章的工作中，這讓我感到驚訝！

我一直在努力尋找幫助AI開發者改進上下文管理的方法，以使他們的技能執行更高效。結果發現，同樣的技術也適用於任何使用AI工具的人，即使你使用的是像Claude.ai或ChatGPT這樣的聊天機器人。

完全披露：我使用多種AI工具來管理這個系列文章。我的主要工具是Claude Cowork（用於頭腦風暴和管理文章研究、筆記和待辦事項）以及Gemini的移動應用（用於朗讀草稿並在離開辦公桌時做筆記）。我想告訴你我在使用這些工具時發生的一件事，因為它很好地說明了為什麼上下文管理不僅僅是開發者面臨的問題。

在撰寫本文時，我使用Gemini的移動應用朗讀草稿並做筆記。在會話中途，我要求它回去檢查是否有未納入的早期筆記。它告訴我無法訪問之前的筆記，這看起來既奇怪又不可思議，因為那些筆記是在會話中前幾個提示中剛剛記錄的。我可以向上滾動並在之前的對話中看到它們，但不知何故它卻“不知道”它們。

原來，Gemini在不告知我的情況下壓縮了對話，而會話前半部分的筆記就這樣……消失了。如果你曾經遇到過網頁聊天AI似乎忘記了你早些時候談論的內容，那麼你就像我一樣經歷了上下文壓縮。即使只瞭解上下文和上下文視窗的基本知識，也能大大有助於防止這種挫折感。

這一切讓我想起了二十多年前在《應用軟體專案管理》（2005年）中寫下的內容：“在討論過程中發現的重要資訊，團隊在開發過程中需要回頭參考，如果這些資訊沒有被記錄下來，團隊將不得不重新進行討論。”我和Jenny Greene當時是針對人類團隊和專案會議寫的這段話，但它同樣適用於AI會話。

這讓我回到了上下文的話題——我在上一篇文章中寫到了它，並將在下一篇中繼續深入，因為它是與AI合作時最重要的概念之一。

**上下文丟失可能是無形的，但這並不意味著它不那麼令人沮喪**

上下文是AI在對話期間持有的所有工作記憶：你告訴它的內容、它告訴你的內容、它讀取的任何檔案或指令，以及系統沿途所做的任何內部筆記。所有這些都存在於一個固定大小的上下文視窗中——可以將其視為AI的短期記憶，即它當前正在思考的內容——當視窗填滿時，AI不得不開始捨棄一些東西。不同的工具處理方式不同：有些截斷較舊的訊息，有些將對話壓縮為摘要（這意味著即使摘要看起來完整，細節也會丟失），有些則開始表現不一致，以至於你無法判斷AI是忘記了某件事還是從一開始就未能理解。結果是一樣的：AI會丟失你告訴它的內容、你們共同做出的決定或它在會話早期注意到的細節。而且它不會告訴你它忘記了。它只會基於仍然保留的內容繼續生成看似自信的輸出。

在深入探討之前，我想快速澄清一些術語。如果你看到“技能”和“代理”這些術語但不確定它們是什麼，可以將技能視為AI的庫，將代理視為可互動的執行檔。這些定義並不完全精確，但如果你是一位開發者，它們足以用於本文的討論。

當你編寫技能和代理時，會很快遇到上下文問題。你要求AI完成的工作通常足夠複雜，以至於上下文視窗很快填滿，AI不得不開始壓縮：壓縮或丟棄對話的較舊部分，以給新內容騰出空間。壓縮似乎總是在最令人沮喪和最不合時宜的時候發生——想想也是，當你剛剛投入最多資訊時，卻恰恰達到了上下文限制，此時丟失資訊的代價最高。

這就是為什麼我認為將AI視為具有與人類團隊相同的缺點，但因其AI特性而被放大，通常會有所幫助。一個人忘記了上週會議中的某件事，在你提醒時可能會想起來。但一個因上下文壓縮而丟失資訊的AI則不會，因為資訊已經消失。不過，你可以採取措施，而且事實證明，無論你是在構建自主AI技能，還是僅僅試圖讓聊天機器人記住你20分鐘前告訴它的內容，這些技巧同樣有效。

我總結了自己反覆使用的四種技巧。每一種技巧的存在都是因為在某個時候AI忘記了重要資訊，而我透過將該資訊放入一個檔案來應對，這樣它就不會被遺忘。這些技巧都不需要特殊工具。令我驚訝的是，所有這些技巧對於構建軟體和管理像本文這樣的寫作專案都同樣有用，無論我是與Claude、ChatGPT、Gemini聊天，還是使用像Claude Cowork或Codex這樣的桌面工具。以下是我認為最有價值的技巧：

1. **將探索與文件編寫分離**：不要要求AI在同一輪次中同時完成“弄清楚某件事”和“生成格式化的輸出”。

1. **使用交接文件，而非延續提示**：在關閉舊會話之前，讓AI寫下下一個會話需要知道的一切。

1. **給AI設定驗收標準，而非具體步驟**：告訴它“完成”的狀態是什麼，而不是詳細說明執行步驟。

1. **使用規範文件作為AI工具之間的橋樑**：建立一個共享文件作為所有工具讀取的單一事實來源。

**將探索與文件編寫分離**

當你要求AI完成複雜任務時，你往往在不知不覺中要求它同時做兩件事：既要弄清楚某件事，又要生成格式化的輸出。問題在於，弄清楚事情需要注意力，生成輸出也需要注意力，而模型的注意力有限。當你在同一個提示中將這兩個任務結合起來時，模型會開始在其中一個任務上偷工減料，而且你無法判斷它忽略了哪一個。

我在構建Quality Playbook（一個開源的AI編碼技能，用於對任何程式碼庫進行結構化程式碼審查）時遇到了這個問題。它的功能之一是從原始碼中推匯出需求：它讀取程式碼，識別程式碼承諾要完成的內容（我稱之為行為契約），然後生成一個需求文件。最初，這一切都在一次遍歷中完成。問題是，單次遍歷的需求生成在大約70個需求後就用盡了注意力。模型忘記了之前在程式碼中注意到的行為契約，而且這種遺忘完全不可見。沒有堆疊跟蹤或錯誤資訊，只有不完整的輸出，而且無法知道遺漏了什麼。我透過將工作分解為兩個獨立的提示來解決這個問題：

• 讀取每個原始檔，並將你觀察到的每個行為契約以簡單列表形式寫入CONTRACTS.md。
• 讀取CONTRACTS.md和文件，然後從它們推匯出需求並寫入REQUIREMENTS.md。

然後進行第三次檢查，確保每個契約都有對應的需求，如果有缺口，則對有缺口的檔案返回第一步。關鍵是，CONTRACTS.md是外部儲存器。當模型“忘記”它之前注意到的某個行為契約時，這種遺忘通常是不可見的。但有了契約檔案，每個觀察結果都在需求工作開始前被記錄下來，因此未覆蓋的契約是一個可見的、可搜尋的缺口。你可以看到被遺忘的內容並進行修復。

原則：不要要求AI在同一個遍歷中同時確定存在什麼並編寫格式化的輸出。模型試圖同時做這兩件事時會耗盡注意力。每當你要求AI完成複雜任務時，考慮一下你是否實際上要求它同時做兩件事。“分析這個程式碼庫並寫一份報告”是兩項任務。“閱讀這份文件並提出改進建議”是兩項任務。將它們分開，讓第一次遍歷將其觀察結果寫入檔案，然後第二次遍歷再開始處理它們。

**使用交接文件，而非延續提示**

任何經歷過長時間AI編碼會話的人都曾感受到上下文開始變得陳舊的那一刻。AI不再追蹤一小時內還能很好處理的細節，或者它之前說過的話自相矛盾。會話變得緩慢，你常常不得不重新開始，因為AI似乎陷入了困境，填滿了你告訴它的內容。你感覺如果繼續下去，你會花費更多時間糾正它而不是取得進展。

大多數開發者對於會話過長有兩種反應：要麼硬著頭皮繼續，要麼開啟新會話並嘗試從頭重新解釋一切。這兩種方法都可能導致AI丟失上下文：第一種透過壓縮丟失，第二種透過不完整的重新解釋丟失。兩者都令人沮喪！特別是因為你剛剛花了這麼多時間與AI建立所有上下文。

還有第三種選擇。在關閉會話之前，要求AI編寫一份交接文件：一個檔案，捕獲下一個會話需要知道的所有資訊，並且是在當前會話仍擁有完整上下文時編寫的。關鍵是在相關細節仍在工作上下文中時要求AI編寫這份文件，並且以它可以被自身或其他AI讀取的方式編寫。

我在Quality Playbook中將此構建為各階段通訊的核心部分。當我把Playbook從單個提示拆分為獨立階段時，我需要每個階段作為完全獨立的會話執行，且沒有上下文繼承。因此，每個階段都有自己獨立的啟動提示檔案。每個啟動提示都遵循以下結構：編寫一個交接文件，使新會話能夠冷啟動這項工作，包括需要知道的所有內容。每個啟動提示都以之前階段完成的內容開頭，包括關於哪些內容已凍結的明確邊界，並指明哪一未來階段擁有剩餘工作的每個部分，因為沒有這一點，AI會在你仍處於第二階段時好心地開始做第三階段的工作。每個階段還以一個必需的向前看的交接結束，其中完成任務的代理寫下下一個會話需要知道的內容。

原則：每個交接都是一個完整的狀態快照。進入的AI代理永遠不需要閱讀之前的啟動提示或聊天曆史記錄。它需要的一切都在當前的交接檔案中：當前狀態、未提交的變更等。

（由於文章較長，此處僅呈現核心內容，原文還討論了“給AI設定驗收標準”和“使用規範文件”兩種技巧，以及總結。）