# Vibe Coding 上下文管理技巧

> 讓 AI 真正理解你的專案



你好，我是魚皮。

在前兩篇文章裡，我們講了 Vibe Coding 的核心心法和對話技巧。今天我們要聊一個更底層、但同樣重要的話題 —— 上下文管理。

你可能遇到過這樣的情況：剛開始和 AI 對話時，它表現得很聰明，生成的程式碼也很符合你的要求。但聊了一會兒之後，它開始失憶了，忘記了你之前說過的技術棧、忘記了專案的設計風格，甚至開始用完全不同的方案來實現功能。

這不是 AI 變笨了，而是它的記憶出了問題。下面我就來教你如何通過 **上下文工程**，給 AI 裝上一個可靠的「記憶補丁」。



## 一、什麼是上下文工程

在講具體方法之前，我們先要理解什麼是上下文。




### 上下文就是 AI 的工作記憶

想像一下，你在和一個新同事合作開發專案。如果你每次都要從頭解釋專案是什麼、用的什麼技術、有什麼規範，那效率會很低。但如果你們有一份共享的專案文件，新同事看一眼就能明白，那合作就會順暢很多。

上下文就是這份「專案文件」。它包含了 AI 需要知道的所有背景資訊：

- 你的專案是什麼
- 用的什麼技術棧
- 有什麼設計規範
- 已經完成了哪些功能
- 當前在做什麼

有了這些資訊，AI 才能給出準確、一致的答案。



### 上下文的重要性

很多人把精力放在「寫好提示詞」上，但其實，**上下文可能比提示詞更重要**。

一個好的提示詞能讓 AI 理解你當前的需求，但一個好的上下文能讓 AI 理解你的整個專案。前者是「點」，後者是「面」。

舉個例子，如果你只說「幫我寫一個按鈕」，AI 可能會用原生 HTML 寫，也可能用 React 寫，樣式也是它自己決定的。

但如果你提供了完整的上下文「專案用 React、Tailwind CSS、設計風格是簡約現代、主色調是藍色」，AI 就能給你一個完全符合專案風格的按鈕。這就是上下文的力量。




### 上下文的 3 個層次

上下文可以分為 3 個層次：

1. 專案級上下文：整個專案的基本資訊，比如技術棧、設計規範、目錄結構等。

2. 功能級上下文：當前正在開發的功能的資訊，比如這個功能要做什麼、依賴哪些其他功能等。

3. 對話級上下文：當前對話中的臨時資訊，比如剛才討論的問題、生成的程式碼片段等。

