上下文管理 SOP（Context Management SOP）

把「上下文」當成系統工程而不是「寫一份 prompt」——分三大支柱：①分層配置（永久層）、②單對話續命（壓縮策略）、③跨會話續命（Memory / Projects）。

為什麼存在

Cowork / Claude Code / Claude.ai 的上下文不是單一檔，它是多層疊加 + 兩種記憶機制。常見痛點都源自沒搞清楚層級：

規則寫太通用 → 每個專案重複貼相同內容
規則寫太細 → 全域層綁住所有專案
長對話 Claude「失憶」→ 沒考慮上下文壓縮的有損特性
Cowork 跨會話什麼都不記得 → 沒用 Projects 持久化空間

本 SOP 把 7 篇相關 entity 的精華整合成一張可執行的作業流程。

核心架構

支柱一：分層配置（永久層）

Cowork 端載入順序（依 Global Instructions）

1. Global Instructions   ← 最先（永遠成立的鐵律）
2. CLAUDE.md（專案手冊）  ← 進到專案才讀
3. 上下文檔（about-me 等）← 任務啟動才讀
4. 你的 prompt           ← 最後

層	內容範圍	範例
Global Instructions	每次會話都成立的鐵律	「繁中、不過度道歉、執行前列 3–5 點 plan」
CLAUDE.md（專案手冊）	該專案 / vault 的規範	「PAM 用 EF Core、禁拼 SQL」
上下文檔體系	跨專案的個人脈絡（about-me / brand-voice / working-preferences）	「我是誰、寫作風格、執行偏好」
Prompt	當下這次任務	「幫我寫 PAM 退回流程的 release note」

Claude Code 端的 4 層機制（依 CLAUDE.md 4 層機制）

L1: ~/.claude/CLAUDE.md           ← 全域個人偏好
L2: {project}/CLAUDE.md            ← 專案手冊
L3: {project}/{module}/CLAUDE.md   ← 子目錄局部
L4: 對話內 # inline                ← 臨時最高優先

關鍵心法：避免上下文污染。L1 寫太細會綁全部專案；L2 寫太通用會跨專案重複；用 L3 子目錄讓模組專屬規則自動只套用該目錄。

支柱二：單對話續命（壓縮策略）

依上下文壓縮：Opus / Sonnet / Haiku 4.6 都是 ~200K tokens，看起來大但長 debug、長 refactor 會撐爆。

三種壓縮觸發

模式	何時用
自動	context > 80% 時觸發（被動，切點不一定漂亮）
手動 `/compact`	任務告一段落主動切（推薦——你決定切點，比自動乾淨）
PostCompact Hook	由 Hooks 介入（適合長期任務，可自動存檔 + 重貼關鍵規則）

三條反壓縮反模式

上下文壓縮強調「壓縮是有損的」，LLM 自己決定丟什麼。對策：

重要決策不要只留在對話裡 → 寫進 CLAUDE.md（專案手冊）或 Projects 持久化空間
走到一半發現方向錯 → 重起新對話比修補上下文更乾淨
接近 context 上限時 → 主動把進度摘要寫到檔案 → 新對話接續

觀察壓縮已發生的徵兆

Claude 突然忘記你說過的規範、提問「你之前提到的 X 是什麼」、重複建議已被否決的方案——很可能壓縮把該段丟了，重貼脈絡或回頭檢視 CLAUDE.md（專案手冊）。

支柱三：跨會話續命（Memory / Projects）

⚠️ 關鍵限制（依 Memory 記憶功能）：

範圍	跨會話記憶？
Claude.ai 對話	✅ 透過 Memory
Cowork 會話	❌ 預設無記憶
Cowork Project 內	✅ 透過 Project 容器

→ Cowork 連續性不能靠 Memory，必須靠 Projects 持久化空間 + 上下文檔體系補。

Memory：管理「整體個人形象」

立即該做（Memory 記憶功能文章建議）：

進 Settings → Capabilities → Memory
看 Claude 已記住什麼
修不準 / 過時的
補它應該知道的背景（角色、服務對象、偏好工具、常用縮寫）

隱身對話（Incognito）開啟後該次不寫入記憶——適合敏感探索。

Projects：管理「這個工作」

對 Vincent 最有價值的三種用法（Projects 持久化空間）：

PAM 系統開發 = 一個 Project：檔案 + GitHub/Notion connector + CLAUDE.md（專案手冊）全部綁進去
2026 年中考核 = 一個 Project：整個 2–3 月週期的對話跨會話有記憶
每位重要客戶 = 一個 Project：合同 / 紀錄 / Slack 共享頻道綁一起

Memory vs 上下文檔

並用：Memory 記「整體個人形象」（雲端，跨裝置同步），上下文檔體系記「具體工作執行偏好」（本機檔，可入 git）。

Vincent 具體執行 SOP

立刻做（30 分鐘）

檢查 Memory（Memory 記憶功能）：Settings → Memory，確認「年代集團 IT 主管 / PAM / 繁中 / 技術名詞英文 / 不過度道歉」這些都在
寫 Global Instructions（Global Instructions）：搬「繁中、不過度道歉、執行前列 plan、需新建 entity 時先用 wiki-ingest skill」進去
建 PAM 專案 Project（Projects 持久化空間）：把 ExamSystem 資料夾掛進去，連 GitHub + Notion connector

中期（1–2 週）

寫上下文檔體系三件組（建構成本 ~45 分鐘換來「10 個詞 prompt 就出可交付」）：
- about-me.md — 你是誰 + 服務對象 + 當前優先順序
- brand-voice.md — 寫作風格 + 2–3 段真實樣本
- working-preferences.md — 執行規範
PAM 子目錄加 L3 CLAUDE.md（依 CLAUDE.md 4 層機制範例）：
- client-app/CLAUDE.md — TanStack Query / Zustand 規範
- Migrations/CLAUDE.md — Add_<Feature>_<Date> 命名規則

長期心法（複利機制）

「Claude 輸出不符預期時」的迭代原則（上下文檔體系）：先判斷是「提示詞問題」還是「上下文問題」——多數是後者，改 .md 規則一勞永逸，比每次重解釋有複利效應
長對話主動 /compact（上下文壓縮）：別等自動觸發
走錯方向就重起新對話（上下文壓縮）：比修補上下文乾淨

跟 Karpathy LLM Wiki Pattern 的呼應

上下文檔體系點出一個漂亮的對應：

Karpathy 三層 ↔ Cowork 上下文管理
raw/         ↔ 工作資料夾的素材
wiki/        ↔ Claude 整理的工作成果
Schema       ↔ 上下文檔 + CLAUDE.md

→ 上下文檔 = 個人版的 Schema layer。裝了 wiki-ingest / wiki-query 等 skill 後，這個 schema 升級成可動態查詢的知識庫——上下文不只是「貼在那裡」，而是 query 出來的。

何時不用這份 SOP

一次性簡單問答 → Memory 自動處理就夠
完全新的探索性任務 → Incognito 對話 + 不污染記憶
跑 Sub-agent / Agent Teams 的並行任務 → 走另一套 agent 隔離原則

Vincent5588 Wiki

探索

上下文管理 SOP