---
title: "上下文管理"
date: "2026-04"
category: "ai運用"
tags: ["ai運用"]
description: "通過漸進披露的模式把入口文件作為目錄，然後不斷建立分層索引的模式來進行逐漸的展現。就像OpenAI這篇文章説的一樣，AGENTS.md/CLAUDE.md應該是一份地圖，而不是全面的手冊..."
source: "https://enriquemark.com/zh-hant/posts/%E4%B8%8A%E4%B8%8B%E6%96%87%E7%AE%A1%E7%90%86"
---

通過漸進披露的模式把入口文件作為目錄，然後不斷建立分層索引的模式來進行逐漸的展現。就像[OpenAI](https://openai.com/zh-Hans-CN/index/harness-engineering/)這篇文章説的一樣，AGENTS.md/CLAUDE.md應該是一份地圖，而不是全面的手冊。這不只是上下文視窗的問題，關鍵點在於注意力——過長的上下文只會導致腐化，注意力渙散，最終反而不如精細的上下文來的有效。

---
我們嘗試了「一個大型的 [`AGENTS.md`⁠（在新視窗中開啟）](https://agents.md/)」方法。可想而知，這是一次失敗的嘗試：
- **情境是一種稀缺資源。** 一個巨大的指令檔案會擠掉任務、程式碼和相關文件 — 因此智慧體要麼會錯過關鍵約束條件，要麼開始針對錯誤的約束條件進行最佳化。
- **過多的指導反而變得無效。** 當一切都 「重要」時，一切都不重要了。智慧體最終會在本地進行模式匹配，而不是有意識地進行導航。
- **它會立即腐爛。** 一本龐雜的手冊會變成陳舊規則的墳場。智慧體無法判斷哪些資訊仍然有效，一旦人類停止維護它，此檔案就會悄然成為一個頗具吸引力的麻煩源頭。
- **這很難核實。** 單個 blob 不適合進行機械檢查（覆蓋率、新鮮度、所有權、交叉連結），因此漂移是不可避免的。
---
説來挺搞笑，但確實應了那句話：全部都有等於全部都沒有。建立一個便攜的 docs/ 才是最正確的辦法，這就像SKLIIS.md的約束一樣——入口不要超過五百行，甚至可以更短。