![](https://pic.yupi.icu/1/contextlevel%E5%A4%A7.jpeg)

管理好這三個層次的上下文，你就能讓 AI 始終「在狀態」。



## 二、AI 的短期記憶

我們先從最基礎的開始 —— 如何管理 AI 的短期記憶？




### 什麼是上下文窗口？

AI 有一個上下文窗口（Context Window），可以理解為它的短期記憶容量。這個窗口是有限的，通常是幾千到幾十萬個 token（大約相當於幾千到幾十萬個單詞）。

當你和 AI 對話時，每條訊息都會佔用這個窗口的空間。對話越長，窗口就越滿。當窗口滿了，早期的對話內容就會被遺忘。

這就是為什麼 AI 會失憶，不是它真的忘了，而是早期的資訊已經被擠出窗口了。




### 一個對話，一個任務

最簡單的管理方法就是：**一個對話只做一件事**。

不要在一個對話裡既討論登入功能，又討論支付功能，還討論效能優化。這樣會讓上下文變得混亂，AI 也容易搞混。

正確的做法是：

- 做登入功能時，開一個新對話
- 做完了，測試通過了，再開一個新對話做支付功能
- 遇到效能問題，又開一個新對話專門討論優化

每個對話都聚焦一個任務，上下文就會保持清晰。

當然，如果是多個簡單的功能，都放在一個對話裡也沒有問題，靈活一點~




### 定期壓縮上下文

如果一個任務確實需要很長的對話，你可以定期壓縮上下文。

具體做法是：當對話進行到一半時，讓 AI 總結一下到目前為止的進展。

有些 AI 程式設計工具自帶了總結上下文的指令，可以直接使用：

![](https://pic.yupi.icu/1/image-20260104180238760.png)

也可以手動輸入提示詞來總結：

```markdown
請總結一下我們到目前為止做了什麼，包括：
1）完成了哪些功能
2）使用了哪些技術方案
3）還有哪些待解決的問題
```

然後，你可以用這個總結開始一個新對話，繼續後面的工作。這樣就相當於把之前的長對話壓縮成了一個簡短的總結。



### 善用回顧

在新對話開始時，讓 AI 簡單回顧一下之前的內容。

比如：

```markdown
我們之前做了一個登入表單，使用了 React Hook Form 和 Zod 驗證。現在我想在登入成功後跳轉到首頁。
```

這樣 AI 就能快速回憶起之前的工作，給出連貫的答案。



## 三、AI 的長期記憶

除了對話中的短期記憶，你還需要給專案建立長期記憶，典型的做法是 **提供專案文件**。



### README.md 專案的身份證

`README.md` 是專案最重要的文件，它應該包含：

1. 專案簡介：這個專案是做什麼的，解決什麼問題

2. 技術棧：用了哪些技術、框架、庫

3. 目錄結構：主要檔案和資料夾的作用

4. 開發規範：程式碼風格、命名規則等

5. 如何執行：安裝依賴、啟動專案的命令

一個好的 `README.md` 應該讓任何人（包括 AI）看一眼就能理解專案的基本情況。

舉個例子：

````markdown
# 我的部落格系統

一個簡潔的個人部落格系統，支援 Markdown 寫作和程式碼高亮。

## 技術棧

- 前端：Next.js 14 (App Router) + TypeScript + Tailwind CSS
- 後端：Supabase (PostgreSQL + Auth)
- 部署：Vercel

## 目錄結構

- `/app` - Next.js 頁面和路由
- `/components` - 可複用元件
- `/lib` - 工具函數和配置
- `/public` - 靜態資源

## 開發規範

- 使用函數式元件，不用 class 元件
- 所有元件都要有 TypeScript 類型
- 樣式使用 Tailwind CSS，不寫自訂 CSS
- API 呼叫統一使用 `/lib/api.ts` 中的函數

## 如何執行

```bash
npm install
npm run dev
```
````

魚皮開源專案的 `README.md` 基本都是遵循這種結構化格式的，比如 [AI 零程式碼應用生成平台專案](https://github.com/liyupi/yu-ai-code-mother)，供大家參考。

每次開始新對話時，把 `README.md` 的內容貼給 AI，它就能快速了解你的專案。



### TODO.md 專案的任務清單

`TODO.md` 記錄了專案的待辦事項和進度，它應該包含：

1. 已完成的功能：哪些功能已經做好了

2. 正在開發的功能：當前在做什麼

3. 待開發的功能：接下來要做什麼

4. 已知問題：有哪些 bug 或待優化的地方

舉個例子：

```markdown
# 開發進度

## 已完成 ✅

- [x] 使用者註冊和登入
- [x] 文章列表頁
- [x] 文章詳情頁
- [x] Markdown 渲染

## 進行中 🚧

- [ ] 文章編輯功能
  - [x] 編輯器介面
  - [ ] 儲存草稿
  - [ ] 發布文章

## 待開發 📋

- [ ] 評論功能
- [ ] 搜尋功能
- [ ] 標籤系統

## 已知問題 🐛

- 行動端導覽列在某些裝置上顯示不正常
- 程式碼高亮在暗色主題下對比度不夠
```

`TODO.md` 能讓你和 AI 都清楚地知道專案的進度，避免重複工作或遺漏功能。



### 及時更新文件

文件最大的問題就是過時。所以，每次完成一個功能或做了重要改動，都要及時更新 `README.md` 和 `TODO.md`。

你可以讓 AI 幫你更新：

```markdown
我們剛才完成了文章編輯功能。請幫我更新 TODO.md，把 "文章編輯功能" 標記為已完成。
```

AI 自然也知道這件事的重要性，所以在我們生成程式碼時 AI 可能會自動為我們生成這些文件。



## 四、AI 程式設計工具的上下文策略

不同的 AI 工具對上下文的處理方式不同，你需要了解它們的特點。




### Cursor 的 .cursorrules

Cursor 支援在專案根目錄建立 `.cursorrules` 檔案，作為專案的系統提示詞。

你可以在這個檔案裡寫上：

```
這是一個 Next.js 的部落格專案。

技術棧：
- Next.js 16 (App Router)
- TypeScript
- Tailwind CSS
- Supabase

程式碼規範：
- 使用函數式元件
- 所有元件必須有 TypeScript 類型定義
- 樣式只用 Tailwind CSS
- 不要使用 any 類型

設計風格：
- 簡約、現代
- 主色調：#3B82F6 (藍色)
- 圓角：8px
- 陰影：subtle

請始終遵循這些規範。
```

這樣，Cursor 在生成程式碼時就會自動參考這些規則。

💡 注意，隨著 AI 程式設計工具的更新，這些規則可能會有變化，建議還是多看看 [官方文件](https://cursor.com/cn/docs/context/rules)。

![](https://pic.yupi.icu/1/image-20260104181209687.png)



### Claude Code 的 CLAUDE.md

Claude Code 會讀取專案根目錄下的 `CLAUDE.md` 檔案作為上下文。

你可以在這個檔案裡放更詳細的資訊：

```markdown
# 專案上下文

## 專案概述
個人部落格系統，支援 Markdown 寫作。

## 技術棧
- Next.js 16 + TypeScript + Tailwind CSS
- Supabase (資料庫 + 認證)

## 重要決策
1. 為什麼選擇 Supabase：簡單、免費額度夠用、自帶認證
2. 為什麼用 App Router：這是 Next.js 的未來方向
3. 為什麼不用 Redux：專案簡單，用 React Context 就夠了

## 已知問題
- 行動端導覽列需要優化
- 程式碼高亮主題需要調整

## 下一步計劃
- 實現評論功能
- 添加搜尋
```

這個檔案相當於給 AI 的專案手冊。




### 通用策略：上下文資料夾

如果你用的工具不支援特定的上下文檔案，可以建立一個 `/docs` 資料夾，把所有文件放在裡面：

```
/docs
  - README.md (專案概述)
  - TECH_STACK.md (技術棧詳情)
  - DESIGN.md (設計規範)
  - API.md (API 文件)
  - TODO.md (任務清單)
```

每次開始新對話時，把相關文件的內容貼給 AI 就好。



## 五、上下文斷裂的修復技巧

即使你做好了上下文管理，有時候 AI 還是會斷片兒。這時候，你需要知道如何修復。



### 怎麼識別斷裂？

上下文斷裂一般有這些表現：

- AI 突然用了不同的技術棧（比如你明明用 React，它卻給你寫 Vue 程式碼）
- AI 忘記了之前討論的設計方案
- AI 生成的程式碼風格和之前的不一致
- AI 重複問你已經回答過的問題

一旦發現這些訊號，就要及時修復。



### 修復方法 1、重新提供上下文

最簡單的方法就是重新把上下文貼一遍。

```markdown
等等，我們的專案用的是 React 和 TypeScript，不是 Vue。
這是我們的技術棧：【貼上 README.md 的技術棧部分】。請用正確的技術棧重新生成程式碼。
```



### 修復方法 2、引用之前的內容

如果是忘記了之前討論的內容，可以引用一下。

```markdown
還記得我們之前決定用 Context API 管理狀態嗎？請繼續用這個方案，不要改用 Redux。
```



### 修復方法 3、開新對話

如果上下文已經混亂到無法修復（比如同一個 Bug 多次修復都沒有結果），最好的辦法就是開一個新對話。

在新對話中，先提供完整的上下文，然後繼續工作。這樣雖然要重新開始，但能保證後續的對話品質。



### 修復方法 4、回到正軌提示詞

有時候，你可以用一個明確的提示讓 AI 回到正軌。

```markdown
請暫停。我們現在的目標是實現登入功能，使用 React Hook Form 和 Supabase Auth。
請確認你理解了這個目標，然後我們繼續。
```

這相當於給 AI 一個重啟的機會。不過魚皮測試下來，有時這個提示詞不一定會生效。



## 六、上下文管理的最佳實踐

基於我的經驗和社群的總結，這裡是一些上下文管理的最佳實踐。


### 1、專案開始時就建立文件

不要等到專案做到一半才想起來寫文件。從第一天就建立 `README.md` 和 `TODO.md`，並保持更新。

這樣不僅能幫助 AI，也能幫助你自己理清思路。



### 2、用工具的原生上下文機制

如果你用的工具支援特定的上下文檔案（比如 `.cursorrules`），優先使用這些機制，它們是最高效的。



### 3、保持上下文簡潔

上下文不是越多越好。太多的資訊反而會讓 AI 困惑。

建議只提供最重要、最相關的資訊。如果一個資訊對當前任務沒用，就不要放進上下文，還會浪費 tokens。



### 實踐四：用層次化的結構

建議把上下文分成不同的層次和檔案，而不是全部堆在一個檔案裡。

比如：
- README.md 放專案概述和基本資訊
- TECH_STACK.md 放詳細的技術棧說明
- DESIGN.md 放設計規範
- 每個功能模組有自己的文件



### 實踐五：定期回顧和更新

每週或每完成一個大功能，回顧一下文件，看看有沒有過時的內容，及時更新。

你可以讓 AI 幫你檢查：

```markdown
請檢查我的 README.md，看看有沒有和當前程式碼不一致的地方。
```



### 6、用註解增強程式碼上下文

在程式碼裡加上有意義的註解，解釋「為什麼」而不只是「是什麼」。

❌ 不好的註解：

```typescript
// 獲取使用者資料
const user = await getUser(id);
```

✅ 好的註解：

```typescript
// 從 Supabase 獲取使用者資料
// 注意：這裡不包含敏感資訊（如密碼），只返回公開欄位
const user = await getUser(id);
```

好的註解能幫助 AI 理解程式碼的意圖，在修改時做出更合理的決策。



## 七、實戰案例：建立完整的上下文體系

讓我用一個真實的例子，展示如何為專案建立完整的上下文體系。

假設你要做一個線上筆記應用。


### 第一步、建立 README.md

```markdown
# 線上筆記應用

一個簡潔的線上筆記應用，支援 Markdown 編輯和即時儲存。

## 技術棧

- 前端：React 18 + TypeScript + Vite
- UI 庫：Tailwind CSS + Headless UI
- 編輯器：CodeMirror 6
- 後端：Supabase (PostgreSQL + Realtime)
- 部署：Vercel

## 核心功能

1. 使用者註冊和登入
2. 建立、編輯、刪除筆記
3. Markdown 即時預覽
4. 筆記自動儲存
5. 筆記搜尋

## 目錄結構

- `/src/components` - React 元件
- `/src/pages` - 頁面元件
- `/src/lib` - 工具函數和 API
- `/src/hooks` - 自訂 Hooks
- `/src/types` - TypeScript 類型定義

## 開發規範

- 元件使用函數式元件 + Hooks
- 所有元件必須有 TypeScript 類型
- 樣式只用 Tailwind CSS
- API 呼叫統一使用 `/src/lib/api` 中的函數
- 狀態管理使用 Zustand

## 設計風格

- 簡約、專業
- 主色調：#6366F1 (Indigo)
- 圓角：6px
- 字體：Inter
```



### 第二步、建立 TODO.md

```markdown
# 開發進度

## 已完成 ✅

- [x] 專案初始化
- [x] Supabase 配置
- [x] 使用者認證（註冊/登入）
- [x] 筆記列表頁面

## 進行中 🚧

- [ ] 筆記編輯器
  - [x] CodeMirror 整合
  - [x] Markdown 語法高亮
  - [ ] 即時預覽
  - [ ] 自動儲存

## 待開發 📋

- [ ] 筆記搜尋
- [ ] 筆記分類/標籤
- [ ] 匯出功能
- [ ] 暗色主題

## 已知問題 🐛

- 編輯器在行動端效能不佳
- 長筆記載入較慢
```



### 第三步、建立 rules 規則檔案

```
專案：線上筆記應用

技術棧：
- React 18 + TypeScript + Vite
- Tailwind CSS + Headless UI
- CodeMirror 6
- Supabase
- Zustand (狀態管理)

程式碼規範：
- 使用函數式元件
- 所有元件必須有 TypeScript 類型定義
-