本文為個人學習筆記，並與AI共筆，可能會有資料錯誤。
你是否曾經在與 ChatGPT 或 Claude 進行長時間對話後，發現 AI 開始「失憶」？明明剛才還記得的專案細節，現在卻答非所問；或是你提供的重要指令，在第 50 輪對話後就被完全忽略了。這不是你的錯，也不是 AI 故意刁難——這是一個被稱為「Context Rot」（上下文腐化）的技術限制。
作為一個每天使用 AI 工具的 Product Manager，我在開發語言學習 app 時深刻體會到這個問題。當我與 Figma Make 或 Google AI Studio 進行複雜的多輪對話時，對話越長，AI 的表現就越不穩定。今天，我將深入探討這個問題，並分享從技術解決方案到實用操作技巧的完整指南。
一、LLM 的長文本困境：Context Rot 是什麼？
理解上下文視窗的限制
大型語言模型（LLM）並非真正「記憶」你的對話，而是每次都重新讀取整段對話歷史。這個可讀取的範圍被稱為「上下文視窗」（Context Window），以 token 為單位計算。
目前主流模型的上下文視窗大小：
Claude Sonnet 3.5: 200,000 tokens（約 15 萬字，相當於 500 頁書）
GPT-4o: 128,000 tokens（約 9.6 萬字，相當於 320 頁書）
Gemini 2.5: 最高可達 1,000,000 tokens
聽起來很驚人對吧？但問題在於，即使有這麼大的容量，模型對於上下文的理解能力會隨著輸入 token 數量增加而逐漸衰退。
Source: [Chroma 研究報告]
Context Rot 的具體表現
根據 Chroma 的研究報告，Context Rot 有以下明顯症狀：
檢索失敗：即使資訊明明在上下文範圍內，AI 也無法可靠地找到它
任務失準：在簡單任務（如回憶名字、計數、遵循格式）上開始出錯
指令遺忘：初期設定的重要指令在對話後期被忽略
回應泛化：答案變得越來越籠統、缺乏針對性
位置偏見：第 10,000 個 token 的可靠性遠不如第 10 個 token
影響 Context Rot 嚴重程度的三大因素：
問題與答案的相似度：語義相似度越低，性能下降越快
干擾資訊：存在無關內容時，負面影響會加劇
資訊結構：乾草堆的組織方式比單純的語義相似度更重要
想像一下在 10 萬字的文件中找一根針——即使 AI 的「眼睛」能看到整個文件，它的「注意力」卻會隨著文件變長而越來越分散。
Source: Chroma 與 Adaline Labs
二、技術解方：RLM 如何對抗上下文腐化
什麼是 RLM？
RLM（Recursive Language Models，遞歸語言模型） 是一種專門為解決 Context Rot 而設計的推理策略。它允許語言模型遞歸地調用自己或其他 LLM，來處理無限長度的輸入上下文。
RLM 的核心設計理念
RLM 的運作方式類似於我們人類處理複雜資訊的方法——分而治之：
變數化儲存：將提示詞（prompt）作為 Python 變數存儲在 REPL 環境中
遞歸回調：允許 REPL 環境回調 LLM，實現遞歸分解和處理
選擇性輸入：根 LLM 只接收查詢部分，而非完整的長上下文
REPL 是什麼？ Read-Eval-Print Loop（讀取-求值-輸出循環）是一種互動式程式設計環境。RLM 利用 REPL 讓 LLM 可以程式化地操作和處理上下文資料。
PM白話文理解：廚房裡面有主廚、二廚、助理；主廚有最高權限，去請二廚與助理做事情，而不在是主廚做全部事情。想像一下，主廚都會做，但你要他同時做一堆事情，他一定會亂掉，品質下降。倒不如我請人專心做。
這部分應該講給老闆聽（誤）
Source: Alex Zhang
RLM 的三大策略
策略一：上下文分解
將長上下文分割成較小的部分，每次只讓模型處理其中一部分，避免單個 LLM 調用處理過長內容。
策略二：遞歸處理
根 LLM 可以啟動遞歸子查詢，對上下文的特定部分進行深入分析，就像在文件中先用 Ctrl+F 粗略搜尋，再針對結果深入閱讀。
策略三：程式化操作
使用 regex 等工具粗略過濾上下文，然後在縮小的範圍內進行遞歸 LLM 調用。
實驗證明的成效
在 OOLONG 基準測試中：
使用 GPT-4o-mini 的 RLM，在處理超過 128k token 的查詢時，表現優於單獨使用 GPT-4o
在 BrowseComp-Plus 數據集上：
RLM(GPT-4o) 是唯一能在 1,000 個文檔規模下維持完美性能的方法
成本效益： 即使使用較小的模型，RLM 也能在成本更低的情況下，達到甚至超越更大模型的表現。
三、一般使用者實戰指南：Figma Make 的八大最佳實踐
雖然 RLM 是技術層面的解決方案，但對於一般使用者來說，我們如果要Vibe Coding最常用的工具之一就是Figma Make，可以從 Figma Make 的官方最佳實踐中學到如何在日常使用中避免 Context Rot。
Source: Figma
PM白話文：其實我認為若不是用Figma Make開發也可以參考，這是General觀點。另外，以下的實踐不用硬記，請想像成在跑Scrum專案的情形。一開始還是會說明專案框架，Step by Step進行開發與驗證，Recap專案開發進度。下方的部分策略是類似的概念。
策略 1：前置式詳盡提示（Front-loading）
核心概念：在第一次提示中包含越多細節，後續需要的調整就越少。
Figma Make 使用 Anthropic 的 Claude Sonnet 4，因此 Anthropic 的提示最佳實踐也適用。一個完整的初始提示應包含：
任務（Task）：AI 應該做什麼
背景（Context）：這個流程或畫面在哪裡使用
關鍵設計元素：應該包含的重要功能
預期行為：元素互動時會發生什麼
限制條件：裝置、版面配置或視覺樣式等限制
實際範例：
專案概述：我正在建立一個語言學習 app 的單字卡功能
平台規格：iOS & Android，響應式設計 用途：讓使用者可以透過滑動卡片來學習新單字
核心功能： - 顯示單字、發音、例句 - 左滑標記為「需要複習」 - 右滑標記為「已掌握」 - TTS 語音播放功能
設計風格：採用 Material 3 設計系統，使用柔和的漸層背景
技術規格：需要與 Supabase 後端整合，支援多語言 為什麼這個策略有效？
當你前置所有重要資訊時，這些資訊會位於上下文視窗的「開頭」，是 AI 最能可靠存取的區域。這就像在會議開始時先設定好議程和目標，而不是在會議中途才慢慢補充。
策略 2：小步迭代而非大幅修正
核心概念：將複雜專案分解為較小、專注的步驟，比一次性修正所有問題效果更好。
Figma 的 Designer Advocate Tammy Taabassum 說：「範圍越小，LLM 就能越詳細。」
實際應用：
一位 alpha 測試者 Antonella Rodriguez 在建立完整的財務儀表板時，使用了超過 150 個提示。她的做法是：
第一階段：建立基本版面和核心功能
第二階段：逐頁填充內容
在日誌頁面加入便利貼來新增筆記在財務頁面加入表格，包含類別、支出類型、美元金額、披索金額、備註、日期加入核取方塊來說明使用的貨幣類型：USD 或 ARS
為什麼這個策略有效？
每次小幅修改都能讓 AI 保持對當前任務的清晰理解，避免在複雜指令中迷失。這也符合 RLM 的分解原則。
策略 3：明確描述取代模糊指令
核心概念：使用精確的數值和具體的動作描述，而非抽象的設計詞彙。
不好的提示 ❌
垂直對齊兩個元素讓版面看起來更平衡改善使用者體驗
好的提示 ✅
將這個元素向下移動 20 像素在這兩個按鈕之間加入 16px 的間距將標題字體從 16pt 改為 20pt
策略 4：使用 Point and Edit 工具快速調整
對於非視覺性的小改動，使用「go to source」按鈕可以直接找到元素背後的程式碼。Figma Make 的程式碼標記清楚易懂，即使沒有編碼經驗也能辨識哪部分控制哪些行為。
策略 5：檔案整理是成功的前提
在將設計匯入 Figma Make 前，花時間整理檔案和設定 Auto Layout。正確的框架約束和 Auto Layout 設定是確保設計能良好轉換的最重要參數。
建議使用的工具：
Figma 的 AI 功能：Suggest Auto Layout、Rename layers with AI
外掛程式：Clean Document
策略 6：善用元件保持一致性
來自元件庫的元件通常已經配置好 Auto Layout 和一致的圖層命名，能很好地轉換到 Make。你也可以將元件貼入提示框作為視覺參考點。
策略 7：整合真實資料
Figma Make 允許建立具有自訂或即時資料的介面。你可以：
要求 Figma Make 提供預期的資料類型
明確要求在介面中加入資料匯入入口
策略 8：將 AI 變成交接助手
提示 Make 創建能生成 production-ready 程式碼片段的介面，創建自己的交接工具來產生設計選擇和程式碼輸出。
四、日常實用替代方案：主動管理對話生命週期
除了 Figma Make 的專業建議外，以下是適用於所有 AI 對話場景的通用策略：
方案 1：為每個主題開新對話
原則：一個對話 = 一個主題
就像你不會在討論行銷策略的會議中突然開始分析財務數據，AI 對話也應該保持主題的單一性。當出現不相關的問題時，開啟新對話——特別是當它不需要當前對話的上下文時。
實際操作：
✅ 對話 A：語言學習 app 的 UI/UX 設計
✅ 對話 B：Supabase 資料庫結構規劃
✅ 對話 C：API 串接的技術問題
❌ 在同一對話中混雜所有主題
方案 2：定期請 AI 總結並另存新檔
核心概念：在對話變得過長或即將結束時，請 AI 總結關鍵內容，然後將總結貼到新對話中繼續。
操作步驟：
步驟 1：請求總結
請總結我們這次對話的重點，包括：
1. 主要目標和需求
2. 已確定的設計決策
3. 技術規格和限制
4. 下一步待辦事項 請用結構化的格式呈現，方便我貼到新對話中。 步驟 2：檢視與修正
檢查 AI 提供的總結是否準確完整。如果有遺漏或錯誤，立即指正。這個步驟很重要，因為你要確保帶入新對話的資訊是正確的。
步驟 3：開啟新對話
將總結貼到新對話的第一則訊息中，加上新的任務描述。
範例：
【前次對話摘要】
我們正在開發一個語言學習 app，核心功能是 AI 生成的單字卡。
已確定： - 使用 Figma Make 作為前端原型工具 - 後端使用 Supabase - API 整合 Google AI Studio 的 Gemini 2.0 - 已設定 TTS 功能和例句生成 - 採用 Material 3 設計系統
【本次任務】 現在我想要優化單字卡的動畫效果，讓滑動更流暢... 為什麼這個策略有效？
新對話從較小的上下文開始，給 AI 更多「呼吸空間」
總結過程本身就是一次資訊驗證
你主動控制了哪些資訊要保留，哪些可以捨棄
方案 3：使用專案功能（ChatGPT Projects / Claude Projects）
如果你使用的 AI 工具支援專案功能，這是目前對抗 Context Rot 最有效的原生方案。
ChatGPT Projects 的優勢：
可以設定專案層級的指令和知識庫
專案內的記憶功能可以跨對話存取資訊
不同對話可以共享相同的基礎設定
Claude Projects 的優勢：
可以上傳參考文件（最多 200MB）
專案設定會自動套用到每個對話
團隊成員可以共享專案設定
實際應用：
建立一個「語言學習 App 開發」專案，在專案指令中包含：
專案背景： 我正在開發一個 AI 驅動的語言學習 app...
技術堆疊：
- 前端：Figma Make - 後端：Supabase - AI API：Google AI Studio (Gemini 2.0)
設計原則：
- 遵循 Material 3 設計系統
- 優先考慮行動裝置體驗 - 確保 API 成本控制在預算內
重要限制：
- Google AI Studio API 預算上限為每月 $50
- 需支援繁體中文、英文、日文 然後在專案內可以開多個對話：
對話 1：UI 設計迭代
對話 2：API 整合問題
對話 3：效能優化討論
方案 4：戰略性強化關鍵資訊
核心概念：定期要求 AI 複述關鍵定義、重複重要指令，將這些資訊「推」到上下文視窗的前端。
操作時機：
每 20-30 輪對話
當你感覺 AI 開始偏離主題時
在進入新的子任務前
範例提示：
在我們繼續之前，請確認以下重點：
1. 這個 app 的核心價值主張是什麼？
2. 我們設定的三個主要技術限制是什麼？
3. 目前為止最重要的設計決策有哪些？ 這不僅能刷新 AI 的「記憶」，也是一個檢查點，確保 AI 的理解仍然準確。
方案 5：保持自己的筆記
不要完全依賴 AI 的記憶——你自己的記憶也不完美！保持一份簡單的筆記，記錄：
重要決策和理由
已解決的技術問題
待辦事項清單
有用的提示範例
我個人使用 Notion 來管理這些筆記，並建立了一個「AI 對話索引」來快速找到之前討論過的主題。
五、綜合策略：建立你的 Context Rot 防禦系統
結合技術理解和實務技巧，這是我個人的 AI 對話管理框架：
對話開始前（Pre-flight Check）
明確單一目標：這次對話要解決什麼問題？
準備初始提示：包含所有必要的背景資訊
選擇合適工具：是否需要用到專案功能？
對話進行中（In-flight Management）
監控對話長度：超過 30-40 輪就考慮換新對話
觀察 AI 表現：出現重複、泛化、遺忘徵兆時警覺
定期檢查點：每 20 輪請 AI 確認關鍵資訊
小步迭代：一次只改一件事
對話結束後（Post-flight Debrief）
請求詳細總結：包含決策、規格、待辦事項
驗證準確性：確保總結沒有錯誤或遺漏
儲存關鍵產出：程式碼、設計檔、重要對話截圖
更新個人筆記：記錄學到的新知識
結論：與 AI 協作的新範式
Context Rot 不是 bug，而是現階段 LLM 技術的固有特性。理解這個限制，不是為了抱怨它，而是為了更聰明地與 AI 協作。
從 RLM 這樣的技術解決方案，我們學到了「分而治之」的智慧。從 Figma Make 的最佳實踐，我們學到了「前置詳細資訊」和「小步迭代」的重要性。從日常使用經驗，我們學到了主動管理對話生命週期的必要性。
記住這三個核心原則：
前置優先：在對話開始時提供完整資訊
主動分段：不要等 AI 失憶才換對話
定期驗證：用總結和檢查點確保資訊準確
作為一個每天使用 AI 工具的產品經理，我深深感受到：AI 不是魔法，而是工具。就像任何工具一樣，了解它的限制和最佳使用方式，才能發揮最大價值。
當你下次發現 AI 開始「忘記」你的指令時，不要沮喪——打開一個新對話，用一個結構良好的總結開始，你會發現一切又回到正軌了。
最後的建議： 把這篇文章的核心概念總結成一個提示範本，存在你的筆記中。當你開始一個新的 AI 專案時，直接拿出來用。這就是我說的「與 AI 協作的新範式」——不是被動接受它的限制，而是主動設計你們的協作流程。
其他參考連結：
https://www.ptt.cc/bbs/Soft_Job/M.1756471875.A.A00.html
https://llmindset.co.uk/posts/2024/07/chatgpt-claude-productivity-techniques/