---
# System prepended metadata

title: AI 記憶是假議題：真正該解決的是 Context Engineering
tags: [Prompt Engineering, AI, Context Engineering, Claude, LLM]

---

---
title: AI 記憶是假議題：真正該解決的是 Context Engineering
tags: [AI, LLM, Context Engineering, Prompt Engineering, Claude]

---

# AI 記憶是假議題：真正該解決的是 Context Engineering
> 你是不是也有過這種感覺——花半小時跟 AI 解釋完專案背景，好不容易進入狀況，下次對話又要從頭來過？社群一直在吵 AI 記憶不夠，但我覺得這個方向從一開始就問錯了。

![context-engineering](https://hackmd.io/_uploads/rk0ihDIaWe.png)

---

# 1️⃣ 記憶這個比喻，從一開始就在誤導

我們說「AI 需要記憶」的時候，腦中浮現的是人類記憶的樣子：慢慢累積、越記越豐富、時間久了自然就懂你。

這個比喻很直覺，但跟 LLM 實際運作完全不是那麼回事。

LLM 本質上是 stateless function（這裡指的是跨呼叫不保留狀態，單次生成內部的 KV cache 不算）。每次推理，它只能看到當前 context window 裡有什麼。沒有長期儲存、沒有跨 session 的狀態、沒有「記憶」這個東西——有的只是：

```
f(context) → response
```

這不是缺陷，這是設計。問題從來不在它記不住，而在於**你送進去什麼**。

---

# 2️⃣ 跨 Session 記憶聽起來很美，實際上很糟

假設你真的把所有對話歷史都持久化、每次 session 都全部注入，你以為會變好，但實際上：

- 三個月前討論的架構決策，現在莫名其妙影響你問的新問題
- 當時評估過但排除的方案，AI 又把它撿回來推薦你
- 你換了個任務方向，AI 還在用舊的假設幫你推理
- Context window 塞滿沒整理過的歷史對話，真正重要的資訊反而被稀釋掉

這就是 context pollution。記憶越多，不等於表現越好。沒整理過的對話歷史一直堆，只會讓 AI 越來越難搞清楚你現在要什麼。

---

# 3️⃣ 「可是 Claude、ChatGPT 都有 memory 功能了啊」

對，而且做得越來越好。但你仔細看它們的實作——都不是把對話歷史原封不動塞回來，而是抽取出結構化的事實、使用者偏好、專案背景，整理過之後再注入。

換句話說，這些 memory 功能本質上就是**把 context engineering 自動化**的一部分。它們反而印證了方向是對的：該記什麼、怎麼組織、什麼時候帶進來，才是真正的問題——不是「能不能記住一切」。

---

# 4️⃣ 重新定義問題：Context Engineering

所以正確的問法不是「AI 怎麼記住更多」，而是：

> 每一次對話，我需要帶入什麼資訊？這些資訊怎麼組織？

這是個工程問題，不是記憶問題。我把它叫做 Context Engineering，因為這東西得自己主動設計、主動維護，不是靠自動累積就能解決的。

我自己用的思考框架是把 context 分三層：

| Layer | 名稱 | 內容 | 策略 |
|-------|------|------|------|
| L1 | Static Identity | 角色定義、行為規範、輸出格式 | 每次都帶，幾乎不變 |
| L2 | Domain Knowledge | 專案架構、業務規則、技術決策 | 按需注入，人工維護 |
| L3 | Session State | 當前任務目標、中間產物、剛執行完的工具輸出 | session 內累積，結束即丟掉 |

這裡有個關鍵差別：L1 和 L2 是**結構化文件**，不是對話紀錄。

你維護的不是「AI 說過什麼」，而是「當前狀態的事實」。這兩件事看起來很像，差很多。對話紀錄會過時、會失準；結構化文件是你主動維護、可以 review、可以刻意刪減的東西。

---

# 5️⃣ context 品質，才是真正的瓶頸

給同一個模型，context 品質高的人得到的結果會好非常多。這不是什麼 prompt 技巧，而是更根本的事：

**你對問題的理解程度，決定你能提供什麼 context。context 的品質，決定 AI 能給你什麼答案。**

所以就算 AI 記住了一切，你送進去的 context 結構爛，結果還是會爛。反過來，context 精準的人，每次從零開始也沒差——因為他們知道哪些資訊是必要的，用最少的輸入就能讓 AI 快速定位到問題核心。

這也解釋了為什麼有些人用 AI 用得很順，有些人一直覺得 AI 不夠聰明。差距不在模型，在 context 品質。

---

# 6️⃣ 同樣的問題，兩種 context 的差別

講那麼多，看個實際對比最快。假設你現在要決定一個快取方案，兩種問法送進 AI：

**❌ 爛 context**

```
幫我看一下這個快取要怎麼做
```

AI 只能從零開始反問：什麼語言？什麼規模？要分散式嗎？資料會變動嗎？
你得來回好幾輪才能進入主題，而且 AI 可能把 Redis、Memcached、資料庫快取全部列一遍讓你自己挑。

**✅ 好 context**

```
專案用 .NET 10 + in-memory 快取，先前評估 Redis 但因維運成本排除。
現在要加一個「商品清單」查詢快取：
- 資料量：約 5000 筆
- 更新頻率：每天 2~3 次
- TTL 需求：5 分鐘

問：直接用 IMemoryCache 夠嗎？還是該自己包一層 TTL 機制?
```

AI 直接進入問題核心：評估 `IMemoryCache` 內建 TTL 是否夠用、需不需要額外的失效策略，不會再把 Redis 推回來。

差別不在模型多聰明，在於你送進去的東西有沒有經過設計。

---

# 7️⃣ 實務上怎麼做

說穿了其實不複雜：

**長期專案開發**：維護一份 `project-context.md`，記技術決策、架構現況、已評估但排除的選項（還有為什麼排除）。每次 session 開始時帶進來。

尤其「為什麼不選這個」一定要寫進去，不然 AI 會一直把你已經否決的方案又推回來。像這樣：

````markdown
## 已評估但排除的方案

- **Redis 分散式快取** — 2026-02 評估，維運成本過高，改用 in-memory + 定期同步
- **GraphQL** — 團隊熟悉度不足，暫用 REST，保留未來遷移空間
````

短短幾行，就能省掉每次 session 重新解釋的工。

**技術評估討論**：一開始就講清楚評估目標、限制條件、已知的取捨。不要讓 AI 從頭猜你在什麼情境下問這個問題。

**跨議題切換**：明確講「換話題了」。不要假設 AI 能自動感知你的任務已經變了，舊的 context 會繼續污染新的推理。

**一次性問答**：什麼都不用做。問題本身就是完整的 context。

Claude Code 的 `CLAUDE.md` 剛好是個現成的例子——它不是什麼「記憶」，就是每次 session 確定性注入的 persistent context。你寫什麼進去，AI 就帶著什麼開始工作。這個設計方向是對的。

---

# ✅ 結語

AI 記憶的討論會一直存在，因為它觸碰到一個真實的痛點：每次重新說明背景很麻煩。

但解法不是讓 AI 記住更多。解法是讓你需要說明的東西更少、更精準——把重要的 context 結構化，知道什麼該帶進來、什麼不用，每次對話都能快速切到重點。

與其問「AI 怎麼記得住」，不如問「我要怎麼組織 context」。後者才是你真正能施力的地方。

這套做法不一定適合所有人。短任務、一次性問答根本不需要。但如果你常和 AI 做長期協作，花點時間經營 context，比期待 AI 「記性變好」實際得多。

---
📘 **HackMD 原文筆記：**  
👉 https://hackmd.io/@jeff377/context-engineering

**📢 歡迎轉載，請註明出處**
**📬 歡迎追蹤我的技術筆記與實戰經驗分享**
[Facebook](https://www.facebook.com/profile.php?id=61574839666569) ｜ [HackMD](https://hackmd.io/@jeff377) ｜ [GitHub](https://github.com/jeff377) ｜ [NuGet](https://www.nuget.org/profiles/jeff377)